Get started with Git

Photo by Emma Frances Logan on Unsplash
$ git status
On branch master
No commits yetnothing to commit
  • Regular branches (or main branches): these branches are available permanently in the repository, the naming convention of regular branches is easy and straightforward, we can mention master and develop.
  • Temporary branches (or support branches): these branches are created by team members and they serve a purpose and once purpose fulfilled they can be deleted, we can mention featureand hotfix.

Main branches

At the core, the main branches are:

  • master: the master branch is the origin, and we consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
  • develop: We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the integration branch.

Supporting branches

Next to the main branches, the Gitflow model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases, and to assist in quickly fixing live production problems.

May branch off from: develop
Must merge back into: develop
Branch naming convention: anything except master, develop, release-*, or hotfix-*
May branch off from: develop
Must merge back into: develop and master
Branch naming convention: release-*
May branch off from: master
Must merge back into: develop and master
Branch naming convention: hotfix-*

Adapting Gitflow to the deployment environment

We generally have three deployment environments where the project is deployed and executed: development (recette or r7 in French), pre-production, and production tier. The correspondence of Gitflow with these environments is as follow:

  • Development: this is the environment in which the developers get to test and see their code running altogether, that’s why use the develop branch.
  • Pre-production: this environment presents the before-production state in which we have a stable tested version of the application, so for this environment, we use one of the release branches.
  • Production: this is also the client environment, is the recent stable version of the application and we only upload make changes in the final phase of the development of a feature or features. We use the master branch for this environment.

Naming conversions of supporting branches

There are multiple choices of naming that can be used to name the supporting branches, it can be hyphens, slashes, or underscores to separate words, we can use dates or issue trackers ID. To have a consensus we created the following rules:

  • We separate the branch’s name from the rest of the naming with a slash (hotfix/, feature/, release/).
  • In the case of features branches, we add the scope of the feature right after the slash for example feature/authentification.
  • In the case of issue tracker software (like mantis), we can add the ID of the issue to the name of the branches of feature or hotfix, for example, hotfix/mantis.7589.
  • We can also use the date as a reference to the release branches as release/YYYY.MM.DD if we have multiple consecutive versions.

The perfect commit

A commit message can greatly help developers track and understand the commits. It can save a lot of time if written well. The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.

<type>[optional scope]: <description>
  • build: when changes affect the system of build or external dependencies (npm, make, pip … ).
  • ci: when changes concern files and scripts of the continuous integration (Travis, Ansible …).
  • feat: when new functionality is being added.
  • fix: when a bug is being fixed.
  • perf: when performances are being improved.
  • style: changes that improve the code by add no functional or semantic improvement (indentation, spaces, names of variables, comments …).
  • docs: the changes in the documentation of the code (wiki, README …).
  • test: the add or change of tests of the code.

Bonus: Git commands cheat sheet

In this paragraph, we list some of the most used Git commands




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aicha Fatrah

Aicha Fatrah

Software Engineer | Technical Writer | IT Enthusiast