On Tue, 17 Nov 2015 23:47:13 -0800 (PST)
mike <mikaelpetter...@hotmail.com> wrote:
> > > I have had a branch, feature_xyz, for a long time ( yes I know I
> > > should not but it was not my call). Problem is I have not updated
> > > it with changes from master. So I started to do a regular rebase
> > > ( i want to keep history):
> > >
> > > git fetch origin master
> > > git rebase origin/master
> > >
> > > After a while with conflicting patches (over 30...) I guess that
> > > there must be an easier way to do this,
> > >
> > > So anyone out there with an better idea I am open to new ideas.
> > > What do you suggest?
> > What prevents you from just merging master into it?
> Not absolutely sure but I guess it is for keeping history of changes
> when I merge back to master.
Merges in Git are different from those in some other tools, namely,
Subversion: when you merge in Git, the merge commit created contains
the merged state of both lines of history which were merged *and*
references both tip commits which were merged together.
This means, that if you have:
Then fork a branch "feature", and both branches receive a number of
commits so that they look like this:
Then when you merge "master" to "feature", you'll get a
So your "D..F" line on "master" and "O..Q" line on "feature" are both
When you proceed developing on both branches again, you'll get:
With M being the last "merge base" between "master" and "feature".
That is, no history on any branch is "lost".
> > Rebasing is only actually needed if you want to keep your work "on
> > top" of the branch it was based on.
> What do you mean with the expression "on top"?
That's quite a literal meaning.
I've tried to explain how rebase works to someone here  (with
pictures borrowed from the "Pro Git" book) -- feel free to read it.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.