Prevent a file from being tracked by other branches

Question

I have a file.config sitting in my master branch. I want to create a feature branch from my master but I don't want my file.config to appear in it.

Knowing that I still want to keep track of the changes that happens to that file.

Is there a way of doing so?

EDIT: For the context, the config.file is a sort of "button" that deploys the code nested in the current branch in the production environment. That's why I don't want it to to be in any other branch than the "master", that limits the risks of human error.

Answer 1

It is possible to tell your local git that a particular file should never be changed using update-index. This will stop the file from showing up in git status and the like, while keeping it in the repository for everyone else.

It's important to note though that this change will happen in your local git, not in your branch. So if you switch branches it will still be in effect, and you won't be able to push this change to a remote.

git update-index --skip-worktree file.config

And if you want changes to this file to show up in git status again, run:

git update-index --no-skip-worktree file.config

Answer 2

You really, seriously, cannot get what you want in Git. The reason is pretty fundamental: files are not tracked or untracked by virtue of being in some branch, or not in some branch. What makes a file tracked (vs untracked) is its presence in (or absence from) the index. At the same time, branch names merely identify one particular commit, with the one commit they identify being changeable at any time ... and each commit can be in many branches simultaneously.

These three facts—(1) tracked vs untracked being a property of the current index contents, hence not directly connected to any branch-name; (2) branch names move over time; (3) commits are in multiple branches—all interact in a fashion that's rather bad for your use case.

To understand these, you need to know how commits, the index, and the work-tree interact, what happens when you use git checkout with a branch name or a commit hash, and how branches get created and move around in general. These are all tied into one big Gordian Knot ... and the solution to your actual problem is similar: don't even try to untie the knot, just sidestep the whole mess by keeping instead a prototype of the configuration. Have whatever process you use that needs it, build or obtain it as needed: this could be as simple as: if I've just run git checkout master, copy the prototype into place; if I've just run a git checkout that takes me off master, remove the in-place copy, leaving only the prototype.

(If you want to automate this, look into the post-checkout hook.)