Files are, in a very important technical sense, not in any branch, in Git. In other words, you're asking the wrong question. You should be asking: Which commit(s), if any, contain this file? You can then refine the question to which commits contain exactly this version of this file or which commits have modified this file, as compared to their parent commit and so on.
(I suspect that one of these answers right now is that no commit contains that file, or that version of that file, but you have not given us enough to go on here, for me to be sure.)
The way Git works is a bit sneaky:
Git repositories store commits, not files. Of course, each commit stores some files, so it's safe to say that Git stores files, right? Well, sort-of-right, but this will lead you down the garden path. Try to think of commits as a sort of unit. They're the unit-of-storage that you will work with, when you work with Git.
The word branch itself is tricky: see What exactly do we mean by "branch"?
The end result of all of this is that given a branch name like master
, we have to first find one specific commit. Then we can decide whether some version of some file is in that specific commit, or not.
In any case, the files that are inside commits are all completely, totally, 100% read-only. They're stored in a special format that only Git understands, and they're de-duplicated, because every commit stores a full copy of every file! The de-duplication makes this OK.
When you're actively working with a repository, you start by doing:
git checkout master
or git checkout
of some other branch name.1 This checkout operation copies the frozen-format Git-only files out of some commit, expanding them into ordinary everyday files.
These ordinary everyday files go into a work area where you can work on them. Git calls this work area your working tree or work-tree.2 The files you can see and work on/with are in this work-tree. The work-tree is not part of the repository proper! Changes you make here are only stored here.
Note that this work-tree is an ordinary set of files and folders, so all of your computer commands that work on such things, work on it. This means you can create files that aren't in Git at all because they exist only in your work-tree, not in any commit.
Git makes new commits, not from the files that are in your work-tree, but rather from files that are stored in Git's index. The index is a bit complicated and I won't go into any most of the details here, except to note that a git checkout
fills in both Git's index and your work-tree from the commit you've selected. This doesn't disturb any work-tree files that Git knows nothing about. Again, such files aren't in Git. They just exist in your work-tree.
If a file is in a Git repository, it's stored inside a commit, in the special frozen Git-only format. Doing git checkout
will extract that file, resulting in two more copies: one you can't see in Git's index, ready to go into the next commit,3 and one that you can see and work on / with, in your work-tree. When you have changed your work-tree copy, the updated file won't go into a new commit until you copy it back into the index, replacing the old index copy: that's what git add
is for.
Git uses the phrase untracked file to mean a file that is not currently in Git's index, but is in your work-tree. The git status
command will show such files as untracked.4
1In Git 2.23 or later, you can use git switch
here. It does exactly the same thing—it's just been split out of git checkout
as git checkout
did at least two separate commands' worth of different jobs. In Git 2.23, git switch
does one job and git restore
does the other one, instead of cramming both into git checkout
.
2In Git 2.5 or later, you can add extra work-trees with git worktree add
. It's best to have Git 2.15 or later for this because of a pretty nasty bug that wasn't fixed until then. (The bug only manifests if you leave an added work-tree around for at least two weeks, so if you have an old Git and want to use git worktree add
for a quick fix, that's fine, just don't let it sit around for too long.)
3Technically, what's in the index isn't a literal copy of the file, but rather a file name, a mode, and an internal Git object ID. But this only shows up if you dig into the index entries, using internal Git commands like git ls-files --stage
and git update-index
.
4To make git status
shut up about these files, you can list them in .gitignore
. Note that listing a tracked file—one that is in Git's index—in .gitignore
has no effect, though.