1

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?

Thanks.

Ben Zotto
  • 70,108
  • 23
  • 141
  • 204

2 Answers2

3

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.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • Thanks Karl. This makes sense. I've edited the above to note the presence of a tag on Y that I'd like to be able to get back to if I need to. I suppose this would still exist if that branch that contains Y continues to live on. So am I merging into master's HEAD? Or can I merge into the middle of its history earlier than the previous commits? – Ben Zotto May 10 '11 at 21:46
  • @quixoto, yeah you would normally merge into master's HEAD. Your changes will still show earlier in the log, but you'll have merge commits that show when you did the integration. – Karl Bielefeldt May 10 '11 at 22:28
  • Karl, thanks. I've taken your advice. Can I safely get rid of the development branches if I want to, preserving the commit history that I now see on master? Or do the merged commits "rely" on the commits that are still on the branch? Thanks. – Ben Zotto May 10 '11 at 23:46
  • @quixoto, you can safely delete branches that have been merged in. If you use a small d in `git branch -d feature1` it will refuse to work unless it is safely merged in. When you delete the branch it just deletes the pointer to its last commit. The commits themselves remain. – Karl Bielefeldt May 11 '11 at 00:11
0

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)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250