tov’s Blog

Mal ein Versuch meinen privaten GIT-Arbeitszyklus zu dokumentieren…

Dieses Post wird wohl ab und zu verändert werden

Arbeitszyklus mit GIT

Start

1. Entweder neu erstellen eines Repositories oder kopieren:
   1. Erstellen
      1. mkdir Name
      2. cd Name
      3. git init
   2. Kopieren
      1. git clone username@hostname:/PFAD/Name
2. edit/compile/fix
3. Commit
   1. git add . (fügt alle neuen Dateien hinzu)
   2. git commit -a -m „KOMMENTAR“ 
   3. git push (zurück ins Repository)

Wenn das Repository ein sogenanntes „non-bare“ Repository ist (also mit Working-Tree), werden die Änderungen dort _nicht_ ins Working Directory eingetragen. Wenn dort nichts verändert wurde (also kein Merge notwendig ist), kann mittels

git reset –hard (http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73)

der neue Sourcecode aktiviert werden. 

Alternative: Benutzen eines „post-update-hooks“

http://utsl.gen.nz/git/post-update

Eintragen in .git/hooks/post-update (auf dem Ziel-Repository)

1. auch: http://www.mail-archive.com/git@vger.kernel.org/msg03458.html

Damit reicht dann das „push“ von der Remote-Maschine, um ein Merge des Repositories zu erreichen!

Wenn im Master Repository (also dem, in das gerade gepushed wurde) vorher kein Commit durchgeführt wurde, werden die lokalen Änderungen gestashed

http://www.kernel.org/pub/software/scm/git/docs/git-stash.html

Mittels 

git stash apply

können die ebenfalls reingemerged werden

Rollback nach einem fehlgeschlagenen Merge

git pull blafasel
hat mal wieder (OK… Das kommt nicht so häufig vor; Es ist ja schließlich nicht Subversion ) diverse Konflikte gemeldet und nur weil vorher lokal irgendetwas vergessen wurde.
Ausweg:

git reset --hard
Alles ist wieder gut (wie vorher).