In git, the number of merge conflicts with people committing to a branch will increase with the number of people working on that branch. Gitflow violates the “Short-lived” branches rule I’ve been using git for 10 years now, and I’m not even sure I’m at the point where I could mentally keep up with what’s going on here. The mental model you need to retain for this to be useful carries a high cognitive load. More so than that, you also need to keep track of what branch is what, all the time. These are all things that have to be tracked, understood, and accounted for in your build and release process. So here you have feature branches, release branches, master, develop, a hotfix branch, and git tags. Take a look at this image and tell me it’s immediately intuitive: (source: ) GitFlow Is Complicated On its FaceĮven before you think about Microservices, or continuous delivery, gitflow is complicated. I can tell a few of you are unconvinced by this line of reasoning, so let’s dig deeper into why the gitflow branching model should die in a fire. I’ll claim it as a truism that not all strategies work in all situations, with all people, in all contexts, and I apply that same logic to this branching model. If you read the blog post, the author claims they successfully introduced it in their projects, but purposefully doesn’t talk about the project details that made it successful.Īnd for the rest of us, this is mistake #1 of trusting the blog post. In the last ten years, countless teams have been snookered by the headline and dare I say lied to.
Git-flow is a branching and merging methodology popularized by this blog post, entitled “A Successful Git branching model”.
0 kommentar(er)
