GIT代码合作开发

Git常用概念

仓库（Repositories）：类似我们生活中的仓库，存储东西，在这是网络或者本地实际存放代码的地方，同一个仓库可存多个项目。

参照（References）：可以看做是指向文件块中特定代码版本的指针，可沿代码版本有向图进行向前（一般指提交操作Commit）,向后（一般是恢复操作Restore）, 跳转（不同分支间的切换Switch）。

分支（Branch）：一般是为了进行代码调试或概念开发，从主要的开发版本中分离出一个副版本，并在此基础上进行修改，（实际中我们可以分离出来进行各自的模块开发）使版本有向图呈现分支状态。

合并(Merge)： 一般是为了将代码调试或概念开发分支的代码加入到主要版本中，将对两部分的代码进行比较：
a) 先向后回朔两个分支的最近公共节点，通过与最近的公共节点进行比较，分析两个分支各对哪些文件进行了修改（因为是文件块，所以需要对两个版本的文件求差，传统模式则需要对两个版本的记录进行求和）
b) 合并最容易产生的错误（冲突）如果某一个文件在 两个版本中均被修改过，则视为“冲突”，这时我们解决的办法是需要人工手动调整其中一个版本，这里推荐使用一个工具（BCompare）可以快速明了的看出修改的地方； 否则，即自动将两个版本分别修改后的部分，未修改的部分合并成一个新的版本。

标签（Tag）：不移动的参照（指针），以标记特殊的代码版本副本，比如说项目的里程碑等

Git使用流程

1. 新建分支
   首先，每次开发新功能，都应该新建一个单独的分支

#获取主干最新代码
$ git checkout master 
$ git pull
#新建一个开发分支myfeature
$ git checkout -b myfeature

2. 提交分支commit
   分支修改后，就可以提交commit了。
   git add 命令的all参数，表示保存所有变化（包括新建、修改和删除）。从Git 2.0开始，all是 git add 的默认参数，所以也可以用 git add . 代替。
   git status 命令，用来查看发生变动的文件。
   git commit -m “some message” 撰写提交信息提交commit时，必须给出完整扼要的提交信息，罗列出改动原因、主要变动、以及需要注意的问题

$ git add --all
$ git status
$ git commit -m "some message"

3. 与主干同步
   分支的开发过程中，要经常与主干保持同步。

$ git fetch origin
$ git rebase origin/master

4. 合并commit
   分支开发完成后，很可能有一堆commit，但是合并到主干的时候，往往希望只有一个（或最多两三个）commit，这样不仅清晰，也容易管理。
   那么，怎样才能将多个commit合并呢？这就要用到 git rebase 命令。rebase：一般翻译为「衍合」或「变基」
   使用 rebase 需要遵循一条准则：
   一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
   简单来说，当待合并 commit 记录中杂糅着他人的 commit 记录，此时就不可以再对这部分 commit 记录做合并操作。
   但只要新开分支且保持分支独立开发，杂糅的情况就不存在。

$ git rebase -i origin/master

5. 推送到远程仓库】
   合并commit后，就可以推送当前分支到远程仓库了

$ git push origin myfeature
$ git push --force origin myfeature  //rebase以后，分支历史改变了，跟远程分支不一定兼容，有可能要强行推送,但是这个操作要谨慎 

6. 发出Pull Request
   提交到远程仓库以后，就可以发出 Pull Request 到master分支，然后请求别人进行代码review，确认可以合并到master。
   当完成功能后提交到远程后，需要经过下述流程：
   1 提交 Merge Request：通过「＋Create Merge Request」按钮创建一个 Merge Request；
   2 必须指定「Assignee」：指定需要 review 你代码的同学，禁止指定自己；
   3 更改「Target branch」：改变为需要合并进去的目标分支；
   4 设置合并后删除被合并分支的选项：勾选「Remove source branch when merge request is accepted.」选项，在合并完成后删除源分支，控制分支总数量，使用「Submit Merge Request」提交合并请求；
   5 完成上述设置后，相关同学将会收到邮件通知，此时可进入 GitLab 进行 code review。
   如果发现问题则对问题代码进行点评并拒绝关闭申请，反之则通过合并申请。
   合并申请通过后留下的 Merge Request 记录，也就记录了 code reviewer 。

项目中长期存在的两个分支

master：主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。
develop：开发分支，该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建。

短期分支（其完成功能开发之后需要删除）

feature/：特性（功能）分支，用于开发新的功能（几乎可以认为是开发和对应测试人员的私人分支, 基本上就是单分支模式的开发模型），不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。
bugfix/：bug修复分支，用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。
release/：发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。
hotfix/：紧急bug修复分支，该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支。

Code Review有什么好处？

团队知识共享的角度
一个开发团队中，水平有高有低，每个人侧重的领域也有不同。怎么让高水平的帮助新人成长？怎么让大家都对自己侧重领域之外的知识保持了解？怎么能有人离职后其他人能快速接手？这些都是团队管理者关心的问题。而代码审查，就是一个很好的知识共享的方式。通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长；通过代码审查，前端也可以去学习后端的代码，做功能模块A的可以去了解功能模块B的。
可能有些高手觉得给新手代码审查浪费时间，自己也没收获。其实不然，新人成长了，就可以更多的帮高手分担繁重的任务；代码审查中花时间，就少一些帮新人填坑擦屁股的时间；良好的沟通能力、发现问题的能力、帮助其他人成长，都是技术转管理或技术上更上一层楼必不可少的能力，而通过代码审查可以有效的去练习这些方面的能力。

代码质量的角度
现实中的项目总是人手缺进度紧，所以被压缩的往往就是自动化测试和代码审查，结果影响代码质量，欠下技术债务，最后还是要加倍偿还。
也有人寄希望于开发后的人工测试，然而对于代码质量来说，很多问题通过测试是测试不出来的，只能通过代码审查。比如说代码的可读性可维护性，比如代码的结构，比如一些特定条件才触发的死循环、逻辑算法错误，还有一些安全上的漏洞也更容易通过代码审查发现和预防。
也有人觉得自己水平高就不需要代码审查了。对于高手来说，让别人审查自己的代码，可以让其他人学习到好的实践；在让其他人审查的同时，在给别人说明自己代码的时候，也等于自己对自己的代码进行了一次审查。这其实就跟我们上学时做数学题一样，真正能拿高分的往往是那些做完后还会认真检查的。

团队规范的角度
每个团队都有自己的代码规范，有自己的基于架构设计的开发规范，然而时间一长，就会发现代码中出现很多不遵守代码规范的情况，有很多绕过架构设计的代码。比如难以理解和不规范的命名，比如三层架构里面UI层绕过业务逻辑层直接调用数据访问层代码。
如果这些违反规范的代码被纠正的晚了，后面再要修改就成本很高了，而且团队的规范也会慢慢的形同虚设。

Code Review清单

常规项
代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
所有的代码是否简单易懂？
代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
是否存在多余的或是重复的代码？
代码是否尽可能的模块化了？
是否有可以被替换的全局变量？
是否有被注释掉的代码？
循环是否设置了长度和正确的终止条件？
是否有可以被库函数替代的代码？
是否有可以删除的日志或调试代码？

安全
所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
在哪里使用了第三方工具，返回的错误是否被捕获？
输出的值是否进行了检查并且编码？
无效的参数值是否能够处理？

文档
是否有注释，并且描述了代码的意图？
所有的函数都有注释吗？
对非常规行为和边界情况处理是否有描述？
第三方库的使用和函数是否有文档？
数据结构和计量单位是否进行了解释？
是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？

测试
代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
单元测试是否真正的测试了代码是否可以完成预期的功能？
是否检查了数组的“越界“错误？
是否有可以被已经存在的API所替代的测试代码？

参考

https://juejin.im/post/59e5b683f265da432c22ec89
http://www.ruanyifeng.com/blog/2015/08/git-use-process.html
https://www.cnblogs.com/kuangliu/p/10942273.html