Trying To Understand/Determine A Basic Git Workflow

Your summary is accurate: you can find illustrated in this cheatsheet.

Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).
There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)

The difference is:

  • with git flow:
    • multiple feature branches are merged in devel (where they discover if they can work together or not)
    • then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).
  • with gitworkflow:
    • feature branches are merged to a “public” “alpha” branch, which is reset after each release (meaning, deleted/recreated on top of the new release)
    • then a subset of those same feature branches are merged to a “next” (“beta”) branch for integration/acceptance test. That “next” (“beta”) branch is similarly recreated on top of master after each new release.
    • then a sub-subset of feature branches are merged to master, to prepare the next release.

The “public” and “next” (aka ‘devel‘) branches are never merged to master. They are “transient” or “ephemeral”, always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master).
That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.

Leave a Comment