问题标签 [git-history-graph]

Git 中是否有命令可以查看（转储到标准输出，或转储到$PAGER或$EDITOR）特定文件的特定版本？

Git 是快照的DAG，图中的每个节点都代表一个提交。每个提交可以有“n”个父提交。

给定任何两个提交，是否有一种简洁的方式来辨别 DAG 中这两个提交的“顺序”。 git rev-list似乎是最有希望的，但我似乎找不到正确的咒语。

理想情况下，我会有以下内容

或者

或者

或者

我通常如何进行：

实际上，要从完整的历史记录中删除一些文件，我使用以下脚本（我称之为 git-crunch）：

它可以完美地从（完整的）历史记录中删除指定的文件。

上下文是：

我有 1 个项目分为 4 个分支。这是一个摘要网络图，显示了 4 个维护分支中的 2 个：

我的问题是：

我在这个存储库中有 3 个大文件，可以从一开始就删除（存储库的创建），但如果我使用我的脚本，它只会在一个分支中运行，它会从头开始重新创建 4 个单独的分支，直到最后一次提交，今天发生的事情。

我的问题：

如何在不从一开始就分离我的分支的情况下从我的整个历史记录中删除这 3 个文件？或者，有没有办法一次重写整个历史记录并从所有分支中删除文件，这样我就可以保持我的进化网络和“共享”提交完整（所以我的 61 个第一次提交不会重复四次）？

两个分支很久以前就出现了分歧（例如，开发和大师）。我想展示该分歧点两侧的历史，例如 +/-10 次提交。（这是为了决定如何重新捕获旧分支并改变命名约定）

很容易找到合并基础 ( git merge-base devel master)，并显示之前的 10 次提交 (例如git log --oneline -10 $(git merge-base devel master))。

但是我不确定如何在合并基础之前（比最近）定位 10 个提交点，以限制显示的提交范围（例如使用 show-branch）。

有没有办法沿着给定的发展路线进行第 n 个最近的提交？

In a project a subcontractor moved some files around in the tree, did a commit (Git marked them as deleted), used git add to re-add them to the tree. That happened several commits ago. Before I merge the changes back into my tree, I'd like to fix this. How can I "reconnect" these files at the right place in the git history?

Update

Okay, so, because people are suggesting a commit undo. That's not what I want (I think).

Imagine the following situation

I'd like to "splice" the history of file_x up to commit 1 with file_y since commit 4 without loosing any of the other changes that happened in between and commits 1 and 4.

我正在使用gitkand查看提交历史记录，git log并试图查看特定提交是如何到达某个分支的。我可以看到历史中的提交，所以我知道它们在那里。

我想了解的是它们是如何合并的（它们应该保留在自己的分支上）。这是一个非常大的项目，在有问题的提交和分支的当前状态之间有数百个提交，所以我无法清楚地破译有限的 DAG gitk，并且提交在其他分支中被掩盖并合并和提交消息。

为此，我一直在尝试：

我不理解结果。我只想查看包含相关特定提交的项目，以便我清楚地看到它是如何进入相关分支的。我该怎么做？

例子

我正在寻找的东西，gitk最好但git log就足够了：

更多信息

我还没有看到任何答案，所以如果没有答案，我会开始赏金，但也许我没有正确解释这个问题（我愿意接受改进和澄清的建议）。

这样做的驱动力是我可以看到提交本身，并且有人告诉我它不应该在某个分支上。这是我所看到的：

有人告诉我，除非它们被释放，否则test_dec14不应提交 in test_jan15，因此 {sha1hashIDstring} 提交不应该在test_jan15，但确实如此。我想知道为什么，它是如何到达那里的，以及是谁把它放在那里的。

例如，我想放弃提交消息为“临时提交”的所有提交，也就是说，如果原始提交历史如下：

那么提交历史将被改写如下，即提交 x4、x6 和 xn-1 被放弃。

如果一个 repo 总共有 2000 个提交，其中 500 个提交的消息是“临时提交”，那么 500 个提交将被放弃，只剩下 1500 个提交，如何重写这个 git 历史？

我知道它可能与过滤器分支有关，我知道如何使用 --tree-index 删除文件夹，但是如何删除某些特征的提交？

如果 Git 存储库结构如下所示：

是否可以将开发分支合并到 master 中，以便只向 master 添加一个提交，其中包含在开发分支中的所有提交中找到的所有更改。所以上面的结构会合并成这样：

提交将包含来自开发分支的E'所有更改，并且仅包含最新的提交消息，在一个整洁的提交中将新功能添加到 master。

这在 Git 中可能吗？我希望能够保持 GitHub 存储库的历史整洁，因为我的开发分支经常包含未完成、未完善且不适合人类使用的早期提交。

在我的工作场所，我们首先创建一个分支，在我们的 Github 存储库中为该分支创建一个拉取请求，然后有人对其进行审查并点击“合并拉取请求”来提交代码。这是一个非常标准的工作流程。

通常，当我们点击“Merge pull request”时，Github 会创建一个名为“Merge pull request #1234 from branchname”的新提交，其中包含 2 个父级——master 的 HEAD，以及 PR 中的最新提交。

今天我像往常一样合并了一个 PR，不知何故 Github 决定不使用 master 的 HEAD 作为父母之一，而是使用一天前的提交（我们每天进行 20 到 30 次提交）。它使用的这个提交是 PR 分支所基于的提交。这导致 master 分支丢失了从那时到此 PR 合并之间的所有提交。

有谁知道这怎么会发生？这是 Github 的错误吗？还是提交 PR 的开发者做了什么坏事，可能会覆盖 master？我认为所有提交都将简单地合并到 master 中，而无需在 Github 中进行任何 rebase 或历史重写。

我有一个 git 项目历史，我有近 400 次提交。我想删除第一个（最早的）200 个提交。然后在剩下的 200 次提交中，我只想删除所有合并提交并保持其余部分井井有条。

完成后，我想检查所有剩余的提交并更改一封特定作者的电子邮件。

有没有办法优雅地做到这一点？