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 planning my releases, I create a tag every time I want to go live. But my branch has special changes too, so git reset --hard v1.0 won't work.

Here a small example. I want this

      C---D---E deploy
     /
A---B---F---G master
     \
      v1.0

to become this

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

Maybe git rebase is what I am looking for, but the man pages don't help me. Thanks for your replies!

Solution 1

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).

Solution 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

Solution 3

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.

Solution 4

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

View more solutions

Comments

[micha149]

I don't want to loose it, because there are some important changes. Like a completely added Zend Framework Library, config of a database connection and other settings, wich I need only on the production system.

[micha149]

But its not possible to use the tag name?!

[Bruce]

with my propositin, you keep your original branch and you got a new one merged on from J, meaning you can still modify your old 1.0-patched branch and work on the new one (in your drawing, you removed C - D - E, thus my question)

[VonC]

@micha149: yes, I mistaken it for a branch name!

[VonC]

I actually like this solution better, if you need to keep track of each development effort needed for each deployment. (So +1) But if said development effort are always the same, a simple rebase would be enough.

[micha149]

The branch name in the production system is fixed. If I recreate the branch, the production system seems to lost the tracking. So, I prefer the rebase variant. Thx