git-checkout man page on OpenBSD

Man page or keyword search:  
man Server   11362 pages
apropos Keyword Search (all sections)
Output format
OpenBSD logo
[printable version]



GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

NAME
       git-checkout - Checkout a branch or paths to the working tree

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

DESCRIPTION
       Updates	files in the working tree to match the version in the index or
       the specified tree. If no paths	are  given,  git  checkout  will  also
       update HEAD to set the specified branch as the current branch.

       git checkout [<branch>], git checkout -b|-B <new_branch> [<start
       point>]
	      This form switches branches by updating the index, working tree,
	      and HEAD to reflect the specified branch.

	      If -b is given, a new branch is created as if git-branch(1) were
	      called and then checked out;  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 cre-
	      ation; see the description of --track below.

	      If  -B  is  given,  <new_branch>	is created if it doesn’t
	      exist; otherwise, it is reset. This is the transactional equiva-
	      lent of

	      .ft C
	      $ git branch -f <branch> [<start point>]
	      $ git checkout <branch>
	      .ft

	      that  is	to  say,  the  branch is not reset/created unless "git
	      checkout" is successful.

       git checkout [--patch] [<tree-ish>] [--] <pathspec>...
	      When <paths> or --patch are given, git checkout 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>	 argu-
	      ment  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.

								1

GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

	      The  index  may  contain	unmerged entries because of a previous
	      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
	      re-create the original conflicted merge result.

OPTIONS
       -q, --quiet
	      Quiet, suppress feedback messages.

       -f, --force
	      When switching branches, proceed even if the index or the	 work-
	      ing  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.

       -B     Creates  the  branch <new_branch> and start it at <start_point>;
	      if it already exists, then reset it to  <start_point>.  This  is
	      equivalent  to running "git branch" with "-f"; see git-branch(1)
	      for details.

       -t, --track
	      When creating a new branch, set up "upstream" configuration. See
	      "--track" in git-branch(1) for details.

	      If  no  -b  option  is given, the name of the new branch will be
	      derived from the remote branch. If "remotes/" or "refs/remotes/"
	      is  prefixed  it	is  stripped away, and then the part up to the
	      next slash (which would  be  the	nickname  of  the  remote)  is
	      removed.	This  would  tell us to use "hack" as the local branch
	      when branching off of "origin/hack"  (or	"remotes/origin/hack",
	      or  even	"refs/remotes/origin/hack").  If the given name has no
	      slash, or the above guessing  results  in	 an  empty  name,  the
	      guessing	is  aborted. You can explicitly give a name with -b in
	      such a case.

								2

GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

       --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.

       --orphan
	      Create a new orphan branch,  named  <new_branch>,	 started  from
	      <start_point>  and  switch  to it. The first commit made on this
	      new branch will have no parents and it will be the root of a new
	      history  totally	disconnected  from  all the other branches and
	      commits.

	      The index and the working tree are adjusted as if you had previ-
	      ously run "git checkout <start_point>". This allows you to start
	      a	 new  history  that  records  a	 set  of  paths	  similar   to
	      <start_point> by easily running "git commit -a" to make the root
	      commit.

	      This can be useful when you want to publish the tree from a com-
	      mit without exposing its full history. You might want to do this
	      to publish an open source branch of a project whose current tree
	      is  "clean", but whose full history contains proprietary or oth-
	      erwise encumbered bits of code.

	      If you want to start a disconnected history that records	a  set
	      of   paths   that	  is   totally	 different  from  the  one  of
	      <start_point>, then you should clear the index and  the  working
	      tree  right  after creating the orphan branch by running "git rm
	      -rf ." from the top level of the working	tree.  Afterwards  you
	      will  be ready to prepare your new files, repopulating the work-
	      ing tree, by copying them from elsewhere, extracting a  tarball,
	      etc.

       -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  con-
	      text.  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.

								3

GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

       --conflict=<style>
	      The  same	 as --merge option above, but changes the way the con-
	      flicting 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  dis-
	      card 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 com-
	      mit, 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 spec-
	      ify - which is synonymous with "@\{-1\}".

	      As  a  further  special case, you may use "A\...B" as a shortcut
	      for the merge base of A and B if	there  is  exactly  one	 merge
	      base. You can leave out at most one of A and B, in which case it
	      defaults to HEAD.

       <new_branch>
	      Name for the new branch.

       <start_point>
	      The name of a commit at which  to	 start	the  new  branch;  see
	      git-branch(1) for details. Defaults to HEAD.

       <tree-ish>
	      Tree  to checkout from (when paths are given). If not specified,
	      the index will be used.

DETACHED HEAD
       It is sometimes useful to be able to checkout a commit that is  not  at
       the  tip	 of one of your branches. The most obvious example is to check
       out the commit at a tagged official release point, like this:

								4

GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

       .ft C
       $ git checkout v2.6.18
       .ft

       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.

       .ft C
       $ git log -g -2 HEAD
       .ft

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.

	  .ft C
	  $ git checkout master		    (1)
	  $ git checkout master~2 Makefile  (2)
	  $ rm -f hello.c
	  $ git checkout hello.c	    (3)
	  .ft

	  1. switch branch
	  2. take a file out of another commit

								5

GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

	  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:

	  .ft C
	  $ git checkout -- hello.c
	  .ft

       2. After working in the wrong branch, switching to the  correct	branch
	  would be done using:

	  .ft C
	  $ git checkout mytopic
	  .ft

	  However, your "wrong" branch and correct "mytopic" branch may differ
	  in files that you have modified locally, in  which  case  the	 above
	  checkout would fail like this:

	  .ft C
	  $ git checkout mytopic
	  error: You have local changes to 'frotz'; not switching branches.
	  .ft

	  You can give the -m flag to the command, which would try a three-way
	  merge:

	  .ft C
	  $ git checkout -m mytopic
	  Auto-merging frotz
	  .ft

	  After this three-way merge, the local modifications are  not	regis-
	  tered	 in  your  index file, so git diff would show you what changes
	  you made since the tip of the new branch.

								6

GIT-CHECKOUT(1)					  GIT-CHECKOUT(1)

       3. When a merge conflict happens during switching branches with the  -m
	  option, you would see something like this:

	  .ft C
	  $ git checkout -m mytopic
	  Auto-merging frotz
	  ERROR: Merge conflict in frotz
	  fatal: merge program failed
	  .ft

	  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:

	  .ft C
	  $ edit frotz
	  $ git add frotz
	  .ft

AUTHOR
       Written by Linus Torvalds <torvalds@osdl.org: mailto:torvalds@osdl.org>

DOCUMENTATION
       Documentation  by Junio C Hamano and the git-list <git@vger.kernel.org:
       mailto:git@vger.kernel.org>.

GIT
       Part of the git(1) suite

								7

[top]

List of man pages available for OpenBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net