Git Tipps: Unterschied zwischen den Versionen
(12 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
+ | == Grundprinzip == | ||
+ | |||
+ | Eine veränderte oder neue Datei kann sich in 3 Zuständen befinden: | ||
+ | |||
+ | * modified (verändert) bzw. neu erstellt | ||
+ | |||
+ | * staged (für Commit vorbereitet) | ||
+ | |||
+ | * committed (Commit ausgeführt, gesichert) | ||
+ | |||
== Einstellungen == | == Einstellungen == | ||
Zeile 4: | Zeile 14: | ||
git config --global diff.tool vimdiff | git config --global diff.tool vimdiff | ||
− | + | Bestätigung beim Editieren jeder Datei ausschalten:<br /> | |
git config --global difftool.prompt false | git config --global difftool.prompt false | ||
Zeile 12: | Zeile 22: | ||
Anschliessend können mit folgenden Befehlen zwei Fenster geöffnet werden zum Vergleich der Änderungen: | Anschliessend können mit folgenden Befehlen zwei Fenster geöffnet werden zum Vergleich der Änderungen: | ||
− | git d (Änderungen, die noch nicht in der Staging Area sind anzeigen) | + | git d [Dateiname] (Änderungen, die noch nicht in der Staging Area sind anzeigen) |
+ | |||
+ | git d --cached [Dateiname] (Änderungen in der Staging Area anzeigen) | ||
+ | |||
+ | == Commits vorbereiten == | ||
+ | * git add [Dateiname] Datei "Dateiname" in Staging Area übernehmen | ||
+ | * git reset [Dateiname] Datei "Dateiname" aus Staging Area entfernen, aber als veränderte Datei behalten (Umkehrung von git add) | ||
+ | * git rm [Dateiname] ...Erklärung fehlt noch... | ||
+ | |||
+ | Änderungen, die nicht committed werden sollen, sichern, bevor z.B. auf einen anderen branch gewechselt werden kann: | ||
+ | |||
+ | * git stash alle Änderungen sichern und verstecken | ||
+ | * git stash show die versteckten gesicherten Änderungen anzeigen | ||
+ | * git stash pop die versteckten gesicherten Änderungen zurückholen und die Sicherung löschen | ||
+ | * git stash apply die versteckten gesicherten Änderungen zurückholen und die Sicherung behalten | ||
+ | |||
+ | == Commits aufspalten und neu zusammensetzen == | ||
+ | |||
+ | ACHTUNG: NIE in einer produktiven Version durchführen!<br /> | ||
+ | |||
+ | * git checkout BranchX zu gewünschtem Branch wechseln | ||
+ | * git checkout -b SicherungBranchX eine Sicherungskopie des Branches erstellen | ||
+ | * git checkout BranchX wieder zum gewünschten Branch zurückkehren | ||
+ | |||
+ | * Mit 'git log' oder tig (siehe unten) den HASH des Commits herausfinden | ||
+ | * git rebase -i HASH^ (wichtig das ^ nach dem HASH einfügen, da damit der Commit vorher ausgewählt wird) | ||
+ | * im neuen Fenster bei dem Commit, der geändert werden soll 'pick' durch 'edit' ersetzen und abspeichern | ||
+ | * git reset HEAD^<br /> | ||
+ | Nun können die einzelnen Dateien, die geändert wurden der Reihe nach neu editiert werden: | ||
+ | * git add --patch Dateiname | ||
+ | * bei langen Dateien ev. mit der Eingabe von 's' diese in kleinere Abschnitte splitten | ||
+ | * mit der Eingabe von 'e' gewünschte Abschnitte editieren und nach Anleitung abändern | ||
+ | * mit der Eingabe von 'n' Abschnitte überspringen, von denen nichts übernommen werden soll | ||
+ | |||
+ | Vor dem Commit überprüfen, ob die Änderungen, die gemacht wurden korrekt sind: | ||
+ | * git d --cached<br /> | ||
+ | Anschliessend ersten Commit ausführen: | ||
+ | * git commit -c ORIG_HEAD (Autor vom früheren Commit übernehmen) | ||
+ | * Commit Message anpassen | ||
+ | * speichern (z.B. im vim: :wq)<br /> | ||
+ | Das gleiche für weitere Commits wiederholen.<br /> | ||
+ | * Dateien, die komplett übernommen werden sollen mit 'git add Dateiname' hinzufügen<br /> | ||
+ | |||
+ | Das Rebase abschliessen mit:<br /> | ||
+ | * git rebase --continue<br /> | ||
+ | |||
+ | Kontrollieren, ob alles korrekt verlaufen ist:<br /> | ||
+ | * git diff SicherungBranchX<br /> | ||
+ | Hier sollte keine Ausgabe kommen, da ja nur ein Commit auf mehrere Commits aufgeteilt wurden und nichts am Code verändert wurde. | ||
+ | |||
+ | Wenn etwas beim Rebase schief läuft:<br /> | ||
+ | * git rebase --abort | ||
− | git | + | == Hochladen der neuen Branches auf github == |
+ | * Eintragen des neuen Repositorys in die git Konfigurationer(.git/config) : | ||
+ | [remote "kividesign"] | ||
+ | fetch = +refs/heads/*:refs/remotes/kividesign/* | ||
+ | url = https://github.com/arevamp/kivitendo-design4.0.git | ||
+ | * Erstes Pushen des eigenen Branches: | ||
+ | git push --set-upstream kividesign eigener-branch | ||
+ | * Weiteres Pushen: | ||
+ | git push -f kividesign eigener-branch | ||
+ | * Koordination, wer welche Commits bearbeitet: | ||
+ | https://github.com/arevamp/kivitendo-design4.0/wiki | ||
== Weitere Werkzeuge == | == Weitere Werkzeuge == |
Aktuelle Version vom 5. April 2019, 10:31 Uhr
Grundprinzip
Eine veränderte oder neue Datei kann sich in 3 Zuständen befinden:
- modified (verändert) bzw. neu erstellt
- staged (für Commit vorbereitet)
- committed (Commit ausgeführt, gesichert)
Einstellungen
vim als Editor für Git einstellen:
git config --global diff.tool vimdiff
Bestätigung beim Editieren jeder Datei ausschalten:
git config --global difftool.prompt false
Alias d für difftool setzen:
git config --global alias.d difftool
Anschliessend können mit folgenden Befehlen zwei Fenster geöffnet werden zum Vergleich der Änderungen:
git d [Dateiname] (Änderungen, die noch nicht in der Staging Area sind anzeigen)
git d --cached [Dateiname] (Änderungen in der Staging Area anzeigen)
Commits vorbereiten
- git add [Dateiname] Datei "Dateiname" in Staging Area übernehmen
- git reset [Dateiname] Datei "Dateiname" aus Staging Area entfernen, aber als veränderte Datei behalten (Umkehrung von git add)
- git rm [Dateiname] ...Erklärung fehlt noch...
Änderungen, die nicht committed werden sollen, sichern, bevor z.B. auf einen anderen branch gewechselt werden kann:
- git stash alle Änderungen sichern und verstecken
- git stash show die versteckten gesicherten Änderungen anzeigen
- git stash pop die versteckten gesicherten Änderungen zurückholen und die Sicherung löschen
- git stash apply die versteckten gesicherten Änderungen zurückholen und die Sicherung behalten
Commits aufspalten und neu zusammensetzen
ACHTUNG: NIE in einer produktiven Version durchführen!
- git checkout BranchX zu gewünschtem Branch wechseln
- git checkout -b SicherungBranchX eine Sicherungskopie des Branches erstellen
- git checkout BranchX wieder zum gewünschten Branch zurückkehren
- Mit 'git log' oder tig (siehe unten) den HASH des Commits herausfinden
- git rebase -i HASH^ (wichtig das ^ nach dem HASH einfügen, da damit der Commit vorher ausgewählt wird)
- im neuen Fenster bei dem Commit, der geändert werden soll 'pick' durch 'edit' ersetzen und abspeichern
- git reset HEAD^
Nun können die einzelnen Dateien, die geändert wurden der Reihe nach neu editiert werden:
- git add --patch Dateiname
- bei langen Dateien ev. mit der Eingabe von 's' diese in kleinere Abschnitte splitten
- mit der Eingabe von 'e' gewünschte Abschnitte editieren und nach Anleitung abändern
- mit der Eingabe von 'n' Abschnitte überspringen, von denen nichts übernommen werden soll
Vor dem Commit überprüfen, ob die Änderungen, die gemacht wurden korrekt sind:
- git d --cached
Anschliessend ersten Commit ausführen:
- git commit -c ORIG_HEAD (Autor vom früheren Commit übernehmen)
- Commit Message anpassen
- speichern (z.B. im vim: :wq)
Das gleiche für weitere Commits wiederholen.
- Dateien, die komplett übernommen werden sollen mit 'git add Dateiname' hinzufügen
Das Rebase abschliessen mit:
- git rebase --continue
Kontrollieren, ob alles korrekt verlaufen ist:
- git diff SicherungBranchX
Hier sollte keine Ausgabe kommen, da ja nur ein Commit auf mehrere Commits aufgeteilt wurden und nichts am Code verändert wurde.
Wenn etwas beim Rebase schief läuft:
- git rebase --abort
Hochladen der neuen Branches auf github
- Eintragen des neuen Repositorys in die git Konfigurationer(.git/config) :
[remote "kividesign"] fetch = +refs/heads/*:refs/remotes/kividesign/* url = https://github.com/arevamp/kivitendo-design4.0.git
- Erstes Pushen des eigenen Branches:
git push --set-upstream kividesign eigener-branch
- Weiteres Pushen:
git push -f kividesign eigener-branch
- Koordination, wer welche Commits bearbeitet:
https://github.com/arevamp/kivitendo-design4.0/wiki
Weitere Werkzeuge
tig
Alternative zu git log
Beispiele:
- tig: zeigt zeilenweise die letzten Commits an
- tig branchname: zeigt die letzten Commits von Branch branchname
- Enter-Taste: Öffnet den gerade ausgewählten Commit in einem Fenster unterhalb
- /muster: sucht in allen Commits nach "muster" → Taste n für weitersuchen
- C: cherry-pick falls anderer Branch geöffnet ist