In the previous lesson we went through four very different projects and in all four the same thing turned up: Git never works on its own. Mailing lists appeared, and proposal platforms, build systems, integration pipelines and tracking tools. Git is the engine, but the daily experience of using it is defined by everything around it.

This lesson is about that layer. Not about new commands — apart from a couple of pieces that were missing — but about how Git fits into a real working setup: the editor, the terminal, the ticketing system, the linters, the review platform. And about where the risk lies, which is not technical but a matter of understanding.

Because there is a pattern that repeats in every team: somebody has been using Git from a button in their editor for two years, everything goes well, and the day something goes wrong they discover they do not know what that button did. That "Sync" that solved everything was git pull --rebase followed by git push, and now there are seventeen rewritten commits, a published branch that has diverged and no idea where to begin.

You already know how to get out of that (the whole of module 9). What we are going to do here is use the tools without giving up on understanding them: take advantage of what they genuinely contribute, know which command they run underneath and be clear about what is worth carrying on doing by hand.

1. The underlying rule: the tool does not replace the mental model
2. Editors and IDEs: what they genuinely contribute
3. What is worth carrying on doing in the terminal
4. Graphical clients and history viewers
5. The terminal as a Git environment: prompt and completion
6. Ticketing systems: closing the GT-NNN convention
7. Quality tools: linters, formatters and .editorconfig
8. Review and analysis: status checks
9. format-patch, am and request-pull as a bridge between worlds
10. How to choose what to automate

Before anything else, the rule that orders the whole lesson:

Every tool that integrates Git ends up running Git commands. If you know which command it runs, the tool saves you time. If you do not, the tool saves you time until the day it fails, and then it costs you far more than it saved you.

This is not an argument against graphical interfaces. It is an argument in favour of knowing how to read what they do. Nearly all of them offer a console or a log where they show the commands they have run: looking at it during the first few weeks is the best learning investment there is.

And there is an important asymmetry. The tools are excellent at the visual and repetitive:

• Seeing differences in colour, by word, side by side.
• Resolving a conflict with three panels on screen.
• Staging changes hunk by hunk with the mouse.
• Seeing the commit graph drawn out.
• Seeing who wrote each line without leaving the file.

And they are bad — or downright dangerous — at the conceptual and irreversible:

• Anything that rewrites history.
• Resolving a divergence with the remote.
• Recovering from a mistake.
• Any operation where you want to understand exactly what happened.

The practical rule that comes out of that, and which is the summary of the whole module:

Use the interface to look. Use the terminal to decide.

Modern editors come with Git integration built in. What follows is what is genuinely worth having, ordered by return on investment.

The editor marks in the gutter the lines added, modified and deleted relative to HEAD, and lets you see the previous version at a glance. It is the equivalent of git diff (lesson 02-05) but without switching context: you see the change inside the file you are editing, with the language's syntax highlighting.

It is probably the most valuable integration there is, because it changes a habit: instead of reviewing the changes at the end, you see them as you work.

What it contributes: immediate context, word-level differences within a line, reverting a specific hunk with one click.

What it does not replace: git diff --staged before committing. It is still the final quality control, and it is worth doing with the full view.

When there is a conflict (lesson 03-05), a good editor shows three versions: yours, the other branch's and the common base. Being able to see the base is what makes the difference, because a conflict is only understood by knowing what the two sides started from.

This can be configured so that Git invokes it directly:

And the equivalent for viewing differences:

One setting that is always worth switching on, and which we already saw in lesson 03-05:

With zdiff3, the conflict markers include the base version between ||||||| and =======, not just the two sides. It is the same information the three panels give, but in the file, and it works whether you resolve in the editor or by hand.

The editor shows at the end of each line who wrote it, when and with what commit message. It is git blame (lesson 06-03) turned into ambient information.

Its virtue is that it removes the friction of wondering why. When reading the reason for a line costs nothing, it gets read; when it costs a command and a change of window, it does not.

Its danger is the one we already discussed: blame gives you the last person who touched the line, who is very often whoever re-indented it. When the result makes no sense, you have to go to the terminal:

That .git-blame-ignore-revs file at the root of the repository is a list of hashes of purely cosmetic commits:

And it can be left permanently active:

Editors respect that setting, so the inline blame stops lying. It is a two-minute adjustment that improves life for the whole team.

git add -p (lesson 02-04) is one of the most useful tools in the course and one of the most uncomfortable to use: you have to decide y/n/s/e on hunks that sometimes have to be split by hand. In an editor, selecting the lines that go into the index is a matter of clicks, and splitting a hunk is trivial.

Here the graphical interface wins clearly. If the e in add -p (editing the hunk by hand in diff format) feels hostile to you, this is its reasonable alternative.

• File history: git log --follow -p file, with convenient navigation.
• Branch list and switching between them: convenient, but it is worth knowing that the editor may be running git switch or git checkout with different nuances.
• Stash from the menu: equivalent to git stash push, almost never with a message. A stash without a message is a stash whose contents you will not know in three days' time (lesson 05-04).

Useful for always knowing what is underneath the button:

The most dangerous one in the table is the first. "Sync" is a button that performs two network operations, one of which may reorder your local history according to a global setting you perhaps put there a year ago. It is worth looking once at exactly what it does:

The other half of the rule. These operations are best done by typing the command, and not out of purism:

The last row is the important one. The mistake to avoid is not using the interface: it is using it for something you do not understand. If you know exactly what a button does, press the button; it saves you typing. If you do not, type the command, even if it takes longer, because you are paying the learning cost only once.

Dedicated graphical clients go a step further than an editor's integration: they are applications whose only job is Git.

The graph. A history with parallel branches and merges is a directed acyclic graph (lesson 03-01), and a graph is much better understood drawn than in text. Seeing at a glance where a branch diverged, what merges there were and which commits belong to whom is genuinely faster in an interface.

In the terminal, the decent equivalent:

And with the formats from lesson 06-04, very readable:

But with more than three or four live branches, the ASCII drawing becomes hard to follow. There an interface wins.

Comparing two arbitrary commits. Selecting two points in the history and seeing the difference is more convenient with the mouse than by remembering two hashes.

Exploring somebody else's repository. When you arrive fresh at a project, going through its history visually gives you an intuition for how the team works that is harder to get from reading text.

Without installing anything, Git includes two minimal graphical tools:

They are austere, but they are everywhere and do not depend on anybody maintaining them. gitk --all --date-order is still a quick way of looking at a graph on a server where you are not going to install anything.

Their ease makes costly operations get run without thinking. Dragging one branch onto another may launch a rebase of twenty commits. A context menu may offer "Force push" right next to "Push", without distinguishing between --force and --force-with-lease (lesson 09-03).

Specific advice: if your graphical client offers force pushing, check in its settings which of the two variants it uses. If it is plain --force and it cannot be changed, do that operation in the terminal. The difference between the two is a colleague's work.

If you are going to decide in the terminal, it is worth having the terminal well equipped. Two settings with an enormous effort-to-benefit ratio.

Seeing the current branch and the state of the tree on every line of the terminal eliminates a whole class of mistakes: committing on the wrong branch, forgetting that there is a half-finished rebase, not noticing that there are uncommitted changes.

Git ships the official script. It is usually already installed with Git:

And it is configured in ~/.bashrc:

The result in practice:

Read them from left to right:

• main=: on main, in sync with the remote.
• GT-231-hidden-filter *%<: there are unstaged changes (*), untracked files (%) and the remote is ahead (<), so a fetch is due.
• |REBASE 2/5: there is a rebase half-finished, at step 2 of 5. This is the one that prevents the most upsets: it is exactly the situation in which somebody gets up for a coffee, comes back and does not understand why git status is saying strange things (lesson 09-01).

On macOS with zsh, Bruno has the equivalent built into his shell configuration; and on Windows, Carla has it out of the box in Git Bash. What matters is not which script you use, but that the branch should always be in sight.

Git also ships its completion script, which completes subcommands, options, branch, tag and remote names:

With it, git switch GT-<TAB> offers the branches beginning with GT-. In a repository with many branches it is an enormous improvement, and it also prevents the mistake of mistyping a branch name, which in Git sometimes does not fail but creates something new instead.

A valuable detail: completion also works with your aliases if they are defined as Git aliases (lesson 06-04):

Compared with shell aliases (alias gs='git status'), Git aliases have three advantages: they travel with your configuration to any machine, they work the same in Bash, zsh and Git Bash, and they are visible to anybody who reads your configuration. Shell aliases are shorter to type; use both, each for its own purpose.

We have spent the whole course writing GT-231 in branches and messages. It is time to explain exactly what it is for and what it achieves.

The complete traceability chain has three links that have to be kept up by hand and one that is automated:

1. The branch carries the identifier. GT-231-hidden-filter. Without this, in six months' time nobody will know what that branch was.
2. The commits carry it. With Conventional Commits (lesson 08-01), in the subject or in a trailer:

3. The proposal declares it, with the keyword the platform recognises (Closes GT-231, Fixes GT-231, Resolves GT-231, depending on the tool).
4. On integration, the ticket closes itself and ends up linked to the integration commit.

Traceability is not bureaucracy. It is the ability to answer, in thirty seconds and without asking anybody, these four questions:

And the corresponding commands, all of them already familiar:

That last command is the one that genuinely gets used when somebody writes "this is still failing in production": it checks objectively whether the fix ever got there.

Writing GT-231 in every message gets forgotten. It can be automated with a hook (lesson 06-01) that extracts it from the branch name:

And the server-side validation, which is what guarantees compliance, we already saw in lesson 06-01 as an update hook and in 07-06 as a pipeline check.

Remember the division of responsibilities we established: the client hook helps, the server hook enforces. A prepare-commit-msg is a convenience; if the requirement is real, it has to be checked on the server or in CI as well, because local hooks are not distributed with the repository and anybody can skip them with --no-verify.

A linter points out problems; a formatter imposes a style. In a team, both should run automatically, because style argued over in reviews is wasted time.

The interesting question is where to hook them in, and there are three possible places.

The correct combination is editor + CI, with the hook as an option for whoever wants it. The editor gives you the immediate answer, CI guarantees compliance. The pre-commit hook is convenient but cannot be the only defence, for the usual reason: it does not travel with the repository.

A well-written pre-commit has one detail that almost everybody forgets: it must check what is in the index, not what is on disk. If you have unstaged changes, checking the file on disk validates something that is not what you are about to commit:

Three things that deserve attention:

• --diff-filter=ACM excludes deleted files: there is no point running the linter over something that no longer exists. It is the most frequent mistake in these hooks.
• The stash push --keep-index sets aside what is not staged (lesson 05-04) so that the linter sees exactly the content that is going to be committed.
• The restore happens whether or not the check passes. A hook that leaves your work in the stash when it fails is a hook people switch off.

A small and very profitable file, which travels in the repository and which almost every editor respects (some out of the box, others with an extension):

Its value lies in solving at the source what .gitattributes (lesson 08-04) solves at the repository boundary. They are complementary, and the division is worth being clear about:

With both, the problem of line endings between Ubuntu, macOS and Windows 11 — the GT-190 we resolved in lesson 08-04 — is attacked twice over: Carla's editor writes LF from the outset, and Git normalises anyway just in case.

Hosting platforms have a mechanism that unifies everything automatic: commit statuses (or checks). Any external system can publish, against a specific commit hash, a verdict: pending, success, failure.

The conceptually important part: the status is associated with a commit hash, not with a branch or a proposal. It is consistent with the whole Git model (lesson 01-04): the commit is immutable, so a verdict on it remains valid forever. If you rewrite the branch, the new commits have different hashes and the checks run again, because they are different objects.

Hence a practical consequence that confuses a lot of people: after a rebase and a push --force-with-lease, all the checks run again. It is not a platform bug. It is that the commit is no longer the same one.

The rule: block on the deterministic, inform with the heuristic. A check that fails often for no real reason teaches the team to ignore the reds, and the day the red is genuine, nobody looks at it.

Measuring coverage over the whole project produces a metric that barely moves and that punishes arbitrarily. What is useful is measuring the coverage of the lines the proposal adds or modifies, and that is worked out, naturally, from a diff:

That --unified=0 gives the diff without context: only the lines actually changed, with their numbers. It is what differential coverage tools consume. And once again the three dots (lesson 07-02), for the usual reason: we want what the branch contributes, not the difference with a main that has moved on.

In lesson 10-01 we saw these commands as the kernel's native workflow. Here they interest us for another reason: they are the universal exchange format between any tool and any repository.

A patch generated by format-patch is plain text that can be pasted into a ticket, attached to an email, saved in an archive or published on a web page. It needs no server, no account, no protocol. And git am applies it preserving authorship and message, something copying and pasting the code never does.

1. Sending a change to somebody with no shared access. An external consultant, a colleague at another company, somebody on an isolated network.

git apply --check is the dry run: it says whether the patch would apply cleanly without touching anything. And --stat shows which files it would affect. It is worth running both before applying anything that comes from outside.

2. Moving a commit between two repositories that know nothing about each other. When cherry-pick is no use because they share no history:

The -3 enables the three-way merge if the context does not match exactly. It is what turns a fragile patch into a reasonably robust one.

3. Archiving a change as readable text. A patch is self-describing and survives any platform migration. For changes that have to be kept for audit reasons, it is a better format than a link to a server that may not exist in ten years' time.

4. Reviewing without a platform. format-patch produces something that reads from top to bottom in any editor, with the commit message above the diff. For reviewing a series of commits on a plane, it beats any web interface.

We already saw it in the previous lesson. Here just one specific use that is surprisingly handy: generating the text of a proposal.

It produces a summary with the base commit, the list of commits grouped by author and the diffstat. Pasted into the description of a large proposal, it saves the reviewer the work of figuring out the scope.

And as glue between the two worlds: a platform proposal can be turned into patches, because every proposal is, underneath, a set of commits on a branch.

That refs/pull/42/head is a refspec (lesson 04-01) that platforms expose for accessing proposal branches. It also works for reviewing them locally:

Reviewing a proposal by running it rather than merely reading it is, by a wide margin, the most effective way of reviewing. And it is one of the things the convenience of the web interface has made a lot of people stop doing.

We close with the criterion, which is what gives unity to everything above.

• The task is repetitive and deterministic: formatting, sorting imports, checking the format of a message.
• The mistake is frequent and detectable: forgetting the ticket, committing a configuration file with credentials, leaving trailing whitespace.
• The check is objective: it passes or it does not, with no human judgement.
• The saving is for the whole team, not just for you.

• The operation is irreversible and contextual: rewrites, force pushes, deletions.
• The decision requires judgement: whether a change is a good idea, whether the abstraction is the right one, whether the message explains the why well.
• The automation hides something you need to understand.
• The cost of a false positive is high: if it blocks the team's work for no reason, it will be switched off, and the good checks will go with it.

Recapping the whole lesson in a specific configuration:

Notice that most of the benefit is in the repository row: four text files that travel with the project and that benefit everybody without anybody having to configure their machine.

Mistake 1: using "Sync" without knowing what it does. It is the mistake of this lesson. Check git config --get pull.rebase and decide consciously. If the button does pull --rebase and you have published the branch, every sync may rewrite commits others already have (lesson 05-01).

Mistake 2: installing hooks nobody else has. Hooks are not distributed with the repository (lesson 06-01). If your team depends on a check, it has to be in CI or in a server hook. Local hooks are a personal convenience, never a guarantee.

Mistake 3: slow hooks. A pre-commit that takes fifteen seconds makes people commit less often and with bigger changes, or use --no-verify systematically. A client hook should take less than two seconds and check only the staged files.

Mistake 4: linting the disk instead of the index. If you have unstaged changes, you are validating something that is not what you are about to commit. Use git diff --cached --name-only --diff-filter=ACM and the stash --keep-index trick.

Mistake 5: trusting the editor's blame without .git-blame-ignore-revs. After a mass reformatting, blame will tell you the whole file was written by whoever ran the formatter. Ten minutes of configuration fix it forever and for the whole team.

Mistake 6: blocking integration with noisy checks. A heuristic analysis with false positives, set as blocking, makes the team learn to ignore the reds. Block on the deterministic, inform with the rest.

Mistake 7: reviewing only through the web interface. For large proposals, fetch the branch and run it. git fetch origin refs/pull/N/head:pr-N and git diff main...pr-N give a far better review than a browser does.

Tip 1: watch your tool's command log for a week. Almost all of them have a console where they show what they run. It is the fastest way of learning the correspondence between buttons and commands.

Tip 2: put Git status in your prompt today. Of everything in this lesson, it is what prevents the most mistakes per minute invested, above all the in-progress operation indicator (|REBASE, |MERGING).

Tip 3: put the shared configuration into the repository. .editorconfig, .gitattributes, .gitignore and .git-blame-ignore-revs are four text files that make the project behave the same for everybody without depending on each person's machine.

Tip 4: when something odd happens in the interface, go to the terminal. git status, git log --oneline --graph -20 and git reflog tell you where you really are. The interface shows an interpretation; the commands show the state.

Carla uses her editor for everything. Describe what is happening in each situation and which command is underneath:

A. She presses "Sync changes" with three unpushed local commits. When it finishes, her three commits have different hashes from before.

B. She presses "Discard changes" on a file with two hours of uncommitted work. She asks whether she can recover it with git reflog.

C. She presses "Undo last commit" and her changes reappear as staged in the changes panel.

Write a commit-msg hook for task-manager that:

1. Rejects the commit if the subject does not follow Conventional Commits (type(optional scope): description).
2. Rejects the commit if the subject exceeds 72 characters.
3. Warns but does not reject if the message does not mention any GT-NNN.
4. Does not get in the way on merges or on automatic rebase/revert commits.

Explain why point 3 warns instead of rejecting.

Diego has opened proposal number 57 on task-manager, with 14 commits and 800 lines changed. Ana wants to review it seriously: understand the changes, run the tests and leave well-founded comments.

Write the sequence of commands you would use, explaining what each step contributes. Include what you would do if Diego pushes a corrected version and you want to see only what has changed relative to what you already reviewed.

Solution 1

A. "Sync" has done pull --rebase and then push.

The hashes change because the rebase (lesson 05-01) rebuilds each commit on the new base: the parent changes, and since a commit's hash includes its parent's (lesson 01-04), the whole hash changes.

What is underneath, according to her configuration:

Is it a problem? It depends on whether the branch was published:

• A local branch, never pushed: nothing happens, this is what you want.
• A published branch with somebody else working on it: she has just rewritten shared history. The subsequent push either was rejected, or was forced by the tool, leaving everybody else with a divergence (lesson 09-03).

Recommendation: Carla should check that setting consciously. pull.rebase = true is a good default for personal branches, but with a button that triggers it without asking, it is worth knowing about.

B. "Discard changes" is git restore <file>, and NO, it cannot be recovered with the reflog.

This is the critical distinction of the whole of module 9:

Her two hours of work, if she never ran git add, do not exist as far as Git is concerned. All that is left is to look at the editor's own local change history, which many editors keep and which is the only safety net in this case.

The lesson: git add is not just "stage for committing", it is also "save a recoverable copy". It is the definitive argument for staging early and often.

C. "Undo last commit" was git reset --soft HEAD~1.

The commit disappears from the branch and its changes stay in the index (which is why they appear as staged). With --mixed (reset's default) they would appear as modified but not staged; with --hard they would have disappeared.

The editor using --soft is the right thing for "undo the commit but keep the work". And the original commit still exists: git reflog shows it and git reset --hard HEAD@{1} restores it (lesson 09-02).

Solution 2

Why point 3 only warns:

1. Legitimately, there is not always a ticket. Fixing a typo in the README.md, adjusting the CI configuration or a maintenance chore do not always have a ticket, and forcing people to invent one degrades the ticketing system: it fills up with fake entries created to satisfy the hook.

2. A hook that rejects too much gets switched off. As soon as somebody has to use --no-verify once a week, they stop using the hook. And in switching it off they also lose rules 1 and 2, which genuinely are valuable. One over-strict rule weakens the good ones.

3. Rules 1 and 2 are objective; rule 3 is contextual. The format of the subject admits no reasonable exception. The presence of a ticket does. It is the same distinction as in section 8: block on the deterministic, inform with the heuristic.

4. If the team decides the ticket is mandatory, that rule has to be on the server or in CI, not in a local hook. A local hook is no guarantee to anybody but you.

The exclusions at the start matter too: a hook that rejects messages generated by git merge or git revert turns normal operations into an ordeal, and it is the number one reason hooks end up in the bin.

Solution 3

The three dots are compulsory (lesson 07-02): they give what the branch contributes since it separated from main, not the difference with the current main. With two dots, any advance in main would appear as if Diego had undone it.

There is already a lot to learn here. Fourteen well-split, well-named commits are reviewed one at a time; fourteen commits called "fixes" and "wip" have to be reviewed as a single block, and it deserves a comment asking him to tidy them up with rebase -i (lesson 05-02).

Step 5 is what distinguishes a real review from a read-through. Running the branch detects things no diff shows: that the interface ends up misaligned, that there is an incomprehensible error message, that an operation takes three seconds.

To review the second version, after Diego redoes the branch:

git range-diff (lesson 07-02) is exactly the tool for this: it compares two versions of the same series of commits and shows a diff of diffs. It pairs up the equivalent commits and marks each one:

• = unchanged relative to the previous version.
• ! the same commit but with modified content, and it shows what changed inside.
• < / > commits removed or added in the new version.

In a proposal of 14 commits where Diego has only corrected two, range-diff shows you those two and saves you reviewing the other twelve again. It is the command that makes reviewing long series sustainable, and the reason the kernel model (lesson 10-01) can afford to reach version 5 of a series.

The + in +refs/pull/57/head:pr-57 is the forced refspec (lesson 04-01): it allows the local reference to be updated even when the advance is not a fast-forward, which is exactly what happens when the other side has rewritten its branch.

Git is an engine; everything else is bodywork. This lesson has gone over that bodywork with one constant criterion: use what it contributes, always knowing what is underneath.

• Editors and IDEs genuinely contribute on the visual side: differences in the gutter, conflict resolution with the common base in view (merge.conflictStyle = zdiff3), inline blame and staging hunks with the mouse. Every button has a command behind it, and the most dangerous one is "Sync", which can rewrite your history according to a setting you may not remember putting there.
• In the terminal it is worth carrying on doing everything irreversible or conceptual: rewrites, divergences, reflog, --force-with-lease, bisect, debugging and precise log queries. The rule: use the interface to look, the terminal to decide.
• Graphical clients win clearly at drawing the graph and comparing arbitrary points in the history. Git brings its own (gitk, git gui) and they are everywhere.
• A well-equipped terminal — Git status in the prompt, completion and Git aliases (06-04) — is the improvement with the best effort-to-benefit ratio in the module. The |REBASE 2/5 indicator on its own heads off a whole category of trouble.
• Ticketing systems close the GT-NNN convention we have used throughout the course: the branch, the commits and the proposal carry the identifier, integration closes the ticket, and the result is being able to answer in thirty seconds "what changed with GT-231?" and "is it in production?".
• Quality tools hook in at three places — editor, client hook and CI — and the healthy combination is editor + CI: the first gives an immediate answer, the second guarantees compliance, because local hooks neither get distributed nor enforce anything. .editorconfig solves at the source what .gitattributes solves at the boundary.
• Status checks are associated with a commit hash, not with a branch: that is why rewriting the branch launches them all again. Block on the deterministic, inform with the heuristic.
• format-patch, am and request-pull are the universal exchange format: they move a change with its authorship and its message between repositories that know nothing about each other, with no server and no permissions. And refs/pull/N/head lets you bring any proposal down locally to review it by running it, which is the only kind of review that finds certain problems.

The underlying idea, which is the same one we opened with:

Automate the repetitive and deterministic. Always understand which command is underneath. And keep the terminal for the irreversible.

There is a kind of file that breaks everything we have set up so far. The editor cannot show its differences, the interface cannot resolve its conflicts, the linter has nothing to say about it and git diff answers with one curt line: Binary files differ.

And that is not the worst of it. The worst is that Git stores every version in full, forever, and everybody who clones the repository downloads them all. A designer who updates an 80 MB file five times has just added 400 MB to everybody's history, and deleting it achieves nothing, because the objects are still there (lesson 08-06).

In task-manager that problem does not exist yet. But the team is about to take on graphical assets, demonstration videos and the design files for ui-components, and it is best to sort it out before the history is contaminated, not afterwards.

Lesson 10-03: Git LFS for Large Files closes what we left pending in lessons 06-05, 08-04 and 08-06: what exactly that filter=lfs diff=lfs merge=lfs -text that appeared in .gitattributes is, how a file gets replaced by a text pointer, and what you need to know — including the awkward limitations — before adopting it.