git - 如果您已经将文件推送到远程分支， merge 到开发分支并且它不是最新提交，如何从 git 中完全删除文件

Question

我看过很多教程解释了如何在不同的场景中执行此操作，但似乎其中许多都在谈论最新的提交。所以我需要的是从两个分支中完全删除这个敏感文件:feature-branch和 develop .
我怎么做？
我找到了这个食谱:

git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch path_to_file" HEAD

它会在我的情况下工作吗？也就是说，它会从所有分支中完全删除这个文件吗？
编辑:
我决定使用 BFG，这是我运行后它给我的输出 bfg --delete-files 'filename_of_the_file_to_delete'输出:

Found 273 objects to protect
Found 198 commit-pointing refs : HEAD, refs/heads/develop, refs/heads/develop-with-relative-paths, ...

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit 7d97ab00 (protected by 'HEAD') - contains 1 dirty file :
    - src/email/filename_of_the_file_to_delete (16.1 KB)

WARNING: The dirty content above may be removed from other commits, but as
the *protected* commits still use it, it will STILL exist in your repository.

Details of protected dirty content have been recorded here :

/Users/albert/Documents/projects/rjx/rjxfp/.git.bfg-report/2020-08-25/21-50-38/protected-dirt/

If you *really* want this content gone, make a manual commit that removes it, and then run the BFG on a fresh copy of your repo.


Cleaning
--------

Found 486 commits
Cleaning commits:       100% (486/486)
Cleaning commits completed in 699 ms.

Updating 7 Refs
---------------

    Ref                                                    Before     After
    --------------------------------------------------------------------------
    refs/heads/develop                                   | e9c3c4ba | 53c5dd39
    refs/heads/feature-icons-for-top-level-cats          | d7dde80c | 377ae820
    refs/heads/feature-user-profile                      | 7d97ab00 | e3b1b336
    refs/remotes/origin/develop                          | e9c3c4ba | 53c5dd39
    refs/remotes/origin/feature-icons-for-top-level-cats | d7dde80c | 377ae820
    refs/remotes/origin/feature-user-profile             | 7d97ab00 | e3b1b336
    refs/stash                                           | 9fc9a356 | 39945789

Updating references:    100% (7/7)
...Ref update completed in 54 ms.

Commit Tree-Dirt History
------------------------

    Earliest                                              Latest
    |                                                          |
    ..........................................................DD

    D = dirty commits (file tree fixed)
    m = modified commits (commit message or parents changed)
    . = clean commits (no changes to file tree)

                            Before     After
    -------------------------------------------
    First modified commit | 6a211a6b | 35597e71
    Last dirty commit     | e9c3c4ba | 53c5dd39

Deleted files
-------------

    Filename                          Git id
    ------------------------------------------------------
    filename_of_the_file_to_delete    | 4121d724 (16.1 KB)


In total, 37 object ids were changed. Full details are logged here:

    /Users/albert/Documents/projects/rjx/rjxfp/.git.bfg-report/2020-08-25/21-50-38

BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive

我想删除的文件仍在创建它的目录中，至少在我运行 bfg 的分支上。命令。然后我不认为我完全理解它对一些 protected 脏内容所说的内容。谁保护了它，为什么？
它说: If you *really* want this content gone, make a manual commit that removes it, and then run the BFG on a fresh copy of your repo.我不明白我应该做什么。
据我了解，它提到的提交 7d97ab00 (现在是 e3b1b336 )是我运行命令的分支上的最后一次提交，所以我必须删除该文件(但我必须用 rm 或 git-rm 删除它吗？)然后做一个再次提交并运行BFG？

Answer 1

虽然我没有使用过 The BFG，但我从它的文档中了解到，它认为每个分支的最尖端提交是“正确状态”。也就是说，假设您要删除文件 secret.txt从每次提交。如果您将 BFG 与指令“删除文件 secret.txt”一起使用，它将从除当前提交(以及包含该文件的任何其他分支提示提交)之外的所有提交中删除它。
请记住，分支名称只是通过其提交哈希 ID 来标识某个提交。提交本身包含文件。每个提交都有每个文件的完整快照。所以如果你添加了 secret.txt四次提交前，并有这个:

... <-H <-I <-J <-K <-L   <--master

每个大写字母代表一次提交，文件 secret.txt正在提交 L , K , J , 和 I .它不在 H因为 H是五次提交前。
这里的向后箭头是 Git 的工作原理:每次提交都会向后引导到上一次提交。任何提交的任何部分都不能更改(也不能被 BFG 更改)，因此 BFG 必须做的是创建新的和改进的提交，然后完全丢弃旧的提交。
BFG 将复制现有提交 I到一个新的和改进的 I'其中 secret.txt不存在。然后它会复制 J到一个新的和改进的 J'其中 secret.txt不存在，并为 K 重复此操作.但是 L是最后一次提交，由名称标识，因此 BFG 假定您的意思是保留 secret.txt那里，因为它现在就在那里，并以名称标识。这是“ protected ”提交。所以BFG副本 L至 L' ——它必须这样做，因为它复制了 K至 K'和现有的 L指向现有 K ——但这次它保持 secret.txt在提交 L' .
你最终得到:

... <-H [ XXX deleted: <-I <-J <-K <-L ]
       \
        I' <-J' <-K' <-L'   <-- master

其中 secret.txt现在只存在于最后一次提交中， L' ，这是受到保护的。
The BFG 的文档建议您这样做:

git rm secret.txt
git commit

在开始之前，以便您开始:

... <-H <-I <-J <-K <-L <-M   <--master

哪里新提交 M没有 secret.txt在里面。现在提交 I通过 L都可以修复，因为 L不再是最后一次提交了。它不是通过名称来识别的。姓名 master发现，而不是 L ，但是 M ;只有 M本身找到 L .
笔记
一旦您更新了自己的存储库以进行新的和改进的提交，并丢弃旧的错误提交，您将需要使用 git push --force获取任何其他仍然拥有并仍在使用旧的错误提交的 Git，以切换到新的和改进的提交。
始终假设如果 secrets.txt甚至几秒钟就可以在网络上使用，有人在那里捕获了它的副本。