Question

I am trying to figure out the right workflow for this situation:

On the shared repo, we have these branches:

-master
-feature

The feature branch is a shared branch, since many developers are working on a new feature together. They are actively pushing their changes to the feature branch.

I’m trying to avoid ‘conflict hell’ for the day that feature finally gets merged back into master. Currently, I see some options:

1) Actively merge master into feature, and do it often. However, this is not recommended in the git docs, and I’m starting to see why. When I try this, I seem to fix the same conflicts over and over again.

2) Use rebase in some way. I’ve read up on this, but it looks like it wont work since the feature branch is actually shared. All it takes is one developer to do 2 rebases, and other developers could have conflicts from mismatched history.

3) Turn the feature branch into an integration branch, and have the developers use their own independent feature branches with rebasing to keep things sane.

4) Something completely different?

Answer 1

For a shared branch, I would go with #3, and use it as an “integration” branch to consolidate their work.
The developers would have to use rebase to constantly replay their private branch on top of feature before merging back their work to feature, that way they are:

• solving any merge conflict locally (in their own repo)
• making the final merge (from their private branch to feature) a trivial one (normally fast-forward)

(as described in “git rebase vs. merge“ answer)

The idea is that, once feature branch has to be merged in master, no more contribution is accepted on feature (the branch is “frozen”), and you can safely rebase it on top of master first, or merge it directly to master.
And then you start a new feature branch (which can actually start in parallel of the previous feature branch if needed)