After several years in management, one forgets how to work with git (on the contrary, one never forgets how to work with vi – I guess it has to do with the pain of the experience).

The tools: If you are working on Windows/Mac, you can get SourceTree. If you want to go vanilla, opt for official client, which is cross-platform.

I went for the latter, but still installed SourceTree – it is very good for branch visualisations, which means it is good to have at hand. Also, the official client, at least on Windows, adds git-bash, meaning you have your old linux commands at hand, along with the vi.

Let’s start with the configuration. First, config your name and email. This helps with all sorts of questions later on.

git config –global user.name “Your Name”
git config –global user.email you@example.com

Once this is done, go into folder, where you want to have the git files. Start with:

git init
git add README.md
git commit -m “first commit”
git remote add origin <whatever it says on github>
git push -u origin master

This will get the master version from GitHub on to your local repository. OK, now you have the code locally. Pay attention to the two-step process when working with git. Fetch only gets it for you, but you cannot see it. Merge will actually merge it locally with your local data. The same for add/commit and push.

Let’s discuss some customs, when working with git.

It is customary, to branch master into your own branch – that’s where you work, experiment and finally add, commit and push changes to the branch on GitHub, where you create pull requests. These are then reviewed and merged.

Let’s proceed in customary fashion and create a branch:

git checkout -b newBranch

Now you pay attention – you will see the name newBranch or master along your commands – this is important as it shows on which branch you are on.

Let’s make a change, add a new file – name is “newFile”.

To push this file to GitHub, you have to go through add, commit and push phases. First one simply adds the new file to the local repository, commit makes the commit locally and push will push it to your branch on GitHub.

git add newFile
git commit -s
git push origin newBranch

Remember: When working locally, git log and git status are your friends – you check what is going on with your repository, what changes have been applied and similar.

Now you go to GitHub and create a pull request for your branch. You now either wait for the merge (in cases where you need to work on related code) or simply create a new branch and work on another part of code.

Usually, you simply switch to the master branch, fetch new stuff and merge it to your local master. After that, you can make a new branch.

git checkout master
git fetch origin master
git merge origin/master

git checkout -b newNewBranch

In some cases, your pull request will require some changes in the code in your newBranch (the previous branch). In that case, you switch to the newBranch, do the changes and then go for the amend and forced push (see below).

git commit –amend

In some other cases, before merge happens, they will ask you to rebase your branch to the new master. This simply means that they want to see all your code changes to be checked against the most recent version of the master and to resolve any issues yourself. First, get the master.

git checkout master
git fetch origin master
git merge origin/master

You switch to the newBranch, issue rebase command, check if everything is OK and then force the push – remember, pull request is already open, this forced push simply updates it.

git checkout newBranch
git rebase master
git push –force origin newBranch

And that’s it. There is a number of tutorials out there to get you through the basics, but this one is simple and fast – under supervision of @gberginc (thanks!).

One good tutorial: http://learngitbranching.js.org/