]>
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] [[-b|--orphan] <new_branch>] [<start_point>] | |
13 | 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... | |
14 | 'git checkout' --patch [<tree-ish>] [--] [<paths>...] | |
15 | ||
16 | DESCRIPTION | |
17 | ----------- | |
18 | Updates files in the working tree to match the version in the index | |
19 | or the specified tree. If no paths are given, 'git checkout' will | |
20 | also update `HEAD` to set the specified branch as the current | |
21 | branch. | |
22 | ||
23 | 'git checkout' [<branch>]:: | |
24 | 'git checkout' -b <new branch> [<start point>]:: | |
25 | ||
26 | This form switches branches by updating the index, working | |
27 | tree, and HEAD to reflect the specified branch. | |
28 | + | |
29 | If `-b` is given, a new branch is created as if linkgit:git-branch[1] | |
30 | were called and then checked out; in this case you can | |
31 | use the `--track` or `--no-track` options, which will be passed to | |
32 | 'git branch'. As a convenience, `--track` without `-b` implies branch | |
33 | creation; see the description of `--track` below. | |
34 | ||
35 | 'git checkout' [--patch] [<tree-ish>] [--] <pathspec>...:: | |
36 | ||
37 | When <paths> or `--patch` are given, 'git checkout' *not* switch | |
38 | branches. It updates the named paths in the working tree from | |
39 | the index file or from a named <tree-ish> (most often a commit). In | |
40 | this case, the `-b` and `--track` options are meaningless and giving | |
41 | either of them results in an error. The <tree-ish> argument can be | |
42 | used to specify a specific tree-ish (i.e. commit, tag or tree) | |
43 | to update the index for the given paths before updating the | |
44 | working tree. | |
45 | + | |
46 | The index may contain unmerged entries because of a previous failed merge. | |
47 | By default, if you try to check out such an entry from the index, the | |
48 | checkout operation will fail and nothing will be checked out. | |
49 | Using `-f` will ignore these unmerged entries. The contents from a | |
50 | specific side of the merge can be checked out of the index by | |
51 | using `--ours` or `--theirs`. With `-m`, changes made to the working tree | |
52 | file can be discarded to re-create the original conflicted merge result. | |
53 | ||
54 | OPTIONS | |
55 | ------- | |
56 | -q:: | |
57 | --quiet:: | |
58 | Quiet, suppress feedback messages. | |
59 | ||
60 | -f:: | |
61 | --force:: | |
62 | When switching branches, proceed even if the index or the | |
63 | working tree differs from HEAD. This is used to throw away | |
64 | local changes. | |
65 | + | |
66 | When checking out paths from the index, do not fail upon unmerged | |
67 | entries; instead, unmerged entries are ignored. | |
68 | ||
69 | --ours:: | |
70 | --theirs:: | |
71 | When checking out paths from the index, check out stage #2 | |
72 | ('ours') or #3 ('theirs') for unmerged paths. | |
73 | ||
74 | -b:: | |
75 | Create a new branch named <new_branch> and start it at | |
76 | <start_point>; see linkgit:git-branch[1] for details. | |
77 | ||
78 | -t:: | |
79 | --track:: | |
80 | When creating a new branch, set up "upstream" configuration. See | |
81 | "--track" in linkgit:git-branch[1] for details. | |
82 | + | |
83 | If no '-b' option is given, the name of the new branch will be | |
84 | derived from the remote branch. If "remotes/" or "refs/remotes/" | |
85 | is prefixed it is stripped away, and then the part up to the | |
86 | next slash (which would be the nickname of the remote) is removed. | |
87 | This would tell us to use "hack" as the local branch when branching | |
88 | off of "origin/hack" (or "remotes/origin/hack", or even | |
89 | "refs/remotes/origin/hack"). If the given name has no slash, or the above | |
90 | guessing results in an empty name, the guessing is aborted. You can | |
91 | explicitly give a name with '-b' in such a case. | |
92 | ||
93 | --no-track:: | |
94 | Do not set up "upstream" configuration, even if the | |
95 | branch.autosetupmerge configuration variable is true. | |
96 | ||
97 | -l:: | |
98 | Create the new branch's reflog; see linkgit:git-branch[1] for | |
99 | details. | |
100 | ||
101 | --orphan:: | |
102 | Create a new 'orphan' branch, named <new_branch>, started from | |
103 | <start_point> and switch to it. The first commit made on this | |
104 | new branch will have no parents and it will be the root of a new | |
105 | history totally disconnected from all the other branches and | |
106 | commits. | |
107 | + | |
108 | The index and the working tree are adjusted as if you had previously run | |
109 | "git checkout <start_point>". This allows you to start a new history | |
110 | that records a set of paths similar to <start_point> by easily running | |
111 | "git commit -a" to make the root commit. | |
112 | + | |
113 | This can be useful when you want to publish the tree from a commit | |
114 | without exposing its full history. You might want to do this to publish | |
115 | an open source branch of a project whose current tree is "clean", but | |
116 | whose full history contains proprietary or otherwise encumbered bits of | |
117 | code. | |
118 | + | |
119 | If you want to start a disconnected history that records a set of paths | |
120 | that is totally different from the one of <start_point>, then you should | |
121 | clear the index and the working tree right after creating the orphan | |
122 | branch by running "git rm -rf ." from the top level of the working tree. | |
123 | Afterwards you will be ready to prepare your new files, repopulating the | |
124 | working tree, by copying them from elsewhere, extracting a tarball, etc. | |
125 | ||
126 | -m:: | |
127 | --merge:: | |
128 | When switching branches, | |
129 | if you have local modifications to one or more files that | |
130 | are different between the current branch and the branch to | |
131 | which you are switching, the command refuses to switch | |
132 | branches in order to preserve your modifications in context. | |
133 | However, with this option, a three-way merge between the current | |
134 | branch, your working tree contents, and the new branch | |
135 | is done, and you will be on the new branch. | |
136 | + | |
137 | When a merge conflict happens, the index entries for conflicting | |
138 | paths are left unmerged, and you need to resolve the conflicts | |
139 | and mark the resolved paths with `git add` (or `git rm` if the merge | |
140 | should result in deletion of the path). | |
141 | + | |
142 | When checking out paths from the index, this option lets you recreate | |
143 | the conflicted merge in the specified paths. | |
144 | ||
145 | --conflict=<style>:: | |
146 | The same as --merge option above, but changes the way the | |
147 | conflicting hunks are presented, overriding the | |
148 | merge.conflictstyle configuration variable. Possible values are | |
149 | "merge" (default) and "diff3" (in addition to what is shown by | |
150 | "merge" style, shows the original contents). | |
151 | ||
152 | -p:: | |
153 | --patch:: | |
154 | Interactively select hunks in the difference between the | |
155 | <tree-ish> (or the index, if unspecified) and the working | |
156 | tree. The chosen hunks are then applied in reverse to the | |
157 | working tree (and if a <tree-ish> was specified, the index). | |
158 | + | |
159 | This means that you can use `git checkout -p` to selectively discard | |
160 | edits from your current working tree. | |
161 | ||
162 | <branch>:: | |
163 | Branch to checkout; if it refers to a branch (i.e., a name that, | |
164 | when prepended with "refs/heads/", is a valid ref), then that | |
165 | branch is checked out. Otherwise, if it refers to a valid | |
166 | commit, your HEAD becomes "detached" and you are no longer on | |
167 | any branch (see below for details). | |
168 | + | |
169 | As a special case, the `"@\{-N\}"` syntax for the N-th last branch | |
170 | checks out the branch (instead of detaching). You may also specify | |
171 | `-` which is synonymous with `"@\{-1\}"`. | |
172 | + | |
173 | As a further special case, you may use `"A...B"` as a shortcut for the | |
174 | merge base of `A` and `B` if there is exactly one merge base. You can | |
175 | leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. | |
176 | ||
177 | <new_branch>:: | |
178 | Name for the new branch. | |
179 | ||
180 | <start_point>:: | |
181 | The name of a commit at which to start the new branch; see | |
182 | linkgit:git-branch[1] for details. Defaults to HEAD. | |
183 | ||
184 | <tree-ish>:: | |
185 | Tree to checkout from (when paths are given). If not specified, | |
186 | the index will be used. | |
187 | ||
188 | ||
189 | ||
190 | Detached HEAD | |
191 | ------------- | |
192 | ||
193 | It is sometimes useful to be able to 'checkout' a commit that is | |
194 | not at the tip of one of your branches. The most obvious | |
195 | example is to check out the commit at a tagged official release | |
196 | point, like this: | |
197 | ||
198 | ------------ | |
199 | $ git checkout v2.6.18 | |
200 | ------------ | |
201 | ||
202 | Earlier versions of git did not allow this and asked you to | |
203 | create a temporary branch using the `-b` option, but starting from | |
204 | version 1.5.0, the above command 'detaches' your HEAD from the | |
205 | current branch and directly points at the commit named by the tag | |
206 | (`v2.6.18` in the example above). | |
207 | ||
208 | You can use all git commands while in this state. You can use | |
209 | `git reset --hard $othercommit` to further move around, for | |
210 | example. You can make changes and create a new commit on top of | |
211 | a detached HEAD. You can even create a merge by using `git | |
212 | merge $othercommit`. | |
213 | ||
214 | The state you are in while your HEAD is detached is not recorded | |
215 | by any branch (which is natural --- you are not on any branch). | |
216 | What this means is that you can discard your temporary commits | |
217 | and merges by switching back to an existing branch (e.g. `git | |
218 | checkout master`), and a later `git prune` or `git gc` would | |
219 | garbage-collect them. If you did this by mistake, you can ask | |
220 | the reflog for HEAD where you were, e.g. | |
221 | ||
222 | ------------ | |
223 | $ git log -g -2 HEAD | |
224 | ------------ | |
225 | ||
226 | ||
227 | EXAMPLES | |
228 | -------- | |
229 | ||
230 | . The following sequence checks out the `master` branch, reverts | |
231 | the `Makefile` to two revisions back, deletes hello.c by | |
232 | mistake, and gets it back from the index. | |
233 | + | |
234 | ------------ | |
235 | $ git checkout master <1> | |
236 | $ git checkout master~2 Makefile <2> | |
237 | $ rm -f hello.c | |
238 | $ git checkout hello.c <3> | |
239 | ------------ | |
240 | + | |
241 | <1> switch branch | |
242 | <2> take a file out of another commit | |
243 | <3> restore hello.c from the index | |
244 | + | |
245 | If you have an unfortunate branch that is named `hello.c`, this | |
246 | step would be confused as an instruction to switch to that branch. | |
247 | You should instead write: | |
248 | + | |
249 | ------------ | |
250 | $ git checkout -- hello.c | |
251 | ------------ | |
252 | ||
253 | . After working in the wrong branch, switching to the correct | |
254 | branch would be done using: | |
255 | + | |
256 | ------------ | |
257 | $ git checkout mytopic | |
258 | ------------ | |
259 | + | |
260 | However, your "wrong" branch and correct "mytopic" branch may | |
261 | differ in files that you have modified locally, in which case | |
262 | the above checkout would fail like this: | |
263 | + | |
264 | ------------ | |
265 | $ git checkout mytopic | |
266 | error: You have local changes to 'frotz'; not switching branches. | |
267 | ------------ | |
268 | + | |
269 | You can give the `-m` flag to the command, which would try a | |
270 | three-way merge: | |
271 | + | |
272 | ------------ | |
273 | $ git checkout -m mytopic | |
274 | Auto-merging frotz | |
275 | ------------ | |
276 | + | |
277 | After this three-way merge, the local modifications are _not_ | |
278 | registered in your index file, so `git diff` would show you what | |
279 | changes you made since the tip of the new branch. | |
280 | ||
281 | . When a merge conflict happens during switching branches with | |
282 | the `-m` option, you would see something like this: | |
283 | + | |
284 | ------------ | |
285 | $ git checkout -m mytopic | |
286 | Auto-merging frotz | |
287 | ERROR: Merge conflict in frotz | |
288 | fatal: merge program failed | |
289 | ------------ | |
290 | + | |
291 | At this point, `git diff` shows the changes cleanly merged as in | |
292 | the previous example, as well as the changes in the conflicted | |
293 | files. Edit and resolve the conflict and mark it resolved with | |
294 | `git add` as usual: | |
295 | + | |
296 | ------------ | |
297 | $ edit frotz | |
298 | $ git add frotz | |
299 | ------------ | |
300 | ||
301 | ||
302 | Author | |
303 | ------ | |
304 | Written by Linus Torvalds <torvalds@osdl.org> | |
305 | ||
306 | Documentation | |
307 | -------------- | |
308 | Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. | |
309 | ||
310 | GIT | |
311 | --- | |
312 | Part of the linkgit:git[1] suite |