Difference between revisions of "De/Git"
From GnuCash
({{*Url}} -> {{URL:*}}; use {{URL:git}}, {{URL:GH}}, …) |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | Eine kleine Einführung | + | [[Category:De|Git]][[Category:Git]] |
| − | + | Eine kleine Einführung zur Verwendung der ''Versionsverwaltung'' Git im GnuCash-Projekt, basierend auf [[An Introduction to Git]] und [[Git]], aber mehr aufgabenorientiert. | |
| + | ;Literatur: Deutsches Handbuch [{{URL:git-scm}}book/de/v2/ Pro Git v2] | ||
== Was ist …== | == Was ist …== | ||
=== Git === | === Git === | ||
| − | [{{URL:wp | + | [{{URL:wp|de}}Git Git] ist eine ursprünglich von Linus Torvalds entwickelte '''[{{URL:wp|de}}Versionsverwaltung#Verteilte_Versionsverwaltung Verteilte Versionsverwaltung]''' (DVCS), um den Linux Quelltext ohne zentralen Server zu verwalten. Aktuelle Versionen und vielfältige Online-Dokumentation gibt es auf [{{URL:git-scm}} Git's Heimat]. Insbesondere ''Pro Git'' von Scott Chacon steht in vielen Sprachen kostenlos als [{{URL:git-scm}}book/de/ Git Book] zur Verfügung. |
Inzwischen bieten die meisten [[:Category:IDE|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 <tt>git gui</tt> oder <tt>gitk</tt>. | Inzwischen bieten die meisten [[:Category:IDE|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 <tt>git gui</tt> oder <tt>gitk</tt>. | ||
=== Github === | === Github === | ||
| − | [{{URL:wp | + | [{{URL:wp|de}}GitHub GitHub] (GH) ist ein netzbasierter Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte. Auch dort gibt es gute Dokumentation wie etwa [{{URL:GH|help.}}articles/good-resources-for-learning-git-and-github/ Good Resources for Learning Git and GitHub]. |
| − | Dort befinden sich die [{{URL: | + | Dort befinden sich die [{{URL:git}} öffenlichen Mirror] der verschiedenen Komponenten (oder Repositorien in git-isch) von GnuCash, wo man sich auch alles schn mal ''ansehen'' kann. |
=== Zweige in Git === | === Zweige in Git === | ||
| Line 18: | Line 19: | ||
:;master: ist für neue Merkmale und führt zur Release {{BetaSeries}} >= {{BetaVersion}}. | :;master: ist für neue Merkmale und führt zur Release {{BetaSeries}} >= {{BetaVersion}}. | ||
:Siehe [[Release Schedule]]. Die ''Releases'' werden vom Releasemanager mit einem git '''tag''' markiert. | :Siehe [[Release Schedule]]. Die ''Releases'' werden vom Releasemanager mit einem git '''tag''' markiert. | ||
| − | Die '''Website''' hat einen zusätzlichen Zweig <tt>beta</tt>, mit dem man Änderungen auf der [{{ | + | Die '''Website''' hat einen zusätzlichen Zweig <tt>beta</tt>, mit dem man Änderungen auf der [{{URL:www}}beta/ Beta-Version der Website] testen kann, bevor man sie in <tt>master</tt> veröffentlicht. |
In den '''anderen Komponenten''' ist lediglich der Zweig <tt>master</tt> aktiv. | In den '''anderen Komponenten''' ist lediglich der Zweig <tt>master</tt> aktiv. | ||
| − | In ''einigen Komponenten'' gibt es noch diverse '''andere Zweige'''. Das sind aber i.d.R. Relikte aus der Zeit, als das Projekt noch [{{URL:wp | + | In ''einigen Komponenten'' gibt es noch diverse '''andere Zweige'''. Das sind aber i.d.R. Relikte aus der Zeit, als das Projekt noch [{{URL:wp|de}}Apache_Subversion SVN] oder zuvor [{{URL:wp|de}}Concurrent_Versions_System CSV] verwendete. |
Idealerweise arbeitet man ''privat'' immer erstmal auf Zweigen wie <tt>Bug_1234567</tt> oder zumindest <tt>work</tt>, die auf einem der Hauptzweige basieren, damit man sich nicht mit anderen Entwicklern in's Gehege kommt. | Idealerweise arbeitet man ''privat'' immer erstmal auf Zweigen wie <tt>Bug_1234567</tt> oder zumindest <tt>work</tt>, die auf einem der Hauptzweige basieren, damit man sich nicht mit anderen Entwicklern in's Gehege kommt. | ||
| Line 29: | Line 30: | ||
:;Konvention: Die mit $ beginnenden Variablen durch sinnvolle Werte ersetzen. | :;Konvention: Die mit $ beginnenden Variablen durch sinnvolle Werte ersetzen. | ||
Aktiven Zweig wechseln: <syntaxhighlight lang="sh" inline> | Aktiven Zweig wechseln: <syntaxhighlight lang="sh" inline> | ||
| − | git checkout $ | + | git checkout $BRANCH |
</syntaxhighlight> | </syntaxhighlight> | ||
| Line 43: | Line 44: | ||
maint: A---C-- | maint: A---C-- | ||
</pre> | </pre> | ||
| − | :;Variante 1: | + | :;Variante 1 - merge: Historie bleibt erhalten, ist aber unübersichtlicher. <syntaxhighlight lang="sh" inline> |
git checkout maint; git merge work | git checkout maint; git merge work | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| Line 51: | Line 52: | ||
maint: A---C---D | maint: A---C---D | ||
</pre> | </pre> | ||
| − | :;Variante 2: | + | :;Variante 2 - rebase: Historie wird linearisiert |
::Schritt 1: <syntaxhighlight lang="sh" inline> | ::Schritt 1: <syntaxhighlight lang="sh" inline> | ||
git checkout work; git rebase maint | git checkout work; git rebase maint | ||
| Line 61: | Line 62: | ||
</pre> | </pre> | ||
::Schritt 2: <syntaxhighlight lang="sh" inline> | ::Schritt 2: <syntaxhighlight lang="sh" inline> | ||
| − | git checkout maint; git | + | git checkout maint; git merge work |
</syntaxhighlight> | </syntaxhighlight> | ||
| + | ::;Anmerkung: Git antwortet was mit <tt>fast forward</tt>, das Ergbenis ist also dasselbe als hätte man <tt>git rebase …</tt> verwendet. <tt>git merge …</tt> ist sicherer für den Fall, daß man zuvor was vergessen hat. | ||
<pre>Zweig, Commits: | <pre>Zweig, Commits: | ||
work: B'=D (maint) | work: B'=D (maint) | ||
| Line 68: | Line 70: | ||
maint: A---C | maint: A---C | ||
</pre> | </pre> | ||
| − | + | ;Anwendungsfälle: | |
| − | *Solange ein Zweig noch nicht veröffentlicht wurde, | + | *Solange ein Zweig noch ''nicht veröffentlicht'' wurde, '''rebas'''i'''e'''re den Arbeitszweig auf den aktuellen Hauptzweig. |
| − | *Auch bei einem als PR veröffentlichen Zweig verwende rebase. Allerdings ist anschließend ein force push erforderlich. | + | *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. | + | *Von dem, was breits im Hauptrepositorium ist, sollte die Historie nie verändert werden. Es bleibt also nur ein '''merge'''. Diese Aufgabe obliegt aber eher den Maintainern. |
== Für jeden Zweck die passende Konfiguration == | == Für jeden Zweck die passende Konfiguration == | ||
| − | ===Stufe 1: Github-Klon für triviale Patches=== | + | ===Stufe 1: Github-Klon für einzelne triviale Patches=== |
:;Voraussetzung: Web-Browser-Führerschein | :;Voraussetzung: Web-Browser-Führerschein | ||
| − | # Nachdem man dort ein '''Konto angelegt''' hat, | + | # Nachdem man dort ein '''Konto angelegt''', bzw. sich angemeldet hat, |
| − | # kann man GnuCash-'''Repositorien''' | + | # kann man [{{URL:git}}GnuCash-'''Repositorien''' in GitHub's Web-Interface] über den grünrn <tt>Code</tt>-Knopf '''klonen'''. |
# Im eigenen Klone kann man dann ''Dateien verändern'' wie z.B. einen Tipfehler in der Dokumentation beheben. | # Im eigenen Klone kann man dann ''Dateien verändern'' wie z.B. einen Tipfehler in der Dokumentation beheben. | ||
# Dann erstellt man eine ''Pull-Request'' (PR). | # Dann erstellt man eine ''Pull-Request'' (PR). | ||
# Falls einen dann einer der Kern-Entwickler um ''Anpassugen'' bittet, sind die dann vorzunehmen. | # Falls einen dann einer der Kern-Entwickler um ''Anpassugen'' bittet, sind die dann vorzunehmen. | ||
| − | # 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. | + | # Nachdem die PR gemerged oder abgelehnt wurde, kann man ''den Klon wieder löschen''. Um für den nächsten Patch wieder einen aktuellen Klone zu bekommen, beginne wieder mit Schritt 2. Es sei denn, Github, baut eines Tages einen Rebase-Befehl in seine Oberfläche ein. |
| − | ===Stufe 2: Lokaler Klon zum | + | ===Stufe 2: Lokaler Klon zum Experimentieren=== |
| + | Nachdem man git installiert hat, konfiguriert man am Besten gleich seine | ||
| + | ;Kontaktdaten: <syntaxhighlight lang="sh"> | ||
| + | git config --global user.name "John Doe" | ||
| + | git config --global user.email johndoe@example.com | ||
| + | </syntaxhighlight> | ||
| + | ;Filter: welche Dateinamensmuster git ignorieren soll. Diese gibt es | ||
| + | :;projekt-/ordnerspezifisch: <tt>.gitignore</tt> für Artefakte Projekt-interner Werkzeuge wie früher Autotools, oder | ||
| + | :;benutzerspezifisch: <tt>$HOME/.config/git/ignore</tt><ref>offiziell "$XDG_CONFIG_HOME/git/ignore", where $XDG_CONFIG_HOME defaults to "$HOME/.config"</ref> für alle Artefakte der von Ihnen verwendeten Werkzeuge, die man nicht zum Repo hinzufügen möchte. | ||
| + | :Beispiel eines Eclipse-Benutzers: <syntaxhighlight lang="kconfig"> | ||
| + | # Backups: | ||
| + | *~ | ||
| + | *.bak | ||
| + | *.orig | ||
| + | # Eclipse: | ||
| + | /.settings/ | ||
| + | /.autotools | ||
| + | /.cproject | ||
| + | /.project | ||
| + | /nbproject | ||
| + | </syntaxhighlight> | ||
TBD | TBD | ||
Latest revision as of 05:44, 30 January 2024
Eine kleine Einführung zur Verwendung der Versionsverwaltung Git im GnuCash-Projekt, basierend auf An Introduction to Git und Git, aber mehr aufgabenorientiert.
- Literatur
- Deutsches Handbuch Pro Git v2
Contents
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.10
- master
- ist für neue Merkmale und führt zur Release 5.9xx >= 5.900.
- Siehe Release Schedule. Die Releases werden vom Releasemanager mit einem git tag markiert.
Die Website hat einen zusätzlichen Zweig beta, mit dem man Änderungen auf der Beta-Version der Website testen kann, bevor man sie in master veröffentlicht.
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 $BRANCH
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übersichtlicher.
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 merge work- Anmerkung
- Git antwortet was mit fast forward, das Ergbenis ist also dasselbe als hätte man git rebase … verwendet. git merge … ist sicherer für den Fall, daß man zuvor was vergessen hat.
- Schritt 2:
Zweig, Commits:
work: B'=D (maint)
/
maint: A---C
- Anwendungsfälle
- 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. Es bleibt also nur ein merge. Diese Aufgabe obliegt aber eher den Maintainern.
Für jeden Zweck die passende Konfiguration
Stufe 1: Github-Klon für einzelne triviale Patches
- Voraussetzung
- Web-Browser-Führerschein
- Nachdem man dort ein Konto angelegt, bzw. sich angemeldet hat,
- kann man Repositorien in GitHub's Web-Interface über den grünrn Code-Knopf klonen.
- Im eigenen Klone kann man dann Dateien verändern wie z.B. einen Tipfehler in der Dokumentation beheben.
- Dann erstellt man eine Pull-Request (PR).
- Falls einen dann einer der Kern-Entwickler um Anpassugen bittet, sind die dann vorzunehmen.
- Nachdem die PR gemerged oder abgelehnt wurde, kann man den Klon wieder löschen. Um für den nächsten Patch wieder einen aktuellen Klone zu bekommen, beginne wieder mit Schritt 2. Es sei denn, Github, baut eines Tages einen Rebase-Befehl in seine Oberfläche ein.
Stufe 2: Lokaler Klon zum Experimentieren
Nachdem man git installiert hat, konfiguriert man am Besten gleich seine
- Kontaktdaten
-
git config --global user.name "John Doe" git config --global user.email johndoe@example.com - Filter
- welche Dateinamensmuster git ignorieren soll. Diese gibt es
- projekt-/ordnerspezifisch
- .gitignore für Artefakte Projekt-interner Werkzeuge wie früher Autotools, oder
- benutzerspezifisch
- $HOME/.config/git/ignore[1] für alle Artefakte der von Ihnen verwendeten Werkzeuge, die man nicht zum Repo hinzufügen möchte.
- Beispiel eines Eclipse-Benutzers:
# Backups: *~ *.bak *.orig # Eclipse: /.settings/ /.autotools /.cproject /.project /nbproject
- ↑ offiziell "$XDG_CONFIG_HOME/git/ignore", where $XDG_CONFIG_HOME defaults to "$HOME/.config"
