Git HowTo:¶
Okay, here a very high level git how to. I will use the shell commands, but this is really more about the underlying concepts. I try to make it as brief as possible:
Getting a repository¶
The first thing you should do is get a local copy of the central repository. You do this by issuing
git clone ssh://username@rehmsen.de/var/git/games-programming.git
It is important to understand that different from svn, this does not only checkout a working copy, but will copy the whole repository, including all commits that have been done to it and so on.
Making a change to an existing file¶
To make a change, simply change a file. If you then type
git status
This will tell you that there have been changes made to a certain file. To commit these changes, use
git commit -a
The -a means that you want to add all changes you made to existing files to be part of the commit. If you only want to commit part of the changes, first add the files whose changes you want to commit and then commit without -a:
git add Source/foo.cpp git commit
This will not commit a possibly also changed file bar.cpp. In both cases calling commit will open a text editor (usually vi) so that you can add a commit message. You have to to that, save the file and exit, otherwise the commit will not be made. GUIs might handle this differently.
There is a funny feature in redmine: If your commit message contains something like "fixes 7" this will automatically close the issue #7 in redmine.
Adding new files¶
If you have created a new file and you want git to track it, the -a flag does not work. Use
git add path/to/newfile.cpp git commit
instead. Often you can get away with
git add . git commit
because all files that should not be tracked (temp files and so on) should be in the .gitignore file and thus not be tracked.
Pushing code to the central repository¶
After you have commit the change, it is still only in your local repository, and the rest of us still cannot access it. To make it available for everyone, call
git push origin master
origin is the name of the central repository and master tells git to push the master branch - more about branches later.
Pulling the code from the central repository¶
Similar to pushing, before you start working you want to make sure that your local repository has all changes that the others might have made in the mean time. You use
git pull origin master
Reverting a change¶
If you have made a change but then want to revert to a version in the repository (your local one) you can do so with
git checkout foo.cpp
Be careful - your local change in foo.cpp will be gone!
Branches¶
Branches are useful for trying new things. If you make an experimental change, such as Dons testbed, that you do not want to mess up everyones code if it is not properly working, create a branch, make the change in there, and push that also to the central repository if you want to share it with someone. You can then work on it until it is working and then merge it into the master branch.
To create a branch experimental, use
git branch experimental
Then type
git branch
which will list all branches and mark the currently active one with a star. To work on the branch, use
git checkout experimental
If you run git branch again, it should now have the star before experimental, not master.
Then commit your changes as above. To share the experimental branch, use
git push origin experimental
Note that your code will not be listed in redmine, as redmine only ever shows the master branch.
Merging branches¶
Say you got to the point where your experimental stuff is stable enough to move into master. Do this by changing to the master branch and merging the experimental into it:
git checkout master git merge experimental
I guess that should be enough for starters. Funny thing I just realised is that I have basically written down a tutorial that can be found here http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html from my head. I guess I learned my lesson. They have some more detail there, if you are interested. I hope this guide is applicable to the GUI aswell. I am sure this does all sound kind of complicated at first, because there are more commands necessary than in svn. The reason for that is that git is more flexible, i.e. allows you to share only part of your repo and use your local repository even while you are offline. This make git usually the better tool, and I hope after mastering the entry difficulties you will learn to appreciate it.