git flow与Cherry-picks

我们有prod生产发布和dev持续开发分支。

我们目前的流程：

我们主要在dev分支机构工作，客户会不时决定他想使用哪些功能/错误修正，prod然后我们挑选它们。

根据我的理解，樱桃小菜与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

笔记

我们对每个提交使用原子提交，以使其具有明确的意图。这简化了审核/责备/平分流程

我们使用自定义消息进行合并，因为它比默认描述更具描述性 Merge 'issue-12345' into 'dev'

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

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

当客户决定将问题＃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，释放分支未使用

据称git flow，只有要素分支应该基于dev分支，并且永远不要合并到prod。

但是，修补程序分支应基于prod，然后合并到prod和中dev。

为什么git flow不适用于我们

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

如果我们基于的功能分支dev，则如果需要，我们将无法将其合并到prod以后（可能要晚得多）

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

例子1

假设我们有一个任务＃12345来实现一个新Contact Us页面。然后，我们有一个任务＃23456将页面的背景颜色从白色更改为黄色。

我们issue-12345从中建立分支机构prod，然后将其合并到中，dev并等待批准将其合并到中prod。

然后，我们开始研究issue-23456并prod再次基于。但是prod代码甚至还没有提及Contact Us页面。因此，我们必须做一些奇怪的事情，例如将issue-12345分支合并到issue-23456第一位。

即使是那种简单的情况，也足够复杂。您可以想象，如果您想使用其他任务中引入的一些代码，将会更加困难。

例子2

任务＃34567要求执行Feedback页面。此页面与页面非常相似，Contact Us因此具有相似的CSS。我们想重用它。但是如何？说＃34567取决于＃12345是不公平的。因此，issue-34567基于issue-12345。所以呢？手动重写代码？复制粘贴？还是还在摘樱桃？

我没有针对此类问题的任何合理解决方案。

1> VonC..：

---

git-flow（在此处翻译为常规git命令）基于合并分支（功能集成到dev，功能集成到master）

git cherry-pick 与合并不兼容，原因是：

复制合并中的提交，

功能依赖

因此，如果您当前基于工作流程的工作流程很合理，那么您应该保留它。
但是，如“ 如果您选择樱桃，则分支模型错误 ”中所述：

他们的见解是，使用git（或任何基于DAG的SCM），如果您可以预料到可能/将要在何处应用提交，则可以将其放在其自己的分支上，并根据需要将其合并到各个位置。

这会将更改应用到所有必要的分支（您可以将其合并到发行版和母版中），但不会导致提交被复制/粘贴。相反，将记录新的合并提交，因此不会记录新的提交ID，并且在DAG中可以很好地跟踪历史记录（分支有什么提交？）。

然而：

不选择樱桃的缺点是，您需要预先知道要将提交应用到多个位置，以便可以将其放在自己的分支上。

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

---

关于git-flow，这确实不适合您。集成模型更准确：

有一个integration分支始于master和的分支比较简单：

具有从分支创建的integration分支

每次合并其他功能时，这些相同的功能分支就会基于更新后的integration分支重新建立integration：涉及与负责该功能分支的团队进行沟通，因为每次重新建立基础时，他们都必须重置自己的功能分支副本（因为它的历史会改变）

如果删除了某个功能部件，则该功能部件的合并提交（将功能部件分支合并到的结果integration）可以随时还原：尚未合并的所有其他功能部件分支都需要在更新后的integration分支顶部重新建立自身。

一旦integration分支是功能齐全，并已通过了用户验收测试，它会被合并master（或prod）

---

在OP的场景中，当功能可以随时单独进入产品时，您不需要dev或integration：

第1天prod= dev=integration

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

第2天。发布了第一期。在这里很明显。所有分支都相同。所以我们可以git checkout prod -B issue-1

第3天。问题＃1已修复。我们issue-1可以在任何地方合并分支吗？

合并--no-ff integration

第4天。提出了问题2。再次基于整合分支？

这里根据prod。特别是如果有问题（在中检测到prod）。
如果它是一项功能，则可以考虑从中启动integration，但是由于将从中删除功能integration，因此早日集成的好处将无济于事。

第5天。问题＃2已修复。合并到任何地方？

到integration（merge --no-ff），检查问题2是否与问题1兼容。

第6天。第2期获得批准进入产品。我们做什么？

首先，issue-2基于prod（如果自那时以来已发展出产品）重新建立基础，
然后再转换merge --no-ff issue-2为prod。

重置integration为prod，然后将所有其他功能分支合并回integration，以验证它们是否可以在新产品（现在包括issue-2）上一起正常使用。

第7天。第1期被批准进入产品。我们做什么？

首先，issue-1基于prod：重新issue-1建立基础，即使基于issue-2（已合并到prod先前）之上，也将验证仍在工作。
然后，合并--no--ff。

请注意，使用merge --no-ff会在功能部件/问题分支中prod或integration从功能部件/问题分支中生成合并提交：如果需要从中删除该功能部件/问题prod，您要做的就是在prod或中还原该唯一的合并提交integration（而不是还原系列）代表要删除的分支的提交数）。