Gestern war ich beim Git Best Practices Meetup der Open TechSchool. Dort wurde eine Git-Einführung zu den Konzepten von Pull-Requests, Branches, Forks, Merges und Fast-Forwards gegeben. Es wurde auch darauf hingewiesen, dass eine gute Commit-Message beschreibt WARUM man etwas gemacht hat. Viele Entwickler beschreiben aber meistens nur WAS man gemacht hat. Das WAS ist aber in der Git-Change-History ersichtlich, so dass es in der Commit-Message durchaus Sinn macht, die WAS-Information mit dem WARUM zu ergänzen.
Als erfahrener Git-User fand ich besonders schön, dass auch über git bisect
gesprochen wurde. Mit git bisect lässt sich nach dem „Teile und herrsche“-Verfahren der Commit ausfindig, welcher einen Fehler verursacht hat. Mehr dazu in „Using Git bisect to figure out when brokenness was introduced„.
Zum Abschluss des Meetups haben wir uns über „Best Practices“ bei der Verwendung von Git unterhalten. Dabei sind wir uns einig gewesen, dass es Sinn macht, einen Branch nach der Issue-Nummer eines Tasks zusammen mit einer kurzen Beschreibung zu benennen.
Beispiel: MYPROJECT-256/add-user
Als GitHub-Nutzer bevorzuge ich sogar einen Teil der URL in den Branchnamen aufzunehmen, dadurch kann man dann diesen Teil aus dem Branchnamen kopieren und in einer bestehenden GitHub-Issue-Url einfügen, um eine genaue Beschreibung des zu integrierenden Features zu erhalten.
Beispiel: Das Issue zu dem der Branch erstellt wird ist zu finden unter: https://github.com/bennyn/wlc-webapp/issues/122
. Also würde ich meinen Branch dazu issues/122/keyboard-shortcuts
nennen.
Mehr Best Practices zum Umgang mit Git zu finden auf den Seiten von Seth Robertson. Wer eine Übersicht über den Arbeitsablauf mit Git haben möchte, der schaut am Besten beim successful Git branching model vorbei.