git 入门

使用git来进行版本控制(同svn

为了得一个项目的拷贝  git clone   <user_name@>url  红色部分可选

git clone /home/git/abc  // 如果省略-b <name>，表示 要克隆master分支

git commit creates a new commit d,

 

git checkout   

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 switch branches. :  git checkout xxx    // checkout xxx  branch，checkout后处于xxx  branch

git checkout [-p|--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

 

 

操作如下：

1. 取出代码

git clone /home/git/abc   // Clone代码树，此时仅有master branch   //如果省略-b <name>，表示 要克隆master分支

git checkout xxx             // checkout xxx  branch，checkout后处于xxx  branch

git命令 解释：

转自：http://blog.csdn.net/hudashi/article/details/7664396

git clone简介：

翻译整理自： http://web.mit.edu/~mkgray/project/silk/root/afs/sipb/project/git/git-doc/git-clone.html 

 在使用git 来进行版本控制(同svn)时， 为了得一个项目的拷贝(copy),我们需要知道这个项目仓库的地址(Git URL). Git能在许多协议下使用，所以 Git URL 可能以ssh://, http(s)://, git://,或是只是以一个用户名（git 会认为这是一个ssh 地址）为前辍. 

有些仓库可以通过不只一种协议来访问，例如， Git 本身的源代码你既可以用  git://  协议来访问：

git clone git://git.kernel.org/pub/scm/git/git.git

也可以通过http 协议来访问:

git clone http://www.kernel.org/pub/scm/git/git.git

git://协议较为快速和有效,但是有时必须使用http协议,比如你公司的防火墙阻止了你的非http访问请求.如果你执 行了上面两行命令中的任意一个,你会看到一个新目录: 'git',它包含有所的Git源代码和历史记录.

   在默认情况下，Git会把"Git URL"里最后一级目录名的'.git'的后辍去掉,做为新克隆(clone)项目的目录名: (例如. git clone http://git.kernel.org/linux/kernel/git/torvalds/linux-2.6.git 会建立一个目录叫'linux-2.6' )

  另外，如果访问一个Git URL需要用法名和密码，可以在Git URL前加上 用户名，并在它们之间加上@ 符以表示分割，然后执行git clone命令，git会提示你输入密码。

示例

git  clone   robin.hu @ http://www.kernel.org/pub/scm/git/git.git

这样将以作为 robin.hu 用户名访问 http://www.kernel.org/pub/scm/git/git.git ， 然后按回车键执行 git clone 命令， git 会提示你输入密码。

另外，我们可以通过-b <name>来指定要克隆的分支名，比如

$ git clone  -b   master2   ../server  .

表示克隆名为master2的这个分支，如果省略 -b <name>， 表示 要克隆master分支。

git clone语法

git clone [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] [--recursive|--recurse-submodules] [--] <repository> [<directory>]

DESCRIPTION

Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch -r), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch.

After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any.

This default configuration is achieved by creating references to the remote branch heads under refs/remotes/origin and by initializingremote.origin.url and remote.origin.fetch configuration variables.

OPTIONS

--local -l

When the repository to clone from is on a local machine, this flag bypasses the normal "git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. This is now the default when the source repository is specified with /path/to/repo syntax, so it essentially is a no-op option. To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository), but still avoid the usual "git aware" transport mechanism, --no-hardlinks can be used.

--no-hardlinks

Optimize the cloning process from a repository on a local filesystem by copying files under .git/objects directory.

--shared -s

When the repository to clone is on the local machine, instead of using hard links, automatically setup .git/objects/info/alternates to share the objects with the source repository. The resulting repository starts out without any object of its own.

NOTE: this is a possibly dangerous operation; do not use it unless you understand what it does. If you clone your repository using this option and then delete branches (or use any other git command that makes any existing commit unreferenced) in the source repository, some objects may become unreferenced (or dangling). These objects may be removed by normal git operations (such as git commit) which automatically call git gc --auto. (See git-gc(1).) If these objects are removed and were referenced by the cloned repository, then the cloned repository will become corrupt.

Note that running git repack without the -l option in a repository cloned with -s will copy objects from the source repository into a pack in the cloned repository, removing the disk space savings of clone -s. It is safe, however, to run git gc, which uses the -l option by default.

If you want to break the dependency of a repository cloned with -s on its source repository, you can simply run git repack -a to copy all objects from the source repository into a pack in the cloned repository.

--reference <repository>

If the reference repository is on the local machine, automatically setup .git/objects/info/alternates to obtain objects from the reference repository. Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs.

NOTE: see the NOTE for the --shared option.

--quiet -q

Operate quietly. Progress is not reported to the standard error stream. This flag is also passed to the ‘rsync’ command when given.

--verbose -v

Run verbosely. Does not affect the reporting of progress status to the standard error stream.

--progress

Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.

--no-checkout -n

No checkout of HEAD is performed after the clone is complete.

--bare

Make a bare GIT repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the<directory> itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created.

--mirror

Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository.

--origin <name> -o <name>

Instead of using the remote name origin to keep track of the upstream repository, use <name>.

--branch <name> -b <name>

Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository’s HEAD, point to <name> branch instead. --branch can also take tags and treat them like detached HEAD. In a non-bare repository, this is the branch that will be checked out.

我们可以通过-b <name>来指定要克隆的分支名，比如

$ git clone  -b   master2   ../server  .

表示克隆名为master2的这个分支，如果省略 -b   <name> 表示克隆master分支。

--upload-pack <upload-pack> -u <upload-pack>

When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end.

--template=<template_directory>

Specify the directory from which templates will be used; (See the "TEMPLATE DIRECTORY" section of git-init(1).)

--config <key>=<value> -c <key>=<value>

Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out. The key is in the same format as expected by git-config(1) (e.g., core.eol=true). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add additional fetch refspecs to the origin remote.

--depth <depth>

Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

--single-branch

Clone only the history leading to the tip of a single branch, either specified by the --branch option or the primary branch remote’s HEADpoints at. When creating a shallow clone with the --depth option, this is the default, unless --no-single-branch is given to fetch the histories near the tips of all branches.

--recursive --recurse-submodules

After the clone is created, initialize all submodules within, using their default settings. This is equivalent to running git submodule update --init --recursive immediately after the clone is finished. This option is ignored if the cloned repository does not have a worktree/checkout (i.e. if any of --no-checkout/-n, --bare, or --mirror is given)

--separate-git-dir=<git dir>

Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, then make a filesytem-agnostic git symbolic link to there. The result is git repository can be separated from working tree.

<repository>

The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.

<directory>

The name of a new directory to clone into. The "humanish" part of the source repository is used if no directory is explicitly given (repofor /path/to/repo.git and foo for host.xz:foo/.git). Cloning into an existing directory is only allowed if the directory is empty.

GIT URLS

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

Git natively supports ssh, git, http, https, ftp, ftps, and rsync protocols. The following syntaxes may be used with them:

• ssh://[user@]host.xz[:port]/path/to/repo.git/

• git://host.xz[:port]/path/to/repo.git/

• http[s]://host.xz[:port]/path/to/repo.git/

• ftp[s]://host.xz[:port]/path/to/repo.git/

• rsync://host.xz/path/to/repo.git/

An alternative scp-like syntax may also be used with the ssh protocol:

• [user@]host.xz:path/to/repo.git/

The ssh and git protocols additionally support ~username expansion:

• ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

• git://host.xz[:port]/~[user]/path/to/repo.git/

• [user@]host.xz:/~[user]/path/to/repo.git/

For local repositories, also supported by git natively, the following syntaxes may be used:

• /path/to/repo.git/

• file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except the former implies --local option.

When git doesn’t know how to handle a certain transport protocol, it attempts to use the remote-<transport> remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used:

• <transport>::<address>

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. Seegit-remote-helpers(1) for details.

If there are a large number of similarly-named remote repositories and you want to use a different format for them (such that the URLs you use will be rewritten into URLs that work), you can create a configuration section of the form:

        [url "<actual url base>"]                 insteadOf = <other url base>

For example, with this:

        [url "git://git.host.xz/"]                 insteadOf = host.xz:/path/to/                 insteadOf = work:

a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".

If you want to rewrite URLs for push only, you can create a configuration section of the form:

        [url "<actual url base>"]                 pushInsteadOf = <other url base>

For example, with this:

        [url "ssh://example.org/"]                 pushInsteadOf = git://example.org/

a URL like "git://example.org/path/to/repo.git" will be rewritten to "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL.

Examples

• Clone from upstream:

  $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 $ make

• Make a local clone that borrows from the current directory, without checking things out:

  $ git clone -l -s -n . ../copy $ cd ../copy $ git show-branch

• Clone from upstream while borrowing from an existing local directory:

  $ git clone --reference my2.6 \         git://git.kernel.org/pub/scm/.../linux-2.7 \         my2.7 $ cd my2.7

• Create a bare repository to publish your changes to the public:

  $ git clone --bare -l /home/proj/.git /pub/scm/proj.git

• Create a repository on the kernel.org machine that borrows from Linus:

  $ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \     /pub/scm/.../me/subsys-2.6.git

GIT

Part of the git(1) suite

 

git clone /home/git/abc   // Clone代码树，此时仅有master branch   //如果省略-b <name>，表示 要克隆master分支

git checkout xxx             // checkout xxx  branch，checkout后处于xxx  branch

git checkout命令解释：

转自：http://blog.csdn.net/hudashi/article/details/7664482

git checkout的主要功能就是迁出一个分支的特定版本。默认是迁出分支的HEAD版本

示例：

git checkout  master      //取出master版本的head。

git checkout  tag_name     //在当前分支上 取出 tag_name 的版本

 

git checkout   master  file_name   //放弃当前对文件file_name的修改

git checkout   commit_id  file_name   //取文件file_name的 在commit_id是的版本。commit_id为 git commit 时的sha值。

 

$  git checkout --  hello.rb

这条命令把 hello.rb 从HEAD中签出.

$  git checkout .

这条命令把  当前目录所有修改的文件  从 HEAD 中签出并且把它恢复成未修改时的样子.

注意：在使用 git checkout  时 ，如果其对应的文件被修改过，那么该 修改会被 覆盖 掉。

NAME

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

SYNOPSIS

git checkout [-q] [-f] [-m] [<branch>] 

git checkout [-q] [-f] [-m] [--detach] [<commit>] 

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 [-p|--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 updateHEAD to set the specified branch as the current branch.

git checkout [<branch>] git checkout -b|-B <new_branch> [<start point>] git checkout [--detach] [<commit>]

This form switches branches by updating the index, working tree, and HEAD to reflect the specified branch or commit.

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 creation; 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 equivalent of$ git branch -f <branch> [<start point>]

       
       

        
        

       
       
       
       

        
        

         
         
$ git checkout <branch>
        
        

       
       

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

git checkout [-p|--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> 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 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 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.

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

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

--detach

Rather than checking out a branch to work on it, check out a commit for inspection and discardable experiments. This is the default behavior of "git checkout <commit>" when <commit> is not a branch name. See the "DETACHED HEAD" section below 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 previously 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 commit 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 otherwise 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 working 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 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. See the “Interactive Mode” section of git-add(1) to learn how to operate the --patch mode.

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

DETACHED HEAD

HEAD normally refers to a named branch (e.g. master). Meanwhile, each branch refers to a specific commit. Let’s look at a repo with three commits, one of them tagged, and with branch master checked out: HEAD (refers to branch 'master')

       HEAD (refers to branch 'master')
            |
            v
a---b---c  branch 'master' (refers to commit 'c')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

When a commit is created in this state, the branch is updated to refer to the new commit. Specifically, git commit creates a new commit d, whose parent is commit c, and then updates branch master to refer to new commit d. HEAD still refers to branch master and so indirectly now refers to commit d:

$ edit; git add; git commit

               HEAD (refers to branch 'master')
                |
                v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

It is sometimes useful to be able to checkout a commit that is not at the tip of any named branch, or even to create a new commit that is not referenced by a named branch. Let’s look at what happens when we checkout commit b (here we show two ways this may be done):

$ git checkout v2.0  # or
$ git checkout master^^

   HEAD (refers to commit 'b')
    |
    v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Notice that regardless of which checkout command we use, HEAD now refers directly to commit b. This is known as being in detached HEAD state. It means simply that HEAD refers to a specific commit, as opposed to referring to a named branch. Let’s see what happens when we create a commit:

$ edit; git add; git commit

     HEAD (refers to commit 'e')
      |
      v
      e
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

There is now a new commit e, but it is referenced only by HEAD. We can of course add yet another commit in this state:

$ edit; git add; git commit

         HEAD (refers to commit 'f')
          |
          v
      e---f
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

In fact, we can perform all the normal git operations. But, let’s look at what happens when we then checkout master:

$ git checkout master

               HEAD (refers to branch 'master')
      e---f     |
     /          v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

It is important to realize that at this point nothing refers to commit f. Eventually commit f (and by extension commit e) will be deleted by the routine git garbage collection process, unless we create a reference before that happens. If we have not yet moved away from commit f, any of these will create a reference to it:

$ git checkout -b foo   <1>
$ git branch foo        <2>
$ git tag foo           <3>

1. creates a new branch foo, which refers to commit f, and then updates HEAD to refer to branch foo. In other words, we’ll no longer be in detached HEAD state after this command.

2. similarly creates a new branch foo, which refers to commit f, but leaves HEAD detached.

3. creates a new tag foo, which refers to commit f, leaving HEAD detached.

If we have moved away from commit f, then we must first recover its object name (typically by using git reflog), and then we can create a reference to it. For example, to see the last two commits to which HEAD referred, we can use either of these commands:

$ git reflog -2 HEAD # or
$ 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
                
                
      
               
               

• 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 differ in files that you have modified locally, in which case the above checkout would fail like this:

  
      
      
  
       
       
  
  
      
      
      
      
  
       
       
  
        
        
  $ git checkout mytopic error: You have local changes to 'frotz'; not switching branches.
       
       
  
       
       
  
  
       
       
  
  
  
       
       
  
  
       
       
  
  
       
       
  
  
        
        
  
  You can give the -m flag to the command, which would try a three-way merge:
  
        
        
  
  
  
        
        
  
         
         
  
          
          
  
  
         
         
         
         
  
          
          
  
           
           
  $ git checkout -m mytopic Auto-merging frotz
          
          
  
          
          
  
  
          
          
  
  
  
          
          
  
  
          
          
  
  
          
          
  
  
           
           
  
  After this three-way merge, the local modifications are not registered in your index file, so git diff would show you what changes you made since the tip
   of the new branch.
  
          
          
  
         
         
       
       
      
      

• 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
  
       
       
  
       
       
  
  
       
       
  
  
  
       
       
  
  
       
       
  
  
       
       
  
  
       
       
  
  
       
       
  
        
        结束
        
        
  
  
        
        
  
  
       
       
  
       
       
   
  
       
       
   
  
       
       
   
  
       
       
  2.
  查看和切换branch
  
       
       
  git branch                      //查看所有的branch，前面有*的表示目前所处的branch
  
       
       
  git checkout [branch name]      //切换到指定的branch
  
       
       
   
  
       
       
  3. branch的pull/commit/push
  
       
       
  和平时一样
  
       
       
  请注意以下几点：
  
       
       
  1.
  每次提交修改前，请务必确认自己所在的branch，以免将对应不同代码树的patch弄混
  
       
       
  2.
  仅针对zzz的，请在master
   branch下进行修改
  
       
       
  3.
  仅针对 xxx
  的，请在xxx branch下进行修改
  
       
       
  4.
  同时针对两者的，务必在两个branch下都进行一遍修改