Git commit workflow

Git commit workflow for crypto-sdcard

Pull requests (PRs)                                                      Release branch specific PRs
         │                                                                                       │   │   │
         │                                                                                       │   │   │

         │                                       ┌─►sfos220+qcrypto◄─┤   │   │

         │                                       ├─►sfos321+qcrypto◄-─⌽─┤   │

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

         │         ├─────────−►sfos220◄─────┘   │   │

         ▼         ├─────────−►sfos321◄───────┘   │

     master─┼─────────−►sfos340                                   │

                      └─────────−►sfos401◄−────────┘

All "horizontal" pull requests (i.e., from master to qcrypto and from either master to the regular release branches or from qcrypto to the +qcrypto 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 {sfos220*,sfos321*,sfos401}), 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 two sfos340-branches should not contain branch-specific commits (except for the uncommented dependencies on SailfishOS release versions) compared to master respectively qcrypto (i.e., these are just temporal stages), in contrast to the sfos220*-, sfos321*- and sfos401-branches, which do differ by code and configuration specifically for the SailfishOS releases they support.

Also note that the basic idea is to accumulate pull requests (PRs) merged into the master branch, move them in tranches (i.e., from time to time) into both, the qcrypto branch and then further to the sfos???+qcrypto release branches, plus directly into the regular release branches sfos???.