7. 团队开发协作 基于github
7.1 选择合适的分支集成策略
初始情况:
-
如果要保证开发只有一条直线,则选择
create a merge commit
开发完特性分支以后,删除特性分支,只会有一条干净的主干,改变分支
最后选择create pull request
:
展示结果:
-
如果以
squash and merge
的方式进行合并:
相当于将原来的多个commit进行合并为一个commit,不改变分支
结果展示:
-
如果以
rebase and merge
的方式进行合并:
相当于将原来的三个直接加到了master的主干,不改变分支
7.2 issue跟踪需求
- setting里面设置启用
issue
- 选择issue模板,仓库作者自己制定
- 提交变更
7.3 github分支集成
github的分支集成都是基于pull request来完成的
初始状态:
-
create pull request
的方式的时候
进行合并的时候:
另一个用户进行pull request
的时候,显示有冲突需要被解决
github支持在线编辑冲突
冲突解决后的结果:
-
squash and merge
的方式的时候
解决结果:
-
rebase and merge
的方式的时候
结果以失败告终
此时回到本地进行变基,都基于远端的master进行变基
然后将变基完的分支往远端进行push,必须使用 -f 不然push不上去
最终结果:
有趣的情况发生了,这次commit有了两个作者
这是因为进行了变基操作,是在原来的作者的基础上进行的变更
之前进行变基的时候需要对一个同样的冲突做多次修改,可以使用rerere
7.4 借鉴别人的readme文档
- 把别人的工程fork到自己仓库
git clone
到本地git push
到自己的github仓库- 打开编辑界面进行编译
因为别人的readme文档,我们不能编辑,所以看不到markdown的语法
了解更多技术文章,欢迎关注我的个人公众号