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: Merge two branches using netbeans
  • How to rename an SVN branch and update references in an existing sandbox?
  • Can I safely rebase one branch into other and then to master?
  • Safely delete a TFS branch project
  • Best practice for three environment setup - to avoid pushing things live when not ready yet
  • Is git-svn dcommit after merging in git dangerous?
  • 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?

    Thanks.

  • Add a folder from outside the repository to repo?
  • How do you organize your git repositories?
  • Heroku - Git push without building
  • Git Commit policy in TFS
  • How to have 2 git users on one computer?
  • Git vs. Subversion for multiple large development branches
  • 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.