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.
