git - 将 Git 提交从复制的 fork 存储库重新应用到原始存储库

Question

我的一位大学同事认为通过克隆存储库并将其内容复制到一个新的、刚初始化的存储库但没有 .git 是一个好主意。来自原始存储库的文件夹。之后，他简单地使用一次提交提交了这个副本，整个团队开始基于这个提交进行项目工作:

A <- B <- C     <- D <- E    (original repository)
\  clone  /        |_____| 
 \       /            |
  \     /     Ofc. work on the original repository was continued after cloning...
   \   /
     M <- N <- O <-P    (our "fork", commits from my team)

现在，我的第一个目标是获得以下存储库结构:

A <- B <- C <- N <- O <- P

在过去的几个小时里，我一直在尝试做以下事情:

1. • 克隆原始存储库。
   • git diff > /path/to/patch从 fork 内。
   • git apply在原始存储库中。
   • 有效，但不保留提交。
2. 各种其他不起作用的东西。
3. • 克隆原始存储库。
   • 创建并切换到新分支。
   • 将其重置为提交 A使用 git reset --hard COMMIT_HASH_A .
   • 从 N <- O <- P 创建补丁使用 git format-patch COMMIT_HASH_M --stdout > /path/to/patch在 fork 上。
   • 使用 git am -3 /path/to/patch 在原始存储库上应用此补丁.解决多次创建空文件等冲突后，会出现如下错误: fatal: sha1 information is lacking or useless (some_file_name).
Repository lacks necessary blobs to fall back on 3-way merge.
这是我无法继续的地方。

那么我如何创建一个存储库，包括来自原始存储库和我们团队的所有提交，以便最终可以将 pull 请求发送到原始存储库？可能是 git-rebase帮助？

Answer 1

TL;DR;

在您的原始仓库克隆中，您应该:

git remote add colleague /path/to/colleague
git fetch colleague
git checkout -b colleague colleague/master
git rebase master
git checkout master
git merge colleague

这将为您提供线性历史，并且不会留下冗余且无父元素的 M提交。

这不同于David Siro's answer ，这将产生一个 merge 提交，该提交也会留下冗余/无父项 M提交在您 merge 的分支中 float 。我不喜欢那种悬而未决的提交场景。

原帖

我复制了您好的和坏的存储库历史记录，并且能够通过基本上重新定位远程来解决问题。

这些是我遵循的步骤:

1. 克隆原始存储库
2. 将远程添加到错误的 repo
3. 获取错误的 repo master分支机构
4. 分支到获取的错误 repo
5. 将错误的 master 分支重新设置为您的 master(将声称已经应用了一些更改)
6. 将这个分支 merge 到你的master
7. 推回原始存储库
8. 安排你同事的死亡 😉

通过该设置，我使用的命令和关键输出如下。

#
# Step 1
#
$ git clone <path-to-original-repo>
$ cd original-repo

#
# Step 2
#
$ git remote add messed-up-repo <path-to-messed-up-repo>

#
# Step 3
#
$ git fetch messed-up-repo

#
# Step 4
#
$ git checkout -b bad-master bad-orig/master

#
# Step 5
#
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: commit M
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: commit N
Applying: commit O
Applying: commit P

#
# Step 5.1: look at your new history
#
$ git log --oneline --graph --decorate
* cc3121d (HEAD -> bad-master) commit P
* 1144414 commit O
* 7b3851c commit N
* b1dc670 (origin/master, origin/HEAD, master) commit E
* ec9eb4e commit D
* 9c2988f commit C
* 9d35ed6 commit B
* ae9fc2f commit A

#
# Step 6
#
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git merge bad-master 
Updating b1dc670..cc3121d
Fast-forward
 n.txt | 1 +
 o.txt | 1 +
 p.txt | 1 +
 3 files changed, 3 insertions(+)
 create mode 100644 n.txt
 create mode 100644 o.txt
 create mode 100644 p.txt

#
# Step 7
#
$ git push
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (9/9), 714 bytes | 0 bytes/s, done.
Total 9 (delta 3), reused 0 (delta 0)
To /tmp/repotest/good-orig.git
   b1dc670..cc3121d  master -> master

#
# Step 7.1: look at your history again
#
$ git log --oneline --graph --decorate
* cc3121d (HEAD -> master, origin/master, origin/HEAD, bad-master) commit P
* 1144414 commit O
* 7b3851c commit N
* b1dc670 commit E
* ec9eb4e commit D
* 9c2988f commit C
* 9d35ed6 commit B
* ae9fc2f commit A

您现在可以用火摧毁您同事困惑的存储库，并让其他人继续使用原来的、现在已修复的存储库。

注意:在您的帖子中，您说您想要提交:

A <- B <- C <- N <- O <- P

但我的解决方案包括提交 D和 E中间:A <- B <- C <- D <- E <- N <- O <- P .如果您真的想丢弃这些提交，即假设它不是您帖子中的拼写错误，那么您可以简单地git rebase -i HEAD~5 , 删除 pick这些提交的行，然后是 git push --force到你好的 repo 的来源。

我假设您了解重写历史的含义，并且您需要与您的用户沟通，以免他们受其影响。

---

为了完整起见，我按如下方式复制了您的设置:

1. 创建原始良好 repo 历史:A <- B <- C
2. 手动复制原始内容到乱七八糟的repo
3. 生成困惑的提交历史:M <- N <- O <- P , 其中M与原版内容相同A <- B <- C
4. 将作品添加到原始存储库:... C <- D <- E