1
私は、マスターとデベロッパーの間のGit戦略のベストプラクティスに従っているかどうかは疑問視されています。環境差によるギットコードの管理
私はいくつかの環境の違いを持つmasterとdevブランチを持っています。設定の違い（接続文字列、アプリの設定など）がほとんどの場所では、Gitの外部にある環境設定ファイルにこれらの異なるものを抽象化することができました。マスターから開発者に切り替えると、チームの開発者は正しい環境設定でコピー＆ペーストし、すべて正常に動作します。
ただし、masterとdevのコード自体が異なる場所があります。最も具体的な例はNinject（DI）設定ファイルの中にあります。これは、プロダクション電子メールサービスと開発者の間で、誤って電子メールが送信されることがないように異なります。
#if DEBUGプリプロセッサの使用を検討しましたが、これは「リリース」モードでdevブランチを実行している開発者を保護しません。
このようなブランチ間のコードの違いは、マスターコードが手動で上書きされないように手動で確認するたびにdevをマスターにマージすると管理が難しくなります。これを助けるために、私たちは生産コミットですでに設定されている "マージ"ブランチを作成し、競合する開発コミットを無視しました。
問題は、これらのすべてのブランチを同期させ、正しいコードがマージされるように正しい順序でプル要求をマージ/発行することになります。
可能であれば、これらのブランチを管理する上でより優れた「戦略」を提案して、デベロッパーをマスターに統合するのと同じくらい簡単に導入できますか？
まず、これはおそらくstackerではなくprogrammersexchangeに適しています。第二に、あなたのコードは、production、test、devの間で決して異なってはいけません（つまり、リリースされ、同じバージョンが3つすべてに実行されれば - 典型的にprodは古いものです。プロダクトとは異なるサービスを持っているという考えは恐ろしいものです。あなたはどうやってそれをテストするのですか？それがまだ機能している場合はどうすれば保証されますか？ ほとんどの電子メールサービス（SMTP、AWS SES、sendgridなど）では、さまざまな環境で異なるcredセットを簡単に使用できます。 – zaitsman
実際の顧客に送ることを避けるために電子メールを送信しているものにもコードを書くべきです（実際の顧客データがdev/testに存在する場合） - >これに 'Environment'のようなものを設定ファイル（何でも構いません）をインストールし、展開時にCIを更新してください。 – zaitsman
config/settingsファイルについては、 '.gitignore'でそれらを管理することもできます。 –