Git 合并到与已删除分支同名的分支后缺少提交

Git 合并到与已删除分支同名的分支后缺少提交,git,Git,将功能分支合并到与该功能分支所来自的现已删除的分支同名的分支后,我们缺少一些提交 更清楚一点,以下是事件的顺序: 我们有一个根回购和一个从根分支的生产支持 我从生产支持分支到创建功能分支 随着时间的推移,功能分支中的工作已经完成 有人删除了生产支持分支,并使用根目录下的相同名称重新创建了一个新分支 我把新的生产支持部门拉到了当地 然后,我将功能分支合并到生产支持中 完成合并后,我在生产支持中丢失了Feature Branch中存在的提交 编辑:合并后,我缺少产品支持中功能分支的一些但不是全部提交

将功能分支合并到与该功能分支所来自的现已删除的分支同名的分支后,我们缺少一些提交

更清楚一点,以下是事件的顺序:

  • 我们有一个根回购和一个从根分支的生产支持
  • 我从生产支持分支到创建功能分支
  • 随着时间的推移,功能分支中的工作已经完成
  • 有人删除了生产支持分支,并使用根目录下的相同名称重新创建了一个新分支
  • 我把新的生产支持部门拉到了当地
  • 然后,我将功能分支合并到生产支持中
  • 完成合并后,我在生产支持中丢失了Feature Branch中存在的提交

    编辑:合并后,我缺少产品支持中功能分支的一些但不是全部提交

    我认为删除生产支持部门可能导致这种情况,对吗?或者我应该去别处看看吗?

    让我先警告你:我不是Git专家。我只是碰巧因为自己的愚蠢而“丢失”了一些东西(呃,也就是说:在没有阅读手册的情况下尝试使用Git…),并且不得不以某种方式恢复它们。。任何提示/描述都是非正式的。你必须阅读更多关于我下面所说的内容

    --

    根据您提供的事件顺序,我猜:

    • 旧Prod分支的hash=AAAA
    • 新产品分支具有hash=BBBB!=AAAA
    • 首先将该功能合并到Prod中,然后进行更改,将Prod分支替换为newProdBranch
    如果我是对的,你真的先做了合并,然后拉,然后你的本地Git还不知道新的分支。它将该功能合并为AAA。然后你拉,AAA被删除,BBB被创建

    如果是这样的话,您现在的目标是找到丢失的AAA分支,并用“Prod”以外的名称重命名/标记它,现在它指向BBB。然后,您将能够将/copy/etc更改从ProdOld移动到NewProd

    --

    如果您在本地合并了分支,那么您仍然可以恢复它。通常,Git不会立即删除内容。您可能仍然拥有本地“工作副本”上的所有内容,它可能只是“分离/孤立的”。它失去了它的名字,没有连接,所以看不见,但是如果你知道它的散列,你可以像一个普通的“活的”分支一样简单地检查它

    当然,除非你同时删除并重新克隆它。或者以任何其他方式对其进行清理/修剪/gc,这将导致永久删除孤立条目

    首先,尽量记住丢失的提交。可能会记录消息、日期、ID/哈希

    如果你知道散列,那很好,跳到下一点。 如果您不知道散列,但还记得日志消息、日期或任何有用的信息,请尝试使用
    reflog
    命令。它将向您显示存储库中任何分支的任何提示的所有“最新”更新。Git通常会记住旧条目一段时间。即使他们被抛弃/删除/丢失,他们仍然可能坐在那里。简单运行

    git reflog
    
    在进行合并的本地工作目录上。
    它将向您显示一些提交,最重要的是,它们的散列。如果您不知道丢失提交的哈希值,现在您可以学习它们了

    如果reflog没有它们,我不知道该怎么办。我记得我读到有另一种低级机制可以让你丢失散列,但我不记得那是什么,对不起

    假设您现在拥有丢失提交的哈希:

    请明确查看:

    git checkout a76sa7..THE_HASH_HERE
    
    即使提交是“丢失的”,如果只有git repo还没有被“删减/GC”掉,提交也会被抓取,当前提示会指向它。现在从它创建一个分支,只是为了标记它并防止被修剪/GCed,例如:

    git branch temp_restoring_commit
    
    新分支
    temp\u restoring\u commit
    将标记提交,以便于参考。从现在起,你可以认为承诺是“恢复的和安全的”,除非你移除分支,否则它不会蒸发。(当然,reflog可能还能再次帮助您)

    现在,您可以尝试:

    • 将提交合并到其他地方(将更改复制/移植到另一个分支)
    • 重新设置提交的基址(将丢失的提交连接到正确的分支)
    • 将其推送到远程回购,以便其他人可以为您清理:)
    • 等等
    正如我所说,当我在本地删除一个尚未投入生产的分支时,我已经做过几次了。我很幸运,因为“损害”是新的,本地回购协议还没有“清理”。如果您的本地repo不再记得这些提交,您可以将live连接到Prod repo并尝试reflog/branching,但我的知识到此为止。只是不要尝试克隆远程repo-它不会像旧的未连接的丢失提交那样获取“垃圾”。你需要把手放在一个“脏”的存储库上。

    让我先警告你:我不是Git专家。我只是碰巧因为自己的愚蠢而“丢失”了一些东西(呃,也就是说:在没有阅读手册的情况下尝试使用Git…),并且不得不以某种方式恢复它们。。任何提示/描述都是非正式的。你必须阅读更多关于我下面所说的内容

    --

    根据您提供的事件顺序,我猜:

    • 旧Prod分支的hash=AAAA
    • 新产品分支具有hash=BBBB!=AAAA
    • 首先将该功能合并到Prod中,然后进行更改,将Prod分支替换为newProdBranch
    如果我是对的,你真的先做了合并,然后拉,然后你的本地Git还不知道新的分支。它将该功能合并为AAA。然后你拉,AAA被删除,BBB被创建

    如果是这样,您现在的目标是找到丢失的AAA分支,并将其重命名/标记为wi
    ..- o - o - o - o - o - o       <-- root
                  \
                    o - C - P       <-- production_support
                          \
                            o - o   <-- feature
    
    ..- o - o - o - o - o - o       <-- root
                  \
                    o - C - P       [no label - abandoned]
                          \
                            o - o   <-- feature
    
                                o   <-- production_support
                              /
    ..- o - o - o - o - o - o       <-- root
                  \
                    o - C
                          \
                            o - o   <-- feature
    
    $ git checkout production_support && git merge feature
    
                                o - M <-- production_support
                              /    /
    ..- o - o - o - o - o - o   <-------- root
                  \               |
                    o - C         |
                          \      /
                            o - o   <---- feature
    
    $ git fsck
    ...
    dangling commit de7c26f2b124f0038ab0ed03da9cb47647fc9867
    ...
    $ git log de7c26f2b124f0038ab0ed03da9cb47647fc9867
    
    $ id_for_c=...   # find SHA-1 for commit C, put that in here
    $ for id in $(cat /tmp/candidates); do
    > [ $(git rev-parse ${id}^) = $id_for_c ] && echo "likely match: ${id}"
    > done
    
    ..- * - * - B - * - * - *   <-------- root
                  \           \
                    \           O   <---- production_support
                      \
                        * - * - T   <---- feature
    
    $ git checkout production_support; git merge feature
    
    ..- * - * - B - * - * - *   <-------- root
                  \           \
                    \           O - M <-- production_support
                      \           /
                        * - * - T   <---- feature