Git hat mich produktiver gemacht, und ich werde in wenigen Worten erklären, warum das so ist. Ich könnte es fast mit Twitter machen, aber ich nehme mir gerne etwas mehr Zeit, um meinen Standpunkt darzulegen. Der Hauptvorteil, den mir Git gebracht hat, liegt in der Leistung bei bestimmten Dingen, die ich bei der Verwaltung von Änderungen an meiner Codebasis erledigen möchte. Die Leistungsverbesserungen einiger kritischer Teile von git sind sogar so tiefgreifend, dass sie meine Arbeitsweise verändert haben. Insbesondere die Tatsache, dass ich Builds für die meisten meiner Commits überspringen kann, ist eine große Zeitersparnis.
Es wurde bereits viel über Git gesagt und ich schlage vor, dass Sie Ihren bevorzugten Suchindex verwenden, um sich auf den neuesten Stand zu bringen, wenn Sie dies benötigen. Git ist ein einfaches verteiltes Versionierungssystem, das viele Annahmen, die ich über die Entwicklung hatte, in Frage stellt. Lassen Sie uns diese Annahmen durchgehen. Ich zeige Ihnen meine (auf svn basierende) Annahme und warum sie nicht zutrifft, wenn Sie Git verwenden.
Arbeiten Sie immer nur an einer Sache
Mit Subversion ist das Zusammenführen unübersichtlich, und da Sie mit Ihren Commits eine Geschichte erzählen wollen, können Sie nicht an mehr als einer Sache gleichzeitig arbeiten, ohne für jedes Thema, an dem Sie arbeiten wollen, einen kompletten Zweig auszuchecken. IDEA hat dafür eine sehr coole Lösung, Shelf genannt, aber mit Git ist das Ganze kein Problem mehr. Da Sie die Übertragungen lokal vornehmen, können Sie an vielen Dingen gleichzeitig arbeiten, sie aufeinander abstimmen und sie dann in mehreren Schritten übertragen. Zum Schluss machen Sie Ihren Build wieder grün und stellen die ganze Geschichte an einen öffentlichen Ort.Wenn Ihnen das nicht reicht, können Sie (sehr kostengünstig) mehrere lokale Zweige behalten und diese vor dem Commit zusammenführen. Mehr zum Branching später.
Committen Sie nie, bevor der Build nicht grün ist
Sie wollen nicht dumm und hässlich aussehen, also stellen Sie sicher, dass, bevor Sie etwas für Ihre Teammitglieder sichtbar machen, es sie nicht zu Tode nervt. Ungetestete Module oder Code, der sich nicht einmal kompilieren lässt, ärgern kluge Leute, also geben Sie das nicht weiter...
Ich weiß nicht, wie es Ihnen geht, aber ich muss erst einen Build ausführen, bevor ich sicher bin, dass alles in Ordnung ist. Die Ausführung eines Builds für ein typisches Projekt dauert mehr als 5 Minuten, wenn Ihr Projekt schneller ist, gehören Sie zu den wenigen Glücklichen. Das Ergebnis mit svn ist, dass selbst eine banale, triviale Änderung wie "ich habe diese Eigenschaft umbenannt" mindestens 5 Minuten dauert. Das macht Sie zimperlich und veranlasst Sie dazu, Regeln zu verletzen (bis Sie dumm und hässlich aussehen und Ihre Lektion gelernt haben, versteht sich).
Mit Git weiß niemand, was Sie übertragen haben, bis Sie sich entscheiden, es zu pushen. Sie können also so dumm und nervig sein, wie Sie wollen, und haben nur eine einzige kluge und überlegte halbe Stunde am Tag, bevor Sie Ihre Änderungen veröffentlichen. Alles, was Sie übertragen, bleibt lokal und das ist ein Glücksfall. Normalerweise mache ich einen oder 5 Commits, führe dann meine Builds aus, prüfe, ob ich meine Geschichte richtig verstanden habe und veröffentliche sie dann (ein- oder zweimal am Tag). Mit Git muss ich häufiger Commits durchführen und weniger Builds erstellen, was eigentlich ein doppelter Gewinn ist.
Was auch immer Sie tun, verzweigen Sie nicht
Subversion und cvs haben mich in mehreren harten Lektionen gelehrt, dass das Verzweigen für Leute ist, die völlig verrückt sind. Wenn Sie jemals verzweigen, dann nur, weil Sie gerade eine neue Version veröffentlicht haben, und Sie sollten NIEMALS, NIEMALS, versuchen, Zweige zusammenzuführen. Ok, ich weiß, dass es möglich ist, ich habe es gesehen und ja, ich habe es selbst getan, aber das waren die drei schrecklichsten Tage in meinem Leben und die Narben werden wahrscheinlich nie verheilen.Wenn ich nur git benutzen würde und den vorherigen Absatz lesen würde, wäre ich erstaunt und entsetzt über die Inkompetenz. Und nachdem ich eine Weile mit git gearbeitet habe, kann ich nicht glauben, dass ich die Tatsache, dass Zweige in svn nutzlos sind, so lange toleriert habe.
Nachdem diese drei Annahmen völlig zerschlagen sind, kann ich viel schneller arbeiten. Und der Clou ist, dass es git-svn gibt, so dass ich keine bestehenden Repositories migrieren muss, um mit der Arbeit am neuen Beat zu beginnen. Ich habe festgestellt, dass ich bei einem vielbeschäftigten Projekt normalerweise mindestens 20 % meiner Zeit mit Versionskontroll- oder Build-Problemen verbringe, was jetzt unter die Schmerzgrenze von 5 % gesunken ist. Die Commits sind auch viel schneller, weil ich die zu erwartenden Merge-Konflikte auf einen Zeitpunkt verschieben kann, an dem ich noch Gehirnwindungen für sie übrig habe. Ich bin noch nicht so weit, dass ich Diffs mit anderen Entwicklern teile, so wie ich normalerweise Patches, die noch nicht zur Veröffentlichung bereit sind, an das ganze Team schicke, aber wenn ich dazu komme, das in der Praxis auszuprobieren, werde ich hier darüber berichten.
Mein Rat: Probieren Sie git aus und schauen Sie nie wieder zurück. Wenn Sie immer noch svn benutzen, sollten Sie git lokal mit git-svn verwenden, weil Sie damit fast die gleiche Sicherheit haben.
