I have been looking at gitflow and maybe someone can clear up this reasoning for me. The merge of a hotfix is done back into master and into develop. It seems to me it should merge to release as well. Release gets merged into develop and master anyways. The problem I see with not merging hotfixes into release is that if I build a release and it passes, merge that release into master but there are hotfixes in master that weren't included in my release build, technically I should revalidate again. If hotfixes were merged into release as well and that build passed, there would be no need for a rebuild after things were merged into master. Also, release gets merged back into develop anyways, so merging into release would by default get those changes back into develop. This is a gripe more with the standard gitflow than with the fact that Source Tree has implemented it this way, but maybe there is a reason for it.
Thoughts?
SourceTree supports the original gitflow plugin (description). All the behavior you describe is controlled by that.
After-re-scanning Nvie's blog, he appears to agree with you: "when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop
". However, I can't explain why he wouldn't have programmed that behavior into his own plugin.
There are feature requests for getting SourceTree to switch to a fork of Nvie's gitflow (Nvie's is no longer maintained), but I'm not sure what its behavior would be in this scenario.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.