Getting Started with Git

This is really an absolute necessity and a **huge** productivity improvement. Basically you need the bash completion script from the source tarball and use your shell profile to include it whenever you open a shell. See the **Auto-Completion** section on this page:

41

[[Git Bash Auto-Completion>>http://progit.org/book/ch2-7.html]]

42

43

=== GitX git GUI ===

44

45

GitX is an awesome FREE history viewer made for OS X. It is a better way to visualize your branch and commit history of your git repository. However, power users (aka "cool kids") will probably only use it for history viewing while they continue to use the terminal command line for checkouts, branching, staging, rebasing and committing.

46

[[GitX Home Page>>http://gitx.frim.nl/]]

=== Open in GitX ===

[[Open In GitX Finder Droplet>>http://code.google.com/p/git-osx-installer/wiki/OpenInGitX]]

== Git Tower ==

For those of you who just get panic attacks at the thought of using the Terminal, there is a commercial app for that:

55

[[Git Tower>>http://www.git-tower.com/]]

56

57

I use Tower (bought it), but only for committing and fixing merge conflicts. I think Tower misses quite a bit of the flagship feature of GIT: branches. You can't see a branch tree graphically, like you can with gitX or even the command line (git log -graph -color, IIRC). But it's cool for committing. For everything else I use command line.

58

Miguel Arroz

59

60

== Using git locally on a Subversion Working Copy ==

61

62

OK, so you are addicted to git, and now you have to work on a team project that is hosted in a remote subversion repository ... and it is making you depressed :-( . Well, you can use manage your local svn working copy using git and be happy again

63

64

I recommend you just use the [[git+svn protocol>>http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx]].

== Git Concepts ==

=== Rebasing ===

Rebasing is unique to git. There is no counterpart in Subversion.

71

72

Rebasing cuts down on the spaghetti history of merging and helps to keep history nice and linear.

73

74

Conceptually, when I rebase my current branch A on another branch B, git removes all my branch A commits back to the common ancestor of A and B, stashes those commits away temporarily, moves the head of the current branch A to the tip of the other branch B, and then re-applys all my stashed commits as **new commit** patches to my branch B.

75

76

However before using it on work that is shared with others you MUST follow the these rules, otherwise you will screw everyone else on the project.

77

78

* If you don't understand rebasing, don't use it!

79

* Use rebase on **private** branches

80

* Use rebase for commits that have **not been pushed** to a remote repo

81

82