The Case for Pull Rebase
When using a trunk-based workflow, the standard git pull clutters your history with merge commits, simply due to the asynchronous nature of collaboration. Fortunately, there's a somewhat obscure way to make things right.
Over the years, I've both written and spoken about Git in articles, talks, workshops and online courses, and I've answered more than a few questions about it on Stack Overflow.
More than once, I've wanted to link to one of those and couldn't find it. This page gathers everything in one place.
I made a rule for myself: every time I learn a new peculiar thing about Git, I write it down. Every once in a while, something needs more explaining than a note, and it becomes an article.
When using a trunk-based workflow, the standard git pull clutters your history with merge commits, simply due to the asynchronous nature of collaboration. Fortunately, there's a somewhat obscure way to make things right.
Your repository has more commits than what meets the eye. They hide somewhere in the .git directory, where you can't see them, but they're there. Knowing where to find them can mean the difference between recovering your work and losing it to the sands of time.
One of the things you often want to know is which commits are in what branch. You wouldn't believe how cumbersome some version control systems make answering such a simple question. With Git, it's as easy as pie.
You're in the middle of rewriting your local commits when you realise you've gone too far and, after one too many rebases, you're left with a history that looks nothing like what you wanted. Here's the git undo command I came up with, and how I got there.
Version control is the rear mirror through which we look at the history of a code base before we go on to shape its future. Among everything it captures, the most critical part is the commit messages.
When I first got into Git, the most frustrating part was the lack of guidance on how to interpret the myriad of commands and switches. What I wanted was a way to see how each one changed the state of my repository.
Sometimes I have more to say than fits in an article or a talk. That's when I make a course instead.
Speed up common tasks, keep a clean history, undo mistakes and even debug, all using Git's lesser-known power features.
Git beyond the basics: working from the command line, crafting commits, searching and rewriting history, recovering from mistakes. Now retired.
My most popular talks about Git. Where a talk was recorded, there's a link to the video.
There is more to Git than meets the eye. On the surface, it's a version control system. Underneath, it's a virtual file system built to track your files. And right in between is a wealth of productivity features very few people know about: from automating common daily tasks to better handling of merge conflicts, the quality-of-life improvements you always wished you knew about.
What I've learned from working with people who are really good at being productive with Git: the things you can do to make Git more pleasant to work with and improve the way you collaborate with the rest of your team. Success starts with good habits.
How Git works from the ground up: its fundamental concepts and how they're implemented in the object model, then up to the user-facing commands and how to use Git's unique features to craft a beautiful history without compromising on your workflow.
Exactly what Git can do for you that none of the GUI tools ever tell you about: moving chunks of commits between branches in a single command, custom history visualisations, data recovery. All 100% from the command line.
Taking advantage of Git's advanced, and therefore lesser-known, features to take your daily workflow to the next level, with a graphic representation of the repository showing how each command affects the underlying history.
The Git zen from the inside out. Working from real-world scenarios, from Git's core concepts and building blocks up to its advanced features, showing graphically what happens under the covers every time you run a command.
I also teach Git in person, as one-day workshops for teams: Understanding Git for people new to it, Mastering Git for everyone else.
Workshops →Want me to speak at your company or event? Interested in hiring me? I'd love to hear from you.