Lots of people advise you to use git update-index --assume-unchanged
. Indeed, this may be a good solution, but only in the short run.
What you probably want to do is this: git update-index --skip-worktree
.
(The third option, which you probably don't want is: git rm --cached
. It will keep your local file, but will be marked as removed from the remote repository.)
Difference between the first two options?
assume-unchanged
is to temporary allow you to hide modifications from a file. If you want to hide modifications done to a file, modify the file, then checkout another branch, you'll have to use no-assume-unchanged
then probably stash modifications done.
skip-worktree
will follow you whatever the branch you checkout, with your modifications!
Use case of assume-unchanged
It assumes this file should not be modified, and gives you a cleaner output when doing git status
. But when checking out to another branch, you need to reset the flag and commit or stash changes before so. If you pull with this option activated, you'll need to solve conflicts and git won't auto merge. It actually only hides modifications (git status
won't show you the flagged files).
I like to use it when I only want to stop tracking changes for a while + commit a bunch of files (git commit -a
) related to the same modification.
Use case of skip-worktree
You have a setup class containing parameters (eg. including passwords) that your friends have to change accordingly to their setup.
- 1: Create a first version of this class, fill in fields you can fill and leave others empty/null.
- 2: Commit and push it to the remote server.
- 3:
git update-index --skip-worktree MySetupClass.java
- 4: Update your configuration class with your own parameters.
- 5: Go back to work on another functionnality.
The modifications you do will follow you whatever the branch. Warning: if your friends also want to modify this class, they have to have the same setup, otherwise their modifications would be pushed to the remote repository. When pulling, the remote version of the file should overwrite yours.
PS: do one or the other, but not both as you'll have undesirable side-effects. If you want to try another flag, you should disable the latter first.
.csproj
file, which is very much an important part of any project. Changes to the.csproj.user
file or any.Publish.XML
files I can totally understand not tracking, but I'm intrigued as to why you wouldn't want to track the.csproj
… – Owen Blacker