问题标签 [git-history-graph]

我对 GIT History 有一个具体的问题。可以比较两个分支并获得所有文件都已更改的列表吗？如果是，请告诉我如何。

原因是我需要在另一个分支中合并一个分支。从开发人员那里不再可用...我需要知道他更改了哪些文件。

非常感谢，弗洛里安

1. 我有Branch1and Branch2，并且在两个分支中添加了一个同名的文件。说Branch1\folder\file.txt和Branch2\folder\file.txt。
2. 我合并Branch1到Branch2文件中并得到预期的合并冲突。
3. 我选择Branch1文件的版本，提交并推送。

当我在其中看到文件的历史记录时，Branch2我看到该文件是“添加”而不是“修改”的。我希望已修改，因为该文件已经存在Branch2并由该文件更新，Branch1但 Git 历史记录并未反映这一点。

这是设计使然吗？有没有其他方法可以通过正确/期望的历史来实现相同的结果？

是否有任何方法或任何工具或命令可以将某个提交号master的历史记录 或某个A分支重新写入NEW REPOSITORY新创建的分支，该分支具有 0 个提交或没有历史记录。mastermaster

以这样的方式：

1. 提交编号“45678”之前的所有先前提交都应在新的存储库主分支中重写为单个提交
2. 重写历史应该从提交“45678”开始

谢谢

我有 GitLab MR，我想在 Upsource 中查看这些更改（我想将更改从featureto合并rc）。feature包含提交2, 4, 6, 8。但是当我点击Create branch review我的 MR 分支时，并不是所有来自 MR 的提交都被导出来审查。

我尝试以 3 种不同的方式解决问题：

1. 当评论由创建时Create branch review，只8添加提交，因为分支fix是从提交创建的6（使用搜索请求时也会发生同样的事情only-branch: {feature}）。MR 提交：2, 4, 6, 8
2. 如果我尝试通过搜索添加修订，branch: {feature}我会收到提交2, 3, 4, 5, 6, 8，因为此搜索会添加来自所有合并到feature. MR 提交：2, 4, 6, 8
3. 我可以使用 requestbranch: {feature} and not branch: rc并获取我想要的所有提交，但我必须将and not branch:所有合并到feature. 而且我还有一个问题 - 我不能使用select all复选框。无法加载所有符合请求的提交，仅通过单击more按钮加载了 20 个提交。

您能否告诉我将所有 MR GitLab 提交添加到 Upsource 审查的最简单方法。

我试图通过嫁接历史将 2 个存储库合并为 1 个。我认为这是获得干净的线性历史的最简单方法。

我尝试通过将另一个作为远程添加到初始存储库来做到这一点：

树看起来不错，问题是我没有在当前目录中获取 repo B 的内容。

我也试过这个（提交哈希是 b/master 的提示）

当我检查树时，我可以看到每个提交都包含它的更改，但是主仓库中的第一次提交基本上是删除了 repo B 带来的所有更改：

原始提交都没有删除文件。

我错过了什么，我使用过滤器分支和移植错误吗？还是我只需要使用cherry-pick或rebase来保留当前目录中的所有更改？

在一个不完整的feature分支上工作，我已经提交了一个Fixfor master。

我如何获得Fix提交到master，...

...但仍然能够合并/重新建立我的feature分支master？

我想Fix'应该保持相同的 SHAFix以便不被看到完全不同的提交并顺利合并/重新调整（所以cherry-pick，我通常使用的，在这里没有帮助）。所以也许这是不可能的，但我很好奇是否有任何方法可以与另一个分支共享来自一个分支的一些临时修复，并且仍然能够稍后合并其余丢失的提交。

我的feature分支只是一个本地分支。我自然要避免改写历史。

我已经执行了git filter-branch --index-filter 'git rm --cached --ignore-unmatched badfiles/ badfiles2/' --prune-empty（per here）来删除一堆文件，以准备将剩余的文件移动到另一个存储库。--prune-empty摆脱任何产生的空提交，但它不会对合并起作用，这是有道理的。

现在这个特定 repo 的历史看起来很丑陋，有一堆实际上没有添加任何东西的合并，还有一些只是合并了其他没有实际添加任何更改的合并（在重写的历史中；他们可能已经在过滤器分支之前“有用”）。

考虑这个带注释的片段（用 生成git log --graph --oneline --shortstat）：

我想将其缩短为（显然使用不同的 id）：

所以我想摆脱“无用”合并，它们都是“空”合并（没有合并更改），但我想保留与同样“空”的KEEP 合并相关的历史记录/分组顶部，将这些提交组合成一个“变更集”。

或者看看传统的简化横向历史中的另一个例子：

我已经尝试了删除“空”合并的解决方案（像这样），但是那些删除了所有空合并，我想保留示例中显示的“有用”空合并...

据我所知，“无用”的空合并不包含任何并非一直到历史左侧/顶部的提交。有没有办法干净地过滤掉那些？我想我什至不知道如何描述/定义那些......

请注意，给定的示例是故意简单的。对于它的价值，在历史的后期，这个回购看起来像这样，所有这些我都想修剪：

我有一个存储库，它只是我的，所以破坏任何东西都没有问题。而且只有一个分支，我认为这让事情变得更容易。假设我有这 7 个提交：

A -> B -> C -> D -> E -> F -> G

我想删除提交 C 和 D

A -> B -> E -> F -> G

作为 A 有史以来第一次提交，而 G 是最后一次提交。

我怎样才能做到这一点？无需接触我的代码，只需了解 git 历史。

我知道我唯一能做的就是重置头部，但这不起作用，因为我不想删除 E、F 和 G。

下面是 show-rev 的 git 输出

正如你所看到的那样，有一行master^2和master~2 所以，想知道这两者之间有什么区别，而且输出不按时间顺序排列。

进一步的git图显示如下

运行git log时我看到奇怪的图表。我将进一步解释。下面是带有图形的 git log 的输出。

如您所见，master 本身有两个独立的分支。为了进一步证实这一点，我跑了

进而

很明显，这两个提交都存在于 master 上 - 那么为什么会有两个图表。 我怎么知道两个提交是否都在 master 上。或者，如果只有其中一个的变化实际上出现在主控器上，那么两者中的哪一个？

编辑 - 遵循 RY 和 Mark 的回复 （如果颜色代码增加了任何进一步的含义，请也提示这一点。）
因此，我进一步试图理解为什么提交（Y）不基于先前的提交（X）（如果 X在 Y) 之前提交。git log 显示同时提交了这两者d56a675和ee9bb70 提交的位置。

但是，在进一步挖掘时，可以看出细微的差别..

和

这些信息应该足以让 git 将提交按正确的顺序排列。但如果不是，那我想它更聪明，而且是有原因的，只是试图理解原因和原因。