Git für Anfänger: Der endgültige praktische Leitfaden

Question

Ok, nachdem ich dieser Beitrag von PJ Hyett habe ich beschlossen, das Ende zu überspringen und mit Git .

Was ich also brauche, ist ein Anfängerhandbuch praktisch Anleitung zu Git. "Anfänger" wird definiert als jemand, der weiß, wie man mit seinem Compiler umgeht, der einigermaßen versteht, was ein Makefile ist, und hat die Versionskontrolle angefasst, ohne sie sehr gut zu verstehen.

"Praktisch" bedeutet, dass diese Person nicht ins Detail gehen möchte, was Git im Hintergrund tut, und sich nicht einmal darum kümmert (oder weiß), dass es verteilt ist. Ihre Antworten könnten die Möglichkeiten andeuten, aber versuchen Sie, auf den Anfänger abzuzielen, der ein "Haupt"-Repository auf einem "Server" haben möchte, das gesichert und sicher ist, und sein lokales Repository lediglich als "Client"-Ressource behandelt.

Also:

Installation/Einrichtung

• So installieren Sie Git
• Wie richtet man Git ein? Versuchen Sie, Linux, Windows, Mac abzudecken, denken Sie an eine "Client/Server"-Mentalität.
  • GIT-Server mit Msysgit unter Windows einrichten
• Wie erstellt man ein neues Projekt/Repository?
• Wie kann man es so konfigurieren, dass es Dateien (.obj, .user usw.) ignoriert, die nicht wirklich Teil der Codebasis sind?

Arbeiten mit dem Code

• Wie erhalten Sie den neuesten Code?
• Wie kann man den Code auschecken?
• Wie können Sie Änderungen übertragen?
• Wie können Sie sehen, was noch nicht übertragen wurde, oder den Status Ihrer aktuellen Codebasis?
• Wie vernichtet man unerwünschte Übertragungen?
• Wie können Sie zwei Revisionen einer Datei oder Ihre aktuelle Datei mit einer früheren Revision vergleichen?
• Wie kann man den Verlauf der Überarbeitungen einer Datei sehen?
• Wie gehen Sie mit Binärdateien um (z. B. Visio-Dokumente oder Compiler-Umgebungen)?
• Wie führt man Dateien zusammen, die "zur gleichen Zeit" geändert wurden?
• Wie kann man eine Übertragung rückgängig machen (rückgängig machen oder zurücksetzen)?

Kennzeichnung, Verzweigung, Veröffentlichungen, Baselines

• Wie kann man einen bestimmten Satz von Revisionen für einen bestimmten Satz von Dateien "markieren", "kennzeichnen" oder "freigeben", so dass man ihn später immer wieder aufrufen kann?
• Wie kann man eine bestimmte "Freigabe" erreichen?
• Wie verzweigt man sich?
• Wie führt man Zweige zusammen?
• Wie können Sie Konflikte lösen und die Zusammenführung abschließen?
• Wie führt man Teile eines Zweigs in einen anderen Zweig ein?
• Was bedeutet Umbasierung?
• Wie kann ich entfernte Zweigstellen verfolgen?
• Wie kann ich einen Zweig in einem entfernten Repository erstellen?
• Wie lösche ich einen Zweig in einem entfernten Repository?
• Beispiele für Git-Arbeitsabläufe

Andere

• Beschreiben Sie eine gute grafische Benutzeroberfläche, ein IDE-Plugin usw., das Git zu einer Ressource macht, die nicht auf der Kommandozeile läuft, und verlinken Sie auf diese, führen Sie aber auch die Vorteile und Einschränkungen auf.
  • msysgit - Plattformübergreifend, mit Git enthalten
  • gitk - Plattformübergreifender Verlaufsbetrachter, enthalten in Git
  • gitnub - Mac OS X
  • gitx - Mac OS X Verlaufsanzeige
  • smartgit - Plattformübergreifend, kommerziell, Beta
  • tig - Konsolen-GUI für Linux
  • qgit - GUI für Windows, Linux
  • Git-Erweiterungen - Paket für Windows, enthält freundliche GUI
• Gibt es noch andere allgemeine Aufgaben, die ein Anfänger kennen sollte?
  • Der Git-Status zeigt Ihnen, was Sie gerade getan haben, welchen Zweig Sie haben und andere nützliche Informationen
• Wie kann ich effektiv mit einem Subversion-Repository arbeiten, das als Quelle für die Versionskontrolle festgelegt wurde?

Andere Referenzen für Git-Anfänger

• Git-Anleitung
• Git-Buch
• Git-Zauber
• gitcasts
• GitHub-Anleitungen
• Git-Anleitung
• Progit - Buch von Scott Chacon
• Git - SVN Crash-Kurs
• Git von unten nach oben
• Git bereit
• gitref.org
• Git visuelles Spickzettelchen

Eintauchen in Git

• Git konzeptionell verstehen
• Git für Informatiker (und andere Version )

Ich werde die Einträge von Zeit zu Zeit durchgehen und sie "aufräumen", damit sie ein einheitliches Aussehen haben und die Liste leicht zu überblicken ist. Ich werde auch einen Link zu den Einträgen in der Aufzählung oben einfügen, damit man sie später leicht wiederfindet.

Answer 1

Nun, trotz der Tatsache, dass Sie darum gebeten haben, dass wir nicht "einfach" auf andere Ressourcen verlinken, ist es ziemlich dumm, wenn es bereits eine von der Gemeinschaft gewachsene (und wachsende) Ressource gibt, die wirklich ziemlich gut ist: die Git Community Book . Ernsthaft, diese 20+ Fragen in einer Frage sind alles andere als prägnant und konsistent. Das Git Community Book ist sowohl im HTML- als auch im PDF-Format verfügbar und beantwortet viele Ihrer Fragen mit klaren, gut formatierten und von Fachleuten geprüften Antworten und in einem Format, das es Ihnen ermöglicht, direkt zu Ihrem Problem zu springen.

Wenn mein Beitrag Sie wirklich verärgert, werde ich ihn leider löschen. Sagen Sie es einfach.

Answer 2

Wie man es so konfiguriert, dass Dateien ignoriert werden:

Die Möglichkeit, dass Git Dateien ignoriert, die Sie nicht verfolgen wollen, ist sehr nützlich.

Um eine Datei oder eine Gruppe von Dateien zu ignorieren, geben Sie ein Muster an. Die Mustersyntax für Git ist recht einfach, aber mächtig. Sie ist auf alle drei der verschiedenen Dateien anwendbar, die ich im Folgenden erwähnen werde.

• Eine Leerzeile ignoriert keine Dateien, sie wird im Allgemeinen als Trennzeichen verwendet.
• Linien starrend mit # dienen als Kommentare.
• El ! Präfix ist optional und negiert das Muster. Jedes negierte Muster, das passt, hat Vorrang vor Mustern mit niedrigerer Priorität.
• Unterstützt erweiterte Ausdrücke und Wildcards
  • Beispiel: Das Muster: *.[oa] ignoriert alle Dateien im Repository, die auf .o oder .a enden (Objekt- und Archivdateien)
• Wenn ein Muster ein Verzeichnis enthält, das mit einem Schrägstrich endet, passt Git nur auf dieses Verzeichnis und die Pfade darunter. Dadurch werden reguläre Dateien und symbolische Links von der Übereinstimmung ausgeschlossen.
• Ein führender Schrägstrich findet alle Dateien in diesem Pfadnamen.
  • Beispiel: Das Muster /*.c wird mit der Datei foo.c pero no bar/awesome.c

Großes Beispiel aus dem gitignore(5) man-Seite:

$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
#       Documentation/gitignore.html
#       file.o
#       lib.a
#       src/internal.o
[...]
$ cat .git/info/exclude
  # ignore objects and archives, anywhere in the tree.
  *.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
[...]

---

Im Allgemeinen gibt es drei verschiedene Möglichkeiten, nicht verfolgte Dateien zu ignorieren.

1) Für alle Benutzer des Repositorys ignorieren:

Fügen Sie eine Datei namens .gitignore zur Wurzel Ihrer Arbeitskopie.

Modifier .gitignore an Ihre Präferenzen anpassen, welche Dateien ignoriert werden sollen und welche nicht.

git add .gitignore 

und bestätigen Sie, wenn Sie fertig sind.

2) Nur für Ihre Kopie des Repositorys ignorieren:

Hinzufügen/Bearbeiten der Datei $GIT_DIR/info/exclude in Ihrer Arbeitskopie mit den von Ihnen bevorzugten Mustern.

Beispiel: Meine Arbeitskopie ist ~/src/project1, also würde ich ~/src/project1/.git/info/exclude

Sie sind fertig!

3) In allen Situationen ignorieren, auf Ihrem System:

Globale Ignoriermuster für Ihr System können in einer Datei mit beliebigem Namen gespeichert werden.

Mein persönlicher Name ist ~/.gitglobalignore

Ich kann dann git von dieser Datei wissen lassen, indem ich meine ~/.gitconfig Datei mit der folgenden Zeile:

core.excludesfile = ~/.gitglobalignore

Sie sind fertig!

Ich finde die gitignore man-Seite ist die beste Quelle für weitere Informationen.

Answer 3

Wie markiert man einen bestimmten Satz von Überarbeitungen?

Wie kann man einen bestimmten Satz von Revisionen für einen bestimmten Satz von Dateien "markieren", "kennzeichnen" oder "freigeben", so dass man ihn später immer wieder aufrufen kann?

Die Verwendung des git tag Befehl.

Um die aktuelle Revision einfach zu "markieren", würden Sie einfach

git tag -a thetagname
git tag -a 0.1
git tag -a 2.6.1-rc1 -m 'Released on 01/02/03'

Um die aktuellen Tags aufzulisten, führen Sie einfach git tag ohne Argumente, oder -l (Kleinbuchstabe L):

$ git tag -a thetagname # and enter a message, or use -m 'My tag annotation'
$ git tag -l
thetagname

Um ein Tag zu löschen, verwenden Sie die -d Flagge:

$ git tag -d thetagname 
Deleted tag 'thetagname'
$ git tag
[no output]

Um eine bestimmte (frühere) Übertragung zu markieren, tun Sie einfach.

git tag [tag name] [revision SHA1 hash]

Zum Beispiel:

git tag 1.1.1 81b15a68c6c3e71f72e766931df4e6499990385b

---

Hinweis: Git erstellt standardmäßig ein "leichtgewichtiges" Tag (im Grunde ein Verweis auf eine bestimmte Revision). Der "richtige" Weg ist die Verwendung des -a Flagge. Dies wird Ihren Editor starten und nach einer Tag-Nachricht fragen (identisch mit der Frage nach einer Commit-Nachricht, Sie können auch die -m Flag, um die Tag-Meldung auf der Befehlszeile anzugeben). Die Verwendung eines kommentierten Tags erzeugt ein Objekt mit eigener ID, Datum, Tagger (Autor) und optional einer GPG-Signatur (mit der Option -s Tag). Weitere Informationen hierzu finden Sie unter diese Stelle

git tag mytagwithmsg -a -m 'This is a tag, with message'

Und um die Tags mit Anmerkungen aufzulisten, verwenden Sie die -n1 Flagge, um 1 Zeile jeder Tag-Meldung anzuzeigen ( -n245 um die ersten 245 Zeilen jeder Anmerkung anzuzeigen, usw.):

$ git tag -l -n1
mytagwithmsg    This is a tag, with message

Weitere Informationen finden Sie in der git-tag(1) Handbuchseite

Answer 4

Workflow-Beispiel mit GIT.

Git ist extrem flexibel und passt sich gut an jeden Arbeitsablauf an, aber wenn man einen bestimmten Arbeitsablauf nicht erzwingt, kann das dazu führen, dass man nicht versteht, was man mit Git über den linearen "Backup"-Arbeitsablauf hinaus tun kann und wie nützlich zum Beispiel Verzweigungen sein können.

Diese Blog-Beitrag erklärt sehr schön einen sehr einfachen, aber effektiven Arbeitsablauf, der mit Git wirklich einfach einzurichten ist.

Ich zitiere aus dem Blogbeitrag: Wir betrachten origin/master als den Hauptzweig, in dem der Quellcode von HEAD immer einen produktionsreifen Zustand widerspiegelt:

Der Arbeitsablauf ist so populär geworden, dass es ein Projekt gibt, das diesen Arbeitsablauf implementiert: git-flow

Eine schöne Illustration eines einfachen Arbeitsablaufs, bei dem man alle Änderungen in der Entwicklungsumgebung vornimmt und erst dann an den Master überträgt, wenn sich der Code im Produktionsstatus befindet:

Nehmen wir an, Sie möchten an einer neuen Funktion oder an der Überarbeitung eines Moduls arbeiten. Sie könnten einen neuen Zweig erstellen, den wir als "Feature"-Zweig bezeichnen könnten, etwas, das einige Zeit in Anspruch nehmen wird und bei dem vielleicht etwas Code kaputt geht. Sobald Ihr Feature "stabil genug" ist und Sie es "näher" an die Produktion heranführen wollen, führen Sie Ihren Feature-Zweig mit dem Entwicklungszweig zusammen. Wenn alle Bugs nach dem Merge beseitigt sind und Ihr Code alle Tests einwandfrei besteht, schieben Sie Ihre Änderungen in den Master-Zweig.

Während dieses Prozesses finden Sie einen schrecklichen Sicherheitsfehler, der sofort behoben werden muss. Sie könnten einen Zweig namens Hotfixes haben, der Änderungen vornimmt, die schneller in die Produktion zurückfließen als der normale "Entwicklungszweig".

Hier haben Sie eine Illustration, wie dieser Feature/Hotfix/Entwicklung/Produktion-Workflow aussehen könnte (gut erklärt im Blogpost, und ich wiederhole, der Blogpost erklärt den ganzen Prozess viel detaillierter und viel besser als ich.

Answer 5

Hier ist eine Kopie des Beitrags von PJ Hyett, da er nicht mehr verfügbar ist:

Git ist nicht schwer

23. November 2008

Wenn wir den Menschen sagen, warum sie Git statt Subversion verwenden sollten, lautet die häufigste ist: "Git kann Subversion besser als Subversion, aber es kann noch viel mehr als das."

Das "viel mehr" besteht aus einer Reihe von Dinge, die Git wirklich glänzen lassen, aber es kann ziemlich überwältigend sein für diejenigen, die von anderen SCMs wie Subversion.

Nichtsdestotrotz gibt es nichts, was die Git zu verwenden, genauso wie Sie Subversion zu verwenden, während Sie den Übergang.

Angenommen, Sie haben die Software installiert haben und über ein entferntes Repository haben, können Sie auf folgende Weise den Code holen und Ihre Änderungen Änderungen mit Subversion zurück:

$ svn checkout svn://foo.googlecode.com/svn/trunk foo
# make your changes
$ svn commit -m "my first commit"

Und wie würden Sie das in Git machen:

$ git clone git@github.com:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git push

Ein weiterer Befehl, um dies zu erreichen in Git. Dieser zusätzliche Befehl hat große Implikationen, aber für die Zwecke dieses dieses Beitrags ist das alles, worüber wir über einen zusätzlichen Befehl.

Sehen Sie, es ist wirklich nicht so schwer.

Aktualisierung: Ich wäre nachlässig, wenn ich nicht auch erwähnen würde, dass das Äquivalent der Aktualisierung Ihrer lokalen Kopie in Subversion im Vergleich zu Git ist svn update y git pull . Nur ein Befehl in beiden Fällen.