Git workflow for demoing features before release

Question

My team and I are looking for a git workflow for demoing experimental changes/features in our web application before they are released. Our audience includes our project manager and designer -- people who we do not expect to run an instance of our app -- so we need to host the webserver as well.

In our first attempt, we created a demo branch and merged in our feature branches as changes were ready to be shared. After a change was approved, the feature branch was to be merged into master and released. Unfortunately, we found that keeping demo up to date with master consistently resulted in merge conflicts.

We could do something like each feature branch gets its own instance of our application, but the ideal would be grouping all demo features together and serving them in one place.

Does anyone have any advice?

EDIT: For clarification, the merge conflicts seem to be the result of files being changed on both master and demo. Our feature branches tend to be long-lived (say, around a week while things are tweaked), and inevitably bug fixes/other changes are made to master in the mean time.

Answer 1

If you use gitflow the develop branch can be used in the same way as your demo branch with no merge conflicts.

However. Your main problem isnt getting pre release version of the code. This could be done in any number of ways.

Your main problem is how to handle the situation if one feature in the demo is not approved for release.

You can't change the code, commenting out the problem feature, and release without retesting and redemoing etc.

The only workable solution is to demo each fearure separately in its feature branch and only merge to master/develop once approved.

This is equivilant to trunk based development, you have to keep the features small because you have a constant stream of changes needing to be merged back up into other features

Feature toggles are highly spoken of, but deeply flawed. If you want to test you have to test each combination of feature toggles and it soon becomes impossible. Avoid at all costs.

Answer 2

It is not clear from your description, are your conflicts caused by genuinely different changes in different feature branches which happened to be in same place, or changes in same feature branch which somehow lost their history information. If the latter, you probably are trying to avoid force pushing the demo. So that all the temporary merges are there in history and they cause conflicts.

Better approach would be re-creating the demo each time from latest master and merge there the feature branches you want to demonstrate. Such approach works for the git project itself, they have pu branch which merges all proposed patches and is updated as often as any patch has any update. This way you would avoid unnecessary merge conflicts because of different versions of same change clashed together.

The merge conflicts which happen when different feature branches edit same place are probably unavoidable completely. If the feature branches live long enough so that you have to merge them several times again and again, resolving same conflicts, you may want to try git rerere - it really helps in such cases.

Answer 3

Instead of having demo updated with master each time a feature is merged, I think you can create different demo branches from master each time a demo is required. (demo/feature_A, demo/featureB, etc)