1. Git 工作流(Git workflows)
Git 工作流可以理解为一种最佳实践,Vincent Diressen 大神的博客上有一篇经典文章 A successful Git branching model 。当然,也有另一位大神 Scott Chacon 写了篇文章来讨论这个模型 Issues with git-flow 的好坏。所以在研究 Git 工作流之前得有个前提,工作流没有对错,没有标准,就是团队协作的一个约定(convention),就像不要争论哪门语言好用一样,关键是适不适用。
1.1 传教士风格的 Git 工作流
我们首先来分析一下 Vincent Diressen 从严格的软件工程角度出发提出的 Git 工作流模型,模型如下:
这种风格的工作流将分支分成 Main branches
和 Supporting branches
。
Main branches 包括:
- master
- develop
Supporting branches 包括:
- Feature branches
- Release branches
- Hotfix branches
Feature branches
May branch off from:
develop
Must merge back into:
develop
Branch naming convention:
anything except master, develop, release-*, or hotfix-*
Release branches
May branch off from:
develop
Must merge back into:
develop and master
Branch naming convention:
release-*
Hotfix branches
May branch off from:
master
Must merge back into:
develop and master
Branch naming convention:
hotfix-*
1.2 自由风格的 Git 工作流
- 1 - anything in the master branch is deployable
- 2 - create descriptive branches off of master
- 3 - push to named branches constantly
- 4 - open a pull request at any time
- 5 - merge only after pull request review
2. Git 约定(Git conventions)
2.1 branch 命名约定
连字符分割风格(Hyphen separated)
- master
- develop
- feature-XXX
- release-XXX
- hotfix-XXX
斜线分割风格(Slash separated)
- master
- develop
- feature/XXX
- release/XXX
- hotfix/XXX
2.2 commit 信息约定
commit 中尽量使用 动词 作为开头,例如
Add
Allow
Apply
Enable
Fix
Ignore
Implement
Integrate
Move
Make
Remove
Support
Switch
Update
2.3 操作约定
下面的说明假设已经存在以下配置:
- Fork Repo 后 默认 remote 为 origin
- git remote add upstream 远程Repo
1. Branch off
当需要开发新功能或者修正bug时建议的操作为:
git fetch upstream
git checkout -b feature/xxxx upstream/develop
应尽量避免使用如下操作
git rebase upstream/develop
2. Branch switch
当 PR 提交后,如果需要另外开发新功能或修正其他问题,需要及时切换分支,避免在原分支上继续操作,影响提交内容。
操作示例:
git checkout -b feature/xxxx upstream/develop
3. PR 本地验证
PR 在进行 Review 和验证前不能合并,本地验证方法参考:https://help.github.com/en/articles/checking-out-pull-requests-locally
操作示例:
git fetch origin pull/101/head:PR101
git checkout PR101