I have some conceptual idea / established workflow that I like to discuss and really would love to implement just to give something back to git-flow. I started already but before finishing it I like to see if it is wanted / needed.
What is the problem?
There is no flow for creating patches. The following steps need to be done by hand instead of (two) simple php-flow commands:
Some bugfixes shall be made.
Creating a new branch based on the version that is broken.
Working on them.
Tagging them.
Merging back to release branch (if given)
Merging back to master branch for production (if needed).
Also imagine hotfixes that do not get back upon the releases.
What is the solution?
Here is the flow (I like to see):
A not so wild bug appears: git flow patch start 0.2.1
Working
git flow patch finish 0.2.1 (tagging, merging back to release branch and master branch)
Also doing git flow hotfix finish foo-debug could take care of putting changes back into a new patch or existing release branch. Otherwise versioning would be a mess.
patch command strategy
Calling patch start a.b.c would mean:
Lookup if "release/a.b" exists and use that for now
Check what is the highest tag named "a.b.X" is
If the tag is newer then the release branch then we either have some invalid state or just use the latest of the two.
The base is checked out as a new branch named "patch/a.b.c" or "release/a.b.c" .
Everyone can work on it.
Calling patch finish a.b.c would mean:
Tag the current state as "a.b.c"
Merge the changes into the master
Merge the changes into a release branch (if exists)
Optional: remove patch branch
Missing parts
My workflow is a bit deeper than that and I need to bring up this scenario:
Patch 0.2.1 should also go into 0.1.5 (currently 0.1.4)
git checkout 0.1.4
git cherry-pick 0.2.0..0.2.1 (handling issues and doing git cherry-pick --continue)
Optional: git reset 0.1.4
Comparing changes, testing and then git commit or git tag 0.1.5 - done.
This is way to complex for git flow to handle I can imagine. But having a patch also in another branch is an issue which is not yet resolved by the git flow patch command.
Hi there,
I have some conceptual idea / established workflow that I like to discuss and really would love to implement just to give something back to git-flow. I started already but before finishing it I like to see if it is wanted / needed.
What is the problem?
There is no flow for creating patches. The following steps need to be done by hand instead of (two) simple php-flow commands:
Also imagine hotfixes that do not get back upon the releases.
What is the solution?
Here is the flow (I like to see):
git flow patch start 0.2.1git flow patch finish 0.2.1(tagging, merging back to release branch and master branch)Also doing
git flow hotfix finish foo-debugcould take care of putting changes back into a new patch or existing release branch. Otherwise versioning would be a mess.patch command strategy
Calling
patch start a.b.cwould mean:Calling
patch finish a.b.cwould mean:Missing parts
My workflow is a bit deeper than that and I need to bring up this scenario:
git checkout 0.1.4git cherry-pick 0.2.0..0.2.1(handling issues and doinggit cherry-pick --continue)git reset 0.1.4git commitorgit tag 0.1.5- done.This is way to complex for git flow to handle I can imagine. But having a patch also in another branch is an issue which is not yet resolved by the
git flow patchcommand.