Question

我们有一个保存BSP和BSP的存储库。 GUI Widget。然后我们从master分支编写主应用程序，并进行单元测试。我从master创建了一个分支来测试键盘小部件：tst-keypad。

在这个分支中，我合并了master的更新，但有时我需要导入键盘错误修复和新功能。另外，我添加了一些属于测试的代码（例如：添加输入和日志）。

到目前为止，我将键盘源代码中的更改与测试代码中的更改分开，以便在主分支中使用cherry-picks（仅键盘）应用提交，因为合并还将应用特定于测试的提交

           B1--B2--B3------   <-- branch test (HEAD)
          /        / <-- cherry-pick B3 because B1 and B2 are "test specific".
A1--A2--A3   <-- master

但是我经常只做键盘改进，但我仍然不能使用合并，因为它也会应用旧的测试特定提交。有没有办法“重新设置”master，因为下一次测试合并不适用旧提交？

Answer 1

虽然您的工作流程远非标准，我建议您重新考虑它，但这并不是您所要求的。所以：

有没有办法去＆＃34; rebase＆＃34; master作为下一次测试合并，不申请旧提交？

有很多方法可以获得这种效果（但不是真的通过变基）。例如，在上面的场景中，您（在挑选之后）：

A1 -- A2 -- A3 -- B3` <--(master)
              \
               B1 -- B2 -- B3 <--(test)

其中B3'对A3上应用的B3上的B2应用相同的更改。因此，从概念上讲，此时所有的更改（包括B3都会在主数据中进行说明。你只需要让git相信。

因此，一种选择是与战略合并＆＃34;我们的＆＃34;。

git checkout master
git merge -s ours test

产生

A1 -- A2 -- A3 -- B3` ------- M0 <--(master)
              \              /
               B1 -- B2 -- B3 <--(test)

其中M0不对B3'应用任何更改，但如果后续从B3合并到test，则可确保将master视为合并基础。< / p>

如果您进行包含合并的rebase，则在合并中使用替代策略会导致麻烦;但是，无论如何通常都不建议使用此类rebase，在这种情况下，rebase可能会在尝试协调合并时报告冲突（因为B3和B3'）。不过，还有其他选择：

你可以执行＆＃34;正常＆＃34;从分支合并到主服务器然后还原它。这基本上告诉git你永远不想要合并那个分支。（但最初的合并可能会发生冲突。）

或者，而不是挑选B3 （所以从

开始

A1 -- A2 -- A3 <--(master)
              \
               B1 -- B2 -- B3 <--(test)

相反），你可以

git checkout test
git checkout -b keypad_changes
git revert B1 B2
git checkout master
git merge keyboard_changes
git branch -d keyboard_changes

给你

A1 -- A2 -- A3 --------------------------- M <--(master)
              \                           /
               \                !B2 -- !B1
                \              /
                 B1 -- B2 -- B3 <--(test)

这次M应该是＆＃34;正常＆＃34;合并 - 希望没有冲突 - 有效地仅应用 B3，同时仍然建立B3作为合并基础。

Answer 2

通常，您可以创建要素分支并将它们合并到两个分支中。那么你就不会遇到一些问题，即你在生产系统中有一些你不想要的提交。

Atlassian有一个很棒的工作流程教程

https://www.atlassian.com/git/tutorials/comparing-workflows

功能分支和其他非常好的部分有一部分如何处理分支。

git - 如何处理分支“测试”

2 个答案: