Die noch offenen Fragen zur Versionsverwaltung mit Git sind der
Inhalt der siebenundsiebzigsten Episode des
Anwendungsentwickler-Podcasts. TL;DR Vor jedem Commit prüfe ich mit
git status und git diff, welche Dateien und Inhalte sich geändert
haben. Über den Index wählst du aus, was in deinen nächsten Commit
kommt, dessen Nachricht den fachlichen Grund beschreibt. Mit den
passenden Git-Befehlen kannst du Commits übertragen und ältere
Stände anschauen; Branches und Tags helfen dir dabei, parallel zu
entwickeln und bestimmte Versionen wiederzufinden. Für die Arbeit
in deinem Ausbildungsbetrieb klärst du außerdem, welche
Repositories du bearbeiten darfst und welche Regeln für
Commit-Nachrichten sowie Branches gelten. Kapitelmarken [00:00:20]
Einstieg und Rückblick auf Commits [00:01:10] Änderungen mit git
diff und git status prüfen [00:04:25] Arbeitskopie, Index und
Repository [00:05:40] Änderungen auswählen und kleine Commits
erstellen [00:07:09] Änderungen mit git add aufnehmen und committen
[00:08:04] Commit-Nachrichten eingeben und fachlich begründen
[00:10:34] Den letzten Commit mit amend korrigieren [00:11:45]
Commits mit git push übertragen [00:12:46] Vor dem Push Änderungen
mit git pull holen [00:14:33] Die Historie mit git log anschauen
[00:15:24] Ältere Commits auschecken und die Arbeitskopie
vorbereiten [00:18:21] Commits über ihren Hash auswählen [00:19:27]
Branches und parallele Entwicklung [00:22:04] Entwicklungszweige
durch einen Merge zusammenführen [00:23:18] Automatische Merges und
manuelle Konfliktlösung [00:25:28] Der Hauptzweig master [00:26:03]
Versionen mit Tags benennen [00:28:23] Fragen für deinen
Ausbildungsbetrieb [00:29:11] Einsatzgebiete der Versionsverwaltung
im Betrieb [00:29:56] Git am eigenen Arbeitsplatz einrichten
[00:30:46] Repositories finden und Zugriffsrechte klären [00:31:53]
Betriebliche Regeln für Commit-Nachrichten [00:32:52]
Branching-Strategie und Namen der Branches klären [00:33:46] Git
praktisch kennenlernen und weiterlernen [00:34:53] Shownotes und
Fragen als Markdown-Datei Inhalt Allgemeine Fragen Welche Befehle
musst du ausführen, um dir die aktuellen Änderungen in deiner
Arbeitskopie anzuschauen? Welche Befehle musst du ausführen, um
deine Änderungen zu "committen"? Was ist der Index? Wie ist eine
sinnvolle Commit-Nachricht aufgebaut? Welche Befehle musst du
ausführen, um Inhalte im letzten Commit zu korrigieren/ergänzen?
Welche Befehle musst du ausführen, um deine eigenen Commits in ein
entferntes Repository zu übertragen? Welche Befehle musst du
ausführen, um den Inhalt deiner Arbeitskopie auf einen alten Commit
zurückzusetzen? Welche Befehle musst du ausführen, um dir die
Commit-Historie eines Repositorys anzuschauen? Was ist ein Branch?
Was ist ein Merge? Wie heißt der Standard-Branch in Git? Wie in
SVN? Was ist ein Tag? Fragen zum Ausbildungsbetrieb Wofür setzt
dein Unternehmen Git/SVN ein? Was musst du tun, um Git an deinem
eigenen Arbeitsplatz nutzen zu können? Wo kannst du dir die
Repositorys deines Unternehmens anschauen? Welche besonderen Regeln
für Commit-Nachrichten gibt es bei deinem Unternehmen? Welche
Branching-Strategie verfolgt dein Unternehmen?
Literaturempfehlungen Git Tutorial – The Ultimate Guide (Julen
Pardo) * Links Permalink zu dieser Podcast-Episode RSS-Feed des
Podcasts Wie man eine gute Git-Commit-Nachricht schreibt Ein
sinnvoller Git-Workflow Zusammenfassung Änderungen vor dem Commit
prüfen Vor meinen Commits führe ich git status und anschließend git
diff aus. Damit kontrolliere ich, ob die vorgesehenen Dateien und
Inhalte zum nächsten Commit gehören. git status zeigt dir, welche
Dateien sich geändert haben. git diff zeigt die Unterschiede
zeilenweise mit etwas Kontext. Farblich hervorgehobene Stellen
helfen dir, hinzugefügte oder entfernte Inhalte zu erkennen. Dabei
kannst du auch Schreibfehler und falsche Einrückungen entdecken.
Ein Commit hält einen Versionsstand fest. Dazu gehören die
betroffenen Dateien sowie Metadaten, etwa die Nachricht, das Datum
und der/die Autor:in. Über den Index festlegen, was du committest
Wenn du Dateien in deiner Arbeitskopie bearbeitest, kannst du die
gewünschten Inhalte anschließend in den Index, auch Stage genannt,
aufnehmen. git commit erstellt daraus einen Commit im lokalen
Repository. Du kannst ganze Dateien oder einzelne geänderte Zeilen
auswählen. Hast du in einer Datei an mehreren Features gearbeitet,
lässt sich dadurch für jedes Feature ein eigener Commit erstellen.
Kleine, fachlich zusammenhängende Commits lassen sich leichter
beschreiben. Auch beim späteren Merge mit den Änderungen anderer
Entwickler:innen bleiben sie überschaubar. Für den gezeigten Ablauf
verwendest du: bash git add . --all git commit Mit git add . --all
übernimmst du die Änderungen im aktuellen Verzeichnis in den Index,
einschließlich gelöschter Dateien. Danach erstellt git commit den
Commit und öffnet einen Texteditor für die Commit-Nachricht. Wenn
du die Nachricht direkt auf der Kommandozeile eingeben möchtest,
verwendest du: bash git commit -m "Deine Commit-Nachricht" Den
fachlichen Grund in die Commit-Nachricht schreiben In deiner
Commit-Nachricht hältst du fest, warum du etwas geändert hast. Das
kann eine geänderte Anforderung aus dem Fachbereich sein oder ein
Fehler, den du beheben musstest. Git speichert bereits, welche
Inhalte geändert wurden und wer sie wann bearbeitet hat. Durch
deine Nachricht wird auch der Anlass nachvollziehbar, sodass dein:e
Kolleg:in den Commit später einordnen kann. Weitere Regeln zum
Aufbau und zur Formulierung von Commit-Nachrichten sind in meinen
Shownotes verlinkt. Den letzten Commit korrigieren Wenn dir
unmittelbar nach einem Commit ein Fehler auffällt und du ihn noch
nicht an das entfernte Repository übertragen hast, kannst du ihn
mit folgendem Befehl bearbeiten: bash git commit --amend Damit
lässt sich beispielsweise ein Tippfehler in der Commit-Nachricht
korrigieren. Auch der Inhalt des letzten Commits kann angepasst
werden. Für das beschriebene Vorgehen befindet sich deine
Arbeitskopie zunächst auf dem Stand dieses Commits. Commits an das
Remote Repository übertragen Mit git push überträgst du deine
lokalen Commits an ein entferntes Repository. Git kann mit mehreren
Remote Repositories arbeiten. Als ausdrücklich angegebenes Ziel
wird hier folgendes Beispiel verwendet: bash git push origin master
Bei passend konfiguriertem Git reicht git push aus. Wenn ein:e
Kolleg:in zwischenzeitlich neue Commits übertragen hat, musst du
diese zunächst lokal übernehmen. Git kann deinen Push sonst
ablehnen, weil dir Änderungen aus dem Remote Repository fehlen. Ich
führe deshalb vor jedem Push einen Pull aus: bash git pull git push
Dafür habe ich mir den eigenen Alias git pp eingerichtet, der beide
Schritte nacheinander ausführt. Eigene Aliase werden in einer
Konfigurationsdatei hinterlegt. Die Historie und ältere Stände
anschauen Über git log kannst du die Commit-Historie durchgehen.
Die neuesten Commits stehen oben. Du findest dort Angaben zu den
Autor:innen und zum Zeitpunkt sowie die Commit-Nachrichten.
Möchtest du einen früheren Stand anschauen oder darin etwas
ausprobieren, kannst du dessen Hash aus der Log-Ausgabe übernehmen:
bash git checkout Git holt die Dateien dieses Commits aus deinem
lokalen Repository in die Arbeitskopie. Ein eindeutig zuordenbarer
Anfang des Hashes reicht dafür aus; häufig genügen sechs bis sieben
Zeichen. Für diesen Ablauf brauchst du eine saubere Arbeitskopie,
in der deine Änderungen bereits committet sind. Wenn beim Wechsel
noch offene Änderungen verloren gehen würden, verweigert Git viele
entsprechende Befehle. Mit git checkout kannst du auch wieder einen
neueren Commit auswählen. In Branches parallel entwickeln Wenn du
ein Feature getrennt vom Hauptentwicklungszweig ausprobieren
möchtest, kannst du dafür einen Branch anlegen. Darin entstehen
eigene Commits, während der Hauptzweig weiterentwickelt werden
kann. Später kannst du das Feature übernehmen oder verwerfen.
Branches sind in Git leichtgewichtig, weil sie als Zeiger auf
Commits dienen. Das Anlegen und Wechseln geht dadurch schnell. Eine
mögliche Arbeitsweise besteht darin, für jedes Feature einen
eigenen Branch zu erstellen. Der Hauptzweig trägt im beschriebenen
Ablauf den Namen master. Bei Subversion heißt der entsprechende
Stamm trunk. Branches zusammenführen und Konflikte lösen Durch
einen Merge führst du Entwicklungszweige zusammen. Der beschriebene
Merge-Commit hat zwei Parent-Commits, sodass beide Entwicklungswege
in der Historie verbunden bleiben. Git kann viele Änderungen
automatisch zusammenführen. Das gilt beispielsweise, wenn
unterschiedliche Dateien bearbeitet wurden oder wenn Änderungen
verschiedene Stellen derselben Datei betreffen. Haben zwei
Entwickler:innen dieselbe Zeile unterschiedlich geändert, kann ein
Konflikt entstehen. Dann entscheidest du, welchen Inhalt die Datei
erhalten soll. Dafür kann auch eine neue gemeinsame Lösung
erforderlich sein. Versionen mit Tags benennen Für eine
veröffentlichte Version kannst du dem zugehörigen Commit einen Tag
geben, etwa v1.0. Dieser Name verweist auf einen bestimmten Stand
und erleichtert dir, ihn später wiederzufinden. bash git tag v1.0
git checkout v1.0 Der Tag-Name lässt sich beim Checkout als Verweis
auf die gewünschte Version angeben. Tags können auch in der
Log-Ausgabe erscheinen. Fünf Fragen für deinen Ausbildungsbetrieb
Diese Fragen habe ich meinem IT-Azubi mitgegeben, damit er die
betrieblichen Abläufe mit Kolleg:innen klärt. Die Antworten
bekommst du direkt in deinem Ausbildungsbetrieb. Wofür wird
Versionsverwaltung eingesetzt? Kläre, welche Software eingesetzt
wird und welche Inhalte damit versioniert werden. In meinem Betrieb
werden beispielsweise auch Dokumente im Fachbereich mit Subversion
verwaltet. Git kommt unter anderem für Quellcode und Textdokumente
zum Einsatz. Wie richtest du deinen Arbeitsplatz ein? Frage dein:e
Ausbilder:in oder eine:n Administrator:in,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.