如何与直接在生产环境中工作的其他团队打交道？
How to deal with other teams working directly in the production environment?
我在一家大公司的一个团队工作，负责为他们建立持续集成。问题是：如何与直接在生产环境中工作的其他团队打交道？
当前设置如下。
我团队中的开发人员在他们自己的环境中工作，使用他们自己的分支。他们将上游合并到测试环境。有时，测试分支会向上游合并到其自己环境中的用户验收分支。反过来，这偶尔会合并到生产环境的上游，这是我们的 master 分支。
问题来自我们没有任何权限的其他团队的存在：
其他团队不会使用我们的repository，他们会在用户验收环境中做比较频繁的改动，有时甚至会在生产环境中改动。
处理这个问题有什么好的策略？
我们是否应该从 production/UA 环境自动（每天）推送到它们各自的分支？如果是这样，我们如何处理可能出现的冲突？有没有更好的解决方案？
如果之前有人问过这个问题，我深表歉意，但我已尽力在这里和其他地方找到答案，但没有成功。我看过很多关于版本控制策略的资源，但它们似乎都做出了基本假设，即其他团队将使用相同的存储库，并且不会直接在生产环境中进行更改，而是使用版本控制将上游合并到 master 分支。
如果你真的不能让他们使用版本控制系统，我能想到的唯一解决方案是编写一个脚本（运行 在生产环境中），定期提交和推送他们的代码.至少，您将能够为您的团队拉取它以便在推送您自己的代码之前合并它。
那不干净。完全没有。但是你好像很绝望，我估计你也甩不掉他们吧。
更新
我通常不会推荐这个，但由于你的选择有限，如果可以的话，那么就在所有非开发环境上安装 git。然后每次当有人手动修补它时，你可以使用 git 状态来识别差异，并从那里决定你想做什么，即提交、推送、还原、格式补丁等。
原始答案
我很难相信现在还有人（整个团队？？）不使用版本控制，直接将更改提交到生产环境。其他团队如何知道他们的更改是否已经过测试和审查，并与其他人所做的保持兼容？就我个人而言，我不会容忍这种类型的反模式，独自改变我的团队的工作流程来适应它们。
以下是我要做的一些事情：
我在一家大公司的一个团队工作，负责为他们建立持续集成。问题是：如何与直接在生产环境中工作的其他团队打交道？
当前设置如下。
我团队中的开发人员在他们自己的环境中工作，使用他们自己的分支。他们将上游合并到测试环境。有时，测试分支会向上游合并到其自己环境中的用户验收分支。反过来，这偶尔会合并到生产环境的上游，这是我们的 master 分支。
问题来自我们没有任何权限的其他团队的存在：
其他团队不会使用我们的repository，他们会在用户验收环境中做比较频繁的改动，有时甚至会在生产环境中改动。
处理这个问题有什么好的策略？
我们是否应该从 production/UA 环境自动（每天）推送到它们各自的分支？如果是这样，我们如何处理可能出现的冲突？有没有更好的解决方案？
如果之前有人问过这个问题，我深表歉意，但我已尽力在这里和其他地方找到答案，但没有成功。我看过很多关于版本控制策略的资源，但它们似乎都做出了基本假设，即其他团队将使用相同的存储库，并且不会直接在生产环境中进行更改，而是使用版本控制将上游合并到 master 分支。
如果你真的不能让他们使用版本控制系统，我能想到的唯一解决方案是编写一个脚本（运行 在生产环境中），定期提交和推送他们的代码.至少，您将能够为您的团队拉取它以便在推送您自己的代码之前合并它。
那不干净。完全没有。但是你好像很绝望，我估计你也甩不掉他们吧。
更新
我通常不会推荐这个，但由于你的选择有限，如果可以的话，那么就在所有非开发环境上安装 git。然后每次当有人手动修补它时，你可以使用 git 状态来识别差异，并从那里决定你想做什么，即提交、推送、还原、格式补丁等。
原始答案
我很难相信现在还有人（整个团队？？）不使用版本控制，直接将更改提交到生产环境。其他团队如何知道他们的更改是否已经过测试和审查，并与其他人所做的保持兼容？就我个人而言，我不会容忍这种类型的反模式，独自改变我的团队的工作流程来适应它们。
以下是我要做的一些事情：