1) Vom Preis-Leistungs-Verhältnis her Pro Git, Scott Chacon, Apress Verlag.
2) Nutze ich nicht. Reicht es nicht, ein Bare Repository anzulegen und SSH-Zugriff auf den Server zu gewähren?

Eine Anleitung, wie man einen Git-Server aufsetzt, haben wir auch im Buch: openbook.galileocomputing.de/a…af-4957-aa6c-60af4a50b34c

Kewl. Danke fürs (mit)teilen!

Ich fände das auch sehr interessant mal ein richtig gutes Buch zu GIT zu finden. Wo man genau erklärt bekommt was man alles machen kann, wie das genau funktioniert etc.

Gruß

Claus

[kay]
Bare Repositories sind Repositories, welche keinerlei Arbeitskopie enthalten. Das heißt, sie halten lediglich den kompletten Verlauf in ihrer History vor (und natürlich die kompletten Änderungen), Du kannst die Dateien aber auf dem Server nicht direkt bearbeiten.

[Thallius]
Es gibt meiner Meinung nach zwei Arten von guter Git Literatur.
Die einen erklären haarklein, wie Git funktioniert und was Git alles kann. Diese finde ich perfekt, wenn man viel mit Git arbeitet und seine Workflows entsprechend anpassen kann.

Die anderen erklären ganz grob, wie man ziemlich zügig mit Git zum Arbeiten kommt. Diese hat mir damals™ sehr gut beim Einstieg geholfen.

Das Problem: zu Ersterem gibt es unzählige Bücher, zu Letzterem nur unzählige Tutorials.
Die meiner Meinung nach beste Sammlung zu Tutorials und Workflows finden sich unter atlassian.com/git/

Ein Git Server ist ja jetzt auch in OS X Mavericks Server eingebaut.

Michael

Von denen ist auch SourceTree; meines Erachtens der beste Git-Client, auch wenn die Registrierung etwas seltsam ist.

Ja, eine Lizenz für ein kostenloses Tool 'erwerben' ist schon arg seltsame Praxis.
Andererseits haben sie auch JIRA, Confluence, BitBucket/Stash, Bamboo, Fisheye und ähnliche Tools im Vertrieb. Da kann es sein, dass man einfach nicht vom Standardverfahren abweichen möchte.

Und ihre Dokumentationen sind wirklich gut.

Ich vermute eher, dass die früher oder später auch dafür Geld nehmen wollen, aber das erstmal am Markt testen wollen.

So wie bei den Jungs und Mädelz von Tower?
Dann muss aber noch ordentlich Integrationsarbeit in gängige Tools fließen.
(Mir persönlich reicht das CLI ja völlig…)

Ich nehm SourceTree hauptsächlich um (fremde) Commits zu reviewn. Das ist etwas komfortabler als auf der CLI. Alles andere mach ich aber auch im CLI.

da hier alle eher pro Git sind, hoffe ich mal das es nicht in einen Glaubeskrieg endet aber mich würde doch mal interessieren warum ihr Git benutzt und nicht SVN

Zum Einen nervt mich die Ordnerstruktur in Subversion.
Ich vergaß permanent, mir die ./trunk, ./branches und ./tags Ordner anzulegen, bemerkte es aber immer viel zu spät.
Auch die Tatsache, dass jeder Unterunterunterunterunterordner ein .svn/ beinhaltet, erschwerte mir die Arbeit immens. Ich will gar nicht wissen, wie oft ich durch ein unbedachtes `rm -r` zur Lösung von Konflikten durch Reinitialisierung meine gesamte Working Copy zerschossen habe.
(Ach, den Unterunterunterunterordner mit den Bildern brauche ich doch gar nicht mehr. SVN meckert wegen irgendwelcher Konflikte. Lösch ich das halt manuell. <10 Sekunden später> Ups. Mist.)
.git/ ruht still und friedlich im obersten Verzeichnis der Working Copy. Das Verzeichnis musste/wollte ich noch nie mal eben schnell leeren.

Schlussendlich wollte ich ab und an mal Code aus anderen Projekten übernehmen. Naiv übernahm ich dann den Ordner, der diesen Code beinhaltete. Und stellte mit Erschrecken fest, dass SVN mich permanent angemotzt hat, es könne diesen Code nicht zum Repository hinzufügen, da es bereits unter Versionsverwaltung stünde.

Weiterhin fand ich den Serverzwang nervig. Biste unterwegs, hast ein bissl gearbeitet und keine Netzverbindung, dann wollten die Commits nicht.
In Git committe ich 15 Änderungen ohne Zugang zum Server und schiebe sie hoch, wenn ich wieder eine Netzverbindung habe.

Ein weiterer Pluspunkt, der auch an diesem lokalen/zentralen Mischmasch hängt: jeder, der einmal ausgecheckt (und im Anschluss nicht wieder gelöscht) hat, besitzt ein potentielles Backup des gesamten Repositories. Sollte der Server in Flammen aufgehen, so sind die Daten dennoch nicht hinüber.

Also insgesamt überwiegen für mich die Vorteile von GIT gegenüber SVN.

Natürlich gibt es da auch Nachteile.
Da man sowohl lokal als auch zentral arbeiten kann, der Zentralzwang aber fehlt, kann ein Push mitunter ätzend werden. Nämlich dann, wenn die auf dem Server befindliche Datei neuer ist als Deine Änderungen.
Gefühlt bist Du bei GIT öfter am mergen als mit SVN.

Mit Git habe ich bislang noch eine Probleme mit beschädigten Meta-Informationen im Working-Directory gehabt.