Don't Fear the Repo: Enhanced Git Flow Explained

Don't Fear the Repo: Enhanced Git Flow Explained

Enhanced Git Flow Explained - For example, if there’s a critical bug in production that needs to be fixed immediately. And deploying code without proper testing—whether the code is considered half-baked or well-defined—is clearly not an option. Inadvertently causing damage with Git can be all too easy. Yet, the best way to use Git will always be controversial. Let's keep the pros of Git flow, but simplify everyday ops!

Inadvertently causing damage with Git can be all too easy. Yet, the best way to use  Git will always be controversial.

That’s because Git itself only details basic branching operations, which leaves its usage patterns—i.e., branching models—a matter of user opinion. Git branching models promise to ease the pain by organizing the chaos that inevitably arises as software developers make changes to their codebases.

Like many developers, you wanted something that would “just work” so you could get on with actual software development. So you picked up Git flow, a branching model often recommended to Git users. Maybe you were on board with Git flow’s logic at first, until you hit some snags with it in practice. Or maybe Git flow doesn’t seem like a good enough fit for you to adopt it. After all, there are countless variables at play, and no single branching model will work well in every situation.

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.

The Splendor and Misery of the Classic Git Flow Model

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).

A significant value increment requires a significant amount of time to complete, like the two-week-plus sprints typically used in  Scrum-based development. 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.

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. In fact, it’s more than okay: This strategy allows the fastest pace of development without much ceremony. But things change in a production environment; then, real people start to rely on the product to be stable.

For 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. And deploying code without proper testing—whether the code is considered half-baked or well-developed—is clearly not an option.

That’s where branching models shine, including Git flow. 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.

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. It effectively solves a lot of headaches from the development workflows of release-based products.

But even with projects well-suited to the classic Git flow model, I’ve suffered the typical problems it can bring:

  • Git flow is complex, with two long-lived branches, three types of temporary branches, and strict rules on how branches deal with each other. Such complexity makes mistakes more likely and increases the effort required to fix them.
  • Release and hotfix branches require “double merging”—once into main, then into develop. At times you can forget to do both. You can make Git flow branching easier with scripts or VCS GUI client plugins, but you have to set them up first for every machine of every developer involved in a given project.
  • In CI/CD workflows, you usually end up with two final builds for a release—one from the latest commit of the release branch itself and another one from the merge commit to main. Strictly speaking, you should use the one from the main, but the two are usually identical, creating the potential for confusion.

git

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Best Practices for Using Git

Git has become ubiquitous as the preferred version control system (VCS) used by developers. Using Git adds immense value especially for engineering teams where several developers work together since it becomes critical to have a system of integrating everyone's code reliably.

7 Best Practices in GIT for Your Code Quality

Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Check out 7 best practices for Git.There is no doubt that Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Still, developers struggle for code quality.

Git Commands You Can Use To Dig Through Your Git History

Git Commands You Can Use To Dig Through Your Git History. In this short article, we’ll be exploring some quick git commands that can help us in digging through our repositories’ history of commits.

Git Rebase Tutorial and Comparison with Git Merge

In this article, I will explain to you a few differences between git merge, git rebase, and the git interactive rebase.I will tell a bit about what pros...

Mirroring Git Changes From One Server to Another Server

Hello all, nowadays most of the development teams using GIT version control, some of you may have a requirement of mirroring your team's git changes from one server to another Git server. This article will help you to achieve the Git mirroring between one server to another server.