部分 merge 的 Git 工作流程？

Question

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

我解决这个问题的策略是在旁边创建一个分支并抑制损坏的功能，然后 merge 到这个分支中。问题是 git 命令有点复杂，所以我需要专家的帮助。

如果可能的话，我希望将这种类型的操作概括为一个 git 扩展，我会调用一些具有 git-cherrymerge 效果的东西。

步骤如下:

1. 重播用户指定的提交(也许这可以通过某种策略自动执行)到临时分支
2. Git filter-branch 删除损坏的文件
3. 压缩临时分支，添加自动提交消息
4. 将临时分支 merge 到目标分支(这里是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 将通过以新顺序应用这些补丁来重建分支。您可能必须解决冲突。有关详细信息，请参阅 Rewriting History in Pro Git .

然后你需要声明一个新的分支。这只是 git branch fixes beadbee 来声明从你想要的最后一次提交开始的 fixes 分支。

正常将修复 merge 到 master 中，并在 master 之上 rebase 功能。

---

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

像以前一样使用 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 仅添加部分更改。这样做直到每个更改都有自己的提交。例如，它可能更改了一个方法的名称，修复了一个错误，但也更改了一个不相关的方法。您可以将它们分成三个提交:一个更改名称，一个修复错误，另一个更改不相关的方法。

您可以在 Interactive Staging 中阅读更多相关信息.

---

I'm not quite an expert in filter-branch or rebase and it looks like I can quite seriously damage the history be misusing them.

是的，但你可以扭转这些错误，除非你 git push 否则不会影响任何其他人。 Git 不会重写历史，它会编写新的历史并假装它一直都是这样。旧历史仍然存在一段时间，您可以使用 ORIG_HEAD 和 git reflog 之类的东西返回它。

最坏情况，delete your local repository and clone a new one .