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