Git Branching & merging workflow problems. How do you do it?

Question

This is our development workflow:

1. Developer works on an issue in a new topic branch.
2. Once he is finished, he pushes the branch up for review.
3. I merge the branch into a develop branch and push it upstream on the staging server.
4. Client reviews the changes and approves / declines it.

My problem is at step 3 & 4. The client has access only on the staging server, so in order for him to see the changes I have to merge the topic branch into a develop branch and push it to the staging server and I usually don't merge only 1 branch, but on average 3 - 4.

If the client rejects the changes and he needs further modifications then the developer fixes the problems in the same topic branch and I have to remerge into develop.

By remerging a topic branch multiple times into develop I loose track of that issue in the history. (sometimes resulting in conflicts too)

Is this a 'healthy' development workflow? What are your suggestions, improvements?

Answer 1

If the client rejects the changes and he needs further modifications then the developer fixes the problems in the same topic branch and I have to remerge into develop.

I would rather revert (as in git revert) the rejected change in the development branch, and wait for the developer's fix.
by using git revert, I only add new commits, instead of changing the history (with rebase or a git reset)

That way, the next commit (of the same feature) should be easily merged again in development branch.

Answer 2

Simply introduce a staging branch, that is dirty and no one is allowed to ever branch of it.

• Make sure your staging deployment process handles history rewrites. If your staging server pulls from a central repo, replace the pull with a fetch and a reset --hard origin/branch
• Whenever you want a client to review a change, simply use your process from before – merge it in and if it needs changing, remerge.
• Merge in develop once in a while to make sure your have all it’s changes. If you are not currently having any reviews (=staging should be in sync with develop), reset staging to develop instead (git checkout staging; git reset --hard develop)
• As staging is supposed to be dirty, you can always do crazy rewriting, like just going back a few steps (git reset --hard HEAD~4) without consequences if a change broke something etc.
• Only merge your changes into develop once the client approved them.

This way, you won’t have to worry about producing a nice history in a process where you don’t really care about history (showing stuff to clients) and your develop branch gets a very clean history.

In case you are worried about a having to resolve merge conflicts multiple times, have a look at git’s rerere feauture