Gibt es in Git eine einfache Möglichkeit, einen nicht verwandten Zweig in ein Repository einzuführen?

Question

Als ich heute einem Freund bei einem Git-Problem half, musste ich eine Zweig einführen, der völlig getrennt von der master Zweigstelle. Der Inhalt dieser Verzweigung hatte tatsächlich einen anderen Ursprung als das, was entwickelt worden war. master Zweig, aber sie sollten in den master Zweigstelle zu einem späteren Zeitpunkt.

Ich erinnerte mich nach der Lektüre von John Wiegleys Git von unten oben wie Zweige sind im Wesentlichen ein Etikett für eine Übergabe, die einer bestimmten Konvention folgt und wie ein Commit mit einem Baum von Dateien und optional zu übergeordneten Commits. Wir haben einen elternlosen Commit zum bestehenden Repository mit Hilfe von Git zu erstellen:

Wir sind also alle Dateien im Index losgeworden ...

$ git rm -rf .

... extrahierte Verzeichnisse und Dateien aus einem Tarball und fügte diese dem Index hinzugefügt ...

$ git add .

... und ein Baumobjekt erstellt ...

$ git write-tree

( git-write-tree hat uns die sha1sum des erstellten Baumobjekts mitgeteilt).

Dann haben wir den Baum committed, ohne die übergeordneten Commits anzugeben...

$ echo "Imported project foo" | git commit-tree $TREE

( git-commit-tree die Sha1-Summe des erstellten Commit-Objekts).

... und einen neuen Zweig erstellt, der auf unsere neu erstellte Übergabe verweist.

$ git update-ref refs/heads/other-branch $COMMIT

Schließlich kehrten wir zum master Zweigstelle, um die Arbeit dort fortzusetzen.

$ git checkout -f master

Dies scheint wie geplant funktioniert zu haben. Aber das ist eindeutig nicht die Art von Verfahren, das ich jemandem empfehlen würde, der gerade erst anfängt Git zu verwenden, um es milde auszudrücken. Gibt es einen einfacheren Weg zur Erstellung einer neuen Zweig zu erstellen, der nichts mit dem zu tun hat, was bisher bisher im Projektarchiv passiert ist?

Answer 1

Github hat eine Funktion namens Projekt-Seiten wo Sie einen bestimmten benannten Zweig in Ihrem Projekt erstellen können, um Dateien bereitzustellen, die von Github bereitgestellt werden. Die Anweisungen lauten wie folgt:

$ cd /path/to/fancypants
$ git symbolic-ref HEAD refs/heads/gh-pages
$ rm .git/index
$ git clean -fdx

Nun haben Sie ein leeres Repository, dem Sie Ihre neuen Inhalte hinzufügen können.

Answer 2

Manchmal möchte ich einfach nur einen leeren Zweig im Projekt erstellen und dann sofort mit der Arbeit beginnen, dann führe ich einfach folgenden Befehl aus:

git checkout --orphan unrelated.branch.name
git rm --cached -r .
echo "init unrelated branch" > README.md
git add README.md
git commit -m "init unrelated branch"

Answer 3

Wenn Ihr vorhandener Inhalt bereits committed wurde, können Sie ihn jetzt (Git 2.18 Q2 2018) in einen eigenen neuen verwaisten Zweig extrahieren, da die Implementierung von " git rebase -i --root " wurde aktualisiert und verwendet nun die Sequenzer-Maschinerie mehr zu nutzen.

Dieser Sequenzer ist jetzt derjenige, der die gesamte Topologie des Commit-Graphen an einen anderen Ort zu verpflanzen .

Siehe Commit 8fa6eea , 9c85a1c übertragen , ebddf39 übertragen , Commit 21d0764 , d87d48b übertragen , Übergabe ba97aea (03. Mai 2018) von Johannes Schindelin ( dscho ) .
(Zusammengefasst von Junio C. Hamano -- gitster -- en c5aa4bc übergeben , 30. Mai 2018)

Sequencer: Einführung neuer Root-Commits ermöglichen

Im Rahmen der neuen --rebase-merges m speziell entwickelt wurde, um eine Änderung der bestehenden Verzweigungstopologie zu ermöglichen großzügig zu ändern, ein Benutzer möchte vielleicht Commits in einen völlig neuen Zweig extrahieren Zweig extrahieren, der mit einer neu erstellten Root-Übertragung beginnt .

Dies ist nun möglich, indem Sie den folgenden Befehl einfügen reset [new root] b pick den Commit, der ein Root-Commit werden soll. Beispiel:

reset [new root]
pick 012345 a commit that is about to become a root commit
pick 234567 this commit will have the previous one as parent

Dies steht nicht im Widerspruch zu anderen Verwendungen des reset c [new root] ist nicht (Teil) eines gültigen Referenznamens: sowohl die öffnende Klammer als auch das Leerzeichen sind in ref-Namen illegal.

Answer 4

Die Erstellung eines separaten Repositorys hat bei mir gut funktioniert. Ich musste mir keine Gedanken über einen <start_point> machen.

1. Erstellen Sie ein neues leeres Projektarchiv an einem anderen Ort.
2. Benennen Sie den Master-Zweig in etwas anderes als Master um, z. B. gh-pages
3. Beginnen Sie mit Ihrer Arbeit als Waise.
4. Commitieren Sie Ihre Arbeit in den einzigen Zweig des neuen Repositorys.
5. Verschieben Sie den neuen Zweig in das gleiche entfernte Repository, das den ursprünglichen Master-Zweig enthält.

Diese Methode wird auf erwähnt:

• https://gitlab.com/tortoisegit/tortoisegit/-/issues/1090#note_77403778
• https://gist.github.com/chrisjacob/1086274/382ef1ccc22b57b9b1f0e3a362b39e806b9ba04c

Answer 5

Dieses Skript finden Sie unter http://wingolog.org/archives/2008/10/14/merging-in-unrelated-git-branches und es funktioniert sehr gut!

#!/bin/bash

set -e

if test -z "$2" -o -n "$3"; then
    echo "usage: $0 REPO BRANCHNAME" >&2
    exit 1
fi

repo=$1
branch=$2

git fetch "$repo" "$branch"

head=$(git rev-parse HEAD)
fetched=$(git rev-parse FETCH_HEAD)
headref=$(git rev-parse --symbolic-full-name HEAD)

git checkout $fetched .

tree=$(git write-tree)

newhead=$(echo "merged in branch '$branch' from $repo" | git commit-tree $tree -p $head -p $fetched)
git update-ref $headref $newhead $head
git reset --hard $headref