Home » SWRepository
Archiv der Kategorie: SWRepository
Git Commit-Meldung ändern
Die Meldung des letzten Commits kann mit dem GIT-Ammend angepasst werden:
git commit --amend "Neue meldung, mit 'amend' erstellt"
Leider geht das nur für den letzten Commit. Will man mehrere Commits anpassen kann man das mittels dem Rebase Feature. Zur Erinnerung: Rebase operiert erstens auf dem derzeitigen Branch und einem als Parameter mitgegebenen Ziel-Branch. Vom gemeinsamen Vorfahren der beiden Branches ausgehend werden alle Commits bis zum derzeitigen Branch (als Commit-Kopie)auf den neuen Branch angefügt.
Gehen wir von dieser Ausganslage aus:
C1 -> C2 -> CA1 -> CA2
\-> CB1 -> CB2
Dann ist C2 der gemeinsame Vorfahre von CB2 und CA2. Wenn HEAD (derzeitiger Brach) auf CB2 zeigt und wir
git rebase CA2
machen, dann resultiert:
C1 -> C2 -> CA1 -> CA2 -> CB1cpy -> CB2cpy
\ -> CB1 -> CB2
CB1 und CB2 werden gelöscht, weil nach der Operation weder HEAD noch ein Branch auf diese Commits zeigt.
Nun zurück zu unserem Rename-Problem: Wie können wir Rebase benutzen um Commit-Meldungen zu ändern?
Ausgangslage ist:
C1 -> Cfalsch1 -> Cfalsch2
Wir stellen sicher, dass wir auf Cfalsch2 sind und setzen ab:
git rebase -i C1
Wir fügen also Kopien von Cfalsch1 und Cfalsch2 nochmals as Nachfolger von C1 ein.
Zusätzlich teilen wir GIT mittels opeion „-i“ mit, dass wir das im interaktiven Modus machen wollen.
Der Interaktive Modus erlaub uns (unter anderem) die Commit-Meldungen für die Commit-Kopien zu setzen.
Er tut das in dem er uns in einem VI editor ein batch script editieren lässt. In unserem Beispiel schlägt er folgendes Script mit zwei Kommandos vor:
pick Cfalsch1 Irgend eine falsche Commit-Meldung
pick Cfalsch2 Irgend eine andere falsche Commit-Meldung
Um die für den rebase benutzten Commit-Meldungen anzupassen müssen wir das command file wie folgt anpassen:
r Cfalsch1 Irgend eine verbesserte Commit-Meldung
r Cfalsch2 Irgend eine andere verbesserte Commit-Meldung
Haben wir fertig editiert quittieren wir das in der für VI editoren gebräuchlichen Art:
ESC gefolgt von :wq!
Sodann wird der rebase inclusive unseren Umbenennungen ausgeführt.
Git Workflow
Ressourcen
Wichtigstes: https://rogerdudler.github.io/git-guide/index.de.html
Die Doku: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Tutorial mit typischem WorkFlow: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners
Schnelle Einführung in Git (auf Deutsch): http://www.andreas-schrade.de/2015/03/11/git-kompakte-einfuehrung/
Eigenes Dokument:
A) Remote- und Local-Repository erstellen
- Repository erstellen
a) Lokal
git init
b) Auf GitHub
–> Irgend so ein „Create Repository“-Button. - Repository einchecken
- Ganzes Repository vom Remote-Repository neu als lokal bewirtschaftete Kopie auschecken:
git clone <Pfad zum Remote-Repository>
Nicht zu verwechseln: git pull (Beziehen von neuerungen im Remote-Repo)
B) Typischer Enwickler-Zyklus (entnommen von da.)
- Für die geplanten Änderungen einen Feature-Branch erstellen und dort hin wechseln:
Zuerst noch letzte Änderungen holen:
git pullgit checkout -b iss53 - Code-Änderungen ins lokale Repository committen:
git commit -a -m 'added a new footer [issue 53]'(Dies ist die Abkürzung für git add … gefolgt von git commit …)
3. Feature-Branch mit dem Master mergen
Auf den Master wechseln: git checkout master
Letzte Änderungen des Masters holen: git pull
Mergen: git merge iss53
Ich denke das muss gemacht werden, um die Gefahr zu verkleinern, daass während dem folgenden Schritt – merge auf dem Remote-Repository – Merge-Konflikte auftauchen, die dann dort gelöst werden müssen.
Konflikte lösen: Siehe z.B. hier (suche nach Kapitel „Basic Merge Conflicts“)
3. Änderungen/Feature-Branch ins Remote-Repository schicken und dort vorschlagen:
git push origin iss53
Auf GitHub ist der neue Branch nun sichtbar unter „Branches“. Es wird dort dann auch ein Button „Create pull request“ angeboten.
4. Pull-Request erstellen
Button: „Create pull request“
Nach Ausfüllen und Abschicken des Requests ist er sichtbar unter Button „Pull requests“.
5. Pull-Request approven und mergen:
Via Button „Merge“ wird der Feature-Branch auf den Master gemerget.
Feature-Branch von jemand anderm aus dem Remote-Repo holen
- Anzeigen der verfügbaren Branches im Local- und Remote-Repository
git branch -v -a - Von Repository Master und Branches
git fetch origin
Dann hat man alle Branches des Remote-Repos auch lokal und kann z.B. mit dem Mergen beginnen. Anleitung dazu ist hier.
Lokales Repo: Unterteilung
a) Working Directory:
Dateien auf dem lokalen Rechner, die durch Programmierer verändert werden.
Move von a -> b via: git add
–> Neuer Status der hinzugefügten Dateien: Staged
b) Index / Staging Area:
Ist eine Datei, in der die Aenderungen verzeichnet werden.
Anzeigen, was im Index vorliegt/für commit bereit ist: git status
Move von b -> c via: git commit -m <Aenderungsbeschrieb>
c) Head:
(.git-Verzeichnis) Lokale VCS-Datenbank, mit den der Aenderungshistorie drin (alle Commits) –> 1. .git-Verzeichnis pro Repository
Anzeigen, was im Head ist: git log
Willkürliches Kommando-Listing
- Ausstehende Commits anzeigen (was noch nicht in der Staging-Area und nicht im Feature-Brach ist):
git status - Status des HEAD aschauen:
git log - Branch erstellen
git checkout -b <Branchname> - Branch liefern
git push -u origin <Branchname> - Branch mit Master mergen lokal
1) zum Master wechseln: git checkout master
2) Master aktualisieren: git pull
3) Merge vom Branch: git merge <Branchname> - Zwischen Branches und/oder Master wechseln
git checkout <Branchname> respektive git checkout master - Branches anzeigen:
git branch - Merge bei Konflikten:
Siehe z.B. hier (suche nach Kapitel „Basic Merge Conflicts“) - Update (Beziehen von Neuerungen aus dem Remote-Repository):
git pull