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 bra开发者_JAVA技巧nch 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?

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)

You can use rerere to handle the merge conflicts you're seeing multiple times.

(I'm not too keen on options 1, 2 or 3 so I'm trying to find a better workflow; I'm therefore describing below how I'm thinking of approaching the problem in the hope someone will advise me)

1. Turn the feature branch in a patch queue using one of the git patch queue tools.
2. Use a separate git repository to version control the patch queue
3. Use the usual git approaches to collaborate on the patch queue.

It might be sensible for people to turn the patch queue back into a feature branch locally.

Git Workflow for Feature branch

The process is follows:-

First Time:

git pull
git checkout -b sprint-4
git pull origin sprint-4

• The above commands will pull all the files from git

• Will make a branch with name sprint-4 on our local machine.

• Will pull the files from server to our sprint-4 branch.

For every new feature:-

git checkout -b <feature-branch>,  example: git checkout -n fer-181
git push -u origin <local-branch>:<remote-branch>, example git push -u     
origin fer-181:fer-181

• Create a remote branch for this local branch on the server.
• Will push files from our local branch to remote branch.

Daily:(on your feature branch)

git pull
git merge dev

• resolve conflicts if any

• do your work for the day

  git push origin

Feature is complete:

git pull
git merge dev

resolve conflicts if any

git checkout dev
git merge <feature-branch>
git push origin dev

• The above commands will merge files from main branch in our feature branch.
• Resolve conflicts in our feature branch if any.
• Merge the files from feature branch to main branch.