Zu den Vorteilen gehören da u.A.:
Echte Branches
Ein Branch in git ist nicht ein eigener Ordner, sondern besteht aus einer Untermenge von Commits.
Du kannst dabei beliebig zwischen Branches wechseln, mergen und was auch immer tun, das Arbeitsverzeichnis ist das selbe, du wechselst bei einem Wechsel des aktiven Branch nur den Inhalt.
Trennung zwischen Commit und Branch
Ein Commit kann zu einem oder mehreren Branches gehören.
Wenn du einen Commit erstellst (mit "git commit"), so gehört dieser erst mal nur zu deinem lokalen, aktiven Branch.
Der Server hat einen eigenen Branch, erst wenn du "git push" sagst, werden deine Commits an den Server übertragen (der Server übernimmt quasi deinen Branch als seinen eigenen). Dabei werden dann nur die Commits noch nachträglich übertragen, die dem Server noch fehlen.
Das bringt auch einen zweiten Vorteil mit sich: Obwohl der Server ein Backup des Repos hat, brauchst du keine Verbindung zum Server um sauber zu arbeiten. Da du die neuen Commits immer erst bei dir lokal auf dem Rechner erstellst, kannst du da auch ohne Netzwerkverbindung strukturiert arbeiten und dann bei der nächsten Gelegenheit gleich ein Dutzend Commits auf einmal synchronisieren.
Einfach mal lokal was ausprobieren?
Simpel, einfach schnell einen neuen Branch erstellen (das ist nur ein einziger Befehl der notwendig ist), die experimentellen Änderungen bereits lokal schon sauber in Commits verpacken und bei nicht gefallen kannst du den Branch immer noch verwerfen. Oder in den master mergen falls es funktioniert.
Wenn du mehrere Baustellen hast an denen du gleichzeitig arbeitest, kann es durchaus Sinn machen jede Baustelle in einem eigenen Branch zu behandeln, ab und an die Änderung testweise in einem "experimental" Branch zu mergen und erst im fertigen Zustand dann alle nacheinander in den Master.
Und ja: Das macht auch schon bei einem einzigen Entwickler Sinn. Der große Vorteil dadurch ist, dass du einzelne Änderungen problemlos zurückstellen kannst, und neue Features in der Reihenfolge in den Master mergen kannst in der du sie fertig gestellt bekommst.
Mit SVN sind Branches immer ein richtiger Alptraum...
Ein anderes nettes Feature: Der "stash".
Git erlaubt es dir Änderungen die du noch nicht in einen Commit verpackt hast, einfach in den "stash" zu packen, sprich die Änderungen werden gespeichert, das Repo wieder auf den letzten Commit zurück gesetzt und du kannst erst einmal etwas anderes tun. Wenn du fertig bist, "stash" wieder auspacken und weiter arbeiten.
Das macht immer dann Sinn, wenn du mitten in einer komplexeren Sache bist, dir allerdings mitten drinnen auf fällt, dass da vorher noch etwas anderes erledigt werden müsste, du aber aus der offenen Baustelle noch keinen Commit machen willst, da nicht lauffähig. In dem Fall kommen die aktuellen Änderungen in den stash, und du kannst auf einer SAUBEREN (lauffähigen) Kopie schnell die notwendigen Änderungen commiten, und anschließend den Stash wieder herstellen - welcher dann allerdings bereits auf dem neusten Commit aufbaut.
Nur EIN .git-Ordner für das gesamte Repo
Während bei SVN wirklich in jedem Ordner ein verstecketer .svn-Ordner liegt, gibt es bei Git nur einen einzigen solchen Ordner welcher im Wurzelverzeichnis des Repos liegt. Du kannst damit die Inhalte des Repos raus, rein, hin- und herverschieben wie es dir lieb ist, ohne dass es jedes mal dein komplettes lokales Repo zerstört. (Kopieren/Verschieben/Löschen innerhalb des Repos solltest du natürlich immer noch nur mit dem passenden GIT-Kommando machen, aus dem ganz einfach Grund dass damit die Versionshistorie für die jeweilige Datei erhalten bleibt.)
Nachteil an Git?
Git kennt keine leeren Ordner. Git kennt nur Dateien, sprich wenn du einen leeren Ordner erzeugen willst, dann muss dieser immer eine Datei als Platzhalter enthalten.
Außerdem ist es ein wenig schwierig innerhalb des Repos an einem bestimmten Pfad ein weiteres Repo ein zu binden (z.B. um eine bestimmte Bibliothek direkt aus einem anderen Repo zu beziehen). Das ist allerdings IMHO etwas, was man eh nicht tun sollte.
