Entwicklung/Git: Unterschied zwischen den Versionen

Die Verwendung von Git setzt eine gewisse Lernkurve voraus. Diese Anleitung soll dir den Einstieg erleichtern und erklärt alles, was du für den Git-Einsatz bei Opencaching.de wissen musst (und Einiges mehr). Sie erklärt die Verwendung von Git anhand der Kommandozeilenversion, die für alle relevanten Betriebssysteme erhältlich ist. Daneben gibt es verschiedene komfortable Benutzeroberflächen. Gerne kannst du ein weiteres Kapitel für die von dir bevorzugte Git-UI hinzufügen!

* http://gitref.org/index.html - eine leichtverständliche Einführung

* http://git-scm.com/documentation - offizielle Dokumentation

Git-Download

Installation per Installationsprogramm und Standardeinstellungen. Zur Installation in der Entwickler-VM siehe [[Entwicklung/Entwicklersystem|Entwicklersystem]].

Diese Information wird später - für jeden einsehbar - zusammen mit jedem Codebeitrag (''commit'') von dir gespeichert. Verwende eine Emailadresse, die veröffentlicht werden darf, und ggf. einen Nickname. Diese Daten werden in der Datei <code>.gitconfig</code> in deinem Benutzerverzeichnis abgelegt.

   

Git arbeitet im Gegensatz zu Subversion ''dezentral''. Jeder Entwickler hat eine eigene Kopie - einen "Klon" - des Repositories, also der Datenbank in der sich alle Dateien des Projekts in allen Branches und Versionsständen befinden. Aus diesem Klon werden die Arbeitsdaten ausgecheckt, und Änderungen der Arbeitsdaten werden dort eingecheckt.

Die Entwickler können in beliebigen Topologien organisiert werden und gleichen den Inhalt ihrer Repositories wechselseitig miteinander ab. Opencaching.de verwendet eine Art Sternstruktur, mit einem Haupt-Repository unter der Adresse  

   

   

Mit <code>git remote -v</code> kannst du dir nun alle "remote"-Repositories anzeigen lassen, die in deinem Klon eingestellt sind.

Die folgende Grafik zeigt den Git-Datenfluss im Opencaching-Team am Beispiel von drei Entwicklern. Oben siehst du die "remote"-Repositories - das für alle Entwickler als "upstream" dienende Haupt-Repo und die drei "origin" genannten Forks -, und unten die drei lokalen Repositories und die Arbeitsdaten. Die grauen Pfeile zeigen, was du eben gemacht hast: 1. den Fork auf Github.com, und 2. das Erzeugen des lokalen Klons (nicht erschrecken lassen durch die vielen Details - das wird unten alles schrittweise erklärt):

Links und in der Mitte ist der Standard-Git-Workflow zu sehen, rechts ein vereinfachter mit nur einem Branch.

== Daten bearbeiten und hochladen ==

   

Die vorangestellte Nummer ist eine Ticketnummer aus der Todo-Liste. Wenn es keine passende gibt, lässt du sie weg. Verwende nach Möglichkeit englische Namen und Kommentare, denn das OC-Projekt ist international vernetzt. Nun kannst du mit <code>git branch</code> sehen, dass es in deinem lokalen Repo zwei Branches gibt, und der neu angelegte ist aktiv. Mit dem Kommando <code>git checkout Branchname</code> kannst du zwischen den Branches hin- und herwechseln; dabei wird jeweils der Code in den Arbeitsdaten entsprechend ausgetauscht.

  git pull upstream

Wenn du die Änderungen vorgenommen hast, zeigt dir

in roter Farbe an, welche Dateien geändert oder hinzugefügt wurden, und

Als nächstes musst du Git mitteilen, dass die Daten zum aktiven Branch hinzugefügt werden sollen; dies geschieht mit

für alle geänderten und neuen Dateien im aktuellen Verzeichnisbaum (falls du Branches gewechselt hast vergewissere dich evtl. mit <code>git branch</code>, dass du im richtigen bist!) Wahlweise kannst du einzelne Dateien per (Pfad+)Dateiname hinzufügen oder Wildcards verwenden. Dateien löschen kann man mit

Nun zeigt <code>git status</code> in grüner Farbe alle vorbereiteten Änderungen an, und mit

checkst du sie in dein lokales Repository ein. Es öffent sich ein vi-Editor, in dem du einen Kommentar eingeben musst. Schreibe eine aussagekräftige, möglichst englische Zusammenfassung in die erste Zeile, und evtl. zusätzliche Erläuterungen in die weiteren Zeilen. Wenn es nur ein einzeiliger Kommentar sein soll, kannst du dir den Editor auch sparen und den Kommentar direkt angeben mit

Wenn keine neuen Dateien hinzugefügt, sondern nur vorhandene geändert werden sollen, kannst du auch das <code>add</code> mit einbauen, also alle geänderten Daten mit nur einem Befehl einchecken:

Mit

siehst du nun, dass ein neuer ''commit'' in die Versionsgeschichte des aktiven Branches eingefügt wurde. Wahlweise kannst du auch mit <code>git log --stat</code> nochmals alle geänderten Dateien anzeigen lassen.

   

Commits sind das Hauptelement der Arbeit mit Git. Jeder Branch ist eine bestimmte Abfolge von Commits. Verschiedene Branches unterscheiden sich dadurch, welche Commits sie enthalten. Ein Commit ist ein Patch, der eine oder mehrere Dateien verändert, hinzufügt und/oder löscht. Jeder Commit hat einen eindeutigen Hashcode, der im Log angezeigt wird. Über diesen Code lassen sich Commits einzeln herauspicken, rückgängig machen, als Diff anzeigen etc. Dabei genügt die Angabe der ersten paar Zeichen, sofern sie eindeutig sind; üblich als Kurzform sind die ersten 7-10 Zeichen.

Der letzte (neueste) Commit des aktiven Branches hat auch den Name HEAD, der vorletzte HEAD~1, der drittletzte HEAD~2 etc. Mit

kannst du dir z.B. alle Änderungen zwischen aktuellem und vorletztem Codestand anzeigen lassen - also genau das, was du mit deinem letzten <code>commit</code> eingecheckt hast.

Zunächst solltest du deine Daten nochmal auf den aktuellen Stand bringen. Damit ist sichergestellt, dass deine Änderungen mit dem aktuellsten OC-Code funktionieren:

  git fetch upstream

Das erste Kommando aktualisiert deine lokale Kopie der Upstream-Branches (die du mit <code>git branch -r</code> auflisten kannst), bzw. legt diese erstmalig an. Das zweite übernimmt alle neuen ''commits'' aus dem Upstream - also dem OC-Hauptrepository - in deinen aktiven Branch, und zwar fügt es sie ''vor'' deine eigenen Änderungen ein! Deine Änderungen werden auf Basis des aktuellen OC-Codestandes neu aufgesetzt (re-based), d.h. sie werden als Patch auf diesen Codestand angewandt. Beide Kommandos lassen sich auch zu einem zusammenfassen:

'''Verwende niemals ein einfaches <code>git pull</code> (ohne <code>--rebase</code>) in einem Arbeitsbranch!''' Es würde die Versionsgeschichte unlesbar machen und das Zurückverfolgen von Codeänderungen verhindern.

Nun kannst du deinen neuen Branch mit

  <code>git push origin 1234-new-feature</code>  

In diesem Fall war es wahrscheinlich nur ein Test, daher kannst du den Branch nun mit

  git push origin :1234-new-feature

wieder aus deinem Fork löschen. Wenn du ihn auch lokal wieder löschen willst, geht das mit

  git branch -D 1234-new-feature  

==== Zusammenfassung des OC-Git-Standard-Workflow ====

   

==== Commits zusammenfassen ====

   

Wenn du selbst gerade nichts programmieren willst, sondern dir einfach nur ein Update vom OC-Server holen und anschauen, machst du

  git pull upstream  

Wenn du mehrere Branches mit eigenen Änderungen angelegt hast, und diese alle im Zusammenhang testen möchtest, kannst du dir dafür einen Testbranch anlegen:

  git merge 1234-new-feature

  git merge 2345-my-bugfix

* <code>git revert commit-ID</code>

* <code>git push</code>

   

Den Kommentar des letzten, noch nicht "gepushten" Commit korrigieren:  

   

Wenn du z.B. den Branch ''1234-new-feature'' von Entwickler ''heinz'' testen möchtest, kannst du ihn in einen Testbranch bei dir herunterladen. Zunächst musst du ''heinz''' Fork einmalig als weitere Upstream definieren:

Dann legst du bei dir einen Testbranch an, am besten auf Basis aktuellster Daten ...

  git pull upstream

  git checkout -b tolles-heinz-feature  

== Der stable-Branch ==

   

== Vereinfachter Workflow ==

   

verwendet werden! Der vereinfachte Ablauf ist dann:

2. mit <code>git status</code> / <code>git diff</code> lokale Änderungen kontrollieren<br>

3. Änderung mit <code>git add</code> / <code>git commit</code> ins lokale Repo einchecken<br>

5. weiter bei 1, wenn der Code noch nicht fertig ist<br>

7. Pull-Request

== Noch ein paar Gimmicks ==

== Forenbeiträge zu Git ==

[[Kategorie:Entwicklung|Git]]