Share
Git bietet zahlreiche Vorteile für den Solo-Entwickler, aber es glänzt auch bei der Teamzusammenarbeit.
Der Schlüssel zum Aufbau eines großartigen Teamworkflows mit Git ist die Kommunikation. Git ist vielseitig und flexibel und kann eine Vielzahl von Nutzungsmustern aufnehmen. Durch die frühzeitige Festlegung der Arbeitsregeln für den Straßenverkehr werden Reibungen und Verwirrungen beseitigt, und ein Team kann die Vorteile von Git optimal nutzen: die Produktivität steigern.
Davon abgesehen, wäre dies kein großartiges Tutorial, wenn es keinen konkreten Git-basierten Teamworkflow für Sie zum Überprüfen gibt. Das folgende Beispiel basiert auf einem sehr beliebten Git-Workflow, der von Vincent Driessen mit dem Namen Git-Flow erstellt wurde, unterscheidet sich jedoch in bestimmten Punkten. Es gibt mehrere beliebte Git-Workflows im Web. Ich würde vorschlagen, so viele wie möglich zu lesen, damit Ihr Team einen Regelsatz auswählen kann, der sich am besten eignet.
Beginnen wir Ihre Forschung mit dem folgenden Workflow:
Das Meister Branch ist immer einsetzbar. Immer.
Ein einsatzbereit Meister Branche ist aus vielen Gründen wichtig. Erstens ermöglicht es jedem, der neu in einem Projekt ist, sofort fehlerfrei abzurufen und zu bauen. Nichts ist so frustrierend, dass es nicht möglich ist, ein fremdes Projekt aufzubauen.
Zweite, Meister Zeigt den aktuellen Stand der Produktion und / oder des ausgelieferten Produkts an. Wenn Hotfixes gemacht werden müssen, ist klar, von wo aus verzweigt werden soll.
Zum Schluss noch ein Einsatz Meister ist ein Sicherheitsnetz. Ob Meister Ist immer einsatzbereit, dann können wir es problemlos einrichten. Sorgen verursachen Stress und Stress verursacht Verdauungsstörungen. Niemand braucht das.
Das entwickeln Branche sollte der Hauptzweig der kontinuierlichen Entwicklung sein. Funktionszweige werden erstellt und wieder zusammengeführt entwickeln, und entwickeln repräsentiert die blutende Kante unserer Codebase.
Da beide Meister und entwickeln Da es sich um dauerhafte und stark frequentierte Branchen handelt, sollten sie niemals direkt eingearbeitet werden. Stattdessen sollte die gesamte Arbeit in Feature-Zweigen ausgeführt werden. Wenn Sie eine neue Funktion implementieren, verzweigen Sie von entwickeln und hacken Sie die Funktion aus.
Es gibt keine festen Regeln für die Benennung von Zweigen, insbesondere für Feature-Zweige. Wenn ein Zweig ein Fix ist, ist es wahrscheinlich am besten, ihm ein "Fix-" voranzustellen. Wenn es sich bei einem Zweig um ein Release handelt, wird allgemein empfohlen, dass der Zweig das folgende Format hat: "release-X.X.X".
Im Allgemeinen sollten Zweignamen beschreibend sein. Und vielleicht komisch. Das gelegentliche und rechtzeitige Wortspiel würde nicht schief gehen.
Sobald Ihre neue fantastische Funktion codiert ist, ist es Zeit, sie wieder in einen gemeinsam genutzten Zweig zu bringen (nehmen wir an, wir verschmelzen miteinander) entwickeln). Aber bevor in verschmelzen entwickeln, Stellen Sie sicher, dass in Ihrem Funktionszweig die neuesten Änderungen vorgenommen wurden entwickeln weil es Konflikte geben kann.
Alle Konfliktlösungen sollten in Ihrem Funktionszweig stattfinden. Wenn Sie verzweigt haben, um eine kleine Änderung / Korrektur vorzunehmen und Sie haben den Zweig nicht zur Fernbedienung geschoben, rebase entwickeln in Ihrem Feature-Zweig und fügen Sie dann Ihren Feature-Zweig zusammen entwickeln. Drücken Sie, und löschen Sie Ihren lokalen Funktionszweig.
Wenn Sie Ihren Zweig auf die Fernbedienung verschoben haben, führen Sie zuerst eine Zusammenführung durch entwickeln in Ihren Zweig (Konfliktlösung), und fügen Sie dann Ihren Zweig zusammen entwickeln. Drücken Sie einfach, um sowohl den lokalen als auch den entfernten Funktionszweig zu löschen.
Bedenken Sie bei der Umbasierung, dass es sich um eine destruktiv Aktion. Bedeutung… sei vorsichtig! Die Neueinstellung ist wirklich nützlich, um Commit-Historien zu bereinigen, aber Sie möchten die Historie nicht für etwas neu schreiben, das mit jemandem geteilt wurde.
Hier sind ein paar Regeln, um Sie beim Umbasieren zu schützen:
Accentsconagua
entwickeln ist ein gemeinsamer Zweig. mein tolles Feature ist eine lokale Niederlassung. Jetzt bin ich bereit zu verschmelzen mein fantastisches Feature zu entwickeln, aber ich möchte sicherstellen, dass alle Änderungen, die in passiert sind entwickeln werden zuerst in meinen Feature-Zweig eingefügt:git checkout my-awesome-funktion git rebase entwickeln git checkout entwickeln git merge my-awesome-feature
Nehmen wir an, wir haben verzweigt, wir haben kodiert, wir haben uns zusammengeschlossen / umbenannt entwickeln, und jetzt können wir unseren neuen Code wieder zusammenführen entwickeln. Aber sollten wir Vielleicht sollte jemand zuerst unsere Änderungen überprüfen ...
Code-Reviews sind eine gute Sache! Sie ermöglichen es Ihnen, wertvolles Feedback zu Ihrer geleisteten Arbeit zu erhalten, und - wenn nichts anderes - die Wahrscheinlichkeit erhöhen, dass Fehler aufgefangen und behoben werden.
Dies ist der Punkt, an dem Gits Pull-Requests (und die Bitbucket-Schnittstelle) hilfreich sind. (Weitere Informationen zum Öffnen und Verwalten von Pull-Anforderungen in Bitbucket finden Sie in Teil zwei dieser Serie: Verwenden von Pull-Anforderungen als Code-Reviews.) Pull-Anfragen können weitaus mehr sein, als nur den geänderten Code zu überprüfen. Da Pull-Anforderungen markenbasiert sind, können sie zu Threads werden, um einzelne Features zu diskutieren und zusammenzuarbeiten. Sie können Fotos einbetten, um Designs zu teilen, direkt Codezeilen kommentieren und sogar GIFs und Emojis verwenden, um Spaß zu haben.
Beim Zusammenführen von Pull-Anforderungen sollte die Zusammenführung vorzugsweise von derselben Person erstellt werden, die die Pull-Anforderung geöffnet hat, da dies wahrscheinlich die Person ist, die den neuen Code geschrieben hat. Um dies zu erreichen, sollten Überprüfer einen Kommentar hinterlassen, der den neuen Code bestätigt, aber nicht tatsächlich auf die Zusammenführungsschaltfläche klicken. Sobald ein Teamkollege dem Code einen "Daumen hoch" gibt (entweder bildlich oder wörtlich mit einem :Daumen hoch: emoji), der Pull-Request-Öffner kann dann fortfahren und zusammenführen. Peer Review und saubere Protokolle - eine wunderbare Sache!
Einmal entwickeln ist bereit für eine Veröffentlichung, führen Sie eine Fusion durch Meister:
git checkout master git merge --no-ff entwickeln
Beachte das --no-ff Flagge? Dadurch wird sichergestellt, dass die Zusammenführung kein schneller Vorlauf ist, und es wird ein neues Commit erstellt. Warum wollen wir das? So können wir es markieren! Kennzeichnen Sie das Commit als neue Version:
git-Tag -a vX.X.X -m 'Version X.X.X'
Dann verschmelzen Meister zurück in entwickeln damit entwickeln hat die Version festgeschrieben.
Apropos Versionen sollten wir semantische Versionierung verwenden. Das bricht zusammen MAJOR.MINOR.PATCH. Im Algemeinen, HAUPT ist eine vollständige Versionsnummer, die für massive Änderungen und / oder Meilensteine verwendet wird. Es ist erlaubt, die Rückwärtskompatibilität zu brechen. GERINGER wird für neue Funktionen verwendet. Es sollte keine Abwärtskompatibilität verursachen. PATCH ist für kleine Änderungen und Korrekturen und sollte die Abwärtskompatibilität nicht beeinträchtigen. Wir sollten in einer Vorabversion sein (0.x.x) bis wir starten.
Wir sollten niemals Fehler versenden.
… Aber wenn wir das tun, ist es am besten, sie schnell zu beheben. Schon seit entwickeln Da möglicherweise unfertige Funktionen vorhanden sind, sollten Hotfixes aus der aktuellen Version heraus verzweigt werden Meister (da Meister ist immer einsatzbereit!).
Um einen Hotfix zu erstellen, verzweigen Sie Meister, machen Sie das Problem, und führen Sie dann eine aus nicht vorspulen Vereinen Meister. Markiere es und füge es dann zusammen Meister zurück in entwickeln (weil wir wollen entwickeln das Update auch haben). Sie können den Hotfix-Zweig löschen.
Lassen Sie uns über Git-Commit-Nachrichten sprechen. Wenn Sie sich an ein allgemeines Format halten, können Sie unsere Protokolle leichter durchsehen. Hier sind einige gute Regeln:
Wenn Sie mehr über das richtige Schreiben von Git-Commits erfahren möchten, werfen Sie einen Blick auf den Beitrag von Tim Pope.
Lassen Sie mich noch einmal darauf hinweisen, dass der oben skizzierte Workflow eine Richtlinie ist und keine harten Regeln, die Sie strikt für Ihre Teams anwenden sollten. Wenn Sie alle mögen, verwenden Sie sie! Wenn etwas für Sie nicht funktioniert, optimieren Sie es!
Das Wichtigste ist, dass Ihr Team einen definierten Git-Workflow vereinbart und sich daran hält. Sobald dies geschieht, folgt die Zusammenarbeit und Sie können die Vorteile nutzen, die Git bietet, wenn Sie als Team arbeiten.
Einige Alternativen zum Git-Flow-Workflow finden Sie im Atlassian-Handbuch für Git-Workflows.
