1git-checkout(1) 2=============== 3 4NAME 5---- 6git-checkout - Checkout a branch or paths to the working tree 7 8SYNOPSIS 9-------- 10[verse] 11'git checkout' [-q] [-f] [-m] [<branch>] 12'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>] 13'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>... 14'git checkout' --patch [<tree-ish>] [--] [<paths>...] 15 16DESCRIPTION 17----------- 18Updates files in the working tree to match the version in the index 19or the specified tree. If no paths are given, 'git checkout' will 20also update `HEAD` to set the specified branch as the current 21branch. 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+ 29If `-b` is given, a new branch is created as if linkgit:git-branch[1] 30were called and then checked out; in this case you can 31use the `--track` or `--no-track` options, which will be passed to 32'git branch'. As a convenience, `--track` without `-b` implies branch 33creation; 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+ 46The index may contain unmerged entries because of a previous failed merge. 47By default, if you try to check out such an entry from the index, the 48checkout operation will fail and nothing will be checked out. 49Using `-f` will ignore these unmerged entries. The contents from a 50specific side of the merge can be checked out of the index by 51using `--ours` or `--theirs`. With `-m`, changes made to the working tree 52file can be discarded to re-create the original conflicted merge result. 53 54OPTIONS 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+ 66When checking out paths from the index, do not fail upon unmerged 67entries; 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+ 83If no '-b' option is given, the name of the new branch will be 84derived from the remote branch. If "remotes/" or "refs/remotes/" 85is prefixed it is stripped away, and then the part up to the 86next slash (which would be the nickname of the remote) is removed. 87This would tell us to use "hack" as the local branch when branching 88off of "origin/hack" (or "remotes/origin/hack", or even 89"refs/remotes/origin/hack"). If the given name has no slash, or the above 90guessing results in an empty name, the guessing is aborted. You can 91explicitly 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-m:: 102--merge:: 103 When switching branches, 104 if you have local modifications to one or more files that 105 are different between the current branch and the branch to 106 which you are switching, the command refuses to switch 107 branches in order to preserve your modifications in context. 108 However, with this option, a three-way merge between the current 109 branch, your working tree contents, and the new branch 110 is done, and you will be on the new branch. 111+ 112When a merge conflict happens, the index entries for conflicting 113paths are left unmerged, and you need to resolve the conflicts 114and mark the resolved paths with `git add` (or `git rm` if the merge 115should result in deletion of the path). 116+ 117When checking out paths from the index, this option lets you recreate 118the conflicted merge in the specified paths. 119 120--conflict=<style>:: 121 The same as --merge option above, but changes the way the 122 conflicting hunks are presented, overriding the 123 merge.conflictstyle configuration variable. Possible values are 124 "merge" (default) and "diff3" (in addition to what is shown by 125 "merge" style, shows the original contents). 126 127-p:: 128--patch:: 129 Interactively select hunks in the difference between the 130 <tree-ish> (or the index, if unspecified) and the working 131 tree. The chosen hunks are then applied in reverse to the 132 working tree (and if a <tree-ish> was specified, the index). 133+ 134This means that you can use `git checkout -p` to selectively discard 135edits from your current working tree. 136 137<branch>:: 138 Branch to checkout; if it refers to a branch (i.e., a name that, 139 when prepended with "refs/heads/", is a valid ref), then that 140 branch is checked out. Otherwise, if it refers to a valid 141 commit, your HEAD becomes "detached" and you are no longer on 142 any branch (see below for details). 143+ 144As a special case, the `"@\{-N\}"` syntax for the N-th last branch 145checks out the branch (instead of detaching). You may also specify 146`-` which is synonymous with `"@\{-1\}"`. 147+ 148As a further special case, you may use `"A...B"` as a shortcut for the 149merge base of `A` and `B` if there is exactly one merge base. You can 150leave out at most one of `A` and `B`, in which case it defaults to `HEAD`. 151 152<new_branch>:: 153 Name for the new branch. 154 155<start_point>:: 156 The name of a commit at which to start the new branch; see 157 linkgit:git-branch[1] for details. Defaults to HEAD. 158 159<tree-ish>:: 160 Tree to checkout from (when paths are given). If not specified, 161 the index will be used. 162 163 164 165Detached HEAD 166------------- 167 168It is sometimes useful to be able to 'checkout' a commit that is 169not at the tip of one of your branches. The most obvious 170example is to check out the commit at a tagged official release 171point, like this: 172 173------------ 174$ git checkout v2.6.18 175------------ 176 177Earlier versions of git did not allow this and asked you to 178create a temporary branch using the `-b` option, but starting from 179version 1.5.0, the above command 'detaches' your HEAD from the 180current branch and directly points at the commit named by the tag 181(`v2.6.18` in the example above). 182 183You can use all git commands while in this state. You can use 184`git reset --hard $othercommit` to further move around, for 185example. You can make changes and create a new commit on top of 186a detached HEAD. You can even create a merge by using `git 187merge $othercommit`. 188 189The state you are in while your HEAD is detached is not recorded 190by any branch (which is natural --- you are not on any branch). 191What this means is that you can discard your temporary commits 192and merges by switching back to an existing branch (e.g. `git 193checkout master`), and a later `git prune` or `git gc` would 194garbage-collect them. If you did this by mistake, you can ask 195the reflog for HEAD where you were, e.g. 196 197------------ 198$ git log -g -2 HEAD 199------------ 200 201 202EXAMPLES 203-------- 204 205. The following sequence checks out the `master` branch, reverts 206the `Makefile` to two revisions back, deletes hello.c by 207mistake, and gets it back from the index. 208+ 209------------ 210$ git checkout master <1> 211$ git checkout master~2 Makefile <2> 212$ rm -f hello.c 213$ git checkout hello.c <3> 214------------ 215+ 216<1> switch branch 217<2> take a file out of another commit 218<3> restore hello.c from the index 219+ 220If you have an unfortunate branch that is named `hello.c`, this 221step would be confused as an instruction to switch to that branch. 222You should instead write: 223+ 224------------ 225$ git checkout -- hello.c 226------------ 227 228. After working in the wrong branch, switching to the correct 229branch would be done using: 230+ 231------------ 232$ git checkout mytopic 233------------ 234+ 235However, your "wrong" branch and correct "mytopic" branch may 236differ in files that you have modified locally, in which case 237the above checkout would fail like this: 238+ 239------------ 240$ git checkout mytopic 241fatal: Entry 'frotz' not uptodate. Cannot merge. 242------------ 243+ 244You can give the `-m` flag to the command, which would try a 245three-way merge: 246+ 247------------ 248$ git checkout -m mytopic 249Auto-merging frotz 250------------ 251+ 252After this three-way merge, the local modifications are _not_ 253registered in your index file, so `git diff` would show you what 254changes you made since the tip of the new branch. 255 256. When a merge conflict happens during switching branches with 257the `-m` option, you would see something like this: 258+ 259------------ 260$ git checkout -m mytopic 261Auto-merging frotz 262ERROR: Merge conflict in frotz 263fatal: merge program failed 264------------ 265+ 266At this point, `git diff` shows the changes cleanly merged as in 267the previous example, as well as the changes in the conflicted 268files. Edit and resolve the conflict and mark it resolved with 269`git add` as usual: 270+ 271------------ 272$ edit frotz 273$ git add frotz 274------------ 275 276 277Author 278------ 279Written by Linus Torvalds <torvalds@osdl.org> 280 281Documentation 282-------------- 283Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. 284 285GIT 286--- 287Part of the linkgit:git[1] suite