]>
Commit | Line | Data |
---|---|---|
1 | git-checkout(1) | |
2 | =============== | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | git-checkout - Checkout a branch or paths to the working tree | |
7 | ||
8 | SYNOPSIS | |
9 | -------- | |
10 | [verse] | |
11 | 'git checkout' [-q] [-f] [-m] [<branch>] | |
12 | 'git checkout' [-q] [-f] [-m] [--detach] [<commit>] | |
13 | 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] | |
14 | 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... | |
15 | 'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...] | |
16 | ||
17 | DESCRIPTION | |
18 | ----------- | |
19 | Updates files in the working tree to match the version in the index | |
20 | or the specified tree. If no paths are given, 'git checkout' will | |
21 | also update `HEAD` to set the specified branch as the current | |
22 | branch. | |
23 | ||
24 | 'git checkout' [<branch>]:: | |
25 | 'git checkout' -b|-B <new_branch> [<start point>]:: | |
26 | 'git checkout' [--detach] [<commit>]:: | |
27 | ||
28 | This form switches branches by updating the index, working | |
29 | tree, and HEAD to reflect the specified branch or commit. | |
30 | + | |
31 | If `-b` is given, a new branch is created as if linkgit:git-branch[1] | |
32 | were called and then checked out; in this case you can | |
33 | use the `--track` or `--no-track` options, which will be passed to | |
34 | 'git branch'. As a convenience, `--track` without `-b` implies branch | |
35 | creation; see the description of `--track` below. | |
36 | + | |
37 | If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it | |
38 | is reset. This is the transactional equivalent of | |
39 | + | |
40 | ------------ | |
41 | $ git branch -f <branch> [<start point>] | |
42 | $ git checkout <branch> | |
43 | ------------ | |
44 | + | |
45 | that is to say, the branch is not reset/created unless "git checkout" is | |
46 | successful. | |
47 | ||
48 | 'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...:: | |
49 | ||
50 | When <paths> or `--patch` are given, 'git checkout' does *not* | |
51 | switch branches. It updates the named paths in the working tree | |
52 | from the index file or from a named <tree-ish> (most often a | |
53 | commit). In this case, the `-b` and `--track` options are | |
54 | meaningless and giving either of them results in an error. The | |
55 | <tree-ish> argument can be used to specify a specific tree-ish | |
56 | (i.e. commit, tag or tree) to update the index for the given | |
57 | paths before updating the working tree. | |
58 | + | |
59 | The index may contain unmerged entries because of a previous failed merge. | |
60 | By default, if you try to check out such an entry from the index, the | |
61 | checkout operation will fail and nothing will be checked out. | |
62 | Using `-f` will ignore these unmerged entries. The contents from a | |
63 | specific side of the merge can be checked out of the index by | |
64 | using `--ours` or `--theirs`. With `-m`, changes made to the working tree | |
65 | file can be discarded to re-create the original conflicted merge result. | |
66 | ||
67 | OPTIONS | |
68 | ------- | |
69 | -q:: | |
70 | --quiet:: | |
71 | Quiet, suppress feedback messages. | |
72 | ||
73 | -f:: | |
74 | --force:: | |
75 | When switching branches, proceed even if the index or the | |
76 | working tree differs from HEAD. This is used to throw away | |
77 | local changes. | |
78 | + | |
79 | When checking out paths from the index, do not fail upon unmerged | |
80 | entries; instead, unmerged entries are ignored. | |
81 | ||
82 | --ours:: | |
83 | --theirs:: | |
84 | When checking out paths from the index, check out stage #2 | |
85 | ('ours') or #3 ('theirs') for unmerged paths. | |
86 | ||
87 | -b <new_branch>:: | |
88 | Create a new branch named <new_branch> and start it at | |
89 | <start_point>; see linkgit:git-branch[1] for details. | |
90 | ||
91 | -B <new_branch>:: | |
92 | Creates the branch <new_branch> and start it at <start_point>; | |
93 | if it already exists, then reset it to <start_point>. This is | |
94 | equivalent to running "git branch" with "-f"; see | |
95 | linkgit:git-branch[1] for details. | |
96 | ||
97 | -t:: | |
98 | --track:: | |
99 | When creating a new branch, set up "upstream" configuration. See | |
100 | "--track" in linkgit:git-branch[1] for details. | |
101 | + | |
102 | If no '-b' option is given, the name of the new branch will be | |
103 | derived from the remote-tracking branch. If "remotes/" or "refs/remotes/" | |
104 | is prefixed it is stripped away, and then the part up to the | |
105 | next slash (which would be the nickname of the remote) is removed. | |
106 | This would tell us to use "hack" as the local branch when branching | |
107 | off of "origin/hack" (or "remotes/origin/hack", or even | |
108 | "refs/remotes/origin/hack"). If the given name has no slash, or the above | |
109 | guessing results in an empty name, the guessing is aborted. You can | |
110 | explicitly give a name with '-b' in such a case. | |
111 | ||
112 | --no-track:: | |
113 | Do not set up "upstream" configuration, even if the | |
114 | branch.autosetupmerge configuration variable is true. | |
115 | ||
116 | -l:: | |
117 | Create the new branch's reflog; see linkgit:git-branch[1] for | |
118 | details. | |
119 | ||
120 | --detach:: | |
121 | Rather than checking out a branch to work on it, check out a | |
122 | commit for inspection and discardable experiments. | |
123 | This is the default behavior of "git checkout <commit>" when | |
124 | <commit> is not a branch name. See the "DETACHED HEAD" section | |
125 | below for details. | |
126 | ||
127 | --orphan <new_branch>:: | |
128 | Create a new 'orphan' branch, named <new_branch>, started from | |
129 | <start_point> and switch to it. The first commit made on this | |
130 | new branch will have no parents and it will be the root of a new | |
131 | history totally disconnected from all the other branches and | |
132 | commits. | |
133 | + | |
134 | The index and the working tree are adjusted as if you had previously run | |
135 | "git checkout <start_point>". This allows you to start a new history | |
136 | that records a set of paths similar to <start_point> by easily running | |
137 | "git commit -a" to make the root commit. | |
138 | + | |
139 | This can be useful when you want to publish the tree from a commit | |
140 | without exposing its full history. You might want to do this to publish | |
141 | an open source branch of a project whose current tree is "clean", but | |
142 | whose full history contains proprietary or otherwise encumbered bits of | |
143 | code. | |
144 | + | |
145 | If you want to start a disconnected history that records a set of paths | |
146 | that is totally different from the one of <start_point>, then you should | |
147 | clear the index and the working tree right after creating the orphan | |
148 | branch by running "git rm -rf ." from the top level of the working tree. | |
149 | Afterwards you will be ready to prepare your new files, repopulating the | |
150 | working tree, by copying them from elsewhere, extracting a tarball, etc. | |
151 | ||
152 | -m:: | |
153 | --merge:: | |
154 | When switching branches, | |
155 | if you have local modifications to one or more files that | |
156 | are different between the current branch and the branch to | |
157 | which you are switching, the command refuses to switch | |
158 | branches in order to preserve your modifications in context. | |
159 | However, with this option, a three-way merge between the current | |
160 | branch, your working tree contents, and the new branch | |
161 | is done, and you will be on the new branch. | |
162 | + | |
163 | When a merge conflict happens, the index entries for conflicting | |
164 | paths are left unmerged, and you need to resolve the conflicts | |
165 | and mark the resolved paths with `git add` (or `git rm` if the merge | |
166 | should result in deletion of the path). | |
167 | + | |
168 | When checking out paths from the index, this option lets you recreate | |
169 | the conflicted merge in the specified paths. | |
170 | ||
171 | --conflict=<style>:: | |
172 | The same as --merge option above, but changes the way the | |
173 | conflicting hunks are presented, overriding the | |
174 | merge.conflictstyle configuration variable. Possible values are | |
175 | "merge" (default) and "diff3" (in addition to what is shown by | |
176 | "merge" style, shows the original contents). | |
177 | ||
178 | -p:: | |
179 | --patch:: | |
180 | Interactively select hunks in the difference between the | |
181 | <tree-ish> (or the index, if unspecified) and the working | |
182 | tree. The chosen hunks are then applied in reverse to the | |
183 | working tree (and if a <tree-ish> was specified, the index). | |
184 | + | |
185 | This means that you can use `git checkout -p` to selectively discard | |
186 | edits from your current working tree. See the ``Interactive Mode'' | |
187 | section of linkgit:git-add[1] to learn how to operate the `--patch` mode. | |
188 | ||
189 | <branch>:: | |
190 | Branch to checkout; if it refers to a branch (i.e., a name that, | |
191 | when prepended with "refs/heads/", is a valid ref), then that | |
192 | branch is checked out. Otherwise, if it refers to a valid | |
193 | commit, your HEAD becomes "detached" and you are no longer on | |
194 | any branch (see below for details). | |
195 | + | |
196 | As a special case, the `"@{-N}"` syntax for the N-th last branch | |
197 | checks out the branch (instead of detaching). You may also specify | |
198 | `-` which is synonymous with `"@{-1}"`. | |
199 | + | |
200 | As a further special case, you may use `"A...B"` as a shortcut for the | |
201 | merge base of `A` and `B` if there is exactly one merge base. You can | |
202 | leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. | |
203 | ||
204 | <new_branch>:: | |
205 | Name for the new branch. | |
206 | ||
207 | <start_point>:: | |
208 | The name of a commit at which to start the new branch; see | |
209 | linkgit:git-branch[1] for details. Defaults to HEAD. | |
210 | ||
211 | <tree-ish>:: | |
212 | Tree to checkout from (when paths are given). If not specified, | |
213 | the index will be used. | |
214 | ||
215 | ||
216 | ||
217 | DETACHED HEAD | |
218 | ------------- | |
219 | HEAD normally refers to a named branch (e.g. 'master'). Meanwhile, each | |
220 | branch refers to a specific commit. Let's look at a repo with three | |
221 | commits, one of them tagged, and with branch 'master' checked out: | |
222 | ||
223 | ------------ | |
224 | HEAD (refers to branch 'master') | |
225 | | | |
226 | v | |
227 | a---b---c branch 'master' (refers to commit 'c') | |
228 | ^ | |
229 | | | |
230 | tag 'v2.0' (refers to commit 'b') | |
231 | ------------ | |
232 | ||
233 | When a commit is created in this state, the branch is updated to refer to | |
234 | the new commit. Specifically, 'git commit' creates a new commit 'd', whose | |
235 | parent is commit 'c', and then updates branch 'master' to refer to new | |
236 | commit 'd'. HEAD still refers to branch 'master' and so indirectly now refers | |
237 | to commit 'd': | |
238 | ||
239 | ------------ | |
240 | $ edit; git add; git commit | |
241 | ||
242 | HEAD (refers to branch 'master') | |
243 | | | |
244 | v | |
245 | a---b---c---d branch 'master' (refers to commit 'd') | |
246 | ^ | |
247 | | | |
248 | tag 'v2.0' (refers to commit 'b') | |
249 | ------------ | |
250 | ||
251 | It is sometimes useful to be able to checkout a commit that is not at | |
252 | the tip of any named branch, or even to create a new commit that is not | |
253 | referenced by a named branch. Let's look at what happens when we | |
254 | checkout commit 'b' (here we show two ways this may be done): | |
255 | ||
256 | ------------ | |
257 | $ git checkout v2.0 # or | |
258 | $ git checkout master^^ | |
259 | ||
260 | HEAD (refers to commit 'b') | |
261 | | | |
262 | v | |
263 | a---b---c---d branch 'master' (refers to commit 'd') | |
264 | ^ | |
265 | | | |
266 | tag 'v2.0' (refers to commit 'b') | |
267 | ------------ | |
268 | ||
269 | Notice that regardless of which checkout command we use, HEAD now refers | |
270 | directly to commit 'b'. This is known as being in detached HEAD state. | |
271 | It means simply that HEAD refers to a specific commit, as opposed to | |
272 | referring to a named branch. Let's see what happens when we create a commit: | |
273 | ||
274 | ------------ | |
275 | $ edit; git add; git commit | |
276 | ||
277 | HEAD (refers to commit 'e') | |
278 | | | |
279 | v | |
280 | e | |
281 | / | |
282 | a---b---c---d branch 'master' (refers to commit 'd') | |
283 | ^ | |
284 | | | |
285 | tag 'v2.0' (refers to commit 'b') | |
286 | ------------ | |
287 | ||
288 | There is now a new commit 'e', but it is referenced only by HEAD. We can | |
289 | of course add yet another commit in this state: | |
290 | ||
291 | ------------ | |
292 | $ edit; git add; git commit | |
293 | ||
294 | HEAD (refers to commit 'f') | |
295 | | | |
296 | v | |
297 | e---f | |
298 | / | |
299 | a---b---c---d branch 'master' (refers to commit 'd') | |
300 | ^ | |
301 | | | |
302 | tag 'v2.0' (refers to commit 'b') | |
303 | ------------ | |
304 | ||
305 | In fact, we can perform all the normal git operations. But, let's look | |
306 | at what happens when we then checkout master: | |
307 | ||
308 | ------------ | |
309 | $ git checkout master | |
310 | ||
311 | HEAD (refers to branch 'master') | |
312 | e---f | | |
313 | / v | |
314 | a---b---c---d branch 'master' (refers to commit 'd') | |
315 | ^ | |
316 | | | |
317 | tag 'v2.0' (refers to commit 'b') | |
318 | ------------ | |
319 | ||
320 | It is important to realize that at this point nothing refers to commit | |
321 | 'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted | |
322 | by the routine git garbage collection process, unless we create a reference | |
323 | before that happens. If we have not yet moved away from commit 'f', | |
324 | any of these will create a reference to it: | |
325 | ||
326 | ------------ | |
327 | $ git checkout -b foo <1> | |
328 | $ git branch foo <2> | |
329 | $ git tag foo <3> | |
330 | ------------ | |
331 | ||
332 | <1> creates a new branch 'foo', which refers to commit 'f', and then | |
333 | updates HEAD to refer to branch 'foo'. In other words, we'll no longer | |
334 | be in detached HEAD state after this command. | |
335 | ||
336 | <2> similarly creates a new branch 'foo', which refers to commit 'f', | |
337 | but leaves HEAD detached. | |
338 | ||
339 | <3> creates a new tag 'foo', which refers to commit 'f', | |
340 | leaving HEAD detached. | |
341 | ||
342 | If we have moved away from commit 'f', then we must first recover its object | |
343 | name (typically by using git reflog), and then we can create a reference to | |
344 | it. For example, to see the last two commits to which HEAD referred, we | |
345 | can use either of these commands: | |
346 | ||
347 | ------------ | |
348 | $ git reflog -2 HEAD # or | |
349 | $ git log -g -2 HEAD | |
350 | ------------ | |
351 | ||
352 | EXAMPLES | |
353 | -------- | |
354 | ||
355 | . The following sequence checks out the `master` branch, reverts | |
356 | the `Makefile` to two revisions back, deletes hello.c by | |
357 | mistake, and gets it back from the index. | |
358 | + | |
359 | ------------ | |
360 | $ git checkout master <1> | |
361 | $ git checkout master~2 Makefile <2> | |
362 | $ rm -f hello.c | |
363 | $ git checkout hello.c <3> | |
364 | ------------ | |
365 | + | |
366 | <1> switch branch | |
367 | <2> take a file out of another commit | |
368 | <3> restore hello.c from the index | |
369 | + | |
370 | If you want to check out _all_ C source files out of the index, | |
371 | you can say | |
372 | + | |
373 | ------------ | |
374 | $ git checkout -- '*.c' | |
375 | ------------ | |
376 | + | |
377 | Note the quotes around `*.c`. The file `hello.c` will also be | |
378 | checked out, even though it is no longer in the working tree, | |
379 | because the file globbing is used to match entries in the index | |
380 | (not in the working tree by the shell). | |
381 | + | |
382 | If you have an unfortunate branch that is named `hello.c`, this | |
383 | step would be confused as an instruction to switch to that branch. | |
384 | You should instead write: | |
385 | + | |
386 | ------------ | |
387 | $ git checkout -- hello.c | |
388 | ------------ | |
389 | ||
390 | . After working in the wrong branch, switching to the correct | |
391 | branch would be done using: | |
392 | + | |
393 | ------------ | |
394 | $ git checkout mytopic | |
395 | ------------ | |
396 | + | |
397 | However, your "wrong" branch and correct "mytopic" branch may | |
398 | differ in files that you have modified locally, in which case | |
399 | the above checkout would fail like this: | |
400 | + | |
401 | ------------ | |
402 | $ git checkout mytopic | |
403 | error: You have local changes to 'frotz'; not switching branches. | |
404 | ------------ | |
405 | + | |
406 | You can give the `-m` flag to the command, which would try a | |
407 | three-way merge: | |
408 | + | |
409 | ------------ | |
410 | $ git checkout -m mytopic | |
411 | Auto-merging frotz | |
412 | ------------ | |
413 | + | |
414 | After this three-way merge, the local modifications are _not_ | |
415 | registered in your index file, so `git diff` would show you what | |
416 | changes you made since the tip of the new branch. | |
417 | ||
418 | . When a merge conflict happens during switching branches with | |
419 | the `-m` option, you would see something like this: | |
420 | + | |
421 | ------------ | |
422 | $ git checkout -m mytopic | |
423 | Auto-merging frotz | |
424 | ERROR: Merge conflict in frotz | |
425 | fatal: merge program failed | |
426 | ------------ | |
427 | + | |
428 | At this point, `git diff` shows the changes cleanly merged as in | |
429 | the previous example, as well as the changes in the conflicted | |
430 | files. Edit and resolve the conflict and mark it resolved with | |
431 | `git add` as usual: | |
432 | + | |
433 | ------------ | |
434 | $ edit frotz | |
435 | $ git add frotz | |
436 | ------------ | |
437 | ||
438 | GIT | |
439 | --- | |
440 | Part of the linkgit:git[1] suite |