20 Aug
2017
20 Aug
'17
10:45 p.m.
Hallo Ralf,
On Sun, Aug 20, 2017 at 10:13:13PM +0200, Ralf Mattes wrote:
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.
Uah, Du schlägst vor, dass man im post-commit-hook pusht? Davon würde
ich abraten.
Liebe Grüße
Uwe
Am Sonntag, 20. August 2017 21:39 CEST, Uwe
Kleine-König <uwe(a)kleine-koenig.org> schrieb:
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.
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. 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. 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.