On Tue, 17 Nov 2015 10:02:03 -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?
Rebasing is only actually needed if you want to keep your work "on top"
of the branch it was based on. The primary use case for keeping your
patch series on top of an "upstream" branch is the need to mail them
as a series of patches to upstream or have a clean run of history for
the upstream to have an easy-to-digest merge from your branch.
If that is not needed and you just want to have your feature branch
synchronized with the branch of its origin, just merge. And re-merge
later, when needed -- it's perfectly okay to do.
On the other hand, try analyzing what that feature branch is really for.
I mean, if merging becomes a pain, it might be a signal that the feature
branch have diverged too much from the branch of its origin and may be
an effort should be taken to bring it more in shape with the "master"
code base. This should make both rebasing and merging easier.
Yet another approach it considering the `git rerere` tool which
basically tries to remember how you have solved conflicts during a merge
and then allows to use this "canned solution" when again in the same
situation. I honestly did not try it but may be it will make your
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.