带有部分合并的 git pull答案

【问题标题】：git pull with partial merge带有部分合并的 git pull
【发布时间】：2013-02-28 03:33:07
【问题描述】：

我的存储库中有 20 个文件 foo1.c,foo2.c,...foo20.c 我正在处理 foo2.c

现在，每当我执行 git pull 时，它都会拉入并合并对所有 foo*.c 的更改，包括 foo2.c 我想阻止自动合并在我的存储库中修改的文件。

例如，有人可能在文件中的某个位置添加了 x=20，这会覆盖我在文件顶部对 x=0 的修改。

将 Bob 的更改与我的更改自动合并可能会导致难以检测到错误，如果其中一个错误有可能随机重启火星探测器，我希望在合并之前手动检查每个更改。

因此，在这种背景下，我想知道是否有办法让我提取（提取+合并）我的仓库中未修改的文件，并且只提取影响我正在修改的文件的更改，以便我可以做手动 diff+merge

【问题讨论】：

在stackoverflow.com/questions/3122056/…找到答案

标签： git

【解决方案1】：

您可以在 .gitattributes 文件中指定您希望您的 foo2.c 版本是合并期间考虑的版本：

foo2.c merge=ours

（来自gitattributes page。你需要activate that driver though）

【讨论】：

5 年后，我想你还在，我很想听听你对我认为按照你的建议做的后果的看法。我来到这里是因为我们中的一个人使用 TortoiseGit 执行了从 master 到他的故事分支的合并；他点击了警告并取消了 Tortoise 合并对话框中的许多文件。因此，在许多情况下，git 注册为合并结果的是他的旧文件版本。当该故事最终合并回主控时，主控更改被有效地丢弃并有效地恢复。
参见randyfay.com/content/avoiding-git-disasters-gory-story，第 2 部分，了解详细说明。现在我认为设置“merge=ours”对命名文件具有相同的后果，即在分支和将 master 合并到故事之间发生的 master 上的更改将在合并故事回来时在 master 上恢复。那正确吗？（我想，这通常既不是有意的，也不是好的。）
@PeterA.Schneider 我总是在;) (meta.stackexchange.com/q/122976/6309)。是的，合并回主版本意味着保留主版本（我们的）。所以这个设置需要是临时的，只是在你真正需要的时候。
我的意思是 其他人 将这样一个故事分支合并回 master（显然是在它被推送之后）将恢复 foo2.c 在 master 之间所做的所有更改story 的分支和 master 合并到 story 与“merge=ours”。（至少，这就是我的假设，并希望得到您的意见。）这是@vonbrand 的反对意见。据说，默默地丢失主更改不是 OP 想要的。（帖子下面提到的答案——取消设置合并属性，导致冲突——似乎不那么危险。）
@PeterA.Schneider 是的，这就是风险。在某些时候，这与工具无关，而更多地与围绕它的协作和流程有关。如果我是唯一一个在 pr/fix/story 分支上工作的人，我总是更喜欢在合并之前做一个 rebase。

【解决方案2】：

不要使用全局变量。
使用代码审查而不是这样做..
或者在最坏的情况下，您可以执行 git diff 并查看 bob 发生了什么变化...

【讨论】：

我同意 #1 On #2 最初的问题是启用增量代码审查。对于我的团队来说，一个 git pull 可以拉动对 100 个文件的更改，并且某些文件已合并的通知可能会在“噪音”中丢失，所以我正在寻找一种方法，如果文件在本地和服务器。例如我当前的版本控制系统给出了一条错误消息“需要合并：文件已在本地和服务器上更改”，并将其留给用户进行 diff+merge 并提取剩余的更改。没看懂#3，能不能详细点。
在本地分支上工作，只有在准备好时才推送。有一个看门人，将 Alice、Bob 和 Charlie 的已发布分支整合到官方发布的分支中。冲洗并重复。

【解决方案3】：

在本地分支上工作，仅拉入官方分支，准备好后在相应的官方（已发布）分支上合并/重新设置您的更改，然后将结果推送到上游。没有“Bob 的更改合并到 Alice 完成一半的工作中，这一切都搞砸了，QA 的 Charlie 搞砸了”。

【讨论】：

我同意，你的答案比我的好（这只是为了避免合并，而不考虑更大的图景）。所以，+1。