Publishing a feature branch to preview periodically in git

Question

I'm trying to understand the best way to occasionally publish a feature branch into a preview branch for git. Here is my setup:

1. Client asks for feature.
2. I develop initial feature and publish to preview/testing site.
3. Client provides feedback.
4. I make more changes.
5. Go to step 3 a few times.
6. Client is good to go with feature
7. Rebase feature into single commit pushed to production site.

Note that several different features may be developed at once and there is only one "preview" site where the client can see all these features as they are being developed. My git workflow currently.

git checkout -b new_feature
...hack hack hack...
git add .
git commit -m "WIP"
git checkout preview
git merge new_feature
... feedback and another feature got approved and merged with master ...
git checkout new_feature
git merge master
... hack hack hack...
git add .
git commit -m "WIP"
git checkout preview
git merge new_feature
... client approves work for release ....
git checkout new_feature
git rebase -i master
... squash all commits except the first which I reword with a good description...
git checkout master
git merge new_feature
git branch -d new_feature
git checkout preview
git merge master
git checkout master

So the end result:

1. I was able to develop the feature in it's own isolated branch and control when it goes to production. It also is rolled up in production as a nice neat commit.
2. The client can see the feature as I develop it and provide feedback. They can also see that feature along with other features I am developing simultaneously.
3. The "preview" branch become a little messy as it gets both the "WIP" commits and the final rebased commit. But I don't mind that much as it is just for client preview and I can periodically delete the branch and re-create from master if I want.

My only problem is that I seem to get more conflicts than I would expect. I am thinking this is because staging is getting both the development commits and the final commit. I am also wonder if there is a better way to do this?

Answer 1

Your workflow seems fine, except I don't like squashing all the commits from your feature branch before merging with master.

In my opinion, this doesn't add any value, and you lose potentially important information about the evolution of the feature.

When I merge, I use git merge --no-ff new_feature. This preserves information about the existence of a feature branch so that at a glance you will know which commits went into each feature:

Image source - A successful Git branching model