Checkout a branch or paths to the working tree

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.

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

    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.

AND and OR lists are sequences of one of more pipelines separated by the &&  and  ||  control  operators,
respectively.  AND and OR lists are executed with left associativity.  An AND list has the form

       command1 && command2

command2 is executed if, and only if, command1 returns an exit status of zero.

An OR list has the form

       command1 || command2

command2  is  executed  if and only if command1 returns a non-zero exit status.  The return status of AND
and OR lists is the exit status of the last command executed in the list.

Join two or more development histories together

-s <strategy>, --strategy=<strategy>
    Use the given merge strategy; can be supplied more than once to specify them in the order they should
    be tried. If there is no -s option, a built-in list of strategies is used instead (git
    merge-recursive when merging a single head, git merge-octopus otherwise).

<commit>...
    Commits, usually other branch heads, to merge into our branch. Specifying more than one commit will
    create a merge with more than two parents (affectionately called an Octopus merge).

    If no commit is given from the command line, and if merge.defaultToUpstream configuration variable is
    set, merge the remote tracking branches that the current branch is configured to use as its upstream.
    See also the configuration section of this manual page.