Does git branch hierarchy reflect branch hierarchy?

Question

I am working on a project with several branches managed by GIT.

Our current workflow is this:

master |-> v1/master |-> v1/dev 

Note. Each developer creates a v1 / dev plug for the implementation of the task. Potentially we have the number of branches allocated from v1 / dev

We need to add a branch, a cheat from v1 / master named v1 / debug. And the current v1 / dev branch should depend on v1 / debug.

We are setting up this new workflow:

 master |-> v1/master |-> v1/debug |-> v1/dev 

Note: everyone should continue to do fork v1 / dev to complete the division task.

---

I am looking for a solution to add an intermediate branch v1 / debug.

After some research, I would use the git rename branch command ( How to rename the local git branch?).

Is this command maintaining a branch hierarchy?

Can I rename v1 / dev to v1 / debug and after that make a new v1 / dev branch a branch to cause problems in the current branch development branch from the current v1 / dev branch?

Can developers be able to combine the result of the branch branches of the renamed v1 / dev to v1 / debug?

Answer 1

First of all, do not rename the branch . You can rename your local branch, but this only applies to you. Remember that git is a distributed system. People have the right to call their local branch a different name than the associated remote tracking branch.

For example, v2/debug might be the name of a local branch tracking the remote tracking branch origin/v1/master (I know this doesn't make sense, but since git is a distributed system, people can name things like they want locally .

Do not rename the branch remotely . This would ruin everything because it would not 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 run it at v1/master at the moment. To create it and switch directly to it:

 git checkout -b v1/debug v1/master 

Or just create it, but stay in the current branch:

 git branch v1/debug v1/master 

The branch is created locally and still needs to be clicked so that others can see it.

Later you only need to change the 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 talked about the hierarchy of branches . Actually the branch hierarchy is "unknown" before git. It’s just how you merge (which branch, which one), which at the end makes a hierarchy.

Image workflow example

• Initial state ( v1/master and v1/dev ). Here it is assumed that v1/dev is 1 commit before v1/master . It is also assumed that we are currently on the v1/master branch.

• Run git branch v1/debug v1/master . This only creates a label that points to the same commit that v1/master is currently pointing to.
  

• Once the v1/dev branch is ready, merge it into v1/debug . Run git checkout v1/debug && git merge v1/dev .
  

• Once the v1/debug branch is ready, merge it into v1/master . Run git checkout v1/master && git merge v1/debug . From now on, what you call a "hierarchy" begins to manifest itself clearly.
  

• Do some work with the v1/dev branch. Run git checkout v1/dev and make some commits.
  

• Combine it in v1/debug . Run git checkout v1/debug && git merge v1/dev .
  

• Combine it in v1/master . Run git checkout v1/master && git merge v1/debug .
  

Now you have 3 clear branches with the desired workflow!

Note that the graph will only look like this if you use git merge --no-ff . This makes things clearer in the picture, so I suggested that merges are not fast forward , so we always see what happened, even if these merge commits are actually useless.