@@ -122,7 +122,7 @@ Let's do what it says:
 
 [source,console]
 ----
-$ git checkout -- CONTRIBUTING.md
+$ git restore CONTRIBUTING.md
 $ git status
 On branch master
 Changes to be committed:
@@ -136,7 +136,7 @@ You can see that the changes have been reverted.
 
 [IMPORTANT]
 =====
-It's important to understand that `git checkout \-- <file>` is a dangerous command.
+It's important to understand that `git restore <file>` is a dangerous command.
 Any local changes you made to that file are gone -- Git just replaced that file with the last staged or committed version.
 Don't ever use this command unless you absolutely know that you don't want those unsaved local changes.
 =====
 
@@ -357,7 +357,7 @@ Let's explore a couple of tools that you now have at your disposal to determine
 Perhaps it's not obvious how exactly you should fix this conflict.
 You need more context.
 
-One helpful tool is `git checkout` with the `--conflict` option.
+One helpful tool is `git restore` with the `--conflict` option.
 This will re-checkout the file again and replace the merge conflict markers.
 This can be useful if you want to reset the markers and try to resolve them again.
 
@@ -366,7 +366,7 @@ If you pass it `diff3`, Git will use a slightly different version of conflict ma
 
 [source,console]
 ----
-$ git checkout --conflict=diff3 hello.rb
+$ git restore --conflict=diff3 hello.rb
 ----
 
 Once we run that, the file will look like this instead:
@@ -395,7 +395,7 @@ If you like this format, you can set it as the default for future merge conflict
 $ git config --global merge.conflictstyle diff3
 ----
 
-The `git checkout` command can also take `--ours` and `--theirs` options, which can be a really fast way of just choosing either one side or the other without merging things at all.
+The `git restore` command can also take `--ours` and `--theirs` options, which can be a really fast way of just choosing either one side or the other without merging things at all.
 
 This can be particularly useful for conflicts of binary files where you can simply choose one side, or where you only want to merge certain files in from another branch -- you can do the merge and then checkout certain files from one side or the other before committing.
 
 
@@ -200,5 +200,5 @@ At this point, you can exit the interactive adding script and run `git commit` t
 
 You also don't need to be in interactive add mode to do the partial-file staging -- you can start the same script by using `git add -p` or `git add --patch` on the command line.
 
-Furthermore, you can use patch mode for partially resetting files with the `git reset --patch` command, for checking out parts of files with the `git checkout --patch` command and for stashing parts of files with the `git stash save --patch` command.
+Furthermore, you can use patch mode for partially resetting files with the `git reset --patch` command, for checking out parts of files with the `git restore --patch` command and for stashing parts of files with the `git stash save --patch` command.
 We'll go into more details on each of these as we get to more advanced usages of these commands.
@@ -210,11 +210,11 @@ index a440db6,54336ba..0000000
 .Automatically resolved merge conflict using previous resolution
 image::images/rerere3.png[Automatically resolved merge conflict using previous resolution]
 
-You can also recreate the conflicted file state with `git checkout`:
+You can also recreate the conflicted file state with `git restore`:
 
 [source,console]
 ----
-$ git checkout --conflict=merge hello.rb
+$ git restore --conflict=merge hello.rb
 $ cat hello.rb
 #! /usr/bin/env ruby
 
 
@@ -1031,7 +1031,7 @@ Switched to branch 'master'
 ----
 
 Then, when you switch back, you get an empty `CryptoLibrary` directory for some reason and `git submodule update` may not fix it either.
-You may need to go into your submodule directory and run a `git checkout .` to get all your files back.
+You may need to go into your submodule directory and run a `git restore .` to get all your files back.
 You could run this in a `submodule foreach` script to run it for multiple submodules.
 
 It's important to note that submodules these days keep all their Git data in the top project's `.git` directory, so unlike much older versions of Git, destroying a submodule directory won't lose any commits or branches that you had.