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.
Best Answer
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:
Some other ideas: