Git 创建与合并分支
2016-07-17 12:47
309 查看
分支简介
几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线。 在很多版本控制系统中,这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说,这样的过程会耗费很多时间。Git 的分支模型被称为它的“必杀技特性”,也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出。 Git 处理分支的方式可谓是难以置信的轻量,创建新分支这一操作几乎能在瞬间完成,并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同,Git 鼓励在工作流程中频繁地使用分支与合并,哪怕一天之内进行许多次。 理解和精通这一特性,你便会意识到 Git 是如此的强大而又独特,并且从此真正改变你的开发方式。
实战
准备工作
首先,先创建一个名称为pro-git的Git Repository,如下:$ mkdir pro-git $ git init Initialized empty Git repository in F:/Git_Studio/pro-git/.git/
添加一个README.md文件,如下:
vi README.md
加上一行:
first commit in master branch!
提交
$ git add README.md $ git commit -m 'inital commit' [master (root-commit) a98c010] inital commit 1 file changed, 1 insertion(+) create mode 100644 README.md
创建分支
首先,我们创建dev分支,如下:$ git branch dev
然后,用git branch命令查看当前分支:
$ git branch dev * master
git branch命令会列出所有分支,当前分支前面会标一个*号。
然后,我们可以使用git checkout命令来切换分支,如下:
$ git checkout dev Switched to branch 'dev'
如果想要新建一个分支并同时切换到那个分支上,你可以运行一个带有 -b 参数的 git checkout 命令:
$ git checkout -b dev Switched to a new branch "dev"
它是下面两条命令的简写:
$ git branch dev $ git checkout dev
接下来,我们就可以在dev分支上正常提交,比如对README.md做个修改,加上一行:
I am in dev branch!
然后提交:
$ git add README.md $ git commit -m 'update README.md' [dev 2c531f9] update README.md 1 file changed, 2 insertions(+), 1 deletion(-)
现在,dev分支的工作完成,我们就可以切换回master分支:
$ git checkout master Switched to branch 'master'
切换回master分支后,再查看一下README.md文件,发现刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
git-br-on-master
合并分支
现在,我们把dev分支的工作成果合并到master分支上:$ git merge dev Updating a98c010..2c531f9 Fast-forward README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
git merge命令用于合并指定分支到当前分支。合并后,再查看README.md的内容,就可以看到,和dev分支的最新提交是完全一样的。
合并完成后,就可以放心地删除dev分支了:
$ git branch -d dev Deleted branch dev (was 2c531f9).
删除后,查看branch,就只剩下master分支了:
$ git branch * master
遇到冲突时的分支合并
有时候合并操作不会如此顺利。 如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 的修改都涉及到同一个文件的同一处,在合并它们的时候就会产生合并冲突:$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
此时 Git 做了合并,但是没有自动地创建一个新的合并提交。 Git 会暂停下来,等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并(unmerged)状态的文件:
$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a")
任何因包含合并冲突而有待解决的文件,都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记,这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段,看起来像下面这个样子:
<<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html
这表示 HEAD 所指示的版本(也就是你的 master 分支所在的位置,因为你在运行 merge 命令的时候已经检出到了这个分支)在这个区段的上半部分(======= 的上半部分),而 iss53 分支所指示的版本在 ======= 的下半部分。 为了解决冲突,你必须选择使用由 ======= 分割的两部分中的一个,或者你也可以自行合并这些内容。 例如,你可以通过把这段内容换成下面的样子来解决冲突:
<div id="footer"> please contact us at email.support@github.com </div>
上述的冲突解决方案仅保留了其中一个分支的修改,并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。 在你解决了所有文件里的冲突之后,对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件,Git 就会将它们标记为冲突已解决。
因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全。
小结
使用 git merge –no-ff dev$ git merge --no-ff dev
默认情况下,Git执行”快进式合并”(fast-farward merge),会直接将Master分支指向Develop分支。
使用–no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。
参考资料
https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%AE%80%E4%BB%8B
相关文章推荐
- RPC failed; result=22, HTTP code = 411
- git更新已經刪除的文件
- 提取Git每次提交后Commit的文件
- GIT迁移服务器
- 分布式版本管理git入门指南使用资料汇总及文章推荐
- git终极指南:在实际开发中的应用
- 6 个托管 git 仓库的地方
- Git远程操作详解
- 25个 Git 进阶技巧(翻译)
- 详解版本控制利器Git,SVN的异同以及适用范围
- Ruby实现的删除已经合并的git分支脚本分享
- 在 Shell 提示符中显示 Git 分支名称的方法
- Git使用基础篇(一些常用命令和原理)
- git 使用及常用命令
- git eclipse 插件的安装
- git fork同步是什么意思?
- Git使用小坑 Out of memory错误的解决方法
- Python的高级Git库 Gittle
- 使用GIT进行源码管理――GUI客户端小结
- 使用git代替FTP部署代码到服务器的例子