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