Je länger das `Weiterarbeiten' dauert, desto glücklicher ist man über die Möglichkeit zwischendurch commiten zu können.

Ist man sich mitten im `Weiterarbeiten' nicht mehr sicher, kann man auch einen experimentellen Zweig erstellen. All das, ohne das Hauptrepository zu belästigen. Und wenn dann der hauptentwickler pullt, bleiben alle commit-messages schön erhalten und man kann als dritter den Ablauf des `Weiterarbeitens' viel besser nachvollziehen als bei einem Riesenpatch/-commit.

Sagen wir so, wenn jemand deinen Patch noch nicht ins Mainrepository einspielen will, aber Änderungen daran vornehmen will, dann wirds komplizierter. Oder wenn ein dritter deinen Fork sieht und daran weiterentwickeln möchte.

Zugegeben, im typischen Entwickleralltag, in kleineren Projekten, macht es weniger den Unterschied, ob du git oder svn benutzt. Aber wenn mal schnell was "gefixt" werden soll, massive Änderungen im Code durchgeführt werden sollen etc., dann zeigt git seine wahre Stärke.

Umgekehrt ist es bei großen Projekten, bzw. bei Projekten, wo man anderen keinen Schreibzugriff aufs Repo gewähren will, ein allein wegen oben genannter Punkte stark im Vorteil.

> 2. Weiterarbeiten und den Patch an den Entwickler schicken.

...was bei jeder größeren Änderung nicht wirklich praktikabel ist. Da will man feingranularere Commits (gerade als Maintainer) und vor allem [lokale] Versionskontrolle während der Entwicklung.