How to mark a file as “uncommitable” with Git?

Question

I want to show off some of my work by uploading them to my GitHub account. However, there are some files that contain passwords, like database connections.

Is there a way of marking a file as uncommitable with Git so that it cannot appear on GitHub?

Answer 1

Is there a way of marking a file as uncommitable with Git so that it cannot appear on GitHub?

First, there is no way to have some files and commits visible in your local Git repository but somehow not viewable in GitHub if it is pushed to GitHub; if you have a file committed in Git it will show up in GitHub if you push it to GitHub.

Second, there is no simple and practical way to ever mark an individual file itself as being “uncommitable.” But there is definitely a way to ignore a file in a Git repo: By adding the file(s)—including their relative path if needed—to a .gitignore file:

A .gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details.

Creating a basic .gitignore is fairly easy since it’s just a plain text file. So—for example—if I had a config.php file in your root you would do this; assuming you are using PHP but the concept applies for any setup. Also I am using Nano as my text editor in this example but feel free to use whatever text editor you normally use for this:

nano .gitignore

And just add that filename to that file:

config.php

Save it and now Git will simply ignore that file.

That said, what I like to do for setups like this is to keep a sample/example config neutered of sensitive specifics in the repository so I have some reference as to what the config file format is a file named something like this:

config.SAMPLE.php

That way you know exactly how the config.php file should be setup via config.SAMPLE.php and you can ensure that the actual config.php is never touched by Git.

Also, if you plan on showing off your code, you need to expect that someone will try to take that code and implement it on their own system in some way. Remember, we are not you and without a sample config file in your repo, folks won’t really understand how to implement the code on their own. Heck they might might even think you’re not competent because you didn’t provide a basic configuration example.

Answer 2

You can also add a pre-commit hook to implement sanity checks. The directory .git/hooks of every git repository has some sample scripts.

The script called pre-commit is executed if it exists before each commit, and a non-zero return value aborts the commit.

For example, you could have a simple script like this:

#! /bin/sh -e
git ls-files --cached | grep -qx 'filename' && { echo "Excluded file included in the commit" >&2; exit 1; }
exit 0

And if that filename matches, the commit fails.

Answer 3

What @Giacomo1968 said in their answer. In some instances you could also make use of special file bits like skip-worktree or assume-unchanged that can be set the following way; for the differences between the two, see this Stack Overflow answer:

git update-index --assume-unchanged <file>

Which will then hide additional changes to an already existing file and which you could use if you really want a file to be there after every pull. But I would advise you to only use it if you really know what you are doing.

Answer 4

Use a .gitignore like @Giacomo1968 said in their answer. In addition, some related info:

• .gitignore keeps files from being tracked; if they are already tracked use git rm --cached to remove them
• files/patterns in $GIT_DIR/info/exclude will also be ignored
• files/patterns in the file specified by the core.excludesFile in the user’s ~/.gitconfig also are ignored.

See the official Git documentation for more details.

Answer 5

To extend on Jake and 46's answers: one very good practice is to have a consistent extension you use for files you include private information in, and use .gitignore to always exclude files with that extension globally (using the .gitconfig file as mentioned elsewhere to have it always ignored for your user).

That way, you can have for example:

/projectname/mypasswords.exc 

and if you've excluded *.exc globally, then you know it won't be committed, even if you forget to individually exclude that specific file.