GitFlow: Branching model – Solution to merge branches

What Is GitFlow?

GitFlow is suitable for collaboration and scaling of the development team. The GitFlow toolset is actually a command line tool that has an installation process. It lets you decide the kind of branches we need to set up and merge. The installation has packages for various operating systems GitFlow, it lets you execute the project on windows. Git flow works on macOS, Linux, and Windows operating systems.

GitFlow is a branching model and solution to merge branches using init command, which is an extension of git init command. It changes nothing in the repository while creating branches.

GitFlow Workflow:

It is a strict branching model around the project release that offers a robust framework for managing huge projects. It is suitable for the scheduled release cycle to assign a specific role to different branches and define how and when they should interact. Individually the branches used by the GitFlow to maintain and record the releases allows in isolated experiments for efficient collaboration.

Benefits of GitFlow:

  1. Parallel Development: GitFLow makes isolated new development and parallel development easy. The branches formed are useful to develop new features or fix urgent bugs. The finished work is ready to release and the code can merge to the main code.  
  2. Collaboration: A feature branch helps developers to work as a team. Just like the sandbox where only the changes for the proper functioning of that new feature are stored. We can track and follow each collaborator’s contribution.
  3. Release Staging Area: The entire ready to release features are in the staging area. These tested features are then merged in the main development branch so that the new pending tasks for development are populated.
  4. Urgent Fixes: GitFlow supports the branches of hot fixes and ensures that you do now merge it to the new development happening simultaneously.
  5. Switching Branches:  Working in multiple branches for some changes that are immediately needed and or switching when you need to go back to the original feature branch to continue the development.

How to develop branches and master branch?

GitFlow uses two branches to record the project history instead of storing in a single master branch. Versioning of the master branches helps in integration. Initially, a developer creates an empty branch locally and pushes it to the server.

  1. Git branch develop
  2. Git push -up origin develop

The branch cannot enclose completely history of the project but the master can contain an abridged version. This history allows other developers to clone the central repository and track the development of the branch.

Executing GitFlow init on the existing repository will create the develop branch using the extension library. There will not be any base branches or branches for production releases i.e. master and develop for the next release.

The supporting branch can be named using prefixes. The feature branches can be named *feature, the develop can be * develop and add the version tag.

  1. Feature Branches:  All new features should dwell in its own branch and we should be able to push it to the central repository for the collaboration and backup. Rather than branching off the master, feature branches uses develop as its parent branch. On completion of a feature we can merge it back into develop. Due care should be taken that the features do not interact with the master directly. The feature branches and develop branch together are meant for all purposes but the GitFlow covers a lot more than feature branches. Feature branching makes it easy to work on a particular feature without disturbing the main code base.
  • Release Branches: A bunchof ready to release features that have a predetermined release date is a release branch. As and when this branch starts the next release cycle, you cannot add any new features but you can add the bug fixes, documentations and other tasks pertaining to the release. Once the features are ready and released, the release branch gets merged into a master and a version number is assigned. One team can improve on the current release and another can work on features in the pipeline for next release. The release branches depend on the develop branches. Release branches reviews code easily.
  • Hotfix Branches: These branches contain the patch releases of the production. The hotfix branches are different from release branches, they are based on the master, and not develop. Once the fix is complete merge into both master and develop or the current release branch. The master can be updated with a version number.
  • Central repositories: Hosted central repositories are created through the GIT hosting services. After the initial process, the bare repository is handled by the hosting service. It provides an address for the central repository to access from the local repository. Cloning of the central repository lets the developers work separately on the entire project and GitFLow adds the shortcut to the parent repository. This cloned repository has a standard commit process for editing, staging and committing. Local repositories allow developers to repeat the process multiple times without making changes to the central repository. Huge requirements divided into small chunks or assigned for development feature-wise make the work process efficient.
  • Manage conflicts: The committed changes pushed to share with other developers may contain code that conflicts the code and updates. The central repository’s commit history is irreversible. If the committed changes of a developer deviate from the central repository GitFlow will refuse to push their changes. Before, publishing the feature a developer needs to fetch the updated central commits to overwrite their change on the top of other changes. In conflicting situation, the Git will pause the rebasing process and permit you to resolve the clashes. If they cannot solve the issues, the developers can opt to abort the entire set of pushed changes. Each developer needs to publish their local commits to the central repository for the other members to access the code and changes; this is done with the git push command. In case of conflicts, the Git displays errors and provides hints to correct the release. If in case you need to rollback the changes, it leaves the minimal impact on the project. The short-lived branches separate the production branch and promote cleaner merge and deployments.

The centralized workflow is suitable for small teams as the conflict resolution can be troublesome and pile up work for the big teams. Git tags branch a versioning helps to keep track of development release cycle. Keep the Git workflow simple to enhance the productivity of your team.

Related Posts

Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.