Change root of a branch in git

Question

I\'m using git and want to change the base of an exiting branch. This is caused by a deployment system, which pulls this explicit branch into my production environment. When pla

Answer 1

git rebase should work for you:

git checkout deploy
git rebase master~1

or

git rebase v1.1

Have a look at http://progit.org/book/ch3-6.html - should help you understand rebase better I think

Answer 2

I don't understand why you'd want to lose your original branch. What I would do in such a case:

 # create a new branch from your 1.1 tag
 git checkout -b deploy1.1 v1.1 
 # merge your existing branch into this one
 git merge deploy

EDIT: added schema

You'll end up with something like that

       C---D---E deploy
       /        \_______ 
      /                  F deploy1.1
     /                  /
A---B---F---G--H--I--J--K--L
     \                   \
    v1.0                 V1.1

Answer 3

git rebase should, like you say, allow you to change the base of deploy:

git checkout deploy
git rebase v1.1 # using the tag
(or:
 git rebase J # SHA1 of J
 or
 git rebase master~1
)

But you will end up with

C'---D'---E' deploy

That is, the SHA1 of the commits part of deploy branch are rewritten, which isn't too bad if nobody cloned said deploy branch and was working on it.
Since it is a branch for deployment, that is most likely the case (i.e. nobody was working on a clone of said branch).

Answer 4

yes, you can use rebase to achieve the desired effect. the following command will checkout the deploy branch and replay all its commits, which are not reachable through v1.1, on top of v1.1:

git rebase v1.1 deploy

(the verbose way would be: git rebase --onto v1.1 v1.0 deploy)

but why rebasing and altering history? you can simply change the mainline of development into your deployment-branch:

git checkout deploy
git merge v1.1

this will leave all your commit hashes intact, your history will then look like this (M being the merge commit):

      C---D---E-----------M deploy
     /                   /
A---B---F---G---H---I---J---K master
     \                   \
      v1.0                v1.1

since conflicts might arise during rebase as well as during merge, you will have a history of merge conflicts when using the merge based approach. with rebase you don't have a history of conflicts which happened during rebase operation. using a merge based workflow, you can later see your conflicts in the (combined) diff of the merge commits.