Flos Spielwiese

Einführung

Anfangen

Als Erstes sagt man git am besten, wer man ist, damit das später in die Commit-Logs geschrieben werden kann:

git config --global user.name "MeinName"
git config --global user.email "email@foobar.de"
git config --global i18n.commitEncoding "MeinEncoding"

(Das wird in der Datei ~/.gitconfig gespeichert.)

Repository anlegen

TODO

Dateien hinzufügen

Nun kann man mit den Dateien ganz normal arbeiten oder z.B. neue Dateien dem Repository hinzufügen:

git add dateiname

Ins lokale Repository committen

Wenn man mit seinen Änderungen fertig ist, kann man in das lokale Repository (das im .git/-Unterverzeichnis) committen:

git commit -a

Danach muss man dann einen Kommentar angeben, der beschreiben sollte, was man da getan hat.
Wichtig ist hier, dass bisher noch niemand anderes etwas von diesem Commit merkt, weil ja alles nur im lokalen Repository gelandes ist.

Ins zentrale Repository pushen

Damit die Änderungen auch ins zentrale Repository gelanden, kann man pushen, also die Änderungen hochschieben. Genauer: Man schiebt sie damit automatisch in das Repository, das man am Anfang geclont hat:

git push

Änderungen aus zentralem Repository übernehmen

Umgekehrt kann man natürlich auch die Änderungen der lieben Kollegen übernehmen, indem man pullt:

git pull

Interessant: Dass push und pull auf unser zentrales Repository zugreifen, ist nur “Zufall”, man kann ebenso gut das lokale Repository des Teamkollegen angeben, dann tauscht man sich eben mit dem aus, z.B.:

git pull /home/kollege/git/spielwiese

Branchen

Da Branchen und Mergen nun sehr einfach und angenehm geworden ist, möchte ich die Devise ausgeben, das auch intensiv zu nutzen. Beispielsweise könnte man für jeden Mantis-Fall, den man bearbeitet, einen eigenen Branch anlegen, z.B.:

git branch branchname

Mit

git branch

sieht man, welche Branches man aktuell in seinem Repository hat.
Nach dem Branchen kann man sich den neuen Branch auschecken. Macht man das nicht, bleibt man im master-Branch!

git checkout branchname

Nun kann man im neuen Branch arbeiten und committen. Man könnte auch einfach den ganzen Branch wieder wegwerfen:

git branch -D branchname

Gerade wenn man länger in so einem Branch arbeitet, sollte man immer mal wieder die Änderungen aus dem master-Branch einarbeiten, damit man sich nicht zu weit von den Änderungen der anderen entfernt.

git pull origin master

Zur Erklärung: origin ist hier eine Abkürzung für die URL des Ursprungsrepositorys, aus dem man sein lokales Repository geclont hat. master ist der Name des Branches, aus dem man die Änderungen übernehmen will.
Man kann jederzeit in den neuen Branch committen:

git commit -a

Einen bestehenden lokalen Branch kann man ins zentrale Repository schieben:

git push origin branchname

Danach sieht man ihn dann auch als remote branch:

git branch -r

Mergen

Wenn man fertig ist und alles in den master übernehmen möchte, macht man erst den normalen commit und springt danach wieder in den master:

git commit -a
git checkout master

Hier kann man dann den Branch hineinmergen:

git merge branchname

Wenn es keine problematischen Konflikte gibt, ist man hier schon fertig und kann direkt wieder committen.
Ansonsten muss man hier entweder nachsehen, welche Dateien noch Konflikte haben:

git status

Und dann alle Konflikte von Hand lösen, oder man nimmt ein grafisches Tool, z.B. kdiff3, das man sich besten erstmal global einstellt:

git config --global merge.tool kdiff3

Dann kann man damit die Konflikte bearbeiten und hoffentlich auflösen:
git mergetool

Remove rückgängig machen

Wenn man eine Datei (z.B. per rm) gelöscht hat, die man doch wieder zurück haben möchte:

git checkout -- dateiname

GUI

Es gibt ein nettes GUI-Tool, das einem den “U-Bahn-Fahrplan” der Branches und Commits anzeigt. Da kann man schön nachvollziehen, wer wann was gemacht hat:

gitg