| 1 | git-checkout(1) |
| 2 | =============== |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-checkout - Switch branches or restore working tree files |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | [synopsis] |
| 11 | git checkout [-q] [-f] [-m] [<branch>] |
| 12 | git checkout [-q] [-f] [-m] --detach [<branch>] |
| 13 | git checkout [-q] [-f] [-m] [--detach] <commit> |
| 14 | git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>] |
| 15 | git checkout <tree-ish> [--] <pathspec>... |
| 16 | git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul] |
| 17 | git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>... |
| 18 | git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul] |
| 19 | git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...] |
| 20 | |
| 21 | DESCRIPTION |
| 22 | ----------- |
| 23 | |
| 24 | `git checkout` has two main modes: |
| 25 | |
| 26 | 1. **Switch branches**, with `git checkout <branch>` |
| 27 | 2. **Restore a different version of a file**, for example with |
| 28 | `git checkout <commit> <filename>` or `git checkout <filename>` |
| 29 | |
| 30 | See ARGUMENT DISAMBIGUATION below for how Git decides which one to do. |
| 31 | |
| 32 | `git checkout [<branch>]`:: |
| 33 | Switch to _<branch>_. This sets the current branch to _<branch>_ and |
| 34 | updates the files in your working directory. The checkout will fail |
| 35 | if there are uncommitted changes to any files where _<branch>_ and |
| 36 | your current commit have different content. Uncommitted changes will |
| 37 | otherwise be kept. |
| 38 | + |
| 39 | If _<branch>_ is not found but there does exist a tracking branch in |
| 40 | exactly one remote (call it _<remote>_) with a matching name and |
| 41 | `--no-guess` is not specified, treat as equivalent to |
| 42 | + |
| 43 | ------------ |
| 44 | $ git checkout -b <branch> --track <remote>/<branch> |
| 45 | ------------ |
| 46 | + |
| 47 | Running `git checkout` without specifying a branch has no effect except |
| 48 | to print out the tracking information for the current branch. |
| 49 | |
| 50 | `git checkout -b <new-branch> [<start-point>]`:: |
| 51 | |
| 52 | Create a new branch named _<new-branch>_, start it at _<start-point>_ |
| 53 | (defaults to the current commit), and check out the new branch. |
| 54 | You can use the `--track` or `--no-track` options to set the branch's |
| 55 | upstream tracking information. |
| 56 | + |
| 57 | This will fail if there's an error checking out _<new-branch>_, for |
| 58 | example if checking out the `<start-point>` commit would overwrite your |
| 59 | uncommitted changes. |
| 60 | |
| 61 | `git checkout -B <branch> [<start-point>]`:: |
| 62 | |
| 63 | The same as `-b`, except that if the branch already exists it |
| 64 | resets _<branch>_ to the start point instead of failing. |
| 65 | |
| 66 | `git checkout --detach [<branch>]`:: |
| 67 | `git checkout [--detach] <commit>`:: |
| 68 | |
| 69 | The same as `git checkout <branch>`, except that instead of pointing |
| 70 | `HEAD` at the branch, it points `HEAD` at the commit ID. |
| 71 | See the "DETACHED HEAD" section below for more. |
| 72 | + |
| 73 | Omitting _<branch>_ detaches `HEAD` at the tip of the current branch. |
| 74 | |
| 75 | `git checkout <tree-ish> [--] <pathspec>...`:: |
| 76 | `git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]`:: |
| 77 | |
| 78 | Replace the specified files and/or directories with the version from |
| 79 | the given commit or tree and add them to the index |
| 80 | (also known as "staging area"). |
| 81 | + |
| 82 | For example, `git checkout main file.txt` will replace `file.txt` |
| 83 | with the version from `main`. |
| 84 | |
| 85 | `git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...`:: |
| 86 | `git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]`:: |
| 87 | |
| 88 | Replace the specified files and/or directories with the version from |
| 89 | the index. |
| 90 | + |
| 91 | For example, if you check out a commit, edit `file.txt`, and then |
| 92 | decide those changes were a mistake, `git checkout file.txt` will |
| 93 | discard any unstaged changes to `file.txt`. |
| 94 | + |
| 95 | This will fail if the file has a merge conflict and you haven't yet run |
| 96 | `git add file.txt` (or something equivalent) to mark it as resolved. |
| 97 | You can use `-f` to ignore the unmerged files instead of failing, use |
| 98 | `--ours` or `--theirs` to replace them with the version from a specific |
| 99 | side of the merge, or use `-m` to replace them with the original |
| 100 | conflicted merge result. |
| 101 | |
| 102 | `git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]`:: |
| 103 | This is similar to the previous two modes, but lets you use the |
| 104 | interactive interface to show the "diff" output and choose which |
| 105 | hunks to use in the result. See below for the description of |
| 106 | `--patch` option. |
| 107 | |
| 108 | OPTIONS |
| 109 | ------- |
| 110 | `-q`:: |
| 111 | `--quiet`:: |
| 112 | Quiet, suppress feedback messages. |
| 113 | |
| 114 | `--progress`:: |
| 115 | `--no-progress`:: |
| 116 | Progress status is reported on the standard error stream |
| 117 | by default when it is attached to a terminal, unless `--quiet` |
| 118 | is specified. This flag enables progress reporting even if not |
| 119 | attached to a terminal, regardless of `--quiet`. |
| 120 | |
| 121 | `-f`:: |
| 122 | `--force`:: |
| 123 | When switching branches, proceed even if the index or the |
| 124 | working tree differs from `HEAD`, and even if there are untracked |
| 125 | files in the way. This is used to throw away local changes and |
| 126 | any untracked files or directories that are in the way. |
| 127 | + |
| 128 | When checking out paths from the index, do not fail upon unmerged |
| 129 | entries; instead, unmerged entries are ignored. |
| 130 | |
| 131 | `--ours`:: |
| 132 | `--theirs`:: |
| 133 | When checking out paths from the index, check out stage #2 |
| 134 | (`ours`) or #3 (`theirs`) for unmerged paths. |
| 135 | + |
| 136 | Note that during `git rebase` and `git pull --rebase`, `ours` and |
| 137 | `theirs` may appear swapped; `--ours` gives the version from the |
| 138 | branch the changes are rebased onto, while `--theirs` gives the |
| 139 | version from the branch that holds your work that is being rebased. |
| 140 | + |
| 141 | This is because `rebase` is used in a workflow that treats the |
| 142 | history at the remote as the shared canonical one, and treats the |
| 143 | work done on the branch you are rebasing as the third-party work to |
| 144 | be integrated, and you are temporarily assuming the role of the |
| 145 | keeper of the canonical history during the rebase. As the keeper of |
| 146 | the canonical history, you need to view the history from the remote |
| 147 | as `ours` (i.e. "our shared canonical history"), while what you did |
| 148 | on your side branch as `theirs` (i.e. "one contributor's work on top |
| 149 | of it"). |
| 150 | |
| 151 | `-b <new-branch>`:: |
| 152 | Create a new branch named _<new-branch>_, start it at |
| 153 | _<start-point>_, and check the resulting branch out; |
| 154 | see linkgit:git-branch[1] for details. |
| 155 | |
| 156 | `-B <new-branch>`:: |
| 157 | The same as `-b`, except that if the branch already exists it |
| 158 | resets _<branch>_ to the start point instead of failing. |
| 159 | |
| 160 | `-t`:: |
| 161 | `--track[=(direct|inherit)]`:: |
| 162 | When creating a new branch, set up "upstream" configuration. See |
| 163 | `--track` in linkgit:git-branch[1] for details. As a convenience, |
| 164 | --track without -b implies branch creation. |
| 165 | + |
| 166 | If no `-b` option is given, the name of the new branch will be |
| 167 | derived from the remote-tracking branch, by looking at the local part of |
| 168 | the refspec configured for the corresponding remote, and then stripping |
| 169 | the initial part up to the "*". |
| 170 | This would tell us to use `hack` as the local branch when branching |
| 171 | off of `origin/hack` (or `remotes/origin/hack`, or even |
| 172 | `refs/remotes/origin/hack`). If the given name has no slash, or the above |
| 173 | guessing results in an empty name, the guessing is aborted. You can |
| 174 | explicitly give a name with `-b` in such a case. |
| 175 | |
| 176 | `--no-track`:: |
| 177 | Do not set up "upstream" configuration, even if the |
| 178 | `branch.autoSetupMerge` configuration variable is true. |
| 179 | |
| 180 | `--guess`:: |
| 181 | `--no-guess`:: |
| 182 | If _<branch>_ is not found but there does exist a tracking |
| 183 | branch in exactly one remote (call it _<remote>_) with a |
| 184 | matching name, treat as equivalent to |
| 185 | + |
| 186 | ------------ |
| 187 | $ git checkout -b <branch> --track <remote>/<branch> |
| 188 | ------------ |
| 189 | + |
| 190 | If the branch exists in multiple remotes and one of them is named by |
| 191 | the `checkout.defaultRemote` configuration variable, we'll use that |
| 192 | one for the purposes of disambiguation, even if the _<branch>_ isn't |
| 193 | unique across all remotes. Set it to |
| 194 | e.g. `checkout.defaultRemote=origin` to always checkout remote |
| 195 | branches from there if _<branch>_ is ambiguous but exists on the |
| 196 | 'origin' remote. See also `checkout.defaultRemote` in |
| 197 | linkgit:git-config[1]. |
| 198 | + |
| 199 | `--guess` is the default behavior. Use `--no-guess` to disable it. |
| 200 | + |
| 201 | The default behavior can be set via the `checkout.guess` configuration |
| 202 | variable. |
| 203 | |
| 204 | `-l`:: |
| 205 | Create the new branch's reflog; see linkgit:git-branch[1] for |
| 206 | details. |
| 207 | |
| 208 | `-d`:: |
| 209 | `--detach`:: |
| 210 | Rather than checking out a branch to work on it, check out a |
| 211 | commit for inspection and discardable experiments. |
| 212 | This is the default behavior of `git checkout <commit>` when |
| 213 | _<commit>_ is not a branch name. See the "DETACHED HEAD" section |
| 214 | below for details. |
| 215 | |
| 216 | `--orphan <new-branch>`:: |
| 217 | Create a new unborn branch, named _<new-branch>_, started from |
| 218 | _<start-point>_ and switch to it. The first commit made on this |
| 219 | new branch will have no parents and it will be the root of a new |
| 220 | history totally disconnected from all the other branches and |
| 221 | commits. |
| 222 | + |
| 223 | The index and the working tree are adjusted as if you had previously run |
| 224 | `git checkout <start-point>`. This allows you to start a new history |
| 225 | that records a set of paths similar to _<start-point>_ by easily running |
| 226 | `git commit -a` to make the root commit. |
| 227 | + |
| 228 | This can be useful when you want to publish the tree from a commit |
| 229 | without exposing its full history. You might want to do this to publish |
| 230 | an open source branch of a project whose current tree is "clean", but |
| 231 | whose full history contains proprietary or otherwise encumbered bits of |
| 232 | code. |
| 233 | + |
| 234 | If you want to start a disconnected history that records a set of paths |
| 235 | that is totally different from the one of _<start-point>_, then you should |
| 236 | clear the index and the working tree right after creating the orphan |
| 237 | branch by running `git rm -rf .` from the top level of the working tree. |
| 238 | Afterwards you will be ready to prepare your new files, repopulating the |
| 239 | working tree, by copying them from elsewhere, extracting a tarball, etc. |
| 240 | |
| 241 | `--ignore-skip-worktree-bits`:: |
| 242 | In sparse checkout mode, `git checkout -- <path>...` would |
| 243 | update only entries matched by _<paths>_ and sparse patterns |
| 244 | in `$GIT_DIR/info/sparse-checkout`. This option ignores |
| 245 | the sparse patterns and adds back any files in `<path>...`. |
| 246 | |
| 247 | `-m`:: |
| 248 | `--merge`:: |
| 249 | When switching branches, |
| 250 | if you have local modifications to one or more files that |
| 251 | are different between the current branch and the branch to |
| 252 | which you are switching, the command refuses to switch |
| 253 | branches in order to preserve your modifications in context. |
| 254 | With this option, the conflicting local changes are |
| 255 | automatically stashed before the switch and reapplied |
| 256 | afterwards. If the local changes do not overlap with the |
| 257 | differences between branches, the switch proceeds without |
| 258 | stashing. If reapplying the stash results in conflicts, the |
| 259 | entry is saved to the stash list. Resolve the conflicts |
| 260 | and run `git stash drop` when done, or clear the working |
| 261 | tree (e.g. with `git reset --hard`) before running `git stash |
| 262 | pop` later to re-apply your changes. |
| 263 | + |
| 264 | When checking out paths from the index, this option lets you recreate |
| 265 | the conflicted merge in the specified paths. This option cannot be |
| 266 | used when checking out paths from a tree-ish. |
| 267 | |
| 268 | `--conflict=<style>`:: |
| 269 | The same as `--merge` option above, but changes the way the |
| 270 | conflicting hunks are presented, overriding the |
| 271 | `merge.conflictStyle` configuration variable. Possible values are |
| 272 | `merge` (default), `diff3`, and `zdiff3`. |
| 273 | |
| 274 | `-p`:: |
| 275 | `--patch`:: |
| 276 | Interactively select hunks in the difference between the |
| 277 | _<tree-ish>_ (or the index, if unspecified) and the working |
| 278 | tree. The chosen hunks are then applied in reverse to the |
| 279 | working tree (and if a _<tree-ish>_ was specified, the index). |
| 280 | + |
| 281 | This means that you can use `git checkout -p` to selectively discard |
| 282 | edits from your current working tree. See the "Interactive Mode" |
| 283 | section of linkgit:git-add[1] to learn how to operate the `--patch` mode. |
| 284 | + |
| 285 | Note that this option uses the no overlay mode by default (see also |
| 286 | `--overlay`), and currently doesn't support overlay mode. |
| 287 | |
| 288 | include::diff-context-options.adoc[] |
| 289 | |
| 290 | `--ignore-other-worktrees`:: |
| 291 | `git checkout` refuses when the wanted branch is already checked |
| 292 | out or otherwise in use by another worktree. This option makes |
| 293 | it check the branch out anyway. In other words, the branch can |
| 294 | be in use by more than one worktree. |
| 295 | |
| 296 | `--overwrite-ignore`:: |
| 297 | `--no-overwrite-ignore`:: |
| 298 | Silently overwrite ignored files when switching branches. This |
| 299 | is the default behavior. Use `--no-overwrite-ignore` to abort |
| 300 | the operation when the new branch contains ignored files. |
| 301 | |
| 302 | `--recurse-submodules`:: |
| 303 | `--no-recurse-submodules`:: |
| 304 | Using `--recurse-submodules` will update the content of all active |
| 305 | submodules according to the commit recorded in the superproject. If |
| 306 | local modifications in a submodule would be overwritten the checkout |
| 307 | will fail unless `-f` is used. If nothing (or `--no-recurse-submodules`) |
| 308 | is used, submodules working trees will not be updated. |
| 309 | Just like linkgit:git-submodule[1], this will detach `HEAD` of the |
| 310 | submodule. |
| 311 | |
| 312 | `--overlay`:: |
| 313 | `--no-overlay`:: |
| 314 | In the default overlay mode, `git checkout` never |
| 315 | removes files from the index or the working tree. When |
| 316 | specifying `--no-overlay`, files that appear in the index and |
| 317 | working tree, but not in _<tree-ish>_ are removed, to make them |
| 318 | match _<tree-ish>_ exactly. |
| 319 | |
| 320 | `--pathspec-from-file=<file>`:: |
| 321 | Pathspec is passed in _<file>_ instead of commandline args. If |
| 322 | _<file>_ is exactly `-` then standard input is used. Pathspec |
| 323 | elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can be |
| 324 | quoted as explained for the configuration variable `core.quotePath` |
| 325 | (see linkgit:git-config[1]). See also `--pathspec-file-nul` and |
| 326 | global `--literal-pathspecs`. |
| 327 | |
| 328 | `--pathspec-file-nul`:: |
| 329 | Only meaningful with `--pathspec-from-file`. Pathspec elements are |
| 330 | separated with _NUL_ character and all other characters are taken |
| 331 | literally (including newlines and quotes). |
| 332 | |
| 333 | `<branch>`:: |
| 334 | Branch to checkout; if it refers to a branch (i.e., a name that, |
| 335 | when prepended with "refs/heads/", is a valid ref), then that |
| 336 | branch is checked out. Otherwise, if it refers to a valid |
| 337 | commit, your `HEAD` becomes "detached" and you are no longer on |
| 338 | any branch (see below for details). |
| 339 | + |
| 340 | You can use the `@{-N}` syntax to refer to the N-th last |
| 341 | branch/commit checked out using "git checkout" operation. You may |
| 342 | also specify `-` which is synonymous to `@{-1}`. |
| 343 | + |
| 344 | As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the |
| 345 | merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can |
| 346 | leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`. |
| 347 | |
| 348 | _<new-branch>_:: |
| 349 | Name for the new branch. |
| 350 | |
| 351 | _<start-point>_:: |
| 352 | The name of a commit at which to start the new branch; see |
| 353 | linkgit:git-branch[1] for details. Defaults to `HEAD`. |
| 354 | + |
| 355 | As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the |
| 356 | merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can |
| 357 | leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`. |
| 358 | |
| 359 | _<tree-ish>_:: |
| 360 | Tree to checkout from (when paths are given). If not specified, |
| 361 | the index will be used. |
| 362 | + |
| 363 | As a special case, you may use `<rev-a>...<rev-b>` as a shortcut for the |
| 364 | merge base of _<rev-a>_ and _<rev-b>_ if there is exactly one merge base. You can |
| 365 | leave out at most one of _<rev-a>_ and _<rev-b>_, in which case it defaults to `HEAD`. |
| 366 | |
| 367 | `--`:: |
| 368 | Do not interpret any more arguments as options. |
| 369 | |
| 370 | `<pathspec>...`:: |
| 371 | Limits the paths affected by the operation. |
| 372 | + |
| 373 | For more details, see the 'pathspec' entry in linkgit:gitglossary[7]. |
| 374 | |
| 375 | DETACHED HEAD |
| 376 | ------------- |
| 377 | `HEAD` normally refers to a named branch (e.g. `master`). Meanwhile, each |
| 378 | branch refers to a specific commit. Let's look at a repo with three |
| 379 | commits, one of them tagged, and with branch `master` checked out: |
| 380 | |
| 381 | ------------ |
| 382 | HEAD (refers to branch 'master') |
| 383 | | |
| 384 | v |
| 385 | a---b---c branch 'master' (refers to commit 'c') |
| 386 | ^ |
| 387 | | |
| 388 | tag 'v2.0' (refers to commit 'b') |
| 389 | ------------ |
| 390 | |
| 391 | When a commit is created in this state, the branch is updated to refer to |
| 392 | the new commit. Specifically, `git commit` creates a new commit `d`, whose |
| 393 | parent is commit `c`, and then updates branch `master` to refer to new |
| 394 | commit `d`. `HEAD` still refers to branch `master` and so indirectly now refers |
| 395 | to commit `d`: |
| 396 | |
| 397 | ------------ |
| 398 | $ edit; git add; git commit |
| 399 | |
| 400 | HEAD (refers to branch 'master') |
| 401 | | |
| 402 | v |
| 403 | a---b---c---d branch 'master' (refers to commit 'd') |
| 404 | ^ |
| 405 | | |
| 406 | tag 'v2.0' (refers to commit 'b') |
| 407 | ------------ |
| 408 | |
| 409 | It is sometimes useful to be able to checkout a commit that is not at |
| 410 | the tip of any named branch, or even to create a new commit that is not |
| 411 | referenced by a named branch. Let's look at what happens when we |
| 412 | checkout commit `b` (here we show two ways this may be done): |
| 413 | |
| 414 | ------------ |
| 415 | $ git checkout v2.0 # or |
| 416 | $ git checkout master^^ |
| 417 | |
| 418 | HEAD (refers to commit 'b') |
| 419 | | |
| 420 | v |
| 421 | a---b---c---d branch 'master' (refers to commit 'd') |
| 422 | ^ |
| 423 | | |
| 424 | tag 'v2.0' (refers to commit 'b') |
| 425 | ------------ |
| 426 | |
| 427 | Notice that regardless of which checkout command we use, `HEAD` now refers |
| 428 | directly to commit `b`. This is known as being in detached `HEAD` state. |
| 429 | It means simply that `HEAD` refers to a specific commit, as opposed to |
| 430 | referring to a named branch. Let's see what happens when we create a commit: |
| 431 | |
| 432 | ------------ |
| 433 | $ edit; git add; git commit |
| 434 | |
| 435 | HEAD (refers to commit 'e') |
| 436 | | |
| 437 | v |
| 438 | e |
| 439 | / |
| 440 | a---b---c---d branch 'master' (refers to commit 'd') |
| 441 | ^ |
| 442 | | |
| 443 | tag 'v2.0' (refers to commit 'b') |
| 444 | ------------ |
| 445 | |
| 446 | There is now a new commit `e`, but it is referenced only by `HEAD`. We can |
| 447 | of course add yet another commit in this state: |
| 448 | |
| 449 | ------------ |
| 450 | $ edit; git add; git commit |
| 451 | |
| 452 | HEAD (refers to commit 'f') |
| 453 | | |
| 454 | v |
| 455 | e---f |
| 456 | / |
| 457 | a---b---c---d branch 'master' (refers to commit 'd') |
| 458 | ^ |
| 459 | | |
| 460 | tag 'v2.0' (refers to commit 'b') |
| 461 | ------------ |
| 462 | |
| 463 | In fact, we can perform all the normal Git operations. But, let's look |
| 464 | at what happens when we then checkout `master`: |
| 465 | |
| 466 | ------------ |
| 467 | $ git checkout master |
| 468 | |
| 469 | HEAD (refers to branch 'master') |
| 470 | e---f | |
| 471 | / v |
| 472 | a---b---c---d branch 'master' (refers to commit 'd') |
| 473 | ^ |
| 474 | | |
| 475 | tag 'v2.0' (refers to commit 'b') |
| 476 | ------------ |
| 477 | |
| 478 | It is important to realize that at this point nothing refers to commit |
| 479 | `f`. Eventually commit `f` (and by extension commit `e`) will be deleted |
| 480 | by the routine Git garbage collection process, unless we create a reference |
| 481 | before that happens. If we have not yet moved away from commit `f`, |
| 482 | any of these will create a reference to it: |
| 483 | |
| 484 | ------------ |
| 485 | $ git checkout -b foo # or "git switch -c foo" <1> |
| 486 | $ git branch foo <2> |
| 487 | $ git tag foo <3> |
| 488 | ------------ |
| 489 | <1> creates a new branch `foo`, which refers to commit `f`, and then |
| 490 | updates `HEAD` to refer to branch `foo`. In other words, we'll no longer |
| 491 | be in detached `HEAD` state after this command. |
| 492 | <2> similarly creates a new branch `foo`, which refers to commit `f`, |
| 493 | but leaves `HEAD` detached. |
| 494 | <3> creates a new tag `foo`, which refers to commit `f`, |
| 495 | leaving `HEAD` detached. |
| 496 | |
| 497 | If we have moved away from commit `f`, then we must first recover its object |
| 498 | name (typically by using git reflog), and then we can create a reference to |
| 499 | it. For example, to see the last two commits to which `HEAD` referred, we |
| 500 | can use either of these commands: |
| 501 | |
| 502 | ------------ |
| 503 | $ git reflog -2 HEAD # or |
| 504 | $ git log -g -2 HEAD |
| 505 | ------------ |
| 506 | |
| 507 | ARGUMENT DISAMBIGUATION |
| 508 | ----------------------- |
| 509 | |
| 510 | When you run `git checkout <something>`, Git tries to guess whether |
| 511 | _<something>_ is intended to be a branch, a commit, or a set of file(s), |
| 512 | and then either switches to that branch or commit, or restores the |
| 513 | specified files. |
| 514 | |
| 515 | If there's any ambiguity, Git will treat `<something>` as a branch or |
| 516 | commit, but you can use the double dash `--` to force Git to treat the |
| 517 | parameter as a list of files and/or directories, like this: |
| 518 | |
| 519 | ---------- |
| 520 | git checkout -- file.txt |
| 521 | ---------- |
| 522 | |
| 523 | EXAMPLES |
| 524 | -------- |
| 525 | |
| 526 | === 1. Paths |
| 527 | |
| 528 | The following sequence checks out the `master` branch, reverts |
| 529 | the `Makefile` to two revisions back, deletes `hello.c` by |
| 530 | mistake, and gets it back from the index. |
| 531 | |
| 532 | ------------ |
| 533 | $ git checkout master <1> |
| 534 | $ git checkout master~2 Makefile <2> |
| 535 | $ rm -f hello.c |
| 536 | $ git checkout hello.c <3> |
| 537 | ------------ |
| 538 | <1> switch branch |
| 539 | <2> take a file out of another commit |
| 540 | <3> restore `hello.c` from the index |
| 541 | |
| 542 | If you want to check out _all_ C source files out of the index, |
| 543 | you can say |
| 544 | |
| 545 | ------------ |
| 546 | $ git checkout -- '*.c' |
| 547 | ------------ |
| 548 | |
| 549 | Note the quotes around `*.c`. The file `hello.c` will also be |
| 550 | checked out, even though it is no longer in the working tree, |
| 551 | because the file globbing is used to match entries in the index |
| 552 | (not in the working tree by the shell). |
| 553 | |
| 554 | If you have an unfortunate branch that is named `hello.c`, this |
| 555 | step would be confused as an instruction to switch to that branch. |
| 556 | You should instead write: |
| 557 | |
| 558 | ------------ |
| 559 | $ git checkout -- hello.c |
| 560 | ------------ |
| 561 | |
| 562 | === 2. Merge |
| 563 | |
| 564 | After working in the wrong branch, switching to the correct |
| 565 | branch would be done using: |
| 566 | |
| 567 | ------------ |
| 568 | $ git checkout mytopic |
| 569 | ------------ |
| 570 | |
| 571 | However, your "wrong" branch and correct `mytopic` branch may |
| 572 | differ in files that you have modified locally, in which case |
| 573 | the above checkout would fail like this: |
| 574 | |
| 575 | ------------ |
| 576 | $ git checkout mytopic |
| 577 | error: You have local changes to 'frotz'; not switching branches. |
| 578 | ------------ |
| 579 | |
| 580 | You can give the `-m` flag to the command, which will carry your local |
| 581 | changes to the new branch: |
| 582 | |
| 583 | ------------ |
| 584 | $ git checkout -m mytopic |
| 585 | Applied autostash. |
| 586 | Switched to branch 'mytopic' |
| 587 | The following paths have local changes: |
| 588 | M frotz |
| 589 | ------------ |
| 590 | |
| 591 | After the switch, the local modifications are reapplied and are _not_ |
| 592 | registered in your index file, so `git diff` would show you what |
| 593 | changes you made since the tip of the new branch. |
| 594 | |
| 595 | === 3. Merge conflict |
| 596 | |
| 597 | When the `--merge` (`-m`) option is given and the local changes |
| 598 | overlap with the changes in the branch we're switching to, the |
| 599 | changes are stashed and reapplied after the switch. If this |
| 600 | process results in conflicts, the stash entry is saved and a |
| 601 | message is printed: |
| 602 | |
| 603 | ------------ |
| 604 | $ git checkout -m mytopic |
| 605 | Your local changes are stashed, however applying them |
| 606 | resulted in conflicts. You can either resolve the conflicts |
| 607 | and then discard the stash with "git stash drop", or, if you |
| 608 | do not want to resolve them now, run "git reset --hard" and |
| 609 | apply the local changes later by running "git stash pop". |
| 610 | ------------ |
| 611 | |
| 612 | CONFIGURATION |
| 613 | ------------- |
| 614 | |
| 615 | include::includes/cmd-config-section-all.adoc[] |
| 616 | |
| 617 | include::config/checkout.adoc[] |
| 618 | |
| 619 | SEE ALSO |
| 620 | -------- |
| 621 | linkgit:git-switch[1], |
| 622 | linkgit:git-restore[1] |
| 623 | |
| 624 | GIT |
| 625 | --- |
| 626 | Part of the linkgit:git[1] suite |