Git Workflow

Preface

There won't be a detailed discussion about the pros and cons of different approaches to working with Git here.

But Git workflow directly impacts your options when working with CI.
So this section will outline decisions that have been made for this project and the thought process behind them.

This should help you better understand how everything ties together and make your own decisions, based on your needs and priorities.

Overview

Branches

1. Master

   • All the code here should be stable, but the only production-stable points are version tags.
   • All the other branches should start from master.
   • The only changes that can be committed straight into master are the ones pertaining to project documentation (e.g. License, Readme).

2. Feature

   • Start from master; used to introduce any features, updates, fixes etc.
   • No mandatory naming convention, although it's usually recommended to start with your initials and continue with a descriptive name (e.g. ac/fix-play-publishing).
   • Always create a pull request; after the review, merge the branch into master and delete it.

3. Release

   • Start from master; used to signify that a new release will be created once this branch is merged into master (read "a new version tag will be created").
   • Must follow a release-X.X.X naming convention.
   • Here you will set your new versionName property and other release-related things like the changelog for Google Play etc.
   • If you find that you need to fix something before the release, you should do this in a usual feature branch.
     Afterwards, rebase release onto master to incorporate new fixes, and merge+delete as you would normally do.

4. Version Tag

   This is obviously not a branch but still an essential part of the flow.

   • Created every time release branch is merged into master.
   • Must follow a vX.X.X naming convention.
   • Signifies an existence of a release with this tag's name, and a point of the production-stable state of code.

Origin

This model is a combination of the Git Flow and GitHub flow.

Notes:

• Develop and hotfix branches are not used for the sake of simplicity.
• Release branches are used to allow running additional pre-release checks on CI.
  These are the checks that we can allow to trade-off for faster iteration by not running them on other branches.

CI integration

To learn which CI jobs are run for each of the branches/tags in detail, read the CI guide.