When merging development code into the production code, what is the preferred method for handling items that should not be in the production code branch? For example, I have configuration scripts that are configured for the test servers in the development branch, and I have the same scripts also configured for the production severs in the production branch. This causes conflicts when merging from dev to prod.


Solve the issue at deployment time.

As in, your production branch has all the dev configs and such. When you have a tool building and deploying your code, that re-configures your application to run in production. This avoids merge conflicts (your production configs aren't in the same file, the build tool overwrites it), and gives you a ton of control over where you actually keep those production configs.

Since many places want to keep the production configs safer than you keep the rest of their code - to help avoiding accidental breaks in production, to keep secrets safe, whatever. Solving this issue at deploy time helps, since it allows you to keep production configs in a more secure repo (maybe only leads have write-access to help prevent accidental breakage), or lets you keep secrets (keys) in an actual secure keystore, where the only allowed access is via the build tool.

|improve this answer|||||
  • You can always commit a distribution file, which is just a (renamed) configuration file with sensible defaults (usually for developers). That also helps secure your build scripts; if the distfile contains parameters your build tool doesn't supply, it should cause the build to fail. – Duroth Apr 2 '19 at 14:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.