From: Enrico Weigelt <weigelt@metux.de>
To: git@vger.kernel.org
Subject: Re: Really beginner on Version Control
Date: Tue, 21 Sep 2010 16:59:22 +0200 [thread overview]
Message-ID: <20100921145922.GA14711@nibiru.local> (raw)
In-Reply-To: <1285080133451-5555023.post@n2.nabble.com>
* 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
----------------------------------------------------------------------
next prev parent reply other threads:[~2010-09-24 11:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2010-09-24 19:33 ` Eric Raible
2010-09-24 20:18 ` Enrico Weigelt
2010-09-24 21:25 ` FernandoBasso
2010-09-21 16:40 ` Andreas Ericsson
2010-09-21 23:35 ` Jakub Narebski
2010-09-22 0:13 ` FernandoBasso
2010-09-22 3:52 ` Andrew Keller
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
2010-09-22 7:31 ` Thomas Hochstein
2010-09-22 22:13 ` Dmitry Potapov
2010-09-22 22:10 ` Dmitry Potapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100921145922.GA14711@nibiru.local \
--to=weigelt@metux.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).