¿Ha intentado escapar de los espacios en la carpeta o los nombres de archivo con barras diagonales inversas?
*.mode1v3
Foo\ Bar.xcodeproj/
Foo\ Bar.xcodeproj/*.mode1v3
Foo\ Bar.xcodeproj/username.mode1v3
Además, ¿estos archivos ya están siendo rastreados por git? De man gitignore
:
A gitignore file specifies intentionally untracked files that git should ignore.
Note that all the gitignore files really concern only files that are not already
tracked by git; in order to ignore uncommitted changes in already tracked files,
please refer to the git update-index --assume-unchanged documentation.
Además, aquí están algunos de los patrones discutidos en man gitignore
:
o If the pattern ends with a slash, it is removed for the purpose of the
following description, but it would only find a match with a directory. In
other words, foo/ will match a directory foo and paths underneath it, but will
not match a regular file or a symbolic link foo (this is consistent with the
way how pathspec works in general in git).
o If the pattern does not contain a slash /, git treats it as a shell glob
pattern and checks for a match against the pathname relative to the location of
the .gitignore file (relative to the toplevel of the work tree if not from a
.gitignore file).
o Otherwise, git treats the pattern as a shell glob suitable for consumption by
fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match
a/in the pathname. For example, "Documentation/*.html" matches
"Documentation/git.html" but not "Documentation/ppc/ppc.html" or
"tools/perf/Documentation/perf.html".
o A leading slash matches the beginning of the pathname. For example, "/*.c"
matches "cat-file.c" but not "mozilla-sha1/sha1.c".
Tienes razón. Tuve un momento novato donde esperaba que los archivos comprometidos fueran ignorados simplemente por estar en .gitignore. Como ya están registrados, ese no es el caso. Esto lo aclaró para mí: http://www.gitready.com/beginner/2009/03/06/ignoring-doesnt-remove-a-file.html – pmc255