Git Tipps: Unterschied zwischen den Versionen

Aus revampedia
(Die Seite wurde neu angelegt: «== Einstellungen == vim als Editor für Git einstellen:<br /> git config --global diff.tool vimdiff git config --global difftool.prompt false Alias d für di…»)
 
 
(13 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
 +
 
 +
== 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 ==
  
git d --cached (Änderungen in der Staging Area anzeigen)
+
=== tig ===
 +
Alternative zu git log<br />
 +
Beispiele:
 +
* tig: zeigt zeilenweise die letzten Commits an<br />
 +
* 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

Aktuelle Version vom 5. April 2019, 11: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