This is impossible in general. Files, in Git, are not stored in branches. Files are stored in commits. A branch name is a way Git lets you find one specific commit; that one commit then lets you and Git find earlier commit(s).
To see why it's impossible, consider the following repository that has just one branch named main. This branch name selects the third of the three commits that are in this repository:
A <-B <-C <--main
This drawing represents the idea that name main identifies (or "points to") commit C, with C standing in for the actual hash ID of that third commit. Meanwhile commit C points to—or more precisely, stores in its metadata the hash ID of—earlier commit B; commit B points to commit A. As commit A was the very first commit, it does not point any further back: those are all the commits in the repository.
Let's now create two new branch names, staging and feature/one:
A <-B <-C <--feature/one, main, staging
All three names select commit C. This means that the snapshot stored in commit C is what you will see regardless of which branch name you choose.
You can—easily—remove a file and commit. Suppose we use:
git switch feature/one
so that the current branch name is feature/one. We then remove somefile and commit. This makes a new commit D, and updates the name feature/one to point to new commit D:
A--B--C <-- main, staging
\
D <-- feature/one (HEAD)
(The name HEAD in parentheses indicates the current branch name, in these drawings.) If we switch back to main or staging:
git switch main
we get:
A--B--C <-- main (HEAD), staging
\
D <-- feature/one
Commit D still exists, and the name feature/one still points to it; the file we removed is still absent from the snapshot in D, and will be forever, since all commits are 100% read-only. The file we removed before making commit D is, however, still here in commit C. When we switched from commit D back to existing commit C, Git removed all the commit-D files and installed, instead, all the commit-C files.1
1This glosses over a bunch of special cases described in Checkout another branch when there are uncommitted changes on the current branch, but is good as a starting mental model: your working tree is where Git extracts the committed files, so that you can see and work on / with them. Switching commits requires removing and replacing some of these files. Note that a branch-change that doesn't switch commits, however, never requires touching any files. As long as two names both select the same commit, you can switch back and forth without consequence.
is there a simple way to remove each file names (*.ids.json) from my repository when merging to staging or master while keep the tracking of those file in branches that are feature/*?
No. It's easy enough to do manually, but to automate that, you must have your merge process do it:
This should work on pipelines ...
Git doesn't have anything called "pipelines". Other, non-Git software that does have pipelines, such as Jenkins or GitHub CI, may or may not let you do what you'd do manually. Note that each of these add-ons has something rather different, that they tend to call a "pipeline" or similar word; you've asked in a Git forum and it's impossible to guess which system you're talking about.
