1

一位开发人员一直在开发一些f1从master.

f1由于 repo 的模块化较差（系统是模块化的，但存在于单体 repo 中）和其他原因，开发人员决定删除分支中的“一堆不相关的东西”（其他与他的功能无关的模块） 。功能单元测试成功，但分支现在包含系统所有其他模块的所有这些删除。

在忽略文件夹删除的情况下，最简单、最轻松的合并方式是f1什么？master假设 . 中修改的一些文件f1也在master.

合并后分支上的附加要求 工作f1可能需要继续一段时间。我不太确定到目前为止提出的答案会如何影响这一点。

4

2 回答 2

1

假设您的源历史记录的质量是一个优先事项，我建议重写历史记录F1以排除删除。任何“无痛修复”都会留下奇怪的删除和添加，这将使未来对项目演变的分析变得复杂。

（顺便说一句，删除“我不从事的项目的一部分”的做法在客观上是不正确的。有关客观上不正确的潜在解决方案，请参阅“稀疏结帐”。）

拥有分支副本的开发人员越F1多，任何人基于该F1分支所做的更改（如果有的话）越多，历史重写就会越乏味。但是，如果这是一个仅由一个开发人员开发的功能分支，并且没有将该功能的合并推送到原点，那么它可能相当简单。

如果F1它本身是线性的，那么 rebase 就可以了。例如

x -- x -- x -- x <--(master)
      \
       A -- B -- C <--(F1)

因为master..F1（可从; 、和在此示例中到达F1但无法从; 、 和masterABCmaster..F1

git rebase -i master f1

您将看到一个“TODO”列表，其中包含每个提交的条目F1。将第一个提交的命令从 更改pick为edit。退出编辑器，变基开始。

A在暂时接受“原样”后，rebase 会暂停并提示您。现在您需要放回已删除的文件。您可以使用类似的东西git show --name-status来识别已删除的文件，并git checkout HEAD^ -- path/to/deleted/file/or/directory恢复已删除的内容。

恢复所有文件后，git commit --amend. 然后继续变基。

还有其他程序也可以使用；这是最简单的情况之一。

在 rebase 之后，如果F1曾经被推送过，那么你可能需要强制推送它。 git push -f 此时，F1在其本地 repo 中有副本的任何人都需要恢复（请参阅git rebase文档中的“从上游 rebase 恢复”）。如果有人根据他们工作过，F1他们将不得不将其重新设置为新的F1.

您应该能够在F1没有删除问题的情况下完成对新的合并。

于 2017-11-15T17:08:27.407 回答
1

我希望我的 git-fu 达到标准。
假设这MERGE_SOURCE是您要从此处合并的分支F1，并且PRESERVED_PATHS是需要恢复的路径列表：

# Find out the commit from which F1 forked
MERGE_SPLIT_POINT=`git merge-base HEAD ${MERGE_SOURCE}`

# Rewrite the branch's history to unstage all changes
# (including removals) of the preserved paths
git filter-branch \
    --index-filter 'git reset ${MERGE_SPLIT_POINT} -- ${PRESERVED_PATHS}' \
    -- ${MERGE_SPLIT_POINT}..${MERGE_SOURCE}

# Regular merge with the resulting new branch
git merge ${MERGE_SOURCE}
于 2017-11-15T17:22:37.077 回答