Skip to content

Git workflow for the development of an MVP

This diagram illustrates the Git workflow for the project, showing the different branches, their relationships and key release points, as well as the issues encountered. It also explains how this workflow relates to the development of a Minimum Viable Product (MVP).

Important

This diagram represents a common and effective Git workflow for MVP development.

You can adapt it to your specific needs and those of your team.

Workflow for the development of MVPs

Development of MVP features

  1. Feature branches are created from “develop” to develop the essential functionalities of the MVP.
  2. Commits are performed on the feature branches to register the changes.
  3. Feature branches are merged into “develop” once completed and tested.

MVP Launch

  1. A release branch is created from “develop” to prepare the first version of the MVP.
  2. Tests and adjustments are performed on the release branch.
  3. The release branch is merged into “master” and labeled with the corresponding version (e.g. v1.0.0).

Iteration and evolution of the MVP

  1. New feature branches are created to develop additional functionalities or improve the existing ones.
  2. Steps 1 and 2 are repeated to release new versions of the MVP with updated functionalities.

Correction of errors:

  1. If errors are found in the MVP, hotfix branches are created from master to correct them.
  2. The “hotfix” branches are merged into “master” and tagged with a new version (e.g. v1.0.1).

Git Workflow Case

The diagram shows an example of how the development of an MVP could be managed with Git:

MVP 1

  1. The feature/ci/cd-files branch (which includes CI/CD configuration) is merged into develop.
  2. The release/v1.0.0.0 branch is created from develop, tests are performed and MVP 1 (v1.0.0.0 tag) is released.

MVP 2

  1. The feature/first-release branch (which adds features for the first release) is merged into develop.
  2. The release/v1.1.0 branch is created from develop, tests are performed and MVP 2 is released (labeled v1.1.0).

Incidence and correction

  1. An issue is detected in MVP 2.
  2. A hotfix branch is created from master to correct the error.
  3. The hotfix branch is merged into master (v1.1.1 tag) and included in the next release of develop.

MVP 3

  1. The release/v1.2.0 branch is created from develop and MVP 3 is released (v1.2.0 tag).

Launch aborted

  1. Critical issues are detected in the release/v1.2.0-rc2 branch.
  2. The release is aborted and corrective actions are taken.

Benefits of using Git

  • Facilitates experimentation and rapid iteration.
  • Allows you to manage different versions of the MVP with ease.
  • Facilitates collaboration between developers.
  • Allows to easily revert changes if necessary.

Additional notes

  • The diagram shows an example of a release abort, which can occur if critical problems are encountered during the release process.
  • The diagram also shows examples of commits labeled “ci/cd files” and “first release”, suggesting that these commits are related to the Continuous Integration/Continuous Delivery (CI/CD) configuration and the first release of the project, respectively.

Additional Resources