Git & GitHub Fundamentals · Module 12 of 12

Capstone: collaborative release workflow

Combine local commits, branching, review, a shared remote and an annotated release tag into one auditable workflow.

Learning objectives

By the end of this module, you should be able to:

Build a repository from initialization to release tag.
Use a bare remote to simulate shared collaboration.
Diagnose divergence and integrate reviewed work without force-pushing.

A healthy workflow is evidence-driven

Status, diffs, commit history and remote-tracking references should explain what will happen before you push or merge. Teams then layer GitHub review and repository rules on top of the same Git graph.

Separate authoring, integration and release

Feature work happens on a branch, review compares it with the base, integration updates main, and a release tag names the exact approved commit. Each step creates evidence that can be inspected later.

Troubleshoot from the graph

When push or merge fails, inspect branches, upstreams and history before forcing anything. git status, git branch -vv, git log --graph --all and git remote -v form a strong first diagnostic set.

Worked examples

See the idea in practice.

Core incident/debug view

git status
git branch -vv
git remote -v
git log --oneline --graph --decorate --all

These commands expose local state, tracking relationships, remotes and commit topology.
They are read-only and appropriate before corrective action.

Hands-on lab

Lab — End-to-end collaborative release

Goal: Create a remote, clone two working copies, propose a feature, integrate a concurrent main change, push and tag a release.

Before you start

Git 2.23 or newer is recommended so the labs can use git switch and git restore.
Run labs in a disposable working directory; the included validator creates and removes its own temporary repository.

STEP 1

Create shared bare repository and maintainer clone

mkdir -p ~/gnu-git-labs/module12 && cd ~/gnu-git-labs/module12
git init --bare remote.git
git clone remote.git maintainer
cd maintainer
git switch -c main
git config user.name "Maintainer"
git config user.email "maintainer@example.invalid"
printf "version=1\n" > app.conf
git add app.conf && git commit -m "Initialize application"
git push -u origin main

STEP 2

Clone contributor and create feature

cd ~/gnu-git-labs/module12
git clone remote.git contributor
cd contributor
git switch main
git config user.name "Contributor"
git config user.email "contributor@example.invalid"
git switch -c feature/logging
printf "logging=enabled\n" > logging.conf
git add logging.conf
git commit -m "Enable logging"
git push -u origin feature/logging

STEP 3

Maintainer adds concurrent main change

cd ~/gnu-git-labs/module12/maintainer
printf "owner=platform\n" > owner.conf
git add owner.conf
git commit -m "Record service owner"
git push

STEP 4

Review and integrate feature

git fetch origin
git diff main...origin/feature/logging
git merge --no-ff origin/feature/logging -m "Merge logging feature"
git push origin main

STEP 5

Tag exact release commit

git tag -a v1.1.0 -m "Release v1.1.0"
git push origin v1.1.0

STEP 6

Verify from a fresh clone

cd ~/gnu-git-labs/module12
git clone remote.git verifier
cd verifier
git switch main
git fetch --tags
git log --oneline --graph --decorate --all
git tag -n
cat app.conf
cat logging.conf
cat owner.conf

Verify

main contains the base configuration plus the logging and owner changes.
The remote has feature/logging, main and tag v1.1.0.
A fresh clone can resolve the release tag.

Expected outcome

The capstone produces an auditable graph that can be mapped directly to a GitHub pull-request/release workflow.

If it fails

If the contributor clone cannot switch main after cloning an initially empty remote, run git fetch origin and git switch -c main --track origin/main.
If a push is rejected, fetch and inspect divergence; do not automatically force-push.
If merge conflicts occur, resolve them using module 6 rather than accepting one side blindly.

Real-world connection

This pattern underlies controlled application delivery: proposed change, review evidence, integration, remote publication and immutable release reference.

Avoid these traps

Common mistakes

Force-pushing because a normal push was rejected.
Tagging a commit before integration checks are complete.
Treating GitHub UI state as a substitute for inspecting the Git graph.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What four commands give a strong first view of a Git collaboration problem?

git status, git branch -vv, git remote -v and git log --graph --decorate --all.

2What should a release tag identify?

The exact validated commit being released.

3Why does the capstone use a fresh verifier clone?

To prove the published remote contains the expected branches, commits and tag independently of the maintainer working copy.