How I can store some local changes that survives g

问题:

I have some local changes (not in separate files so .gitignore doesn't work) that I don't want to commit.
I do git reset --hard sometimes after commit to clear occasional changes but obiously I also lose my useful changes that I want to leave.

How I can keep my useful changes?

回答1:

You can also try:

git update-index --skip-worktree -- file
# to cancel it:
git update-index --no-skip-worktree -- file

It should resist a git reset --hard. (see this answer on the '--' double hyphen use)
See this blog post.

• It looks like skip-worktree is trying very hard to preserve your local data. But it doesn’t prevent you to get upstream changes if it is safe. Plus git doesn’t reset the flag on pull. But ignoring the ‘reset --hard' command could become a nasty surprise for a developer.
• assume-unchanged flag could be lost on the pull operation and the local changes inside such files doesn’t seem to be important to git.
  Assume-unchanged assumes that a developer shouldn’t change a file. If a file was changed – than that change is not important. This flag is meant for improving performance for not-changing folders like SDKs. But if the promise is broken and a file is actually changed, git reverts the flag to reflect the reality. Probably it’s ok to have some inconsistent flags in generally not-meant-to-be-changed folders.

On the other hand, skip-worktree is useful when you instruct git not to touch a specific file ever. That is useful for an already tracked config file. Upstream main repository hosts some production-ready config but you would like to change some settings in the config to be able to do some local testing. And you don’t want to accidentally check the changes in such file to affect the production config. In that case skip-worktree makes perfect scene.

回答2:

You can use git stash to store your changes temporarily, then pull them back later - see the Pro Git chapter on stashing.

回答3:

If you never want these changes to be committed but always need them locally then consider creating and commiting a script or patch file for your local changes. Then you can keep and document your changes as well as easily apply them after a hard reset.

If you have changes that are specific to your environment then it may be worth externalising them into a configuration file.