Git 的代码管控机制

Git 由于他自身的优势和灵活性，已经渐渐取代了SVN，作为代码管控的首选工具。
先聊聊用git 来管控代码，我们到底需要多少分支才算是一个比较OK的选择呢：
答案是： Master 分支 + Develop 分支 + Release 分支。
Master 分支： Master 分支上面的代码一定是当前能够直接发布的，能正常工作的代码。
Dev 分支： Dev 分支是开发人员的功能开发完成且自验通过后 ，提交到dev 分支。dev 分支上面可以比master 分支的功能和代码多。
Release 分支： 每次release 版本时，必须从Master 上面重新拉一个分支，基于该分支去对此次的release 版本去开发和回归。
当前，三个分支很多情况下来说，merge 代码的工作量比较大，所以我们建议采用 Master 分支来充当 Dev 分支的角色。这样我们就存在两个分支：Master + Release 分支。
1） 功能开发，选择 Master分支， 预研，基于Master分支去拉预研的个人分支。
2） 版本测试问题修复和回归，基于Release 分支修复和回归， cherry-pick 进Master分支。

Git Review 代码有很多方式，比如 Gerrit，但是 git 自身也提供了 Pull Request 的方式来提交代码。下面我们来聊一下这个流程。

1） 配置当前的项目代码提交权限仅仅为Master 用户，其他用户一律不能够进行 push 操作。

2）用 Fork 的方式创建个人项目

3）克隆产品的代码

git clone git@url/project/xxx.git

4）添加fork的源

git remote add who git@url/who/xxx.git

5) 同步远端源项目master 代码

git pull origin master

6） 产生改变和commit

#change code
#add changes
git add .
#commit changes into local git project
git commit -m "test"

7) 提交commit 到fork 项目

git push who master

8）创建merge request
点击 Merge Request —–> Create New Merge Request —–> Submit Merge Request. 选择你需要他帮你Review 和能Accept Merge的人，然后Assign 给他。

9) 等待别人Review Code, Accept or Reject.

如有问题，可以加微信交流

如果觉得写得好，期待您的赞赏：