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 indevel
(where they discover if they can work together or not) - then
release
is created fromdevel
(at which point removing features becomes complex) before being merged back todevel
(andmaster
).
- multiple
-
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 ofmaster
after each new release. - then a sub-subset of
feature
branches are merged tomaster
, 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.