Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
: Historical Background Back on July 22 2017, this style guide for Git was created that also included the compliance with Git Flow [1]. Generally this branching model is really dynamic and can help a larger team to keep the overview of different story implementations while being able to build and deploy version backports. Using `develop` as the main branch also helps to make sure the `master` branch always contains stable versions. Anyway, the model also comes with disadvantages like the overhead of keeping both `develop` and `master` in sync when tagging a new release version. The main target groups for this model are larger teams that work on projects with legacy support. I've adapted Git Flow because I liked the idea of having one branch that reflects the actual development state, but after using it for over 6 years I don't see any advantages in it anymore compared to other great models like GitHub Flow [2]. I've checked the original Git Flow blog post of Vincent Driessen again and was amazed that he recently (March 5, 2020) added an update at the top of the post that exactly matches my opinion regarding the fact that Git Flow is not suitable these days, comes with too much overhead and that he now recommends to use GitHub Flow instead: > Note of reflection (March 5, 2020) > > This model was conceived in 2010, now more than 10 years ago, and not > very long after Git itself came into being. In those 10 years, > git-flow (the branching model laid out in this article) has become > hugely popular in many a software team to the point where people have > started treating it like a standard of sorts — but unfortunately also > as a dogma or panacea. > > During those 10 years, Git itself has taken the world by a storm, > and the most popular type of software that is being developed with Git > is shifting more towards web apps — at least in my filter bubble. Web > apps are typically continuously delivered, not rolled back, and you > don't have to support multiple versions of the software running in the > wild. > > This is not the class of software that I had in mind when I wrote the > blog post 10 years ago. If your team is doing continuous delivery of > software, I would suggest to adopt a much simpler workflow (like > GitHub flow) instead of trying to shoehorn git-flow into your team. > > If, however, you are building software that is explicitly versioned, > or if you need to support multiple versions of your software in the > wild, then git-flow may still be as good of a fit to your team as it > has been to people in the last 10 years. In that case, please read on. > > To conclude, always remember that panaceas don't exist. Consider your > own context. Don't be hating. Decide for yourself. This update perfectly reflects the way I thought about the Git Flow model quite a while now. Therefore I've finally decided to switch to GitHub Flow and retire the good old `develop` in favor of `master` as the one and only single-source-of-truth™️. : Migration Tasks Since all Arctic Ice Studio projects adhere to this guide each repository must gradually adapt to this change one after the other. Large projects like Nord [3] with all of it's port projects [4] will require a lot more time and effort to migrate regarding the goal and tooling compatibility of the actual project. Smaller projects like my igloo [5] dotfile repository, snowsaw [6] as well as this style guide repository itself are way easier and can be done within the next few weeks. [1]: https://nvie.com/posts/a-successful-git-branching-model [2]: https://guides.github.com/introduction/flow [3]: https://www.nordtheme.com [4]: https://www.nordtheme.com/ports [5]: https://github.com/arcticicestudio/igloo [6]: https://github.com/arcticicestudio/snowsaw GH-9
- Loading branch information
1 parent
3de2eeb
commit 05e3fae