You are here:

Home
Git
Gitflow

Estimated reading time: 3 min

In this article

Git Flow is a branching model, which proposes a branching strategy and generations of product versions using a git repository.

¿What is Git?

Git is a version control system of a project, software that allows to record all history of changes that are made in the project(VCS).

Terminology

Repository.-It’s all a project followed by git.

Commit.- It’s each of the changes recorded in the git history. Each one of the developers send commits of the changes they have made.

Branches.- New paths that the project takes, in git everything is worked by branches. There is a branch that is the main one that is usually called master where the project that goes to the public is; Every time you want to work on a new feature or correct something, a branch is removed, so that you can work in an isolated environment so that if something breaks you do not commit to the project and if everything goes well that branch is re-unify with the main project and if something goes wrong you can delete the branch if no problem.

Clon.- It is an exact copy of the repository. When a programmer joins a work team, the first thing is to clone the repository on his local computer. Each of the developers has a local disk repository clone.

Features

Distributed.-You do not need to connect to a central server or internet connection to work, each developer has a copy of the project in case something happens.

Branches and mergers.- Branches that make their way back to the main branch.

Data integrity-There is total security that each one of the developers has the same data as the others.

Tools to working with git

Terminal or command line

You cannot learn git with a graphical interface, git is handled using commands, later you can speed up the work with graphical clients such as gitkraken, sourcetree or github desktop.

Cloud repositories

These repositories are branches called “remote branches”, example: the local branch is called master and the remote one is called origin. They are tools that allow us to distribute our project anywhere in the world.

WORKFLOW.

A Git workflow is a formula or recommendation for using Git to get work done consistently and productively. Git workflows encourage users to take advantage of Git efficiently and stably.

Git Flow

Git flow, which as its name suggests, is a workflow applied to a Git repository. Vincent Driessen was in charge of popularizing, defining a strict branching model designed around the project launches. It is ideal for projects that have iterative release planning. It allows the parallelization of the development through independent branches for the preparation, maintenance and publication of project versions as well as supports the repair of errors at any time.

Main branches

Master & Develop

We consider origin / master to be the main branch where HEAD source code always reflects a production-ready state.

We consider origin / development what is the main branch where the HEAD source code always reflects a state with the latest development changes delivered for the next version.

Start Git Flow with Plugin, with default configuration:

git flow init -d

Support branches

Unlike the main branches (master and develop), these are limited in time. They will be removed eventually. The different types of branches that will be used are:

Feature
Release
Hotfix

Feature branches

These branches have to arise from the develop branch. Each of these branches store development code with new features. Typically they exist only in the developers’ local repositories and not in the source repository. Once their development is complete, they will be incorporated back into the develop branch, which will contain the latest version of code under development.

Naming convention: These branches can be named in any way except master, develop, release- *, or hotfix- *.

See Git Feature Branch Plugin Commands

See Git Feature Branch Standar commands

Release branches

Like feature branches, release branches also have to emerge from the develop branch. They contain the code for the version to be released soon. It is a preliminary and preparatory step for the final production version. It includes all the develop code required for the release. It may contain a small bug that needs to be fixed at this time so it is not included in production. After the branch is complete, it must be included in both the develop branch and the master branch.

Naming convention: they must follow the following convention: release- *, replacing the * with the version number (1.1, 2.3, 4.7, etc)

We must first update the master branch. Next, we need to save those changes to the develop branch. Once the branch is integrated in both master and develop, we will delete the branch in the local repository.

See Git Release Branch Plugin commands

See Git Release Branch Standar commands

Hotfix branches

These branches arise from the master branch. They contain a production version with a bug that you want to urgently fix. After the bug is fixed, the contents of this branch are included in the master and develop branches to fix the bug. Also, you have to mark the fixed production version with a tag in the master branch.

Naming convention: they must follow the following convention: hotfix- *, replacing the * with the revision number (1.1.5, 2.3.1, 4.7.9, etc)

First we must update the master branch and tag it. Next we must include the hotfix in develop as well. Once the branch is integrated in both master and develop, we will delete the branch in the local repository.

See Git Hotfix Branches Plugin commands

See Git Hotfix Branches Standar commands