Chapter 04
Command line and Git
The terminal and Git commands every team expects from day one: moving around, committing, branching, working with GitHub and recovering from mistakes.
Repositories and commits
Also called git init, git commit, version control, repo
- What
- A Git repository stores the full history of a project. A commit is a saved snapshot of your staged changes with a message, an author and a unique hash.
- Why
- Commits let you see what changed and why, go back to any earlier state and work safely with others.
git init
git status
git add app.py
git commit -m "Add monthly summary report"
git log --oneline --graphWatch out
Making one giant commit at the end of the day; small commits are easier to review, revert and understand.
Staging area
Also called index, git add, git diff
- What
- The staging area holds the changes that will go into the next commit.
git addmoves changes there;git diffshows unstaged changes andgit diff --stagedshows staged ones. - Why
- It lets you build a focused commit from a messy working folder, for example committing a bug fix without the half-done feature next to it.
git diff
git add -p
git diff --staged
git restore --staged notes.txtWatch out
Running git add . without looking, which commits debug prints, secrets and build output.
.gitignore
Also called ignored files
- What
- A file listing patterns of files and folders Git should not track, such as dependencies, build output, logs and local secrets.
- Why
- It keeps repositories small and stops passwords and machine-specific files from being committed and shared.
.venv/
node_modules/
bin/
obj/
build/
*.log
.envWatch out
Adding a file to .gitignore after committing it: Git keeps tracking it until you run git rm --cached.
Branches
Also called git switch, git branch, feature branch
- What
- A branch is a movable name that points to a commit. Creating one lets you commit new work without touching
main. - Why
- Each feature or fix lives on its own branch until it is reviewed, so
mainstays working and several pieces of work can happen at once.
git switch -c feature/export-csv
git branch
git switch main
git branch -d feature/export-csvWatch out
Committing straight to main in a team repository, which skips review and makes a bad change hard to undo.
Merging and rebasing
Also called git merge, git rebase, fast-forward
- What
- Merging joins another branch into yours, adding a merge commit if both changed. Rebasing replays your commits on top of another branch, giving a straight history.
- Why
- You use one of them to bring your branch up to date with
mainand to land finished work. Teams pick a convention; both end with the same code.
git switch main
git merge feature/export-csv
git switch feature/export-csv
git rebase mainWatch out
Rebasing commits you already pushed and others use, which rewrites shared history and forces everyone to repair their copies.
Merge conflicts
Also called conflict markers
- What
- A conflict happens when two branches changed the same lines. Git stops and marks both versions in the file for you to choose or combine.
- Why
- Conflicts are normal in team work. Resolving them calmly, then testing, is a daily skill.
<<<<<<< HEAD
total = sum(prices)
=======
total = sum(prices) * 1.2
>>>>>>> feature/taxWatch out
Deleting the markers and keeping one side without reading the other change, which silently drops a colleague's work.
Remotes: clone, fetch, pull and push
Also called origin, GitHub, git pull, git push
- What
- A remote is a copy of the repository on a server such as GitHub, usually named
origin.fetchdownloads new commits,pullfetches and integrates them, andpushuploads yours. - Why
- Remotes are how a team shares work and how your code is backed up off your machine.
git clone https://github.com/you/ledger.git
git remote -v
git fetch origin
git pull --rebase
git push -u origin feature/export-csvWatch out
Force-pushing (git push --force) to a shared branch; if you must, use --force-with-lease.
Pull requests
Also called PR, merge request, code review
- What
- A pull request asks to merge one branch into another on GitHub. It shows the diff, runs automated checks and collects review comments before merging.
- Why
- It is where teams review code, discuss design and catch bugs. A clear description and a small diff get reviewed faster.
- Example
- Title "Add CSV export to monthly report". Description: what changed, why, how you tested it, and a screenshot. About 200 changed lines, not 2,000.
Watch out
Opening one huge pull request that mixes a refactor, a feature and formatting changes, so nobody can review it properly.
Undoing mistakes
Also called git restore, git revert, git reset, git reflog, amend
- What
restorediscards uncommitted changes to a file,commit --amendfixes the last commit,revertadds a commit that undoes an old one,resetmoves your branch back, andrefloglists where HEAD has been.- Why
- Almost nothing committed in Git is truly lost. Knowing the right undo turns a panic into a one-line fix.
git restore app.py
git commit --amend
git revert a1b2c3d
git reset --soft HEAD~1
git reflogWatch out
Using git reset --hard on work you have not committed: those changes cannot be recovered.
Commit messages
- What
- A short summary line in the imperative mood (about 50 characters), a blank line, then a body that explains why the change was made.
- Why
- The history is documentation. Future you and your reviewers read messages to understand why code looks the way it does.
Add CSV export to monthly report
People asked to open reports in a spreadsheet. The export
uses the same columns as the on-screen table so both stay
in sync. Dates use ISO 8601 to avoid locale confusion.Watch out
Messages like "fix", "stuff" or "wip" that say nothing a year later.