Really beginner on Version Control

Really beginner on Version Control

[FernandoBasso]

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 ?


-- 
View this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5555023.html
Sent from the git mailing list archive at Nabble.com.

Re: Really beginner on Version Control

[Thomas Moulard]

Hi!

On Tue, Sep 21, 2010 at 4:42 PM, FernandoBasso
<FernandoBasso.br@gmail.com> wrote:
>
> 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 ?

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.

>
> 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
> ?

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.

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

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,
-- 
Thomas Moulard

Re: Really beginner on Version Control

[Enrico Weigelt]

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

Hi,

> Why do we merge, say a testing branch into the master branch ? 
> What is the use of it ?

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.

> 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 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).

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

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


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Really beginner on Version Control

[Andreas Ericsson]

On 09/21/2010 04:42 PM, FernandoBasso wrote:
> 
> 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 ?
> 

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.

> 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 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.

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

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Really beginner on Version Control

[Jakub Narebski]

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

Re: Really beginner on Version Control

[FernandoBasso]

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).

-- 
View this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5557145.html
Sent from the git mailing list archive at Nabble.com.

Re: Really beginner on Version Control

[Andrew Keller]

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

> 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).

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

Re: Really beginner on Version Control

[Thomas Hochstein]

FernandoBasso schrieb:

> 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 ? 

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.

Re: Really beginner on Version Control

[FernandoBasso]

 On 09/22/2010 12:52 AM, Andrew Keller wrote:
> The only thing is, in your example, since master did not progress since
> testing diverged, 
> git simply thinks of it as being "behind" testing...



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.

-- 
View this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5558696.html
Sent from the git mailing list archive at Nabble.com.

Re: Really beginner on Version Control

[FernandoBasso]

On 09/22/2010 04:35 AM, Thomas Hochstein [via git] wrote:
>
> 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.
>

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 ?

-- 
View this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5558706.html
Sent from the git mailing list archive at Nabble.com.

Re: Really beginner on Version Control

[Tor Arntsen]

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

> 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 ?

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

Re: Really beginner on Version Control

[Dmitry Potapov]

On Tue, Sep 21, 2010 at 6:42 PM, FernandoBasso
<FernandoBasso.br@gmail.com> wrote:
>
> Why do we merge, say a testing branch into the master branch ? What is the
> use of it ?

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.

> 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 to resolve conflicts, after
you commit the result to your current branch.

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

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

Re: Really beginner on Version Control

[Dmitry Potapov]

On Wed, Sep 22, 2010 at 4:13 AM, FernandoBasso
<FernandoBasso.br@gmail.com> wrote:
>
> 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).

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

Re: Really beginner on Version Control

[Dmitry Potapov]

On Wed, Sep 22, 2010 at 3:45 PM, FernandoBasso
<FernandoBasso.br@gmail.com> wrote:
>
>  On 09/22/2010 12:52 AM, Andrew Keller wrote:
>> The only thing is, in your example, since master did not progress since
>> testing diverged,
>> git simply thinks of it as being "behind" testing...
>
>
> 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 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

Re: Re: Really beginner on Version Control

[Eric Raible]

On 11:59 AM, Enrico Weigelt wrote:
> * FernandoBasso <FernandoBasso.br@gmail.com> wrote:
> (use the -ff option on merge if it should show up in history
> as merge instead of sequential additions - see "fast forward").

Didn't you mean --no-ff?

Re: Re: Really beginner on Version Control

[Enrico Weigelt]

* Eric Raible <raible@nextest.com> wrote:
> On 11:59 AM, Enrico Weigelt wrote:
> > * FernandoBasso <FernandoBasso.br@gmail.com> wrote:
> > (use the -ff option on merge if it should show up in history
> > as merge instead of sequential additions - see "fast forward").
> 
> Didn't you mean --no-ff?

Yes, of course ;-o


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Re: Really beginner on Version Control

[FernandoBasso]

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. 


-- 
View this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5568448.html
Sent from the git mailing list archive at Nabble.com.