Letzte Woche hatten wir eine unserer berüchtigten Tech-Rallyes und wir hatten viel Spaß bei dem Versuch, an einem Tag unseren eigenen Posterous-Klon zu erstellen, d.h. E-Mails in Blogposts zu verwandeln. Die Projektquellen werden auf Github gehostet. Wir arbeiteten an diesem eintägigen Projekt mit etwa 20 Entwicklern, die sich auf 4 Teams verteilten, und mir fiel auf, dass die meisten von uns nicht mehr als grundlegende Git-Erfahrung hatten. Das bedeutete, dass wir auf eine Menge Merge-Konflikte stießen, die nicht immer leicht zu lösen sind. Im Folgenden finden Sie eine kleine Übersicht über die Git-Lernphasen, die wir im Team MongoDB durchlaufen haben, um dieses Problem zu lösen.
Die meisten von uns haben mit einer Herangehensweise begonnen, die für langjährige Subversion-Benutzer ganz natürlich ist: Arbeiten Sie einfach am Master, übertragen Sie Ihre Änderungen lokal, holen Sie sich die Übertragungen der anderen, lösen Sie etwaige Merge-Konflikte und übertragen Sie sie auf den zentralen Server. Leider führt dieser Ansatz zu vielen Merge-Konflikten, da andere Leute genau das Gleiche tun. Git ist ziemlich gut im automatischen Zusammenführen, aber das erzeugt zusätzliche Commits, die Ihre Historie wie folgt aussehen lassen:
Verbesserungsversuch 1
Iwein erzählte uns von einem Arbeitsablauf, den er bei einem seiner Open-Source-Projekte verwendet hat. Die erste Neuerung besteht darin, einen kleinen Entwicklungszweig zu verwenden, an dem Sie alle Übertragungen vornehmen, während Sie den Master-Zweig sauber halten. Wenn es an der Zeit ist, das Projekt auf den zentralen Server zu übertragen, durchlaufen Sie eine Reihe komplizierter Schritte, um den Master-Zweig auf die neueste zentrale Version zu aktualisieren, Ihren lokalen Zweig damit zu vergleichen, das Ergebnis wieder mit dem Master-Zweig zusammenzuführen und diesen schließlich auf das zentrale Repository zu übertragen. Der Arbeitsablauf sieht in etwa so aus:
git co local-dev
... do some commits...
git co master
git pull
git co local-dev
git rebase master
git co master
git merge local-dev
...run your tests again, and if they are green...
git push
Das hat ganz gut funktioniert, aber damit gewinnt man keine Schönheitspreise und all diese Schritte führen zwangsläufig zu einigen Fehlern. Hinzu kommt, dass, während Sie diese Schritte ausführen, wahrscheinlich schon wieder jemand anderes zugeschlagen hat. Wie wäre es mit etwas Einfacherem?
Verbesserungsversuch 2
Wieder einmal war es Iwein, der mit einer viel einfacheren Version aufwartete, die uns fast ganz zu unserem ersten Ansatz zurückbrachte. Wir arbeiteten wie zuvor an unserem lokalen Master-Zweig (oder an einem beliebigen Zweig Ihrer Wahl, solange er den Remote-Master verfolgt), aber wenn wir Änderungen von anderen Leuten einbrachten, verwendeten wir Rebasing statt Merge, um diese Commits in unseren lokalen Zweig einzufügen. Etwa so:
git co master
... do some commits...
git pull --rebase
...run your tests again, and if they are green...
git push
Das funktionierte viel besser und das war der Ansatz, den wir für den Rest des Tages verwendet haben.
Danach habe ich etwas gelesen und wie bei allen Dingen, die mit Git zu tun haben, gibt es Leute, die sagen, dass man das oben genannte niemals tun sollte und es gibt Leute, die darauf schwören. Auf der Website Git Ready finden Sie einen guten Artikel darüber und bei StackOverflow gibt es eine interessante Diskussion darüber, warum man diese Technik verwenden sollte oder nicht, so dass Sie sich selbst eine Meinung bilden können.
Schauen Sie sich das Online-Buch Pro Git an, das eine sehr gute Einführung in Git und/oder ein Handbuch enthält.
Verfasst von
Age Mooij
Contact