petervanderdoes
Why does finishing release/hotfix merge master to develop?
According to the original Gitflow model a hotfix or release should be merged to both master and develop. But using Git-tower (they send me here since they use gitflow-avh) a hotfix or release branch is merged to master, which is then merged to develop. This pollutes the history since there are now two merge-commits in develop (one for merging hotfix/release to master and one for merging master to develop) instead of a single merge-commit on master and a single merge-commit on develop.
So what is the reason for implementing it this way? I guess I must have overlooked something :)
I'm having the same issue. This did not happen in 2.4.8.0 (using SourceTree here), but happens on 2.6.10.0.
I guess I'll have to live with this then though I believe it should be an option so that people (like me) that do not rely on git-describe can avoid the extra merges
btw. I changed to SourceTree as well. Used to use it at my old job but it got too slow when having 5+ tabs/repos open at the same time :)
I agree it should be made an option, as that was how gitflow was originally designed.
Actually imo I think doing a git describe on develop logically doesn't necessarily always have to return the most recent release version, and in fact it doesn't have to at all. It does what it does, and for users who wants to know the version, they can simply do it on master branch.
So I'm on your side. However I feel that most people are command line users who don't us graphical client. They tend to care less about how the graph ends up looking like.
Maybe you're right about most people using cli and therefore not caring about the graph π they do however have to "scroll" past the extra commits in command window when getting a list of commits to review what has been done lately π Also I agree with you about describe on develop. Actually I'm not sure I see the reason for using it on develop at all? Making a last commit with version bump (and tag) on release (or including it I a bugfix) and merging that to both master and develop should, as far as I know, make sure that the version tag is reachable from develop should you need to use describe. This tagging could be part of the finishing of a release/bugfix for automation as well.
ζηεδΊδΉζε樣ηηεγ
But I work fine with this. No problem at all.
Until today I was following original branching model but I find merging master to develop better in git describe context. In original model tags on master branch are not part of develop branch which is misleading since develop contains all changes from released versions.
I think I'll change my flow starting from today.
