I have a bunch of files that should not be under version control. However, if I don't bring them under version control then my build fails. As those files contain key/value content, I added those files in but replaced the actual values with a fake value. Therefore, I am able to get my build passed and also I have not those actual key/value under VC. I committed this change into the VC. I also put the list of those file under .gitignore file like this:
/app/src/main/assets/*.json
/app/src/main/assets/*.kt
Now the problem is that In order to test my change I need to replace those fake files/values with the actual ones. However, by doing so, I get those files in the list of changed files when I run git status.
I clearly added them under .gitignore so why I see them here again? This is what I see:
hesam(dev)$ git status
On branch dev
Your branch is up to date with 'origin/dev'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: app/src/main/assets/EmergencyContacts.json
modified: app/src/main/assets/LocationOfSites.json
modified: app/src/main/assets/LocationOfHospitals.json
modified: app/src/main/assets/LocationOfOffices.json
The root of the problem is that files that are currently tracked cannot be ignored.
Unfortunately, fixing that requires removing the files from the index / staging-area (so that they become untracked), which in turns means that Git will remove the files from the work-tree. You can suppress the immediate removal of such files using git rm --cached, but in the future, anyone who goes back to any existing commit that contains the files will have the files put into their index/staging-area and their work-tree, and then moving from that commit back to a current commit (that doesn't have the files) means Git will remove the files.
That is, any time you git checkout a commit that has the files, they go into both your index/staging-area (these are two names for one thing) and your work-tree (this is where you can see and work with your files). Any time you move from having checked out this kind of commit, that has the files, to any commit that doesn't have the files, Git will remove the files from the index and from your work-tree. So the presence of these files in any historical commit effectively "poisons" the repository.
The only complete solution to this problem is never to have committed the files in the first place. This requires that you go back in time and stop yourself from committing the files. An approximation to this solution is to rewrite the commit history so that no remaining commits have the files: eliminate all the commits that did have the files, perhaps inserting new-and-improved replacement commits that don't have the files. See some of the many answers to How to make Git "forget" about a file that was tracked but is now in .gitignore?
The drawback to this solution is that you cannot have sample prototype files in your commits. The solution to this drawback is to put sample prototype files in your commits but under some other file names:
I have a bunch of files that should not be under version control. However, if I don't bring them under version control then my build fails. As those files contain key/value content, I added those files in but replaced the actual values with a fake value.
Have your build process use the alternate (sample-file) files instead of the real files, for test builds.
Users of the software will use the real files, which will not be under version control. Users of the test builds will use the test files, which will be under version control.