How to ignore existing, committed files in git? [duplicate]

Question

Possible Duplicate:
GIT: Ignoring Version-Controlled Files

There are plenty of answers around .gitignore on Stackoverflow, still I haven't found an answer:

I have an existing git project, with a readme.md and a sample_folder/, both on top-level. I do want to remove these from my git(hub) repository in general. But I would like to ignore them, that is, preventing them to be pulled at all, in a certain cloned local repository, i.e. on a deployment machine.

.gitignore I understand, is only about ignoring non-committed files? Frankly, I don't find anything around hiding (from pull+commit) stuff that already is committed...

In the days of Perforce I would simple exclude it from the respective 'client spec' (which is pretty close to a locally cloned repo):

//whatever/myProject
-//whatever/myProject/readme.md
-//whatever/myProject/sample_folder

Sure, I could settle for a second branch where I simply delete readme and the entire sample folder. But then, I would have to keep merging over every tiny fix from 'develop'. Which is something, I would rather avoid... I'd rather prefer a local 'exception' over a (tracked) branch.

Also, I think git rm --cached whenever I do commits (which may also happen now and then from my 'deployment repo')...

Answer 1

Perhaps I got the question wrong, but wouldn't the following solve your problem?

git rm --cached readme.md sample_folder/*
echo "readme.md" >>.gitignore
echo "sample_folder/*" >>.gitignore
git commit -am "Untracked some files"

Answer 2

It sounds like you might be using a git checkout as your deployment method. Sometimes this works, sometimes it needs a little more. If there's development artifacts in the repository, you need a little more.

The most obvious way to deal with this is to have a deployment script that does the pull and then deletes the superfluous directories and files. This unfortunately leaves you with a partial repository that might confuse people and it adds a special script that has to remember to be used and kept up to date.

Another way to handle it is to have a deployment branch. Make a branch, delete the offending files and directories, and then pull from that branch. Yes, you'd have to merge changes from your development branch into deployment. You see this as a chore, but it is a safeguard. If you are rapidly making chances in development and just as rapidly deploying them, you might have a problem with your deployment cycle.

You want a step between development and deployment in which you can consider and test your changes. If nothing else, this prevents developer A from pushing a bad change and admin B compounding the mistake by unknowingly pulling it into production. You also want to be able to push to development and share your work with other developers without ALSO risking it being pushed into production.

You might be the single person handling development AND deployment right now, but you may not be later. If nothing else, this protects yourself from accidentally pushing an unstable change to development and then compounding that mistake by pulling it into deployment before you have a chance to think.