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?