Capstone Setup: Repository, Tests, Branch Policy, and Release Plan

Capstone Setup: Repository, Tests, Branch Policy, and Release Plan

Module: Module 12: Capstone - Advanced Git Delivery Simulation

The capstone begins by setting up a small project with enough structure to simulate team Git work: a main branch, feature branches, tests, release tags, and written policy.

Your capstone repository should be small enough to finish but realistic enough to exercise decisions. Use a simple configuration-driven command-line project, documentation site, or notes app. Add a test script that can pass or fail based on file content. Add README, CHANGELOG, and RELEASE_NOTES files.

Before writing features, write the policy: branch naming, merge strategy, commit message expectations, required checks, release tag format, and hotfix process. This forces you to connect Git commands to team rules.

Command Walkthrough

mkdir git-capstone && cd git-capstone
git init
mkdir scripts src docs
printf 'mode=stable\n' > src/app.conf
printf '#!/bin/sh\ngrep -q stable src/app.conf\n' > scripts/test.sh
chmod +x scripts/test.sh
git add . && git commit -m 'Create capstone project skeleton'
git tag -a v0.1.0 -m 'Initial capstone baseline'

v1.0.0
v1.1.0

Hands-on Lab

Create WORKFLOW.md describing your branch, review, merge, release, hotfix, and recovery rules. Commit it before starting feature work.

What to Watch For

• A capstone without tests cannot exercise bisect or release confidence.
• A workflow policy written after the project is finished will not influence decisions.
• Keep the project simple. The learning target is Git, not application complexity.

Completion Check

You should be able to explain what each command changed, inspect the resulting history, and describe how you would undo or recover from the operation before using it in a shared repository.