4

I've tried for almost a day to find out the best way to handle this situation, but even if I found and understood many things about how git works, I was not able to find any 'conventional' way of handle and solve the following situation on git (because of my lack of experience). In our project we have a develop branch and from this branch we need to create a new big feature branch that will be used to put together other small functionalities that will be developed in other sub branches, starting from this feature branch.

A--B--C--D (develop) \ E--F--G (feature-branch) \ H (sub-branch)

The reason for doing that is that we don't want to touch our develop branch until the entire feature is completed and, at the same time, if some bug fixes will be needed into the develop branch, we want to be able to apply them. At the same time we want to keep up to date our feature-branch if some changes (or bug fixes) will be applied to the develop branch. So from this situation

A--B--C--D--I--J--K (develop) \ E--F--G (feature-branch) \ H (sub-branch)

We want to have the following

A--B--C--D--I--J--K (develop) \ E--F--G (feature-branch) \ H (sub-branch)

Usually when creating a simple feature branch from develop I use to rebase my branch onto develop to move my commits and keep the history clean. In the explained scenario instead, me and my collegues we are sharing the feature-branch and we are creating sub branches from there, so how to keep the feature-branch up to date with the new commits added to the develop branch? Is it possible to rebase in the same way as we do for our local private branches without any side effects? Any example with git commands will be appreciated

Thanks in advance for every hint/resource or suggestion.

Improve this question

2 Answers 2

Reset to default
4

Firstly "sub-branch" is purely your concept, in git all branches are equal, there is no tracking of how branches relate to each other (only how commits relate when do operations like finding a common merge base).

All you need to do is merge from develop into feature-branch.

Assuming changes have been pushed by others into one or other of these branches (using git fetch and git merge remote/branch can avoid network round trips, but here I'll keep it simple):

git checkout develop git pull git checkout feature-branch git pull git merge develop # Resolve any merge issues... which may need an explicit git commit git push

feature-branch is now up to date with all changes committed to develop.

If you have only some changes in develop you want to merge then you may need to cherry pick some commits.

If any topic branches live for more than a short period the same process can be used to update a topic branch with the latest merges into feature-branch.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Ok, I understood your solution. I used the "sub-branch" term just to better explain the concept. One small question, why instead of merging develop into feature-branch is not possible to rebase? What are the consequences for other developers that created "sub-branches"?
@AndreaLoprieno Rebasing rewrite commits, which will mean forcing a push. This means the commits a developer is referencing locally are no longer part of the server's branch history. This can be clean up but unless you know you need to do that before merging from the server you can really dig your local repository into a hole. Merge vs Rebase is mostly about how the history looks, and I tend to prefer "what really happened" and have no problem visualising branches and merges.
1

When there has new changes pushed to develop branch (as commits I, J and K in below graph):

A--B--C--D--I--J--K (develop) \ E--F--G (feature-branch) \ H (sub-branch)

You can use below steps to keep feature branches up to date:

1. Rebase sub-branch on the top of develop branch

Execute below commands to rebase sub-branch:

git checkout sub-branch git pull origin develop --rebase git push origin sub-branch -f

Then the commit history will be:

 E'---F'---G'---H' (sub-branch) / A--B--C--D--I--J--K (develop) \ E--F--G (feature-branch)

2. Reset feature-branch

Use below commands to reset feature-branch:

git checkout feature-branch git reset --hard G' git push origin feature-branch -f

Then the commit history will be:

A--B--C--D--I--J--K (develop) \ E'--F'--G' (feature-branch) \ H' (sub-branch)
Improve this answer

3 Comments

Forcing a push o feature-branch will impact the rest of the team, and certainly will need some fixing if someone else is in the process of merging their sub-branch back into feature-branch.
@Richard is absolutely correct concerning the influence to the rest of the team. But I think that this is exactly the answer to the question. It's pity that it has such bad consequences. Note that you can use --force-with-lease with git push, but it doesn't solve much...
@Richard Yeah, after force push, it does should inform other members. But based on Andrea requirement (update feature-branch and sub-branch while keeping the branch structures), force push is the way which must be passed.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.