git for versioning
mailtomanish.sharma at gmail.com
Thu Jul 31 13:19:32 CEST 2008
On Wed, Jul 30, 2008 at 7:26 PM, martin f krafft wrote:
> also sprach Manish [2008.07.30.1520 +0200]:
>> I am also new to git so just to confirm. Merge will leave us with one
>> less branch whereas a rebase will move our changes on top of the
>> changes of other branch. Right?
> No, you'll have two branches in both cases. The distinction is
> between linear (rebase), meaning that one branch builds off the tip
> of another, and recursive (merge), meaning that the branches run in
> parallel and later join up.
You are right. Branches live on till they are deleted intentionally.
> I really suggest to play around with this, the manpages, and gitk!
>> Also if a document is modified in master and also modified in
>> branch A, then when we rebase A on top of master what will be the
>> state of contents of A? Same as master or same as A or will
>> a merge be performed?
> A merge will be performed, or conflict resolution required. Just
> like if you merged them.
> Rebasing is essentially taking each commit and
> cherry-picking/applying it on top of the destination tip; if
> a commit cleanly applies, move on; if not, try merge; if that fails,
> ask the user to resolve the conflict.
Thank you. It helped.
More information about the vcs-home