这种工作流程是我总结的，主要吸收的是 GitFlow 和 GithubFlow 的优点，兼顾简易性和严谨性，适用于规模不大的团队。大团队遵循团队原有的工作流程即可，或遵循下文中 3 种标准的工作流。
项目开发初期，只在 main 分支上进行。这一阶段的主要工作是搭建项目框架、编写基础代码。力求快速完成，基本只解决依赖管理、编译构建等问题，不涉及业务逻辑。
之后按照以下工作流程进行。
当积累适当多的 feature 后，对当前 main 分支进行打包，定版本后发布。可以将 develop 分支作为测试通道发布。不同的通道（channel）使用不同的发布频率，根据 feature 数区分。
进行 feature 开发时，根据设想的功能，从 develop 分支上拉取新分支。开发完成后，向 develop 分支发起 pull request。
从 feature 分支合并向 develop 分支时，使用 --no-ff 参数。请注意：sqush merge和rebase只允许在这个过程中使用。
当 develop 分支上的 feature 达到一定数量并通过测试后，可以将 develop 分支合并到 main 分支。
将 develop 分支合并到 master 分支时，使用：
git checkout master
git merge --no-ff develop
默认情况下，Git 执行 "快进式合并"（fast-farward merge），会直接将 Master 分支指向 Develop 分支。使用 --no-ff 参数后，会执行正常合并，在 Master 分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考 Benjamin Sandofsky 的《Understanding the Git Workflow》。
命名规范：
feature-* 的格式。hotfix-* 或 fixbug-* 的格式。release-* 的格式。优点：清晰可控。
缺点：
新功能开发完成后，向 main 分支发起 pull request。
如果新功能需要讨论，也可以发起 PR，同贡献者讨论、review代码，在过程中也可以继续提交代码。
PR 被接受后被合并入 main 分支，部署后原分支被删除。
优点：
缺点：
遵循“上游优先”（upstream first）的原则，即：所有的修改都必须先合并到上游分支（主分支 main），然后再合并到下游。
遵循上下游排序原则，代码的变化必须从相对上游合并至下游。只有紧急情况，才允许跳过上游。
从上游到下游的变化合并使用cherry-pick，只有在需要全部接纳的情况下才使用merge。
优点：
缺点：
cherry-pick提交可能会导致一些意想不到的问题参考文档：