【发布时间】：2017-12-04 00:55:48
【问题描述】：
我开始质疑我是否在 master 和 dev 之间遵循我的 Git 策略的最佳实践，因为部署并不像看起来那么简单。
我有一个 master 和 dev 分支，它们有一些环境差异。在大多数存在配置差异的地方（即连接字符串、应用程序设置等），我已经能够将这些差异抽象到位于 Git 之外的环境配置文件中。从 master 切换到 dev 时，团队中的开发人员复制并粘贴到正确的环境配置中，一切正常。
但是，在某些地方，master 和 dev 之间的代码本身有所不同。最具体的示例是在 Ninject (DI) 配置文件中，它在使用生产电子邮件服务和开发电子邮件服务之间有所不同，因此客户永远不会意外收到电子邮件。
我们考虑过使用 #if DEBUG 预处理器，但这并不能防止开发人员在“发布”模式下运行 dev 分支。
当将 dev 合并到 master 时，跨分支的代码差异变得难以管理，因为每次我们发现自己手动确保 master 代码永远不会被覆盖。为了帮助解决这个问题，我们最终创建了一个“合并”分支，该分支已经设置了生产提交并忽略了冲突的开发提交。
问题变成使所有这些分支保持同步并以正确的顺序合并/发出拉取请求，以确保合并正确的代码。
如果可能，有人可以提出更好的“策略”来管理这些分支，以便部署就像将 dev 合并到 master 一样简单？
【问题讨论】：
-
首先，这可能更适合programmersexchange，而不是stack。其次，您的代码在生产、测试和开发之间永远不应该有所不同（也就是说，当然，一旦它已经发布并且相同的版本在所有三个中运行 - 通常 prod 将是最旧的，test 是新的，而 dev 是最新的）。你有不同的产品服务的想法是可怕的。你如何测试它？你如何确保它是否仍然有效？对于大多数电子邮件服务（SMTP、AWS SES、sendgrid 等），您可以轻松地为不同的环境使用不同的信用集。
-
您还应该在发送电子邮件的任何内容中编写一些代码，以避免将其发送给真实客户（如果您遇到真实客户数据存在于开发/测试中的情况）-> 为此，添加将
Environment之类的内容添加到您的设置文件（无论可能是什么），并让您的 CI 在部署时对其进行更新。 -
config/settings文件也可以在
.gitignore管理。 -
@zaitsman 我强烈反对您的第一条评论。使用开发特定的依赖注入服务不会损害测试能力。如果我们在生产中使用 sendgrid 但想将 mailtrap.io 用于开发目的，我看不出这有多“可怕”。至于你的第二条评论，我比较喜欢。您的建议是将环境保留在配置文件中并阅读它而不是使用调试标志。将其发布为答案？我会合并方法并根据环境变量切换 SMTP 服务，但两者之间的来源是相同的。
-
@MarinaLiu-MSFT - 是的，我们对所有 *.config 文件使用 .gitignore。
标签： c# git azure-devops