git: merging feature branches into earlier part of master line
I’m sure this has been asked before but I’m not even really sure what the terms I am looking for are.
I have a branch structure that looks like this:
- Git: What's would be the correct way of merging (or rebasing) code based on an old commit/tag that was not being tracked by git?
- Git Submodule Merge
- What happens to a branch once I merge it?
- How to pick a commit in sub-branch and merge it into main branch?
- Inject a merge commit with Git
- understanding commit and merge
startoftime -> A -> B -> C -> D (master head) | -> X -> Y (feature1 head)(tag T) | -> Q -> R (feature2 head)
Essentially I created two feature branches from commit B and did development in them. The head of one of them has a tag on it that reflects its overall history from the original root. Now I want to fold them back into master, but ideally I’d like them to appear in the history before the new stuff on master, not after, so leaving the current master head where it is. Ideally I’d like this:
startoftime -> A -> B -> X -> Y -> Q -> R -> C -> D (master head) | (tag T)
What are the concepts or commands I should be looking at here?
There is a suggestion that
rebase might be what I’m after here. All three of these branches have been pushed to my remote already, although I can guarantee that no one but me has pulled from it/checked it out. Can I still use rebase?
2 Solutions collect form web for “git: merging feature branches into earlier part of master line”
Rebases aren’t an issue as long as no one else has used your branches. Doesn’t matter if it’s “remote” or not. You’ll just have to use
--force the next time you do a push.
That being said, I’d like to encourage you to reconsider just using a merge. Your history will still show the timeline of when the features were developed, but it will also more accurately reflect the history of you working in parallel, as well as when you integrated it into your master branch. If you do a rebase, your current
Q will be different than
Q was when you were originally working on it, possibly to the point where it doesn’t work like you expect if you ever have to go back to it. Also, it makes it easier to remove feature1 or feature2, should it be required for some reason.
Just to be complete (and I agree with karl Bielefeldt’s answer), a solution using rebase would be:
git checkout feature2 git rebase feature1 git checkout master git rebase --onto feature2 B D
(See here for an example of
git rebase --onto)