我将任务分为两部分：后端任务和前端任务。我提出合并请求，以合并后端更改并等待其合并（和地址反馈）。在等待期间，我无法真正处理前端更改，因为它取决于后端更改，而这些更改在master分支上尚不可用。仍在审查中，从后端变更分支分支？
#1 楼
等等，跳过合并对于这种方法，您不想将
feature_a重复合并到feature_b。到master上。您要执行的操作是：从
feature_b开始feature_a，即：git checkout feature_a
git checkout -b feature_b
每当
feature_a等待合并到master时发生变化时，就以此为基础对feature_b进行基础： feature_a已被合并到master中，您只需获得新的master并在最后一次将feature_a重新建立基础：将feature_a提交（现在已经无关紧要，因为它已合并到master中）直接到master上。您的feature_b现在是从master开始的一个简单的标准分支。编辑：从注释中得到启发，请注意：如果您需要进行一些更改以影响两个功能，然后确保在
feature_a中进行设置（然后如图所示进行变基）。即使可能很诱人，也不要在两个分支的两次不同的提交中都这样做。由于feature_a是feature_b历史的一部分，因此在两次不同的提交中进行一次更改在语义上是错误的，并可能导致不必要代码的冲突或“复活”。评论
多次基于feature_a进行重新基准处理时，您可能随后会遇到问题，因为与此同时feature_a本身已被重新基准化。由于运行git checkout feature_b; git rebase feature_a可能会导致冲突或一些有趣的提交，这些提交包含还原feature_a的新更改的提交。通常可以通过使用--interactive并跳过从另一个分支的旧版本中提交的提交来解决（我最近不得不这样做了几次）。
– maaartinus
17年6月28日在22:24
@maaartinus，谢谢您的单挑，我自己还没有遇到过此类问题。与简单的合并相比，rebase可以执行更多的单个步骤，因此肯定会产生冲突的机会明显增加。另一方面，在这种情况下，合并在语义上是完全错误的。
– AnoE
17年6月28日在22:51
我猜想，合并会遇到类似或更严重的问题（冲突不如进行不必要的更改那样糟糕）。我将分支视为所需更改的序列，之后是许多不相关的更改（逻辑上属于另一个分支）。当重复使用同一分支进行基础调整时，我总是删除无关的更改，因为我知道它们无论如何都会出现（可能是更新的形状），并且效果很好。
– maaartinus
17年6月29日在3:15
@maaartinus，我为此添加了一个小附录（以一致地进行更改，这些更改仅需要在基本分支而不是两个不同的提交中才进入两个分支）。
– AnoE
17年6月29日在7:32
好的技术。这也是我一直都这样做的方式。 git rebase --on到FTW：D
–拉杜（Radu Murzea）
17年6月29日在10:10
#2 楼
我有时也有这个问题。 Git非常灵活。这是您执行操作的一种方法。您的第一个分支
featureA尚待审核。您的第二个分支
featureB正在开发中，并且取决于featureA分支中的代码。 将
featureA分支合并到featureB分支中。 如果对
featureA分支进行了更改，则应再次将featureA分支合并到featureB分支中以合并所做的更改。还应确保将
featureA合并到首先将主干合并，否则将featureB合并到主干中时，也会无意中将featureA合并。一旦将featureA合并到主干中，您就可以摆脱featureA分支，因为featureB现在仅依赖于主干。做，你必须顺其自然。评论
这很有道理。如果需要，这是否允许撤消特征A与特征B的合并？
– sul4bh
17-6-28在1:25
没有撤消操作，但是正如@ 9000所提到的，您可以创建一个新分支，并且如果必须重新开始，则可以从featureA中选择所需的提交。最好将Git分支视为一次性的。它们既便宜又容易，您随时可以建立新的分支机构。如果您想使用不确定的内容，甚至可以在featureB分支上创建一个测试分支，然后在无法解决的情况下将其报废，或者将其合并回您的featureB分支中做到了。
–马特
17年6月28日在4:34
合并将产生一团糟，将很难（不是不可能）回滚。我会选择摘樱桃或重新设置基址（即：在特性B的基础上选中特性A中的所有内容）。请参阅9000的答案。
– Pierre.Sassoulas
17年6月28日在12:47
这会创建一个复杂的历史记录，每当有人想了解featureA和featureB更改了哪些代码时，这将是很多年后的问题。
–伊恩
17年6月28日在20:27
如果FeatureA已更新，则应该重新建立FeatureB的基础，不要合并
–林登·怀特（Lyndon White）
17年6月29日在1:47
#3 楼
您已经有了一个分支，每个功能分支都依赖于此分支，并且该分支一直在变化。它称为master。功能分支与
master保持同步的典型方法是保持在其顶部。当master发生更改时，通常在分支的工作目录中使用git fetch origin master:master && git rebase master。 如果由于某种原因需要将更改移到另一个分支，则可以挑选您的提交，这些提交绝不会与其他分支的提交混合。
评论
但是我认为情况是功能b需要功能a中的代码，从master分支不会很有帮助。我应该从哪里开始？我是否应该从功能部件a分支并保持同步，直到功能部件a与主部件重新集成，然后从主部件重新定位到功能部件b？
–感官
19年4月22日在23:53
@Sinaesthetic：您当然可以将功能b建立在功能a的基础上，并随着功能a的变化一次又一次地重新设置基准。这是使大型更改可观察到的典型方法：将其分为A部分（基于主服务器），B部分（基于A部分）以及更多（如果需要）。然后对每个零件提出拉动请求，审阅者可以更轻松地查看逻辑上分组的较小零件。
– 9000
19年4月23日在3:03
在PR方面，如果我将b部分与a部分相对于master对b部分进行调整，会不会很重要？我只想确保我的更改没有像a部分中的更改那样显示a部分中的更改。另外，如果我合并vs.调整基准，那将如何影响b部分PR？每次我了解效果时，都会得到不同的结果，哈哈
–感官
19年4月23日在23:41
#4 楼
在这种情况下，如果前端任务与后端代码有关键的依赖关系，并且您想在后端完成并在master上接受之前开始在前端上工作，那么我将直接启动前端任务，将其作为功能分支从后端分支，而不是在master上分支前端。寿命足够长的功能分支需要偶尔从master进行更改合并（以确保您将任何合并或语义冲突作为dev的一部分进行协调）在功能分支上工作，而不是作为“审查，质量检查，合并到主文档”过程的一部分）。因此，您可以在前端分支上进行此操作，并且当您接受了后端工作的掌握后，您将通过与您相同的方式，自动对后端做任何细微的更改，作为其审核/接受的一部分。在master上进行其他任何代码更改。在检查过程中），那么您可能希望直接从后端分支到前端分支进行定期合并（因此，不要将所有前端工作都基于过时的后端代码）。如果您是同时使用这两项功能的唯一开发人员，那么这很容易（因为您知道自己是否进行了重大更改），但是即使最终两项功能都由不同的开发人员并行进行，也应该没问题。您只需要保持沟通即可（无论如何，如果您正在并行处理任务，而其中一项对另一项的依赖性很强，则仍然需要进行沟通）。
如果事实证明整个后端分支需要被丢弃并且永远不会被合并（听起来这将是一件非常重要的事情，几乎不会发生），那么您要么选择将提交提交到新分支，然后再脱离主分支没有后端工作，或者您应用了反向提交，从而将所有后端代码删除到了前端分支。但是，正如我所看到的，在您弄清楚将要替换的后端将要替换掉的前端，然后决定做什么之前，暂停前端工作的可能性更大。
#5 楼
我在这里看不到问题。master分支每次都具有此功能，它在开发功能并合并时会不断变化。所以，在您的具体示例，您首先创建
feature_xxx_backend分支并开发后端更改。完成此操作后，分支将进行审核，并且在审核完成后将合并到master中。您可能希望直接从feature_yyy_frontend分支，以便在branc中已经有了这些更改。然后只需开发前端功能，就好像分支是feature_xxx_backend一样。当
master分支发生变化时，例如因为在审核过程中有些事情需要解决，所以只需进行这些更改并将它们合并到feature_xxx_backend分支中即可。然后继续在前端分支上。一旦完成对后端分支的审阅，它将合并到
feature_yyy_frontend中。此时，明智的做法是将master分支重新基础到feature_yyy_frontend，以便审阅者只需要审阅该分支对master做出的新更改，而无需重新审阅为后端所做的更改（具有已经被批准）。当您有两个，三个或更多从属分支机构时，也可以这样做。如果您有两个依赖的要素分支，则简单地创建一个将两个要素合并到一起的派生分支。从那里分支，开发第三个要素，并在每个要素分支发生变化时合并两个要素分支。当这两个功能都完成并合并到派生分支中时，重新建立基础，或者在将它们合并到master中时，重新建立基础。干净的更改日志，使审核更加容易。
#6 楼
如Polygnome所述，您实际上可以将前端分支与后端分支（而不是母版）合并。即使使用当前的分支设置，也可以轻松执行以下操作：git checkout frontend
git merge backend
，或者简单地
git merge backend frontend
请记住，如果不接受后端更改并且需要进行更多工作，则必须将后端的更新合并到前端，以避免冲突。一旦更改被主服务器接受，您就可以在主服务器上重新建立前端基础，以摆脱后端合并提交。前端分支的历史。我来自哪里，这被认为是不好的做法。 YMMV
评论
“很奇怪，没有人提到您实际上可以将前端分支与后端分支而不是母版合并：”已经提到过，例如用我自己的答案。
– Polygnome
17-6-28在14:31
@Polygnome前端不必直接从后端分支。它们都可以从母版中分支出来，但是您仍然可以合并它们。因此，您的答案实际上并未提及。
– Joris Meys
17年6月28日在14:41
实际上，我的回答并不建议您直接从后端分支，它只是说那可能是要走的路（因为无论如何您将这些更改合并到前端分支中）。
– Polygnome
17年6月28日在15:04
@Polygnome，然后我误解了您的答案。特别为您更新：-)
– Joris Meys
17-6-28在15:49
我不知道谁对此表示反对，但是请告诉我我错了，这样我也可以学到一些东西。
– Joris Meys
17年6月28日在15:52
#7 楼
这里的大多数答案正确地描述了将更改从第二个分支合并到第一个分支的过程，但是它们并未解决如何最大程度地减少您可能需要解决的冲突。您想要分别查看的两组重大更改（例如
featureA和featureB），创建的PR不是要合并的，而是要收集关于featureA的PoC的早期反馈。能够快速对其进行审核（这只是一个PoC），目标是验证总体设计或方法。然后，您可以继续处理功能A，为其创建拉取请求并分支然后使用功能B。代码审查和所需的更改可能是微妙的和局部的，而不是“糟糕，您需要一种不同的方法”。这将使以后在
featureA的代码上合并featureB时所需要做的工作最少，而无论选择哪种方法。
评论
为什么不能针对尚未审查的后端代码编写它？您的团队是否具有某种商定的技术来处理这种情况？如果不是，也许您应该就这样的事情达成共识，因为这是相当普遍的情况。
空无一人。这就是我问这个问题的原因。我有很好的建议。我将尝试这些建议，看看它们如何为我解决。
@ user253751关注点分离。
@RobinHood傻傻的理由。