Git：从分支中删除不需要的未跟踪文件

Question

I updated my branch from master and have a few files that were deleted on master, but remain on my local and appear as untracked files. I want to remove these files - ie confirm I don't want them on my local anymore.

I've tried git rm <file> but this does nothing - no message and no changes when I run git status .

I've tried checking out the files from master ( git checkout -- <file> ) but of course I get a message saying the file doesn't exist on master.

I've tried running git clean -n but I get a lot of messages saying Would not remove <file> .

I also tried deleting the branch git branch -D <branch-name> and pulling in a fresh version, but still get the same merge conflicts.

Would anyone know what I can do?

Answer 1

TL;DR

This question does not seem to make sense. Untracked files are already not there, so there is nothing to remove. More precisely, an untracked file is a file that is in the work-tree, but not in the index. As such, Git just lets it sit there, and mostly ignores it, except for two things:

• Git keeps whining about it being untracked, in git status output for instance.
• Running git add with any option that means "add everything", such as git add . , will add it to the index, so that it is now tracked.

To stop both of these annoying cases, people list particular untracked file names or name-patterns in .gitignore files. Note that .gitignore does not cause a file to become untracked; it just shuts up Git about the file clutttering up the work-tree, and makes sure that "add all" skips that file.

Long

An untracked file is a file that is not in the index. The index is its own independent thing: it's not a branch and it's not a work-tree. Instead, it's the place where you build the next commit that you intend to make, by staging updated files. This is why it is sometimes called the staging area . It also has the effect of indexing and caching the work-tree, hence its name index , and a third name, the cache .

Note that the index is a sort of live thing: its contents change over time, especially as you check out particular commits, or go to create new ones. In any case, though, the index is not part of a branch, so "remove untracked files from a branch" makes no immediate sense. But we also need to pin down what you mean by "branch" here: see What exactly do we mean by "branch"?

Note that a branch name points to one specific commit. If you run git checkout name , you are checking out the specific commit to which the name name points. The act of checking out a commit fills in the index, so now the index contains some set of files, and now we can talk about whether some file is or is not in the index, and hence is or is not untracked. (The word untracked appears more often than tracked , but it seems clear enough that a tracked file is one that is in the index.)

If, after git checkout name , some path P is tracked, running git rm P followed by git commit will make a new commit, and change name so that it identifies this new commit. This new commit will be one that, when checked out, leaves P out of the index, removing it from the index if necessary. So now name identifies a commit that has path P untracked. If that's what you meant by "branch" above, then this is your answer.

On the other hand, if you meant the word "branch" to encompass all commits reachable from the name, or something along those lines, you have a much tougher problem. You cannot change any existing commit at all. You can make a series of new commits, that you consider somehow "better" than the originals: for instance, you can make a series of new commits, none of which have path P in them, and then stop using all the old commits and begin using only these new commits instead. This is what many call rewriting history: changing the set of commits identified by some branch name(s) so that those new-and-improved commits are different from all the original commits. The downside to this kind of history rewriting is that you must get all users of clones of these repositories to switch all their usage to the new commits; otherwise the old commits just keep coming back, like a bad case of some sort of terrible disease.

Answer 2

I've tried running git clean -n but I get a lot of messages saying Would not remove .

-n means dry-run , ie Don't actually remove anything, just show what would be done. , The message just tell you this fact.

If you want to delete untracked file, you should use command git clean -dxf

Quatation from manpage of git clean

-d

Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.

-f, --force

If the git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given -f or -n.

-x

Don't use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build.