LinuxGuruz
  • Last 5 Forum Topics
    Replies
    Views
    Last post


The Web Only This Site
  • BOOKMARK

  • ADD TO FAVORITES

  • REFERENCES


  • MARC

    Mailing list ARChives
    - Search by -
     Subjects
     Authors
     Bodies





    FOLDOC

    Computing Dictionary




  • Text Link Ads






  • LINUX man pages
  • Linux Man Page Viewer


    The following form allows you to view linux man pages.

    Command:

    git-checkout

    
    
    

    SYNOPSIS

           git checkout [-q] [-f] [-m] [<branch>]
           git checkout [-q] [-f] [-m] [-b <new_branch>] [<start_point>]
           git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
           git checkout --patch [<tree-ish>] [--] [<paths>...]
    
    
    

    DESCRIPTION

           When <paths> are not given, this command switches branches by updating
           the index, working tree, and HEAD to reflect the specified branch.
    
           If -b is given, a new branch is created and checked out, as if git-
           branch(1) were called; in this case you can use the --track or
           --no-track options, which will be passed to git branch. As a
           convenience, --track without -b implies branch creation; see the
           description of --track below.
    
           When <paths> or --patch are given, this command does not switch
           branches. It updates the named paths in the working tree from the index
           file, or from a named <tree-ish> (most often a commit). In this case,
           the -b and --track options are meaningless and giving either of them
           results in an error. The <tree-ish> argument can be used to specify a
           specific tree-ish (i.e. commit, tag or tree) to update the index for
           the given paths before updating the working tree.
    
           The index may contain unmerged entries after a failed merge. By
           default, if you try to check out such an entry from the index, the
           checkout operation will fail and nothing will be checked out. Using -f
           will ignore these unmerged entries. The contents from a specific side
           of the merge can be checked out of the index by using --ours or
           --theirs. With -m, changes made to the working tree file can be
           discarded to recreate the original conflicted merge result.
    
    
    

    OPTIONS

           -q, --quiet
               Quiet, suppress feedback messages.
    
           -f, --force
               When switching branches, proceed even if the index or the working
               tree differs from HEAD. This is used to throw away local changes.
    
               When checking out paths from the index, do not fail upon unmerged
               entries; instead, unmerged entries are ignored.
    
           --ours, --theirs
               When checking out paths from the index, check out stage #2 (ours)
               or #3 (theirs) for unmerged paths.
    
           -b
               Create a new branch named <new_branch> and start it at
               <start_point>; see git-branch(1) for details.
    
           --no-track
               Do not set up "upstream" configuration, even if the
               branch.autosetupmerge configuration variable is true.
    
           -l
               Create the new branch's reflog; see git-branch(1) for details.
    
           -m, --merge
               When switching branches, if you have local modifications to one or
               more files that are different between the current branch and the
               branch to which you are switching, the command refuses to switch
               branches in order to preserve your modifications in context.
               However, with this option, a three-way merge between the current
               branch, your working tree contents, and the new branch is done, and
               you will be on the new branch.
    
               When a merge conflict happens, the index entries for conflicting
               paths are left unmerged, and you need to resolve the conflicts and
               mark the resolved paths with git add (or git rm if the merge should
               result in deletion of the path).
    
               When checking out paths from the index, this option lets you
               recreate the conflicted merge in the specified paths.
    
           --conflict=<style>
               The same as --merge option above, but changes the way the
               conflicting hunks are presented, overriding the merge.conflictstyle
               configuration variable. Possible values are "merge" (default) and
               "diff3" (in addition to what is shown by "merge" style, shows the
               original contents).
    
           -p, --patch
               Interactively select hunks in the difference between the <tree-ish>
               (or the index, if unspecified) and the working tree. The chosen
               hunks are then applied in reverse to the working tree (and if a
               <tree-ish> was specified, the index).
    
               This means that you can use git checkout -p to selectively discard
               edits from your current working tree.
    
           <branch>
               Branch to checkout; if it refers to a branch (i.e., a name that,
               when prepended with "refs/heads/", is a valid ref), then that
               branch is checked out. Otherwise, if it refers to a valid commit,
               your HEAD becomes "detached" and you are no longer on any branch
               (see below for details).
    
               As a special case, the "@{-N}" syntax for the N-th last branch
               checks out the branch (instead of detaching). You may also specify
               - which is synonymous with "@{-1}".
    
           <new_branch>
    
               $ git checkout v2.6.18
    
           Earlier versions of git did not allow this and asked you to create a
           temporary branch using the -b option, but starting from version 1.5.0,
           the above command detaches your HEAD from the current branch and
           directly points at the commit named by the tag (v2.6.18 in the example
           above).
    
           You can use all git commands while in this state. You can use git reset
           --hard $othercommit to further move around, for example. You can make
           changes and create a new commit on top of a detached HEAD. You can even
           create a merge by using git merge $othercommit.
    
           The state you are in while your HEAD is detached is not recorded by any
           branch (which is natural --- you are not on any branch). What this
           means is that you can discard your temporary commits and merges by
           switching back to an existing branch (e.g. git checkout master), and a
           later git prune or git gc would garbage-collect them. If you did this
           by mistake, you can ask the reflog for HEAD where you were, e.g.
    
               $ git log -g -2 HEAD
    
    
    

    EXAMPLES

            1. The following sequence checks out the master branch, reverts the
               Makefile to two revisions back, deletes hello.c by mistake, and
               gets it back from the index.
    
                   $ git checkout master             (1)
                   $ git checkout master~2 Makefile  (2)
                   $ rm -f hello.c
                   $ git checkout hello.c            (3)
    
               1. switch branch
               2. take a file out of another commit
               3. restore hello.c from the index
    
               If you have an unfortunate branch that is named hello.c, this step
               would be confused as an instruction to switch to that branch. You
               should instead write:
    
                   $ git checkout -- hello.c
    
            2. After working in the wrong branch, switching to the correct branch
               would be done using:
    
                   $ git checkout mytopic
    
               However, your "wrong" branch and correct "mytopic" branch may
               changes you made since the tip of the new branch.
    
            3. When a merge conflict happens during switching branches with the -m
               option, you would see something like this:
    
                   $ git checkout -m mytopic
                   Auto-merging frotz
                   ERROR: Merge conflict in frotz
                   fatal: merge program failed
    
               At this point, git diff shows the changes cleanly merged as in the
               previous example, as well as the changes in the conflicted files.
               Edit and resolve the conflict and mark it resolved with git add as
               usual:
    
                   $ edit frotz
                   $ git add frotz
    
    
    

    AUTHOR

           Written by Linus Torvalds <torvalds@osdl.org[1]>
    
    
    

    DOCUMENTATION

           Documentation by Junio C Hamano and the git-list
           <git@vger.kernel.org[2]>.
    
    
    

    GIT

           Part of the git(1) suite
    
    
    

    NOTES

            1. torvalds@osdl.org
               mailto:torvalds@osdl.org
    
            2. git@vger.kernel.org
               mailto:git@vger.kernel.org
    
    
    

    Git 1.7.1 03/04/2013 GIT-CHECKOUT(1)

    
    
  • MORE RESOURCE


  • Linux

    The Distributions





    Linux

    The Software





    Linux

    The News



  • MARKETING






  • Toll Free

webmaster@linuxguruz.com
Copyright © 1999 - 2016 by LinuxGuruz