====== GitHub ======

===== Wichtige Commands =====

<code>
svn checkout: git clone linkZuRepo
svn commit: git commit (-a)
svn up: git pull (zuerst alles commiten!)
svn switch: git checkout (-b) nameDesBranches
svn status: git status (-s)
svn info: git show
</code>

===== Aller Anfang =====

Damit man nicht immer user/pass eingeben muss, kann man [[https://help.github.com/articles/generating-ssh-keys/|bei github einen public key eintragen]] und [[https://help.github.com/articles/about-two-factor-authentication/|2 factor auth zu aktivieren]] schadet auch nicht :-)

Damit commits als github User aufscheinen muss man die Mailadresse ([[https://help.github.com/articles/adding-an-email-address-to-your-github-account/|die auch github wissen muss]]) so lokal konfigurieren: <code>git config --global user.email "XYZ@technikum-wien.at"</code>

===== git commit (-a) =====

Um etwas zu commiten muss es zum "git index" geaddet werden (''git add''). Diese Dateien in der aktuellen Version sind dann im index ("staged for commit"). Ändert man noch etwas bei einer dieser Dateien muss man sie **nochmal** adden.

''git commit'' commited alle Änderungen die im index ("staged") sind.

''-a'' erspart das adden. Es staged und commited alle Dateien die schon mal im repository vorhanden waren.

===== git pull =====

Holt sich die Änderungen (''git fetch'') von den remotes (github) und merged (''git merge'') es ins lokale repository in den aktuellen branch. D.h. wenn es Änderungen gibt, ist ''git pull'' auch automatisch gleich ein commit.

Damit man mit den lokalen Änderungen nicht durcheinander, kommt sollte vorher alles lokale **commited** werden.

Falls bereits lokale Änderungen im Master vorhanden sind wird automatisch ein Merge Commit erzeugt. Um das zu verhindern kann <code>git pull --rebase</code> verwendet werden.

===== Alternative zu merge commit: git rebase =====

[[http://matthew-brett.github.io/pydagogue/rebase_without_tears.html|Rebase without tears]]

Hintergrund: Man arbeitet lokal an einem Fix/Feature, hat bereits eine history (ein paar commits) und benötigt jetzt eine Änderung die irgendjemand gepusht hat. rebasing erzeugt eine sauberere history als ständige merge commits.

Hab es gerade so ausprobiert und geschafft \o/:

Wechsel auf den Branch. Hol die letzten Änderungen von github vom Branch "master" und rebase deine Änderungen darauf.

<code>
# Zuerst master updaten
git checkout master
git pull

# Jetzt den branch rebasen
git checkout mein-feature-branch
git rebase master
</code>

Merge (Fast Forward) die Änderungen vom Branch. Push.

<code>
git checkout master
git merge mein-feature-branch
git push
</code>

In diesem Fall wird die gesamte history (alle commits) vom branch in den master mitgenommen. Wenn das nicht gewollt ist, kann man dem merge-Befehl noch den Parameter ''%%--%%squash'' mitgeben. Muss dann aber noch einen extra commit durchführen. Git befüllt in diesem Fall die commit message bereits mit allen möglichen Infos.

<code>
git checkout master
git merge --squash mein-feature-branch
git commit -a
git push
</code>

Wenn man danach mit dem branch noch weiter arbeiten möchte, muss man den Startpunkt ändern (wo zweigt der branch ab).

<code>
git checkout master
git branch -f mein-feature-branch <letzterCommit>
</code>

Oder branch einfach löschen.

<code>
git branch -D mein-feature-branch
</code>

Soll ein neuer lokaler Branch für alle zur Verfügung stehen, kann dieser mit folgendem Befehl auf Github gepusht werden
<code>
git push origin mein-feature-branch
</code>

Damit danach ein status/pull/push korrekt funktioniert muss noch folgender Befehl ausgeführt werden
<code>
git branch --set-upstream-to=origin/mein-feature-branch mein-feature-branch
</code>

===== git checkout (-b) nameDesBranches =====

''git checkout nameDesBranches'' wechselt auf einen bestehenden branch mit Namen "nameDesBranches".

Wenn man einen neuen branch anfangen will kann man ihn mit ''-b'' erstellen und direkt hin switchen.

===== git status (-s) =====

Ist sehr detailliert. ''-s'' kürzt es ab.

===== git tag -a nameDesTags =====

Markiert eine bestimmte Version/Revision. Hilfreich zB wenn man festhalten will welche Version aktuell auf Produktion ist. Ermöglicht dann auch einen einfachen Rollback bei Fehlern zu vorigen Versionen.

===== git stash =====

Will man zB auf einen anderen branch wechseln ohne die aktuellen Änderungen zu commiten oder zu verwerfen kann man sie "stashen". Nach ''git stash'' hat man einen sauberen directory tree und kann branch wechseln, commiten, testen usw.

Um die Änderungen wieder auf den aktuellen branch anzuwenden gibts folgende Befehle:

<code>
git stash apply
git stash pop
git stash apply --index
git stash pop --index
</code>

  * ''apply'' wendet die Änderungen nur an
  * ''pop'' wendet die Änderungen an und löscht den Eintrag vom stash.
  * Der Parameter ''%%--%%index'' stellt dann auch die "staging area" genauso wieder her wie sie vorher war.

===== commit rückgängig machen =====

Jeder commit hat einen Hash (vergleichbar mit Revisionsnummer). Sehen kann man diese hashes über ''git log''.

<code>
commit 1ece8a2f6be4429b3b9ddc934da5030389f7ecb1
Author: Robert Hofer <robert.hofer@technikum-wien.at>
Date:   Tue Jan 20 10:34:08 2015 +0100

    erster commit
</code>

Um zu einem vorigen commit zu springen benötigt man diesen:

<code>
git checkout 1ece8a2f6be4429b3b9ddc934da5030389f7ecb1
</code>

Das Ganze geht auch kürzer:

<code>
$ git log --oneline
8d9a142 Squashed commit of the following:
6121e0e acht
08d267d Squashed commit of the following:
37fa721 drei
274478b zwei
1ece8a2 erster commit
$ git checkout 1ece8a2
</code>

Vom hash reichen also auch die ersten 7 Stellen aus.
===== Working Copy zurücksetzen =====
Wenn bereits lokale Commits vorhanden sind die verworfen werden sollen kann der aktuelle stand des Remote repositorys geholt werden mit:
<code>
Auf Branch ci
Ihr Branch ist vor 'origin/ci' um 30 Commits.
  (benutzen Sie "git push", um lokale Commits zu publizieren)
nichts zu committen, Arbeitsverzeichnis unverändert
</code>
Diese können mit folgenden Befehl verworfen werden:
<code>
git reset --hard origin/ci
</code>
wobei ci der name des Remote Branch ist.

===== Branch Merge =====
Wenn die Entwicklung in einem eigenen Branch stattfindet können die Änderungen vom Master in den Branch übernommen werden damit der Branch wieder am aktuellen Stand ist.\\
1. Schritt: Master aktualisieren
<code>
git checkout master
git pull
</code>
2. Schritt: Branch aktualisieren
<code>
git checkout ci
git pull
</code>
3. Schritt: Änderungen vom Master in den Branch mergen
(Man muss sich im Branch befinden)
<code>
git merge master
</code>

Wenn es zu Konflikten kommt müssen diese aufgelöst werden.
Mit 'git status' bekommt man eine Übersicht über den aktuellen Stand.
\\
Soll bei einem Konflikt die Version des Branches übernommen werden kann das mit folgendem Befehl gemacht werden:
<code>
git checkout --ours datei.php
</code>
Soll stattdessen die Version aus dem Master übernommen werden:
<code>
git checkout --theirs datei.php
</code>
Anschließend wird die korrigierte Datei hinzugefügt:
<code>
git add datei.php
</code>
Wenn alle Konflikte behoben sind werden die Änderungen commited:
<code>
git commit
</code>
Und nach dem testen gepusht:
<code>
git push
</code>
===== Andere interessante Befehle =====

<code>git reset: zB git reset HEAD index.php
git mv config.server1.php config.server2.php
git rm index.php</code>

===== Branch auf Commandline anzeigen =====
Um den aktuellen Branch direkt im Prompt auf der Commandline anzuzeigen kann die Variable %%$(__git_ps1)%% in der Datei ~/.bashrc gesetzt werden:
<code>
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\[\033[0;32m\]$(__git_ps1)\[\033[0m\]\$ '
</code>
Um zusätzlich anzuzeigen ob es dort Änderungen gibt kann folgende Zeile hinzugefügt werden:
<code>
export GIT_PS1_SHOWDIRTYSTATE=1
</code>

==== Alias ====
In der Datei ~/.gitconfig können Alias Befehle gesetzt werden um zB formatierte Logeinträge leichter anzuzeigen:
<code>
[alias]
    ci = commit
    lc = log ORIG_HEAD.. --stat --no-merges
    st = status
    co = checkout
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
</code>
===== Workflow =====

Um in einem Projekt zu arbeiten ist der normale Workflow: klonen, branch erstellen (passiert nur lokal), developen/commiten bis es passt, in den master mergen, master pushen

Die Grafiken in der [[http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging|git doku]] sagen mehr als 1000 Worte. Und [[https://guides.github.com/introduction/flow/index.html|der Guide]] schaut auch übersichtlich aus.

===== Aktuelle git Version installieren =====

Für debian gibt es nur relativ alte git Versionen (max. 1.9 über backport). Aktuell sind sie aber bei 2.3.0. Die Version muss man selbst kompilieren. Und zwar so:

<code>
sudo apt-get install autoconf libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev
sudo apt-get remove git
wget https://www.kernel.org/pub/software/scm/git/git-X.Y.Z.tar.gz
tar -zxf git-X.Y.Z.tar.gz
cd git-X.Y.Z
make configure
./configure --prefix=/usr
make all doc info
sudo make install install-doc install-html install-info
cd ..
rm -r git-X.Y.Z
</code>

Siehe auch [[http://git-scm.com/book/en/v2/Getting-Started-Installing-Git|Installing Git]]

===== git url alias =====

Um zum Beispiel https URLs auf ssh URLs umzuschreiben kann man in ''~/.gitconfig'' folgenden Eintrag machen:

<code>
[url "git://git@github.com:"]
    insteadOf = https://github.com/
</code>

''<nowiki>https://github.com/</nowiki>'' wird jetzt immer durch ''<nowiki>git://git@github.com:</nowiki>'' ersetzt.

Damit dieses Alias bei ''git submodule'' greift, müssen vorher in ''.git/config'' die submodule gelöscht werden. Beispiel:

<code>
[submodule "submodules/tablesorter"]
    url = git@github.com:christianbach/tablesorter.git
</code>

Diesen Eintrag entfernen. Den Ordner samt submodule (sicherheitshalber) löschen. Und dann

<code>
git submodule init
git submodule update
</code>

''.git/config'' kontrollieren, hier sollten jetzt die ssh URLs eingetragen sein.