Git commands — a guide for everyday work

My life went so that as an Android developer, I’ve almost never used git commands from the command line for real everyday work, as Android Studio has a very good build-in GUI tool for this. But time has come and life forced me to do all the same process I do every day in git from CLI. Proving the practice of learning from the best — google, I’ve found a hell lot of articles about top git commands, all git commands, and of course — all top git commands :)

But the truth is that I didn’t need a list of commands, this could be easily received via git help , I needed my work process turned into a list of commands. That’s how this article came to life — I won’t bother you with unnecessary commands you remember only in periods of applying for a new job, or with commands you can use only once in a couple of months — these are quite specific and so could be easily googled (git tag, git clone, git stash, git config and so on). We’ll just go through the commands you need in everyday work, step by step.

Step 0:

It is not necessary but I would highly recommend each developer to upgrade the command line like described here. It’ll make your experience with command line easier and pretty-looking.

There are also two command line life hacks that were surprisingly not obvious for me at first:

• if you’re always misspelling words like me, use the command line autotype feature — just start writing the command and press tab to see the available endings
• if you’re viewing some lines taking long-tracking space (like after git log ), exiting from it is simply done with control+z

Step 1:

Go inside your project with cd command and checkout on the base branch, from which we’ll start working:

git checkout develop

I’ve used develop branch, but it could be release/... branch, feature/... branch, and so on. You could see the list of all branches available via git branch .

Step 2:

You’ve checkout-ed to the local version of your base branch, which could be not really up-to-date, let’s update it to proceed with our work on freshly new data:

git pull

Please note that git pull is equals to git fetch + git merge , so you could go with these two commands instead (don’t know why). If you don’t need to update your local branch, but want to be up-to-date with the server (for instance — to have the updated list of branches) — use just git fetch .

Step 3:

Now let’s create a new branch (I’ll name it feature/test-git), on which we’ll be working, and checkout on it:

git checkout -b feature/test-git

This command could be also divided into two — create git branch feature/test-git and checkout git checkout feature/test-git.

Step 4:

Finally, let’s work and write some code — this is what this whole thing is about, right?!

Step 5:

Before committing files that you’ve changed and/or created and/or deleted should be added to the index:

git add .

Please note that if you’re using git version less than 2.xxx you should use git add -A instead. Here is a good explanation of how it works and what other commands could be useful.

Step 5.1:

If you don’t want to add all the files, there are two ways to add only the files you need. First, let’s see all files being changed:

git status

Now you have the names of the files. You could either add only files that you need:

git add file1 file2 file3

Or add all files and then exclude non-needed:

git add .
git reset file1

Step 6:

Commit changes with the message, describing what you’ve done:

git commit -m "some awesome stuff was done in this commit"

Step 7:

Now we need to push changes made in the local branch to the remote branch. This is done with a command that first connects your local branch with remote and then does the push (I’m doing it again for feature/test-git):

git push --set-upstream origin feature/test-git

Note that setting upstream is usually a one-time thing, and for the next commits just do:

git push

Step 8:

If you need to make your branch up-to-date with the basic branch (in our case it is develop) again use either:

git merge develop

or

git rebase develop

Please note that rebase will drive all your commits up, and git push -f will be needed afterward. For me using merge or rebase is more of a matter of taste, but you can read more about the difference here.

Step 9:

You might encounter merge conflicts during you merge/rebase , about which command line will tell you in state of error and a list of all files, containing conflicts. To resolve them, you’ll need to go through each file listed in command line (use git status if you need to get the list again) with your IDE and manually solve conflicts, which will look like this:

<<<<<< HEAD
onSomeCodeEncountered()
==========
onSomeOtherCodeEncountered()
>>>>>>> test

After that add all changed files to the index

git add fileThatCauseConflicts

And continue with merge/rebase :

git merge --continue

or

git rebase --continue

So, we’ve run through the developer’s daily git routine — creating a branch, working on it, committing changes and merging them back to the base branch.

For many of you, it should sound like something known, but I’m sure there are still developers there who are afraid of using command line more than it requires for installing software by instructions in Github's readme. I highly recommend you to go through this process via command line, then next time you’re in your favorite git client (for instance SourceTree or GitUp), you’ll understand what is going underneath this pretty interface. Or maybe you’ll decide to stay in CLI and learn git reset , git log and all other useful commands.

If you have any further questions or just want to stay in touch: https://twitter.com/YCoenova