Basiskonfiguration git

Es bietet sich an in seinem Home Verzeichnis (Linux: /home/<username>) eine Datei '.gitconfig' anzulegen. Meine Datei sieht wie folgt aus:

[user]
        name = <mein_name>
        email = <mein_name>@gmx.de

[diff]
        color = auto

[page]
        color = true

[status]
        color = auto

[core]
        editor = kate
        safecrlf = true
        # Unix/Mac only
        autocrlf = input
        # Windows only
        # autocrlf = true

[merge]
        tool = kdiff3

[color]
        ui = auto
[push] 
        # defines what 'git push' means, see 'man git-config' section push.default for details 
        # possible values are: nothing, matching, upstream, simple, current
        # default = matching # default for git 1.x but only recommented for experienced git users
        default = simple # future default for git 2.x

Ich empfehle jedem, diese Datei entsprechend seiner Vorlieben anzupassen (insbesondere push.default). (Eine vollständige Übersicht darüber, was man da alles konfigurieren könnte liefert 'man git config').

Dokumentation und GUI/Clients

Die ultimative Referenz kann online und auf deutsch hier gelesen werden.
Online stehen auch die Manpages zur Verfügung.
Im Git Wiki befinden sich ebenfalls viele interessante Inhalte, z.B. Links zu weiterer Dokumentation und eine Liste von GUI git Clients.
egit, der Eclipse/STS git team support, besitzt ebenfalls eine ausführliche Dokumentation.
Die Weboberfläche von Bitbucket hat ebenfalls einige spezielle Feature: Get Started und Dokumentation.
Eine alternative Benutzeroberfläche (GUI) für Mac Osx ist SourceTree. Maik mag sie und ihre Dokumentation.
Für Linux ist (das mit git gebündelte) gitk der GUI Client der Wahl. Ferner gibt es das graphische Commit Tool git gui.
Ein guter GUI Client ist ferner SmartGit. SmartGit läuft auf allen Betriebssystemen, aber für den kommerziellen Einsatz wird eine kostenpflichtige Lizenz benötigt. (Daher ungeeignet für die Hauptberuflichen Nuclos Entwickler.)

Erstmaliges Auschecken eines Branches

Hat man aus bitbucket.org zum ersten mal ausgecheckt, dann hat man zwar alle 'remote Branches' (git branch -r), aber nur einen lokalen 'tracking branch' (git branch), nämlich den der 'remotes/origin/master' folgt: 'heads/master' oder kurz 'master'.

Die anderen 'tracking branches' müssen also noch erstellt werden! In eclipse/sts geht das wie folgt:

Project Explorer -> nuclos (Hauptprojekt) -> rechte Maustaste -> Team -> Switch to -> New branch ...

Hier wird also der richtige 'remote branch' gewählt. Eclipse/STS schlägt dann automatisch einen Namen für den lokalen 'tracking branch' vor. Alternativ funktioniert's auch auf der Kommandozeile mit 'git branch -l -t 3.8 origin/3.8'.

Sollte hier der gewünschte Branch nicht angezeigt werden, dann ist das lokale Repository wahrscheinlich nicht aktuell genug. In diesem Fall hilft ein 'git fetch' bzw. in eclipse/sts: Project Explorer -> nuclos (Hauptprojekt) -> rechte Maustaste -> Team -> Fetch from Upstream.

Ein Fetch ist übrigens immer zum Abgleich eine gute Idee - und er macht nie etwas kaputt, da er den gerade ausgecheckten Stand ('working copy' und 'index') nicht verändert.

Zeilenende Policy

In einem neu ausgecheckten Repository bitte gleich die Zeilenende Policy richtig einstellen.

Window:

cd <repo>
git config core.autocrlf true 
git config core.safecrlf true

Linux/Mac:

cd <repo>
git config core.autocrlf input 
git config core.safecrlf true

Rebase als 'pull strategy'

Sehr wichtig ist es, als 'Pull stategy' Rebase auszuwählen (wie im Screenshot geschehen), da so unnötige 'Merges' durch Pull vermieden werden! Genauere Informationen hierzu finden sich unter [http://git-scm.com/book/de/Git-Branching-Rebasing] und [http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/] (beides Pflichtlektüre für Entwickler!).

Diese Erstellung des 'tracking branch' muss nur einmal durchgeführt werden. Danach finden man die schon erstellten 'tracking branches' in Eclipse/STS direkt im 'Switch to' Menü:

Git intern fügt die Erstellung eines 'tracking branch' einen Abschnitt ähnlich dem folgenden in die Datei '<repository>/.git/config' ein:

[branch "3.8"]
        remote = origin
        merge = refs/heads/3.8
        rebase = true

Nach dem Auschecken ist die letzte Zeile 'rebase = true' für den Branch 'master' nicht gesetzt. Sie sollte aber gesetzt sein. Alle Nuclos-internen Entwickler fügen daher diese Zeile in der Datei <repository>/.git/config hinzu. Der Abschnitt sollte dann insgesamt wie folgt aussehen:

[branch "master"]
        remote = origin
        merge = refs/heads/master
        rebase = true

Die Zeile kann mit einem einfachen Texteditor hinzugefügt werden. Noch einfacher ist es mit:

git config branch.master.rebase true

Weitere Informationen in [http://stackoverflow.com/questions/11955305/what-is-the-meaning-of-pull-strategy-when-creating-a-branch-with-egit].

Rebase als Standard 'pull strategy'

Es ist auch möglich (und eine Überlegung wert), für alle 'tracking branches' rebase als Standard zu benutzen! Dazu muss man folgende Kommandozeile benutzen:

cd <repository> 
git config branch.autosetuprebase always

Weitere Informationen liefert [http://alblue.bandlem.com/2011/06/git-tip-of-week-pulling-and-rebasing.html].

Seitenhierarchie

Git