2

I have a list of files that contain different configurations for live and development branches.
Currently, every time we need to test things we go and change all the configurations to dev settings, do our dev and then change them all back when it is time for the pull request. This is silly.

I'm looking for a git way to just exclude those files at merge time.

  • I don't want to add them to the .gitignore, because that causes problems later on when someone else pulls the branch for example.
  • Using environment variables won't work (or at least, to make it work would require lots of hacking and a heavy foot to stomp it into place)
  • Our company is strict in that all merges from dev to live must go through a Pull Request. I think this is a good system.
  • None of these look like a very good idea.
  • This answer provides this solution (also this). However I've added all the config files to the .gitattributes file in both branches but a merge still overwrites them all.

So is there a git way into which I can paste a list of files that are branch specific and do not get merged during PRs?

EDIT

It seems worthwile to explain the system a bit.

We have 2 branches that always exist. master for the live deployment environment and dev for the development environment. These 2 branches should have identical code except for the configuration files. These files look the same, but they contain different IPs, VM names, paths etc.

If we develop a new feature, we would checkout from dev, create that feature and test it in the dev environment, then once happy, create a PR and merge it into master. master has to keep its own configs at this point. Same for master and hotfixes, except that those changes would then get merged into dev.
dev never gets deleted, only the feature branches that work off dev do.
This is a big project with different config files that get sent all over the place for sub-modules. We can't just simplify and make one mega config file.

Community
  • 1
  • 1
Roman
  • 8,826
  • 10
  • 63
  • 103
  • Suppose, for the sake of simplicity, that each branch has a single config file. Now, if we merge a feature branch into master, logically what should happen with regard to that config file? Should we keep master/feature version? Does it even make sense after the merge to have a config file associated with master? – Tim Biegeleisen Dec 06 '16 at 06:32
  • @TimBiegeleisen The master branch should **not** take over the config file from the feature branch. Each config file has all the same variables, but contain different URLs, project ids, VM names, paths etc. So it makes perfect sense to keep them seperate – Roman Dec 06 '16 at 06:44
  • In my travels, once a feature branch returns to its source, that feature branch is effectively killed. Then can you explain the problem better with regard to the config files? – Tim Biegeleisen Dec 06 '16 at 06:45
  • @TimBiegeleisen I have 2 branches. `master` (for live) and `dev`. If all were well in the world, these would have identical code in them *except* that each branch has different configs stored in a set of files which are *specific* to that environment. Now feature/hotfix branches can be created from either of those two which would then inherit that specific set of configs. Like you say, after the feature/hotfix is done that branch dies, but `master` and `dev` never will. – Roman Dec 06 '16 at 06:50
  • So does your problem really boil down to how to handle whose version of the config file to retain during a merge? And obviously, using `ours` or `theirs` isn't attractive, because that applies to _all_ files. – Tim Biegeleisen Dec 06 '16 at 07:09
  • 1
    The usual answer is "don't do that", and in my experience, this is also the correct answer: don't put *actual* configuration files in your source code control system, ever. Put *sample* ones in, sure. Copy the sample to the real one automatically, even, on the first run. But never put the actual one in. (This does, unfortunately, require advance planning.) – torek Dec 06 '16 at 07:19
  • @TimBiegeleisen Hmm, I hadn't thought of it that way. I just figured there was a way to ignore a set of files during merge. But I guess so. – Roman Dec 06 '16 at 07:21
  • Keep the sample file in the repo and put the main file in `.gitignore`, so whenever someone takes pull of that branch he can make the `config` file according to him on his machine. – Deepesh Dec 06 '16 at 09:30
  • @Deep its not machine specific, its deployment environment specific. And I don't want to put it into a gitignore file because anyone should be able to pull dev of master without problems – Roman Dec 06 '16 at 09:52
  • Yes but this is very hectic to change the config each time for each server so instead we prefer it to keep in the gitignore and keep a sample file there so the production server would have its own copy and dev will have its own copy, no need to change it everytime. – Deepesh Dec 06 '16 at 10:18

0 Answers0