Git-Workflows für Profis: Ein guter Git-Leitfaden

Git kann Ihr Projekt nicht nur bei der Versionskontrolle, sondern auch bei der Zusammenarbeit und dem Release-Management unterstützen. Wenn Sie verstehen, wie Git-Workflowmuster ein Projekt unterstützen oder behindern können, erhalten Sie das Wissen, um die Git-Prozesse Ihres Projekts effektiv zu bewerten und anzupassen.

In diesem Leitfaden werde ich Muster von Softwareentwicklungsprozessen isolieren, die in gängigen Git-Workflows zu finden sind. Das Wissen darüber wird Ihnen helfen, eine Richtung zu finden, wenn Sie einem Entwicklungsteam beitreten, es aufbauen oder erweitern. Die Vor- und Nachteile für bestimmte Arten von Projekten oder Teams werden in den von uns untersuchten Workflow-Beispielen hervorgehoben, sodass Sie auswählen können, was für Ihr Szenario gut funktionieren könnte.

Dies ist keine Einführung in die Verwendung von Git. Es gibt bereits fabelhafte Anleitungen und Dokumentationen dafür. Sie werden von diesem Git-Workflow-Leitfaden profitieren, wenn Sie bereits Erfahrung in einem Anwendungsentwicklungsteam haben und mit Workflow-Störungen, Integrationsimplosionen oder Git-Tastrophen konfrontiert waren – diese Muster können Aufschluss darüber geben, wie diese Situationen in Zukunft vermieden werden können.

Zusammenarbeit

In Bezug auf Git-Prozesse geht es bei der Zusammenarbeit oft um das Verzweigen von Workflows. Wenn Sie vorausdenken, wie Sie Commit-Bäume verflechten, können Sie Integrationsfehler minimieren und Ihre Release-Management-Strategie unterstützen.

Integrationszweig

Verwenden Sie einen Integrationszweig mit Softwareentwicklungsteams, die darauf hinarbeiten, eine Sammlung von Beiträgen als eine Einheit in der Produktion bereitzustellen. Dies steht im Gegensatz zu Teams, die sich auf die individuelle Bereitstellung von Funktionen konzentrieren. Oft möchten Teams letzteres tun, aber praktische Einschränkungen erzwingen einen Prozess, der ihre Bemühungen gruppiert, und das Team tut schließlich ersteres. Überprüfen Sie also Ihre tatsächliche Git-Nutzung, um zu sehen, ob Sie von dieser Art der Zusammenarbeit profitieren würden Muster.

Dieses Workflow-Muster ist ein nützlicher Ausgangspunkt, wenn das Risiko der Integration mehrerer Zweige hoch genug ist, um das Testen der kombinierten Beiträge als Ganzes zu rechtfertigen.

Ein Integrationszweig besteht normalerweise aus einem Hauptfeature und mehreren kleineren Beiträgen, die zusammen bereitgestellt werden. Führen Sie einen Integrationszweig durch den Prozess Ihres Entwicklungsteams (z. B. Fragen und Antworten und Akzeptanztests). Schieben Sie kleinere Commits darauf, um es nahezu produktionsbereit zu machen, und verwenden Sie dann einen Umgebungs- oder Release-Zweig (unten besprochen), um es für die Bereitstellung vorzubereiten.

Beachten Sie, dass die Beiträge zum Integrationszweig in die nächste Versionsstufe gemergt werden müssen, bevor ein weiteres Hauptfeature in den Integrationszweig gemergt werden kann – andernfalls mischen Sie Features in verschiedenen Stadien der Fertigstellung. Dies wird Ihre Fähigkeit hemmen, das freizugeben, was bereit ist.

Themenzweige

Teams werden Themenzweige verwenden wollen, wenn es wichtig ist, ihre Commit-Bäume in einem leicht lesbaren Zustand zu halten oder einzelne Funktionen rückgängig zu machen. Themenzweige bedeuten, dass die Commits überschrieben werden können (unter Verwendung eines Force-Push), um ihre Struktur zu bereinigen und auf ein Feature-Commit zu verkleinern.

Themenzweige gehören oft einem einzelnen Mitwirkenden, können aber auch ein ausgewiesener Bereich für ein Team sein, in dem ein Feature entwickelt wird. Andere Mitwirkende wissen, dass bei dieser Art von Zweig der Commit-Baum jederzeit neu geschrieben werden könnte, und sollten nicht versuchen, ihre lokalen Zweige damit synchron zu halten.

Ohne die Verwendung von Topic-Branches in Ihrem Git-Workflow sind Sie darauf beschränkt, sich an die Commits zu halten, die Sie an einen Remote-Branch pushen. Das Erzwingen eines Pushings eines neuen Commit-Baums in einen Remote-Zweig könnte andere Mitwirkende verärgern, die sich auf die aufrechterhaltene Integrität des Zweigs verlassen, mit dem sie synchronisieren.

Es besteht die Möglichkeit, dass Sie dieses Workflow-Muster bereits verwenden, ohne es zu merken, aber es lohnt sich, einen gemeinsamen Satz von Definitionen zwischen den Teams zu haben, um die dahinter stehenden Praktiken zu verstärken. Zum Beispiel magst du feststellen, dass die Konvention, dem Branch-Namen die Initialen des Branch-Erstellers voranzustellen, hilfreich ist, um zu signalisieren, welche Topic-Branches es sind. Wie auch immer, es liegt an Ihrem Team, über interne Konventionen zu entscheiden.

Verwenden Sie KEINE Themenzweige in öffentlichen Repositories, Sie verursachen eine Vielzahl von Konflikten für jeden, der seine lokalen Zweige mit einem Themenzweig synchronisiert hat, dessen Commit-Baum neu geschrieben wurde.

Gabel

Open-Source-Projekte gedeihen mit dieser von Github stammenden Funktion. Der Fork gibt den Repository-Betreuern ein erzwungenes Gateway, um direkt zu einem Ursprungs-Repository-Zweig zu pushen, aber was noch wichtiger ist, es erleichtert die Zusammenarbeit. Wahoo!

Möglicherweise befinden Sie sich in dem Szenario, in dem das Erstellen eines Forks eines privaten Repositorys auch Ihren Anforderungen entspricht. Wenn Sie das Ursprungs-Repository für die Mitwirkenden des Fork-Repositorys auf schreibgeschützt setzen und mit Pull-Anforderungen rollen, haben Sie dieselben Vorteile wie die Open-Source-Community-Erfahrung. Teams aus verschiedenen Organisationen können effektiv arbeiten, indem sie einen Fork verwenden, der als Plattform für die Kommunikation und die Einhaltung von Projektrichtlinien dienen kann.

Das Fork-Workflow-Muster gibt Teams ihren eigenen Raum, um auf die Weise zu arbeiten, an die sie gewöhnt sind, mit einem einzigen Integrationspunkt zwischen den beiden Repositories – einer Pull-Anfrage. Eine übermäßige Kommunikation ist in der Pull-Request-Beschreibung zwingend erforderlich. Die Teams hatten getrennte Kommunikationsströme, bevor ein Pull-Request ausgegeben wurde, und die Hervorhebung der bereits getroffenen Entscheidungen wird den Überprüfungsprozess beschleunigen.

Ein Vorteil des Fork-Workflows besteht natürlich darin, dass Sie Kommentare an Mitwirkende des ursprünglichen Repositorys richten können, da die Berechtigungen nach unten kaskadieren. Aus Sicht des Ursprungs-Repositorys haben Sie die Kontrolle, Forks zu löschen, wenn sie nicht mehr benötigt werden.

Stellen Sie sicher, dass Sie ein Tool verwenden, das Forking und Pull-Requests erleichtert, um dieses Muster zu nutzen. Diese Tools sind nicht auf Github beschränkt: Andere beliebte Optionen sind Bitbucket und GitlLab. Aber es gibt noch einige andere Git-Workflow-Hosting-Dienste, die diese Funktionen (oder ähnliche) haben werden. Wählen Sie aus, welcher Dienst für Sie am besten geeignet ist.

Verwenden Sie KEINEN Fork eines privaten Repositorys für jedes Mitglied eines Teams. Die zahlreichen verzweigten Repositories können es für mehrere Mitglieder schwierig machen, an demselben Feature-Branch zusammenzuarbeiten, und das Synchronisieren all dieser Repositories kann aufgrund der schieren Anzahl der sich bewegenden Teile fehleranfällig werden. Open-Source-Projekte haben Mitglieder des Kernteams mit Push-Zugriff auf das Ursprungs-Repository, wodurch dieser Overhead verringert wird.

Klon

Eine gängige Outsourcing-Strategie besteht darin, „Beitragsplätze“ für ein Projekt zu haben, die von mehreren Softwareentwicklern besetzt werden können. Es ist Sache des Outsourcing-Unternehmens, seine Ressourcenpipeline zu verwalten, um vertraglich vereinbarte Stunden zu liefern. Die Probleme, mit denen es konfrontiert ist, sind, wie es einen Pool von Entwicklern für die Projekte jedes Kunden an Bord bringt, schult und pflegt.

Die Verwendung eines Klons des Projektarchivs bietet dem ausgelagerten Team eine isolierte Schulungs- und Kommunikationsumgebung, um ihre Beiträge zu verwalten, Richtlinien durchzusetzen und den Wissensaustausch zu nutzen – alles unter dem wachsamen Auge des Entwicklungsteams des Kunden. Sobald ein Beitrag dem Standard entspricht und bereit für das Haupt-Repository ist, kann er zu einem der entfernten Zweige des Ursprungs-Repositorys gepusht und wie gewohnt integriert werden.

Einige Projekte haben hohe Erwartungen an die Einhaltung ihrer Codierungskonventionen und definierten Git-Workflow-Standards, um zu ihrem Repository beizutragen. Es kann entmutigend sein, in dieser Umgebung zu arbeiten, bis Sie die Grundlagen gelernt haben, also arbeiten Sie als Team zusammen, um die Zeit für beide Parteien zu optimieren.

Erstellen Sie KEINE gehostete Kopie des Repositorys des Kunden ohne dessen Erlaubnis, Sie könnten eine vertragliche Vereinbarung brechen, vergewissern Sie sich im Voraus, dass diese Vorgehensweise dem Projekt mit dem Kunden zugute kommt.

Freigabeverwaltung

Die Schritte zwischen der Zusammenarbeit und der Veröffentlichung beginnen an unterschiedlichen Punkten innerhalb des Entwicklungsprozesses für jedes Team. Im Allgemeinen sollten Sie nicht mehr als ein Git-Muster für die Release-Verwaltung verwenden. Sie möchten einen möglichst einfachen Workflow haben, der es Ihrem Team ermöglicht, effektiv zu liefern.

Umweltbranchen

Ihr Softwareentwicklungsprozess kann von mehreren Umgebungen unterstützt werden, um bei der Qualitätssicherung zu helfen, bevor er in der Produktion bereitgestellt wird. Umgebungszweige ahmen die Stufen dieses Prozesses nach: Jede Stufe entspricht einer Verzweigung, und Beiträge fließen in einer Pipeline durch diese.

Teams, die mit diesen Prozessen arbeiten, haben oft Anwendungsumgebungen für jede Phase in der Pipeline eingerichtet, zum Beispiel „QA“, „Staging“ und „Produktion“. In diesen Fällen ist die Infrastruktur vorhanden, um das Personal zu unterstützen, das dafür verantwortlich ist, ein Feature oder einen Beitrag für seinen Teil dessen, was es bedeutet, produktionsreif zu sein (z. B. explorative Tests, QA, Abnahmetests), abzuzeichnen, bevor es auf die nächste Person übertragen wird Bühne. Dies gibt ihnen ihren eigenen Ort zum Bereitstellen, Testen und Evaluieren anhand ihrer Anforderungen, mit einem Git-Workflow, um seine Reise durch den Sign-Off-Tunnel aufzuzeichnen.

Für kleine Teams, die als Einheit auf eine Veröffentlichung hinarbeiten können, ist es in Ordnung, einen Zweig für jede Phase des Prozesses zu haben. Leider kann eine Pipeline wie diese zu leicht zu Engpässen führen oder sich zusammenballen und Lücken hinterlassen. Es koppelt Ihren Git-Prozess an Ihre Infrastruktur, was zu Problemen führen kann, wenn Funktionen hochgefahren werden müssen und beide Prozesse skaliert werden müssen.

Verwenden Sie dieses Muster NICHT , ohne zuerst die langfristigen Vorteile anderer Muster zu berücksichtigen.

Branches freigeben

Ein Team, das eine Sammlung von Beiträgen als Einheit in aufeinanderfolgenden Sprints an seine Produktionsanwendung weiterleitet, kann Release-Zweige als günstig empfinden.

Eine Sammlung von nahezu „produktionsreifen“ Commits erhält kleinere Fehlerkorrekturen in einem Release-Zweig. Verwenden Sie einen Integrations-Branch, um die Funktionen zu kombinieren und zu testen, bevor Sie dessen Commit-Baum auf einen Release-Branch verschieben. Beschränken Sie die Verantwortung eines Release-Branch auf eine abschließende Prüfung vor der Bereitstellung in der Produktionsanwendung.

Release-Zweige unterscheiden sich von Umgebungszweigen dadurch, dass sie eine kurze Lebensdauer haben. Release-Zweige werden nur bei Bedarf erstellt und zerstört, nachdem der Commit-Baum in der Produktion bereitgestellt wurde.

Versuchen Sie zu verhindern, dass Release-Branches mit Ihrer Softwareentwicklungs-Roadmap gekoppelt werden. Wenn Sie sich darauf beschränken, einem vordefinierten Plan zu folgen, wird die Bereitstellung einer Version verzögert, bis alle geplanten Funktionen produktionsbereit sind. Wenn Sie der Roadmap keine Versionsnummer zuweisen, bevor Sie einen Release-Branch erstellen, können Sie diese Art von Verzögerungen verringern, indem Sie produktionsreife Features in einem Release-Branch platzieren und bereitstellen können.

Verwenden Sie für den Release-Branch-Namen eine Namenskonvention für Versionsnummern, um deutlich zu machen, welche Version des Repositorys in der Produktion bereitgestellt wurde.

Stellen Sie den Master-Branch und nicht den Release-Branch bereit. Um kleinere Korrekturen an Release-Zweigen vor dem Zusammenführen mit dem Master-Zweig zu fördern, verwenden Sie einen Git-Hook im Master-Zweig, um auszulösen, nachdem eine Zusammenführung stattgefunden hat, um den aktualisierten Commit-Baum automatisch in der Produktion bereitzustellen.

Indem Sie zu einem bestimmten Zeitpunkt nur einen Release-Zweig zulassen, vermeiden Sie den Aufwand, mehrere Release-Zweige miteinander synchron zu halten.

Verwenden Sie KEINE Release Branches mit mehreren Teams, die am selben Repository arbeiten. Auch wenn Release-Zweige kurzlebig sind, wenn die endgültige Überprüfung zu lange dauert, hält es das andere Team davon ab, Releases zu veröffentlichen. Ein Team, das auf dem Release-Zweig eines anderen Teams huckepack läuft, wird wahrscheinlich Fehler einführen und Verzögerungen für beide Teams verursachen. Sehen Sie sich das Veröffentlichungsmuster mit Zeitstempel unten an, das für eine größere Anzahl und Gruppen von Mitwirkenden besser funktioniert.

Veröffentlichungen mit Zeitstempel

Anwendungen mit Infrastruktureinschränkungen planen ihre Bereitstellung normalerweise in Zeiten mit geringem Datenverkehr. Wenn Ihr Projekt regelmäßig mit einsatzbereiten Funktionen konfrontiert wird, können Sie von der Verwendung von Releases mit Zeitstempel profitieren.

Ein Release mit Zeitstempel verlässt sich darauf, dass der Bereitstellungsprozess automatisch ein Zeitstempel-Tag zum letzten Commit auf dem Master-Branch hinzufügt, der in der Produktion bereitgestellt wurde. Themenzweige werden verwendet, um ein Feature durch den Entwicklungsprozess zu führen, bevor es in den Master-Branch gemergt wird, um auf die Bereitstellung zu warten.

Das Zeitstempel-Tag sollte einen tatsächlichen Zeitstempel und eine Bezeichnung enthalten, die angibt, dass es sich um eine Bereitstellung handelt, zum Beispiel: deployed-201402121345 .

Das Einbeziehen von Bereitstellungsmetadaten in Form des Zeitstempel-Tags in den Commit-Baum des Master-Zweigs hilft Ihnen beim Debuggen von Regressionen, die in die Produktionsanwendung freigegeben wurden. Es ist unwahrscheinlich, dass die Person, die mit der Suche nach der Ursache des Problems beauftragt ist, viel über jede einzelne Zeile weiß, die in der Produktionsanwendung bereitgestellt wird. Das Ausführen eines git diff Befehls für die letzten beiden Tags kann schnell einen Schnappschuss darüber geben, welche Commits zuletzt bereitgestellt wurden und wer die Commit-Autoren sind, die bei der Lösung des Problems helfen könnten.

Zweige mit Zeitstempel sind mehr, als sie an der Oberfläche erscheinen. Ein einfacher Mechanismus zum Aufzeichnen einer Bereitstellung von Funktionen in der Warteschlange erfordert überraschend viele gute Prozesse, um ihn zu steuern. Der Prozess ist skalierbar und funktioniert auch mit einem kleinen Team von Mitwirkenden gut.

Damit dieses Git-Workflow-Muster wirklich effektiv ist, muss der Master-Branch immer bereitstellbar sein. Das könnte für Ihr Team verschiedene Dinge bedeuten, aber im Wesentlichen müssen alle Commits den Entwicklungsprozess Ihres Projekts durchlaufen haben, bevor sie im Master-Branch landen.

Neue Commits, die auf dem Master-Zweig landen, werden mehrmals am Tag ausgeführt. Dies ist ein Problem für Themenzweige, die den Entwicklungsprozess durchlaufen haben und während dieser Zeit nicht mit dem Hauptzweig synchronisiert wurden. Leider kann ein solches Szenario Regressionen in den Master-Zweig einführen, wenn Merge-Konflikte falsch behandelt werden.

Wenn Zusammenführungskonflikte zwischen einem Topic-Branch und dem Master-Branch auftreten, sollte das Risiko, einen neuen Fehler einzuführen, mit Ihrem Team besprochen werden, bevor Sie den Remote-Master-Branch aktualisieren. Wenn Zweifel bestehen, dass eine Regression auftreten könnte, kann der Topic-Zweig erneut dem Qualitätssicherungsprozess unterzogen werden, wobei die Merge-Konflikte gelöst sind.

Um Integrationsfehler zu reduzieren, können Entwickler, die an verwandten Teilen des Repositorys arbeiten, zusammenarbeiten, um festzulegen, wann ihre Topic-Branches am besten mit dem Master-Branch zusammengeführt und synchronisiert werden können. Integrationszweige funktionieren auch gut, um Konflikte von verwandten Themenzweigen zu lösen – diese sollten den Testprozess durchlaufen, bevor sie in die Warteschlange auf dem ausstehenden Master-Zweig zusammengeführt werden.

Softwareentwicklungsprojekte mit vielen Mitwirkenden müssen Kollaborations- und Release-Management-Prozesse mit praktischen und effizienten Ansätzen bewältigen. Die zusätzlichen Metadaten zum Commit-Baum, die wir durch die Verwendung von Veröffentlichungen mit Zeitstempel erhalten, sind ein Hinweis auf die Weitsicht der Teams, die sich darauf vorbereiten, auf Produktionsprobleme zu reagieren.

Versionszweig

Wenn Sie ein Repository haben, das Sie nicht nur in der Produktion ausführen, sondern auch von anderen für ihre eigenen gehosteten Anwendungen verwenden, kann die Verwendung von Versionsverzweigungen Ihrem Team die Plattform bieten, um Benutzer zu unterstützen, die nicht auf dem neuesten Stand der Entwicklungen Ihrer Anwendung bleiben können oder können .

Ein Repository, das Versionszweige verwendet, hat einen Zweig pro Nebenversion der Anwendung. Haupt-, Neben- und Patch-Versionen werden in der Dokumentation zur semantischen Versionierung erläutert. Versionszweige folgen normalerweise einer Namenskonvention, um das Wort „stable“ einzuschließen und die Patchnummer aus der Anwendungsversion zu entfernen: zB 2-3-stable , um ihren Zweck und ihre Zuverlässigkeit für Endbenutzer offensichtlich zu machen.

Git-Tags können bis hinunter zur Patch-Versionsnummer der Anwendung angewendet werden, aber Versionszweige sind nicht so feinkörnig. Ein Versionszweig zeigt immer auf den stabilsten Commit für eine unterstützte Nebenversion.

Wenn Sicherheitspatches oder die Notwendigkeit einer Rückportierung von Funktionen hinzukommen, stellen Sie die Commits zusammen, die für die Arbeit mit älteren Anwendungsversionen, die Sie unterstützen, erforderlich sind, und verschieben Sie sie entsprechend in Ihre Versionszweige.

Verwenden Sie KEINE Versionszweige, es sei denn, Sie unterstützen mehr als eine Version Ihres Repositorys.

Zusammenfassung

Wenn sich die Größe Ihres Teams ändert oder Ihr Projekt seine Prozesse durch kontinuierliche Evaluierung weiterentwickelt, lassen Sie es nicht aus, auch Ihren Git-Prozess zu evaluieren. Verwenden Sie die Muster in diesem Tutorial als Ausgangspunkt, um Sie auf den Weg der Git-Workflow-Gerechtigkeit zu führen.

Das Muster in diesem Leitfaden kann Ihnen dabei helfen, Ihr verteiltes Versionskontrollsystem so anzupassen, dass es für Sie funktioniert. Wenn Sie sich über Git-Workflows informieren möchten, schauen Sie sich unbedingt Gitflow, Github Flow und vor allem die erstaunliche Git-SCM-Dokumentation an!