Git has turned out to be one of the leading Version Control System in today’s time. Git is used to store the source code and work collaboratively with the team. This blog explains how to efficiently use Git and plan for project releases.
What is Git?
Git is a distributed version control system that is used to store the source code in software development to track its changes. It facilitates the developers to work collaboratively with teams on repositories to manage the codebase versions i.e., maintaining the history of project modifications.
Key Points:
- Stores source code of the applications.
- Shares the code with the team to work collaboratively.
- Maintains the history of the changes with details.
- Organized approach to the software development.
Understanding Git Branching
In the world of Git, a branch symbolizes a collection of code alterations that have deviated from the code base. The main purpose of branches in Git is to separate and manage development efforts.
Git Flow
The development process begins by establishing branches for each feature. These individual branches are later combined with the integration branch, followed by the release branch, for fine tuning and ultimately merged into the prod branch, for production deployment. If any fixes are required, they are directly merged into the branch as hotfixes with an approval for the pull request. Then reintegrated with the development branch.
Development (dev) Branch
- The development (dev) branch is the starting point for any project. The dev branch is very important, and it should be protected against accidental deletion until the project is in a better defined state.
- The dev branch serves for integrating different features planned for an upcoming release. This branch may or may not be stable, as the developers collaborate and merge feature branches.
- Only authorized leads or project owners should be given responsibility to merge the changes from other branches to dev branch
Feature Branch
- Any new feature development needs to be conducted within a feature branch.
- This branch merges back to the dev branch after the completion of the feature.
- After the feature is fully developed and functional, it should be deleted.
- The conventional naming of this branch is as below:
- “feature/{TICKET_ID}”
Release Branch
- The release branch is also derived from the dev branch, but it is used during releases for QA, Staging and UAT.
- Any releases of developed features will be conducted within a release branch.
- QA, Staging and UAT deployment should be done from the release branch.
- After the release approved to deploy to the production, it should be merged to the production branch with a release tag and deleted.
- The conventional naming of this branch is as below:
- “release/{RELEASE_VERSION}”
Bugfix Branch
- The bugfix branch is derived from the dev branch.
- The bugfix branch is used to fix any bugs reported by testers in the development and QA environments.
- After the bugs are fixed in the bugfix branch, it should be merged back to the dev branch and deleted.
- The conventional naming of this branch is as below:
- “bugfix/{TICKET_ID}”
Hotfix Branch
- The hotfix branch is derived from the release branch.
- The hotfix branch is used to fix a bug reported in the UAT and production environments.
- After the bugs are fixed in the hotfix branch, it should be merged back to the release branch and dev branch and then it should be deleted.
- Once the hotfix branch is merged into release branch, the bugfix branch should be deleted.
- The conventional naming of this branch is as below:
- “hotfix/{TICKET_ID}”
Production (prod) Branch
- The prod branch is a highly stable branch that is always production-ready and contains the last release version of source code in the production environment.
- This branch is very important, and it should be protected against accidental deletion irrespective of any state of the code.
- Only authorized leads or project owners should be given responsibility to merge the changes from other branches to dev branch
- The conventional naming of this branch is as below:
- “release/prod”
How to plan for release strategies
Core Git branching strategies for release management
Choosing the Git branching strategy depends on important factors. Firstly, consider the size of the team; smaller teams may find it easier to manage their workflow using the simplicity of GitHub Flow while larger teams could benefit from the approach provided by Git Flow. The complexity of the project is also an aspect to consider; if the project involves features that are interdependent, Git Flow or GitLab Flow might be more suitable due to their comprehensive structure. Additionally, deployment frequency is another factor to consider; for those who require continuous deployment the streamlined process offered by GitHub Flow can be advantageous.
Examples: As an example of a startup that is working on a web application and frequently needs to make updates. In this case using GitHub Flow would be beneficial as it allows for iterations and continuous delivery. On the other hand, if it considers an enterprise, with a complex software ecosystem they might prefer using Trunk-based or Git Flow. These methodologies provide an approach to managing development streams and release stages. It’s important to adapt these strategies based on the team’s workflow communication patterns and project requirements to improve efficiency and clarity, throughout the development process.
Why use Git?
Since the development and release of Git, it has gained huge popularity among the developers and being open source have incorporated many features
Benefits of using Git
- Performance: Git provides the best performance when it comes to version control systems. Committing, branching, merging all are optimized for a better performance than other systems.
- Security: Git handles your security with cryptographic method SHA-1. The algorithm manages your versions, files, and directory securely so that your work is not corrupted.
- Branching Model: Git has a different branching model than the other VCS. Git branching model lets you have multiple local branches which are independent of each other. Having this also enables you to have friction-less context switching (switch back and forth to new commit, code and back), role-based code (a branch that always goes to production, another to testing etc) and disposable experimentation (try something out, if does not work, delete it without any loss of code).
- Staging Area: Git has an intermediate stage called “index” or “staging area” where commits can be formatted and modified before completing the commit.
- Distributed: Git is distributed in nature. Distributed means that the repository or the complete code base is mirrored onto the developer’s system so that he can work on it only.
- Open Source: This is a very important feature of any software present today. Being open source invites the developers from all over the world to contribute to the software and make it more and more powerful through features and additional plugins. This has led the Linux kernel to be a software of about 15 million lines of code.
Best Practices in Release Management with Git
In the realm of Git based release management it is crucial to prioritize the stability of the production branch. This involves implementing strategies that ensure hotfixes and emergency changes are thoroughly tested before being merged. The integration of Continuous Integration/Continuous Delivery (CI/CD) pipelines plays a role in simplifying the release process, automating testing and facilitating deployments. Regardless of the branching strategy employed, having a testing and Quality Assurance (QA) framework is essential. For example, in Git Flow feature branches must undergo testing before being merged into the develop branch. On the other hand, in GitHub Flow every change made in a feature branch needs to be ready for production, after review highlighting the significance of an efficient and comprehensive testing system.
Having a defined approach to releasing software using Git branching is crucial for managing software development processes. It helps to streamline workflows, enhance stability, and improve efficiency throughout the release cycle. However, it’s essential to understand that there isn’t a solution that fits all scenarios. The strategies should be. Continuously refined based on factors, like team size, project requirements, and real-world experiences. By embracing adaptability and learning from each release it can establish a more efficient development process that caters to the challenges of the projects.
As for now, we have understood that Git is a more powerful and widely used version control systems. To summarize, the main branching model is outlined here:
- There are six branches in origin: dev, feature, release, prod, bugfix and hotfix.
- Normal development happens on the dev branch. All new features are merged in the dev branch.
- Features that are being developed are put behind the feature branches
- Release branch is cut from the dev branch.
- Any bugs found in release branch are fixed in hotfix branch and then merged in both release and dev branch
- When the release branch is ready for production deployment, it is merged in the prod branch with the appropriate tags.
