Git Flow 研发流程

目录

Git Flow

最简单的 Git Flow 主要有 3 个步骤：

1. 在工作区修改文件。
2. 将文件的快照放入暂存区。
3. 找到暂存区的文件，将快照永久性存储到 Local Repo。

详细的说，Git Flow 的项目存在两个长期分支：

1. 主分支（Master branch）：存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；
2. 开发分支（Develop branch）：用于日常开发，存放最新的开发版。

其次，项目存在三种短期分支，一旦完成开发，它们就会被合并进 Develop 或 Master branch，然后被删除：

1. 功能分支（Feature branch）
2. 补丁分支（Hotfix branch）
3. 预发分支（Release branch）

之所以如此设计，是因为当开发一个新的 Feature 时，可能会有很多的 Commits。所以应该将 Feature 完整实现并通过测试之后再 Merge 到 Master 主干。

Git Flow 的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。这个模式是面向 “版本发布” 的，并不适用于 “持续发布（代码一有变动，就部署一次）” 的场景。

Github Flow

Github Flow 是在 Git Flow 基础上，由 Github 提出的最佳实践。Github Repo 只有一个长期分支，就是 Master。官方推荐的流程如下：

1. 根据需求，从 Master 主干拉出本地的新分支。
2. 新分支开发完成后，或者需要讨论的时候，就向 Remote Repo 发起一个 Pull Request（PR）。
3. Pull Request 既是一个通知，又是一种对话机制，大家可以一起评审和讨论你的代码。过程中，你还可以不断地根据反馈提交代码修改。
4. 你的 Pull Request 被接受，合并进 Master 主干。此后，上述拉出来的那个新分支就会被删除掉。

Github Flow 的最大优点就是简单，对于 “持续发布” 的产品，可以说是最合适的流程。通常的，Master 主干的更新与产品的发布是一致的，也就是说，Master 主干的最新代码，默认就是当前的线上代码。

Github Flow 使用规范流程

1、新建分支

每次开发新功能，都应该新建一个单独的本地分支：

# 获取主干最新代码
$ git checkout master
$ git pull

# 新建一个开发分支 myfeature
$ git checkout -b myfeature

2、提交分支修改

分支修改后，就可以 Commit 了：

$ git add --all
$ git status
$ git commit --verbose

此时的 Commit 只是提交到 Local Repo，并不会影响到 Remote Repo，而且提交 Commit 时，必须撰写提交信息，说明这个 Commit 的内涵。

3、与 Remote Repo 的 Master 主干保持同步

分支的开发过程中，要经常与 Remote Repo 的 Master 主干保持同步，避免代码冲突的情况：

$ git fetch origin
$ git rebase origin/master

4、合并多个 Commits

分支开发完成后，在 Local Repo 很可能会出现多个 Commits，但是真正合并到 Remote Repo 的 Master 主干时，往往希望只体现为一个 Commit，这样不仅清晰，也容易代码评审和管理。

$ git rebase -i origin/master

• -i：表示互动（interactive），此时的合并 git 会打开一个互动界面，进行下一步操作。

pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

上面的互动界面，首先列出当前分支最新的 4 个 Commits（越下面越新）。每个 Commit 前面有一个操作命令，默认是 pick，表示该 Commit 被选中要进行 rebase（合并）到 Local Repo Master 的操作。

除了 pick 操作指令之外，还有：

• pick：正常选中。
• reword：选中，并且修改提交信息。
• edit：选中，rebase 时会暂停，允许你修改这个 Commit。
• squash：选中，会将当前 Commit 与上一个 Commit 合并。
• fixup：与 squash 相同，但不会保存当前 Commit 的提交信息。
• exec：执行其他 Shell 命令。

其中，squash、fixup 是用来合并 Commits 的，将指定的 Commits 从 pick 替换为 squash 或 fixup 即可：

pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
s 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

这样一来，当前分支只会剩下两个 Commits，第 2、3 个 Commits，都会合并到第 1 个 Commit。使用 squash 时，Commit Message 会同时被包含；使用 fixup 时，被合并的 Commit Message 不会被包含。

或者，还有另一种方式：先撤销过去的 5 个 Commits，然后再建一个新的 Commit，这样也实现了 Commits 的合并：

$ git reset HEAD~5
$ git add .
$ git commit -am "Here's the bug fix that closes #28"
$ git push --force

5、推送提交到远程仓库

合并 Commit 后，就可以推送当前分支到 Remote Repo 了。

$ git push --force origin myfeature

• –force：因为 rebase 以后，分支历史改变了，跟远程分支不一定兼容，有可能要强行推送。

6、发出 Pull Request

提交到 Remote Repo 以后，就可以发出 Pull Request 到 Master 主干，然后让别人进行代码 Review，确认可以合并到 Master。

Git Flow 与敏捷开发

参考文档

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
http://www.ruanyifeng.com/blog/2015/08/git-use-process.html