如何让 git-push 永久跳过详细分支的提交？

Question

对于一个 repo，我使用一个简单的脚本来定期提交对文件的更改，以保留相当详细且不合逻辑的历史记录，我想保留这些历史记录用于我自己的统计目的（即我知道 git rebase ，但无论如何我都想保留这个不合逻辑的历史）。目前我只是致力于一个单独的分支autocommit 并使用

git checkout master
git merge --squash autocommit
git commit
git checkout autocommit
git merge --ff-only master

对于“正确的”提交保持master 分支整洁，同时保持与autocommit-分支的关系。所以我有这样的历史

| *   95e4189 Merge branch 'main' into autocommit
| |\
| |/
|/|
* | 040386a <= created via git merge --squash autocommit
| * 72bc5a5 autocommit
| * 9aaf5a6 autocommit
| * ea758c0 autocommit
| * 7ff1de8 autocommit

但我真正想要的是将git merge autocommit --edit 转换为master 以正确 链接到历史记录。但是，我不想git push 来自autocommit 分支的任何内容（或任何带有所述消息的提交，如果这样更易于管理的话）。但是我想这基本上会破坏推送的回购，因为部分提交历史将无法访问。所以我的问题是：

• 我该怎么做呢？ IE。一种git push --skip autocommit
• 我应该怎么做？ squash-commit 版本似乎不是最佳的

对于可视化，我目前有：

   A1 -> A2 -> A3--=> A3' -> A4 -> ...    [autocommit]
  /            ↓' /
M1-----------> M2 -----> ...              [master]

其中↓' 表示git merge --squash，这意味着A3 不是M2 的父级，但只有M1 是，A3' 只是合并回M2 以更好地跟踪连接。我认为我想要的只是

M1--------------=> M2 ---> ....                             [master]
  \            /
  A1 -> A2 -> A3 -> A4 (or maybe A3' first merging M2 back) [autocommit]

但是来自autocommit 分支的A1 等提交都没有被推送。

Answer 1

IMSoP's answer 涵盖了大部分可能性，但还有一种可能性假设您的“详细”和“非详细”分支始终完全同步源代码在“更新非详细分支”点，就是这样做：

o----------A----------B   <-- master
 \         ⋮\         ⋮\
  D1--D2--D3-M1--D4--D5-M2   <-- detailed

在这里，您可以在 detailed 分支上工作。当您决定进行新的master 提交时，您实际上是将文件从detailed-branch 提交（例如D3）复制到master 上的新提交中，由垂直省略号⋮ 表示.然后使用git merge 将来自master 的新提交合并到detailed，作为合并提交M1。 Git 现在相信/知道master 和detailed 的合并基数 是提交A。

此合并的目的并不是真正执行合并，甚至不是记录合并，而是在提交图中记录来自detailed 的提交用于在master 中创建提交。换句话说，这更多的是 your 参考而不是 Git。但这也让我们可以使用git merge --squash 来创建 提交A、B 等等。我们可以像这样创建提交A：

git checkout master
git merge --squash detailed

由于从 o 到 o 没有任何变化（o 是这次合并的合并基础），Git 将这些无变化与 detailed 上的 o 之后的变化“结合”起来。生成的非合并（壁球）提交是提交A。但是在提交A 之后，我们现在运行：

git checkout detailed
git merge master

Git 现在比较提交 o 与 A 以查看它们更改了什么，并比较 o 与 D3 以查看我们更改了什么。这些更改完全匹配（当然），因此合并提交 M1 有一个与 两个 提交 D3 和 A 匹配的快照。

我们现在在detailed 上进行更多通常的详细提交，然后重复上述过程以创建提交B 和M2。这次的合并基础是提交A。最终结果是，我们的位置与提交 A 时的位置相同，但下一次我们执行所有这些操作时，合并基础将是提交 B。

请注意，可以在不运行 git merge --squash 的情况下创建提交 A 和 B，并且可以在不运行 git merge 的情况下创建合并 M1 和 M2：我们知道所需的 tree 对于每个提交，我们可以简单地使用 git commit-tree 来进行这些提交。但是git commit-tree 不是面向用户的命令，使用起来有点困难。您可以编写自己的 Git 命令来执行此操作，以确保所有操作都正确完成 - 例如，没有直接提交到 master - 但是如果您做使用git merge --squash，则提交直接发给master 实际上只是工作。以下是其中一个可能的样子，表示为哈希 ID 为 C 的提交：

o----------A----------B-----C----D   <-- master
 \         ⋮\         ⋮\         ⋮\
  D1--D2--D3-M1--D4--D5-M2--D6--D7-M3   <-- detailed

在这里，也许提交C 是一个紧急的错误修复。我们没有在 detailed 分支中创建它，而是直接在一个新分支上创建它，对其进行测试，然后将其合并到 master （所以也许这是一个小的合并气泡而不是直接提交——最终结果是无论它是如何构建的，都一样）。 git merge --squash 操作结合C 中的更改与从B 到D7 的更改，以及从D 到M3 的合并引入 从提交 C 更改为 M3 和 D 匹配，源代码快照明智。

Answer 2

要了解什么是可能的，了解一下 git 的工作原理是很有用的。从根本上说，git 建立了分层的版本控制模型：

1. 一个内容寻址的数据库，可以根据其内容的散列查找任意数据块。这些 blob 是不可变的，因为更改任何内容都会产生新的哈希，因此永远不会更新现有项目。
2. 有向无环图，其中 blob 描述存储库的状态、一些元数据（日期、提交者、消息等）以及零个或多个父级。父母通过其不可变哈希来寻址，并且反过来又是新提交的哈希内容的一部分。
3. 指向特定提交的指针，以赋予它们更用户友好的名称。我们称其中一些为“分支”，但它们只指向一个提交；从那里，git 可以沿着父引用向后走，以找到该分支“上”的所有提交。

由此，我们可以看到一些不可能的事情：

• 让您的本地副本记录两个父级的提交，但 github 仅显示同一提交的一个父级 - 一组不同的父级会给出不同的哈希值，因此没有任何东西会识别为相同的提交。
• 记录了双亲，但没有在autocommit 分支上推送提交 - git 不知道它在历史中找到的合并中的分支名称，它只是将所有父提交视为它正在跟踪的历史的一部分向后。
• 推送在一个分支上可访问的所有提交，但在不同分支上也可访问的提交除外。这仍然不是一个足够强的定义，因为最终您将在创建autocommit 分支之前 到达历史记录中的提交，并且git 也不知道历史记录中发生的位置.
• 即使您可以定义不想推送的提交列表，工具也不会很高兴找到对显然不存在的父提交的引用，并且可能会假定您是存储库已损坏。

我真的只能想到两个选择：

• 从您的自动提交分支记录一次正常的合并，并与您的历史记录中显示的自动提交一起使用。
• 像现在一样压缩提交，但创建您自己的工具来记录您压缩了哪些自动提交，并允许您查找它们，确保没有遗漏，等等