1

I have a workflow in which I need to have some features shipped to dev for testing before they are pushed to prod. The problem is that some of these features need to stay on dev server indefinitely and never be pushed to production server, so I can't ever sync dev branch with prod branch directly. This means I can't use a model in which I only have one master branch that gets published to prod via tags. I probably need to create a branch per each feature request and always branch off of the prod branch so as not to push anything that shouldn't be on prod from dev. I'm wondering what is the best approach for managing something like this with git.

The current idea is as follows:

Production branch (master)
Development branch (development)

feature1:
- branch created from master
- completed and merged into dev
- tested
- stays on dev indefinitely

feature2
- branch created from master
- completed and merged into dev
- tested
- merged into prod

Is this solid enough approach?

Thanks!

Eugene
  • 10,006
  • 4
  • 37
  • 55

1 Answers1

1

Yes, this is actually what the Git repo itself follows:

  • It resets the staging/dev/testing branches at each new release cycle, making those branches ephemeral (ie destroyed/recreated)
  • it merges the feature branches to those branches (instead of merging from dev to test to staging)

See the Gitworkflow as an example (not "git flow", but the workflow used for the Git repo itself): by merging the feature branches directly to each environment branches, you avoid any dependencies between those branches (in your case, master does not depend on dev), and it becomes very easy to cancel some of those feature during the integration done in those different environments: all you need to not merge that feature branch in the next environment branch (in your case: master).

See more at rocketraman/gitworkflow.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250