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?