Hallo Ralf,
On Sun, Aug 20, 2017 at 10:13:13PM +0200, Ralf Mattes wrote:
Am Sonntag, 20. August 2017 21:39 CEST, Uwe Kleine-König uwe@kleine-koenig.org schrieb:
Im Gegenteil, wenn man sich nicht mit git auseinander setzt, verpasst man viel. Zum einen weil git gegenüber svn mächtiger und schneller ist und zum anderen, weil so viele Projekte inzwischen git verwenden, dass heute schon fast eine grundlegende Voraussetzung für Opensource-Mitarbeit ist, mit git umzugehen.
Nun ja, nicht jeder arbeitet an Opensource. Hier ging's ja auch um Firmen.
OK, das ist vielleicht meine rosa Brille, weil ich auch beruflich zum größten Teil mit OSS zu tun habe.
Auch für Firmen ist das verteilte Entwickeln hilfreich. Ich erinnere mich noch an CVS-Zeiten, wo man vor einem Release nicht mehr committen (also pushen) durfte, weil es sonst nicht mehr ohne Gefiesel möglich war, nach dem Release-Build den Tree zu taggen. Mit Subversion ist das besser, da kann man den richtigen Stand schon ein ein Tag gießen. Aber mit einem DVCS kannst Du erst mal lokal taggen und wenn dann der Releasebuild oder dessen Test auf die Bretter geht, pushst Du einfach den Tag nicht, sondern fixt erst das Problem und probierst es nochmal ohne, dass die Welt den Fehlversuch sehen muss und Du eine neue Versionsnummer brauchst.
Für Nutzer von Subversion ist der einzige relevante, konzeptionelle Unterschied, dass Committen und Pushen zwei Schritte sind, die zusammen verwirrenderweise bei Subversion commit heißen.
Wieso verwirrend? Commit schreibt die Änderungen in's Repository. Bei SVN liegt das halt auf dem Server (und nicht lokal) und desswegen muss SVN eben auch "pushen". Das ist nur konsequent.
Ja, wenn "commit" für Dich heißt "ich schiebe das ins (eventuell lokale) Repository", dann hast Du das Konzept von git-commit schon richtig verstanden. Der Otto-Normal-Subversion-Nutzer versteht unter committen aber vielleicht: "Ich mache meine Änderung den anderen zugänglich." und das passt bei git dann nicht.
Da braucht es also zum einen etwas git-Konzept-Verständnis und zum anderen etwas Disziplin, auch an den push-Schritt zu denken (so man ihn den braucht).
Dem ersten Teil würde ich sofort unterstreichen. Das ist extrem wichtig, gerade eben weil git so offen ist, was den Workflow betrifft. Für den zweiten Teil: glücklicherweise gibt's ja bei Git Hooks mit denen man Teile des Workflows automatisieren kann.
Uah, Du schlägst vor, dass man im post-commit-hook pusht? Davon würde ich abraten.
Liebe Grüße Uwe