git - 在Git中的根提交之前添加提交？

Question

This question already has answers here:

Insert a commit before the root commit in Git?

（15个答案）


6年前关闭。





新问题

两个问题：


我正在尝试在所有提交之前提交一个提交。
最底部的提交具有 660fb2a76211f36ec9a67d0454a90eab469e9fd0作为SHA。当我键入 git rebase -i 660fb2a76211f36ec9a67d0454a90eab469e9fd0时，除最后一个提交外的所有提交都会显示在列表中。
我确实需要此提交出现，因此我可以将第一个提交作为最后一个提交！
当我将第一个提交作为列表中的第一个提交时（意味着总计第二个提交，因为如上所述，第一个提交不在列表中），我得到一个错误： error: could not apply b722c76... v1.4.3 BEAT release
我只是将其从列表的底部切下，然后放到顶部！我没有更改号码！
我也尝试了几次。相同的结果。


到此为止。如果您有任何疑问，请继续提问！

原始问题

我只是发现了项目的旧备份。这些备份是在我使用git之前创建的。
我现在想将它们作为旧提交添加到我的存储库中。那意味着我必须将这些提交置于所有其他提交之前。

现在有几个问题：


我通常如何将提交放在其他提交之前？
我怎么能这么快？ （我有很多备份！）
如何为这些“旧”提交设置日期？ （我知道备份的日期！）


如果不清楚，请提及。那我将解决问题！

最后一件事：

我已经在GitHub上发布了这个。我主要使用他们的软件来提交提交。那么，如何将其推回GitHub？

最佳答案

更新资料

我使用--root的git rebase标志找到了另一种稍微更简单的方法。我尝试了一个我的仓库，所以我知道它是有效的（至少对于完全线性的历史，最后更多）。

步骤1：为您的仓库创建备份克隆

为了安全起见，请进行备份，以防万一我们遭受了灾难性的损失而丢失了数据：

git clone original-repo backup-repo

第2步：创建孤立分支（这将是您的新根）

检出孤立分支。指定起点提交/分支是可选的，如果您忽略该参数，则Git将默认使用当前提交作为起点（遵循标准分支语法的模式）：

git checkout --orphan new-master firstCommitOfOldMaster

我将旧主目录的根指定为起点，因为它可能会使后续步骤更快（删除工作目录文件）。

步骤3：删除工作目录文件

从旧的主节点创建孤立分支 new-master可能会在工作目录和索引中留下文件，这取决于分支所提交的文件中文件的状态：


就像您以前运行 git checkout <start_point>一样调整索引和工作树。这样，您可以轻松运行 <start_point>进行根提交，从而开始一个新的历史记录，该历史记录会记录一组类似于 git commit -a的路径。 — git checkout docs


您现在要做的是完全清除分支的状态，以便真正从干净的面板（从顶层文件夹运行）开始：

git rm -rf .

这是来自文档的解释：


如果要启动一个断开的历史记录，该历史记录记录的路径集与 <start_point>的路径完全不同，则应在创建孤立分支后立即通过从顶部运行 git rm -rf .来清除索引和工作树工作树的级别。之后，您将准备好准备新文件，重新填充工作树，从其他位置复制它们，提取压缩包等。


步骤4：将较早的工作重新提交到 new-master

现在，您要开始将较早的工作提交到 new-master中。完成后，您将在原来的基础上重新建立基础。

我不确定您的备份文件夹的组织方式，但我将假设每个文件夹都只是项目文件夹的带日期的副本，以 YYYY-MM-DD格式命名，例如 2013-01-30。您可以手动将每个文件夹的内容添加为新的提交，也可以编写脚本来自动执行该过程。

假设所有备份文件夹都位于一个名为 backup的顶级文件夹中，该文件夹与主项目文件夹位于同一目录中。这是脚本的一些伪代码，可用于自动执行提交每个文件夹的过程：

# Get backups and sort them from oldest to newest
backups = open("backups").toList().sort("date ascending")
for each (backup in backups)
    copy files from backup to project folder
    execute `git add "*"`
    execute `git commit --date="#{backup.date}" --message="#{backup.date}"`

上面的脚本只会在提交之间添加和修改文件。如果您的任何备份删除，移动或重命名了文件，该脚本将不会记录。您需要编写一个更聪明的脚本来做到这一点（也许是使用 git diff或其他差异工具的东西），或手动记录这些更改。

步骤5：将旧的 master重新设置为 new-master

表现出惊人的力量！现在，我们将重新记录您的整个历史！背诵这些神秘的力量之词，并观看魔术的发生！：

git rebase --onto new-master --root master

TA-DA！您可能必须解决 new-master的最后一次提交和 master的第一次提交之间的冲突，但是除此之外，就应该这样！

--root的 rebase标志解决了我们前面遇到的一个问题，即通常情况下 rebase不会在Git存储库的第一次（根）提交上运行。 --root标志基本上告诉Git将其包括在 rebase中：


重新设置所有可从 <branch>访问的提交，而不是使用 <upstream>限制它们。这使您可以在分支上重新建立根提交。与 --onto一起使用时，它将跳过 <newbase>中已包含的更改（而不是 <upstream>），而没有 --onto时，它将对每个更改进行操作。 — rebase docs


步骤6：确认最终提交仍然相同

为了确保我们不会弄乱任何代码，我们想要将 master的当前最终状态与其进行 rebase之前的状态进行比较。以下任何一个命令都可以使用（它们是相同的）。在 master分支上时：

git diff orig_head   # "Original" head
git diff master@{1}  # Master at its 1st prior position

如果您没有从 diff获得任何输出，则意味着重新设置基准的 master的最终状态与 rebase之前的状态相同。做得好！

注意：不确定合并提交会发生什么...

现在，如果您具有完美的线性历史记录，即没有任何合并提交，则上述步骤将可以正常工作。我不确定是否可以继续使用。在下面的上一个答案中，我提到将 --preserve-merges标志与 rebase一起使用可能会帮助您保留这些合并，但是文档提到该标志还与 --onto和 --root标志交互：


当[ --root]与 --onto和 --preserve-merges一起使用时，所有根提交都将被重写为以 <newbase>作为父级。 — rebase docs


我现在不确定这意味着什么...我可能不得不尝试一下，看看会发生什么。这是否意味着如果您拥有多个根提交（例如10个），那么其中9个根提交最终将基于最后一个作为新根提交的根提交？这似乎不是我们想要的行为。我们只想保留将一个根重新建立到另一个根的合并提交。



先前的答案

MGA具有 the right idea with rebase。我不确定这是否可以解决您的问题，但是也许您需要在存储库中进行新的根提交，将备份文件添加为新的提交，然后再将旧的提交图重新建立基础。

例如， git checkout根据 the documentation具有 --orphan标志：


--orphan <new_branch>
创建一个新的孤立分支，名为 <new_branch>，从 <start_point>开始并切换到该分支。在这个新分支上进行的第一次提交将没有父母，这将是与所有其他分支和提交完全脱节的新历史的根源。


所以也许你可以尝试

git checkout --orphan <temp_branch>

然后将备份文件提交到该文件。然后在 temp_branch检出的情况下执行

git cherry-pick <first commit from master>
git rebase --onto temp_branch <first commit from master> master

我认为您可能需要 cherry-pick第一次提交，因为 rebase --onto的第二个参数是您要重新设置的分支的旧基础（在本例中为 master），并且不包含旧基础。所以这就是为什么我认为您需要 cherry-pick才能获取它，因为它本身没有基础提交，因此您不能在 rebase中为其指定一个。

另请注意，如果您的提交历史记录不是线性的（即具有合并提交），则 rebase通常不会保留这些提交。它有一个 --preserve-merges标志，但是我以前从未使用过它，因此我不确定它是如何工作的。从 the docs：


-p
--preserve-merges
不要忽略合并，而是尝试重新创建它们。

这在内部使用 --interactive机制，但是除非明确知道您在做什么，否则将它与 --interactive选项明确地组合通常不是一个好主意（请参见下面的错误）。


那么，也许所有这些都会起作用？

关于git - 在Git中的根提交之前添加提交？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16762160/

上一篇：tridion - 如何将参数传递给组件 (Dreamweaver) 模板？

下一篇：c - 如何将 gchar* 转换为 char

Answer 1

更新资料

我使用--root的git rebase标志找到了另一种稍微更简单的方法。我尝试了一个我的仓库，所以我知道它是有效的（至少对于完全线性的历史，最后更多）。

步骤1：为您的仓库创建备份克隆

为了安全起见，请进行备份，以防万一我们遭受了灾难性的损失而丢失了数据：

git clone original-repo backup-repo

第2步：创建孤立分支（这将是您的新根）

检出孤立分支。指定起点提交/分支是可选的，如果您忽略该参数，则Git将默认使用当前提交作为起点（遵循标准分支语法的模式）：

git checkout --orphan new-master firstCommitOfOldMaster

我将旧主目录的根指定为起点，因为它可能会使后续步骤更快（删除工作目录文件）。

步骤3：删除工作目录文件

从旧的主节点创建孤立分支 new-master可能会在工作目录和索引中留下文件，这取决于分支所提交的文件中文件的状态：


就像您以前运行 git checkout <start_point>一样调整索引和工作树。这样，您可以轻松运行 <start_point>进行根提交，从而开始一个新的历史记录，该历史记录会记录一组类似于 git commit -a的路径。 — git checkout docs


您现在要做的是完全清除分支的状态，以便真正从干净的面板（从顶层文件夹运行）开始：

git rm -rf .

这是来自文档的解释：


如果要启动一个断开的历史记录，该历史记录记录的路径集与 <start_point>的路径完全不同，则应在创建孤立分支后立即通过从顶部运行 git rm -rf .来清除索引和工作树工作树的级别。之后，您将准备好准备新文件，重新填充工作树，从其他位置复制它们，提取压缩包等。


步骤4：将较早的工作重新提交到 new-master

现在，您要开始将较早的工作提交到 new-master中。完成后，您将在原来的基础上重新建立基础。

我不确定您的备份文件夹的组织方式，但我将假设每个文件夹都只是项目文件夹的带日期的副本，以 YYYY-MM-DD格式命名，例如 2013-01-30。您可以手动将每个文件夹的内容添加为新的提交，也可以编写脚本来自动执行该过程。

假设所有备份文件夹都位于一个名为 backup的顶级文件夹中，该文件夹与主项目文件夹位于同一目录中。这是脚本的一些伪代码，可用于自动执行提交每个文件夹的过程：

# Get backups and sort them from oldest to newest
backups = open("backups").toList().sort("date ascending")
for each (backup in backups)
    copy files from backup to project folder
    execute `git add "*"`
    execute `git commit --date="#{backup.date}" --message="#{backup.date}"`

上面的脚本只会在提交之间添加和修改文件。如果您的任何备份删除，移动或重命名了文件，该脚本将不会记录。您需要编写一个更聪明的脚本来做到这一点（也许是使用 git diff或其他差异工具的东西），或手动记录这些更改。

步骤5：将旧的 master重新设置为 new-master

表现出惊人的力量！现在，我们将重新记录您的整个历史！背诵这些神秘的力量之词，并观看魔术的发生！：

git rebase --onto new-master --root master

TA-DA！您可能必须解决 new-master的最后一次提交和 master的第一次提交之间的冲突，但是除此之外，就应该这样！

--root的 rebase标志解决了我们前面遇到的一个问题，即通常情况下 rebase不会在Git存储库的第一次（根）提交上运行。 --root标志基本上告诉Git将其包括在 rebase中：


重新设置所有可从 <branch>访问的提交，而不是使用 <upstream>限制它们。这使您可以在分支上重新建立根提交。与 --onto一起使用时，它将跳过 <newbase>中已包含的更改（而不是 <upstream>），而没有 --onto时，它将对每个更改进行操作。 — rebase docs


步骤6：确认最终提交仍然相同

为了确保我们不会弄乱任何代码，我们想要将 master的当前最终状态与其进行 rebase之前的状态进行比较。以下任何一个命令都可以使用（它们是相同的）。在 master分支上时：

git diff orig_head   # "Original" head
git diff master@{1}  # Master at its 1st prior position

如果您没有从 diff获得任何输出，则意味着重新设置基准的 master的最终状态与 rebase之前的状态相同。做得好！

注意：不确定合并提交会发生什么...

现在，如果您具有完美的线性历史记录，即没有任何合并提交，则上述步骤将可以正常工作。我不确定是否可以继续使用。在下面的上一个答案中，我提到将 --preserve-merges标志与 rebase一起使用可能会帮助您保留这些合并，但是文档提到该标志还与 --onto和 --root标志交互：


当[ --root]与 --onto和 --preserve-merges一起使用时，所有根提交都将被重写为以 <newbase>作为父级。 — rebase docs


我现在不确定这意味着什么...我可能不得不尝试一下，看看会发生什么。这是否意味着如果您拥有多个根提交（例如10个），那么其中9个根提交最终将基于最后一个作为新根提交的根提交？这似乎不是我们想要的行为。我们只想保留将一个根重新建立到另一个根的合并提交。



先前的答案

MGA具有 the right idea with rebase。我不确定这是否可以解决您的问题，但是也许您需要在存储库中进行新的根提交，将备份文件添加为新的提交，然后再将旧的提交图重新建立基础。

例如， git checkout根据 the documentation具有 --orphan标志：


--orphan <new_branch>
创建一个新的孤立分支，名为 <new_branch>，从 <start_point>开始并切换到该分支。在这个新分支上进行的第一次提交将没有父母，这将是与所有其他分支和提交完全脱节的新历史的根源。


所以也许你可以尝试

git checkout --orphan <temp_branch>

然后将备份文件提交到该文件。然后在 temp_branch检出的情况下执行

git cherry-pick <first commit from master>
git rebase --onto temp_branch <first commit from master> master

我认为您可能需要 cherry-pick第一次提交，因为 rebase --onto的第二个参数是您要重新设置的分支的旧基础（在本例中为 master），并且不包含旧基础。所以这就是为什么我认为您需要 cherry-pick才能获取它，因为它本身没有基础提交，因此您不能在 rebase中为其指定一个。

另请注意，如果您的提交历史记录不是线性的（即具有合并提交），则 rebase通常不会保留这些提交。它有一个 --preserve-merges标志，但是我以前从未使用过它，因此我不确定它是如何工作的。从 the docs：


-p
--preserve-merges
不要忽略合并，而是尝试重新创建它们。

这在内部使用 --interactive机制，但是除非明确知道您在做什么，否则将它与 --interactive选项明确地组合通常不是一个好主意（请参见下面的错误）。


那么，也许所有这些都会起作用？