🦥 Git Branch Strategy

🦥 Git Branch Strategy

🦥 Git Branch Strategy is a strategy or a convention over a git and GitHub across a team directly involved in developing an application.

Git Branch Strategy is critical in a project that involves more than a single person following the overhead that could incur from understanding individual approaches and methodologies on communal git and GitHub branches and commits.

It appears that there are two common git branch strategies:

• 🐱 GitHub Flow
• 🐙 Git Flow

where the above strategies will be discussed in the following sections.

🐱 GitHub Flow

🐱 GitHub Flow is a strategy strictly suggested by GitHub from its official document.

GitHub Flow simply and largely works upon a single main branch, the main (master) branch, and various sub-branches can be created upon demands, including developing features, bug fixes, and etc.

---

👨‍💻 Process

Overall processes of GitHub Flow can be described below:

1. Create a Branch
2. Make Changes
3. Create a PR (Pull Request)
4. Address Reviews & Comments
5. Merge Branches
6. Delete Branches

---

🧐 Cost-Benefit Analysis

GitHub Flow can offer the following advantages:

• Consistent CI/CD followed by its simplicity.

  • hence suitable for small projects

As the trade-off to the above, the following challenges could occur:

• Unable to support multiple versions of code in production simultaneously.

• The lack of dedicated development branches.

  • leading GitHub Flow to be bug-prone

---

🐙 Git Flow

🐙 Git Flow is a strategy suggested by software developer Vincent Driessen in 2010 where Git Flow divides workflows into varying types of git branches.

Git Flow aims to simplify the overall release process and further address issues that were unable to be addressed in the above GitHub Flow strategy.

Git Flow introduces the following git branches as its functioning core:

• Main
• Develop
• Feature
• Release
• Hotfix

where the main and develop branches become the primary branches that persist over all git branch life-cycle and other feature, release, and hotfix branches in accordance to demands becomes created and removed.

---

👨‍💻 Process

There are no sequential processes within the Git Flow strategy. However, each branch has varying innate purposes where:

• Main

  • contains commit history of publicly released versions.

• Develop

  • responsible for storing all changes to the features.

• Feature

  • responsible for developing features
  • branches out from the develop branch
  • the changes updated to the develop branch

• Release

  • responsible for QA
  • branches out from the develop branch
  • the changes updated to the main branch

• Hotfix

  • responsible for urgent bug fixes after the release from the main branch
  • the changes updated to the main branch

---

🧐 Cost-Benefit Analysis

The Benefits of Git Flow can be summarised as below:

• Various types of branches enable work organisation to be more intuitive.

• Allows efficient testing over small branches.

• Supports multiple production code versions.

The Challenges of Git Flow are:

• Can overcomplicate and slow the development process and release cycle.

• Due to the long development cycle, Not suitable for CI/CD.

---

📚 References

GitHub
GitKraken