git版本管理规范
https://images2015.cnblogs.com/blog/968514/201704/968514-20170416203231790-1361072650.png b.选择origin masterhttps://images2015.cnblogs.com/blog/968514/201704/968514-20170416203252946-575408367.png
c.commit 合并
https://images2015.cnblogs.com/blog/968514/201704/968514-20170416203333056-451322361.png
d.存在冲突时，必须要解决
e.继续 rebase
https://images2015.cnblogs.com/blog/968514/201704/968514-20170416203401227-1762426449.png
四、 Git-push
4.1什么时候push？
① 代码需要提测，并且自己都测试OK了，如果一次性测试通过则可以把master合并到自己的分支，然后push自己的分支，进行提测
② 代码提测了，如果有问题，把问题修改好后，再push自己的分支。
4.2 push流程
[*]git fetch
[*]git checkout dev
[*]git branch -b copy_dev(copy新分支进行合并)
[*]git merge origin master (存在冲突必须解决)
解决冲突：
a) git reset --HARD HEAD^
b) git lg(查看你的所有提交的历史)
[*]git checkout dev
[*]git merge copy_dev
[*]git branch -d copy_dev
[*]git push origin dev
五、Git-issue
5.1对需求完全了解后，开发前先整理思路，在git上填写Issues
① 整理思路，快速开发代码
② 方便后续出现线上问题，快速定位
③ 有类似功能开发时，方便别人借鉴，和自己快速回忆
④ 相互学习
5.2 写完Issues后，找有相关开发经验同事评审
5.3 影响范围较大的Issues必须拉上大家一起评审
5.4 issues规范 (别人一看就懂)
① 需求概述
② 难点，解决方案
③ 概要设计
④ 详细设计
六、git-codeReview
6.1 代码开发完毕，自测通过后，提测之前，在git上提merge Requests
① WIP:分支标题
② Issues
https://images2015.cnblogs.com/blog/968514/201704/968514-20170416203854509-170447335.png
6.2 找有相关开发经验人员进行评审
6.3 按照评审人的建议进行修改，修改后自测
七、 Git-merge
7.1 merge流程
① merge之前保证自己的工作区是干净的
② fetch,更新本地仓库
③ 合并master，如果出现merge conflict，找到相关开发人员一起解 决，确保操作正确
④ merge完成后，验证是否成功
7.2 合主干
① 多人在不同分支上开发多个需求，需要同时上线，事先确定各自上线时间
② 别人合主干后，需要再次拉取最新的master进行merge，进行回归测试
③ 上线的代码一定是提测的代码，是完全一模一样，中间如果有过合并代码就要重新提测，早合并代码比较合适
④ merge Request上，需要附带Issue，代码评审人，测试用例
页:
[1]