我喜欢亚里士多德的答案。但我发现对于大型存储库(>5000次提交)，基于以下几个原因，filter-branch比rebase更好 1)它更快 2)当存在合并冲突时，不需要人工干预。 3)它可以重写标签——保存它们。 注意，filter-branch可以工作，因为每次提交的内容都没有问题——它与“rebase”之前完全相同。

我的步骤是:

# first you need a new empty branch; let's call it `newroot`
git symbolic-ref HEAD refs/heads/newroot
git rm --cached -r .
git clean -f -d

# then you apply the same steps
git commit --allow-empty -m 'root commit'

# then use filter-branch to rebase everything on newroot
git filter-branch --parent-filter 'sed "s/^\$/-p <sha of newroot>/"' --tag-name-filter cat master

注意，'——tag-name-filter cat'选项意味着标签将被重写以指向新创建的提交。

结合最新和最好的。没有副作用，没有冲突，保持标签。

git log --reverse

tree=`git hash-object -wt tree --stdin < /dev/null`
commit=`git commit-tree -m 'Initialize empty repository' $tree`
echo $commit # copy below, interpolation didn't work for me

git filter-branch --parent-filter 'sed "s/^\$/-p <commit>/"' --tag-name-filter cat master

git log --reverse

请注意，在GitHub上，您将丢失CI运行数据和PR可能会搞砸，除非其他分支也得到修复。

启动一个新的存储库。

将日期设置为您想要的开始日期。

按照你希望的方式做每件事，调整系统时间以反映你希望那样做的时间。根据需要从现有存储库中提取文件，以避免大量不必要的输入。

当您到达今天时，交换存储库，您就完成了。

如果你只是一个疯狂的(成熟的)但相当聪明的人(很可能，因为你必须有一定的智慧才能想出像这样疯狂的想法)，你将编写这个过程。

当你决定让过去的事情从现在开始以另一种方式发生时，这也会让事情变得更好。

好吧，这是我想到的:

# Just setting variables on top for clarity.
# Set this to the path to your original repository.
ORIGINAL_REPO=/path/to/original/repository

# Create a new repository…
mkdir fun
cd fun
git init
# …and add an initial empty commit to it
git commit --allow-empty -m "The first evil."

# Add the original repository as a remote
git remote add previous $ORIGINAL_REPO
git fetch previous

# Get the hash for the first commit in the original repository
FIRST=`git log previous/master --pretty=format:%H  --reverse | head -1`
# Cherry-pick it
git cherry-pick $FIRST
# Then rebase the remainder of the original branch on top of the newly 
# cherry-picked, previously first commit, which is happily the second 
# on this branch, right after the empty one.
git rebase --onto master master previous/master

# rebase --onto leaves your head detached, I don't really know why)
# So now you overwrite your master branch with the newly rebased tree.
# You're now kinda done.
git branch -f master
git checkout master
# But do clean up: remove the remote, you don't need it anymore
git remote rm previous

Git将——root——重基到$emptyrootcommit

应该很容易做到吗

我认为使用git replace和git filter-branch是一个比使用git rebase更好的解决方案:

更好的性能 更简单，风险更低(你可以在每一步验证你的结果，并撤销你所做的…) 与多家分公司合作，工作成果有保证

它背后的理念是:

在过去创建一个新的空提交 用一个完全类似的提交替换旧的根提交，除了新的根提交被添加为父提交 验证一切都如预期的那样，并运行git filter-branch 再次验证一切正常，并清除不再需要的git文件

以下是前2步的脚本:

#!/bin/bash
root_commit_sha=$(git rev-list --max-parents=0 HEAD)
git checkout --force --orphan new-root
find . -path ./.git -prune -o -exec rm -rf {} \; 2> /dev/null
git add -A
GIT_COMMITTER_DATE="2000-01-01T12:00:00" git commit --date==2000-01-01T12:00:00 --allow-empty -m "empty root commit"
new_root_commit_sha=$(git rev-parse HEAD)

echo "The commit '$new_root_commit_sha' will be added before existing root commit '$root_commit_sha'..."

parent="parent $new_root_commit_sha"
replacement_commit=$(
 git cat-file commit $root_commit_sha | sed "s/author/$parent\nauthor/" |
 git hash-object -t commit -w --stdin
) || return 3
git replace "$root_commit_sha" "$replacement_commit"

您可以毫无风险地运行此脚本(即使在执行以前从未执行过的操作之前进行备份也是个好主意;))，如果结果不是预期的，只需删除在.git/refs/replace文件夹中创建的文件并重试;)

一旦您验证了存储库的状态是您所期望的，运行以下命令来更新所有分支的历史:

git filter-branch -- --all

现在，你必须看到2个历史记录，旧的和新的(更多信息请参阅filter-branch上的帮助)。您可以比较这两个并再次检查是否一切正常。如果您满意，删除不再需要的文件:

rm -rf ./.git/refs/original
rm -rf ./.git/refs/replace

你可以返回到你的主分支并删除临时分支:

git checkout master
git branch -D new-root

现在，一切都该完成了;)