Comments (38)
@travisdmathis : it's a workaround, yes, but not always possible. Sometimes you just started a hotfix for a certain issue, and it takes a couple of days to pinpoint/fix/test before you can release. In the meantime an urgent production issue crops up that needs to be dealt with now. You have a half-finished hotfix in progress that won't be released for another couple of days, and no way to start a new hotfix until the first one is released or abandoned/deleted.
Sure, you could manually
- create a regularbranch off of the first hotfix branch (git co -b)
- cease work on the original hotfix branch
- remove it
- start the new, urgent hotfix branch from master
- finish that
- then create a new hotfix branch for your original abandoned hotfix
- cherry-pick the changes in from your copy of the original hotfix branch
- continue where you left off in the original hotfix before the interruption.
Kind of counter to the whole idea of saving work by using git flow as a standardised branching strategy.
Multiple hotfixes for separate issues is a regular occurrence in production environments, and should be supported by the VC workflow. And indeed, the decision of which version number to release under should be postponed until the hotfix is merged in again. To ensure an urgent fix that was started after a less urgent one, but released before, ends up with a lower version number than the next release.
from gitflow.
It's incredibly common for projects to maintain some number of legacy releases, and have a need to patch multiple past releases when a serious bug or vulnerability is found. I've tried to introduce gitflow to some teams I work with, and I agree with them that this is a must have feature before they can adopt it.
from gitflow.
Hello. It is implemented in gitlow-avh, packaged in my Debian:
https://github.com/petervanderdoes/gitflow-avh/blob/develop/git-flow-hotfix#L208
Regards.
from gitflow.
This wouldn't be the case if you have already "released" 1.0. Because a release would mean you have finished the release branch and tagged the commit on master. So effectively, after releasing, your release branch is gone.
However, problems arise when you start a release branch, and while applying the latest bugfixes on that release branch, some hotfix needs to be created. Since the hotfix is branched-off from master and merged back into master+develop, this would bypass the currently active release branch.
In effect, you would:
- Introduce the bug again in the next release; or
- Risk changing behaviour (untested) when merging the release branch back into master. Note that the last commit on the release branch and the merge commit on the master branch should ideally have no code changes (i.e. should ideally be no "real" merge). This changes that situation. You're going to tag something that hasn't been tested.
For implementors/contributors: A way to deal with this problem would intuitively be the following. (Note that I haven't thought this through yet in great detail.):
When finishing a release/hotfix branch, we should merge changes into master and develop (like regular), but additionally merge that release/hotfix branch into every other existing release/hotfix branch too.
Note that this may well become unwieldy quickly if there are lots of concurrent release/hotfix branches. If there exist n release and m hotfix branches, this implies 2 + n + m - 1 merges.
from gitflow.
@bitslasher We've been using https://github.com/petervanderdoes/gitflow and have been happy with it. Still no multi-hotfix support, but it is being actively maintained.
from gitflow.
If I'm reading this right, this is to cover situations where I have tagged and released 1.0, and am actively working on 1.1, but might need to apply some fixes for a 1.0.1 release that are also included in 1.1. Is that correct? If so, I'm interested in seeing this functionality too. Do you have an idea as to how you might like to see this implemented so others might contribute?
from gitflow.
Just submitted another pull for this. I'm thinking this should be a flag you can set in your gitconfig, ie:
[gitflow]
hotHot = true
from gitflow.
work around for multiple hotfix branches is to complete work locally on one hotfix and push to remote then delete locally and create a new hotfix branch. this will let you have multiple hotfixes remotely. Not ideal, but its what i've resorted to doing in the meantime.
from gitflow.
I see the problem, though as a team, we often have multiple hotfix branches. I would like to have support for multiple hotfix branches. Maby add code so when they are finishes its merged into all release branches also.
from gitflow.
Hello,
+1 to multiple hotfix branches
Sometime, it take long time for a bug to get solved, and if an easier one is opened, I prefer to close it as soon as possible.
Other time, hotfixes are imbricated:
- new bug number 13 => new hotfix branch hotfix/13
hmm, this result in a bad interaction due to another bug - new bug number 23 (arf, too much bug in so little time... ) => new hotfix branch hotfix/23
- solve and finish hotfix/23 => new release 1.0.1
- rebase hotfix/13 on hotfix/23
- solve and finish hotfix/13 => new release 1.0.2
Regards.
from gitflow.
The require_no_existing_hotfix_branches()
function can be removed with my pull request to Peter van der Does
When finishing a hotfix, must be ahead of the production release branch, this require the branch to be rebased/renamed.
We could decouple the hotfix branch name and the version number.
And then change the cmd_start()
and cmd_finish()
prototypes to:
git flow hotfix start <name> [<base>]
git flow hotfix finish [-n <name>] <version>
The name would be calculated from <version>
except if option -n <name>
is passed
The same logic can be applied to release branches.
from gitflow.
After some tests an thoughts I got the following interface:
usage: git flow hotfix [list] [-v]
git flow hotfix start [-F] <name> [<base>]
git flow hotfix finish [-Fsumpknb] <version> [<name>]
git flow hotfix publish <name>
git flow hotfix delete [-fr] <name>
This imply changes only to version filter (#186), the version is only required when finishing a hotfix (the same applies to release)
Except the semantic, lhe real new thing is the optional <name>
parameter:
-
If omitted, use
hotfix/<version>
as branch to merge -
if provided use it as branch to merge:
git flow hotfix finish 1.1 42
-> merge branchhotfix/42
to production release branch
Done in baby-gnu/gitflow@0abbb45
from gitflow.
Looking at Peter van der Does code there is a possible issue with tags:
- hotfix branch is merge into production release branch
- if user want tag and the tag does not exists, tag the current HEAD
I think we could make a better sanity check on the tag, before merging to the production branch:
- if user want tag and the tag exists, it must point to a merge commit with the hotfix branch as parent.
Done in my permit multiple hotfix branch (baby-gnu/gitflow@54cc9cb)
Done for release in my develop branch (baby-gnu/gitflow@961ebcd)
from gitflow.
I am unclear on the status of this issue. Why has @baby-gnu's commit not been merged in? Does it fail to resolve all issues? I would really like to be able to start and finish multiple hotfix branches concurrently, and independent of each other.
from gitflow.
@spiffytech +1
from gitflow.
+1 for multiple hotfix branches concurrently.
from gitflow.
+1 is important feature!
from gitflow.
Would also love to have the option for multiple hotfix branches.
from gitflow.
+1 for multiple hotfix branches
from gitflow.
So it looks like this just won't ever get fixed? This issue was raised over 4 years ago. Is there not a solution? Is gitflow not being maintained anymore? If not, guess I'll just fork it and fix issues myself. However it looks like others have fixed it already, it would be nice if the fix could be accepted one way or another.
Edit: It looks like gitflow is kind of dead. No one has commited in over 2 years. If author isn't interested in maintaining anymore, perhaps others could take it over? This is a very very nice thing you guys have created (I'm very appreciative), but it's a shame so many people have to keep forking to fix issues all over the place.
from gitflow.
π
from gitflow.
Another not ideal way is to simply rename the hotfix branch
git branch -m hotfix/ticket-102 hotfix-pending/ticket-102
from gitflow.
π
from gitflow.
This is an important feature! Our company likes using the gitflow model, and we have a ton of different projects, and it's not uncommon that the need arises for multiple parallel hotfix branches when support tickets start rolling in. We've resolved to manual creation of branches as well as part of gitflow's workflow at times due to that! Please please pretty pretty please with a cherry on top - could we have multiple parallel hotfix branches, please?? It always seemed odd to us that we couldn't..
from gitflow.
Just adding myself to the other folk who really want this feature (well really it's a removal of the check for one existing, I assume).
from gitflow.
Awesome work guys
from gitflow.
π
from gitflow.
π
from gitflow.
π
from gitflow.
π
from gitflow.
π
from gitflow.
π
from gitflow.
+1 for multiple release and hotfix branches.
from gitflow.
+1
from gitflow.
+1
from gitflow.
+1
from gitflow.
+1
from gitflow.
+1
from gitflow.
Related Issues (20)
- sorry
- README link 404
- Is it possible to make custom message during MERGE
- [BUG] "Fatal" error of "Working tree contains unstaged changes" returns zero error code HOT 2
- Branch and all commits lost from local machine and server when interrupting "git flow feature finish" and re-running. HOT 1
- How can I suppress "Summary of actions"
- Is it possible to make git flow merge the master branch into develop instead of the hotfix one on finish? HOT 1
- Error when install from `gitflow-installer.sh` HOT 2
- Will git flow be configurableοΌsuch as change the hotfix merging direction from Master&develop to Master&realease HOT 1
- Multiline release tag messages cause problems
- ry 2
- Windows gitflow install link has malware HOT 2
- why can't I clone the gitflow folder? HOT 3
- Can't install in Fedora 36
- Link to probably virus in Wiki
- Dead project: Archiv state and link to replacement HOT 3
- how to work gitflow together with github HOT 1
- RFC: Improving Git Workflow Using Versioning Patterns
- Error install git-flow Rocky Linux 9.3 HOT 5
- Add -m parameter to `git flow feature finish` for custom commit messages
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gitflow.