I have local working branch branchA , branchB , branchC.

My current working branch is branchB. If I run git clean -f will it just clean the untracked files in my branchB or all untracked files in my other branches too?

CodePudding user response：

To clarify your exact question, removing untracked files doesn't "affect" any branch (or commit). Instead, git clean -f will delete all of the untracked files from the point of view of the currently checked out commit.

Suppose you have two branches:

• branch1 is tracking just one file: file1.
• branch3 is tracking three files: file1, file2, and file3.
• For simplicity let's assume you don't have any files ignored.

Your working directory currently has 5 files: file1, file2, file3, file4, and file5, and you have branch1 currently checked out.

If you run git clean -f in this case, all files would be deleted except for file1. If you had those same 5 files in your working directory but instead branch3 was checked out, then only file4 and file5 would be deleted.

Note in the case where you have branch1 checked out, the fact that you are deleting file2 and file3 doesn't matter. As soon as you checkout branch3 again those 2 files will come right back.

CodePudding user response：

Your question is a little bit like asking whether airplanes tear holes in the cotton candy (or "candy floss" to the British) clouds so that bits fall down to the ground, or whether they eat the cotton candy clouds when they fly through them. That is, there's a fundamental error, so that the question can't be answered. Just as clouds in the sky aren't cotton candy in the first place, untracked files aren't in a branch.

Here's what you need to know:

• A Git repository does not store files, at least not directly. It stores commits. (Each commit then stores files, but in a peculiar Gitty fashion.)

• Branches, in the sense you're thinking of them, don't really exist. Multiple different things do exist, and they are all called branches (by different people at different times), and it's probably not possible to use and talk about Git without saying the word branch. But when someone says "branch" without enough context, you should wonder what they're talking about—and perhaps, even, whether they know what they're talking about.

• Hence we should strive to say branch name rather than branch for cases like this one: "I have three branch names". Or, we should strive to say tip commit rather than branch for cases like: "branch name branchA locates tip commit a123456".

• When we do get to specific commits—whose "true names" are those big, ugly, random-looking hash IDs like d420dda0576340909c3faff364cfbd1485f70376—each of those commits stores (indirectly) a full snapshot of every file, but the files in the commit are frozen for all time, so that we can get them back any time in the future by calling up that particular commit using that particular hash ID.

Once a commit is made, no part of it—neither the snapshot nor the metadata—can ever be changed by anything, not even by Git itself. The files in the commit just aren't writable. They're also not even readable by most programs; Git has special code to read them once they become packed. (A "loose" object is just zlib-compressed, so if you have a zlib function, you can at least read it without having to use Git—but you'll need Git anyway so you might as well let Git read it for you.)

What this means is that a commit works great as an archive, but is utterly useless when it comes to getting any new work done. The only way to get new work done is to extract some existing commit. The extraction process—i.e., git switch or git checkout—checks out all the files from the snapshot, turning each Git-ified, archived file into an ordinary read/write file that ordinary computer programs on your ordinary computer can use ordinarily. (How extraordinary is that?