The McGyver GIT Survival Guide
Working with version control system is one of the elementary skills for each and every software engineer. Over the years, I worked with CVS, Subversion, SourceSafe, Perforce as well as Mercurial. Within Microsoft, I worked a lot with Source Deport and Microsoft Team Foundation Server. At home I run my dedicated SVN repository. In fact, I don’t feel comfortable when not being able to check in source code at all.
For my personal projects, Git especially Github works quite well, however, since the openHAB project moved from Google Code (Mercurial) to GitHub, I deal with quite a lot of issues within Git over and over. Currently we have more than 50 60 forks and more than frequent pull requests. Therefore, keeping your local branch permanently in sync is quite inevitable.
Abstraction None
The worst thing about Git is the fact, the user interface and console commands seem to reflect the Git implementation bit by bit. Personally, I have the feeling there is zero abstraction for the user. Even worse, when used to non distributed systems like SVN or TFS doing simple syncs and commits, the concepts behind Git might drive one mad.
Small Steps
This seems obvious, however, try to make only small commits to the repository. The more collaborators you have, the more challenging it might become to merge. At the same time, the less experienced you are with Git, the smaller your checkins should be. Commit single files, minor changes as isolated as possible. This will make you life just so much easier.
Daily Routine Conflicts
As daily routine, fetching and merging the local branch should be done via
git fetch upstream git merge upstream/master
Usually, this should work quite well unless there are changes on local files that should not be merged at all or you have done changes not to be merged yet.
Updating e21a751..349468b
error: Your local changes to the following files would be overwritten by merge:
foo/bar/buzz.ext
Please, commit your changes or stash them before you can merge.
Aborting
To just avoid the merge stash the changes via
git stash
Do the merge, and than pull the stash.
git stash pop
Again, usually this should work fine unless the merge results in a conflict which cannot be resolved automatically.
Auto-merging foo/bar/buzz.ext CONFLICT (content): Merge conflict in foo/bar/buzz.ext
Simply run
git mergetool
to solve the issues and try to pull the stash again.
Delete from Repository only
To remove a file from the repository whilst keeping it locally just performa a
git rm --cached myfile.c
Bear in kind, this git will realise this file immediately as a new. rm works on folders as well, though. Anyway, this will become very handy once you accidentally check in files that are not intended to be checked in.
Backup early – Backup often
Just in case you don’t know what’s going to happen e.g. due to a larger refactoring – move the current state into a new brach as backup right after a commit
git branch my-backup-work
Reset to Remote
Ok, this one gave me quite a hard time, as I had changes checked in my forks but needed to reset particular files to the current revision of the original repository (not your local branch and neither your fork).
To do so, reset your working copy to the upstream master:
git remote update git reset --hard upstream/master
Afterwards push this new branch-head to your origin repository, ignoring the fact that it won’t be a fast-forward:
git push origin +master
you might have something like
Fetching origin Fetching upstream remote: Counting objects: 685, done. remote: Compressing objects: 100% (336/336), done. remote: Total 507 (delta 249), reused 321 (delta 87) Receiving objects: 100% (507/507), 6.57 MiB | 146.00 KiB/s, done. Resolving deltas: 100% (249/249), completed with 64 local objects. From https://github.com/aheil/example f55f8b0..e060456 master -> upstream/master macbook-pro:example andreas$
Reverting to a specific Revision
This one is easy, you simply need to tell git the hash of the revision you want to check out. This works quite well, however, you always need to consider the visibility of the branch you want to check out. To understand the reachability in git, you might want to read this article.
git checkout e095 -- somefolder/somefile
Conclusion
In my very personal opinion, Git is s**t if you are used to centralised repositories. If you worked a lot with Mercurial, Git is simply to complex. Git is not abstract enough. When working on code, I want spend 99% on the code and 1% on the revisioning system, not the other way around. When working on the open source projects, I currently waste a major part of my time on Git.
I probably will never setup and run a personal git server (I do run a SVN server and did run CVS before) and I probably will not maintain any Git servers (I did at work maintain Microsoft TFS, SVN and CVS servers, though).
Git is great when it comes to some kind of mass collaboration (but I haven’t found anything so far Mercurial won’t offer for the same purpose). While everybody plays nicely together, it works just great.
As there is much more to learn about Git, you eventually want to pick Pro Git
For quite a while my SpamAssassin installation for Windows won’t update anymore. It simply quit with some exit code 4. Unfortunately, SpamAssassin is running on this server for quite some time and often one simply forgets about systems that are up and running until they fail. Having a closer look at the error message it appeared that sa-update had some problems with some of the preconfigured channels.
I continually move between different office places using different setups for monitors with my laptop. Sizes, numbers and orders of the monitors vary from place to place. As a consequence, you either deal with a complete mess on your desktop or you spend several hours per week in rearranging icons on your desktop. 
