问题标签 [merge-strategy]

无论是否有更改，我都想忽略某个文件被覆盖。我有以下内容/etc/gitconfig：

在存储库本身中，在.git/info/attributes：

但是，当我运行时git pull，无论如何都会覆盖该somefile.txt文件。我是否配置错误，或者有什么我不理解的地方？

我需要知道如何手动编辑每个合并。我在这里找到了答案，但一切都只有在合并冲突时才出现。我实现了这些，如果有新文件被拉出或代码之间没有直接冲突，它将自动合并，这是我做不到的。

我想手动确定每个新文件、代码行以及与合并工具的冲突。

请帮助我一个多星期以来一直试图解决这个问题。

我的用例是：我有一个包含子模块的仓库的两个分支。我想设置这两个分支的自动集成。但是，每当两个分支上都有子模块更新时，我的自动集成脚本就会失败，并且子模块会发生冲突。有没有办法让 git 在合并期间忽略子模块指针的变化？或者为merge=ours给定的子模块提供类似的东西？

我在这里读过这个。

我在上面的页面中为这样的子模块文件夹尝试了合并策略（但它只适用于文件）

- 初始文件内容：

- 分支 A) 的文件内容：

- 分支 B) 的文件内容：

- 将A合并到B后我想在B分支实现的文件内容：

哪种合并策略使我能够自动实现此结果？

正常（递归）合并会导致此结果，并且无法自动解决：

我在我的项目中使用 GitLab，我有一个非常具体的工作流程。我有 2 个分支“ Dev ”和“ Release ”，如下所示。当我从 Dev 向 Release 提交合并请求时，配置文件也被 Dev 分支的配置文件覆盖。

但理想情况下，这两个分支的配置文件必须不同。我尝试使用merge=ours. 但它并没有达到我的目的，因为除非配置文件中存在冲突，否则它不会覆盖。我不想在 中添加这些文件.gitignore，因为对这些文件的任何更改都不会在Dev分支中提交。有人可以指导我如何实现这一目标吗？

我们在一些分支中进行了开发，其中有很多提交，因为我们不确定可能存在的错误。经过大量更改后，我们决定将整个项目迁移到 master 分支而不进行任何更改，因此我们选择了 master 分支，但找不到他们的 git 合并策略。将 git 与 CLI 一起使用也没有任何区别。有什么问题？

我有一个master生产分支和一个qa测试分支。

当我开发一个新功能时，我会从 master 创建一个新分支（例如 new_branch），将其用于开发并将其合并到 qa 以进行测试。

我使用以下 git 别名：

myc = "!f() { git commit -a -m ${1} && git checkout qa && git merge ${1} && git push origin qa && git checkout ${1}; }; f"

这种策略允许我将 QA 团队批准的仅主功能合并到其中。

在我的代码define.inc.php中，我设置了一个define('_STATIC_VER_', '20');此计数器自动附加到所有静态 css、js 文件，例如：

/themes/css/global.css?sv=20

因此，每当我更改 css 文件时，我都会增加 SV 计数器，从而强制浏览器重新加载所有静态文件。

define.inc.php问题是 - 当我在开发 n1、n2 中有 2 个分支并且都对我进行了更改时

CONFLICT (content): Merge conflict in config/defines.inc.php

我必须手动选择their'define.inc.php'的版本

如何改进我的别名命令以their在冲突时始终使用？

注意：git merge --strategy-option theirs不能解决问题

我正在尝试将一个分支合并到 master 中，但想确保来自另一个分支的所有更改都生效，无论如何，但不知道如何去做？主要问题是我们最终会在 50 个文件中发生合并冲突，我们不关心 master 的先前状态。

故事：主分支已在 2018 年发布，而 2019 年发布的工作已在另一个分支中完成。由于运行时环境依赖性变化的影响，2019 年的变化很复杂，需要丢弃大部分 2018 年的变化。我们现在想要从 2019 年开始进行所有更改，并使其成为 master 的新状态。

到目前为止我尝试过的（作为单独的尝试）：

最后一个似乎更好，但遇到了重命名和删除文件的问题，其中有很多，因为我们包含的框架已被重写。

想知道是否采用焦土类型的方法来掌握（清除所有文件并提交），然后进行合并将是另一种方法？

我确实尝试过查看 Stack Overflow，但没有找到似乎可以正确解决该问题的答案。

任何建议，将不胜感激？

我想在 bitbucket-cloud 中实现分支策略，其中对 master 的拉取请求只能从 release/* 分支和 hotfix/* 分支完成。不允许任何分支向 master 提出 Pull 请求。同样，对 Release/* 分支的拉取请求只能从 feature/* 分支完成。

我已经启用了相同的分支模型。在分支许可下，我无法控制流量。

我想做cherry-pick/merge/rebase/checkout的“最难版本”，这意味着我的分支上的应用程序状态开始看起来与cherry-picked提交中的完全一样（但保留了我的分支的历史记录）。事实上，我可以复制我的 repo，删除我的分支中的所有内容，然后将整个内容从复制的版本集中复制到所需的提交。但是，这并不方便，我相信有一些更简单的方法。

我已经尝试过git cherry-pick <hash> --strategy-option theirs，但这并不完美，因为它不会删除樱桃挑选的提交中不存在的文件，这在我的情况下会导致大混乱。

那么，我该怎么做呢？

编辑：我澄清说我还需要保留我的历史，首先不明显。