Git commit workflow

Git commit workflow for crypto-sdcard

Pull requests                                                           Release branch specific PRs
         │                                                                                       │
         │                                                                                       │

         │                                       ┌─►sfos220+qcrypto◄─┤

         │                                       ├─►sfos321+qcrypto◄─┤

         │         ┌─►qcrypto─┴─►sfos340+qcrypto◄─┤

         │         ├─────────-►sfos220◄─────┤

         ▼         ├─────────-►sfos321◄─────┤

     master─┼─────────-►sfos340◄─────┤

                      └─────────-►sfos401◄─────┘

All "horizontal" pull requests (i.e., from devel to master and from master to the release branches) must be regular merge commits. Do not perform "squash merge"-commits "horizontally", even though they are feasible for PRs comprising a single commit and look slightly nicer in the commit log than a regular merge commit, but "squash merges" might be harder to revert. Hence stubbornly always performing merge commits "horizontally" is the rule of thumb.
Release branch specific commits (i.e., pull requests which are directed at a git branch out of {sfos3.2,sfos3.3,sfos4.2}), should be "squash merge"-commits; regular merge commits may be deliberately used in select cases for these branches.

Note that above diagram also tries to depict that the sfos3.3 branch should not contain branch-specific commits (except for the uncommented dependencies on SailfishOS release versions) compared to master or devel (i.e., these are just temporal stages), in contrast to the sfos3.2- and sfos4.2-branches, which do differ by code and configuration specifically for the SailfishOS releases they support. For details see the Wiki page "Differences between git branches".

Also note that the basic idea is to accumulate pull requests (PRs) merged into the devel branch, move them in tranches (i.e., from time to time) into the master branch (which is subjected to different CI builds for quality assurance, see below). When preparing for a release, PRs are posed from the master branch to the release branches, so the CI for these PRs runs the actual code which would be released when these PRs are merged.

The CI and release building is described at its own Wiki page.