Git 多人合作的一点经验

经过接近半年的中等规模项目（200 个页面这样）的开发，我渐渐找到了一种在 Git 上合作的模式。

提交规则

提交的文件不能出现与本地开发有关的配置，即那些会损坏别人开发环境的代码，比如

• .idea 文件夹，有一次有一个合并请求里包含了这个文件夹，我本地合并测试的时候我的 webstorm 直接炸了
• vue.config.js 中 devServer 的配置

提交的文件必须遵循项目的代码规范（代码风格、命名规则）。

不要去改别人的代码，别人的代码有问题的话应该发起一个 issue，即使你本地修改能用了也不要提交，别人的代码别人负责。

提交的代码中不要出现成片注释掉的代码。

提交信息(commit message)应该要能概括本次提交的内容，要让别人看到提交信息就知道这一次提交做了什么。

分支

Git 上最重要的一个东西就是分支，在我的新体系中有这么几种类型的分支

• master
  主分支，保护分支，存放随时可供发布的代码版本。
• dev
  开发分支，保护分支，当 dev 分支上的代码稳定后并且新功能完备后，将 dev 合并至 master。
• feature-xxx
  功能分支族，在我的项目中也可命名为 view-xxx，表明这个分支开发的是哪一个功能。当要开发新功能时，从 dev 拉出去一条 feature 分支，开发人员在这条分支上工作，当这一分支的功能开发完毕、测试可用后合并至 dev。
• hotfix-xxx
  热修复分支族，用于修复 dev 上的 bug，修复完成测试后合并至 dev。

分支管理

master 和 dev 是受保护的分支，即只有项目管理员才能修改的分支。

开发人员在 feature 分支族上工作，在功能完善后，发起合并请求，合并请求的代码必须完全遵守上面的提交规则，由管理员审核后合并入 dev。

如果开发分支仅存在于本地，在开发完成后可以将开发分支 rebase 至最新的 dev 再推送至远端发起合并请求。如果分支已存在于远端，无论如何都不应该进行 rebase 操作。

为了方便合并请求的审核，每个 feature 分支上的新功能规模不应该过大，如果规模过大最好考虑进行细分。

后记？

先写这些吧，等想到什么再补充。

另外，项目成员必须要遵守项目组的规定，代码风格也好，Git 管理模式也好，如果觉得有问题应该跟组里讨论，但无论如何你都必须按照规定办事。