Does anyone know of a name for the practice of maintaining $USER/$feature branches, or any discussion of git flows that use that pattern?

We're experimenting with a workflow that involves each team member maintaining a $USER/$feature branch, adding their own commits and merging from others' branches until they all match, at which point we merge to base. We're finding this works well for consensus-building on how a feature works as well as cross-training on how it's implemented. It also parallelizes code reviews and helps avoid some of the other downsides of a single-threaded release or deployment process.

In our example, alice commits on the alice/feature1 branch, bob commits on bob/feature1, carol on carol/feature1, and they are encouraged to selectively merge or cherry-pick from each others' branches while working on their own. We use pre-written test cases to give them all the same target. While this sounds like a lot of redundant code would be written, what we're finding in practice is that it encourages better communication and collaboration, both sync and async, and helps junior members come up to speed faster. We're so far using a simple bash script that helps with merging and diffing. The script also scrapes the git log of the remote branch to create Co-authored-by: lines in the commit so we have proper attribution when code is copied between individuals' branches.

Continuing the example, when git diff alice/feature1 bob/feature1 and git diff alice/feature1 carol/feature1 both return nil, then we've converged on a solution and it's time to merge to the base feature1 branch. What happens after that is dependent on project, but in general feature1 then merges to master or a deployment branch.

If I had to name this, I'd call it something like "consensus flow", but that's just me. Has this pattern already been in use for a while elsewhere and my google fu is simply failing me?

  • I'm not sure that I fully follow. If you have two people would they have their own feature branches for the same feature? For example, if you had Bob and Sue working on Widget, would there be Bob/Widget and Sue/Widget branches? Could you also elaborate on "merging from all others' branches until they all match"? – Thomas Owens Mar 15 at 10:20
  • @ThomasOwens Thanks for the question -- I've added an example. – Steve Traugott Mar 15 at 21:47
  • I honestly can't see how what you describe can be effective. You're spending 3 people's effort on a problem, but not collaboratively like pairing or mobbing. I doubt that there's a name for this because there are names for other patterns that have been proven effective at having multiple people collaborate on a problem. If it's only the asynchronous nature that you're working on, I don't see how this is much better than sharing a single branch with decent commit history to let people understand the progression. – Thomas Owens Mar 15 at 21:55
  • @ThomasOwens This started as mobbing. We're finding this as if not more effective for remote mobbing. What were mobbing sessions where everyone's time is focused on one line of code has segued into what I'm describing here. We're finding ourselves still meeting during our normal mobbing time slot, but alternating between traditional mobbing and this practice. We also tend to use mobbing-style flow during convergence. I'm pretty sure if I were to ask Woody if this is still mobbing, his answer would be something along the lines of "try it and see if it works for you". – Steve Traugott Mar 15 at 22:15
  • 1
    To the best of my knowledge, this doesn't exist anywhere else. Perhaps you and your team should consider giving it your own name and writing and/or presenting about it. It does seem like it could be an asynchronous version of mobbing, but the emphasis is typically on reducing the amount of asynchronous work within a team instead of finding ways to work around it. – Thomas Owens Mar 15 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.