Git工作流程是否可以进行部分合并？

Question

我有两个分支机构dev和a 。 我需要将功能a合并到dev ，但是我的队友已经在一个尚未准备好合并的文件中创建了某些功能。 如果我只是使用我的合并和解析，则git将此文件中的更改标记为无效，而不是允许这些更改在以后合并，如果我尝试重新合并分支，请快速前进。 如果我不解决冲突，则git拒绝执行合并。

解决此问题的策略是在旁边创建一个分支并抑制损坏的功能，然后在该分支中合并。 问题是为此的git命令变得有些复杂，因此我需要专家的帮助。

我想尽可能将这种类型的动作推广到git扩展中，我称之为git-cherrymerge 。

步骤如下：

1. 将用户指定的提交（也许可以通过某些策略自动执行）重播到临时分支上
2. git filter-branch删除损坏的文件
3. 压榨临时分支，添加自动提交消息
4. 将临时分支合并到目标分支（此处为dev）

我不是很专家filter-branch或rebase ，它看起来像我可以很认真地滥用武器伤害的历史 。

我想我的问题是

1. 请问这项工作还是有更好的规范方法来做到这一点？
2. 我应该按什么顺序执行什么git命令，以免意外损坏存储库历史记录。

Answer 1

您基本上有一个正确的想法，您想要将一个分支变成两个分支：一个分支，其中包含准备就绪的内容，另一个分支是未完成的更改。 例如，一个分支可能包含大量重构和错误修复，这些错误与不完整的功能交错在一起。

A - B - C - D [master]
         \
          R1 - B1 - F1 - R2 - B2 - F2 [feature]

R1和R2正在重构更改。 B1和B2是错误修正更改。 F1和F2是不完整的功能。 您想要的是：

A - B - C - D [master]
         \
          R1 - B1 - R2 - B2 [fixes]
                           \
                            F1 - F2 [feature]

在那里有两个步骤，重新排列提交并声明新分支。 使用git rebase -i重新排列提交。 这将显示如下内容：

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick d100dd2 Feature 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
pick 0123abc Feature 2

然后，您实际上可以在编辑器中对它们进行重新排序。

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
pick d100dd2 Feature 1
pick 0123abc Feature 2

Git将通过以新顺序应用这些补丁来重建分支。 您可能必须解决冲突。 有关更多信息，请参见在Pro Git中重写历史记录 。

然后，您需要声明一个新分支。 仅仅是git branch fixes beadbee从声明的最后一次提交开始声明fixes分支。

正常情况下，将修补程序合并到主服务器中，然后在主服务器上重新建立功能。

---

但是，提交通常不是那么整齐地分开。 如果您的提交包含多个更改，并且只需要其中的一些更改，则可以将其转换为多个提交。

像以前一样使用git rebase -i ，但是将要拆分的提交设置为edit而不是pick 。

pick f37beee Refactor 1
pick 7f238ea Bugfix 1
pick aa1124b Refactor 2
pick beadbee Bugfix 2
edit beacd4a Messy commit
pick d100dd2 Feature 1
pick 0123abc Feature 2

然后，Git将停止该提交，并允许您按自己的喜好对其进行编辑。 使用git add -p仅将部分更改添加到登台区域（在其中构建提交），而git commit仅git commit部分更改。 这样做直到每个更改都有自己的提交。 例如，也许它更改了方法的名称，修复了错误，还更改了不相关的方法。 您将其分为三部分：一处更改名称，一处修复错误以及一处更改不相关的方法。

您可以在Interactive Staging中了解有关此内容的更多信息。

---

我不是过滤器分支或重新设置基准方面的专家，并且看起来我很可能会因滥用它们而严重破坏历史记录。

是的，但是您可以扭转这些错误，除非您git push ，否则不会影响任何其他人。 Git不会重写历史记录，而是会编写新的历史记录并假装一直都是这样。 过去的历史仍然存在了一段时间，您可以使用ORIG_HEAD和git reflog类的东西来追溯到过去。

最坏的情况是， 删除本地存储库并克隆一个新的存储库 。

Answer 2

由于这是最普遍的情况，因此我将Schwern的答案标记为正确的答案 -但值得注意的是，对于我的情况，有一个非常简单的策略如下。 由于我打算压缩所有更改，因此这意味着该过程可以在一次提交中完成。 仍然有必要创建一个新分支，但是可以使用软复位快速完成。 如果您要推迟的更改数量很少且易于管理，那么我建议您采用这种策略

1. 检出A
2. 分支到临时分支
3. 将Git软重置为A的“根”
4. 提交更改（不包括不需要的更改）
5. 合并develop