The Git flow process addresses these fundamental scenarios by separating “main” (the production or “current version” branch) and “develop” (the development or “next release” branch) and providing all the rules about using feature/release/hotfix branches. Any sophisticated branching model should answer questions regarding how to isolate the next release from the version of the system currently used by people, how to update that version with the next release, and how to introduce hotfixes of any critical bugs to the current version. That’s where branching models shine, including Git flow. And deploying code without proper testing-whether the code is considered half-baked or well-developed-is clearly not an option. But things change in a production environment then, real people start to rely on the product to be stable.įor example, if there’s a critical bug in production that needs to be fixed immediately, it would be a major disaster for the development team to have to roll back all the work accrued in the main branch thus far just to deploy the fix. In fact, it’s more than okay: This strategy allows the fastest pace of development without much ceremony. While the product is still in the initial development phase-i.e., there’s no production and there are no real users of the product-it’s okay for the team to simply keep everything inside the main branch. If a development team has already deployed to production, there may be trouble if the scope of the next release accumulates at the same place where production code lives-e.g., in the main branch of the Git repo they use. I’ve been a strong advocate of Git flow ever since I discovered how it excels when developing a product that evolves in significant value increments (in other words, releases).Ī significant value increment requires a significant amount of time to complete, like the two-week-plus sprints typically used in Scrum-based development. The Splendor and Misery of the Classic Git Flow Model Good news! A variation of the classic Git flow model, enhanced Git flow simplifies the more common maneuvers of the Git flow workflow while still retaining the main advantages. After all, there are countless variables at play, and no single branching model will work well in every situation. Or maybe Git flow doesn’t seem like a good enough fit for you to adopt it. Maybe you were on board with Git flow’s logic at first, until you hit some snags with it in practice. So you picked up Git flow, a branching model often recommended to Git users. Like many developers, you wanted something that would “just work” so you could get on with actual software development. Git branching models promise to ease the pain by organizing the chaos that inevitably arises as software developers make changes to their codebases. That’s because Git itself only details basic branching operations, which leaves its usage patterns-i.e., branching models-a matter of user opinion. Yet, the best way to use Git will always be controversial. Inadvertently causing damage with Git can be all too easy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |