Does the git branch renaming affect branch hierarchy?
I'm working on a multi-branch project managed by GIT.
Our workflow is currently this one :
master
|-> v1/master
|-> v1/dev
Note : Each developper make a "fork" of v1/dev to realise task. Potentially we have numbers of branch heritated from v1/dev
We need to add branch whose heritate from v1/master named v1/debug. And the current v1/dev branch have to heritate of v1/debug.
We target this new workflow :
master
|-> v1/master
|-> v1/debug
|-> v1/dev
Note : Each have to continue to make "fork" of v1/dev to realise unit task.
I'm looking for a solution to add the intermediate branch v1/debug.
After some research, i would use the git rename branch command (How do I rename a local Git branch?).
Is this command preserve branch hierarchy?
Could i rename v1/dev to v1/debug and after that make the new v1/dev branch whitout to make trouble in current development branch outcome from the current v1/dev branch?
Could developers will are able to merge unit branch outcome of renamed v1/dev in v1/debug?
First of all, don't rename the branch . You could rename your local branch, but this will only apply to you. Remember that git is a distributed system. People have the right to name their local branch using a different name than the associated remote tracking branch.
For example, v2/debug could be the name of a local branch tracking the remote tracking branch origin/v1/master (I know, this doesn't make sense, but because git is a distributed system, people can name things like they want locally .
Don't rename the branch remotely either . This would mess up everything, because it wouldn't change the local repositories of your colleagues. Their local branches will continue to point to the same remote tracking branches (same name).
You just need to create a new branch and make it start at the point v1/master currently is. To create it and switch to it directly:
git checkout -b v1/debug v1/master
Or to only create it but stay on your current branch:
git branch v1/debug v1/master
The branch is created locally and still needs to be pushed for others to be able to see it.
Later, the only thing you need is to change your merge workflow. From now on, stop to merge v1/dev directly into v1/master , and only merge it into v1/debug . And merge v1/debug into v1/master whenever the code base is ready.
You were talking about branch hierarchy . Actually, branch hierarchy is « unknown » to git. It's just the way you merge (which branch into which one) which in the end makes the hierarchy.
Workflow example with pictures
Initial state (only v1/master and v1/dev ). Here, it is assumed that v1/dev is 1 commit ahead of v1/master . It is also assumed that we are currently on branch v1/master . 
Run git branch v1/debug v1/master . This only creates a label pointing on the same commit currently pointed by v1/master . 
Once the branch v1/dev is ready, merge it into v1/debug . Run git checkout v1/debug && git merge v1/dev . 
Once the branch v1/debug is ready, merge it into v1/master . Run git checkout v1/master && git merge v1/debug . From now on, what you call the « hierarchy » starts to appear clearly. 
Do some work on branch v1/dev . Run git checkout v1/dev and do several commits. 
Merge it into v1/debug . Run git checkout v1/debug && git merge v1/dev . 
Merge it into v1/master . Run git checkout v1/master && git merge v1/debug . 
Now you have 3 clear branches with the wanted workflow!
Note that the graph would only look like this if you use git merge --no-ff . It makes things clearer in the picture so I assumed the merges are non fast-forward , so that we always see what happened, even if those merge commits are actually useless.
上一篇: 在VS中维护同一个基础项目的多个分支
下一篇: git分支重命名是否会影响分支层次结构？