wake-up-neo.com

Was sind die Unterschiede zwischen Git Branch, Fork, Fetch, Merge, Rebase und Clone?

Ich möchte den Unterschied zwischen einem Zweig, einer Gabel und einem Klon in Git verstehen.

Ebenso, was bedeutet es, wenn ich ein git fetch im Gegensatz zu einem git pull?

Was bedeutet rebase im Vergleich zu merge?

Wie kann ich einzelne Commits zusammen quetschen?

Wie werden sie verwendet, warum werden sie verwendet und was repräsentieren sie?

Wie spielt GitHub eine Rolle?

489
jackiekazil

Ein Klon ist einfach eine Kopie eines Repositorys. An der Oberfläche ist das Ergebnis gleichbedeutend mit svn checkout, wo Sie Quellcode aus einem anderen Repository herunterladen. Der Unterschied zwischen zentralisierten VCS wie Subversion und DVCS wie Git besteht darin, dass Sie in Git beim Klonen das gesamte Quellrepository einschließlich des gesamten Verlaufs und der Verzweigungen kopieren. Sie haben jetzt ein neues Repository auf Ihrem Computer und alle Commits, die Sie vornehmen, werden in dieses Repository verschoben. Niemand wird Änderungen sehen, bis Sie diese Commits in ein anderes Repository (oder das ursprüngliche Repository) verschieben oder bis jemand Commits aus Ihrem Repository abruft, sofern es öffentlich zugänglich ist.

Ein Zweig ist etwas, das sich in einem Repository befindet. Konzeptionell ist es ein Entwicklungsstrang. Normalerweise haben Sie einen Hauptzweig, aber Sie können auch einen Zweig haben, in dem Sie an einem Feature xyz arbeiten, und einen anderen, um den Fehler abc zu beheben. Wenn Sie einen Zweig ausgecheckt haben, bleiben alle von Ihnen getätigten Festschreibungen in diesem Zweig und werden erst dann mit anderen Zweigen geteilt, wenn Sie sie mit dem betreffenden Zweig zusammenführen oder auf diesen aufbauen. Natürlich scheint Git etwas seltsam, wenn es um Verzweigungen geht, bis Sie sich das zugrunde liegende Modell ansehen, wie Verzweigungen implementiert werden. Anstatt es selbst zu erklären (ich habe bereits zu viel gesagt, denke nach), werde ich auf die "Informatik" -Erläuterung verweisen, wie Git-Modelle Verzweigungen und Commits erstellen, die von der Git-Website stammen:

http://eagain.net/articles/git-for-computer-scientists/

Eine Gabel ist eigentlich kein Git-Konzept, sondern eher eine politische/soziale Idee. Das heißt, wenn einige Leute mit dem Ablauf eines Projekts nicht zufrieden sind, können sie den Quellcode nehmen und ihn unabhängig von den ursprünglichen Entwicklern selbst bearbeiten. Das wäre eine Gabelung. Git macht das Forken einfach, da jeder Benutzer bereits eine eigene "Master" -Kopie des Quellcodes hat. Dies ist so einfach wie das Trennen von Beziehungen zu den ursprünglichen Projektentwicklern und erfordert keinen Export des Verlaufs aus einem freigegebenen Repository, wie Sie es möglicherweise mit SVN zu tun haben .

BEARBEITEN: Da mir die moderne Definition von "fork", wie sie von Websites wie GitHub verwendet wird, nicht bekannt war, werfen Sie bitte einen Blick auf die Kommentare und auch auf Michael Durrants Antwort unter meinen, um weitere Informationen zu erhalten.

361
siride

Git

Diese Antwort enthält GitHub, da viele Leute auch danach gefragt haben.

Lokale Speicherorte

Git (lokal) hat ein Verzeichnis (.git), In das Sie Ihre Dateien übertragen, und dies ist Ihr 'lokales Repository'. Dies unterscheidet sich von Systemen wie SVN, bei denen Sie das Remote-Repository sofort hinzufügen und festschreiben.

Git speichert jede Version einer Datei, die sich ändert, indem die gesamte Datei gespeichert wird. Diesbezüglich unterscheidet es sich auch von SVN, da Sie zu jeder einzelnen Version wechseln können, ohne sie durch Delta-Änderungen neu zu erstellen.

Git 'sperrt' Dateien überhaupt nicht und vermeidet daher die 'exklusive Sperre' für eine Bearbeitung (ältere Systeme wie pvcs fallen ein), sodass alle Dateien immer bearbeitet werden können, auch wenn sie offline sind. Das Zusammenführen von Dateiänderungen (innerhalb derselben Datei!) Zu einem Remote-Repository wie GitHub ist eine erstaunliche Aufgabe. Sie müssen nur dann manuelle Änderungen vornehmen (dh eine Datei bearbeiten), wenn zwei Änderungen dieselbe Codezeile (n) betreffen.


Geäst

Mit Zweigen können Sie den Hauptcode (den 'Master'-Zweig) beibehalten, eine Kopie (einen neuen Zweig) erstellen und dann in diesem neuen Zweig arbeiten. Wenn die Arbeit eine Weile dauert oder der Master viele Aktualisierungen erhält, seit der Zweig erstellt wurde, sollte das Zusammenführen oder Neu-Basieren (häufig aus Gründen des besseren Verlaufs und zur einfacheren Lösung von Konflikten bevorzugt) mit dem Master-Zweig durchgeführt werden. Wenn Sie fertig sind, führen Sie die in der Verzweigung vorgenommenen Änderungen wieder im Master-Repository zusammen. Viele Organisationen verwenden Zweige für jede Arbeit, unabhängig davon, ob es sich um ein Feature, einen Bug oder einen Job handelt. Andere Organisationen verwenden Zweige nur für wichtige Änderungen, z. B. Versionsupgrades.

Gabelung: Mit einer Verzweigung steuern und verwalten Sie die Verzweigung, während mit einer Gabelung eine andere Person die Annahme des Codes steuert.

Allgemein gesagt gibt es zwei Hauptansätze, um Zweige zu machen. Die erste besteht darin, die meisten Änderungen in der Master-Verzweigung beizubehalten und nur Verzweigungen für größere und länger laufende Objekte wie etwa Versionsänderungen zu verwenden, bei denen zwei Verzweigungen für unterschiedliche Anforderungen verfügbar sein sollen. Die zweite Möglichkeit besteht darin, dass Sie für jede Featureanforderung, jeden Bugfix oder jeden Job eine Verzweigung erstellen und dann manuell entscheiden, wann diese Verzweigungen tatsächlich in der Hauptverzweigung zusammengefasst werden sollen. Obwohl dies mühsam klingt, ist dies ein gängiger Ansatz, den ich derzeit verwende und empfehle, da der Master-Zweig sauberer bleibt und der Master, den wir in die Produktion befördern, sodass wir nur vollständigen, getesteten Code über das Rebasing und verwenden möchten Zusammenlegung von Zweigen.

Die Standardmethode, um eine Verzweigung 'in' Master zu bringen, ist ein merge. Zweige können auch "umbasiert" werden, um den Verlauf zu "bereinigen". Dies hat keinen Einfluss auf den aktuellen Status und wird durchgeführt, um eine "sauberere" Historie zu erstellen.

Grundsätzlich ist die Idee, dass Sie von einem bestimmten Punkt (in der Regel vom Master) verzweigt sind. Seit Sie verzweigt sind, hat sich 'master' von diesem Verzweigungspunkt aus vorwärtsbewegt. Es wird "sauberer" (leichter zu lösen und der Verlauf wird leichter zu verstehen sein), wenn alle Änderungen, die Sie in einem Zweig vorgenommen haben, gegen den aktuellen Status des Masters mit all seinen neuesten Änderungen gespielt werden. Der Prozess ist also: Speichern Sie die Änderungen; Holen Sie sich den 'neuen' Master und wenden Sie die Änderungen erneut an (dies ist der Rebase-Teil). Beachten Sie, dass ein erneutes Binden genau wie ein Zusammenführen zu Konflikten führen kann, die Sie manuell lösen müssen (d. H. Bearbeiten und beheben).

Eine Richtlinie zu beachten:
Nur zurücksetzen, wenn der Zweig lokal ist und Sie ihn noch nicht auf Remote verschoben haben!
Dies liegt hauptsächlich daran, dass das Umbasieren die Geschichte, die andere Leute sehen, verändern kann, einschließlich ihrer eigenen Verpflichtungen.

Filialen verfolgen

Dies sind die Zweige mit dem Namen Origin/branch_name (Im Gegensatz zu nur branch_name). Wenn Sie den Code zu/von Remote-Repositories verschieben und ziehen, ist dies der Mechanismus, über den dies geschieht. Wenn Sie beispielsweise git Push Einen Zweig mit dem Namen building_groups Erstellen, wechselt Ihr Zweig zuerst zu Origin/building_groups Und dann zum Remote-Repository. Wenn Sie einen git fetch building_groups - Befehl ausführen, wird die abgerufene Datei in Ihrem Origin/building_groups - Zweig abgelegt. Anschließend können Sie diesen Zweig in Ihrer lokalen Kopie zusammenführen. Unsere Praxis besteht darin, immer einen git fetch Und einen manuellen Merge durchzuführen und nicht nur einen git pull (Was beides in einem Schritt erledigt).

Neue Zweige holen.

Neue Zweige bekommen: Am Anfang eines Klons haben Sie alle Zweige. Wenn andere Entwickler jedoch Zweige hinzufügen und diese an die Remote-Einheit übertragen, muss es eine Möglichkeit geben, diese Zweige und ihre Namen zu kennen, damit sie lokal abgerufen werden können. Dies erfolgt über einen git fetch, Der alle neuen und geänderten Zweige unter Verwendung der Verfolgungszweige (z. B. Origin/) In das lokale Repository bringt. Sobald fetched ist, kann man git branch --remote, Um die Verfolgungszweige aufzulisten, und git checkout [branch], Um tatsächlich zu einem bestimmten zu wechseln.

Zusammenführen

Beim Zusammenführen werden Codeänderungen aus verschiedenen Zweigen oder aus verschiedenen Versionen desselben Zweigs kombiniert (z. B. wenn ein lokaler Zweig und ein Remote-Zweig nicht synchron sind). Wenn eine Arbeit in einem Zweig entwickelt wurde und die Arbeit abgeschlossen, fertig und getestet ist, kann sie in den Zweig master eingefügt werden. Dies geschieht mit git checkout master, Um zum Zweig master zu wechseln, dann mit git merge your_branch. Durch das Zusammenführen werden alle unterschiedlichen Dateien und sogar unterschiedliche Änderungen an denselben Dateien zusammengeführt. Dies bedeutet, dass der Code in den Dateien geändert wird, um alle Änderungen zusammenzuführen.

Wenn Sie checkout von master ausführen, wird außerdem empfohlen, einen git pull Origin master Durchzuführen, um die neueste Version des Remote-Masters in Ihrem lokalen Master zusammenzuführen. Wenn sich der entfernte Master geändert hat, d. H. moved forward, Sehen Sie Informationen, die dies während dieses git pull Widerspiegeln. Wenn dies der Fall ist (Master geändert), wird empfohlen, git checkout your_branch Und dann rebase den Master zu verwenden, damit Ihre Änderungen tatsächlich über dem 'neuen' Master wiedergegeben werden. Dann würden Sie fortfahren, den Master auf den neuesten Stand zu bringen, wie im nächsten Absatz gezeigt.

Wenn keine Konflikte vorliegen, werden die neuen Änderungen dem Master hinzugefügt. Wenn Konflikte vorliegen, bedeutet dies, dass dieselben Dateien Änderungen an ähnlichen Codezeilen aufweisen, die nicht automatisch zusammengeführt werden können. In diesem Fall meldet git merge new_branch, Dass Konflikte zu lösen sind. Sie lösen sie auf, indem Sie die Dateien (die beide Änderungen enthalten) bearbeiten, die gewünschten Änderungen auswählen, die Zeilen der nicht gewünschten Änderungen buchstäblich löschen und die Datei dann speichern. Die Änderungen sind mit Trennzeichen wie ======== Und <<<<<<<< Gekennzeichnet.

Sobald Sie alle Konflikte gelöst haben, werden Sie diese Änderungen erneut git add Und git commit Durchführen, um die Zusammenführung fortzusetzen (Sie erhalten während dieses Vorgangs Feedback von git, das Sie anleitet).

Wenn der Prozess nicht gut funktioniert, werden Sie feststellen, dass git merge --abort Sehr praktisch ist, um Dinge zurückzusetzen.

Interaktives Umbasieren und Quetschen/Umordnen/Entfernen von Commits

Wenn Sie in vielen kleinen Schritten gearbeitet haben, z. B. jeden Tag Code als "Work-in-Progress" festschreiben, möchten Sie diese vielen kleinen Festschreibungen möglicherweise in ein paar größere Festschreibungen "quetschen". Dies kann besonders nützlich sein, wenn Sie Codeüberprüfungen mit Kollegen durchführen möchten. Sie möchten nicht alle 'Schritte', die Sie unternommen haben (über Commits), wiederholen. Sie möchten lediglich sagen, dass hier der Endeffekt (Diff) aller meiner Änderungen für diese Arbeit in einem Commit vorliegt.

Der Schlüsselfaktor für die Beurteilung, ob dies zu tun ist, ist, ob die mehreren Festschreibungen gegen dieselbe Datei oder gegen mehrere Dateien gerichtet sind (in diesem Fall ist es besser, Festschreibungen zu quetschen). Dies erfolgt mit dem interaktiven Tool zum erneuten Basieren. Mit diesem Tool können Sie Commits quetschen, Commits löschen, Nachrichten umformulieren usw. Beispiel: git rebase -i HEAD~10 ( Hinweis: Das ist ein ~, Kein -) bringt Folgendes hervor:

interactive rebasing in Git

Seien Sie jedoch vorsichtig und gehen Sie vorsichtig mit diesem Werkzeug um. Führen Sie jeweils ein Squash/Löschen/Neuanordnen durch, beenden und speichern Sie das Commit und geben Sie das Tool erneut ein. Wenn Commits nicht zusammenhängend sind, können Sie sie neu anordnen (und dann nach Bedarf quetschen). Sie können hier auch tatsächlich Commits löschen, aber Sie müssen wirklich sicher sein, was Sie tun, wenn Sie das tun!

Gabeln

Es gibt zwei Hauptansätze für die Zusammenarbeit in Git-Repositorys. Das erste, das oben beschrieben wurde, erfolgt direkt über Zweige, die von Personen gezogen und von/nach gedrückt werden. Diese Mitarbeiter haben ihre SSH-Schlüssel im Remote-Repository registriert. Dadurch können sie direkt in dieses Repository pushen. Der Nachteil ist, dass Sie die Liste der Benutzer pflegen müssen. Der andere Ansatz - das Forken - ermöglicht es jedem, das Repository zu "forken" und im Grunde genommen eine lokale Kopie in seinem eigenen Git-Repository-Konto zu erstellen. Sie können dann Änderungen vornehmen und, wenn sie fertig sind, eine "Pull-Anfrage" senden (es handelt sich eigentlich eher um eine "Push" - und eine "Pull" -Anfrage für den eigentlichen Repository-Betreuer), um den Code zu akzeptieren.

Bei dieser zweiten Methode, bei der Gabeln verwendet werden, muss nicht eine Benutzerliste für das Repository erstellt werden.


GitHub

GitHub (ein Remote-Repository) ist eine Remote-Quelle, an die Sie normalerweise die festgeschriebenen Änderungen übertragen und abrufen, wenn Sie über ein solches Repository verfügen (oder zu diesem hinzugefügt werden), sodass lokal und remote tatsächlich ziemlich unterschiedlich sind. Eine andere Möglichkeit, sich ein Remote-Repository vorzustellen, besteht darin, dass es sich um eine Verzeichnisstruktur .git Handelt, die sich auf einem Remote-Server befindet.

Wenn Sie "Fork" - in der GitHub-Webbrowser-GUI können Sie auf diese Schaltfläche klicken Image of fork button - Sie erstellen eine Kopie ("Klon") des Codes in Ihrem GitHub-Konto. Dies kann beim ersten Mal etwas subtil sein. Überprüfen Sie daher immer, unter welchem ​​Repository eine Codebasis aufgeführt ist - entweder der ursprüngliche Eigentümer oder "Forked From", und Sie haben beispielsweise Folgendes vor:

Image of name of forked repository

Sobald Sie die lokale Kopie haben, können Sie Änderungen vornehmen, wie Sie möchten (indem Sie sie auf einen lokalen Computer ziehen und schieben). Wenn Sie fertig sind, senden Sie eine Pull-Anfrage an den ursprünglichen Repository-Besitzer/Administrator (klingt ausgefallen, aber tatsächlich klicken Sie einfach darauf: Image of pull request button) und sie ziehen es hinein.

Für ein Team, das gemeinsam an Code arbeitet, ist es üblich, das Repository zu klonen (klicken Sie im Hauptbildschirm des Repository auf das Symbol "Kopieren"). Geben Sie dann lokal git clone Ein und fügen Sie es ein. Dadurch werden Sie lokal eingerichtet und können auch per Push und Pull zum (gemeinsam genutzten) GitHub-Speicherort wechseln.

Klone

Wie im Abschnitt über GitHub angegeben, ist ein Klon eine Kopie eines Repositorys. Wenn Sie ein Remote-Repository haben, geben Sie den Befehl git clone Für dessen URL ein und erhalten dann eine lokale Kopie oder einen Klon des Repositorys. Dieser Klon hat alles , die Dateien, den Hauptzweig, die anderen Zweige, alle vorhandenen Commits, den gesamten Shebang. Es ist dieser Klon, gegen den Sie Ihre Adds und Commits ausführen, und das Remote-Repository selbst ist der Ort, an den Sie diese Commits senden. Es ist dieses lokale/entfernte Konzept, das Git (und ähnliche Systeme wie Mercurial) zu einem DVCS ( Distributed Version Control System) macht, im Gegensatz zu den anderen herkömmliche CVSs (Code Versioning Systems) wie SVN, PVCS, CVS usw., bei denen Sie ein Commit direkt zum Remote-Repository ausführen.

Visualisierung

Visualisierung der Kernkonzepte finden Sie unter
http://marklodato.github.com/visual-git-guide/index-en.html und
http://ndpsoftware.com/git-cheatsheet.html#loc=index

Wenn Sie eine visuelle Darstellung der Funktionsweise der Änderungen wünschen, können Sie das visuelle Tool gitg (gitx für macOS) nicht mit einer GUI übertreffen, die ich 'die U-Bahn-Karte' nenne (insb Londoner U-Bahn), großartig, um zu zeigen, wer was getan hat, wie sich die Dinge verändert haben, auseinander gegangen sind und verschmolzen sind usw.

Sie können damit auch Ihre Änderungen hinzufügen, festschreiben und verwalten!

Image of gitg/gitx interface

Obwohl gitg/gitx relativ gering ist, nimmt die Anzahl der GUI-Tools weiter zu. Viele Mac-Benutzer verwenden gitx von Brotherbard, und für Linux ist smart-git mit einer intuitiven und dennoch leistungsstarken Oberfläche eine großartige Option:

Image of smart-git GUI

Beachten Sie, dass Sie selbst mit einem GUI-Tool wahrscheinlich viele Befehle in der Befehlszeile ausführen werden.

Dafür habe ich die folgenden Aliase in meiner ~/.bash_aliases - Datei (die für jede Terminalsitzung aus meiner ~/.bashrc - Datei aufgerufen wird):

# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias Gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard Origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git Push '

UND ich habe die folgenden "Git Aliase" in meiner ~/.gitconfig Datei - warum haben diese?
Damit der Verzweigungsabschluss (mit der TAB-Taste) funktioniert!

Das sind also:

[alias]
  co = checkout
  cob = checkout -b

Anwendungsbeispiel: git co [branch] <- Das Ausfüllen der Tabs für Zweige funktioniert.

GUI-Lernwerkzeug

Sie können https://learngitbranching.js.org/ nützlich finden, um einige der Grundkonzepte zu lernen. Bildschirmfoto: enter image description here
Video: https://youtu.be/23JqqcLPss

Endlich 7 wichtige Lebensretter!

  1. Sie nehmen Änderungen vor, fügen sie hinzu und schreiben sie fest (aber drücken Sie nicht) und dann oh! Sie erkennen, dass Sie im Meister sind!

    git reset [filename(s)]
    git checkout -b [name_for_a_new_branch]
    git add [file(s)]
    git commit -m "A useful message"
    
    Voila!  You've moved that 'master' commit to its own branch !
    
  2. Sie vermasseln einige Dateien, während Sie in einer lokalen Filiale arbeiten, und möchten einfach zu dem zurückkehren, was Sie beim letzten Mal mit einem git pull Gemacht haben:

    git reset --hard Origin/master  # You will need to be comfortable doing this!
    
  3. Sie nehmen Änderungen lokal vor, Sie bearbeiten ein halbes Dutzend Dateien und dann, oh Mist, befinden Sie sich immer noch im Master-Zweig (oder einem anderen Zweig):

    git checkout -b new_branch_name  # just create a new branch
    git add .                      # add the changes files
    git commit -m"your message"    # and commit them
    
  4. Sie vermasseln eine bestimmte Datei in Ihrem aktuellen Zweig und möchten diese Datei im Grunde genommen "zurücksetzen" (Änderungen verlieren), damit Sie feststellen können, wie sie das letzte Mal aus dem Remote-Repository abgerufen wurde:

    git checkout your/directories/filename
    

    Dadurch wird die Datei tatsächlich zurückgesetzt (wie bei vielen Git-Befehlen ist der Name für das, was sie hier ausführt, nicht gut).

  5. Sie nehmen einige Änderungen lokal vor und möchten sicherstellen, dass Sie sie nicht verlieren, während Sie einen git reset Oder rebase ausführen: Ich mache häufig eine manuelle Kopie des gesamten Projekts (cp -r ../my_project ~/) wenn ich nicht sicher bin, ob ich in Git Fehler machen oder wichtige Änderungen verlieren könnte.

  6. Sie basteln um, aber die Dinge geraten durcheinander:

    git rebase --abort # To abandon interactive rebase and merge issues
    
  7. Fügen Sie Ihren Git-Zweig zu Ihrer PS1 - Eingabeaufforderung hinzu (siehe https://unix.stackexchange.com/a/127800/1004 ), z.

    Image of Prompt

    Der Zweig ist Selenium_rspec_conversion.

520
Michael Durrant

Hier ist Oliver Steeles Bild, wie alles zusammenpasst:

enter image description here

142
Contango

Fork Vs. Klonen - zwei Wörter, die beide Kopie bedeuten

Bitte beachten Sie diese Diagramm. (Ursprünglich von http://www.dataschool.io/content/images/2014/Mar/github1.png ).

.-------------------------.     1. Fork     .-------------------------.
| Your GitHub repo        | <-------------- | Joe's GitHub repo       |
| github.com/you/coolgame |                 | github.com/joe/coolgame |
| ----------------------- | 7. Pull Request | ----------------------- |
| master -> c224ff7       | --------------> | master -> c224ff7 (c)   |
| anidea -> 884faa1 (a)   |                 | anidea -> 884faa1 (b)   |
'-------------------------'                 '-------------------------'
    |                 ^
    | 2. Clone        |
    |                 |
    |                 |
    |                 |
    |                 |
    |                 | 6. Push (anidea => Origin/anidea)
    v                 |
.-------------------------.
| Your computer           |  3. Create branch 'anidea'
| $HOME/coolgame          |
| ----------------------- |  4. Update a file
| master -> c224ff7       |
| anidea -> 884faa1       |  5. Commit (to 'anidea')
'-------------------------'

(a) - after you have pushed it
(b) - after Joe has accepted it
(c) - eventually Joe might merge 'anidea' (make 'master -> 884faa1')

Gabel

  • Eine Kopie Ihres Remote-Repos (Cloud), die es mit Joes verknüpft
  • Eine Kopie, die Sie dann auf Ihr lokales Repo klonen und F *% $ - up
  • Wenn Sie fertig sind, können Sie auf Ihre Fernbedienung zurückschieben
  • Sie können Joe dann fragen, ob er es in seinem Projekt verwenden möchte, indem Sie auf Pull-Request klicken

Klon

  • eine Kopie auf Ihr lokales Repo (Festplatte)

Nur um anderen eine spezielle Anmerkung zum Gabeln hinzuzufügen.

Es ist gut zu erkennen, dass technisch gesehen das Klonen des Repos und das Gabeln des Repos dasselbe sind. Machen:

git clone $some_other_repo

und Sie können sich auf den Rücken klopfen --- Sie haben gerade ein anderes Repo gegabelt.

Git ist als VCS in der Tat alles über klonen gabeln. Abgesehen davon, dass Sie über eine Remote-Benutzeroberfläche wie cgit "nur browsen", hat dies mit Git-Repo nur wenig zu tun gabeln irgendwann das Repo klonen.

Jedoch,

  • wenn jemand ich habe repo X gegabelt sagt, bedeutet dies, dass er irgendwo anders einen Klon des Repos erstellt hat, mit der Absicht aufzudecken B. um einige Experimente zu zeigen oder um andere Zugriffskontrollmechanismen anzuwenden (z. B. um Personen ohne Github-Zugriff, aber mit firmeninternem Account die Zusammenarbeit zu ermöglichen).

    Fakten: Das Repo wird höchstwahrscheinlich mit einem anderen Befehl als git clone Erstellt, es wird höchstwahrscheinlich irgendwo auf einem Server gehostet und hat höchstwahrscheinlich ein etwas anderes Format (es ist ein "nacktes Repo"). dh ohne Arbeitsbaum) sind alles nur technische Details.

    Die Tatsache, dass es höchstwahrscheinlich verschiedene Verzweigungen, Tags oder Commits enthält, ist höchstwahrscheinlich der Grund, warum sie es überhaupt gemacht haben.

    (Was Github macht, wenn Sie auf "fork" klicken, klont nur mit hinzugefügtem Zucker: Es klont das Repo für Sie, legt es unter Ihrem Konto ab, zeichnet das "forked from" irgendwo auf, fügt eine entfernte Quelle mit dem Namen "upstream" hinzu und vor allem: spielt die Nice Animation.)

  • Wenn jemand sagt ich habe repo X geklont, bedeutet dies, dass er einen Klon des Repos lokal auf seinem Laptop oder Desktop erstellt hat, um es zu studieren, damit zu spielen, dazu beizutragen oder etwas aus dem Quellcode zu erstellen Code drin.

Das Schöne an Git ist, dass dadurch alles perfekt zusammenpasst: Alle diese Repos teilen den gemeinsamen Teil von block Commit-Kette, so dass es möglich ist, Änderungen zwischen all diesen Repos nach Belieben sicher (siehe Hinweis unten) zusammenzuführen.


Hinweis: "sicher", solange Sie den gemeinsamen Teil der Kette nicht umschreiben und die Änderungen nicht widersprüchlich sind.

6
Alois Mahdal