GIT Rebase a Branch that is collaborated on?

Question

After reading this article, it makes sense to rebase to gather changes from the main branch on to my feature branch: Git workflow and rebase vs merge questions

c         


        

Answer 1

If you are working alone the rebases do nothing. You did not commit anything new to master.

Your merge will be a fast forward merge and you could do it by not checking it out at all with

git push . HEAD:master

Whether you are working with someone or not, merging work that is in master into your feature branch is a bad practice. It is called a back-merge. The reason that it is bad is that you now do not have an atomic piece of work. the history of master is now entangled with your feature making working with this feature, such as rebasing, impossible in many situations.

You need to think about your branching strategy and what you want to achieve. Here is mine:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

You can see that each branch starts from the same place. You have a separate integration branch and release candidate branch to mix and match the features you want while not contaminating them.

As for collaborating on one feature with a colleague, it depends on how large a feature is (the granularity of your work). If it's large, you can apply the process above to the feature itself and branch per task instead.

If it's a small feature you can merge or rebase on that branch - it won't matter much. At this point it comes down to what the team is comfortable with.

Answer 2

There is solution for your case without switching to a completely different workflow.

Regarding getting fixes from your main branch into feature branches, as you already found out, the best is to cherry-pick those particular commits. But I prefer to have topic branches even for hotfixes instead of fixing in the mainline, that way I can properly merge those fixes into every feature blocked by them.

To maintain feature development history as clean and linear as possible all collaborators must use git pull --rebase to get updates so no meaningless merge commits gets in the way.

If you still want to rebase a collaborative feature branch over current main development branch (for continuous integration testing or other purposes) or rewrite its history in any other way, you can do it once the feature is complete/done, just before the merge to main branch, but you should do it in a new separate local/private branch.

Here is how to recreate your on-topic changes (skip cherry-picks) in a new branch from master:

$ git checkout -b feature_final feature # jump to a new branch for grooming
$ git rebase [-i] master                # rebase topic changes onto master

From there is up to you what to do with the rebased branch —push upstream for QA or directly merge to master (with --no-ff if you like to make it explicit in history).