What This Book Did Not Cover
This book taught the part of Git you use every day and deliberately left out the rest. Here is the list, honestly, with what each thing is and where it is taught properly — so that nothing you meet next year arrives as a surprise or as evidence of a gap in you.
Notice the reason for each omission. Almost none of them is "too difficult". Most are "not needed yet", and several are "can lose work".
Rebase
Replaying your commits on top of another branch, so the history comes out as a straight line instead of showing where two efforts joined.
It is genuinely useful and genuinely capable of destroying shared work, which is why this book merged instead. A beginner who rebases a branch someone else is using loses their commits; a beginner who merges gets an untidy graph and keeps everything. That trade was deliberate, and it is the single largest omission here.
Rewriting history
Interactive rebase for editing a stretch of past commits, squashing several into one, and removing a file from every commit it ever appeared in — the proper answer to Chapter 5's committed secret.
All real, all sharp, all requiring coordination with everyone who has a copy. Deep-dive material, and reasonably so.
Tags and releases
Marking a specific commit as version 1.0 and publishing it as something people can download. You will meet this the first time you ship anything, and it is small enough to learn in an afternoon when you need it.
Internals
How Git actually stores commits, what a ref is, why the hash is what it is, how identical content is stored once rather than a thousand times.
You need none of it to work, which is why this book kept saying so. What it buys is diagnosis: when Git behaves in a way that seems arbitrary, internals is where the reason lives. It is the deep dive's opening chapter, and it is the fastest way to make Git stop feeling like a set of rules.
Everything else, briefly
git bisect finds which commit introduced a bug by searching the history for you, and it feels like magic the first time. Submodules put one repository inside another. Large file storage handles the video from Chapter 10 properly. Hooks run your own scripts automatically when you commit or push. Worktrees let one repository have several folders checked out at once. Signing proves a commit really came from you.
These are named so the words are familiar when you meet them. That is all this page owes them.
Where to go
Git, GitHub & GitHub Actions covers all of it, and it starts from a reader who knows exactly what this book taught. Fourteen chapters: Git in depth, the object model, history rewriting, remotes and large repositories, GitHub properly, team workflows, and three chapters on GitHub Actions, which is the subject of the next page.
The honest advice about when to start it is in the last topic of this book, and it is not "immediately".
What you can do now
Worth saying explicitly, because a list of omissions can leave the wrong impression.
You can put any project under version control and keep a history worth reading. You can branch, merge, and resolve a conflict without help. You can undo every common mistake, and find work that appears to be lost. You can push to GitHub, clone anything, open a pull request, review someone else's, and contribute to a stranger's project.
Sandpiper never needed anything on the omissions list, and that is the honest reason none of it is here: a real small project runs for years on Chapters 1 to 10.
- "These were skipped because they are advanced tricks." They were skipped by order rather than by difficulty. Several of them can lose work, and none is needed in the first months.
- "I should learn rebase immediately to look professional." Plenty of teams forbid it on shared branches. Merging is never wrong, and learning rebase when a team asks you to is soon enough.
- "Not knowing the internals means I do not really know Git." You know what Git does. Knowing how it is built makes you faster at diagnosis, and that is the next book rather than a missing foundation.
- "A book that leaves things out has left me unprepared." The things left out are the ones a first year rarely needs. The things included are the ones every working day uses.
- An honest boundary prevents two failure modes at once: believing the book covered everything, and reading its gaps as personal deficiencies.
- Knowing the name of a thing is most of what you need to look it up. That is what this page is for.
- Naming the deep dive as the successor gives the reader a specific next step rather than a vague instruction to keep learning.
Knowledge Check
Why does this book teach merging rather than rebasing?
- Because a mistaken rebase on shared work loses commits, and a merge does not
- Because rebase is much harder to understand than merging for a newcomer
- Because rebase is being removed from Git in favour of merge in future versions
- Because merging produces a smaller repository than rebasing does
What does knowing Git's internals actually buy you?
- Faster diagnosis, because behaviour that seemed arbitrary has a reason
- The ability to use commands that are otherwise inaccessible to beginners
- A repository that performs better because you can configure storage directly
- Protection from mistakes, since understanding the storage prevents lost work
Which of these was left out because it can lose work rather than because it is difficult?
- Rebase, which replays commits and can destroy shared history
git bisect, which searches the history for the commit that broke something- Tags, which mark a specific commit as a released version of the project
- Submodules, which place one repository inside another one
What is the intended next step after this book?
- Git, GitHub & GitHub Actions, which begins exactly where this one stops
- A course on a different version control system, for a broader perspective
- Nothing — the daily loop is all anyone needs for a full career in software
- The deep dive's final chapters only, since the early ones repeat this book
You got correct