1

I have a docker multi-project, where some files are configuration and bash scripting files

  • .env (eg. facebook_app_id=abcd)
  • build.sh (eg. checkout project with depth 1)
  • install.sh

They specify how the different projects communicate together, which is different when in production or in development mode.

I solved this by creating different branches (dev, test, preprod, and prod) and having those files with the same names but different content in each branch.

So my need is to have those files present in git, but I don't want them to override content between branches. I can have a version in master, then modify it in each branch so that they become conflicting to get a warning at each merge, but that's not very user-friendly.

I've read this post, but it still doesn't answer my needs.

Any ideas?

Zied Hamdi
  • 2,400
  • 1
  • 25
  • 40
  • 4
    Although you *could* use different branches to maintain different config files, I'm not sure that you *should*. Typically having all the configs in the same branch is easier to maintain when you need to do branch merges down the road. Imagine something like `.env`, `.env-dev`, `.env-test`, `.env-prod`, etc. Then when you deploy, you use the proper config, or perhaps rename the proper config to .`env`, or transform it, etc. – TTT Feb 09 '22 at 21:55
  • 1
    A `git push` operation sends *commits*, not files. Commits do contain files, but each commit holds a full snapshot of *every* file. You'll get yourself in trouble doing what you're trying to do. – torek Feb 10 '22 at 00:09
  • Thanks @TTT you're probably right, it would have been elegant to have those files with the same names act differently in each branch, the most relevant one being docker-compose.yml since I only have to call 'docker-compose up' in a given branch to be satisfied :) I liked the idea of clean separation, where each branch has only the config files that concerns it. Maybe this could be a feature request to the git team – Zied Hamdi Feb 10 '22 at 07:41
  • I suspected it to have a price @torek :-), there's also the possibility to work only in master (which has no conflicts with the other branches) then merge master to each branch. The issue rises only when someone tries to fix a bug in a branch that is not extracted from master. This could lead to more rigorous work too ;-) (although any additional risk is an addition problem waiting to show up when we expect it the least) – Zied Hamdi Feb 10 '22 at 07:46
  • 1
    there is an skip-worktree option to make local files be skipped – TheDudeWithHat Feb 10 '22 at 12:34
  • 1
    Hey @TheDudeWithHat that seems to be exactly what I was searching for, I was wondering how it could be that my need didn't encounter anybody else, so an article about it made my day: https://compiledsuccessfully.dev/git-skip-worktree/ You can add an official answer, I'll mark it as my solution – Zied Hamdi Feb 10 '22 at 12:53

1 Answers1

0

Since you want the files to be part of your repo, you dont want to ignore them.

But changes to settings for environmental-dependent attributes shall not be commit and merge every time. You can put files into skip-worktree for this. Works locally and needs to be setup at every local git repo.

https://compiledsuccessfully.dev/git-skip-worktree/

It might take some time (amount of commits merged) till the configuration files are all merged into one, but after that you only need to pay attention to the configurations when you actually change them.

TheDudeWithHat
  • 155
  • 9