Reputation: 21830
In my dev team, we have multiple projects spanned across several git repos. Those projects actually share a few common config elements. We have recently made a local change to one of our shared config files that none of us wish to commit to the production environment.
/www/
|
|-- git repo 1 (containing shared config files)
|-- git repo 2 uses files from 1
|-- git repo 3 uses files from 1
|-- git repo n uses files from 1
While we were setting up a .gitignore
file for each repo, I came across ~/.gitignore_global
Since .gitignore_global
is in ~/
, its per user, right?
Should I have each developer implement their own .gitignore_global file, or can I apply the regular .gitignore to all of them so it can be committed globally?
Upvotes: 4
Views: 3563
Reputation: 1325137
That supposes you define, as mentioned in gitignore
man page, the property core.excludesfile
:
Which file to place a pattern in depends on how the pattern is meant to be used:
- Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a
.gitignore
file.- Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the
$GIT_DIR/info/exclude
file.- Patterns which a user wants git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by
core.excludesfile
in the user’s~/.gitconfig
.
So yes, it is per user.
That being said, for configuration files with variable content (depending on the environment), I would rather prefer version in the repository a .gitattributes
file with a content filter driver in it.
See forinstance "How to keep different content of one file in my local and github repository?"
zerocog mentions in the comments the tutorial yakiloo.com.
Upvotes: 5