Zuehlke
Article: Git Branching Models Dissected
There is the very popular "GitFlow" model: http://nvie.com/posts/a-successful-git-branching-model/
As a contraposition, there is the "Cactus" model: https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
I don't agree that either of these is a silver bullet, and I have an opinion on which of the two models fits well in which context (which both of the authors lacked to make clear imho). https://twitter.com/tknerr_de/status/836828287741661185
In the article I'd like to clarify:
- which of the models fits well in which context
- define the context / constraints in which "GitFlow" fits well
- define the context / constraints in which "Cactus" fits well
- emphasize the importance of remote / shared topic branches (for PRs / code reviews) and that they are only worth half if they are not built on CI
- define what "topic branch" means (short-lived, per feature/bug/whatever)
I don't want to repeat what's written in the original articles, but rather discuss when to apply which of the models
There are also some nitty gritty details where I'm opinionated about and which could be discussed (just don't know if that would get too long then), e.g.:
- rebasing topic branches vs. merging master into the topic branch
- fast-forward merging a topic branch for linear history vs. non-fast-forward merges explicitly creating an artificial merge commit
- using release preparation branches
What do you think?
See https://www.yammer.com/zuehlke.com/#/Threads/show?threadId=832088152 and some other threads in yammer were we discussed allready similar topics.
I think the article should give a clear view on how to work in a usual Zühlke project with those models and should be "pragmatic" and practical and not dogmatic about only one of these models.
@tknerr I have an oppinion on that one, that I would like to share in this article. Can we write it together? What do you think?
@bruderol yes sure, would love that. Just a matter of getting some non-project / friday slack time for this on my side currently...
The discussion linked above (feature branches / pull requests) is more of the micro view. There is also the macro view (release branches, cactus vs gitflow, etc) which I'd like to discuss in this article.
And there is also an earlier discussion on that which I found :-) https://www.gitbook.com/book/bruderol/pragmatic-development-team-guide/discussions/7
we could also make several articles out of it, if the topic gets too complicated.
and we can link to additional material (like fowler's blog, trunk based dev blog, git flow, my dev guidelines, ...)
I would add another viewpoint to this article: "What problem are Feature Branches solving?" --> Are the other options to solve this?
Great discussion so far. Can someone confirm, that he/she will write the article? Or shall we put the "author wanted" label?
To be honest: I am a little bit bored of this dogmatic discussions about trunk based versus feature branches and especially of people fighting against feature branches. For me it is not one or the other - you usually have to use both in conjunction for a larger software project. I consider git flow a great model when doing it right. For me it has become a defacto standard in the git world. And that is not a bad thing at all. All criticism out there mostly comes from people that had bad experiences when it was applied wrong. Gitflow doesnt say: do many long living isolated feature branches without never integrating between them. I could write the article - but currently no time for it and especially I fear the discussions that could be caused again through this article. If I wrote the article I would only focus on gitflow and how to apply it right to not cause damage in your projects. Maybe I would call it something like "Most famous mistakes and missconceptions about gitflow"
putting the "author wanted" label because it is unclear whether this article gets written