1 / 31

Git 与代码提交流程

Git 与代码提交流程. By Nicholas. 以 前的代码. 代码风格各异 开发者各写各的项目，或模块。 少、甚至无合 并。 无 review 不区分开发版和发布版 ， 直接提交到 master 可能错误操作导致旧代码直接覆盖代码库. 以后要. 基本统一代码风格 区分发布版和开发 版 可能协作开发 ( 公共模块 ) Review 代码. 代码风格. PEP8 标准 多看别人的代码 看自己领悟. 区分发布版、开发版. 问 题： 一就是全，全就是一，干净不干净，都一起。 分不清库中的代码是否可以发布。 现在要做： 最少建立两个代码分支.

pandora-farmer
Download Presentation

Git 与代码提交流程

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Git与代码提交流程 By Nicholas

  2. 以前的代码 • 代码风格各异 • 开发者各写各的项目，或模块。少、甚至无合并。 • 无review • 不区分开发版和发布版，直接提交到master • 可能错误操作导致旧代码直接覆盖代码库

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

  4. 代码风格

  5. PEP8标准 • 多看别人的代码 • 看自己领悟

  6. 区分发布版、开发版

  7. 问题： • 一就是全，全就是一，干净不干净，都一起。 • 分不清库中的代码是否可以发布。 • 现在要做： • 最少建立两个代码分支

  8. 协同开发

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

  10. 分支

  11. master • Git默认只有一个分支，master。但不能依靠这个分支做了任何事情。 • 严谨的代码库中master的代码应该是一个可以直接发布的版本。

  12. 开发分支 • 每个程序员或许都应该有一个自己专属的开发分支，或许叫dev，是一个长期分支 • 这个分支用于长期频繁提交代码，到达稳定可发布的程度了，再合并到master

  13. 临时分支 • 一些临时需求造成的代码，也许只用一次，以后永远都不用了。 • 以前我们用注释，或脏代码。 • 建一个临时分支，用完后再切回原开发分支。 • 这个分支，可删，可不删。

  14. 建立和使用分支 • git branch xxx • Git checkout xxx • Git commit … push origin xxx 第一次push必须要指定提交到新分支

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

  16. git merge 默认是Fast forward模式 • 用--no-ff关闭该模式 --no-ff merge后保留分支历史提交信息 Fast forward merge后跟在主分支做开发提交一样，完全没了分支的影子

  17. 代码Review

  18. 基于merge操作 • 登陆GitLab，使用其webUI发起一次代码审查合并

  19. 主要指定审查人 里程碑，一个分支，master中的master，目前先不用

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

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

  22. 不急着合并，先审查…

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

  24. 当发现修改的地方存在某些问题，我们可以直接编辑代码，以及提交。当发现修改的地方存在某些问题，我们可以直接编辑代码，以及提交。 • ps：编辑的当前代码，会以当前分支最新版本为基础

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

  26. 有冲突的merge

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

  28. 冲突解决的后续 • 从开发分支合并到master分支，避免不了冲突， • 但冲突解决后，最好还需从master分支合并到开发分支上来，避免下次发起合并时，相同的内容需要再次合并。或许会造成越来越多脏代码。 • 这需要开发者之间的沟通。

  29. 最后注意 • 经过上述发现，拥有master所有权者，则可以自行对分支进行合并，并不一定需要发起merge Request来审核。或许权限分配? • 更多的开发经验告诉我们，协作开发，回归根本，最重要的还是沟通。工具也只是协助我们进行更多、更好的沟通。

  30. The end~Thank you!

More Related