Pulling changes into remote tracking feature branch while keeping simple branching workflow

Question

We're a team of a couple of developers that have our master branch and develop features in feature branches. We branch release branches of master when we release. All bug fixes are made in master and then cherry-picked into the relevant release branch.

We want to have atomic merge commits for each new feature that we can roll back and bisect over as described in https://gist.github.com/jbenet/ee6c9ac48068889b0912. It should give us a history that looks like this.

* aa55ffe -  (HEAD, master) D
* 88425f8 -  C
*   7bc519f -  Merge branch 'feature-X' into master
|\
| * 9364e61 -  feature-X: 2
| * bc76674 -  feature-X: 1
|/
* 88425f8 -  B
*   7bc519f -  Merge branch 'feature-Y' into master
|\
| * 0e0deea -  feature-Y: 4
| * 11079b5 -  feature-Y: 3
| * 9364e61 -  feature-Y: 2
| * bc76674 -  feature-Y: 1
|/
* c765ae3 -  A

Our issue becomes when we have multiple devs working on the same feature tracking to our remote version of the feature branch. Because while some devs work on that feature, the bug fixing can be happening during a feature development in master. We now want to include those bug fixes in the feature branch(i.e. re-rebasing the feature branch of a new state in master where the bug is fixed.).

Is there a way to do this that doesn't include corrupting the remote tracking branch and thus screwing up the clean history and the other feature-developers working copies?

F.x. Could one cherry-pick the bug into the feature branch and have git automatically resolve it away after the final rebase where we orphan the remote tracking branch just before merging the new rebased version of the feature branch into master?

Answer 1

Could one cherry-pick the bug into the feature branch and have git automatically resolve it away

This can work if your fix introduces no conflicts. git clone https://gist.github.com/jbenet/7959265, see the history and read the reflog I pasted there.

If you resolve conflict upon cherry-picking, you could remove the commit manually when rebasing on top of master, right before merging PR in (you can tag it/write a reminder in the commit message resolving the conflict).

But IMO, I'd rebase the feature branch on top of master when the hotfix was available. This is the same as pulling in any changes from master (inc other feature branches merged recently). Thus you're not worried about your branch being out of date. Depends on what your team likes to handle-- removing merged hotfixes, or rebasing often.

Answer 2

If you really need the bug fix in your feature branch, merge the bug fix branch in. The talk about bisect/rollback/whatever was FUD--bisect, in my experience, handles complicated merge histories just fine. The model proposed in that post creates artificial problems (such as the one you are asking questions about) and quite literally its only benefit is a cleaner looking history. We used this model for a couple years before realizing the benefit of not rebasing. I rebase when I need to clean up my own history (squash commits, change commit messages, etc) but only it does not effect anyone else downstream (like if I'm working on the branch solo).