Von ayatollaTorvald am Di, 28. April 2009 um 17:13 #
Kann mir jemand diesen Satz erklären: "Mit der neuen Version wird das Projekt vom Versionskontrollsystem »SVN« auf »git« umstellen, um weiteren Entwicklern eine einfachere Möglichkeit zur Entwicklung zu geben."
Wer SVN nicht benutzen kann, kommt auch mit git nicht klar. Wenigstens gabs "bahnbrechende" Änderungen.
Bei git muss man niemandem schreibzugriff auf das Repository geben. Jeder kann das Repository clonen, bei sich weiterarbeiten und der Hauptentwickler kann dann einen Patch aus dem geclonten Repository ziehen oder sich einen Patch zuschicken lassen.
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.
Wer SVN nicht benutzen kann, kommt auch mit git nicht klar. Wenigstens gabs "bahnbrechende" Änderungen.
Bei git muss man niemandem schreibzugriff auf das Repository geben. Jeder kann das Repository clonen, bei sich weiterarbeiten und der Hauptentwickler kann dann einen Patch aus dem geclonten Repository ziehen oder sich einen Patch zuschicken lassen.
1. Herunterladen der aktuellen Version
2. Weiterarbeiten und den Patch an den Entwickler schicken.
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.
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.
...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.