3

Let's say we use two branches for development: staging and master. During the iteration all the changes made by all team members are regularly merged into staging branch and appear on our staging environment. Customer has the ability to review the changes and give a feedback. At the end of the iteration we merge staging branch into master and perform deployment from the master to our production instance

Imagine the situation when we have specific feature that can only be partially implemented in the current iteration. But at the same time we want our customer to see (and hopefully give a feedback) the changes brought by that feature on our staging env. As a result at the end of the iteration in our staging branch we have commits related to the features that should and should not be merged into master

Is there a way to solve situations like this?

amost
  • 153
  • 3
  • 7
  • 1
    Have you considered using the Feature Toggle pattern? This would enable you safely deploy changes to production and switch them on in a selective manner. This is a common approach to implementing Continuous Deployment: See http://martinfowler.com/bliki/FeatureToggle.html and http://stackoverflow.com/questions/22700147/mitigating-the-risks-of-auto-deployment/22702282#22702282 – Mark O'Connor Mar 28 '14 at 01:03

1 Answers1

0

You basically have 2 options.

  1. Reverse out the merges from the staging branch that you do not want merged into master:

    $ git revert <merge_commit_sha1>

    This will append a new commit that "undoes" the changes from that merge commit (file deletions, code changes, etc)

  2. Cherry pick the ranges of commits into master that formulate the features you want pushed

    $ git cherry-pick <start_hash>^..<end_hash>

Remember the ^ or else git will not include the <start_hash> commit

Bauhaus
  • 509
  • 8
  • 22