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:

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?


  • How can I “splice” two (or more) completely unrelated linear branch ancestries into a new one?
  • Git - Bare repo cannot have a worktree for master branch - WHY?
  • Git - how to merge additional branch changes after branch has been 'merge --squash'ed
  • Find files that were conflicting or locally edited during git merge commit
  • Git merge and resolve any conflicts to current branch
  • vimdiff is not launching when I try to resolve a git merge conflict
  • How to re-base a forked repo when doing a merge request - Gitlab
  • Merge conflict resolution over new code
  • 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)

    Git Baby is a git and github fan, let's start git clone.