Git 2.23.0: Forget about checkout, and switch to restore.

Alberto de Murga
Blue Harvest Tech Blog
4 min readAug 21, 2019
Screenshot of a git tree.
Photo by Yancy Min on Unsplash

Today, discussing at Blue Harvest the new article of Jay Rajani, I found out that the new improvements in usability of Git 2.23.0 are not much spread yet. Releases in established well-known open source projects like the Linux kernel, git or vim usually do not bring much new hot stuff for the common folks, but the changes in the last release of git are really something.

Probably you have heard about the git checkout command. This is a rhetorical question of course, because if you have ever used git, you must have realised that it is literally everywhere.

Beginning of the git-checkout man page.
That is slightly confusing.

Until last week, you used git checkout to create a new branch, to retrieve a new branch for a remote repository, to change the branch you are currently working, to remove files from your staging area, to pick up changes from a different commit, and for other more obscure tasks that are not used often and you wish you do not have to. All these functionalities crammed in one utility are annoying for experts are terrifying for beginners who will run away from the terminal like it is some type of witchery. At the end, UNIX tools are supposed to do one thing and do it well, and it has taken long time to realise that there was some room for improvement in this area.

Since version 2.23.0, there are two new commands that will delight both beginners and experts: git switch and git restore. It is important to notice that these are experimental features and they might change.

git-switch

git switch is the new tool to manage your branches. It allows you to switch to existing branches or to create and switch new branches, from the current branch, orphan or detached. In order to create, list and remove branches, you still have to use the command git branch.

The usage of this tool is much simpler than the previous git-checkout version. Lets say we want to create a new branch from master named new-feature.

λ threkk → git switch -C new-feature
Switched to a new branch ‘new-feature’
λ threkk →

And to go back to master.

λ threkk → git switch master
Switched to branch 'master'
λ threkk →
git-switch switches branches ORLY?
I would have never guess!!!

git-restore

git-restore does not only substitute git checkout but also other commands, becoming the missing link to manage the changes in the tree. Usually, in order to add a file in git, you use git add/rm <file>. Or more often, git add . (aka. commit everything you find) when you are working on a project and you have been changing a lot of things around.

You are about to commit when you realised that you also modified the secrets.sample.json used as a example in your project. That is not good, we do not want our private keys stored in git, so we need to remove them from the commit. With git-restore is easy:

λ threkk → git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: secrets.sample.json
λ threkk → git restore --staged secrets.sample.json
λ threkk →

Now, our changes are removed from the staging area. However, this is not enough for us. We want to leave the file as we found it to avoid further mistakes:

λ threkk → git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: secrets.sample.json
no changes added to commit (use "git add" and/or "git commit -a")
λ threkk → git restore secrets.sample.json
λ threkk →

This is a significant improvement over git checkout -- secrets.sample.json.

A smart reader might have realised that this is not much different from git reset, which can also be used to remove files from the staging area. The purpose of git-reset is to “Reset current HEAD to the specified state”, while git-restore “Restore working tree files”. This means that many of git-reset invocations, if not careful, might affect other files as they target HEAD rather than individual files as git-restore does.

A breeze of fresh air.

These new commands provide a more accessible and intuitive way of using git in the command line. Newcomers can rely on these new commands instead of having to learn by heart how to perform simple operations in the working tree. Old dogs can still make use of their muscle memory to manage the changes in the tree, but in those moments of doubts when your forget the correct combination, these new additions will be welcomed.

--

--

Alberto de Murga
Blue Harvest Tech Blog

Software engineer at @bookingcom. I like to make things, and write about what I learn. I am interested in Linux, git, JavaScript and Go, in no particular order.