Git wiki page

[Geert Janssens]

On Friday 17 May 2013 20:23:36 Geert Janssens wrote:
> I know from experience that this last part takes some time to fully grasp
> when coming from  svn. So I'll just add a simplified, explicit example on
> git branches for others still deeply in the svn mindset (best viewed with a
> fixed-width font):
> 
> Suppose you have this tree of commits in your local repository
> 
> A - B    (trunk)
>   \
>     C    (feature-x)
> 
> A is the parent commit, B is a descendant of this commit on the trunk
> branch. C is a  descendant of A on the feature-x branch. It's already worth
> pointing out here what branch means in git. The trunk 'branch' is some kind
> of label that is currently attached to commit B. The feature-x 'branch' is
> equally some kind of label attached to commit C
> 
> When you merge feature-x into trunk in git, you will get this tree:
> 
> A - B - D (trunk)
>   \   /
>     C     (feature-x)
> 
> The 'trunk branch' is now a label attached to commit D. All the ancestors of
> commit D are  considered part of the trunk branch. But note already how the
> branch itself is just a label moving from commit to commit as changes are
> committed.
> 
> Now this all happened in your local git repository. The upstream git
> repository doesn't know  about any of this yet. At some point you want to
> push your work upstream. Let's assume for simplicity that commit A and B
> were already in the upstream repo as well. This means the upstream repo
> looks like this:
> 
> A - B    (trunk)
> 
> 'trunk' is a public branch. Let's push our local trunk changes upstream.
> After a successful  push, upstream will look like this:
> 
> A - B - D (trunk)
>   \   /
>     C
> 
> You might say that's exactly like the local repo, but there's one slight,
> yet important  difference: the *branch* feature-x wasn't pushed upstream
> (note that I didn't put that name next to the C commit).
> 
> The *commits* that were on that branch and are ancestors of commit D are
> (commit C in our  example). These are required to regenerate commit D, so
> they are pushed upstream as well. But as John notes, the *branch* itself is
> just a name tied to a commit. This name can move to another commit or even
> be removed without affecting the commits themselves in any way. So unless
> you explicitly push that branch (name) to the upstream repository it won't
> appear in there. That's what John means with "we can keep the branch list
> manageable".
> 
> Hopefully this will help some to understand git branches better and why they
> are totally  different from svn branches (where each branch is a commit in
> itself, not a floating label to attach to some commit).

For the record, I have put this explanation an a separate page in our wiki (1), so others can 
still reference it later. Feel free to improve if you like.

Geert

(1) http://wiki.gnucash.org/wiki/Git_vs_Svn