【问题标题】:Are squashed commits in a rebase visible to others?其他人可以看到变基中的压缩提交吗?
【发布时间】:2021-09-04 18:47:46
【问题描述】:

我想知道变基中的压缩提交是否对其他人可见+可访问。我将举一个简单的例子。假设这一切都发生在我的本地机器上的本地 git repo 中。

  • 我使用 env 机密提交“X”(哦,不!)
  • 我提交“Y”删除了已提交的 env 机密以及其他一些不相关的代码更改
  • 然后我通过压缩 2 个提交(例如 git rebase -i HEAD~2)来重新设置基准,这样我的带有 env 机密的提交就被压缩了

问题:如果我随后将我的提交推送到公共 repo,其他人(假设是坏演员)是否能够以某种方式拉取更改并搜索包含 env 机密的压缩提交?

注意:我从here 了解到,reflog 提交仍然可以在本地访问,但我不是从本地 repo 的角度询问,而是从另一台机器上的某人拉动我的新提交的角度询问。此外,我不介意压缩的提交消息(强调消息)是否仍然可见,例如在有人忘记在变基期间将它们注释掉的情况下,我的问题与压缩的提交本身有关。

谢谢!!

【问题讨论】:

  • 不,我不这么认为。但是,需要注意的一件事是,如果您已经切换到另一个分支,其中包含您的秘密的提交,然后在不知不觉中推送(例如通过--all)该分支到您的远程。据我所知,Git 也不应该推送松散的对象。

标签: git github version-control versioning


【解决方案1】:

在交互式 rebase 期间,XY 被替换为包含结果更改的全新提交 (Z)。如果原始提交没有链接到另一个提交、分支、标签或其他引用,它们就会变得悬空/无法访问。如您所知,它们仍然可以在您的本地存储库中访问,并且最终会被垃圾回收。

当您将分支推送到远程时,只会推送引用的提交。在这种情况下,Z 和更早的提交尚未在远程(如果有)上。 XY 不会被推送,除非它们是您稍后推送的另一个引用(例如分支)的一部分。


$ git clone <remote-repo> .
$ echo "SECRET" > file.txt
$ git commit -am "X"
$ echo "******" > file.txt
$ git commit -am "Y"

$ git log --oneline --graph --all
* 2e61b2a (HEAD -> master) Y
* fbeb59a X
* 3068e71 (origin/master, origin/HEAD) Initial commit

$ git rebase -i HEAD~2               # pick X, squash Y, new message: 'Z'

$ gittest % git log --oneline --graph --all
* bc58ac7 (HEAD -> master) Z
* 3068e71 (origin/master, origin/HEAD) Initial commit

新的提交 bc58ac7 替换了另外两个提交。 diff 不显示秘密值(在提交 X 中看到),而只显示两个提交的结果更改

$ git diff 3068e71 bc58ac7
diff --git a/file.txt b/file.txt
index e69de29..0b13ec0 100644
--- a/file.txt
+++ b/file.txt
@@ -0,0 +1 @@
+******

推送后,我们看到origin/master 引用了新的提交:

$ git push
$ git log --oneline --graph --all
* bc58ac7 (HEAD -> master, origin/master, origin/HEAD) Z
* 3068e71 Initial commit

当我们打印远程存储库上的所有对象时,我们看到两个提交都不存在。 (此命令需要在远程仓库中执行,而不是在本地克隆中。)

$ git cat-file --batch-check --batch-all-objects
0b13ec01f786f69139940c06f3bc7f9645550cfa blob 7
3068e71e3ca27d864af7a1c5eb7dc90aee31de14 commit 229
76fd94cb5a10f70fe2fadc41af74e9eeeb8e35b5 tree 36
bc58ac7510f3e08d693029674a7ac545404e48cd commit 264
bdd68b0120ca91384c1606468b4ca81b8f67c728 tree 36
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 blob 0

【讨论】:

    【解决方案2】:

    我从这里了解到 reflog 提交仍然可以在本地访问,但我不是从本地 repo 的角度提出问题,而是从另一台机器上的某人拉动我的新提交的角度提出问题。

    那么不:reflog 纯粹是本地的,您在 reflog 中看到的任何取消引用的历史记录在推/拉之后都将不可见。

    只有在您推送第一次提交时才会可见,然后合并压缩然后强制推送:第一次和第二次推送之间的间隔可能会让某人有时间获得有问题的提交。

    【讨论】:

      猜你喜欢
      • 2010-12-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-10-05
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多