Git
Diese Antwort enthält GitHub, da viele Leute auch danach gefragt haben.
Lokale Repositorys
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. Es unterscheidet sich auch in dieser Hinsicht 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 so die "exklusive Sperre" -Funktion für eine Bearbeitung (ältere Systeme wie PVCs kommen in den Sinn), so dass alle Dateien immer bearbeitet werden können, auch wenn sie offline sind. Es macht tatsächlich einen erstaunlichen Job, Dateiänderungen (innerhalb derselben Datei!) Beim Ziehen oder Abrufen / Drücken in ein Remote-Repository wie GitHub zusammenzuführen. Das einzige Mal, dass Sie manuelle Änderungen vornehmen müssen (tatsächlich eine Datei bearbeiten), ist, wenn zwei Änderungen dieselbe Codezeile (n) betreffen.
Geäst
Mit Zweigen können Sie den Hauptcode (den Hauptzweig) beibehalten, eine Kopie erstellen (einen neuen Zweig) und dann in diesem neuen Zweig arbeiten. Wenn die Arbeit eine Weile dauert oder der Master seit der Erstellung des Zweigs viele Aktualisierungen erhält, sollte ein Zusammenführen oder erneutes Basieren (häufig bevorzugt für einen besseren Verlauf und eine einfachere Lösung von Konflikten) mit dem Master-Zweig durchgeführt werden. Wenn Sie fertig sind, führen Sie die in der Verzweigung vorgenommenen Änderungen wieder in das Master-Repository ein. Viele Organisationen verwenden Zweige für jede Arbeit, unabhängig davon, ob es sich um eine Funktion, einen Fehler oder eine Aufgabe handelt. Andere Organisationen verwenden Zweige nur für wichtige Änderungen, z. B. Versions-Upgrades.
Gabelung: Mit einer Verzweigung steuern und verwalten Sie die Verzweigung, während mit einer Verzweigung jemand anderes die Annahme des Codes wieder steuert.
Grundsätzlich gibt es zwei Hauptansätze für die Durchführung von Zweigen. Die erste besteht darin, die meisten Änderungen im Hauptzweig beizubehalten und nur Zweige für größere und länger laufende Dinge wie Versionsänderungen zu verwenden, bei denen zwei Zweige für unterschiedliche Anforderungen verfügbar sein sollen. Die zweite Möglichkeit besteht darin, für jede Feature-Anfrage, Fehlerbehebung oder Aufgabe einen Zweig zu erstellen und dann manuell zu entscheiden, wann diese Zweige tatsächlich in den Haupt-Hauptzweig zusammengeführt werden sollen. Obwohl dies langwierig klingt, ist dies ein gängiger Ansatz, den ich derzeit verwende und empfehle, da dies den Master-Zweig sauberer hält und es der Master ist, den wir in die Produktion befördern. Daher möchten wir nur vollständigen, getesteten Code über das Rebasing und Zusammenschluss von Zweigen.
Die Standardmethode, um einen Zweig zum Master zu bringen, ist a merge. Zweige können auch "neu basiert" werden, um den Verlauf zu "bereinigen". Es hat keinen Einfluss auf den aktuellen Status und dient dazu, eine "sauberere" Geschichte zu erstellen.
Grundsätzlich besteht die Idee darin, dass Sie von einem bestimmten Punkt aus verzweigt sind (normalerweise vom Master). Seit Sie verzweigt haben, hat sich 'master' selbst von diesem Verzweigungspunkt nach vorne bewegt. Es wird "sauberer" (einfacher zu lösende Probleme und der Verlauf wird leichter zu verstehen sein), wenn alle Änderungen, die Sie in einem Zweig vorgenommen haben, mit allen aktuellen Änderungen gegen den aktuellen Status des Masters abgespielt 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 Rebase ebenso wie Merge zu Konflikten führen kann, die Sie manuell lösen müssen (dh bearbeiten und beheben).
Eine zu beachtende Richtlinie:
Nur neu starten, wenn der Zweig lokal ist und Sie ihn noch nicht auf Remote verschoben haben!
Dies liegt hauptsächlich daran, dass eine Neubasierung die Geschichte anderer Menschen verändern kann, einschließlich ihrer eigenen Commits.
Verfolgen von Zweigen
Dies sind die Zweige, die benannt werden origin/branch_name(im Gegensatz zu nur branch_name). Wenn Sie den Code in Remote-Repositorys verschieben und von diesen entfernen, ist dies tatsächlich der Mechanismus, über den dies geschieht. Wenn Sie beispielsweise git pusheinen Zweig aufgerufen haben building_groups, geht Ihr Zweig zuerst zum origin/building_groupsRemote-Repository und dann zum Remote-Repository. Wenn Sie a git fetch building_groupsausführen, wird die abgerufene Datei in Ihrem origin/building_groupsZweig abgelegt . Sie können diesen Zweig dann in Ihre lokale Kopie einfügen. Unsere Praxis besteht darin, immer eine git fetchund eine manuelle Zusammenführung durchzuführen und nicht nur eine git pull(die beide oben genannten Schritte in einem Schritt ausführt).
Neue Filialen holen.
Neue Zweige erhalten: Am Anfang eines Klons befinden sich alle Zweige. Wenn jedoch andere Entwickler Zweige hinzufügen und auf die Fernbedienung übertragen, muss es eine Möglichkeit geben, diese Zweige und ihre Namen zu kennen, um sie lokal abrufen zu können. Dies erfolgt über a, git fetchwodurch alle neuen und geänderten Zweige mithilfe der Tracking-Zweige (z origin/. B. ) in das lokale Repository übertragen werden . Einmal fetchbearbeitet, kann git branch --remoteman die Tracking-Zweige auflisten und git checkout [branch]tatsächlich zu einem bestimmten 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 eine Remote nicht synchron sind). Wenn man eine Arbeit in einer Niederlassung entwickelt hat und die Arbeit vollständig, bereit und getestet ist, kann sie in die masterNiederlassung zusammengeführt werden. Dies geschieht, indem Sie git checkout masterdann zum masterZweig wechseln git merge your_branch. Durch das Zusammenführen werden alle verschiedenen Dateien und sogar verschiedene Änderungen an denselben Dateien zusammengeführt. Dies bedeutet, dass der Code in den Dateien tatsächlich geändert wird, um alle Änderungen zusammenzuführen.
Wenn dabei die checkoutvon masterihm ist auch eine empfohlene zu tun git pull origin masterdie aktuelle Version des Remote - Master zu bekommen fusionierte in Ihrem lokalen Master. Wenn sich der Remote-Master geändert hat, dh, moved forwardwerden Informationen angezeigt, die dies widerspiegeln git pull. Wenn das der Fall ist (Master geändert) Sie werden gebeten, git checkout your_branchund dann , rebaseum es zu meistern , damit die Änderungen tatsächlich bekommen ‚abgespielt‘ auf den ‚neuen‘ Master. Dann würden Sie fortfahren, den Master auf den neuesten Stand zu bringen, wie im nächsten Absatz gezeigt.
Wenn keine Konflikte vorliegen, werden dem Master die neuen Änderungen 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 git merge new_branchwird gemeldet, dass Konflikte gelöst werden müssen. Sie "lösen" sie auf, indem Sie die Dateien bearbeiten (die beide Änderungen enthalten), 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 , sobald Sie wieder werden git addund git commitdiese Änderungen die Serie fortzusetzen (werden Sie Feedback von git während dieses Prozesses erhalten Sie zu führen).
Wenn der Prozess nicht gut funktioniert, werden Sie feststellen, dass dies git merge --abortsehr praktisch ist, um Dinge zurückzusetzen.
Interaktives Umbasieren und Quetschen / Neuordnen / Entfernen von Commits
Wenn Sie in vielen kleinen Schritten gearbeitet haben, z. B. jeden Tag Code als "in Arbeit" festschreiben, möchten Sie diese vielen kleinen Festschreibungen möglicherweise in einige größere Festschreibungen "zerquetschen". 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), erneut abspielen. Sie möchten nur sagen, dass hier der Endeffekt (diff) aller meiner Änderungen für diese Arbeit in einem Commit ist.
Der zu bewertende Schlüsselfaktor bei der Überlegung, ob dies zu tun ist, ist, ob die mehreren Festschreibungen gegen dieselbe Datei oder gegen mehrere Dateien erfolgen (in diesem Fall ist es besser, Festschreibungen zu quetschen). Dies erfolgt mit dem interaktiven Rebasing-Tool. Mit diesem Tool können Sie Commits quetschen, Commits löschen, Nachrichten umformulieren usw. git rebase -i HEAD~10( Hinweis: das ist a ~, nicht a- ) zeigt Folgendes an:
Seien Sie jedoch vorsichtig und verwenden Sie dieses Werkzeug "vorsichtig". Führen Sie jeweils einen Squash / Löschen / Neuordnen 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 Commits auch hier 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. Die erste, oben beschriebene, erfolgt direkt über Zweige, die von / nach gezogen und 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 - Forking - ermöglicht es jedem, das Repository zu "forken", indem er im Grunde genommen eine lokale Kopie in seinem eigenen Git-Repository-Konto erstellt. Sie können dann Änderungen vornehmen und nach Abschluss eine Pull-Anfrage senden (es handelt sich eher um einen Push von ihnen 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 niemand eine Liste der Benutzer für das Repository verwalten.
GitHub
GitHub (ein Remote-Repository) ist eine Remote-Quelle, an die Sie normalerweise die festgeschriebenen Änderungen senden, wenn Sie über ein solches Repository verfügen (oder zu diesem hinzugefügt werden), sodass lokal und remote tatsächlich sehr unterschiedlich sind. Eine andere Möglichkeit, sich ein Remote-Repository vorzustellen, besteht darin, dass es sich um eine .gitVerzeichnisstruktur handelt, die sich auf einem Remote-Server befindet.
Wenn Sie "gabeln" - in der Benutzeroberfläche des GitHub-Webbrowsers können Sie auf diese Schaltfläche klicken 
- erstellen Sie eine Kopie ("Klon") des Codes in Ihrem GitHub-Konto. Es kann ein wenig subtil sein, wenn Sie es zum ersten Mal tun. Stellen Sie also sicher, dass Sie sich ansehen, unter welchem Repository eine Codebasis aufgeführt ist - entweder der ursprüngliche Eigentümer oder "gegabelt von", und Sie, z.
Sobald Sie die lokale Kopie haben, können Sie die gewünschten Änderungen vornehmen (indem Sie sie auf einen lokalen Computer ziehen und verschieben). Wenn Sie fertig sind, senden Sie eine 'Pull-Anfrage' an den ursprünglichen Repository-Eigentümer / Administrator (klingt ausgefallen, aber tatsächlich klicken Sie einfach darauf :) 
und sie 'ziehen' sie ein.
Für ein Team, das gemeinsam an Code arbeitet, ist es üblicher, das Repository zu "klonen" (klicken Sie auf das Symbol "Kopieren" im Hauptbildschirm des Repositorys). Geben Sie dann lokal ein git cloneund fügen Sie es ein. Dadurch werden Sie lokal eingerichtet und können auch auf den (freigegebenen) GitHub-Speicherort verschieben und ziehen.
Klone
Wie im Abschnitt auf GitHub angegeben, ist ein Klon eine Kopie eines Repositorys. Wenn Sie über ein Remote-Repository verfügen, geben Sie den git cloneBefehl für dessen URL aus 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, für den Sie Ihre Adds und Commits ausführen, und dann ist das Remote-Repository selbst das, worauf Sie diese Commits übertragen. 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 traditionelleren CVSs (Code Versioning Systems) wie SVN, PVCS, CVS usw., wo Sie verpflichten sich direkt zum Remote-Repository.
Visualisierung
Die 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( gitxfür macOS) nicht mit einer GUI schlagen, die ich als "U-Bahn-Karte" (insbesondere Londoner U-Bahn) bezeichne. wie sich Dinge ändern, auseinander gehen und verschmelzen usw.
Sie können es auch verwenden, um Ihre Änderungen hinzuzufügen, festzuschreiben und zu verwalten!
Obwohl gitg / gitx ziemlich minimal ist, wächst die Anzahl der GUI-Tools weiter. Viele Mac-Benutzer verwenden Brotherbards Gabel von Gitx und für Linux ist Smart-Git mit einer intuitiven und dennoch leistungsstarken Oberfläche eine großartige Option:
Beachten Sie, dass Sie selbst mit einem GUI-Tool wahrscheinlich viele Befehle in der Befehlszeile ausführen werden.
Zu diesem Zweck habe ich die folgenden Aliase in meiner ~/.bash_aliasesDatei (die ~/.bashrcfür jede Terminalsitzung aus meiner 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 ~/.gitconfigDatei - warum haben diese?
Damit funktioniert die Verzweigung (mit der TAB-Taste)!
Das sind also:
[alias]
co = checkout
cob = checkout -b
Anwendungsbeispiel: git co [branch]<- Tab-Vervollständigung für Zweige funktioniert.
GUI-Lernwerkzeug
Unter https://learngitbranching.js.org/ finden Sie möglicherweise nützliche Informationen zum Erlernen einiger der Basiskonzepte. Screenshot:
Video: https://youtu.be/23JqqcLPss0
Endlich 7 wichtige Lebensretter!
Sie nehmen Änderungen vor, fügen sie hinzu und übernehmen sie (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 !
Sie bringen einige Dateien durcheinander, während Sie in einer lokalen Niederlassung arbeiten, und möchten einfach zu dem zurückkehren, was Sie beim letzten Mal getan haben git pull:
git reset --hard origin/master # You will need to be comfortable doing this!
Sie nehmen lokal Änderungen vor, bearbeiten ein halbes Dutzend Dateien und befinden sich dann, oh Mist, immer noch im Hauptzweig (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
Sie haben eine bestimmte Datei in Ihrem aktuellen Zweig durcheinander gebracht und möchten diese Datei grundsätzlich auf das letzte Mal zurücksetzen (Änderungen verlieren), als Sie sie aus dem Remote-Repository abgerufen haben:
git checkout your/directories/filename
Dadurch wird die Datei tatsächlich zurückgesetzt (wie bei vielen Git-Befehlen ist sie nicht gut benannt, was sie hier tut).
Sie nehmen einige Änderungen lokal vor, möchten sicherstellen, dass Sie sie nicht verlieren, während Sie ein git resetoder rebase: Ich mache oft eine manuelle Kopie des gesamten Projekts ( cp -r ../my_project ~/), wenn ich nicht sicher bin, ob ich in Git Fehler machen oder wichtige verlieren könnte Änderungen.
Sie sind neu gegründet, aber die Dinge werden durcheinander gebracht:
git rebase --abort # To abandon interactive rebase and merge issues
Fügen Sie Ihrer PS1Eingabeaufforderung Ihren Git-Zweig hinzu (siehe https://unix.stackexchange.com/a/127800/10043 ), z
Die Niederlassung ist selenium_rspec_conversion.
