git忽略的文件取消忽略_GIT：永远不会太晚忽略文件

git忽略的文件取消忽略

I commonly see Git projects bloated with files and folders that should have been ignored and are now using valuable space in the repository. These files are usually auto-generated data from the IDE or the software used, such as the infamous .vs folder from Visual Studio or Unity’s Temp folder.

我通常会看到Git项目中充满了文件和文件夹，这些文件和文件夹本应被忽略，现在正在使用存储库中的宝贵空间。 这些文件通常是从IDE或使用的软件自动生成的数据，例如Visual Studio中臭名昭著的.vs文件夹或Unity的Temp文件夹。

Auto-generated files are usually dependent on the environment (installed API and OS, for instance). Thus, it is preferable to let each user generate them themselves, instead of keeping them in the repository. For the same reason, those files are more likely to conflict in a merge operation, since they will differ for every user. While those merge conflicts can be easily solved, it is still a time-consuming task and detrimental to the stability of the repository.

自动生成的文件通常取决于环境(例如，已安装的API和OS)。 因此，最好让每个用户自己生成它们，而不是将它们保留在存储库中。 由于相同的原因，这些文件在合并操作中更可能发生冲突，因为每个用户的文件都不同。 尽管可以轻松解决这些合并冲突，但这仍然是一项耗时的任务，并且不利于存储库的稳定性。

While in an ideal world, .gitignore files solve that issue on their own, we are still bound to make mistakes and let some data slip. Fortunately, there are plenty of ways to remove unwanted files from the repository after they have been added and tracked by the repository.

在理想情况下，.gitignore文件可以自行解决该问题，但我们仍然会犯错误并让一些数据遗漏。 幸运的是，在存储库添加并跟踪不需要的文件后，有很多方法可以从存储库中删除它们。

This article describes a simple action to clear the repository and a more sophisticated alternative. Additionally, it is used the term “file”, but the techniques work just the same as for folders. When there is any difference between file and directories, it will be noted.

本文介绍清除存储库的简单操作以及更复杂的替代方法。 另外，它使用术语“文件”，但是技术的工作原理与文件夹相同。 当文件和目录之间有任何差异时，将予以注意。

一个简单的步骤 (A Simple Step)

Add the file to your .gitignore file and then delete it from your repository. To remove a file from your Git repository, use the rm command:

将文件添加到您的.gitignore文件 ，然后将其从存储库中删除。 要从Git存储库中删除文件，请使用rm命令：

git rm <file>

The remove command deletes the file locally and stops tracking it. Thus, you can commit and push the change to your repository. It should now be purged.

remove命令将在本地删除文件并停止对其进行跟踪 。 因此，您可以提交更改并将其推送到存储库。 现在应该将其清除。

In some cases, you might want to keep the local files and only remove them from the repository. For this, we can use the --cachedflag. It will remove the file and save it, modified or not, as it is in your local repository.

在某些情况下，您可能希望保留本地文件，仅将其从存储库中删除。 为此，我们可以使用--cached标志。 它将删除文件并保存，无论是否修改，就像在本地存储库中一样 。

git rm --cached <file>

As stated previously, you can then commit and push this action to your remote repository and not bother again with the file.

如前所述，然后您可以提交此操作并将其推送到远程存储库，而不必再麻烦文件了。

For directories, you need to add the -r flag as follows:

对于目录，您需要添加-r标志，如下所示：

git rm --cached -r <folder>

A more automated alternative is to ask Git to untrack everything from the local repository, using the --cached flag to avoid deleting them by mistake and then re-add everything back. By doing so, Git will be forced to reevaluate all files according to your .gitignore file and, by the end, should stage the deletion of all ignored files that are currently being tracked. For this alternative, use the following commands in the root folder of your repository:

一种更自动化的选择是让Git取消跟踪本地存储库中的所有内容，使用--cached标志以避免误删除它们，然后重新添加所有内容。 这样，Git将被迫根据您的.gitignore文件重新评估所有文件，最后，应逐步删除当前正在跟踪的所有忽略文件。 为此，请在存储库的根文件夹中使用以下命令：

git rm --cached -r .
git add .

The dot (.) added, in the end, stands for the path of the current directory. Thus, these commands: remove everything from the repository, but do not delete the files from your computer (due to the --cached flag); recursively (-r); and, starting from the current directory (.).

最后添加的点( . )代表当前目录的路径。 因此，这些命令：从存储库中删除所有内容，但不要从计算机中删除文件(由于--cached标志)； 递归( -r ); 并且，从当前目录( . )开始。

After performing the second command (git add .) Git will track all the files again and mark the ignored files as deleted. Ideally, it will show a list of tracked changes containing only deletion operations, since the rest of the repository was not changed at all. You can then commit and push.

在执行第二个命令( git add . )之后，Git将再次跟踪所有文件，并将忽略的文件标记为已删除。 理想情况下，它将显示仅包含删除操作的跟踪更改列表，因为存储库的其余部分完全没有更改。 然后，您可以提交并推送。

清洁历史 (Cleaning History)

In some cases, removing the objects from the repository is not enough. Data with sensitive information (such as passwords stored in code, e.g.) should be deleted from the Git history as if they never existed.

在某些情况下，从存储库中删除对象是不够的。 具有敏感信息的数据(例如存储在代码中的密码)应从Git历史记录中删除，就好像它们不存在一样。

The same applies to large files that will continue to use repository memory, even if you remove them with the previous steps showed here. That is the case because they are still part of the history, and any user could reset to a commit in which those files exist. Thus, Git needs to keep them.

这同样适用于将继续使用存储库内存的大型文件，即使您按照此处显示的先前步骤将其删除。 之所以如此，是因为它们仍然是历史记录的一部分，并且任何用户都可以将其重置为包含这些文件的提交。 因此，Git需要保留它们。

The easiest, but the limited alternative, is to use the amend flag. When committing with the amend flag, Git will replace the tip of the current branch (the latest commit) with the new one. Think of it as if you were merging a new commit with the previous one, resulting in a single new commit.

最简单但受限的选择是使用amend标志。 当使用amend标志提交时， Git将用新分支替换当前分支的尖端(最新提交) 。 可以将其想像为要将新提交与上一个提交合并，从而产生一个新提交。

If the last commit (the tip of the current branch) was the one to add the unwanted file, you could amend it, deleting the file by using:

如果最后一次提交(当前分支的尖端)是添加不需要的文件的提交，则可以对其进行修改，使用以下方法删除该文件：

git commit --amend
git push -f

It is necessary to use the -f flag, that stands for "force," and ignores some of the Git checks, forcing it to operate as requested. In this case, it will force rewriting the history, removing the previous tip, and replacing it with the new commit. With that, the unwanted file will not be part of it.

必须使用-f标志，它代表“强制”， 并忽略某些Git检查 ，强制其按要求进行操作。 在这种情况下，它将强制重写历史记录，删除先前的提示，并用新的提交替换它。 这样，不需要的文件将不会成为其中的一部分。

Rewriting Git history is the way of completely removing files from it so that for all effects, it is as if the files were never there.

重写Git历史记录是从其中完全删除文件的方法，因此对于所有效果而言，仿佛文件从未存在过。

通过变基重写历史 (Rewriting History through Rebasing)

If your files were added in older commits and now you want them to be erased from history, you need to use the rebase command. Rebase is the process of reapplying commits in a different base. The base, as the tip of the branch mentioned in the previous section, is another commit.

如果您的文件是在较早的提交中添加的，而现在您希望从历史记录中删除它们，则需要使用rebase命令。 重新基准化是在不同基准中重新应用提交的过程 。 作为上一部分中提到的分支技巧的基础，是另一个提交。

It is possible to interactively apply the commits into the base by using the -i flag. This flag allows the user to edit the list of commits before doing so, allowing for changes, such as reordering commits or dropping them. To perform a rebase, use the following command. The <base> variable should be the hash of the second commit before the one that added the unwanted file.

可以使用-i标志将提交交互地应用到基础中。 该标志允许用户在这样做之前编辑提交列表 ，从而进行更改，例如重新排列提交或删除它们。 要执行变基，请使用以下命令。 <base>变量应该是第二次提交的哈希值，该第二次提交在添加不需要的文件之前。

git rebase -i <base>

As an example, given the following commit order:

例如，给定以下提交顺序：

123ac60 Commit with code
321ab56 Commit with unwanted files
213ad23 Commit with code
413ee26 Commit with code
...
324cc15 Initial commit

If you were to rebase using the commit213ad23 Git might not allow you to drop the commit 321ab56 since it is the first commit in the rebase operation. There are other alternatives, but the easiest one is to rebase using the previous commit, 413ee26. Thus you can safely remove the commit 321ab56.

如果您要使用提交213ad23进行213ad23 Git可能不允许您删除提交321ab56因为它是重新设置操作中的第一个提交。 还有其他选择，但最简单的选择是使用上一次提交413ee26 。 因此，您可以安全地删除提交321ab56 。

In our example, use the rebase command as below:

在我们的示例中，使用rebase命令，如下所示：

git rebase -i 413ee26

After this command, you will be allowed to select one operation per commit, including the drop operation that deletes a commit. Depending on your configuration, using the interactive rebase command will launch Vim in your terminal. If you have no idea how to use Vim, check this link. Otherwise, you can change the default program Git uses by doing this. Do it before the rebase.

执行此命令后，将允许您为每个提交选择一个操作，包括删除一个提交的放置操作。 根据您的配置，使用交互式rebase命令将在您的终端中启动Vim。 如果您不知道如何使用Vim，请检查此链接 。 否则，您可以通过执行以下操作更改Git使用的默认程序。 在变基之前执行此操作。

After that, the list of commits and operations will appear as below:

之后，提交和操作的列表将如下所示：

pick 123ac60 Commit with code
pick 321ab56 Commit with unwanted files
pick 213ad23 Commit with code

The pick operation uses the commit as it is. You should keep all other commits as pick and change the unwanted commit to drop instead. The drop command does not delete a commit but removes it from the list of commits to be applied in the new base. Since we will later change our history for the new, rebased history, the unwanted commit will not be there, as if it was deleted.

选择操作按原样使用提交。 您应该保留所有其他提交作为选择，并将不需要的提交更改为丢弃。 drop命令不会删除提交，而是将其从要在新基础中应用的提交列表中删除。 由于以后我们将更改历史记录以重新建立新的历史记录，因此不需要的提交将不会在那里，就好像已被删除一样。

Your commit list should look like this:

您的提交列表应如下所示：

pick 123ac60 Commit with code
drop 321ab56 Commit with unwanted files
pick 213ad23 Commit with code

After finishing this operation (in Vim, you have to save the file and close it), Git will interactively rebase the commits. With this, your branch is conflicting with the remote branch. That happens because your branch history differs from the remote branch, as we intended. To alter the remote branch and reflect the changes, you must perform a push -f command.

完成此操作后(在Vim中，您必须保存并关闭文件)，Git将以交互方式对提交进行基础更改。 这样，您的分支便与远程分支发生冲突。 发生这种情况是因为您的分支历史记录与我们期望的远程分支有所不同。 要更改远程分支并反映所做的更改，必须执行push -f命令。

Notice that with this action, you are rewriting the branch history, and this is a destructive operation, use it with care! For the sake of security, try checking your repository locally first to see if the action harmed it anyway. You should only push the changes after being sure that everything is working.

请注意，通过此操作，您将重写分支历史记录，这是一个破坏性操作，请谨慎使用！ 为了安全起见，请尝试首先在本地检查存储库，以查看操作是否对存储库造成了损害。 仅在确保一切正常后，才应推送更改。

Alternatively, you might need to keep some of the changes in that commit (321ab56) instead of dropping it entirely. For that, you can use the edit operation. During the rebasing, Git will stop when it starts to rebase the edited commit and will let you perform operations on it as if you were committing it. In our example, you could delete or untrack the unwanted file.

或者，您可能需要保留该提交中的某些更改( 321ab56 )，而不是完全删除它。 为此，您可以使用编辑操作。 在重新设置基准期间，Git在开始为已编辑的提交重新设置基础时将停止，并允许您像对其进行提交一样对其执行操作。 在我们的示例中，您可以删除或取消跟踪不需要的文件。

Your commit list using the edit command should look like this:

使用edit命令的提交列表应如下所示：

pick 123ac60 Commit with code
edit 321ab56 Commit with unwanted files
pick 213ad23 Commit with code

After editing the commit to remove the unwanted file, you need to ask Git to continue the rebase operation by using git rebase --continue . Everything else should proceed as explained before: finish the rebase and push -f .

编辑提交以删除不需要的文件后，您需要使用git rebase --continue要求Git继续进行重新设置操作。 其他所有操作均应按照之前的说明进行：完成变基并push -f 。

更糟的情况 (Even Worse Scenario)

It might be the case that your unwanted file was not only tracked and added; it was also changed and updated. Therefore, there are multiple versions of it spread through various commits in your story. Fortunately, our previous strategy still works, but there are going to be conflicts in every commit that alters the unwanted file. Grab some tea, relax, and solve them one by one.

可能是不仅跟踪并添加了不需要的文件； 它也被更改和更新。 因此，它有多个版本，遍及您故事中的各种提交。 幸运的是，我们以前的策略仍然有效，但是每次更改都会更改不需要的文件，因此会有冲突。 喝点茶，放松一下，一一解决。

In the end, it is never too late to ignore a file and remove it from your repository. But, keep in mind that the longer it takes to take action, the harder it might be to do it (and, potentially, the number of conflicts).

最后，忽略文件并将其从存储库中删除永远不会太晚。 但是，请记住，采取行动所花费的时间越长，执行该行动的难度就可能越大(可能还有冲突的数量)。

Keep your .gitignore files update to date and always check your commit meticulously before pushing them. If it fails, fall back to an --amend approach first to avoid repercussions in a later stage. In the worst case, recur to a big rebase and check everything before pushing the changes to your remote. Unit testing and a good CI are handy tools in that scenario and might save time.

使您的.gitignore文件保持最新状态，并在推送之前始终仔细检查您的提交。 如果失败， --amend使用--amend方法，以避免在以后产生影响。 在最坏的情况下，请重新进行大型调整并检查所有内容，然后再将更改推送到您的遥控器。 在这种情况下，单元测试和良好的CI是方便的工具，并且可以节省时间。

Thanks for reading :)

谢谢阅读 ：)

翻译自: https://medium.com/the-innovation/git-it-is-never-too-late-to-ignore-files-b8d7efc0c7b3

git忽略的文件取消忽略