Difference between revisions of "De/Git"

Revision as of 01:44, 6 April 2021

Eine kleine Einführung zu Git basierend auf An Introduction to Git und Git, aber mehr aufgabenorientiert.

Was ist …

Git

Git ist eine ursprünglich von Linus Torvalds entwickelte Verteilte Versionsverwaltung (DVCS), um den Linux Quelltext ohne zentralen Server zu verwalten. Aktuelle Versionen und vielfältige Online-Dokumentation gibt es auf Git's Heimat. Insbesondere Pro Git von Scott Chacon steht in vielen Sprachen kostenlos als Git Book zur Verfügung.

Inzwischen bieten die meisten IDEs eine gute Integration von Git, es stehen aber auch viele Werkzeuge für die befehlszeile zur Verfügung. Hilfreich ist es mindestens eins für die graphische Anzeige der verschiedenen Zweige zu haben wie git gui oder gitk.

Github

GitHub (GH) ist ein netzbasierter Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte. Auch dort gibt es gute Dokumentation wie etwa Good Resources for Learning Git and GitHub.

Dort befinden sich die öffenlichen Mirror der verschiedenen Komponenten (oder Repositorien in git-isch) von GnuCash, wo man sich auch alles schn mal ansehen kann.

Zweige in Git

Für Programm und Dokumentation gibt es jeweils 2 aktive Zweige (branchs):

Maint

ist für Bugfixes und führt zur Release 5.xx > 5.9

Master

ist für neue Merkmale und führt zur Release 5.9xx >= 5.900.

Siehe Release Schedule.

In den anderen Komponenten ist lediglich der Zweig Master aktiv.

In einigen Komponenten gibt es noch diverse andere Zweige. Das sind aber i.d.R. Relikte aus der Zeit, als das Projekt noch SVN oder zuvor CSV verwendete.

Idealerweise arbeitet man privat immer erstmal auf Zweigen wie Bug_1234567 oder zumindest work, die auf einem der Hauptzweige basieren, damit man sich nicht mit anderen Entwicklern in's Gehege kommt.

Verzweigen, aktualisieren und vereinen

Konvention

Die mit $ beginnenden Variablen durch sinnvolle Werte ersetzen.

Aktiven Zweig wechseln: git checkout $SELECTION

Neuen Zweig basiered auf aktuellem erstellen: git branch $NEW

Aktualisieren und Vereinen

Merge vs. rebase:

Ausgangssituation

parallele Änderungen auf beiden Zweigen

Zweig, Commits:
work:    B---
        /     
maint: A---C--

Variante 1

merge, Historie bleibt erhalten, ist aber unübersichtlich. git checkout maint; git merge work

Zweig, Commits:
work:    B---
        /     \
maint: A---C---D

Variante 2

rebase, Historie wird linearisiert

Schritt 1: git checkout work; git rebase maint

Zweig, Commits:
work:        B'-
            /
maint: A---C-

Schritt 2: git checkout maint; git rebase work

Zweig, Commits:
work:        B'=D (maint)
            /
maint: A---C

Im allgemeinen gilt:

• Solange ein Zweig noch nicht veröffentlicht wurde, rebasiere den Arbeitszweig auf den aktuellen Hauptzweig.
• Auch bei einem als PR veröffentlichen Zweig verwende rebase. Allerdings ist anschließend ein force push erforderlich.
• Von dem, was breits im Hauptrepositorium ist, sollte die Historie nie verändert werden.

Für jeden Zweck die passende Konfiguration

Stufe 1: Github-Klon für triviale Patches

Voraussetzung

Web-Browser-Führerschein

1. Nachdem man dort ein Konto angelegt hat,
2. kann man GnuCash-Repositorien über GitHub's Web-Interface klonen.
3. Im eigenen Klone kann man dann Dateien verändern wie z.B. einen Tipfehler in der Dokumentation beheben.
4. Dann erstellt man eine Pull-Request (PR).
5. Falls einen dann einer der Kern-Entwickler um Anpassugen bittet, sind die dann vorzunehmen.
6. Nachdem die PR gemerged oder abgelehnt wurde, kann man den Klon wieder löschen. Es sei denn, Github, baut eines Tages einen Rebase-Befehl in seine Oberfläche ein.

Stufe 2: Lokaler Klon zum Spielen

TBD