Version control with Git

Nineteen chapters ago, among the tools of the trade, I promised Git the space it deserves. Today we pay the last remaining debt.

Start with a familiar problem: project-final-v2-FINAL-okay-this-one.zip. Endless copies, fear of touching working code, "it worked before, what changed?". Git eliminates this: the time machine for code, one of the first tools learned in a team.

📸 The idea: snapshots

Git is version control: it photographs the project whenever asked and keeps its history. Each photograph is a commit, recording what changed, who changed it, when and, in the message, why.

Put the Watch project under control. From its folder:

1# once: turn the folder into a repository
2git init
3
4# choose what to snapshot (dot = everything)
5git add .
6
7# take the snapshot with a meaningful description
8git commit -m "Watch register: first working version"

That version is now recorded. Break everything tomorrow? Go back. Want the server from three weeks ago? It is there. View history with git log, and current state with your most frequent command: git status.

Before the first commit, create .gitignore, listing what Git should ignore. Here: node_modules/ (regenerated by npm install, chapter 13), guardia.db (data is not code) and .env (never commit secrets, chapter 15, and that was no mere suggestion).

🌿 Branches: parallel universes

The feature turning Git from a lifeline into a superpower: want to experiment (castle management, perhaps) without risking working code? Create a branch, a parallel timeline.

1# create and switch to the branch
2git switch -c gestione-castelli
3
4# ...work, experiment, commit freely...
5git add .
6git commit -m "Add castle table and routes"

On gestione-castelli, make whatever mess you like: the main branch (main) stays intact. When the experiment is ready, reunite timelines with a merge:

git switch main
git merge gestione-castelli

Changes flow into main. If main changed the same areas meanwhile, Git asks you to resolve conflicts manually: intimidating the first time, routine by the third.

🌍 GitHub and teamwork

Everything so far lives on your computer. GitHub (or GitLab, Bitbucket) hosts a remote repository copy: backup, showcase and, most importantly, team meeting point.

1# connect the remote repository (once)
2git remote add origin https://github.com/tuonome/guardiani.git
3
4# send your commits
5git push
6
7# download your colleagues' commits
8git pull

Branches now reveal their real purpose. Teams commonly avoid direct commits to main: work on branches, then open a pull request, asking to bring changes in. The PR is the team's square: colleagues read code, comment line by line, request changes, then merge after approval.

Code review is not an exam: it is where both sides learn most. Years later, the most intense PR discussions often become your best free lessons.

The complete workflow used in companies:

1. git pull on main: start up to date.
2. git switch -c nome-funzionalita: your branch.
3. Work and commit in small steps with clear messages.
4. git push and open the pull request.
5. Review, adjust, merge, return to step 1.

✅ Conclusion

Commits as photographs, branches as parallel universes, merges joining them, pull requests for collaboration: four concepts covering most daily Git use. One piece of advice: start now, even alone, even on the Watch project. Your future self breaking something next month will thank you and fix it with a command.

We are almost at the end. The next chapter, the last, maps what follows: topics to deepen, places to study and how to keep growing after the guide.