Question

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?

Answer 1

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.