Git操作-分支管理(二)
2015-05-03 11:56
155 查看
解决冲突
场景:创建一个新的分支feature1,然后在README.txt文件里添加4 create a branch named feature1,然后在feature1分支上提交。提交后切换到master分支,再在master分支上将最后一行修改为
create a new branch named feature1,再提交,现在,master分支和feature1分支各自都分别有新的提交:
此时结构图是这样的:
在这种情况下,我们尝试把两个分支合并,
git merge feature1:
提示README.txt文件有冲突(conflict),需要解决冲突后再提交,此时看一下文件内容:
Git用
<<<<<<<,=======,>>>>>>>标记出不同分支的内容,
将冲突部分手动修改后保存:
4 create a branch named feature1,再提交,发现冲突解决了:
此时的分支结构图如下:
然后就可以删除分支feature1了
注:当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
用git log –graph命令可以看到分支合并图。
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
合并分支时,加上–no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward模式合并就看不出来曾经做过合并。但这种模式下,删除分支后,会丢掉分支信息。通常,合并分支时,如果可能,Git会用Fast forward模式。。
如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息
举个例子:在feature1分支上添加一行:
fast forward,然后提交到feature1分支,切换到master分支,合并feature1分支,注意–no-ff参数,表示禁用Fast forward,命令
$ git merge --no-ff -m "merge with no-ff" feature1,因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。
合并后,我们用git log看看分支历史:
$ git log --graph --pretty=oneline --abbrev-commit * 7825a50 merge with no-ff |\ | * 6224937 add merge |/ * 59bc1cb conflict fixed ...
注意
如果在master分支上修改内容后但未提交,此时要切换到其它分支会出错:相关文章推荐
- git常用操作和分支管理
- Linux下git操作(三)——分支管理与标签
- git常用操作之分支管理(五)
- git diff 生成patch, git apply patch 打补丁方法说明,以及分支管理的简单操作。
- 版本控制工具(下)——Git的远程仓库、分支管理与其它操作
- 用安卓Studio操作Git项目管理(包括GitHub和GitChina的项目提交和管理)和各种本地远程分支操作
- Git分支管理和远程操作
- Git常用操作 - 分支管理
- Git学习笔记(四)——分支管理和远程操作
- git diff 生成patch, git apply patch 打补丁方法说明,以及分支管理的简单操作。
- 【GIT-3】GIT 的基础教程 分支管理 fixbug分支 Featur 冲突处理 标签管理 操作
- Git分支管理的基本操作
- windows下git的安装、配置与操作(十一)——分支的管理
- Git常用操作 - 分支管理
- Git知识总览(四) git分支管理之rebase 以及 cherry-pick相关操作
- Git分支管理的基本操作
- Git操作-分支管理(一)
- Git操作-分支管理(三)
- git仓库管理分支误操作 导致文件丢失
- Git操作——分支管理(一)