Ich habe vorher gefragt, wie die ersten beiden Commits in einem Git-Repository gequetscht werden sollen.

Die Lösungen sind zwar ziemlich interessant und nicht wirklich so verwirrend wie einige andere Dinge in Git, aber sie sind immer noch ein bisschen sprichwörtlich verletzt, wenn Sie den Vorgang während der Entwicklung Ihres Projekts viele Male wiederholen müssen.

Daher möchte ich lieber nur einmal Schmerzen haben und dann die standardmäßige interaktive Basis für immer verwenden können.

Was ich dann tun möchte, ist ein leeres anfängliches Commit, das nur zum Zweck der Ersten existiert. Kein Code, kein Nichts. Nehmen Sie einfach Platz ein, damit es die Basis für Rebase sein kann.

Meine Frage ist dann, ob ich bei einem vorhandenen Repository ein neues, leeres Commit vor dem ersten einfügen und alle anderen nach vorne verschieben kann.

Es gibt zwei Schritte, um dies zu erreichen:

1. Erstellen Sie ein neues leeres Commit
2. Schreiben Sie den Verlauf neu, um mit diesem leeren Commit zu beginnen

Wir werden das neue leere Commit der Einfachheit halber in einen temporären Zweig stellen newroot.

1. Erstellen Sie ein neues leeres Commit

Es gibt verschiedene Möglichkeiten, dies zu tun.

Verwenden Sie nur Sanitär

Der sauberste Ansatz besteht darin, Git's Sanitär zu verwenden, um direkt ein Commit zu erstellen, wodurch vermieden wird, dass die Arbeitskopie oder der Index berührt wird oder welcher Zweig ausgecheckt wird usw.

1. Erstellen Sie ein Baumobjekt für ein leeres Verzeichnis:

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

2. Wickeln Sie ein Commit darum:

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

3. Erstellen Sie einen Verweis darauf:

   git branch newroot $commit
   

Sie können den gesamten Vorgang natürlich in einen Einzeiler umwandeln, wenn Sie Ihre Shell gut genug kennen.

Ohne Sanitär

Mit regulären Porzellanbefehlen können Sie newrootohne guten Grund kein leeres Commit erstellen, ohne den Zweig auszuchecken und den Index und die Arbeitskopie wiederholt zu aktualisieren. Einige mögen dies jedoch leichter verstehen:

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

Beachten Sie, dass Sie bei sehr alten Versionen von Git, denen der --orphanWechsel zu fehlt checkout, die erste Zeile durch folgende ersetzen müssen:

git symbolic-ref HEAD refs/heads/newroot

2. Schreiben Sie den Verlauf neu, um mit diesem leeren Commit zu beginnen

Sie haben hier zwei Möglichkeiten: Neubasieren oder ein sauberes Umschreiben des Verlaufs.

Wiederherstellen

git rebase --onto newroot --root master

Dies hat den Vorteil der Einfachheit. Es werden jedoch auch der Name und das Datum des Committers bei jedem letzten Commit in der Verzweigung aktualisiert.

Bei einigen Edge-Case-Historien kann dies sogar aufgrund von Zusammenführungskonflikten fehlschlagen - trotz der Tatsache, dass Sie auf ein Commit zurückgreifen, das nichts enthält.

Geschichte neu schreiben

Der sauberere Ansatz besteht darin, den Zweig neu zu schreiben. Im Gegensatz zu mit git rebasemüssen Sie nachschlagen, von welchem ​​Commit Ihre Niederlassung ausgeht:

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

Das Umschreiben erfolgt natürlich im zweiten Schritt; Es ist der erste Schritt, der einer Erklärung bedarf. Was git replacetut , ist es Git sagt , dass , wenn es einen Verweis auf ein Objekt sieht man ersetzt wollen, Git statt auf dem Ersatz des Objekts aussehen soll.

Mit dem --graftSchalter sagen Sie etwas anderes als normal. Sie sagen, dass Sie noch kein Ersatzobjekt haben, aber Sie möchten das <currentroot>Festschreibungsobjekt durch eine exakte Kopie von sich selbst ersetzen , außer dass die übergeordneten Festschreibungen der Ersetzung die von Ihnen aufgelisteten sein sollten (dh die newrootFestschreibung) ). Anschließend git replacewird dieses Commit für Sie erstellt und dieses Commit als Ersatz für Ihr ursprüngliches Commit deklariert.

Wenn Sie nun a ausführen git log, werden Sie feststellen, dass die Dinge bereits so aussehen, wie Sie es möchten: Der Zweig beginnt bei newroot.

Beachten Sie jedoch, dass git replace der Verlauf dadurch weder geändert noch aus Ihrem Repository weitergegeben wird. Es wird lediglich eine lokale Umleitung zu Ihrem Repository von einem Objekt zu einem anderen hinzugefügt. Dies bedeutet, dass niemand sonst die Wirkung dieses Ersatzes sieht - nur Sie.

Deshalb ist der filter-branchSchritt notwendig. Mit git replaceerstellen Sie eine exakte Kopie mit angepassten übergeordneten Commits für das Root-Commit. git filter-branchWiederholt diesen Vorgang dann auch für alle folgenden Commits. Hier wird die Geschichte tatsächlich neu geschrieben, damit Sie sie teilen können.

Zusammenführung der Antworten von Aristoteles Pagaltzis und Uwe Kleine-König und des Kommentars von Richard Bronosky.

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

(nur um alles an einem Ort zu platzieren)

Ich mag Aristoteles 'Antwort. Es wurde jedoch festgestellt, dass ein Filterzweig für ein großes Repository (> 5000 Commits) aus mehreren Gründen besser funktioniert als eine Neubasis. 1) Er ist schneller. 2) Bei einem Zusammenführungskonflikt ist kein menschliches Eingreifen erforderlich. 3) Es kann die Tags umschreiben und sie beibehalten. Beachten Sie, dass die Filterverzweigung funktioniert, da keine Frage zum Inhalt jedes Commits besteht - es ist genau das gleiche wie vor dieser 'Rebase'.

Meine Schritte sind:

# 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

Beachten Sie, dass die Optionen '--tag-name-filter cat' bedeuten, dass Tags neu geschrieben werden, um auf die neu erstellten Commits zu verweisen.

Ich habe Teile der Antwort von Aristoteles und Kent erfolgreich verwendet:

# 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

Dadurch werden masterzusätzlich zu den Tags auch alle Zweige (nicht nur ) neu geschrieben.

git rebase --root --onto $emptyrootcommit

sollte den Trick leicht machen

Ich denke, dass die Verwendung von git replaceund git filter-brancheine bessere Lösung ist als die Verwendung von git rebase:

• bessere Leistung
• einfacher und weniger riskant (Sie können Ihr Ergebnis bei jedem Schritt überprüfen und rückgängig machen, was Sie getan haben ...)
• Arbeiten Sie gut mit mehreren Niederlassungen mit garantierten Ergebnissen

Die Idee dahinter ist:

• Erstellen Sie ein neues leeres Commit weit in der Vergangenheit
• Ersetzen Sie das alte Root-Commit durch ein genau ähnliches Commit, außer dass das neue Root-Commit als übergeordnetes Element hinzugefügt wird
• Stellen Sie sicher, dass alles wie erwartet ist, und führen Sie es aus git filter-branch
• Stellen Sie erneut sicher, dass alles in Ordnung ist, und bereinigen Sie die nicht mehr benötigten Git-Dateien

Hier ist ein Skript für die 2 ersten Schritte:

#!/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"

Sie können dieses Skript ohne Risiko ausführen (auch wenn es eine gute Idee ist, ein Backup zu erstellen, bevor Sie eine Aktion ausführen, die Sie noch nie zuvor durchgeführt haben;)). Wenn das Ergebnis nicht das erwartete ist, löschen Sie einfach die im Ordner erstellten Dateien .git/refs/replaceund versuchen Sie es erneut. )

Nachdem Sie überprüft haben, ob der Status des Repositorys Ihren Erwartungen entspricht, führen Sie den folgenden Befehl aus, um den Verlauf aller Zweige zu aktualisieren :

git filter-branch -- --all

Jetzt müssen Sie zwei Historien sehen, die alte und die neue ( filter-branchweitere Informationen finden Sie in der Hilfe ). Sie können die 2 vergleichen und erneut prüfen, ob alles in Ordnung ist. Wenn Sie zufrieden sind, löschen Sie die nicht mehr benötigten Dateien:

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

Sie können zu Ihrem masterZweig zurückkehren und den temporären Zweig löschen:

git checkout master
git branch -D new-root

Jetzt sollte alles erledigt sein;)

Ich war aufgeregt und habe eine 'idempotente' Version dieses netten Skripts geschrieben ... es wird immer das gleiche leere Commit einfügen, und wenn Sie es zweimal ausführen, werden Ihre Commit-Hashes nicht jedes Mal geändert. Also, hier ist meine Einstellung zu 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

Lohnt sich die zusätzliche Komplexität? vielleicht nicht, aber ich werde diesen verwenden.

Dies sollte es auch ermöglichen, diesen Vorgang für mehrere geklonte Kopien des Repos durchzuführen und die gleichen Ergebnisse zu erzielen, damit sie weiterhin kompatibel sind ... Testen ... ja, es funktioniert, aber Sie müssen auch Ihre löschen und hinzufügen wieder Fernbedienungen, zB:

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

So fügen Sie zu Beginn eines Repositorys ein leeres Commit hinzu, wenn Sie vergessen haben, unmittelbar nach "git init" ein leeres Commit zu erstellen:

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

Folgendes habe ich mir ausgedacht:

# 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

Hier ist mein bashSkript basierend auf Kents Antwort mit Verbesserungen:

• es überprüft den ursprünglichen Zweig, nicht nur master, wenn es fertig ist;
• Ich habe versucht, die temporäre Verzweigung zu vermeiden, git checkout --orphanarbeite aber nur mit einer Verzweigung, nicht mit einem Status mit getrenntem Kopf. Daher wurde sie lange genug ausgecheckt, um das neue Root-Commit durchzuführen, und dann gelöscht.
• Es verwendet den Hash des neuen Root-Commits während des filter-branch(Kent hat dort einen Platzhalter zum manuellen Ersetzen gelassen).
• Die filter-branchOperation schreibt nur die lokalen Zweige neu, nicht auch die Fernbedienungen
• Die Metadaten für Autor und Committer sind standardisiert, sodass das Root-Commit über alle Repositorys hinweg identisch ist.

#!/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='nobody@example.org'
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"

So wechseln Sie das Root-Commit:

Erstellen Sie zunächst das gewünschte Commit als erstes.

Zweitens ändern Sie die Reihenfolge der Commits mit:

git rebase -i --root

Ein Editor mit den Commits wird bis zum Root-Commit angezeigt.

Wählen Sie 1234 alte Root-Nachricht

Wählen Sie 0294 Ein Commit in der Mitte

Wählen Sie 5678 Commit aus, das Sie an der Wurzel ablegen möchten

Sie können dann das gewünschte Commit zuerst setzen, indem Sie es in die erste Zeile setzen. Im Beispiel:

Wählen Sie 5678 Commit aus, das Sie an der Wurzel ablegen möchten

Wählen Sie 1234 alte Root-Nachricht

Wählen Sie 0294 Ein Commit in der Mitte

Beenden Sie den Editor. Die Festschreibungsreihenfolge hat sich geändert.

PS: Um den Editor zu ändern, den Git verwendet, führen Sie Folgendes aus:

git config --global core.editor name_of_the_editor_program_you_want_to_use

Das Neueste und Beste kombinieren. Keine Nebenwirkungen, keine Konflikte, Tags behalten.

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

Beachten Sie, dass Sie auf GitHub CI-Ausführungsdaten verlieren und PR möglicherweise durcheinander kommt, wenn nicht auch andere Zweige repariert werden.

Folgende Antwort Aristoteles Pagaltzis und andere, aber mit einfacheren Befehlen

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).

Beachten Sie, dass Ihr Repo keine lokalen Änderungen enthalten sollte, die darauf warten, festgeschrieben zu werden.
Note git checkout --orphanwird bei neuen Versionen von Git funktionieren, denke ich.
Beachten Sie, dass die meiste Zeit git statusnützliche Hinweise gibt.

Starten Sie ein neues Repository.

Setzen Sie Ihr Datum auf das gewünschte Startdatum zurück.

Tun Sie alles so, wie Sie es sich gewünscht haben, und passen Sie die Systemzeit an, um zu reflektieren, wann Sie es gewünscht haben. Ziehen Sie nach Bedarf Dateien aus dem vorhandenen Repository, um unnötiges Tippen zu vermeiden.

Wenn Sie heute ankommen, tauschen Sie die Repositorys aus und Sie sind fertig.

Wenn Sie nur verrückt (etabliert), aber einigermaßen intelligent sind (wahrscheinlich, weil Sie eine gewisse Menge an Intelligenz benötigen, um sich verrückte Ideen wie diese auszudenken), werden Sie den Prozess per Skript ausführen.

Das macht es auch schöner, wenn Sie entscheiden, dass die Vergangenheit in einer Woche auf andere Weise geschehen soll.

Ich weiß, dass dieser Beitrag alt ist, aber diese Seite ist die erste, wenn "Google einfügen" gegoogelt wird.

Warum einfache Dinge kompliziert machen?

Sie haben ABC und möchten ABZC.

1. git rebase -i trunk (oder irgendetwas vor B)
2. Ändern Sie die Auswahl, um sie in der B-Zeile zu bearbeiten
3. Nehmen Sie Ihre Änderungen vor: git add ..
4. git commit( git commit --amendwodurch B bearbeitet und nicht Z erstellt wird)

[Sie können hier so viele festlegen, git commitwie Sie möchten, um weitere Commits einzufügen. Natürlich können Sie Probleme mit Schritt 5 haben, aber das Lösen von Zusammenführungskonflikten mit Git ist eine Fähigkeit, die Sie haben sollten. Wenn nicht, üben Sie!]

5. git rebase --continue

Einfach, nicht wahr?

Wenn Sie verstehen git rebase, sollte das Hinzufügen eines Root-Commits kein Problem sein.

Viel Spaß mit git!