Re: Really beginner on Version Control

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 21, 2010, 23:35 UTC
Message-ID: <m3mxrak937.fsf@localhost.localdomain>
In-Reply-To: <1285080133451-5555023.post@n2.nabble.com>

FernandoBasso <FernandoBasso.br@gmail.com> writes:

> I am really a beginner in. Bear with me please.
> 
> Why do we merge, say a testing branch into the master branch ? What
> is the use of it ?

Short answer: to make it visible. Usually only a specific set of branches is published.

Long answer: the real question is why we should use topic branches. The answer is to keep unfinished code separate and not visible untill it is finished and ready to be shown.

You create new [private] branch for developing a feature, 'testing' in
your example, develop code on it, and when code is ready you make it
visible by putting it on 'master' branch.  One of possibilities is to
merge 'testing' branch into 'master'.  Then people can use those
changes taking / fetching from a 'master' branch.

> When there is a conflict when merging branches (merging the testing
> into the current branch), should I edit the 'current' branch or the
> 'testing' branch ?

You edit files in your working directory. You are on current ('master') branch, and you are creating state of the new [merge] commit.

Edit files, add those files after resolving conflict, then run 'git commit' which would notice that you were in conflicted merge and do the right thing.

> 
> Should both branches have exactly the same code so that they can be
> merged without conflicts ?

No, if there is merge conflict you edit the files so they make sense, incorporating your changes made on 'testing' branch with the changes that were made on 'master' branch since branching point (merge base) of 'testing' and 'master'.

Branches would merge without conflict if:

1. You did the changes on 'testing', while 'master' didn't move at all.
   This is so called "fast-forward" case and wouldn't even create merge
   conflict without --no-ff option.

2. Changes on 'testing' and on 'master' (since merge base) touch
   different files.  This is so called "trivial" merge (tree level
   merge to be more exact).

3. Changes on 'testing' and on 'master' touch different areas of
   files, so that textual 3-way merge succeeds.

HTH

-- 
Jakub Narebski
Poland
ShadeHawk on #git