以下 Git 提交策略是否正确？

Question

我刚刚用 Git 做了以下事情，但我不确定这是否是正确的做事方式。我所拥有的是一个包含一些东西的文件。然后有一个分支向这个文件添加额外的东西（扩展它，它是我们单独出售的插件）。假设 branch1 和 branch2 有一个包含以下内容的文件：

-----------
branch1
-----------
123

-----------
branch2
-----------
123
qwe
-----------

然后我在 branch1 的一个主要特性上做了一些工作，并对该分支进行了提交。之后，我将 branch1 合并到 branch2 以将此新功能也重新应用于文件的插件版本。现在文件是

-----------
branch1
-----------
1234

-----------
branch2
-----------
1234
qwe
-----------

但是代码并不能完全正常工作，我现在需要切换到 branch2 并对在那里扩展文件的代码进行一些更改（将“qwe”更改为“qwer”）。但是，在工作时，我还在基本代码（“1234”）中发现了一些错误并修复了它们（将“1234”更改为“12345”）。现在我的 HEAD 位于 branch2 的工作目录具有以下内容

-----------
branch2 (working directory)
-----------
12345
qwer
-----------

现在我需要提交这个，我想要的结果是

-----------
branch1
-----------
12345

-----------
branch2
-----------
12345
qwer
-----------

我担心，如果我只是将其提交给 branch2，然后将单独重新应用 1234->12345 更改到 branch1 并提交，这将产生我正在寻找的结果，但 Git 会将其识别为两个独立且完全独立提交，并且当我将来经历类似的过程时（例如，branch1 中的 12345->123456，然后是 branch1->branch2 合并），我会在那个地方发生冲突。所以我的解决方案是使用交互式暂存仅将 qwe->qwer 更改提交到 branch2。然后 stash 剩余的更改（否则不允许切换回 branch1），切换到另一个分支，应用 stash，将 1234->12345 提交到 branch1，最后合并 branch1->branch2。

但是因为我对 Git 比较陌生，所以我不太确定我是否正确地以最好的方式使用了这些东西。请让我知道以上是否有意义，如果没有，请告诉我更好的方法。

Answer 1

你的方法在我看来是合理的。但是，我会采取不同的做法：

1. 我一看到基本代码中的错误，就把它们藏起来并切换到 branch1，并在那里修复它们。 测试、润色、提交。

2. 将 branch1 的旧合并丢弃到 branch2 并使用步骤 1 中的修复程序重做（我知道手动合并 git-rerere 可以减少重复的工作，但我从未使用过），或者只是再次合并，并生活在稍微混乱的历史中。

这样可以确保“错误修复”实际上适用于 branch1，并且不会在 branch2 代码之外被巧妙地破坏，并且它们在两个分支中都是相同的。

另一方面，“不要那样做”的回答：“插件”需要修改主程序代码是糟糕的软件架构；这使得它不是真正的插件。如果你解决了这个问题，那么主程序和插件将成为独立的树（就你对 Git 的使用而言）并且不需要合并（尽管仍然可能需要更新兼容性，如在你的 qwe→qwer 中）。

Answer 2

您可以使用交互式添加 (git add -p) 暂存“qwer”更改并将其提交到 branch2，但不要使用：

git stash
git checkout branch1
git stash pop

你可以：

git checkout -m branch1

它将您的更改转移到 branch1 的工作树中并为您节省一些 git 命令

Answer 3

我们使用发布候选分支来组合不同的功能。 Rerere 是您想要依靠的东西。在此处进一步阅读：

http://dymitruk.com/blog/2012/02/05/branch-per-feature/