Version Control #

Control Code: KBC1

TLDR: Every change to the source is tracked in a version control system

Rationale: Version control allows us to track and manage changes to our software code. As a traceability system, it provides a means to understand how our software changes, who changes it, and why it was changed.

Background #

We use git to manage versioning for software development source code. For repository hosting and user management we use github.

How we implement this control #

Our git repositories can be found here: https://github.com/kosli-dev

Branching Strategies #

Every service will follow one of the following branching strategies:

Feature Branch + Pull Request, or:
Production Branches

These are described below.

1. Feature Branch + Pull Request #

This branching strategy uses a combination of feature branches with pull requests.

Main branch is protected
Pull requests must be approved before merge to the main branch.
We use pull requests to enforce and document our code review process. You can read more about it here: Code Review Process
Pull request merges should create merge or squash commits. (no fast-forward)

Merges to the main should either be merge commits or squash commits… i.e. no fast-forward merges. This allows us to atomically back out merges should we need to.

2. Production Deployment Branch #

The Production Deployment branch is an alternative to the feature-branch/pull-request strategy.

This allows a model similar to trunk-based-development, where code reviews are implemented in the merge to production.

Production branch is protected
Pull requests must be approved before merge to production.
We use pull requests to enforce and document our code review process. You can read more about it here: Code Review Process
Pull request merges will fast-forward. This means the production branch will always “point” to a commit on the main branch

Protected Deployment Branches #

To ensure compliance to the code review process, we protect the branch we deploy from (main or production) with the following requirements:

Merges require at least one approval (two if the strategy is Production Deployment Branch)
Builds and tests run successfully
No unresolved merge checks