git分支管理：创建与合并分支解决合并冲突.docxVIP

GIT 分支管理：创建与合并分支、解决合并冲突 转载自： /wangmingshun/p/5425150.html 分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学 习 Git 的时候，另一个你正在另一个平行宇宙里努力学习 SVN。 如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不 过，在某个时间点，两个平行宇宙合并了，结果，你既学会 了 Git 又学会了 SVN ！ 分支在实际中有什么用呢？假设你准备开发一个新功能，但 是需要两周才能完成， 第一周你写了 50%的代码， 如果立刻 提交，由于代码还没写完，不完整的代码库会导致别人不能 干活了。如果等代码全部写完再一次提交，又存在丢失每天 进度的巨大风险。 现在有了分支，就不用怕了。你创建了一个属于你自己的分 支，别人看不到，还继续在原来的分支上正常工作，而你在 自己的分支上干活，想提交就提交，直到开发完毕后，再一 次性合并到原来的分支上，这样，既安全，又不影响别人工 作。 其他版本控制系统如 SVN 等都有分支管理，但是用过之后 你会发现，这些版本控制系统创建和切换分支比蜗牛还慢， 简直让人无法忍受， 结果分支功能成了摆设， 大家都不去用。 但 Git 的分支是与众不同的，无论创建、切换和删除分支， Git 在 1 秒钟之内就能完成！无论你的版本库是 1 个文件还 是 1 万个文件。 创建与合并分支 在版本回退里，你已经知道，每次提交， Git 都把它们串成 一条时间线，这条时间线就是一个分支。截止到目前，只有 一条时间线，在 Git 里，这个分支叫主分支， 即 master 分支。 HEAD 严格来说不是指向提交，而是指向 master ， master 才是指向提交的，所以， HEAD 指向的就是当前分支。 一开始的时候， master 分支是一条线， Git 用 master 指向最 新的提交，再用 HEAD 指向 master ，就能确定当前分支， 以及当前分支的提交点： 每次提交， master 分支都会向前移动一步， 这样，随着你不 断提交， master 分支的线也越来越长： 当我们创建新的分支，例如 dev 时， Git 新建了一个指针叫 dev ，指向 master 相同的提交， 再把 HEAD 指向 dev ，就表 示当前分支在 dev 上： 你看，Git创建一个分支很快，因为除了增加一个dev指针， 改改 HEAD 的指向，工作区的文件都没有任何变化！ 不过，从现在开始，对工作区的修改和提交就是针对 dev 分 支了，比如新提交一次后， dev 指针往前移动一步， 而 master 指针不变： 假如我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上。 Git 怎么合并呢？最简单的方法，就是直接把 master 指向 dev 的当前提交，就完成了合并： 所以 Git 合并分支也很快！ 就改改指针， 工作区内容也不变！ 合并完分支后， 甚至可以删除 dev 分支。 删除 dev 分支就是 把 dev 指针给删掉，删掉后，我们就剩下了一条 master 分 支： 真是太神奇了，你看得出来有些提交是通过分支完成的吗？ 下面开始实战。 首先，我们创建 dev 分支，然后切换到 dev 分支： $ git checkout -b dev Switched to a new branch dev git checkout 命令加上 -b 参数表示创建并切换，相当于以下 两条命令： $ git branch dev $ git checkout dev Switched to branch dev 然后，用 git branch 命令查看当前分支： $ git branch * dev master git branch 命令会列出所有分支， 当前分支前面会标一个 *号 然后，我们就可以在 dev 分支上正常提交， 比如对 readme.txt 做个修改，加上一行： create new branch dev.. 然后提交： $ git add readme.txt $ git commit -m create new branch [dev 45ae9a9] create new branch 1 file changed, 1 insertion(+) 现在，dev分支的工作完成，我们就可以切换回 master分支: $ git checkout master Switched to branch master Your branch is up-to-date with origin/master. 切换回 master 分支后，再查看一个 readme.txt 文件，刚才 添加的内容不见了！因为那个提交是在 dev 分支上