git版本分支管理

    Git作为一个开源的分布式版本控制系统，用以有效、高速的处理任何或小或大的项目版本管理。下面我们就来主要说一下其是如何实现版本库的管理工作的：

1、git实现版本库的管理工作

     1）首先git初始化会创建git分支，默认情况下，创建的是主分支，即master，如果没有在继续创建工作分支的话，默认开发是在master主分支上进行的，

           但是这个显然不是我们要的结果。

          git init :此命令是创建一个有master分支的版本库。

     2）git的工作分支，git上关于工作的分支，称之为work分支，develop分支(dev分支)。master和develop的关系中表明，master是提供给用户的正式版本，

           每次发布的正式版本都是在master上完成的。develop分支是我们的工作分支，是根据master创建出来的，代码是要和master同步的。

           在develop上完成的开发之后，要发布正式的版本就把这个位于develop上的代码合并到master分支上面。

          //基于主分支创建工作分支：

          gitcheckout   - b develop master

        //  切换到主分支master

        git  checkout  master

     // 合并develop分支到主分支,develop是 --no-ff  参数，表示正常合并

        git  merge--no-ff develop  

2、 git 的master、develop分支之外的常用临时分支：

   1）release：预测版本分支，就是在master正式版本发布之前，用于预测的，应用在开发人员内部的。这个分支是从develop工作分支上创建的，

          最后要合并到两处，分别是develop,master。

          //基于develop创建release分支 

          gitcheckout -b release-1.0 develop

         //之后将这个release合并到develop和master分支上

          git checkout master

　　  git merge --no-ff release-1.0

        // 对合并生成的新节点，做一个标签

　　  git tag -a 1.0

         develop的合并和master一样。

       //  用完之后将这个分支删除

         git branch -d release-1.0

    2）feature  ：功能分支，功能分支是为了完成开发中某项功能的，它是从develop分支上创建出来的，完成功能开发之后合并到develop分支上。

           在完成功能合并完事后，就把这个feature分支删掉。

            git  checkout -b feature-x develop

            git  checkout develop

            git  merge --no-ff feature-x

           git branch -d feature-x

  3）fixBug分支

          顾名思义，是用来修补代码中的bug，这个是从master分支中创建出来的，但是也同时要合并到两个分支上，develop和master分支上边。

        // 创建分支

          git checkout -b fixbug-1.0 master

       // 完成修复后合并到主分支

    　　gitcheckout master

       　git merge --no-ff fixbug-1.0

       // 添加一个标签

   　　git tag -a 1.0

       同时，也要合并到develop分支

　      git checkout develop

          git merge --no-fffixbug-1.0

       保持分支的整洁，用完这个fixBug之后将这个分支删除：

          git branch -d fixbug-1.0

      分支查看与创建：

     1、查看远程分支

          gitbranch -a

               * dev

                 hotfix

                  master

                  remotes/origin/HEAD -> origin/master

                  remotes/origin/dev

                  remotes/origin/hotfix

                  remotes/origin/master

     2、查看本地分支

          git branch

               * dev

                  hotfix

                 master

   3、创建分支

        git branch 命令创建新分支

        git checkout 命令切换到新分支

        git checkout -b [] 检出命令git checkout通过参数-b实现了

      创建分支和切换分支两个动作的合二为一

  4、把分支推送到远程

        git push origin test

  5、  删除本地分支 

         git branch -d xxxxx

  6、删除远程分支

         git push origin :被删除的分支名

  7、合并分支到主线上

        首先切换分支到主线上
        git merge branchname这个命令把分支"branchname"合并到了主线分支

8、显示本地 tag
  git tag
9、删除本地tag
  git tag -d Remote_Systems_Operation(tag名称)
  用push, 删除远程tag
  git push origin :refs/tags/Remote_Systems_Operation

8、移除远程已删除或不存在但是本地存在的分支

        远程分支已删除或不存在，但是本地使用git branch -a发现本地还有remotes/origin/xxxx分支，

       此时可以使用git remote show origin 来查看分支信息，然后使用git remote prune origin 命令将本地已过时分支移除，如下图

       


分支合并

一、如何分支的合并
在git中，可以使用git merge 和git rebase两个命令来进行分支的合并。
gitmerge 和gitrebase在大体上都差不多，下文主要以gitmerge来例来讲解分支的合并流程。
如果你想了解分支合并的更多内容，请阅读《gitmerge简介》，《gitrebase简介(基本篇)》和《gitrebase简介(高级篇)》。
git merge命令示例:
$ git merge branchname
这个命令把分支"branchname"合并到了当前分支里面。
如有冲突(冲突--同一个文件在远程分支和本地分支里按不同的方式被修改了）；那么命令的执行输出就像下面一样
$ git merge next
 100% (4/4)done
Auto-merged file.txt
CONFLICT (content): Merge conflictin file.txt
Automatic merge failed; fixconflicts and then commit the result.
在有问题的文件上会有冲突标记，在你手动解决完冲突后就可以把此文件添加到索引(index)中去，用git commit命令来提交，就像平时修改了一个文件 一样。
如果你用gitk来查看commit的结果，你会看到它有两个父分支：一个指向当前的分支，另外一个指向刚才合并进来的分支。

二、解决合并中的冲突

如果执行自动合并没有成功的话，git会在索引和工作树里设置一个特殊的状态，提示你如何解决合并中出现的冲突。
有冲突(conflicts)的文件会保存在索引中，除非你解决了问题了并且更新了索引，否则执行 gitcommit都会失败:
$ git commit
file.txt: needs merge
如果执行 git status 会显示这些文件没有合并(unmerged),这些有冲突的文件里面会添加像下面的冲突标识符:
<<<<<<<HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>>77976da35a11db4580b80ae27e8d65caf5208086:file.txt
你所需要的做是就是编辑解决冲突，（接着把冲突标识符删掉），再执行下面的命令:
$ git add file.txt
$ git commit
注意：提交注释里已经有一些关于合并的信息了，通常是用这些默认信息，但是你可以添加一些你想要的注释。
上面这些就是你要做一个简单合并所要知道的，但是git提供更多的一些信息来帮助解决冲突。
三、撒销一个合并
如果你觉得你合并后的状态是一团乱麻，想把当前的修改都放弃，你可以用下面的命令回到合并之前的状态：
$ git reset --hard HEAD
或者你已经把合并后的代码提交，但还是想把它们撒销：
$ git reset --hard ORIG_HEAD
但是刚才这条命令在某些情况会很危险，如果你把一个已经被另一个分支合并的分支给删了，那么以后在合并相关的分支时会出错。
关于撤销的更多内容请参考《gitreset简介》
四、快速向前合并
还有一种需要特殊对待的情况，在前面没有提到。通常，一个合并会产生一个合并提交(commit),把两个父分支里的每一行内容都合并进来。
但是，如果当前的分支和另一个分支没有内容上的差异，就是说当前分支的每一个提交(commit)都已经存在另一个分支里了，git 就会执行一个“快速向前"(fast forward)操作；git不创建任何新的提交(commit),只是将当前分支指向合并进来的分支。
五、在合并过程中得到解决冲突的协助
git会把所有可以自动合并的修改加入到索引中去,所以git diff只会显示有冲突的部分. 它使用了一种不常见的语法:
$ git diff
diff --cc file.txt
index802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,5@@@
++<<<<<<<HEAD:file.txt
 +Helloworld
++=======
+ Goodbye
++>>>>>>>77976da35a11db4580b80ae27e8d65caf5208086:file.txt
回忆一下, 在我们解决冲突之后,得到的提交会有两个而不是一个父提交: 一个父提交是当前分支提交前的HEAD,; 另外一个父提交是被合并分支的HEAD,被暂时存在MERGE_HEAD.
在合并过程中, 索引中保存着每个文件的三个版本.三个"文件暂存(file stage)"中的每一个都代表了文件的不同版本:
$ git show :1:file.txt #两个分支共同祖先中的版本.
$ git show :2:file.txt  # HEAD中的版本.
$ git show :3:file.txt #MERGE_HEAD中的版本.
当你使用git diff去显示冲突时,它在工作树(worktree), 暂存2(stage 2)和暂存3(stage3)之间执行三路diff操作,只显示那些两方都有的块(换句话说,
当一个块的合并结果只从暂存2中得到时, 是不会被显示出来的;对于暂存3来说也是一样).
上面的diff结果显示了file.txt在工作树,暂存2和暂存3中的差异. git不在每行前面加上单个'+'或者'-', 相反地, 它使用两栏去显示差异:第一栏用于显示第一个父提交与工作目录文件拷贝的差异,第二栏用于显示第二个父提交与工作文件拷贝的差异. (参见git diff-files中的"COMBINEDDIFF
FORMAT"取得此格式详细信息.)
在用直观的方法解决冲突之后(但是在更新索引之前),diff输出会变成下面的样子:
$ git diff
diff --cc file.txt
index802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,1@@@
- Hello world
-Goodbye
++Goodbye world
上面的输出显示了解决冲突后的版本删除了第一个父版本提供的"Helloworld"和第二个父版本提供的"Goodbye", 然后加入了两个父版本中都没有的"Goodbyeworld".
一些特别diff选项允许你对比工作目录和三个暂存中任何一个的差异:
$ git diff -1 file.txt    # 与暂存1进行比较
$ git diff --base file.txt        # 与上相同
$ git diff -2 file.txt    # 与暂存2进行比较
$ git diff --ours file.txt        # 与上相同
$ git diff -3 file.txt    # 与暂存3进行比较
$ git diff --theirs file.txt   # 与上相同.
还有，gitlog和gitk命令也为合并操作提供了特别的协助:
$ git log --merge
$ gitk --merge
这会显示所有那些只在HEAD或者只在MERGE_HEAD中存在的提交,还有那些更新(touch)了未合并文件的提交.
你也可以使用git mergetool,它允许你使用外部工具如emacs或kdiff3去合并文件.

每次你解决冲突之后,应该更新索引:
$ git add file.txt
完成索引更新之后,git-diff(缺省地)不再显示那个文件的差异, 所以那个文件的不同暂存版本会被"折叠"起来.
六、多路合并
你可以一次合并多个头, 只需简单地把它们作为gitmerge的参数列出. 例如,
$ git merge scott/masterrick/master tom/master
相当于:
$ git mergescott/master
$ git mergerick/master
$ git mergetom/master
七、子树
有时会出现你想在自己项目中引入其他独立开发项目的内容的情况. 在没有路径冲突的前提下,你只需要简单地从其他项目拉取内容即可.
如果有冲突的文件, 那么就会出现问题.可能的例子包括Makefile和其他一些标准文件名. 你可以选择合并这些冲突的文件, 但是更多的情况是你不愿意把它们合并.一个更好解决方案是把外部项目作为一个子目录进行合并. 这种情况不被递归合并策略所支持,所以简单的拉取是无用的.
在这种情况下,你需要的是子树合并策略.
这下面例子中,我们设定你有一个仓库位于/path/to/B (如果你需要的话, 也可以是一个URL).你想要合并那个仓库的master分支到你当前仓库的dir-B子目录下.
下面就是你所需要的命令序列:
$ git remote add -fBproject /path/to/B (1)
$ git merge -s ours --no-commitBproject/master (2)
$ git read-tree --prefix=dir-B/ -uBproject/master (3)
$ git commit -m "Merge B projectas our subdirectory" (4)
$ git pull -s subtree Bprojectmaster (5)
子树合并的好处就是它并没有给你仓库的用户增加太多的管理负担.它兼容于较老(版本号小于1.5.2)的客户端, 克隆完成之后马上可以得到代码.
然而, 如果你使用子模块(submodule),你可以选择不传输这些子模块对象. 这可能在子树合并过程中造成问题.
译者注:submodule是Git的另一种将别的仓库嵌入到本地仓库方法.
另外, 若你需要修改内嵌外部项目的内容,使用子模块方式可以更容易地提交你的修改