Git 如何与直接在生产环境中工作的其他团队打交道？

我在一家大公司的一个团队工作，负责为他们建立持续集成。问题是：我如何处理直接在生产环境中工作的其他团队

当前设置如下所示

我的团队中的开发人员使用他们自己的分支在他们自己的环境中工作。它们合并到测试环境的上游。有时，测试分支会在其自己的环境中合并到上游的用户接受分支。反过来，它偶尔会被合并到生产环境的上游，生产环境是我们的主分支

问题来自于我们没有任何权限的其他团队的存在：

其他团队不会使用我们的存储库，他们会在用户接受环境中进行相对频繁的更改，有时甚至在生产环境中

处理这个问题的好策略是什么

我们是否应该每天自动将生产/UA环境推送到各自的分支机构？如果是，我们如何处理可能出现的冲突？有更好的解决方案吗

---

如果以前有人问过这个问题，我很抱歉，但我尽了最大努力在这里和其他地方找到了答案，但没有成功。我已经阅读了很多关于版本控制策略的参考资料，但它们似乎都假设其他团队将使用相同的存储库，不会直接在生产环境中进行更改，而是使用版本控制将上游合并到主分支。

如果您真的无法让他们使用版本控制系统，我能想到的唯一解决方案是编写一个在生产环境中运行的脚本，定期提交和推送代码。至少，您可以为您的团队拉取它，以便在推送您自己的代码之前合并它

那不干净。完全但你似乎非常绝望，我想你不能摆脱他们。

更新

我通常不推荐这样做，但由于您的选项有限，如果可以的话，只需在所有非开发环境中安装git即可。然后，每当有人手动修补它时，您可以使用git status来识别差异，并决定从那里执行什么操作，即提交、推送、还原、格式化修补程序等

原始答案

我发现很难相信整个团队还有人？？他们现在不使用版本控制，直接向生产环境提交更改。其他团队如何知道他们的更改是否已经过测试和审查，并与其他人的操作保持一致？一、 就个人而言，我不会容忍这种反模式，更不用说改变我的团队工作流程来适应他们了

以下是我将要做的一些事情：

与你的上司和他们的上司谈谈这些未经测试、未经验证、不可追踪和不可重复的变更将带来的风险和成本。 锁定对所有非开发环境的直接访问。任何人都不应该直接访问任何非开发环境。您没有使用SFTP进行部署，是吗- 使用诸如等工具自动化部署过程。 强制执行这些工具提供的自动恢复策略，应用于环境的任何非版本控制的手动更改都将被无情地恢复。 向其他团队传授使用版本控制的好处和技巧。或者，只需启动它们：-

---

是什么阻止你将其他团队所做的这些更改拉到你自己的回购协议中？问题是其他团队不会提交和推送他们的代码。他们直接在暂存/生产环境中进行更改。我100%同意您的意见，但我们无法阻止其他团队直接在生产环境中进行更改。@MLG25我通常不建议这样做，但如果可以的话，只需在所有非开发环境中安装git即可。然后，每当有人手动修补它时，你可以使用git status来识别差异，并决定你想从那里做什么，即提交、推送、还原、格式化修补等。这远不是理想的，但考虑到这种情况，这可能是我唯一的选择。顺便说一句，Isim是正确的：不应该允许这些人这样工作。你必须向有能力让他们改变习惯的人解释情况。