Skip to content

Git workflow

Git workflow, zwany też Gitflow to sposób na usystematyzowanie pracy w projekcie opartym o Git.


This process is excellently described on the Bitbucket documentation page and is a universal approach to teamwork, in addition, perfectly suited to CI/ CD. The link mentioned above indicates the use of git flow commands, but all the above-mentioned actions and the approach itself do not require installing any Git add-ons.


Workflow in Riupress does not use the git flow recommendation, because the use of github actions and semantic release automates version numbering and partially the developers' work process with git.


Below is a figure illustrating the git flow approach.

An image

You can include the following information:

  • everything starts from the main branch, which is identical to the production environment;
  • merge to the main branch triggers the creation of a production release;
  • the main branch creates the develop branch, which is identical to the development environment;
  • the develop branch creates the release release branch, which is identical to the uat environment, and the feature branch where changes are simply introduced;
  • from the develop and release branches you can also use the bug branch in case of non-critical errors;
  • if a bug occurs in the production environment, then from the main branch we create a hotfix branch, which after making corrections is merged with main, these changes should then be merged with the develop branch;
  • after merging the release branch into main, the first one is removed and the second one is merged into develop, which updates the version number to develop;

Additional assumptions

It should be assumed that:

  • in the simplest approach to using the above work system, we do not have to release the prerelease type, but if they were to appear, they would be created when creating the release branch;
  • the names of the release, feature, bug and hotfix branches will be expanded and an additional element describing the branch, e.g. feature/<id-issue-title>;
  • we always create a branch from a created ticket by clicking Create a branch in the Development section in the right column on the page of the created ticket;


Creating branches from systematized tickets is important because it is easier to understand the scope of work performed during a review

Git Feature Branch Workflow

An alternative to the above is an approach in which we do not have a develop branch, but only a main branch from which feature or hotfix branches are created. In this way, we keep the main branch almost always up to date, but with this assumption, versioning is based on merging to main, which results in a rapid increase in numbering in a project with a large number of changes.