🏆Capstone project: Build a Full Project Lifecycle

There are no prepared files and no old commits to follow. You are standing in an initialized main repository, and the whole history you leave behind will be yours.

This is the course capstone. You will take one tiny plain-text project through a complete Git lifecycle: begin it, protect local-only paths, develop on a branch, resolve a conflict, recover discarded work, and finish with a clean repository another person could understand.

Read the empty starting point

Run plain git status before you create anything. It should report main, no commits yet, and no changes.

git status

Choose a project small enough to finish

Pick something that works as one or two short text files: a reading list, a packing plan, a field journal, or another small idea you care about. Choose your own filenames and content. The project is only the setting; the evidence in its Git history is what matters.

Use nano -w with the filename you chose to create and edit the project, just as you did earlier in the course. Save each meaningful change before you inspect and stage it.

You need at least six commits reachable from the final main. Make each commit represent one understandable change and give it a useful first-line subject. A subject is useful when a reader can tell what changed without opening the commit; an empty subject or the one-word defaults wip, update, and fix do not do that.

Use the review loop from Chapter 9 as you work: inspect with git status and git diff, stage only the intended change with git add, inspect the staged snapshot with git diff --staged, then commit it. Your commit count can grow across all the milestones below, so you do not need six foundation commits before branching.

Protect local and generated paths

Add a regular .gitignore file and commit it. Its rules should keep virtual environments in .venv/, Python cache directories named __pycache__/, and files whose names end in .env out of Git.

Use git check-ignore on representative paths before you trust the rules. The final history check looks through every reachable commit, so committing one of those private or generated paths and deleting it later is not safe enough. It must never enter reachable history.

Make two lines of work meet

Create a feature branch with git switch -c and make a meaningful commit there. Choose one already tracked project file for the branch to edit, because that same file will carry the evidence of your resolution.

Return to main and edit the same part of that shared file differently, then commit the main-side change. Now neither side contains the other: the two branches genuinely diverge.

Merge the feature branch into main with git merge. Git should stop on a conflict in the shared file. Read the marker sections, edit them into one intentional result that is different from either parent’s version, stage the resolved file, and finish the merge commit. Keeping useful ideas from both sides is often the clearest resolution, but the exact words are your choice.

If the merge fast-forwards without creating a conflict, the histories did not diverge in the required way. Read git log and git branch, then add the missing independent main-side and feature-side work before trying the milestone again. The final evidence must include a real two-parent merge, not merely the same files after a linear sequence.

Discard a commit, then recover the real work

Make and commit one more genuine project change. Confirm that commit in git log, then use the destructive git reset --hard technique from Chapter 4 to move main back to an earlier commit. This is deliberate here: the capstone needs evidence that a real commit left the branch.

Read git reflog immediately. Find the entry for the commit the reset moved away from, and recover that actual work with git cherry-pick, the recovery route from Chapter 4. Retyping similar content in a new commit is not recovery because it loses the discarded commit’s provenance.

The revision shown by your reflog is the one to use. Do not copy an example hash from a lesson or guess a fixed HEAD@{...} position; your own history determines both.

Read the history as the next collaborator

Use git log to read the story from newest to oldest. A future collaborator should be able to recognize the small starting changes, the two lines of work meeting in a merge, and the real change you recovered. Vague subjects are much easier to notice when you read the history as a story rather than count it as a score.

Inspect .gitignore and use git check-ignore once more on the representative local-only paths. Then run git status on main and settle anything staged, modified, untracked, or unresolved that belongs in the project. If one of those readings exposes a gap, repair the repository with the commands you already know instead of rebuilding a second project.

Your project idea, filenames, feature-branch name, message wording, and route through the work are deliberately yours. The shared standard is a readable history that preserves both lines of work, proves that committed work can be recovered, keeps machine-only files out, and leaves the next person a clean starting point.

Do not add a remote or use a hosted service for this capstone. Collaboration was assessed in Chapter 8; this final lifecycle stays inside one local, network-disabled repository.

Finish by reading git status one last time. A clean answer is the handoff: the project has a history worth trusting, and the next person can begin without first untangling yours.