下面的Git提交策略是否正确？

我刚刚用Git完成了以下工作，但我不确定这是否是正确的做事方式。我拥有的是一个有一些东西的文件。然后有一个分支为这个文件添加额外的东西（扩展它，它是我们单独销售的插件）。比方说，BRANCH1和BRANCH2有以下内容的文件：下面的Git提交策略是否正确？

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

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

然后我做了一大特色一些工作BRANCH1，并提出了承诺分支。之后，我将branch1合并到branch2中，以将此新特性重新应用于该文件的插件版本。现在，这些文件

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

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

但代码完全不起作用，我现在需要一些改变切换到BRANCH2并做有扩展文件中的代码（变“QWE”到“QWER”）。然而，在工作中，我也在基本代码（“1234”）中发现一些错误并修复它们（将“1234”更改为“12345”）。现在

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

现在我需要提交此与BRANCH2的HEAD是我的工作目录有以下，我的目标的结果是

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

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

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

这样做的伎俩，但因为我对Git比较新，我不是很确定我是否正确地使用了正确的东西并且以最好的方式。请让我知道，如果上述情况是有道理的，如果它不请告诉我一个更好的方式来做到这一点。

来源

2012-02-17 Eugene

你的方法对我来说似乎合理。然而，我会这样做：

只要我看到基本代码中的错误，就隐藏并切换到branch1，并在那里修复它们。测试，波兰语，承诺。
丢弃branch1的旧合并到branch2中，并用第1步中的修复重做它（我了解手动合并git-rerere可以减少重复的工作，但我从来没有使用它），或者只是再次合并并生活在一个稍微混乱的历史。

这确保了“错误修复”实际上适合BRANCH1和Branch2的代码之外不巧妙打破，他们在两个分支相同。

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

来源

2012-02-17 19:27:33

我们使用发布候选分支来组合不同的功能。雷雷是你想要依靠的东西。进一步阅读这里：

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

来源

2012-02-17 21:54:19

可以使用互动附加（GIT添加-p）上演的 'QWER' 变化，并承诺BRANCH2，但不是使用：

git stash 
git checkout branch1 
git stash pop

你可以：

git checkout -m branch1

您想要改变其传输到工作树BRANCH1并为您节省一些Git命令

来源

2012-02-18 16:21:09 ralphtheninja

下面的Git提交策略是否正确？

回答

相关问题