3.5.1 git-flow 基本模型 在以前的gitlab中，我们使用了git-flow模型去管理分支，该分支模型主要如下：

其详细的接受可以参考：http://blog.jobbole.com/76867/ 关于git的其他工作流程可以参考：https://segmentfault.com/a/1190000002918123

3.5.2 phabricator 工作流程 我们目前保留了以前的git-flow工作流，在次基础上加入了pre-push review审核机制，其流程如下图所示：

详细步骤如下：

• 开发人员加入项目组，clone 项目, git clone http://xx.xx.xx/xxxx.git
• 开发人员在gitbash中执行以下命令（仓库根目录）

  git branch --track develop origin/develop    
    git checkout develop

• 开发人员开发前，需求拉取origin的最新代码，执行以下命令

  git pull
  

• 开发人员开发新功能时，需要建立开发分支，并在开发分支上做修改

  git checkout -b feature/功能名称
  

• 开发人员添加，修改，删除文件后，提交代码至本地feature/功能分支

  git add .
  git status
  git commit -m "提交日志"
  git status
  git log
  

• 开发人员完成功能的开发，进行diff提交前，需要检查一下，远端的origin/develop是否有更新需要更新至本地

  git checkout develop
  git pull
  

  显示 already up to date 则无需更新，否则会显示具体更新了什么内容，切换至功能分支

  git checkout feature/功能名称
  

  如果develop分支已经有更新了，我们可以通过以下将develop分支合并至feature分支来同步远端最新的修改。

  git checkout feature/功能名称
  git merge develop
  

  如果合并过程中产生了冲突，你可以使用sourcetree工具查看具体产生冲突的文件，并解决这些冲突

• 在完成以上的拉取更新之后，我们可以执行以下命令去提交一个diff。请注意,如果文件不是使用UTF-8编码格式编码的文件，需要加上GBK选项，另外推荐所有的文件使用UTF-8编码，包括文件名也一样，另外注意仓库不要使用中文路径，可能会导致arc报错

  arc diff  --encoding GBK
  

• 审核请求的内容提交写法

• 标题必须填写

• Summary 概要介绍
• Test Plan：测试内容，写具体的测试内容，没有填N/A
• Reviewers:填写审核者，可以多个，用空格或者分号隔开

• Subscribers: 抄送

• 审核提交后，如果需要继续修改，请将该revison修改为拒绝状态,修改后，直接更新diff，同理审核被拒绝后，直接在功能分支上继续修改，完成后继续更新diff

  arc diff  --encoding GBK
  

• 审核人员收到审核请求后，应尽快进行代码审核，进行代码审核时，应该严格安装要求进行处理，对有问题对地方进行指正。审核成功后，系统会自动将该revision关闭，此时，开发人员不应该再更新该revision中的diff,而是应该通过使用以下命令进行推送代码（平时开发的功能代码都应该推送至develop分支上)（在自己的功能分支执行以下命令即可）

  arc land --onto develop
  

  系统push完成后，会自动将代码合并至develop分支中，并自动将功能分支删除