Suppose my Git repository initially has two branches: Foo and Bar.
... ─ Foo ... ─ Bar
I create a third branch, FooBar in which I commit the merge of the two other branches.
... ─ Foo ──┐ FooBar ... ─ Bar ──┘
FooBar is now one commit ahead of both Foo and Bar. Next, I do some more work, committing a few times on Foo only.
... ── A ───┬── B ── C ── D ── Foo FooBar ... ─ Bar ──┘
The question is: since the first parent of branch FooBar is no longer Foo, can I rebase the merge commit in branch FooBar to again have Foo and Bar as its two parents? In other words, can I incorporate the development in Foo into the previously merged FooBar along with the unchanged Bar?
... ── A ── B ── C ── D ── Foo ──┐ FooBar ... ─ Bar ───────────────────────┘
If you want to see the history completely same as it happened, you should use merge. Merge preserves history whereas rebase rewrites it . Rebasing is better to streamline a complex history, you are able to change the commit history by interactive rebase.
Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow.
We use Git Rebase when the logs of the repository will not be referred by anyone else. To summarise, we can use Git Rebase, when we are working on branches, which cannot be seen by other developers. And we use Git Merge when the target and source branch can be viewed by other developers.
I realize this is quite an old topic but since I found this question while facing a similar situation I could as well tell what I used in the end.
git checkout FooBar
git rebase -p --onto Foo A
I tried to use the names from the original question. Note especially that A
means the commit that is marked as A in the ascii art. You would probably use the hash of the commit instead or any other way to point to the commit where branches Foo
and FooBar
originally separate.
The -p
flag is also known as --preserve-merges
and it does pretty much what it says.
Note that the branch Bar
doesn't play a role here so that line of commits might be a named branch or then not - it makes no difference.
You couldn't rebase under branch FooBar
without changing what defines FooBar
. What you could do is merge FooBar
and Foo
. That would have the same contents that you desire.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With