Git Survival Guide

I think the git UI is pretty awful, and encourages using Git in ways that +will screw you. Here are a few things I've picked up that have saved my bacon.

You will inevitably need to understand Git's “internals” to make use of it + as an SCM tool. Accept this early. If you think your SCM tool should not + expose you to so much plumbing, don't + use Git.
- Git weenies will claim that this plumbing is what gives Git all of its + extra power. This is true; it gives Git the power to get you out of + situations you wouldn't be in without Git.
+
git log --graph --decorate --oneline --color --all
Run git fetch habitually. Stale remote-tracking branches lead to sadness.
git push and git pull are not symmetric. git push's + opposite operation is git fetch. (git pull is equivalent to git fetch + followed by git merge, more or less).
Git configuration values don't always have the best defaults.
The upstream branch of foo is foo@{u}. The upstream branch of your + checked-out branch is HEAD@{u} or @{u}. This is documented in git help + revisions.
You probably don't want to use a merge operation (such as git pull) to + integrate upstream changes into topic branches. The resulting history can be + very confusing to follow, especially if you integrate upstream changes + frequently.
- You can leave topic branches “real” relatively safely. You can do + a test merge to see if they still work cleanly post-integration without + actually integrating upstream into the branch permanently.
- You can use git rebase or git pull --rebase to transplant your + branch to a new, more recent starting point that includes the changes + you want to integrate. This makes the upstream changes a permanent part + of your branch, just like git merge or git pull would, but generates + an easier-to-follow history. Conflict resolution will happen as normal.
+
+
Example test merge, using origin/master as the upstream branch and foo + as the candidate for integration:
+
```
git fetch origin
+git checkout origin/master -b test-merge-foo
+git merge foo
+# run tests, examine files
+git diff origin/master..HEAD
+
```
+
To discard the test merge, delete the branch after checking out some other +branch:
+
```
git checkout foo
+git branch -D test-merge-foo
+
```
+
You can combine this with git rerere to save time resolving conflicts in +a later “real,” permanent merge.
+
+
You can use git checkout -p to build new, tidy commits out of a branch + laden with “wip” commits:
+
```
git fetch
+git checkout $(git merge-base origin/master foo) -b foo-cleaner-history
+git checkout -p foo -- paths/to/files
+# pick out changes from the presented patch that form a coherent commit
+# repeat 'git checkout -p foo --' steps for related files to build up
+# the new commit
+git commit
+# repeat 'git checkout -p foo --' and 'git commit' steps until no diffs remain
+
```
+
- Gotcha: git checkout -p will do nothing for files that are being + created. Use git checkout, instead, and edit the file if necessary. + Thanks, Git.
- Gotcha: The new, clean branch must diverge from its upstream branch + (origin/master, in the example above) at exactly the same point, or + the diffs presented by git checkout -p foo will include chunks that + revert changes on the upstream branch since the “dirty” branch was + created. The easiest way to find this point is with git merge-base.
+

Useful Resources

That is, resoures that can help you solve problems or understand things, not +resources that reiterate the man pages for you.

Sitaram Chamarty's git concepts + simplified
Tv's Git for Computer + Scientists

+ + + +

+ + +comments powered by Disqus +

+ + + + + +