Before this lesson
Complete staging, branching, diff review and tags in this course.
Use Git 2.35+ and a Bash-compatible terminal, such as Git Bash on Windows. Each complete example creates an independent temporary directory. Run it only in that practice repository. Configuration is repository-local and uses a practice identity. Temporary directories are not automatically removed; clean them up after finishing.
What you will be able to do
Connect branching, diff review, validation and tagging into a repeatable workflow.
Understand the mechanism
Start with a concrete goal: add a verifiable study checklist. A feature branch carries an independent change, its commit message explains intent, and review focuses on differences from main.
The three-dot comparison main...feature/checklist shows feature-side changes since the common ancestor, unlike a general two-endpoint comparison. A real pull request also explains tests, limits and compatibility and follows branch protection and review rules.
rebase replays commits on a new base, normally creating new identifiers; cherry-pick applies selected changes to the current branch. Both can conflict. Learn merges first and do not unilaterally rewrite shared history.
Git Flow, short-lived feature branches and trunk-based development are different strategies. A small tutorial project can use feature, verify, review, merge and tag without introducing unnecessary long-lived branches.
Runnable example
lab=$(mktemp -d)
cd "$lab"
git init -b main .
git config user.name "Honeysuck Learner"
git config user.email 'learner'@'example.invalid'
git config commit.gpgsign false
git config core.autocrlf false
printf 'Start learning\n' > notes.txt
git add notes.txt
git commit -m "Start learning notes"
git switch -c feature/checklist
printf 'read\npractice\nreview\n' > checklist.txt
git add checklist.txt
git commit -m "Add three-step study checklist"
git diff --check main...feature/checklist
git diff main...feature/checklist -- checklist.txt
test "$(wc -l < checklist.txt | tr -d ' ')" = 3
git switch main
git merge --no-ff feature/checklist -m "Merge verified checklist"
test "$(wc -l < checklist.txt | tr -d ' ')" = 3
git tag -a v1.0.0 -m "Release verified checklist"
git log --graph --oneline --all
git status --short
Trace and verify
After diff and three-line checks pass, merge, verify the integrated result and tag it. Final status is clean, v1.0.0 identifies the merge commit, and checklist.txt contains read, practice and review.
Common mistakes and boundaries
The line-count check verifies only this teaching artifact, not real software correctness. No hosted pull request or deployment is created here. Run project-specific tests before applying the workflow to a business repository.
Practice challenge
Add a fourth step, publish, update the validation and create a new version commit.
Reference solution and reasoning
Use a new feature branch with four lines, change the check to 4, review and merge. Create a new tag such as v1.1.0 under your versioning policy rather than moving the published v1.0.0.