以下Git提交策略正确吗？

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

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

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

然后，我在branch1中的一个主要特性上做了一些工作，并对该分支作出了承诺。之后，我将branch1合并到branch2中，以便将这个新功能重新应用到文件的插件版本。现在这些文件都被删除了

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

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

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

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

现在我需要做这件事，我的目标是

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

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

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

---

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

你的方法对我来说似乎是合理的。不过，我会采取不同的方式：

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

扔掉旧的branch1到branch2的合并，并使用步骤1中的修复程序重新进行（我知道手动合并

git Reere

可以减少重复的工作，但我从未使用过它），或者只是再次合并，过着稍微混乱的历史生活

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

---

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

我们使用一个发行候选分支来组合不同的功能。下面是您想要依靠的内容。请进一步阅读此处：

---

您可以使用interactive add（git add-p）来启动“qwer”更改并将其提交给branch2，但不使用：

git stash
git checkout branch1
git stash pop

你可以：

git checkout -m branch1

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