Version control with Git
Version control records every change to a project, lets people work in parallel, and makes it possible to undo mistakes. Git is by far the most widely used system.
Why version control
Without version control, projects end up with files like report_final_v3_REALLY_final.doc and no way to know who changed what. Version control keeps a full history of changes, with author, time, and message, lets you return to any earlier state, and lets many people work on the same code safely.
Git basics
Git was created by Linus Torvalds in 2005 to manage Linux kernel development. It is distributed: every developer has the full history locally. Key commands: git init creates a repository; git status shows changes; git add stages changes; git commit -m "message" records a snapshot; git log shows history.
The three areas
Git has a working directory (your files), a staging area (changes selected for the next commit), and the repository (committed history). Staging lets you commit related changes together while leaving others for later. git diff shows unstaged changes, and git diff --staged shows what will be committed.
Good commits
Each commit should be one logical change with a clear message: a short summary line, such as 'Fix rounding in invoice totals', and optionally a body explaining why. Small, focused commits make history readable, reviews easier, and bugs easier to locate and revert. Never commit secrets such as passwords or API keys; use a .gitignore file to exclude them and generated files.
Branches
A branch is an independent line of development. git switch -c feature-login creates and switches to a new branch, where you can work without affecting main. Branches are cheap in Git, so teams create one per feature or fix. When work is finished, it is merged back into main.
Merging and conflicts
git merge combines branches. If both changed the same lines differently, Git reports a merge conflict and marks the file with <<<<<<<, =======, and >>>>>>> sections. You edit the file to the correct result, remove the markers, then add and commit. Rebasing is an alternative that replays commits onto another branch for a linear history.
Remotes
A remote is a shared copy of the repository on a server, such as GitHub, GitLab, or Bitbucket. git clone copies a remote; git push sends your commits; git pull fetches and merges others' commits. Pull often to stay current and reduce conflicts. git revert creates a new commit undoing an earlier one, which is safe on shared branches.
Worked example
Fixing a typo on a team project: git switch main; git pull; git switch -c fix-header-typo; edit index.html; git add index.html; git commit -m "Fix typo in page header"; git push -u origin fix-header-typo. Then open a pull request on the hosting site for review. After approval, it is merged into main, and the branch can be deleted.
Key takeaways
Version control keeps a full history and enables safe collaboration. Git (Torvalds, 2005) is distributed; init, status, add, commit, and log are core commands. Changes move from working directory to staging area to repository. Commit small logical changes with clear messages; never commit secrets; use .gitignore. Branches isolate work; merges combine it, and conflicts are resolved by editing marked sections. Remotes such as GitHub are shared via clone, push, and pull; revert safely undoes commits.
Flashcard
System recording every change
Check your understanding
You accidentally committed a bad change that teammates have already pulled. What is the safest way to undo it?