Merging from unfinished feature branches and code review

Question

We are using the git flow workflow, and it sometimes happens that we have long-lived feature branches. Of course we can merge from the develop branch into our feature branch, when another feature branch gets finished and merged to the develop branch. However, is it a good idea to merge directly from other feature branches, i.e. before they have been finished? Won't that create code review duplication and potential conflicts, because reviewers could end up reviewing the same commit(s) multiple times, potentially with diametrically opposing comments from different reviewers if the change is controversial, without anyone realising? Or, the same logical change could diverge in the two feature branches, and then become two slightly different changes.

Ideally we want our stories to be independent, but even if they are theoretically independent, there is often some partial changes such as low-level refactoring and fixup work in one branch that we might want to reuse in another branch.

What do you suggest we do in such a situation? Manually copying and pasting changes doesn't seem to help, it seems to in fact merely hide the problem. Sure, we can try to avoid this problem by giving more priority to code review and demos, trying to make stories smaller, etc., but I think this problem will still occur from time to time.

Answer 1

This is a common problems with all source control systems. It is a communication problem, perhaps made worse by the ease with which extensive changes can be made globally. You have outlined the most common solutions:

• Make the work done in a feature branch smaller, so that it is easier to integrate, and compare to the main branch.
• Make it a priority to integrate feature branches as soon as possible. Don't allow branches to become stale.

Some other ideas:

• Don't allow "low-level refactoring and fixup work" in any branch except one, the most important branch.
• When you compare changes in a feature, only compare against the original source it was branched from. You may have to re-do the work to integrate.
• Anyone who is going to do extensive global changes must communicate with all other people working on all other branches. Try to get all branches merged before these types of changes are made. Put a freeze on further branching until it is completed.