Really beginner on Version Control

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 ?

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 ?

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

Hi!

On Tue, Sep 21, 2010 at 4:42 PM, FernandoBasso <FernandoBasso.br@gmail.com> wrote:

Ususally, one develops a feature on a separate branch to avoid polluting the "master" branch with non working or fragile commits and prevent other people from working.

You always merge a branch into the branch you *are* in. For instance: # Switch to master branch. $ git checkout master

# List the available branches.
$ git branch
* master
  my-new-feature

# Merge the topic branch into master. $ git merge my-new-feature

Here what I call a topic branch is what you call a "testing" branch.

If there is a conflict, in theory it means that *both* sides have change a same location in a tracked file. Usually, it means that you have to take *both* contents and depending on the context write manually the result.

For instance, one can fork master to create a topic branch, then changes are made in the topic branch and in master. When you merge back your topic branch you want to integrate your changes but also preserving the changes that have been made to master between the time the topic branch has been created and now.

In general, yes. Please note that git can work around whitespace problems (whitespace versus tab and \n versus \r\n).

You may also want to google "git workflow" to get a rough idea about how to manage a project with git and how to do more advanced stuff with topic branches.

I hope it helps,

* FernandoBasso <FernandoBasso.br@gmail.com> wrote:

Hi,

That heavily depends on your workflows.

I'm a big friend of topic-branches, which means that I'm alsways working on one topic (eg. fixing one particular bug or developing some feature) in it's own branch. When it's decided that the code is ready to go mainline, it will be merged into there (normally the "master" branch).

And I really advise rebasing the topic branch onto the mainline, which means, the changes that happened in the topic branch after the forkoff, will be applied step by step ontop the mainline, so coming after those happend meanwhile in the mainline. (use the -ff option on merge if it should show up in history as merge instead of sequential additions - see "fast forward"). This can reduce the chance of conflicts dramatically and make them easier to resolve.

You can resolve the conflict within the merge (git will tell you the conflicts and leave conflict markers in the source code - see "resolving conflicts").

As said above, I always rebase the to-be-merged branch ontop the destination and resolve conflicts there. After this there can be no conficts as the rebased branch is now an direct descendant of the merge target (so, fast-forward possible).

Obviously not - in this case you wouldn't even need a merge.

cu

On 11:59 AM, Enrico Weigelt wrote:

Didn't you mean --no-ff?

* Eric Raible <raible@nextest.com> wrote:

Yes, of course ;-o

cu

Wow! You guys really have the will to help. I know small talk is to be avoided, but I wanted to let you know that I'm still following this thread with great interest. You really helped me lot. I'm reading all the posts everyday trying to internalize the concepts.

Thank all you for your help. 

On 09/21/2010 04:42 PM, FernandoBasso wrote:

Because the sum of the whole is greater than the parts. Most features in git for example are developed on topic branches. This makes it possible to keep unfinished code separate from the production branch that people actually use.

You should edit the working tree, since that's where the conflict will be staged. When you're done, commit the results and that will be a new commit on the branch you're on.

Both branches should most definitely not have exactly the same code. If they did, there would be no point in merging them. The merge-result shouldn't have the same code as any of the branches either, unless you actually want to throw one branch away, in which case you'd be far better off doing just that.

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

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.
 

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.

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

I really appreciate your help. All of you. This is all starting to make sense to me thanks to you guys.

Now, what are the possible ways that we can get to a conflict when merging branches ? I'm doing some study tests, and some times I get conflicts, some times I don't. I couldn't really understand what causes them or not yet.

For instance, I have 'hello' in line 2 of site.php in the master branch. I go to the testing branch, edit site.php, change 'hello' for 'world' at the same line, commit and got back to master. I merge testing into master and I get no conflicts. Shouldn't it conflict ? (site.php in master also contains the string 'world' in the place of 'hello' now).

On Sep 21, 2010, at 8:13 PM, FernandoBasso wrote:

If I am understanding correctly, then this is an example of a fast-forward merge.

It sometimes helps to think of a series of commits as a series of changes, rather than a series of snapshots.  A merge conflict will occur when you *modify* overlapping sections of the same file in each branch.  The key word here is modify.  When you ask git to merge testing into master, you are not asking git to look at the code and figure out which one is "correct".  Instead, you are asking git to take the changes in testing, and the changes in master, each since they diverged, and create a new commit that incorporates both changes.

The only thing is, in your example, since master did not progress since testing diverged, git simply thinks of it as being "behind" testing, so you end up with a fast-forward merge, where master simply acquires the newer commits that testing has.  You can think of it as a special case optimization.  No need to make a merge commit if master is just behind and needs to be caught up.

If you would like to cause a merge conflict, then you should modify the same line of the same file in two different branches, and then try to merge the branches.  This is similar to what you just did, except that both master and testing must progress individually before you merge.

~ Andrew Keller

 On 09/22/2010 12:52 AM, Andrew Keller wrote:

You have used the word 'behind'. I think 'time' what is making me fail to understand git merging. It depends on which branch I have changed last. Not only if I changed the same line in both branches. If I change (same line) the master, commit. Change testing commit. Merge testing into master, they will not conflict because master haven't changed since testing changed. Master is "behind" testing.

On 09/22/2010 04:35 AM, Thomas Hochstein [via git] wrote:

Okay. So, If I have not changed master since I last edited testing, I can merge testing into master without problem.

I merge testing into master (without problems) and I change master and merge testing into master again (without any further modification). Now, git thinks that the changes I've just made in master are more important than the old changes in testing ?

On Wed, Sep 22, 2010 at 13:49, FernandoBasso <FernandoBasso.br@gmail.com> wrote:

Those old changes were already merged, so they won't get merged again. Git keeps track of which commits have been merged. If master originally consists of commits A, B, C, then you branch and make 'testing', then testing will start out with A, B, C. Then you add D to testing. Now master is A, B, C as before, testing is A, B, C, D. Then you merge. Now master will be A, B, C, D too. Then you add E to master: A, B, C, D, E. If you try to merge testing to master again Git sees that testing contains nothing that's not in master already.

(The letters stand for commits, i.e. changes you commited.)

-Tor

On Wed, Sep 22, 2010 at 3:45 PM, FernandoBasso <FernandoBasso.br@gmail.com> wrote:

Not really. Time is irrelevant, what matters is the common ancestor. Please, run gitk and take a look at the history graph. I think it will make some things obvious. They say one picture is worth a thousand words...

Dmitry

FernandoBasso schrieb:

No.

You have changed "hello" to world in your testing branch. When you merge your testing branch back to your master branch, git will apply all changes you made in testing to master. That's not a problem in that case, as master was not changed since testing was branched from it.

Another example:

You create a testing branch from master. Now you'll go to your testing branch, change "hello" to "world", commit, go back to your master branch and change "hello" to "all" there (and commit). Now you'll get a conflict when trying to merge your testing branch - git will try to apply the change from testing (i.e. change "hello" to "world"), but can't to that as "hello" was already changed to "all" in your master branch. git doesn't know which of this conflicting [1] changes is the right one you'll want to keep, so you have to tell it.

Merging a branch into master will make git try to apply all changes that you made in this branch to the master branch. That's easy if master didn't change since you created your testing branch from it. It's also easy if master _did_ change, but never at the same places as in testing. You'll only get a conflict if you change the same line(s) in master _and_ in testing.

Regards, -thh

[1] That's why it's called a conflict.

On Wed, Sep 22, 2010 at 4:13 AM, FernandoBasso <FernandoBasso.br@gmail.com> wrote:

Conflicts happen only if two branches have contradictory _changes_ to the same line. If you merge some branch, it means you accept all changes from it. So, if one branch has no changes, and the other branch has some changes then all changes from the other branch will be accepted without any conflict. The special case when there is no changes on your current branch but only on the merged branch is often described as fast-forward merge, because the result merge does not produce any new commit, but only advance the current state to the state of the other branch.

Dmitry

On Tue, Sep 21, 2010 at 6:42 PM, FernandoBasso <FernandoBasso.br@gmail.com> wrote:

We usually don't do that, because it goes against recommended git workflows http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

With Git, you typically merge your stable branch to to your main development branch or you merge some feature branch to master if you consider it to be mature enough to be included in the next release.

You edit files in your working directory to resolve conflicts, after you commit the result to your current branch.

No... There are different merging strategies, and Git is flexible enough to allow you to specify your own merging strategy for some files. The default merging strategy relies on the context to find if there is any conflict. It means that the same file has been edited around the same place (around the same line), then it will generate a conflict.

There is one important thing to keep in mind when it comes to merges. Merge conflict are your friends and not your enemies. In other words, they warn you about changes to some files that can contradict each other, so you need to use your brain to resolve them gracefully. Usually, they do pretty good job at that, but in some rare cases, merge without any merge conflict can produce unworkable code. So, after any non-trivial merge, you should do testing. If testing reveals some problem then you should correct them. Git allows you amend any last commit (including the merge commit) using:

git commit --amend

If two branches are diverged a long time ago, it is very useful to look at history of those branches to find what changes caused the conflict. You can do that using the following command:

gitk --merge

or if you are interested only in one particular file then:

gitk --merge this-file

Dmitry