| blob | 1cb4910599b97e723a4cd58d419ffcccc40e8bf1 |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 git-checkout(1) Manual Page
407 </h1>
410 <p>git-checkout -
411 Checkout a branch or paths to the working tree
412 </p>
413 </div>
414 </div>
420 <em>git checkout</em> [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
421 <em>git checkout</em> [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>…
424 </div></div>
425 </div>
431 branch.</p></div>
435 </dt>
438 </dt>
441 </dt>
442 <dd>
443 <p>
444 This form switches branches by updating the index, working
445 tree, and HEAD to reflect the specified branch or commit.
446 </p>
447 <div class="paragraph"><p>If <tt>-b</tt> is given, a new branch is created as if <a href="git-branch.html">git-branch(1)</a>
448 were called and then checked out; in this case you can
452 <div class="paragraph"><p>If <tt>-B</tt> is given, <new_branch> is created if it doesn’t exist; otherwise, it
453 is reset. This is the transactional equivalent of</p></div>
458 </div></div>
459 <div class="paragraph"><p>that is to say, the branch is not reset/created unless "git checkout" is
460 successful.</p></div>
461 </dd>
464 </dt>
465 <dd>
466 <p>
467 When <paths> or <tt>--patch</tt> are given, <em>git checkout</em> does <strong>not</strong>
468 switch branches. It updates the named paths in the working tree
471 meaningless and giving either of them results in an error. The
473 (i.e. commit, tag or tree) to update the index for the given
474 paths before updating the working tree.
475 </p>
476 <div class="paragraph"><p>The index may contain unmerged entries because of a previous failed merge.
477 By default, if you try to check out such an entry from the index, the
478 checkout operation will fail and nothing will be checked out.
480 specific side of the merge can be checked out of the index by
482 file can be discarded to re-create the original conflicted merge result.</p></div>
483 </dd>
484 </dl></div>
485 </div>
490 -q
491 </dt>
493 --quiet
494 </dt>
495 <dd>
496 <p>
497 Quiet, suppress feedback messages.
498 </p>
499 </dd>
501 -f
502 </dt>
504 --force
505 </dt>
506 <dd>
507 <p>
508 When switching branches, proceed even if the index or the
509 working tree differs from HEAD. This is used to throw away
510 local changes.
511 </p>
513 entries; instead, unmerged entries are ignored.</p></div>
514 </dd>
516 --ours
517 </dt>
519 --theirs
520 </dt>
521 <dd>
522 <p>
523 When checking out paths from the index, check out stage #2
525 </p>
526 </dd>
528 -b
529 </dt>
530 <dd>
531 <p>
534 </p>
535 </dd>
537 -B
538 </dt>
539 <dd>
540 <p>
545 </p>
546 </dd>
548 -t
549 </dt>
551 --track
552 </dt>
553 <dd>
554 <p>
555 When creating a new branch, set up "upstream" configuration. See
557 </p>
560 is prefixed it is stripped away, and then the part up to the
561 next slash (which would be the nickname of the remote) is removed.
562 This would tell us to use "hack" as the local branch when branching
564 "refs/remotes/origin/hack"). If the given name has no slash, or the above
565 guessing results in an empty name, the guessing is aborted. You can
567 </dd>
569 --no-track
570 </dt>
571 <dd>
572 <p>
573 Do not set up "upstream" configuration, even if the
574 branch.autosetupmerge configuration variable is true.
575 </p>
576 </dd>
578 -l
579 </dt>
580 <dd>
581 <p>
583 details.
584 </p>
585 </dd>
587 --detach
588 </dt>
589 <dd>
590 <p>
591 Rather than checking out a branch to work on it, check out a
592 commit for inspection and discardable experiments.
593 This is the default behavior of "git checkout <commit>" when
595 below for details.
596 </p>
597 </dd>
599 --orphan
600 </dt>
601 <dd>
602 <p>
605 new branch will have no parents and it will be the root of a new
606 history totally disconnected from all the other branches and
607 commits.
608 </p>
609 <div class="paragraph"><p>The index and the working tree are adjusted as if you had previously run
610 "git checkout <start_point>". This allows you to start a new history
614 without exposing its full history. You might want to do this to publish
615 an open source branch of a project whose current tree is "clean", but
616 whose full history contains proprietary or otherwise encumbered bits of
617 code.</p></div>
618 <div class="paragraph"><p>If you want to start a disconnected history that records a set of paths
620 clear the index and the working tree right after creating the orphan
621 branch by running "git rm -rf ." from the top level of the working tree.
622 Afterwards you will be ready to prepare your new files, repopulating the
623 working tree, by copying them from elsewhere, extracting a tarball, etc.</p></div>
624 </dd>
626 -m
627 </dt>
629 --merge
630 </dt>
631 <dd>
632 <p>
633 When switching branches,
634 if you have local modifications to one or more files that
635 are different between the current branch and the branch to
636 which you are switching, the command refuses to switch
637 branches in order to preserve your modifications in context.
638 However, with this option, a three-way merge between the current
639 branch, your working tree contents, and the new branch
640 is done, and you will be on the new branch.
641 </p>
643 paths are left unmerged, and you need to resolve the conflicts
645 should result in deletion of the path).</p></div>
647 the conflicted merge in the specified paths.</p></div>
648 </dd>
651 </dt>
652 <dd>
653 <p>
654 The same as --merge option above, but changes the way the
655 conflicting hunks are presented, overriding the
656 merge.conflictstyle configuration variable. Possible values are
658 "merge" style, shows the original contents).
659 </p>
660 </dd>
662 -p
663 </dt>
665 --patch
666 </dt>
667 <dd>
668 <p>
669 Interactively select hunks in the difference between the
671 tree. The chosen hunks are then applied in reverse to the
673 </p>
674 <div class="paragraph"><p>This means that you can use <tt>git checkout -p</tt> to selectively discard
676 section of <a href="git-add.html">git-add(1)</a> to learn how to operate the <tt>--patch</tt> mode.</p></div>
677 </dd>
680 </dt>
681 <dd>
682 <p>
683 Branch to checkout; if it refers to a branch (i.e., a name that,
684 when prepended with "refs/heads/", is a valid ref), then that
685 branch is checked out. Otherwise, if it refers to a valid
686 commit, your HEAD becomes "detached" and you are no longer on
687 any branch (see below for details).
688 </p>
689 <div class="paragraph"><p>As a special case, the <tt>"@{-N}"</tt> syntax for the N-th last branch
690 checks out the branch (instead of detaching). You may also specify
692 <div class="paragraph"><p>As a further special case, you may use <tt>"A...B"</tt> as a shortcut for the
694 leave out at most one of <tt>A</tt> and <tt>B</tt>, in which case it defaults to <tt>HEAD</tt>.</p></div>
695 </dd>
698 </dt>
699 <dd>
700 <p>
701 Name for the new branch.
702 </p>
703 </dd>
706 </dt>
707 <dd>
708 <p>
709 The name of a commit at which to start the new branch; see
711 </p>
712 </dd>
715 </dt>
716 <dd>
717 <p>
718 Tree to checkout from (when paths are given). If not specified,
719 the index will be used.
720 </p>
721 </dd>
722 </dl></div>
723 </div>
726 <div class="paragraph"><p>HEAD normally refers to a named branch (e.g. <em>master</em>). Meanwhile, each
727 branch refers to a specific commit. Let’s look at a repo with three
731 <pre><tt> HEAD (refers to branch 'master')
732 |
733 v
734 a---b---c branch 'master' (refers to commit 'c')
735 ^
736 |
737 tag 'v2.0' (refers to commit 'b')</tt></pre>
738 </div></div>
739 <div class="paragraph"><p>When a commit is created in this state, the branch is updated to refer to
746 <pre><tt>$ edit; git add; git commit
748 HEAD (refers to branch 'master')
749 |
750 v
751 a---b---c---d branch 'master' (refers to commit 'd')
752 ^
753 |
754 tag 'v2.0' (refers to commit 'b')</tt></pre>
755 </div></div>
757 the tip of any named branch, or even to create a new commit that is not
758 referenced by a named branch. Let’s look at what happens when we
762 <pre><tt>$ git checkout v2.0 # or
763 $ git checkout master^^
765 HEAD (refers to commit 'b')
766 |
767 v
768 a---b---c---d branch 'master' (refers to commit 'd')
769 ^
770 |
771 tag 'v2.0' (refers to commit 'b')</tt></pre>
772 </div></div>
773 <div class="paragraph"><p>Notice that regardless of which checkout command we use, HEAD now refers
775 It means simply that HEAD refers to a specific commit, as opposed to
779 <pre><tt>$ edit; git add; git commit
781 HEAD (refers to commit 'e')
782 |
783 v
784 e
785 /
786 a---b---c---d branch 'master' (refers to commit 'd')
787 ^
788 |
789 tag 'v2.0' (refers to commit 'b')</tt></pre>
790 </div></div>
791 <div class="paragraph"><p>There is now a new commit <em>e</em>, but it is referenced only by HEAD. We can
792 of course add yet another commit in this state:</p></div>
795 <pre><tt>$ edit; git add; git commit
797 HEAD (refers to commit 'f')
798 |
799 v
800 e---f
801 /
802 a---b---c---d branch 'master' (refers to commit 'd')
803 ^
804 |
805 tag 'v2.0' (refers to commit 'b')</tt></pre>
806 </div></div>
807 <div class="paragraph"><p>In fact, we can perform all the normal git operations. But, let’s look
808 at what happens when we then checkout master:</p></div>
811 <pre><tt>$ git checkout master
813 HEAD (refers to branch 'master')
814 e---f |
815 / v
816 a---b---c---d branch 'master' (refers to commit 'd')
817 ^
818 |
819 tag 'v2.0' (refers to commit 'b')</tt></pre>
820 </div></div>
821 <div class="paragraph"><p>It is important to realize that at this point nothing refers to commit
823 by the routine git garbage collection process, unless we create a reference
825 any of these will create a reference to it:</p></div>
831 </div></div>
833 <li>
834 <p>
837 be in detached HEAD state after this command.
838 </p>
839 </li>
840 <li>
841 <p>
843 but leaves HEAD detached.
844 </p>
845 </li>
846 <li>
847 <p>
849 leaving HEAD detached.
850 </p>
851 </li>
852 </ol></div>
853 <div class="paragraph"><p>If we have moved away from commit <em>f</em>, then we must first recover its object
854 name (typically by using git reflog), and then we can create a reference to
855 it. For example, to see the last two commits to which HEAD referred, we
856 can use either of these commands:</p></div>
861 </div></div>
862 </div>
866 <li>
867 <p>
870 mistake, and gets it back from the index.
871 </p>
876 $ rm -f hello.c
878 </div></div>
880 <li>
881 <p>
882 switch branch
883 </p>
884 </li>
885 <li>
886 <p>
887 take a file out of another commit
888 </p>
889 </li>
890 <li>
891 <p>
892 restore hello.c from the index
893 </p>
894 <div class="paragraph"><p>If you have an unfortunate branch that is named <tt>hello.c</tt>, this
895 step would be confused as an instruction to switch to that branch.
896 You should instead write:</p></div>
900 </div></div>
901 </li>
902 </ol></div>
903 </li>
904 <li>
905 <p>
906 After working in the wrong branch, switching to the correct
907 branch would be done using:
908 </p>
912 </div></div>
914 differ in files that you have modified locally, in which case
915 the above checkout would fail like this:</p></div>
918 <pre><tt>$ git checkout mytopic
919 error: You have local changes to 'frotz'; not switching branches.</tt></pre>
920 </div></div>
922 three-way merge:</p></div>
925 <pre><tt>$ git checkout -m mytopic
926 Auto-merging frotz</tt></pre>
927 </div></div>
930 changes you made since the tip of the new branch.</p></div>
931 </li>
932 <li>
933 <p>
934 When a merge conflict happens during switching branches with
936 </p>
939 <pre><tt>$ git checkout -m mytopic
940 Auto-merging frotz
941 ERROR: Merge conflict in frotz
942 fatal: merge program failed</tt></pre>
943 </div></div>
944 <div class="paragraph"><p>At this point, <tt>git diff</tt> shows the changes cleanly merged as in
945 the previous example, as well as the changes in the conflicted
946 files. Edit and resolve the conflict and mark it resolved with
950 <pre><tt>$ edit frotz
951 $ git add frotz</tt></pre>
952 </div></div>
953 </li>
954 </ol></div>
955 </div>
959 </div>
963 </div>
964 </div>
965 </body>
966 </html>