2

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.

  • 2
    Do not use feature branches. Use feature toggles. And make sure you demo on environment that is as close to production as possible. – Euphoric Oct 25 '19 at 6:12
3

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.

  • You don't have to test each combination of feature toggles. You mostly need to test the combination(s) that you intended to use when the code under test is released. Generally this is just one or two combinations. – bdsl Oct 25 '19 at 11:03
  • @bdsl true, if you never toggle a feature, but this would be the same as commenting out code. There would be no purpose to the toggle. – Ewan Oct 25 '19 at 13:15
  • Feature toggles look a little loose (ie, easy to forget about and accidentally release the wrong version). – danwoz Oct 25 '19 at 19:05
  • @danwoz: only when used in an non-systematic way, or when applied wrong. – Doc Brown Oct 27 '19 at 13:32
  • @Ewan: the same argument you gave against feature toggles could be applied to any (regular) configuration option in an application. And just because an application allows lot of configuration options, it does not become "untestable". – Doc Brown Oct 27 '19 at 13:36
1

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.

  • Good point. I've updated the description with more info about our conflicts. git rerere sounds really interesting, and may be the solution to our problem. – danwoz Oct 25 '19 at 18:54
1

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)

  • This may well be what we end up going with, but that does mean we'd have to have a separate instance of our webserver running for each feature, probably. Not the end of the world, but it would be nice to put them all together. – danwoz Oct 25 '19 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.