git flow vs 樱桃选择

Question

我们有分支 prod 用于生产版本和 dev 用于持续开发。
我们目前的流程:
我们主要在 dev 分支工作，客户不时决定他想要来 prod 的功能/错误修复，然后我们挑选它们。
根据我的理解，cherry-picks 与 git flow 模型相矛盾。
到目前为止，我不知道如何调整我们的流程来避免它。
git flow 假设您事先知道是否应该更改为 prod
社区是否有解决方法？
更新:我发现我的问题需要更好地澄清术语
我们现在使用的
实现一个问题 #12345

git fetch
git checkout origin/dev -B issue-12345 # new branch for issue #12345 from bug tracking system
# ... do many atomic commits
git fetch
git checkout origin/dev -B dev
git merge issue-12345 --no-ff -m "Bug #12345 - Bug title from bug tracking system"
# ... fix merge conflicts if any and commit
git branch -D issue-12345
git push

笔记

我们对每个提交使用原子提交来有明确的意图。这简化了审查/blame/二等分流程

我们使用自定义消息进行 merge ，因为它比默认的 Merge 'issue-12345' into 'dev'

更具描述性

我们通过 --no-ff 强制非快进 merge ，因为我们希望所有问题都表示为 merge 。因此 git log dev --first-parent 返回已完成任务的高级 View

我们不使用 git merge --squash 及其 rebase 类似物。我们希望保留整个任务历史记录

当客户决定将问题 #12345 投入生产时

git fetch
git checkout origin/prod -B issue-12345
git log origin/dev --grep "#12345" --oneline --reverse # get all commits that have to be cherry-picked, usually that's only one merge commit (abcd1234)
git cherry-pick abcd1234 -x -m 1 # '-m 1' required for cherry-picking merge commit
# ... fix merge conflicts if any and commit
# ... repeat for other commit if any
git checkout origin/prod -B prod
git merge issue-12345-prod --no-ff -m "Bug #12345 - Bug title from bug tracking system"
# ... fix merge conflicts if any and commit (although that's unlikely for them to occur)
git branch -D issue-12345
git push

git flow 告诉我们做什么
有关更多详细信息，请参阅 http://nvie.com/posts/a-successful-git-branching-model/
在那篇文章中我们的 dev 分支对应 develop ， prod 对应 master ，没有使用 release 分支
根据 git flow ，只有特征分支应该基于 dev 分支，并且它们永远不会 merge 到 prod 。
然而，修补程序分支应该基于 prod ，然后 merge 到 prod 和 dev 。
为什么 git flow 不适用于我们

我们事先不知道任务是否需要转到 prod 分支。

如果我们基于 dev 的特征分支，我们将无法在稍后将其 merge 到 prod 中(如果需要的话)

如果我们基于 prod 的特征分支，我们将无法从之前完成的其他任务中受益。

示例 1
假设我们有一个任务 #12345 来实现一个新的 Contact Us 页。然后我们有一个任务 #23456 将页面的背景颜色从白色更改为黄色。
我们基于 issue-12345 的 prod 分支，然后将其 merge 到 dev 并等待批准将其 merge 到 prod 。
然后我们开始研究 issue-23456 并再次基于 prod。但是 prod 代码甚至还没有提到 Contact Us 页。所以我们必须做一些奇怪的事情，比如先将 issue-12345 分支 merge 到 issue-23456 中。
即使是那个简单的案例，这也足够复杂了。而且你可以想象，如果你想使用其他任务中引入的一些代码，它会困难得多。
示例 2
任务 #34567 要求实现 Feedback 页。此页面与 Contact Us 页面非常相似，因此具有相似的 css。我们想重用它。但是如何？说#34567 依赖于#12345 是不公平的。因此，将 issue-34567 建立在 issue-12345 上是不合逻辑的。所以呢？手动重写代码？复制粘贴？或者仍然是 cherry-pick ？
对于此类问题，我没有看到任何合理的解决方案。

Answer 1

git-flow(见 here translated as regular git commands)基于 merge 分支(功能到 dev，dev 到 master)git cherry-pick与 merge 不兼容，因为:

duplicating commits on merge ,

functional dependencies

因此，如果您当前基于挑选的工作流程有效，您应该保留它。
但是，如“ If you cherry pick, your branch model is wrong ”中所述:

Their insight is that, with git (or any DAG-based SCM), if you can anticipate where a commit may/will be need to applied, you can put it on it’s own branch, and merge it into those various places as needed.

This will get the change applied to all the necessary branches (you can merge it into release as well as master), but not result in the commit getting copy/pasted. Instead, new merge commits will be recorded, so no new commit ids, and the history (what branches have this commit?) is tracked nicely in the DAG.

然而:

The con to not cherry picking is that you’ll need to know up front that you want your commit applied into multiple places, so that you can place it on it’s own branch.

在您的情况下，这将涉及多个单独的功能分支，只有在客户批准后才 merge 到主分支。

关于 git-flow，它确实不适合您。集成模型更准确:
拥有 更简单integration 从 master 开始的分支与:

从 integration 创建的功能分支分公司

那些相同的功能分支重新基于更新的 integration每次其他功能 merge 到 integration 时分支:这涉及与负责该功能分支的团队进行沟通，因为每次重新设置功能分支时，他们都必须重置自己的功能分支副本(因为它的历史会改变)

来自功能的 merge 提交，将功能分支 merge 到 integration 的结果, can be reverted at any time if that feature is dropped :所有其他尚未 merge 的功能分支需要在更新的 integration 之上重新调整自己分支。

曾经 integration分支功能完整并已通过用户验收测试，将 merge 到 master (或 prod)

从 OP 的场景来看，当功能可以随时单独进入生产环境时，您不需要 dev或 integration :

Day 1. prod=dev=integration

让我们只考虑 prod和 integration在这里，以及功能或问题分支。

Day 2. Issue #1 raised. Here it is obvious. All branches are the same. So we can git checkout prod -B issue-1

Day 3. Issue #1 fixed. Do we merge issue-1 branch anywhere?

merge --no-ff 到 integration

Day 4. Issue #2 raised. Basing from integration branch again?

这里基于 prod .特别是如果它是一个问题(在 prod 中检测到)。
如果是特性，可以考虑从 integration开始，但由于功能将从 integration 中删除，早期集成的好处并不能保证。

Day 5. Issue #2 fixed. Merging anywhere?

致 integration ( merge --no-ff )，检查问题 2 是否适用于问题 1。

Day 6. Issue #2 approved to get into prod. What do we do?

一、rebase issue-2顶部 prod (如果产品从那时起已经发展了)
然后 merge --no-ff issue-2至 prod .
重置 integration至 prod ，并将所有其他功能分支 merge 回 integration ，以验证它们是否在新产品(现在包括 issue-2 )之上一起发挥良好。

Day 7. Issue #1 approved to get into prod. What do we do?

一、rebase issue-1顶部 prod :这将验证 issue-1仍在工作，即使基于 issue-2 的顶部(之前已 merge 到 prod 中)。
然后， merge --no--ff。
注意使用 merge --no-ff ，它会在 prod 中生成一个 merge 提交或 integration从功能/问题分支:如果需要从 prod 删除所述功能/问题，您需要做的就是在 prod 中恢复唯一的 merge 提交。或 integration (而不是恢复代表要删除的分支的一系列提交)。