Ich habe "traditionelle" Versionskontrollsysteme verwendet, um Quellcode-Repositories in früheren Projekten zu verwalten. Ich beginne ein neues Projekt mit einem verteilten Team und ich sehe Vorteile bei der Verwendung eines verteilten Systems. Vorausgesetzt, dass ich SourceSafe, CVS und Subversion verstehe; Welche Vorschläge hast du für einen Git-Neuling?Was sollte ich über Git wissen, bevor ich es benutze?
Die Git - SVN Crash Course ist eine gute Lektüre für den Einstieg.
Vor dem Übertragen von Dateien müssen sie dem Git-Staging-Bereich — alle Mal hinzugefügt werden. Um dies zu erleichtern, gibt es eine -a Option zum Hinzufügen aller überwachten Dateien, wie in git commit -a.
Auch wenn Sie git diff tun, zeigt es Ihnen nur den Unterschied zwischen Ihrer Arbeitskopie und was im Staging-Bereich ist. Wenn Sie dem Bereitstellungsbereich geänderte Dateien hinzugefügt haben, meldet git diff möglicherweise nichts, obwohl Sie möglicherweise nicht festgeschriebene Änderungen vorgenommen haben. Verwenden Sie git status, um sicher zu sehen.
die tutorial
spielen Sie dann mit ihm um. Machen Sie ein kleines Spielzeugprojekt, um ein Gefühl dafür zu bekommen, bevor Sie anfangen, mit Ihrer Hauptcodebasis zu arbeiten.
Ich benutze gitk viel, um Patches zu überprüfen und zu verfolgen, wie sich der Code von Commit zu Commit ändert.
Ich versuchte git in meiner Firma. Wir verwendeten CVS und wollten zu einem besseren VC-Tool wechseln. Wir haben git als bestes Tool für die Versionsverwaltung von Dateien ausgewählt (Linus on GIT). Seine Leistung ist einfach die beste und es ist ein wirklich tolles Werkzeug für einen Entwickler, der die Versionskontrolle in der Tiefe versteht, aber es ist ein Albtraum für einen normalen Entwickler, der Versionskontrolle im Hintergrund verwendet und nicht lernen möchte, wie man mehr verwendet als einige Stunden (und sie müssen eine Menge lernen)
Auch ist die Integration mit bestehenden IDEs weit weg, um abgeschlossen zu sein. Die gesamte Benutzerfreundlichkeit ist ein ziemlich großes Problem für einen normalen Entwickler.
Nach einem Pilotprojekt mit 4 Entwicklern haben wir als einfachste, aber nicht so überlegene Software auf Subversion umgestellt.
Es gibt auch kommerzielle Lösung für Subversion Multisite (die wir noch nicht versuchen, aber werden versuchen, kurz) - WANDisco
In meiner eigenen Erfahrung von Subversion zu Git bewegen, das Wichtigste nicht das, was Sie brauchen zu lernen, aber was Sie brauchen, um verlernen. Die verteilte Versionskontrolle ist sehr, die sich von der zentralisierten Versionskontrolle unterscheidet. CVC ist eine Teilmenge von DVC, also können Sie CVC einfach in einem DVC-Tool ausführen, aber es wird komplizierter als mit einem CVC-Tool.
Versuchen Sie CVC zu verlernen, und gehen Sie in die DVC-Denkweise. Wenn Sie am Ende CVC in einem DVC-Tool tun, werden Sie nur frustriert von all der zusätzlichen Komplexität und Sie werden nicht erkennen, was diese zusätzliche Komplexität Sie in Bezug auf Flexibilität kauft.
Alle DVC-Tools haben große und sehr leistungsfähige Unterstützung für die Verzweigung und Zusammenführung. Benutze es. Die ganze Geschichte ist auf Knopfdruck verfügbar. Benutze es. (Zum Beispiel: Code nie auskommentieren, einfach löschen. Sie können ihn immer wieder erhalten, sogar in einem Flugzeug ohne Internetverbindung.)
Ein sehr wichtiger Aspekt von Git: Alle anderen Tools haben einen mehr oder weniger definierten Workflow. Git nicht. Git ist ein DVCS-Workflow-Baukasten. Dies macht es manchmal schwierig zu wissen, was zu tun ist: Sie müssen Ihren eigenen Workflow entwerfen und implementieren (Hinweis: Verwenden Sie viele Shell-Skripte). Ich benutze Git seit mehr als einem Jahr, und ich habe meinen Workflow noch nicht vollständig verstanden.
... es sei denn, Sie befehlen "git diff foo/bar.file" –