Для этого есть 2 шага:

1. Создать новую пустую фиксацию
2. Перепишите историю, чтобы начать с этого пустого коммита

Мы поместим новую пустую фиксацию во временную ветку newroot для удобства.

1. Создайте новую пустую фиксацию

Есть несколько способов сделать это.

Использование только сантехники

Самый чистый подход - использовать встроенную систему Git, чтобы просто создать фиксацию напрямую, что позволяет избежать касания рабочей копии или индекса, а также того, какая ветка извлечена и т. Д.

1. Создайте объект дерева для пустого каталога:

   tree=`git hash-object -wt tree --stdin < /dev/null`
   

2. Оберните вокруг него коммит:

   commit=`git commit-tree -m 'root commit' $tree`
   

3. Создайте ссылку на него:

   git branch newroot $commit
   

Вы, конечно, можете преобразовать всю процедуру в однострочную, если вы достаточно хорошо знаете свою оболочку.

Без сантехники

С помощью обычных фарфоровых команд вы не можете создать пустую фиксацию, не проверив ветку newroot и неоднократно обновляя индекс и рабочую копию, без уважительной причины. Но некоторым это будет легче понять:

git checkout --orphan newroot
git rm -rf .
git clean -fd
git commit --allow-empty -m 'root commit'

Обратите внимание, что в очень старых версиях Git, в которых отсутствует переключатель --orphan на checkout, вы должны заменить первую строку следующим образом:

git symbolic-ref HEAD refs/heads/newroot

2. Перепишите историю, чтобы начать с этого пустого коммита.

У вас есть два варианта: перебазирование или перезапись чистой истории.

Ребазинг

git rebase --onto newroot --root master

В этом преимущество простоты. Однако он также будет обновлять имя и дату коммиттера при каждой последней фиксации в ветке.

Кроме того, с некоторыми краевыми историями случаев он может даже выйти из строя из-за конфликтов слияния - несмотря на то, что вы выполняете переустановку на фиксацию, которая ничего не содержит.

Переписать историю

Более чистый подход - переписать ветку. В отличие от git rebase, вам нужно будет посмотреть, с какого коммита начинается ваша ветка:

git replace <currentroot> --graft newroot
git filter-branch master

Очевидно, что переписывание происходит на втором этапе; это первый шаг, требующий объяснения. Что git replace делает, так это сообщает Git, что всякий раз, когда он видит ссылку на объект, который вы хотите заменить, Git должен вместо этого проверять замену этого объекта.

С переключателем --graft вы говорите немного иначе, чем обычно. Вы говорите, что у вас еще нет заменяющего объекта, но вы хотите заменить объект <currentroot> commit его точной копией за исключением, что родительский коммит (и) замены должен быть тем (и) ), который вы указали (т. е. фиксация newroot). Затем git replace создает эту фиксацию для вас, а затем объявляет эту фиксацию как замену вашей исходной фиксации.

Теперь, если вы выполните git log, вы увидите, что все уже выглядит так, как вы хотите: ветвь начинается с newroot.

Однако обратите внимание, что git replace на самом деле не изменяет историю - и не распространяется за пределы вашего репозитория. Он просто добавляет локальное перенаправление в ваш репозиторий с одного объекта на другой. Это означает, что никто другой не видит эффекта от этой замены - только вы.

Вот почему необходим filter-branch шаг. С git replace вы создаете точную копию с настроенными родительскими коммитами для корневого коммита; git filter-branch затем повторяет этот процесс для всех следующих коммитов. Вот где история фактически переписывается, чтобы вы могли ею поделиться.

Слияние ответов Аристотеля Пагальциса и Уве Кляйне-Кенига и комментария Ричарда Броноски.

git symbolic-ref HEAD refs/heads/newroot
git rm --cached -r .
git clean -f -d
# touch .gitignore && git add .gitignore # if necessary
git commit --allow-empty -m 'initial'
git rebase --onto newroot --root master
git branch -d newroot

(просто чтобы собрать все в одном месте)

Мне нравится ответ Аристотеля. Но обнаружено, что для большого репозитория (> 5000 коммитов) filter-branch работает лучше, чем rebase по нескольким причинам: 1) он быстрее 2) не требует вмешательства человека при конфликте слияния. 3) может переписывать теги - сохраняя их. Обратите внимание, что filter-branch работает, потому что нет вопросов о содержимом каждого коммита - оно точно такое же, как и до этого «перебазирования».

Мои шаги:

# 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 replace и git filter-branch - лучшее решение, чем использование git rebase:

• лучшая производительность
• проще и менее рискованно (вы можете проверять свой результат на каждом этапе и отменять то, что вы сделали ...)
• хорошо работать с несколькими ветками с гарантированным результатом

Идея заключается в следующем:

1. Создать новую пустую фиксацию в далеком прошлом
2. Замените старую корневую фиксацию на фиксацию точно так же, за исключением того, что новая корневая фиксация добавляется как родительская.
3. Убедитесь, что все в порядке, и запустите git filter-branch
4. Еще раз убедитесь, что все в порядке, и очистите ненужные файлы git.

Вот сценарий для первых двух шагов:

#!/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). Вы можете сравнить 2 и снова проверить, все ли в порядке. Если вас устраивает, удалите ненужные файлы:

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

Вы можете вернуться в свою ветку master и удалить временную ветку:

git checkout master
git branch -D new-root

Теперь все должно быть сделано;)

Я успешно использовал части ответа Аристотеля и Кента:

# first you need a new empty branch; let's call it `newroot`
git checkout --orphan newroot
git rm -rf .
git commit --allow-empty -m 'root commit'
git filter-branch --parent-filter \
'sed "s/^\$/-p <sha of newroot>/"' --tag-name-filter cat -- --all
# clean up
git checkout master
git branch -D newroot
# make sure your branches are OK first before this...
git for-each-ref --format="%(refname)" refs/original/ | \
xargs -n 1 git update-ref -d

Это также перезапишет все ветки (не только master) в дополнение к тегам.

Чтобы добавить пустую фиксацию в начало репозитория, если вы забыли создать пустую фиксацию сразу после "git init":

git rebase --root --onto $(git commit-tree -m 'Initial commit (empty)' 4b825dc642cb6eb9a060e54bf8d69288fbee4904)

git rebase --root --onto $emptyrootcommit

должно с легкостью справиться с задачей

Я был в восторге и написал «идемпотентную» версию этого красивого скрипта ... он всегда будет вставлять один и тот же пустой коммит, и если вы запустите его дважды, он не изменит хэши ваших коммитов каждый раз. Итак, вот мой взгляд на git-insert-empty-root:

#!/bin/sh -ev
# idempotence achieved!
tmp_branch=__tmp_empty_root
git symbolic-ref HEAD refs/heads/$tmp_branch
git rm --cached -r . || true
git clean -f -d
touch -d '1970-01-01 UTC' .
GIT_COMMITTER_DATE='1970-01-01T00:00:00 +0000' git commit \
  --date='1970-01-01T00:00:00 +0000' --allow-empty -m 'initial'
git rebase --committer-date-is-author-date --onto $tmp_branch --root master
git branch -d $tmp_branch

Стоит ли лишняя сложность? может и нет, но я воспользуюсь этим.

Это ДОЛЖНО также позволить выполнить эту операцию с несколькими клонированными копиями репо и получить те же результаты, поэтому они все еще совместимы ... тестирование ... да, работает, но также необходимо удалить и добавить свой снова пульты, например:

git remote rm origin
git remote add --track master user@host:path/to/repo

Чтобы переключить корневую фиксацию:

Сначала создайте фиксацию, которую хотите первым.

Во-вторых, измените порядок коммитов, используя:

git rebase -i --root

Появится редактор с коммитами до корневого коммита, например:

выберите 1234 старого корневого сообщения

выберите 0294 коммит посередине

выберите 5678 коммит, который хотите поместить в корень

Затем вы можете поместить желаемый коммит первым, поместив его в первую строку. В примере:

выберите 5678 коммит, который хотите поместить в корень

выберите 1234 старого корневого сообщения

выберите 0294 коммит посередине

Выйдите из редактора, порядок фиксации изменится.

PS: Чтобы изменить редактор, который использует git, запустите:

git config --global core.editor name_of_the_editor_program_you_want_to_use

Что ж, вот что я придумал:

# 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

Вот мой bash сценарий, основанный на ответе Кента с улучшениями:

• по завершении он проверяет исходную ветвь, а не только master;
• Я пытался избежать временной ветки, но git checkout --orphan работает только с ветвью, а не с состоянием с отсоединенной головкой, поэтому она проверяется достаточно долго, чтобы сделать новую корневую фиксацию, а затем удалить;
• он использует хэш нового корневого коммита во время filter-branch (Кент оставил там заполнитель для ручной замены);
• операция filter-branch перезаписывает только локальные ветки, но не удаленные
• метаданные автора и коммиттера стандартизированы, поэтому корневой коммит во всех репозиториях идентичен.

#!/bin/bash

# Save the current branch so we can check it out again later
INITIAL_BRANCH=`git symbolic-ref --short HEAD`
TEMP_BRANCH='newroot'

# Create a new temporary branch at a new root, and remove everything from the tree
git checkout --orphan "$TEMP_BRANCH"
git rm -rf .

# Commit this empty state with generic metadata that will not change - this should result in the same commit hash every time
export GIT_AUTHOR_NAME='nobody'
export GIT_AUTHOR_EMAIL='[email protected]'
export GIT_AUTHOR_DATE='2000-01-01T00:00:00+0000'
export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
export GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
git commit --allow-empty -m 'empty root'
NEWROOT=`git rev-parse HEAD`

# Check out the commit we just made and delete the temporary branch
git checkout --detach "$NEWROOT"
git branch -D "$TEMP_BRANCH"

# Rewrite all the local branches to insert the new root commit, delete the 
# original/* branches left behind, and check out the rewritten initial branch
git filter-branch --parent-filter "sed \"s/^\$/-p $NEWROOT/\"" --tag-name-filter cat -- --branches
git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
git checkout "$INITIAL_BRANCH"

Сочетание новейшего и лучшего. Никаких побочных эффектов, никаких конфликтов, сохранение тегов.

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 может испортиться, если другие ветки также не будут исправлены.

После ответа Аристотеля Пагальциса и других, но с использованием более простых команд

zsh% git checkout --orphan empty     
Switched to a new branch 'empty'
zsh% git rm --cached -r .
zsh% git clean -fdx
zsh% git commit --allow-empty -m 'initial empty commit'
[empty (root-commit) 64ea894] initial empty commit
zsh% git checkout master
Switched to branch 'master'
zsh% git rebase empty
First, rewinding head to replay your work on top of it...
zsh% git branch -d empty 
Deleted branch empty (was 64ea894).

Обратите внимание, что ваше репо не должно содержать никаких локальных изменений, ожидающих фиксации.
Я полагаю, что git checkout --orphan будет работать в новых версиях git.
Обратите внимание, что в большинстве случаев git status дает полезные подсказки.

Запустить новый репозиторий.

Установите дату обратно на желаемую дату начала.

Делайте все так, как вы хотите, настраивая системное время, чтобы отразить, когда вы хотели бы сделать это именно так. По мере необходимости извлекайте файлы из существующего репозитория, чтобы избежать ненужного набора текста.

Когда дойдете до сегодняшнего дня, поменяйте местами репозитории, и все готово.

Если вы просто сумасшедший (авторитетный), но достаточно умен (вероятно, потому, что вам нужно иметь определенное количество ума, чтобы придумывать такие сумасшедшие идеи), вы запишете процесс.

Это также сделает его приятнее, если вы решите, что через неделю вы хотите, чтобы прошлое произошло каким-то другим образом.

Я знаю, что этот пост старый, но эта страница - первая, когда гуглил "вставка фиксации git".

Зачем усложнять простые вещи?

У вас есть A-B-C, и вы хотите AB-Z-C.

1. git rebase -i trunk (или что-нибудь до B)
2. изменить выбор для редактирования в строке B
3. внесите изменения: git add ..
4. git commit (git commit --amend, который будет редактировать B, а не создавать Z)

[Вы можете сделать столько git commit, сколько хотите, чтобы вставить больше коммитов. Конечно, у вас могут возникнуть проблемы с шагом 5, но разрешение конфликта слияния с помощью git - это навык, которым вы должны обладать. Если нет, практикуйтесь!]

5. git rebase --continue

Просто, не правда ли?

Если вы понимаете git rebase, добавление «корневого» коммита не должно быть проблемой.

Удачи с git!