* Re: Really beginner on Version Control
2010-09-21 14:42 Really beginner on Version Control FernandoBasso
@ 2010-09-21 14:59 ` Thomas Moulard
2010-09-21 14:59 ` Enrico Weigelt
` (3 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: Thomas Moulard @ 2010-09-21 14:59 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Really beginner on Version Control
2010-09-21 14:42 Really beginner on Version Control FernandoBasso
2010-09-21 14:59 ` Thomas Moulard
@ 2010-09-21 14:59 ` Enrico Weigelt
2010-09-24 19:33 ` Eric Raible
2010-09-21 16:40 ` Andreas Ericsson
` (2 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Enrico Weigelt @ 2010-09-21 14:59 UTC (permalink / raw)
To: git
* 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
----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Really beginner on Version Control
2010-09-21 14:42 Really beginner on Version Control FernandoBasso
2010-09-21 14:59 ` Thomas Moulard
2010-09-21 14:59 ` Enrico Weigelt
@ 2010-09-21 16:40 ` Andreas Ericsson
2010-09-21 23:35 ` Jakub Narebski
2010-09-22 22:10 ` Dmitry Potapov
4 siblings, 0 replies; 17+ messages in thread
From: Andreas Ericsson @ 2010-09-21 16:40 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-21 14:42 Really beginner on Version Control FernandoBasso
` (2 preceding siblings ...)
2010-09-21 16:40 ` Andreas Ericsson
@ 2010-09-21 23:35 ` Jakub Narebski
2010-09-22 0:13 ` FernandoBasso
2010-09-22 22:10 ` Dmitry Potapov
4 siblings, 1 reply; 17+ messages in thread
From: Jakub Narebski @ 2010-09-21 23:35 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Really beginner on Version Control
2010-09-21 23:35 ` Jakub Narebski
@ 2010-09-22 0:13 ` FernandoBasso
2010-09-22 3:52 ` Andrew Keller
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: FernandoBasso @ 2010-09-22 0:13 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: Really beginner on Version Control
2010-09-22 0:13 ` FernandoBasso
@ 2010-09-22 3:52 ` Andrew Keller
2010-09-22 11:45 ` FernandoBasso
2010-09-22 7:31 ` Thomas Hochstein
2010-09-22 22:13 ` Dmitry Potapov
2 siblings, 1 reply; 17+ messages in thread
From: Andrew Keller @ 2010-09-22 3:52 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-22 3:52 ` Andrew Keller
@ 2010-09-22 11:45 ` FernandoBasso
2010-09-22 11:49 ` FernandoBasso
2010-09-22 22:15 ` Dmitry Potapov
0 siblings, 2 replies; 17+ messages in thread
From: FernandoBasso @ 2010-09-22 11:45 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-22 11:45 ` FernandoBasso
@ 2010-09-22 11:49 ` FernandoBasso
2010-09-22 12:50 ` Tor Arntsen
2010-09-22 22:15 ` Dmitry Potapov
1 sibling, 1 reply; 17+ messages in thread
From: FernandoBasso @ 2010-09-22 11:49 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-22 11:49 ` FernandoBasso
@ 2010-09-22 12:50 ` Tor Arntsen
0 siblings, 0 replies; 17+ messages in thread
From: Tor Arntsen @ 2010-09-22 12:50 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-22 11:45 ` FernandoBasso
2010-09-22 11:49 ` FernandoBasso
@ 2010-09-22 22:15 ` Dmitry Potapov
1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Potapov @ 2010-09-22 22:15 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-22 0:13 ` FernandoBasso
2010-09-22 3:52 ` Andrew Keller
@ 2010-09-22 7:31 ` Thomas Hochstein
2010-09-22 22:13 ` Dmitry Potapov
2 siblings, 0 replies; 17+ messages in thread
From: Thomas Hochstein @ 2010-09-22 7:31 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-22 0:13 ` FernandoBasso
2010-09-22 3:52 ` Andrew Keller
2010-09-22 7:31 ` Thomas Hochstein
@ 2010-09-22 22:13 ` Dmitry Potapov
2 siblings, 0 replies; 17+ messages in thread
From: Dmitry Potapov @ 2010-09-22 22:13 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Really beginner on Version Control
2010-09-21 14:42 Really beginner on Version Control FernandoBasso
` (3 preceding siblings ...)
2010-09-21 23:35 ` Jakub Narebski
@ 2010-09-22 22:10 ` Dmitry Potapov
4 siblings, 0 replies; 17+ messages in thread
From: Dmitry Potapov @ 2010-09-22 22:10 UTC (permalink / raw)
To: FernandoBasso; +Cc: git
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
^ permalink raw reply [flat|nested] 17+ messages in thread