简体   繁体   English

有没有办法从 git 中取消跟踪文件?

[英]Is there a way to untrack files from git?

it seems like a similar question with Untrack files from git temporarily but I can't find a good-working answer for me.这似乎与来自 git 的 Untrack 文件类似的问题,但我找不到适合我的答案。

I'm running a python-django server and have trouble on git merge .我正在运行 python-django 服务器并且在git merge上遇到问题。

At the beginning of the project, a developer had committed all the *.pyc files on git, and these commits are used on the server as production code.在项目开始时,开发人员已经提交了 git 上的所有 *.pyc 文件,这些提交在服务器上用作生产代码。

Now I have removed all the *.pyc files from the repository and make the proper.gitignore file.现在我已经从存储库中删除了所有 *.pyc 文件并制作了正确的 .gitignore 文件。

But the problem occurs here.但是问题就出现在这里。

Everything goes well till commit, but if I tried to merge it with production code, it emits an error.在提交之前一切都很顺利,但是如果我尝试将它与生产代码合并,它会发出错误。

Your local changes to the following files would be overwritten by merge:您对以下文件的本地更改将被合并覆盖:

Of course, the troubled files are the *.pyc files.当然,有问题的文件是 *.pyc 文件。

I assume it's because the *.pyc files are already tracked in some commits, and when trying to merge, git judge that the local *.pyc files will be removed by the commits which have 'delete: *.pyc' internally.我认为这是因为 *.pyc 文件已经在某些提交中被跟踪,并且在尝试合并时,git 判断本地 *.pyc 文件将被内部具有“删除:*.pyc”的提交删除。


Describe it as an example:举例说明:

Let's say I'm on branch A and want to merge branch B to branch A. The top commit of branch B has no *.pyc file.假设我在分支 A 上并且想要将分支 B 合并到分支 A。分支 B 的顶部提交没有 *.pyc 文件。 And the top commit of branch A has *pyc files on the working tree, but they're already removed from index(stage) by git rm --cached .并且分支 A 的顶部提交在工作树上有 *pyc 文件,但它们已经被git rm --cached从索引(阶段)中删除。 When I try git merge B on branch A the error Your local changes to the following files would be overwritten by merge: occurs.当我在分支 A 上尝试git merge B时,出现错误Your local changes to the following files would be overwritten by merge:发生。

Is there any feature to resolve it in git? git 中是否有任何功能可以解决它?


PS: I'm new in StackOverflow and not fluent in English. PS:我是 StackOverflow 的新手,英语不流利。 If I made any mistake on this question or some phrases are hard to understand, please comment on me.如果我在这个问题上犯了任何错误或某些短语难以理解,请评论我。 Thank you.谢谢你。


Add git-status:添加 git 状态:

I can't upload the output with real file names, but it seems like below.我无法上传带有真实文件名的 output,但看起来如下所示。 Just the file names differ.只是文件名不同。

  Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   files.pyc

You can resort to using filter-branch, as in Naeem Khoshnevis's answer .可以使用过滤器分支,如 Naeem Khoshnevis 的回答 If you need to do a lot of work with the "bad" commits that contain the *.pyc files, this might even be the way to go.如果您需要对包含*.pyc文件的“坏”提交进行大量工作,这甚至可能是 go 的方法。 The downside of doing this kind of work is that the product of filter-branch is usually a new, incompatible repository, that requires everyone who has a clone of the original repository, to throw out their clones, and painstakingly copy any work they had done on the original clone, over to the new clone.做这种工作的缺点是filter-branch的产品通常是一个新的、不兼容的存储库,这要求每个拥有原始存储库克隆的人都扔掉他们的克隆,并煞费苦心地复制他们所做的任何工作在原始克隆上,转到新克隆上。 1 It may be better just to work around the problem: 1解决问题可能会更好:

  • *.pyc files are simply byte-compiled Python code, made from the "real" Python source. *.pyc文件是简单的字节编译 Python 代码,由“真正的” Python 源代码制成。
  • They can therefore be removed before and/or after merging .因此它们可以在合并之前和/或之后被移除
  • So all you have to do is get ready for the merge step, then make sure there are no *.pyc files in your current commit and current working tree.因此,您所要做的就是为合并步骤做好准备,然后确保当前提交和当前工作树中没有*.pyc文件 Then, do the merge.然后,进行合并。 If that introduces some *.pyc files, so be it: let that happen.如果这引入了一些*.pyc文件,那就这样吧:让它发生。 Then re-remove the files and commit this as a "repair the merge" step.然后重新删除文件并将其作为“修复合并”步骤提交。

You're now done with the problematic merge.您现在完成了有问题的合并。 The fact that the merge commit itself has incorrect *.pyc files in it is not really a problem except that the merge commit itself cannot be tested during bisection.合并提交本身包含不正确的*.pyc文件这一事实并不是真正问题,只是在二等分期间无法测试合并提交本身。 If you don't like that—it can be a problem later, because there's no obvious marker for this—you can consider making an evil merge using git merge -n (then removing the *.pyc files before committing the merge), or using git commit --amend after the merge to replace the normal merge with the evil merge.如果你不喜欢这样——以后可能会出现问题,因为没有明显的标记——你可以考虑使用git merge -n进行恶意合并(然后在提交合并之前删除*.pyc文件),或者合并后使用git commit --amend将正常合并替换为邪恶合并。

Note that no matter which of these various approaches you take, there is some pain.请注意,无论您采用哪种方法,都会有一些痛苦。 That's unavoidable: someone made a mistake earlier, and everyone is now paying for it.这是不可避免的:之前有人犯了错误,现在每个人都在为此付出代价。 What you get to choose now is which painful process to go with, based on how painful you believe it will be.你现在要选择的是 go痛苦过程,这取决于你认为会有多痛苦。


1 There are some ways to automate some of this, especially in modern Git and/or using the new filter-repo system, but it's painful no matter what. 1有一些方法可以自动化其中的一些,特别是在现代 Git 和/或使用新的过滤器回购系统中,但无论如何这都是痛苦的。

It seems you need to remove that file from your entire git history.看来您需要从整个 git 历史记录中删除该文件。 In Pro Git , you can read the "Removing a File from Every Commit" section.Pro Git中,您可以阅读“从每次提交中删除文件”部分。 You need to use git filter-branch command.您需要使用git filter-branch命令。 Example from the book for removing password.txt from all commits.书中用于从所有提交中删除 password.txt 的示例。

git filter-branch --tree-filter 'rm -f passwords.txt' HEAD

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM