有人从git存储库中取消跟踪文件。 Git Kraken用户在提取最新提交时如何将文件保存在本地？

Question

I untracked a file from a git repo using git rm --cached myFile.txt

Using the command line, this is fine, myFile.txt is still there, now untracked. After pushing the commit, other users, who are using the Git Kraken GUI want to get the latest commit. However, Git Kraken shows myFile.txt as deleted, and when pulling, myFile.txt is deleted from their working directory. How can they keep myFile.txt in their working directory, when the most recent commit removes that file?

I can't figure out a way to keep the file locally using Git Kraken, but they can just open up git on the command line, but I am unsure which commands to use to keep the local file, and let it get untracked when they fetch or pull the latest commit.

Answer 1

From the standpoint of a user receiving changes, it appears that the next commit specifies "delete this file" as part of the next required change. There isn't really a way, in the commit, to distinguish "untrack this file" as a separate type of change.

I assume you also added the file to .gitignore , by the way - and if you didn't, it seems like you'd want to in this situation. With that thought, I guess it might be nice if git could tell, for a deleted file, "hey, this commit also adds that path to .gitignore , so I'll assume they just mean to untrack it"; but this would still be an assumption where git couldn't be sure, and in that context maybe it's for the best that the behavior is kept simple. For better or for worse, that's how it's done.

So basically each user pulling the commit in which you want to untrack the file is going to have to take some special steps to keep the file in (or get it back into) their work tree.

Now it seems likely that everyone has the same file, and it's the version that was in the commit just before you untracked it. (Otherwise uncommitted local changes should be causing problems for each user.) In that case, you could do something like tag the last commit that had the file; and then let everyone know that after a pull deletes the file, they should do something like

git checkout myTag -- myfile.txt
git rm --cached myfile.txt

On the other hand, maybe you're untracking the file because constant uncommitted local changes are causing problems for each developer. In that case, you'd have to warn everyone in advance - "hey, next time you pull git will try to delete this file. If you have uncommitted changes it should throw a conflict. You'll need to move your file out of the way, let it finish checking out, and then put your file back" - at which point again I assume you'll have an ignore rule in place for it