0

We have a git repo that is set up in a git-flow(ish) type way -- we have 3 "mainline" branches, dev, release, and production. Our workflow is something is that a new piece of code goes into dev, which has a cycle of two weeks. Once those two weeks is up, dev becomes "release", at which point it is tested and things are fixed on it, but no new features are applied. 2 weeks after that, release gets deployed, and becomes the production branch, which doesn't really get touched (except in the case of emergency out of band fixes)

Because of that, we have 3 versions of the database locally to track the 3 different branches. We tend to have a lot of schema churn, so it is very common that changes that happen to it in the dev branch could break what is on release or production.

The problem is, how do you manage 3 different sets of config files in the same git repository? Currently, what we are doing is .gitignoring them, and keeping 3 local versions of the codebase on everyones machine. However, this isn't really ideal for several reasons, and it would be great if we could have a single version of the repo and just switch between the branches.

I guess I am looking for a way to check a file in to a branch, and have it stay there, but not get picked up between merges of the mainline branches. So that way there could be a version on dev, one on release, and a third on master, but each would be isolated from the others. Sort of like a .gitignore for merging.

Is that even possible? Has anyone run into this before? (can't believe we are the only ones) How did you solve it?

Matt Briggs
  • 41,224
  • 16
  • 95
  • 126

2 Answers2

1

If you are talking of environment configs, you can have a config for each environment like dev.config, test.config, production.config etc. Changes can be done to dev.config on the dev branch. Once it gets tested and the time for release comes, the test / production config in release can be updated and tested appropriately. It doesn't makes sense to have one config for all environments.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • so thats pretty much what we have. But we need to split our configs by stuff in qa, and stuff in active development, and switch between them fairly regularly. I am looking for a way to not have to rename 3-4 files, or have 2 repos sitting on different branches on my hd to do the switch – Matt Briggs Feb 06 '12 at 06:26
0

Manojlds is right: separate config files are best (no merge issue that way).

It is best to combine those "value config files" with a content filter driver in order to generate automatically on checkout (with a 'smudge' script the right and final (but non-versioned) config file.

See the question "Something like gitignore, but not gitignore" for more.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250