By Nicholas

Git 与代码提交流程

以前的代码• 代码风格各异• 开发者各写各的项目，或模块。少、甚至

无合并。• 无 review• 不区分开发版和发布版，直接提交到

master• 可能错误操作导致旧代码直接覆盖代码库

以后要

• 基本统一代码风格• 区分发布版和开发版• 可能协作开发 ( 公共模块 )• Review 代码

代码风格

• PEP8 标准

• 多看别人的代码

• 看自己领悟

区分发布版、开发版

• 问题：– 一就是全，全就是一，干净不干净，

都一起。– 分不清库中的代码是否可以发布。

• 现在要做：– 最少建立两个代码分支

协同开发

• 毫无疑问，合并代码是个累活• So ，做好代码风格统一很有必要• 学会使用分支，学会 merge 代码，

而不是覆盖

分支

master

• Git 默认只有一个分支， master 。但不能依靠这个分支做了任何事情。

• 严谨的代码库中 master 的代码应该是一个可以直接发布的版本。

开发分支

• 每个程序员或许都应该有一个自己专属的开发分支，或许叫 dev ，是一个长期分支

• 这个分支用于长期频繁提交代码，到达稳定可发布的程度了，再合并到 master

临时分支• 一些临时需求造成的代码，也许只用一次，

以后永远都不用了。• 以前我们用注释，或脏代码。

• 建一个临时分支，用完后再切回原开发分支。

• 这个分支，可删，可不删。

建立和使用分支• git branch xxx

• Git checkout xxx

• Git commit … push origin xxx 第一次push 必须要指定提交到新分支

分支合并• 从开发分支 (dev) 合并到主分支 (master)

git checkout mastergit merge --no-ff –m’some message’

dev

• 从主分支 (master) 合并到开发分支 (dev)git checkout devgit merge --no-ff –m’some message’

master

• git merge 默认是 Fast forward 模式• 用 --no-ff 关闭该模式

--no-ff merge 后保留分支历史提交信息

Fast forward merge 后跟在主分支做开发提交一样，完全没了分支的影子

代码Review

• 基于 merge 操作• 登陆 GitLab ，使用其 webUI 发起一次代

码审查合并

主要指定审查人

里程碑，一个分支，master 中的master ，目前先不用

• 审查人则马上能收到一个合并申请

• 若本次合并，与 master 分支无冲突，则可以直接接受合并

• 若本次合并，与 master 分支有冲突，则提示需要命令操作进行手动合并，过程则是上述 merge 命令操作

不急着合并，先审查…

• 可以在审查页最底部查看本次合并修改的内容。也可以在讨论模块中发起讨论。

• 当发现修改的地方存在某些问题，我们可以直接编辑代码，以及提交。

• ps ：编辑的当前代码，会以当前分支最新版本为基础

• 编辑完之后，我们可以通过审核，也可以驳回本次合并请求

有冲突的 merge

• 排除冲突• 然后提交代码 git commit it• Gitlab 提示完成合并

冲突解决的后续• 从开发分支合并到 master 分支，避免不了冲突，• 但冲突解决后，最好还需从 master 分支合并到开

发分支上来，避免下次发起合并时，相同的内容需要再次合并。或许会造成越来越多脏代码。

• 这需要开发者之间的沟通。

最后注意• 经过上述发现，拥有 master 所有权者，

则可以自行对分支进行合并，并不一定需要发起 merge Request 来审核。或许权限分配 ?

• 更多的开发经验告诉我们，协作开发，回归根本，最重要的还是沟通。工具也只是协助我们进行更多、更好的沟通。

The end~Thank you!