git 与代码提交流程
Post on 30-Dec-2015
82 Views
Preview:
DESCRIPTION
TRANSCRIPT
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!
top related