My .gitignore file is ignored by git and it does not work 10

Some times, even if you haven’t added some files to the repository, git seems to monitor them even after you add them to the .gitignore file.

This is a caching issue that can occur and to fix it, you need to clear your cache.

NOTE : Before proceeding with this solution, commit all changes you do not want to lose!

.. then execute the following commands from the root folder of your repository:
The following, will untrack every file that is in your .gitignore:

git rm -r --cached .;
git add .;
git commit -m "Untracked files issue resolved to fix .gitignore";

git-rm removes files from the index, or from the working tree and the index. git rm will not remove a file from just your working directory. (There is no option to remove a file only from the working tree and yet keep it in the index; use /bin/rm if you want to do that.) The files being removed have to be identical to the tip of the branch, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the -f option. When --cached is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index.

-r allows recursive removal when a leading directory name is given.

--cached unstages and removes paths only from the index. Working tree files, whether modified or not, will be left alone.

From: git-rm

To stop tracking a single file file but not delete it from your filesystem use the following:

git rm --cached <file>;

Another issue: file removed from .gitignore filters does not appear to be tracked

When you remove something from .gitignore file and the file does not appear to be tracked, you can add it manually as follows:

git add -f <file>;
git commit -m "Re-Adding ignored file by force";

How to add untracked files to a git patch

Recently, we had to create a git patch for the deployment of a 3rd party repository in our code.
Some of the changes we had to apply using the patch mechanism was the creation of a few new files.
We did not want to have an external script to copy the new files to the appropriate locations, so we had to include those new files in the git patch somehow.
The git diff command (with the parameter -p or --patch) that generates the patch, it ignored the untracked files and so they did not appear in the patch.
To make the untracked files visible to the git diff command, we staged them (using git add) and then used the following command to create the patch:

git diff --patch --staged;

git diff [--options] --cached [<commit>] [--] [<path>...]
git diff [--options] --staged [<commit>] [--] [<path>...]
Adding the parameter --staged or --cached allows you to view the changes you staged for the next commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. If HEAD does not exist (e.g. unborned branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached.
From: man git-diff

In the end our commands to create the patch with the new files and apply it on a new clone of the 3rd party repository was as follows:

#In the folder of the modified repository, where the new files are staged
git diff -p --staged > ~/new.file.patch.diff;
#In the folder of the new clone of the repository, where the new files need to be created
git apply ~/new.file.patch.diff;