6

Say I have a project that is located on both a public open-source repo and a private development repo. Some files on the development repo would include stuff like database passwords and such that I don't want public. What would be the best way to share the safe files between the two remotes? I'm thinking some kind of .gitignore file that is only applied to the public repo, is that possible? If not, any other suggestions?

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
Stephen Belanger
  • 6,251
  • 11
  • 45
  • 49
  • This is usually handled with a filter driver, as in http://stackoverflow.com/questions/3318043/mark-a-file-in-the-git-repo-as-temporarily-ignored/3318202#3318202 – VonC Jun 14 '11 at 04:53

3 Answers3

3

Maybe put the more sensitive files in a different repo, submodule it in the original repo and give only your private developers the access to the private repo.

manojlds
  • 290,304
  • 63
  • 469
  • 417
0

If there are really files, that should not leak to the public, for securities sake, don't put them in the repository, or encrypt the files with a password!

Best is, when you put unshared files in a separate repository that can live within the private development version:

BASE_DIR/.git
BASE_DIR/private/.git

Here BASE_DIR contains all the public files. BASE_DIR/private contains the private files.

When you just publish the data and not the repository (with all its history), you can simply

git --work-tree=PATH_TO_THE_PUBLIC checkout HEAD -- .

when a new version arrives.

ikrabbe
  • 1,909
  • 12
  • 25
-1

Don't put passwords in source control, period. Just .gitignore them everywhere; distribute the private password file by other means.

(And no, there isn't a way to ignore files only in some repositories.)

Amber
  • 507,862
  • 82
  • 626
  • 550
  • That doesn't help. We need our deployment configurations in the repo so we can change them as needed and everyone will know, and also our production environment is git-based, so all files needed to deploy need to be available in the private repo. There is no reason private data like that shouldn't be in private source control. – Stephen Belanger Jun 14 '11 at 04:31
  • @Stephen: The problem is that due to how Git operates, if you change even a single file, you have a completely different set of commit hashes, and thus a completely different history. Git doesn't distinguish between your public repository and your private repository on a history level. – Amber Jun 14 '11 at 04:33
  • 1
    @Stephen: What you *could* do is keep a separate branch which has a commit that adds in your private files, and never publish that branch to the public repository. When the open-source portion is updated, you can merge it into the 'private' branch and the private files will be retained. – Amber Jun 14 '11 at 04:34
  • 1
    @Stephen Or you could use submodule for sensitive files if you really need to store them in some repository, and then on deploy just link/copy files to their desired locations. – MBO Jun 14 '11 at 07:03