一些可能性较高的Git使用约定

2019-09-03

master

master 是最稳定的分支，随时可以当作 release 版本，只能从其他分支合入，不能在上面做任何提交；每个版本发布之后，对应的发布分支会合并到 master。只接收 release/hotfix 分支的合并。

develop

主干开发分支，是稳定的、最新的分支，主要合并其他分支，比如 feature 分支、bugfix 分支。每个版本发布的 release 分支从 develop 分支检出。对于旧版本的 bugfix，需要从 develop 检出分支，修复后合回 develop。

release

每个确认要发布的版本测试稳定之后，基于 develop 检出独立的 release 分支，来确保发布流的稳定；发布之后，合到主干分支（develop 和 master），并打上 tag。每个 release 分支会保留 2 个版本。命名规则 release + 版本描述，示例 release_v1.0.0。

eg.) release/release_v1.0.0

feature（具体按功能命名）

新功能（需求）的开发分支，新功能在 feature 分支开发并测试稳定之后，确认发布时，合并到develop进行进步一测试，等待发布。合并时注意，先 rebase develop 分支，然后提交合并到 develop 分支，并且要确保提交历史整洁性。

eg.) feature/moment_preview
     feature/bugfix_moment_preview

hotfix

紧急 bug 修复分支。已发布的版本，需要紧急修复 bug 重新上线，从之前 release 分支检出 hotfix 分支来修复和发布；发布之后，合到主干分支（develop 和 master），并打上 tag。命名规则 hotfix + 版本描述，示例 hotfix_v1.0.0。

eg.) release/hotfix_v1.0.1

git commit

commit 原子化

为了方便追溯，每个 commit 以尽量小的单位进行 commit，粒度要适当。
一个 commit 一个需求或功能点，一个 commit 一个 bugfix。

commit message：

对于较大内容体的提交，commit 的 message 第一行写总结性的描述，然后空一行，再对提交做详细的描述
commit 的 message 要详细的描述修改内容，对于解决的问题，需要描述原因。
- 参考：解决因为 xxx 而引起 xxx 的问题，优化了因为 xxx 导致的 xxx 问题；如：解决因为 xxx 而导致崩溃问题，解决因为 xxx 情况下空指针导致的崩溃问题
- 禁止：解决了一个崩溃问题，解决了UI不对的问题……
需要注明改动的影响面，尤其是在bug平台上无法体现的优化。
- 格式：换行，[影响范围] xxxx。

commit 整合

禁止将过于零散的 commit 提交合并到主干分支：对于需求或者模块化的 commit，尤其是在协作开发时，如果 commit 过于零散的，需要整合成一个 commit，使用 git rebase -i。

commit 样板

__【标题】内容__，如“【Feature】xxxxx”。

commit 标题：

【Update】 工程配置等相关信息更新
【Optimize】 优化类的提交
【Feature】 需求方面的提交
【Bugfix】 针对 bugfree 上的 bug 修复
- 对于 Bug 的 commit需要体现具体的bugid或者bug链接。

commit示例

【Bugfix-90011】解决480*320屏幕的机型，特效框显示不完整问题

【Feature】产品要求修改设置页检查更新new逻辑

【Optimize】优化消息收发速度，提升10%成功率

【Update】更新人脸识别静态库v1.1.0版本：优化人脸识别速度

git merge & git rebase

git merge

Fast-Forward 的合并才能进行直接 merge，否则必须使用 rebase，确保时间轴的单一性。
对于已经 merge 过的分支，不要使用 rebase，避免重复的 commit 节点。

git rebase

本地分支开发一段时间之后，如果要合并回主干分支，必须先 rebase 主干分支，再进行合并。
减少不必要的 commit，对于需求或者模块化的 commit，尤其是在协作开发时，如果 commit 过于零散的，需要整合成一个 commit 才能合并到主干分支；使用 git rebase -i。

Merge request

严格遵循 分支模型 提交合并请求
代码必须经过严格自测，才能提交合并到主干分支；对于新功能，必须达到一定的完成度，才能合并到主干分支。
尽早提交 merge request，避免代码堆积引起过多冲突，增加审核成本。
当存在还没有合并的 merge request，需要合并完之后，再 rebase 提交，确保时间轴的单一性。
Bugfix 阶段，merge request 中 commit 数量不能超过5个；需求阶段可灵活控制。
Bugfix 阶段，修改了 Bugfree 状态的 commit，要及时合并（当天的要在当天合并完）。
Merge request 被合并之后，及时清理无用的远程分支。

git log

master、develop 等主干同步时，用__git log master..develop__，确认是否一致

技巧：

git log branch1..branch2  # 显示 branch2 比 branch1 前进多少 commit

展开全文 >>

tags