GitHub Flow migration #10
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
: 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
svengreb
approved these changes
Apr 7, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #9