2

我们在 Windows Powershell 上使用 posh-git 进行源代码控制。

我们将一些构建的程序集存储在我们的 git 存储库中，处于令人羡慕的位置。我知道所有关于你为什么不应该这样做的布道，但我们现在必须忍受它。值得庆幸的是，他们在一个单独的解决方案中，但有时两个人同时在他们自己的分支中处理该解决方案，最后一个人得到合并冲突。当然，这个过程看起来像这样：

  1. 人 A 将他们的更改放在开发上。
  2. 人 B 合并了这些更改，其中包括程序集和更新源代码。
  3. 人 B 解决冲突，因为必须确认他们想要保留每个程序集的哪个版本。这既烦人又费时，而且也是不必要的，因为无论如何，人 B 都会在合并源代码后重建程序集。
  4. 人 B 重建程序集并进行新的提交以完成合并。

这些程序集位于我们的仓库中的一个文件夹中：/Source/Foundation Assemblies/

人 B 不能只从远程获取所有更改，因为他们的分支可能有冲突的更改，但只为 /Source/Foundation Assemblies/ 文件夹“获取他们的”或“获取我的”会很有帮助。这是可以用git完成的吗？

命令行示例会很有帮助。通常，合并只是：

git merge develop

我在想有可能 .gitignore /Source/Foundation Assemblies/ 文件夹，然后在合并后将其从 .gitignore 中删除，但这是三个步骤。如果我们可以从命令行一次性完成，那就太好了！！！

任何帮助表示赞赏！

4

3 回答 3

2

您可以这样做git merge develop -X theirs，所有冲突都将获取远程分支的副本。

编辑：回顾您的问题，我发现您只想将“他们的”用于特定的子文件夹。在这种情况下，在 之后git merge develop，做git checkout --theirs /Source/Foundation Assemblies/。这将用“他们的”替换该文件夹的内容。然后就git add /Source/Foundation Assemblies/可以了。

于 2016-02-16T19:26:57.903 回答
2

在您的情况下，“正确”的方法是在提交合并之前重建程序集。我不明白你为什么不这样做。以下步骤应该有效：

  1. 解决和git add所有冲突的来源。那么合并期间发生的任何事情都不应影响您提交的内容。
  2. 删除冲突的程序集文件。无需对他们的 git 信息做任何事情，只需删除文件
  3. 构建程序集。
  4. git add准备好的组件。
  5. 然后提交。您得到的是合并，其中包括本地和远程更改。

编辑：试试这个：

  1. git rm --force -r <dirname>
  2. 运行你的合并工具，现在它应该提到二进制文件（kdiff3没有）
  3. 构建程序集
  4. git add <dirname>
  5. 犯罪

据我所知，我尝试了这个bash 脚本来重现你的情况。

于 2016-02-16T20:42:07.537 回答
0

您有几种可以使用的合并策略：

解决

这只能使用 3 路合并算法解决两个头（即当前分支和您从中拉出的另一个分支）。它试图仔细检测交叉合并歧义，并且通常被认为是安全和快速的。

递归的

这只能使用 3 路合并算法解决两个头。当有多个共同祖先可用于 3 路合并时，它会创建共同祖先的合并树并将其用作 3 路合并的参考树。据报道，通过对取自 Linux 2.6 内核开发历史的实际合并提交进行的测试，这会导致更少的合并冲突，而不会导致错误合并。此外，这可以检测和处理涉及重命名的合并。这是拉取或合并一个分支时的默认合并策略。

“递归”策略可以采用以下选项：

我们的

此选项强制通过支持“我们的”版本来干净地自动解决冲突的帅哥。与我们这边不冲突的另一棵树的更改会反映到合并结果中。对于二进制文件，整个内容都是从我们这边获取的。

这不应与“我们的”合并策略相混淆，后者甚至根本不查看其他树包含的内容。它丢弃了其他树所做的一切，声明“我们的”历史包含其中发生的一切。

他们的

这与“我们的”相反。

甚至更多，但这些是主要的。

于 2016-02-16T19:30:19.000 回答