Untangling a git branch from others

Question

I need to untangle a feature branch from an underlying develop branch. We have two immortal git branches: An upstream development branch and stable branch that gets deployed. Our workflow calls for feature branches is to merge to develop, go through a manual test process there and merge the feature branch to when it passes the test. That way the product team knows where they can test and we can catch feature interactions.

Unfortunately, I started a feature branch by merging it from develop instead of from stable, and later merged it into my feature branch again. So even though my feature got merged to develop, got through testing and should be going to stable, I can't merge it to it, since it contains code from other feature branches that got merged to develop, but haven't gotten through testing yet.

So I basically need to remove all the unrelated commits from my feature branch or get all good commits to another one.

A coworker figured we could copy paste the related files. That should work, since it's a fairly isolated feature, but I'd like to have the same commits on the feature branch, on develop and on stable, so we don't get weird merges and even more commits polluting our history.

I initially tried branching a new branch from stable, getting all related commits in reverse order via git log and cherry-picking them over. But that got me merge conflicts and problems from merge commits for some reason.

Then I tried branching a new branch from stable, rebasing it against the feature branch and dropping all unrelated commits. That worked, but git sees a lot of differences between the new feature branch and both the old feature branch and develop (where it got merged into) for some reason.

Unfortunately, I think the right thing to do is what you already tried: create a new branch from stable, cherry pick (in chronological order) the relevant commits, and bite the bullet: fix each conflict one at a time. The conflicts might come from the other features that were present when you wrote your feature, e.g., in which case you might need to adjust your code to work on stable. My advice is to just keep at it: fix the conflicts and continue cherry picking. — joanis, Jun 18 '21 at 18:50
You are following the right way to solve it (by cherry-picking.... i think trying through rebase is possible but trickier), as @joains already commented. The conflicts, if they happen, are because code is different between stable and develop so you need to take care of them, no way around that. — eftshift0, Jun 18 '21 at 21:36
As an aside, your workflow sounds very much like the one I discussed the problems with here: https://softwareengineering.stackexchange.com/q/421093/96713 If your "develop" branch never gets merged to "stable", what value is there in testing it, over testing the individual features directly? — IMSoP, Jun 19 '21 at 08:34
Hey, thanks for your answers. I eventually managed to separate my commits by cherry-picking in chronological order. Got a lot easier once I went started from stable two weeks ago instead of stable now :) Having fairly isolated features helped a lot, and having a bunch of merge commits and duplicate commits made it a lot worse. And then the other features that had gotten tangled up in mine got accepted today, so the whole point became moot :) — Damian, Jun 21 '21 at 20:03
@IMSoP There are a bunch of different features in progress and some get to product testing at the same time. When we deploy the feature branches, we need a growing number of servers, there's a risk one of us will accidently overwrite somebody else deployment and the product team gets confused about which feature is on which server. But yea, develop and stable are bound to diverge after a while. Hopefully we can periodically cut develop and pull a new state from stable. Though it still feels awkward to branch from stable and merge to develop. — Damian, Jun 21 '21 at 20:06
@Damian The biggest risk is not that the develop will diverge from stable, or not directly. The biggest risk is that somebody wastes entire days of their time testing a version of the code that will never exist, because it includes a combination of features that never gets released - they test features A plus B, but B is scrapped, and A is actually released with C, which interacts differently. You need exactly as many servers as you have things being tested at once _because that's how many things you're testing_. — IMSoP, Jun 21 '21 at 20:08

score 0 · Answer 1 · answered Jul 08 '21 at 19:19

I eventually managed to separate my commits by cherry-picking in chronological order. Got a lot easier once I went started from stable two weeks ago instead of stable now

In theory, a git rebase -i could help, since it presents to you all the commits, and you can drop the one not part of feature, keeping the ones of interest.

We have two immortal git branches: An upstream development branch and stable branch that gets deployed

You could consider gitworkflow (one word), making development a branch reset at each new release iteration:

The idea is: avoid the tension of Git Flow (feature->dev->master) described here:

in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts.

If you merge multiple feature in Dev and merge it to stable, you merge everything, including features which are not ready.

If you merge directly features to stable, you are merging only the ones deemed ready in dev, which becomes an ephemeral branch, reset at each new development iteration.

Hey VonC, thanks for the comment. Resetting the development branch would definitely be a good idea. We can't automatically do it at every release, since there might be features for other releases already on there, but we should usually be able to do it. — Damian, Jul 10 '21 at 05:31
@Damian The idea is to take those "other feature already there" and remerge those feature branches to the new reset dev branch. — VonC, Jul 10 '21 at 08:04

Untangling a git branch from others

1 Answers1