Forem: Pauline Vos

Git Legit cheat sheet

Pauline Vos — Wed, 12 Mar 2025 09:22:24 +0000

This is a repost of my 2018 Git cheat sheet, due to getting rid of my personal blog :) Enjoy

I’ve given my talk about best practices in Git a few times now, and I’ve had several people come up to me asking if I’m going to upload the slides, or “what was that one Git command again?” I thought it might be a good idea to offer a cheat sheet based on the talk to refer them to in the future. Maybe throw in some handy resources.

So here you go 🙂 There’s a lot more options to Git than this, but this is what I use daily to easily keep my commits atomic and my sanity in tact.

Here’s a quick recap of the talk. It explains atomic commits and why they’re a Good Thing™. You’ll need them for the below to help you

Add changes to your last commit

Stage your changes with git add ., then amend them to your last commit with git commit --am. Edit your commit message and/or description if desired, and write the file.

Change several past commits

Go into interactive rebase with git rebase -i HEAD~5 where 5 is the number of commits you want to go back. Change pick into e for edit on any commit you want to change. Write the file. Make the changes you want to do on that commit. Continue to the next commit with git rebase --continue. It will first offer you to change the commit message and/or description, similar to when you git commit --am.

Stash your changes

You can stash away your changes with git stash and retrieve them later with git stash pop. Very handy if you’ve made some changes that you want to add to a commit further back than your latest one.

Drop a commit

Enter interactive rebase. Simply delete the line that shows the commit you want to drop. Write the file. Done.

Change the order of commits

Enter interactive rebase. Cut the line of a commit you want to move. Paste it anywhere in the list to change the order, and write the file.

Reset a commit

Resetting a commit will remove the commit and make all its changes reappear in your working directory (soft reset). Especially handy when you’ve made a quick checkpoint commit and want to organize all the changes into relevant commits. Use git reset HEAD~ to reset your latest commit. Add a number to the end to reset that many of your latest commits.

Adding the --hard option will remove the changes entirely, as if they never happened.

Take a commit from another branch

git log [branch] where branch is the name of the branch that has the commit. Find the commit you want. Copy the commit hash. Move back to your own branch. Cherry-pick the commit with git cherry-pick 887ab710ac81a5d8cf6986305e9303ae5771b602 (replace with the commit hash).

Stage a hunk of changes

Instead of staging all the changes in a file, you can stage hunks of changes separately so as to add them to their respective atomic commits. Do this with git add --patch some-file.php. Git will stop at each hunk and ask you if you want to stage it (y, n).

Some other options are: –d: Don’t add this and any remaining hunks. You’re finished. –s: Split the hunk into smaller hunks.
–e: Manually edit the hunk. Keep in mind you're editing _which changes you want to stage`. You are not affecting the actual change.

Find the commit that broke something

You’re a bunch of commits along and notice something’s broken along the way. You can either check out every commit separately (takes a while), or use the binary search method (takes less time). Here’s how:

– git bisect start
– git bisect bad will mark your HEAD as the bad commit. Pass a commit hash if the bad commit it an earlier one.
– git bisect good 887ab710ac81a5d8cf6986305e9303ae5771b602 (replace with hash of good commit)

Git will now check out a commit somewhere in the middle. Check if it’s broken (bad) or not (good) and mark it in the same way as the last two steps. Repeat this until there’s nothing more to check. The CLI output will give you the first bad commit

– Run git bisect reset to leave the bisect.

Fix bugs ⚡ fast with regression tests and auto-bisect

Pauline Vos — Wed, 17 Mar 2021 15:54:04 +0000

Even if you have amazing test coverage (don’t we all?), chances are you’ll still run into unexpected behavior in your application. You may have missed a case, or you may not have thought it was crucial to test at the time. Whatever the reason, it can be tricky to debug unexpected behavior after the fact. Once you do find and fix the bug, you might create a regression test to prevent it from happening again…

… but did you know you can write the regression test first and make it debug for you?

NOTE: If you haven’t heard of atomic commits or interactive rebase, now might be a good time to read my post + cheatsheet on that.

Take this completely reasonable and realistic scenario: you write an application for a dragon whose sole job it is to destroy villages:

class Trogdor 
{
    /** * @var Type */ 
    private $type; 
    public function __construct(Type $type = null) 
    { 
        $this->type = $type ?? Type::dragon(); 
    } 
    public function burninate(Village $village) 
    { 
        foreach ($village->getCottages() as $cottage) { 
            $cottage->burn(); 
        } 
    } 
    public function getType(): Type 
    { 
        return $this->type;
    } 
}

You did some refactoring and you’re a bunch of commits in, when suddenly you notice your dragon has stopped burning cottages. When and how did this happen? Let’s assume you know that last week everything was working fine.

Step 1: write a test

First, write a regression test that covers your expected behavior. At this point it will fail. Commit your test. Don’t worry about writing a pretty message.

class TrogdorTest extends TestCase
{
    public function testCottagesShouldBurn()
    {
        $application = new TrogdorApplication(new Trogdor(), Village::withCottages());
        $application->run();
        foreach ($village->getCottages() as $cottage) {
            self::assertTrue($cottage->isBurned());
        }
    }

}

Step 2: move the test

Using interactive rebase, move the commit back in time to the point everything was still working. In this example we’ll just assume that wasn’t so long ago, but bisect is especially useful in situations where you have many more commits to work through.

 git rebase -i HEAD~7

A file will open in your default text editor. Cut and paste the line to a place in time where the test will pass, then save and close the file:

pick 1b81fc5 Create Trogdor 
pick 51927a0 TROGDOR TEST
pick cf3ea2d Introduce dragon types
pick 6882ded He was a man
pick 95a11c7 I mean he was a... dragonman
pick 0f763a8 Or maybe he was just a... dragon
pick 8587b82 Add people to the cottages

This will reorder the commit. To check that the test now passes, you can check out the commit and run it:

git checkout 51927a0    // Replace this with the correct commit ID.
phpunit TrogdorTest.php // Check that this passes.
git checkout -          // Return to your HEAD.

Step 3: run bisect

If you’re unfamiliar with bisect, in a nutshell it’s a Git feature that helps you find a point in history efficiently. Instead of manually checking out and investigating commits one by one, bisect will automatically check out commits for you using a binary search strategy, making it much more efficient. Again, you might want to head over to my cheatsheet and jump to bisect for more context.

You can run bisect automatically by feeding it any script that will either succeed (exit code 0) or fail (anything else). That’s how tests succeed or fail, so your test is one such script. If you provide bisect a commit on which the test will pass (good), and one on which it will fail (bad), it will use binary search to automatically find the first point in time where it will fail:

git bisect start
git bisect good ea7753a                // Mark the passing commit as good
git bisect bad HEAD                    // Mark your HEAD as bad
git bisect run phpunit TrogdorTest.php

When bisect is finished running, it will present the commit that introduced the bug:

0f763a8374ecb38fdc02657f0502495227cb2d94 is the first bad commit

You can then exit bisect by running git bisect reset.

Step 4: fix the bug

Now that you know which commit introduced the bug, you can check it out and inspect the changes it introduced. In this case, it seems that you forgot to change a conditional that checks Trogdor’s type when you changed his default type from dragonMan to dragon:

class Application
{
    /**
     * @var Trogdor
     */
    private $trogdor;

    /**
     * @var Village
     */
    private $village;

    public function __construct(Trogdor $trogdor, Village $village)
    {
        $this->trogdor = $trogdor;
        $this->village = $village;
    }

    public function run()
    {
        if ($trogdor->getType()->isDragonMan()) { // <- This should check for `isDragon()`!
            $trogdor->burninate($village);
        }
    }
}

In your detached HEAD state, do what you need to do to make the test pass. Create a commit for the fix, and check out a new branch from there.

Step 5: apply the fix
Great, so now you’ve implemented a fix. But you’ll probably want to apply it to your original branch and commit it together with your test. So copy the commit ID of the fix, and check out your previous branch. Then, cherry pick your fix so that it’s on your branch:

git cherry-pick cc78654

Now, enter interactive rebase, move your test commit, and squash them together. Don’t forget to write a nice commit message describing the what and the why.

git rebase -i HEAD~8
pick 1b81fc5 Create Trogdor 
pick cf3ea2d Introduce dragon types
pick 6882ded He was a man
pick 95a11c7 I mean he was a... dragonman
pick 0f763a8 Or maybe he was just a... dragon
pick 8587b82 Add people to the cottages
pick cc78654 fix

All done! Of course, this was a simplified example. But in complex projects, it can be very hard to pinpoint exactly what went wrong. Especially if you’re looking at 20+ commits. You don’t want to go through them one by one, and with this strategy you won’t have to.

If you want to try it out yourself, clone this repo and check out a branch called 4_bisect. I’ve broken a test in the HEAD. The commit you’ll want to mark as good is 85ce6e4 Fix risky tests. Good luck 🙂

Atomic commits will help you git legit.

Pauline Vos — Wed, 17 Mar 2021 12:20:09 +0000

I’ve given a talk (Git Legit) a few times that basically makes a case for atomic commits. I’ve created a cheatsheet to go with it, but then I realized there’s no point to the cheatsheet if you don’t use atomic commits. Then I realized you won’t start using atomic commits until you know the benefits. So, here’s basically a short recap of my talk if you haven’t seen it.

When I started using Git, I used it as a save point. Similarly to when you’re playing a video game, made a bunch of progress, and think “I should probably find a save point or I’ll lose all my progress”. This makes a lot of sense; we’re used to this linear, “checkpoint” mindset. But I shifted from the “checkpoint commit” mindset to atomic commits and haven’t looked back once.

Firstly, what are atomic commits?

Atomic commits, in short, are what they sound like: atomic. So small that they can't be broken up any further. I feel like there’s basically three features a commit needs to have to be atomic:

In short, all your tests need to be green on every commit and your application shouldn’t break. Every commit has a clear commit message and a description detailing what the purpose of these changes was. Lastly, the commit should only have changes pertaining to one fix or feature (or whatever you were working on). Don’t have commits where you “fixed that bug and also implemented the feature and then also refactored some class”.

Why, you ask? Well,

Atomic commits have big benefits

For me, one of the biggest advantages of atomic commits is spending a LOT less time solving merge conflicts. Because all your commits are concentrated to a certain part of the code, merging and rebasing become so, so much less painful. You’ll have a lot more context to the conflict and your conflicts will become smaller and much more rare. Any time you need to rebase your branch will go much more smoothly. Also, dropping and cherry-picking commits become very handy options.

Atomic commits also make code review much more pleasant. You’ll be able to review commit by commit, which will give your brain less information overload and offer a clear context of what you’re reviewing. After all, the commit is about one fix or feature only, and the message and description are clear and concise. Having this context and diminished confusion will not only make reviewing more pleasant; it will make you better at reviewing. This commit by commit review isn’t possible if you’re using git like a save point, creating checkpoint commits. That’s because they’re based on time, not on a portion of the code. Consequently, you might request changes or comment on one commit, when that particular change was already undone in a next commit. You just hadn’t gotten to that commit yet. Very inconvenient.

Lastly, your history becomes much more relevant. Without atomic commits, it becomes difficult to be descriptive in your commit messages, since you’re touching different areas of the code and not focusing on one central theme per commit. So, at a glance, people won’t be able to tell what happened in your history. Take this scenario:

You fix a bug. Commit. You realize you broke something else in the process. Another commit. You address comments on your PR. Commit. And so on, and so on. You end up with this:

Anyone looking through your history won’t know what commit actually fixed the bug. Without the context of your PR, the upper commit messages have no meaning. Every commit captures your application in a broken state, so you can’t revert comfortably. All you really wanted was to fix the bug. So amend your initial commit until you’ve actually fixed the bug.

How, you ask? Well, here’s

How to keep your commits atomic

While on your task/feature/whatever branch, group all the changes to their relevant commits. This means you’ll need to change your commits if you make any changes to them afterwards. This is possible through interactive rebase and amending.

Please note: any time you change a commit, it changes the commit hash. This means that if you try to push it to your origin, it will be rejected (your origin thinks the commit doesn’t belong there), unless you git push -f. You should probably protect master and any other important branches.

My cheatsheet lays out some handy commands Git offers to help you keep your commits atomic. It takes some learning and getting used to, but you’ll breathe a lot easier once you do.

A Bit About Kanban

Pauline Vos — Wed, 17 Mar 2021 12:08:44 +0000

I have a lot of feelings about Kanban. Mostly because I’ve had brilliant experiences with it, and I see it go wrong so often. As with anything new in software development, knowing why it was designed a certain way is essential to its successful adoption.

The main reason I see teams make the switch from Scrum to Kanban is because they think it’s more flexible, and there’s essentially no rules. While in some ways that’s true, that mindset is a common pitfall. And, of course, this misconception will often lead to the conclusion that Kanban sucks, and a frustrated team switching back to Scrum or some strange hybrid for the n-th time.

Let’s have a look at some commonly held views about Kanban:

There is no commitment in Kanban.

FALSE: while the team does not commit to a set of stories over a cycle, once a task is picked up and moving along the board, it is committed to. It cannot suddenly be taken out or abandoned for no good reason.

You can constantly change prioritization in Kanban.

FALSE: once an item is picked up, it has to move forward on the board and cannot be swapped with something deemed higher priority (unless an expedite lane is implemented). However, as the team doesn’t plan for a sprint cycle, anything in the ready column or in the backlog can be moved up or down in priority. So it does give the team more flexibility in prioritization to a degree.

There are no rituals in Kanban.

TRUE: Kanban does not dictate that the team must have retro or planning sessions like Scrum does, but it also leaves teams free to have them if they so please. Many teams still prefer having a regular retrospective to reflect on their process or check in on team dynamics. And that’s totally fine!

As you can see, although there are fewer than in Scrum, ground rules definitely exist. I’d even argue that to be successful with Kanban, the few rules it has should be followed quite strictly. There are reasons these rules exist, and, just like the rules in the Scrum framework, I would not forego them unless you know why they exist and why you’re doing it.

Most of the “why” boils down to this: Kanban is designed to show you flaws in your process. The goal is to optimize your work pipeline to be as smooth as possible, always flowing. This means your main priority is to remove bottlenecks. The rules in Kanban all work towards showing you where these bottlenecks exist:

Each column has transitioning rules dictating when a task can be moved into it.
Every column has a WIP (work in progress) limit. The amount of tasks in a column can never exceed it.
Tasks move column to column from left to right. They never move back.
You can only work on one task at a time (but multiple developers working on one task is allowed). If you switch to another task for a while, you unassign yourself from the current task and anyone else on the team can pick it up.
Kanban is a pull system, meaning a tast is only pulled (not pushed) into the next column, when that column has availability.
Tasks on the right of the pipeline have priority, clearing the path for tasks on the left to be pulled in.

That’s really about it. The WIP limits prevent developers from moving forward with a task if the subsequent column has already reached its limit. Not being able to move tasks around makes it so that devs are forced to clear work further along in the pipeline.

The Phoenix Project is a “Dev-Ops novel” that follows a character who’s faced with the challenge of delivering a complex project in a highly unstable environment. He meets an enigmatic mentor, who compares the software development process to a factory, with work stations and conveyor belts. If you think about it, the above rules apply to such a factory too. If one work station has reached its maximum capacity, the conveyor belt has to be stopped until the work station is cleared. There’s no use in piling more work onto the work station, because it’s not going to make the work station clear out any faster. It will only make subsequent items get stuck on the same things, and actual output will be minimal. The same applies to your software development pipeline.

Following these rules strictly may become annoying, but that’s exactly the point. Kanban is meant to feel uncomfortable sometimes. Bottlenecks become painfully obvious, and the team is motivated to resolve them. This in turn improves predictability and productivity. Before you know it, the entire process feels smooth and beautiful ✨

Take a conversation that happened today:

This seems like a fairly straightforward decision. There’s no hard rules, right? Shouldn’t be a problem to increase the WIP limit, surely? Sure, but the question is always “why?”. Is there a reason the column can’t be cleared out?

And, sure enough:

By increasing the WIP limit any time the pipeline is blocked, this problem would never have been noticed. Now, with the underlying issue revealed, the team can ask themselves how to resolve it. Maybe the technical solution should be documented somewhere in the ticket? Maybe everyone should push to origin before going home?

Of course, any decision is still up to the team. Nobody’s calling the Kanban police 🚓 if you break a rule. But trust me: you’ll do yourself a massive favor if you ask yourself “why?” any time you’re tempted to break any of the rules mentioned above. More often than not, I think you’ll find you’ll change your mind.

Do you still have hangups about your Kanban process? Let’s see if we can resolve them in the comments.