Design and implement a source control strategy

2.1 Branching strategies for the source code

Choosing a branch strategy

Trunk-based development

Everyone integrates into main at least daily. Branches, if used at all, live for hours.

• Feature flags are mandatory — they are what makes it safe to merge incomplete work into a branch that ships. (See Domain 3.4.)
• Requires fast, reliable CI on every commit, plus strong automated test coverage.
• Eliminates merge hell: there is nothing to diverge from.

Release branching

Naming conventions

feature/1234-user-authentication   # new work, references the work item
bugfix/5678-null-reference         # non-urgent defect
hotfix/payment-gateway-timeout     # urgent production fix
release/2.4                        # stabilisation branch for a version
users/marco/spike-caching          # personal/experimental (Azure Repos convention)

Consistent prefixes matter operationally: branch policies, pipeline triggers and branch-control checks are all configured with wildcards such as release/* and feature/*.

Pull request workflow

Azure Repos branch policies

GitHub branch protection rules & rulesets

Merge strategies and restrictions

CODEOWNERS

# Later matches win — the LAST matching pattern takes precedence.
*                       @org/platform-team

/docs/                  @org/docs-team
*.ts                    @org/frontend-team @lead-developer
/infrastructure/        @org/devops-team
/src/auth/              @org/security-team
/.github/workflows/     @org/devops-team

• Owners are automatically requested for review when a PR touches a matching path.
• Combine with Require review from Code Owners to make that approval mandatory.
• Azure Repos achieves the same with automatically included reviewers scoped to a path.

2.2 Configure and manage repositories

Managing large files

Git stores a complete copy of every version of every file in every clone. Large binaries — which do not delta-compress — bloat the repository permanently, because history is immutable.

Git LFS (Large File Storage)

LFS replaces large files in the repo with small text pointer files; the real content lives on a separate LFS server and is fetched on checkout.

git lfs install                # one-time, per machine

git lfs track "*.psd"          # writes rules into .gitattributes
git lfs track "*.mp4"
git lfs track "assets/**/*.bin"

# .gitattributes now contains:
#   *.psd filter=lfs diff=lfs merge=lfs -text

git add .gitattributes         # MUST be committed — it is what makes LFS work for everyone
git add design.psd
git commit -m "Add design assets"
git push origin main

git lfs ls-files               # list files currently managed by LFS
git lfs migrate import --include="*.psd"   # convert EXISTING history to LFS (rewrites history)

git-fat

A lighter-weight, third-party alternative to LFS: large files are replaced by a placeholder containing a SHA-1, and the real payload is synced to an external store over rsync (or S3-style backends).

[rsync]
remote = storage-server:/srv/fat-store

Use it when you need a self-hosted binary store with no vendor dependency. In practice LFS is the default answer; git-fat appears in the skills measured mainly so you recognise the name.

Scaling and optimizing a Git repository

Scalar

Scalar ships with Git itself and applies the large-repo configuration that Microsoft developed for the Windows and Office repositories.

scalar clone https://dev.azure.com/org/project/_git/large-repo
scalar register            # opt an EXISTING clone into Scalar's maintenance + config
scalar run all             # run maintenance tasks now
scalar unregister

# The underlying primitives, if asked about them directly:
git clone --filter=blob:none <url>
git sparse-checkout set --cone src/api src/shared

Cross-repository sharing

git submodule add https://github.com/org/shared-lib ./libs/shared
git clone --recurse-submodules https://github.com/org/project
git submodule update --init --recursive     # after a plain clone
git submodule update --remote --merge       # advance to the submodule's latest

Permissions in the source control repository

Azure DevOps

Access is the intersection of an access level (what you paid for), security group membership (what role you hold) and object-level permissions (Allow / Deny / Not set on a specific repo or branch).

GitHub

• Grant access through teams, not individuals — teams support nesting and inherit parent permissions.
• Outside collaborators are non-org members granted access to specific repositories; they do not consume a team's permissions model and should be reviewed regularly.
• Where a user gets permissions from multiple sources, the highest permission wins (the opposite of Azure DevOps' Deny-wins model).

Tags

git tag v1.0.0                             # lightweight: just a pointer, no metadata
git tag -a v2.1.0 -m "Adds payment gateway" # annotated: tagger, date, message — RECOMMENDED for releases
git tag -s v2.1.0 -m "Signed release"       # signed: annotated + GPG signature
git tag -a v1.9.5 abc1234 -m "Hotfix"       # tag a specific historical commit

git push origin v2.1.0                      # tags are NOT pushed by default
git push origin --tags                      # push all tags

git tag --list "v2.*"
git tag -d v1.0.0                           # delete locally
git push origin --delete v1.0.0             # delete on the remote

Recovering specific data with Git commands

git reflog
# abc1234 HEAD@{0}: reset: moving to HEAD~1
# def5678 HEAD@{1}: commit: the work I just destroyed   ← recover this
# ghi9012 HEAD@{2}: commit: earlier work

git reset --hard HEAD@{1}          # put HEAD back
git branch recovered def5678       # or rescue it onto a new branch

Removing specific data from source control

# Remove one file from ALL history
git filter-repo --path secrets.env --invert-paths

# Remove every file matching a glob
git filter-repo --path-glob '*.pem' --invert-paths

# Redact a literal string everywhere
git filter-repo --replace-text patterns.txt

git clone --mirror https://.../repo.git

java -jar bfg.jar --delete-files secrets.env repo.git
java -jar bfg.jar --replace-text passwords.txt repo.git
java -jar bfg.jar --strip-blobs-bigger-than 50M repo.git

cd repo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force

The full incident response for a leaked secret

1. Rotate the secret first. Assume it is compromised the moment it was pushed — history rewriting is cleanup, not containment.
2. Rewrite history with git filter-repo or BFG, then force push all branches and tags.
3. Tell every collaborator to re-clone. Old clones still contain the secret and can push it back.
4. Purge cached copies. Forks, PR refs and the server-side cache can still serve the old blobs — on GitHub, open a support request to purge cached views; on Azure DevOps, contact support to clear server-side data after the force push.
5. Prevent recurrence — enable secret scanning with push protection, add pre-commit hooks (gitleaks, detect-secrets) and move the value into Key Vault. (See Domain 4.)

Domain 2 rapid recap