Ich möchte den Unterschied zwischen einer Verzweigung, einem Fork und einem Klon in Git verstehen?
Was bedeutet es außerdem, wenn ich eine git fetch im Gegensatz zu einer git pull ?
Außerdem: Was bedeutet rebase Mittelwert im Vergleich zu merge ?
Wie kann ich einzelne Engagements zusammenpressen?
Wie werden sie verwendet, warum werden sie verwendet und wofür stehen sie?
Welche Rolle spielt GitHub?
Diese Antwort schließt GitHub ein, da viele Leute auch danach gefragt haben.
Git hat (lokal) ein Verzeichnis ( .git ), in das Sie Ihre Dateien übertragen und das Ihr "lokales Repository" ist. Dies unterscheidet sich von Systemen wie SVN, bei denen Sie dem entfernten Repository sofort Dateien hinzufügen und übertragen.
Git speichert jede Version einer Datei, die sich ändert, indem es die gesamte Datei speichert. Auch in dieser Hinsicht unterscheidet es sich von SVN, da man zu jeder einzelnen Version gehen kann, ohne sie durch Delta-Änderungen "neu zu erstellen".
Git "sperrt" Dateien überhaupt nicht und vermeidet somit die "exklusive Sperrfunktion" für eine Bearbeitung (ältere Systeme wie pvcs kommen mir in den Sinn), so dass alle Dateien immer bearbeitet werden können, auch wenn sie offline sind. Es leistet erstaunliche Arbeit beim Zusammenführen von Datei-Änderungen (innerhalb derselben Datei!) während Pulls oder Fetches/Pushes in ein entferntes Repository wie GitHub. Manuelle Änderungen (tatsächliche Bearbeitung einer Datei) sind nur dann erforderlich, wenn zwei Änderungen dieselbe(n) Codezeile(n) betreffen.
Zweige ermöglichen es Ihnen, den Hauptcode (den "Master"-Zweig) zu erhalten, eine Kopie (einen neuen Zweig) zu erstellen und dann innerhalb dieses neuen Zweigs zu arbeiten. Wenn die Arbeit eine Weile dauert oder der Master-Zweig seit der Erstellung des Zweigs viele Aktualisierungen erhalten hat, sollte man ihn mit dem Master-Zweig zusammenführen oder neu einbinden (oft bevorzugt, um eine bessere Historie zu erhalten und Konflikte leichter zu beheben). Wenn Sie fertig sind, führen Sie die im Zweig vorgenommenen Änderungen wieder in das Master-Repository ein. Viele Organisationen verwenden Zweige für jede Arbeit, egal ob es sich um eine Funktion, einen Fehler oder eine Aufgabe handelt. Andere Organisationen verwenden Zweige nur für größere Änderungen wie Versions-Upgrades.
Fork: Bei einer Verzweigung kontrollieren und verwalten Sie die Verzweigung, während bei einem Fork jemand anderes die Kontrolle darüber hat, ob der Code wieder aufgenommen wird.
Im Großen und Ganzen gibt es zwei Hauptansätze für die Durchführung von Zweigstellen. Die erste ist, die meisten Änderungen auf dem Master-Zweig zu belassen, und Zweige nur für größere und länger laufende Dinge wie Versionsänderungen zu verwenden, bei denen Sie zwei Zweige für unterschiedliche Bedürfnisse zur Verfügung haben wollen. Die zweite ist, dass man im Grunde einen Zweig für jede Funktionsanforderung, Fehlerbehebung oder Aufgabe macht und dann manuell entscheidet, wann man diese Zweige in den Hauptzweig des Masters zusammenführt. Auch wenn sich das mühsam anhört, ist dies ein gängiger Ansatz, den ich derzeit verwende und empfehle, weil der Master-Zweig dadurch sauberer bleibt und wir nur fertigen, getesteten Code über das Rebasing und Mergen von Zweigen in die Produktion überführen wollen.
Der Standardweg, um einen Zweig in den Master zu bringen, ist ein merge . Zweige können auch "rebased" werden, um die Historie zu "bereinigen". Dies wirkt sich nicht auf den aktuellen Zustand aus und dient dazu, den Verlauf "sauberer" zu gestalten.
Im Grunde genommen geht es darum, dass Sie von einem bestimmten Punkt aus verzweigt haben (in der Regel vom Master). Da Sie verzweigt haben, hat sich "master" selbst von diesem Verzweigungspunkt aus weiterentwickelt. Es ist "sauberer" (einfacher, Probleme zu lösen und die Geschichte wird leichter zu verstehen sein), wenn alle Änderungen, die Sie in einem Zweig gemacht haben, gegen den aktuellen Stand von "master" mit all seinen letzten Änderungen gespielt werden. Der Prozess ist also: Speichern Sie die Änderungen; holen Sie sich den "neuen" Master und wenden Sie dann die Änderungen erneut gegen diesen an (das ist der rebase-Teil). Seien Sie sich bewusst, dass rebase, genau wie merge, zu Konflikten führen kann, die Sie manuell lösen müssen (d.h. bearbeiten und korrigieren).
Ein Leitfaden ist zu beachten:
Führen Sie nur dann ein Rebase durch, wenn der Zweig lokal ist und Sie ihn noch nicht auf remote gepusht haben!
Das liegt vor allem daran, dass das Rebasing die Historie verändern kann, die andere Personen sehen, was ihre eigenen Commits einschließen kann.
Dies sind die Zweige mit den Namen origin/branch_name (im Gegensatz zu nur branch_name ). Wenn Sie den Code zu/von entfernten Repositories schieben und ziehen, ist dies der Mechanismus, über den dies geschieht. Zum Beispiel, wenn Sie git push einen Zweig namens building_groups geht Ihr Zweig zuerst zu origin/building_groups und das geht dann an das entfernte Repository. Ähnlich ist es, wenn Sie eine git fetch building_groups wird die abgerufene Datei in Ihrem origin/building_groups Zweigstelle. Sie können dann wählen, ob Sie diesen Zweig in Ihre lokale Kopie zusammenführen wollen. Unsere Praxis ist es, immer eine git fetch und eine manuelle Zusammenführung statt nur eine git pull (die beides in einem Schritt erledigt).
Neue Filialen erhalten: Zu Beginn eines Klons werden Sie alle Zweige haben. Wenn jedoch andere Entwickler neue Zweige hinzufügen und diese auf das Remote-System übertragen, muss es eine Möglichkeit geben, diese Zweige und ihre Namen zu kennen, um sie lokal abrufen zu können. Dies geschieht über eine git fetch die alle neuen und geänderten Zweige in das lokale Repository unter Verwendung der Tracking-Zweige (z.B., origin/ ). Sobald fetch kann man git branch --remote um die Verfolgungszweige aufzulisten und git checkout [branch] um tatsächlich zu einem bestimmten zu wechseln.
Beim Merging werden Code-Änderungen aus verschiedenen Zweigen oder aus verschiedenen Versionen desselben Zweigs zusammengeführt (z. B. wenn ein lokaler und ein entfernter Zweig nicht synchron sind). Wenn man Arbeit in einem Zweig entwickelt hat und die Arbeit vollständig, fertig und getestet ist, dann kann sie in den master Zweigstelle. Dies geschieht durch git checkout master zum Wechsel zum master Zweig, dann git merge your_branch . Die Zusammenführung bringt alle verschiedenen Dateien und auch unterschiedliche Änderungen an denselben Dateien zusammen. Das bedeutet, dass der Code in den Dateien tatsächlich geändert wird, um alle Änderungen zusammenzuführen.
Bei der Durchführung der checkout de master Es wird auch empfohlen, eine git pull origin master um die allerneueste Version des entfernten Masters in Ihren lokalen Master einzubinden. Wenn sich der entfernte Master ändert, d.h., moved forward werden Sie Informationen sehen, die widerspiegeln, dass während dieses git pull . Wenn dies der Fall ist (Master geändert), wird empfohlen, dass Sie git checkout your_branch und dann rebase in den Master, so dass Ihre Änderungen tatsächlich auf dem 'neuen' Master 'wiedergegeben' werden. Dann würden Sie damit fortfahren, den Master auf den neuesten Stand zu bringen, wie im nächsten Absatz beschrieben.
Wenn es keine Konflikte gibt, werden dem Master die neuen Änderungen hinzugefügt. Wenn es Konflikte gibt, bedeutet dies, dass dieselben Dateien Änderungen an ähnlichen Codezeilen aufweisen, die nicht automatisch zusammengeführt werden können. In diesem Fall git merge new_branch meldet, dass es einen oder mehrere Konflikte zu lösen gibt. Sie "lösen" sie auf, indem Sie die Dateien bearbeiten (die beide Änderungen enthalten), die gewünschten Änderungen auswählen, die Zeilen mit den nicht gewünschten Änderungen buchstäblich löschen und dann die Datei speichern. Die Änderungen werden mit Trennzeichen markiert, z. B. ======== y <<<<<<<< .
Sobald Sie alle Konflikte gelöst haben, werden Sie erneut git add y git commit diese Änderungen, um die Zusammenführung fortzusetzen (Sie erhalten während dieses Prozesses Rückmeldungen von git, die Sie anleiten).
Wenn der Prozess nicht gut funktioniert, werden Sie feststellen, dass git merge --abort ist sehr praktisch, um Dinge zurückzusetzen.
Wenn Sie Ihre Arbeit in vielen kleinen Schritten erledigt haben, z.B. wenn Sie jeden Tag Code als "work-in-progress" committen, möchten Sie vielleicht diese vielen kleinen Commits in ein paar größere Commits "zerquetschen". Dies kann besonders nützlich sein, wenn Sie Code-Reviews mit Kollegen durchführen wollen. Sie wollen nicht alle "Schritte", die Sie unternommen haben (über Commits) wiedergeben, Sie wollen nur sagen, hier ist das Endergebnis (diff) aller meiner Änderungen für diese Arbeit in einem Commit.
Der Schlüsselfaktor bei der Überlegung, ob man dies tun sollte, ist, ob die mehrfachen Übertragungen sich auf dieselbe Datei oder auf mehrere Dateien beziehen (in diesem Fall ist es besser, die Übertragungen zu zerlegen). Dies wird mit dem interaktiven Rebasing-Tool durchgeführt. Mit diesem Werkzeug können Sie Commits zerdrücken, löschen, Nachrichten umformulieren usw. Zum Beispiel, git rebase -i HEAD~10 ( Anmerkung: Das ist ein ~ , nicht ein - ) führt zu folgendem Ergebnis:
Seien Sie jedoch vorsichtig und verwenden Sie dieses Werkzeug "behutsam". Führen Sie jeweils einen Squash/Löschen/Umordnen durch, beenden und speichern Sie den Commit und starten Sie das Tool dann erneut. Wenn Commits nicht zusammenhängend sind, können Sie sie neu anordnen (und dann nach Bedarf zerdrücken). Sie können hier auch Commits löschen, aber Sie müssen wirklich sicher sein, was Sie tun, wenn Sie das tun!
Es gibt zwei Hauptansätze für die Zusammenarbeit in Git-Repositories. Die erste, oben beschriebene, erfolgt direkt über Zweige, aus denen und in die man zieht und schiebt. Diese Mitarbeiter haben ihre SSH-Schlüssel bei dem entfernten 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 - Forking - erlaubt es jedem, das Repository zu "forken", also 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 (eigentlich ist es eher ein "Push" von ihnen und eine "Pull"-Anfrage für den eigentlichen Betreuer des Projektarchivs), damit der Code akzeptiert wird.
Diese zweite Methode, bei der Gabelungen verwendet werden, ist pas jemanden benötigen, der eine Liste von Benutzern für das Repository führt.
GitHub (ein entferntes Repository) ist eine entfernte Quelle, zu der Sie normalerweise die Änderungen übertragen und ziehen, wenn Sie ein solches Repository haben (oder zu dem Sie hinzugefügt werden). Eine andere Möglichkeit, sich ein entferntes Repository vorzustellen, ist, dass es ein .git Verzeichnisstruktur, die sich auf einem entfernten Server befindet.
Wenn Sie "fork" - in der GitHub Webbrowser-GUI können Sie auf diese Schaltfläche klicken 
- erstellen Sie eine Kopie ('Klon') des Codes in votre GitHub-Konto. Beim ersten Mal kann es ein wenig subtil sein, also stellen Sie sicher, dass Sie darauf achten, unter wessen Repository eine Codebasis aufgeführt ist - entweder der ursprüngliche Eigentümer oder "forked from" und Sie, z. B. so:
Sobald Sie die lokale Kopie haben, können Sie nach Belieben Änderungen vornehmen (indem Sie sie auf einen lokalen Rechner ziehen und schieben). Wenn Sie fertig sind, übermitteln Sie eine "Pull-Anfrage" an den ursprünglichen Repository-Besitzer/Administrator (klingt ausgefallen, aber in Wirklichkeit klicken Sie einfach auf diese Schaltfläche: 
) und sie "ziehen" es ein.
Üblicher für ein Team, das gemeinsam an Code arbeitet, ist es, das Repository zu "klonen" (klicken Sie auf das Symbol "Kopieren" auf dem Hauptbildschirm des Repositorys). Dann geben Sie lokal git clone und einfügen. Dadurch werden Sie lokal eingerichtet und können auch zum (gemeinsamen) GitHub-Speicherort pushen und ziehen.
Wie im Abschnitt über GitHub beschrieben, ist ein Klon eine Kopie eines Repositorys. Wenn Sie ein entferntes Repository haben, geben Sie die git clone Befehl mit seiner URL und Sie erhalten eine lokale Kopie oder einen Klon des Repositorys. Dieser Klon hat alles die Dateien, den Master-Zweig, die anderen Zweige, alle vorhandenen Übertragungen, den ganzen Kram. Es ist dieser Klon, gegen den Sie Ihre Hinzufügungen und Übertragungen vornehmen, und dann ist es das entfernte Repository selbst, in das Sie diese Übertragungen übertragen. Es ist dieses lokale/entfernte Konzept, das Git (und ähnliche Systeme wie Mercurial) zu einem DVCS macht ( Verteilt Version Control System) im Gegensatz zu den traditionelleren CVSs (Code Versioning Systems) wie SVN, PVCS, CVS usw., bei denen Sie direkt in das entfernte Repository übertragen.
Die Visualisierung der Kernkonzepte ist zu sehen unter
http://marklodato.github.com/visual-git-guide/index-en.html et
http://ndpsoftware.com/git-cheatsheet.html#loc=index
Wenn Sie eine visuelle Darstellung der Auswirkungen der Änderungen wünschen, ist das visuelle Tool unschlagbar gitg ( gitx für macOS) mit einer grafischen Benutzeroberfläche, die ich als "U-Bahn-Karte" bezeichne (insbesondere die Londoner U-Bahn), um zu zeigen, wer was gemacht hat, wie sich die Dinge ändern, auseinandergehen und zusammenkommen usw.
Sie können es auch zum Hinzufügen, Übertragen und Verwalten Ihrer Änderungen verwenden!
Obwohl gitg/gitx ziemlich minimal ist, wächst die Zahl der GUI-Tools weiter an. Viele Mac-Benutzer verwenden den Fork von gitx von brotherbard, und für Linux ist smart-git eine großartige Option mit einer intuitiven und dennoch leistungsstarken Oberfläche:
Beachten Sie, dass Sie auch mit einem GUI-Tool wahrscheinlich viele Befehle über die Befehlszeile ausführen werden.
Zu diesem Zweck habe ich die folgenden Aliase in meinem ~/.bash_aliases Datei (die von meiner Seite aus aufgerufen wird ~/.bashrc Datei für jede Terminalsitzung):
# 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 aliases" in meinem ~/.gitconfig Datei - warum gibt es diese?
Damit die Verzweigungsvervollständigung (mit der TAB-Taste) funktioniert!
Diese sind:
[alias]
co = checkout
cob = checkout -bBeispiel für die Verwendung: git co [branch] <- Die Tabulatorvervollständigung für Zweige wird funktionieren.
Sie finden vielleicht https://learngitbranching.js.org/ nützlich, um einige der grundlegenden Konzepte zu lernen. Bildschirmfoto: 
Video: https://youtu.be/23JqqcLPss0
Sie nehmen Änderungen vor, fügen sie hinzu und übertragen sie (aber pushen sie nicht), und dann stellen Sie fest, dass Sie in Master 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 !Sie haben bei der Arbeit in einer lokalen Zweigstelle einige Dateien durcheinander gebracht und möchten einfach zu dem Stand zurückkehren, den Sie beim letzten Mal hatten, als Sie eine git pull :
git reset --hard origin/master # You will need to be comfortable doing this!Sie fangen an, lokal Änderungen vorzunehmen, bearbeiten ein halbes Dutzend Dateien und dann, oh Mist, sind Sie immer noch im Master-Zweig (oder einem anderen):
git checkout -b new_branch_name # just create a new branch
git add . # add the changes files
git commit -m"your message" # and commit themSie vermasseln eine bestimmte Datei in Ihrem aktuellen Zweig und möchten diese Datei im Grunde auf den Stand des letzten Abrufs aus dem entfernten Repository "zurücksetzen" (Änderungen verlieren):
git checkout your/directories/filenameDies setzt die Datei tatsächlich zurück (wie viele Git-Befehle ist der Name nicht gut für das, was er hier tut).
Wenn Sie lokal Änderungen vornehmen, möchten Sie sicherstellen, dass diese nicht verloren gehen, während Sie eine git reset o rebase : Ich mache oft eine manuelle Kopie des gesamten Projekts ( cp -r ../my_project ~/ ), wenn ich mir nicht sicher bin, ob ich in Git nicht Fehler mache oder wichtige Änderungen verliere.
Sie nehmen eine Umbasierung vor, aber die Dinge geraten durcheinander:
git rebase --abort # To abandon interactive rebase and merge issuesFügen Sie Ihren Git-Zweig zu Ihrem PS1 Aufforderung (siehe https://unix.stackexchange.com/a/127800/10043 ), z.B.
Die Niederlassung ist selenium_rspec_conversion .
Ein Klon ist einfach eine Kopie eines Repositorys. Oberflächlich betrachtet ist das Ergebnis äquivalent zu svn checkout , bei dem Sie den Quellcode aus einem anderen Repository herunterladen. Der Unterschied zwischen zentralisierten VCS wie Subversion und DVCS wie Git besteht darin, dass Sie bei Git beim Klonen tatsächlich das gesamte Quellcode-Repository kopieren, einschließlich der gesamten Historie und der Zweige. Sie haben nun ein neues Repository auf Ihrem Rechner und alle Änderungen, die Sie vornehmen, gehen in dieses Repository. Niemand wird irgendwelche Änderungen sehen, bis Sie diese Commits in ein anderes Repository (oder das ursprüngliche) verschieben oder bis jemand Commits aus Ihrem Repository abruft, wenn es öffentlich zugänglich ist.
Ein Zweig ist etwas, das sich innerhalb eines Repositorys befindet. Vom Konzept her stellt er einen Entwicklungsstrang dar. Normalerweise haben Sie einen Hauptzweig, aber Sie können auch einen Zweig haben, in dem Sie an einer Funktion xyz arbeiten, und einen anderen, um den Fehler abc zu beheben. Wenn Sie einen Zweig ausgecheckt haben, bleiben alle Übertragungen, die Sie machen, auf diesem Zweig und werden nicht mit anderen Zweigen geteilt, bis Sie sie mit dem betreffenden Zweig zusammenführen oder auf diesen zurücksetzen. Natürlich scheint Git ein wenig seltsam zu sein, wenn es um Zweige geht, bis man sich das zugrunde liegende Modell ansieht, wie Zweige implementiert werden. Anstatt es selbst zu erklären (ich glaube, ich habe schon zu viel gesagt), verweise ich auf die "computerwissenschaftliche" Erklärung, wie Git Zweige und Übertragungen modelliert, die der Git-Website entnommen ist:
http://eagain.net/articles/git-for-computer-scientists/
Eine Abspaltung ist eigentlich kein Git-Konzept, sondern eher eine politisch-soziale Idee. Das heißt, wenn einige Leute mit der Art und Weise, wie ein Projekt läuft, nicht zufrieden sind, können sie den Quellcode nehmen und unabhängig von den ursprünglichen Entwicklern daran arbeiten. Das würde man als Fork bezeichnen. Git macht das Forken einfach, da jeder bereits seine eigene "Master"-Kopie des Quellcodes hat. Es ist also so einfach wie die Verbindung zu den ursprünglichen Projektentwicklern zu kappen und erfordert nicht den Export der Historie aus einem gemeinsamen Repository, wie es bei SVN der Fall ist.
EDIT: Da ich mir der modernen Definition von "fork", wie sie von Seiten wie GitHub verwendet wird, nicht bewusst war, sehen Sie sich bitte die Kommentare und auch Michael Durrant's Antwort unter meiner für weitere Informationen.
Fork Vs. Clone - zwei Wörter, die beide Kopie bedeuten
Bitte sehen Sie dies Diagramm. <sup>(Ursprünglich von <a href="http://www.dataschool.io/content/images/2014/Mar/github1.png" rel="noreferrer">http://www.dataschool.io/content/images/2014/Mar/github1.png </a>).</sup>
.-------------------------. 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
Klonen
Nur als Ergänzung zu den anderen, eine Anmerkung speziell zum Forking.
Es ist gut zu wissen, dass technisch gesehen das Klonen der Repo und das Forken der Repo dasselbe sind. Tun:
git clone $some_other_repound Sie können sich selbst auf die Schulter klopfen - Sie haben gerade ein anderes Repo geforkt.
Bei Git als VCS geht es in der Tat um Klonen Gabelung. Abgesehen vom "bloßen Durchstöbern" mit einer entfernten Benutzeroberfläche wie cgit gibt es nur sehr wenig, was man mit einem Git-Repository tun kann, ohne dass man Verzweigung das Klonen des Repos zu einem bestimmten Zeitpunkt.
Allerdings,
wenn jemand sagt Ich habe das Repo X geforkt bedeuten sie, dass sie Folgendes geschaffen haben einen Klon des Repos irgendwo anders mit der Absicht aussetzen. es zu andere, z. B. um einige Experimente zu zeigen, oder um verschiedene Zugriffskontrollmechanismus anzuwenden (z.B. um Leuten ohne Github-Zugang, aber mit einem firmeninternen Konto mitarbeiten können).
Tatsache ist, dass das Repo höchstwahrscheinlich mit einem anderen Befehl erstellt wurde als git clone dass sie höchstwahrscheinlich irgendwo auf einem Server als Laptop gehostet wird und höchstwahrscheinlich eine etwas andere Format hat (es ist ein "bare repo", d.h. ohne Arbeitsbaum), sind alles nur technische Details.
Die Tatsache, dass es höchstwahrscheinlich verschiedene Zweige enthalten wird, Tags oder Commits enthalten wird, ist höchstwahrscheinlich der Grund, warum sie es überhaupt getan haben gemacht haben.
(Was Github macht, wenn Sie auf "fork" klicken, ist nur Klonen mit Zucker: Es klont das Projektarchiv für Sie, legt es unter Ihrem Konto ab, zeichnet das "forked from" irgendwo auf, fügt ein remote namens "upstream" hinzu, und vor allem vor allem aber spielt es die nette Animation ab).
Wenn jemand sagt Ich habe Repo X geklont meinen sie, dass sie Folgendes geschaffen haben einen Klon des Repo lokal auf ihrem Laptop oder Desktop mit der Absicht es zu studieren, damit zu spielen, dazu beizutragen oder etwas aus dem Quellcode zu Code zu erstellen.
Das Schöne an Git ist, dass dies alles perfekt zusammenpasst: all diese Repos haben den gemeinsamen Teil von Block Commit-Chain, so dass es möglich ist, auf sichere Weise (siehe Hinweis unten) Änderungen zwischen all diesen Repos hin und her zu schieben, wie Sie es für richtig halten.
Nota: "sicher", solange Sie den gemeinsamen Teil der Kette nicht umschreiben und die Änderungen nicht in Konflikt miteinander stehen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
