Zum Hauptinhalt springen

git

Git ist eine freie Software zur verteilten Versionsverwaltung von Dateien.

Git branching strategy​

Branching-Modelle werden in Teams oft unterschiedlich umgesetzt und sind Thema zahlreicher Debatten in der Community. Eins der vorrangigen Themen ist, wie viel Arbeit in einem Branch verbleiben sollte, bevor er zurück in den Haupt-Branch gemergt wird.

A. Trunk-Based Development: Enhancing Collaboration and Rapid Feedback​

Trunk-Based Development is a Git branching strategy that promotes collaboration and enables rapid feedback within a development team. In this strategy, all developers work directly on the main branch, minimizing the use of feature branches. This direct collaboration fosters communication and knowledge sharing among team members, leading to faster development cycles and improved efficiency.

One of the key advantages of Trunk-Based Development is its emphasis on continuous integration and continuous delivery. By working on the main branch, developers are continuously integrating their changes, reducing the risk of integration issues later on. This approach allows for rapid feedback, as any issues or bugs can be identified and addressed quickly. Additionally, it ensures that the codebase is always in a releasable state, enabling a constant flow of new features and enhancements.

While Trunk-Based Development offers several benefits, it is important to consider its disadvantages as well. By working directly on the main branch, conflicts can arise when multiple developers make changes to the same area of code. To mitigate this, implementing strict code review practices and utilizing automated testing tools can help identify and resolve conflicts early on. It is also crucial to have a disciplined approach to managing feature toggles, which allow changes not ready for release to be easily enabled or disabled.

B. Feature Branching: Parallel Development and Controlled Code Review​

Feature Branching is a popular Git branching strategy that enables parallel development and controlled code review. It involves creating separate branches for specific features or changes, allowing developers to work independently without affecting the main branch. This strategy promotes efficient collaboration and minimizes conflicts by isolating code changes within feature branches.

Release Branching​

Das Release-Branching basiert auf der Idee, das sich ein Release komplett innerhalb eines Branch befindet. Das heißt, dass der Release-Manager zu einem späten Zeitpunkt im Entwicklungszyklus einen Branch aus dem Haupt-Branch (Main) erstellt. Das Release-Branching ist für den Support versionierter Software auf dem Markt sehr wichtig. Ein einziges Produkt verfügt möglicherweise über mehrere Release-Branches (z. B. 1.1, 1.2, 2.0).

Feature Branching​

Feature-Branches werden oft mit Feature-Flags kombiniert – eine Art "Umschalter", mit denen ein Feature im Produkt aktiviert oder deaktiviert werden kann. Damit kann der Code einfacher im Haupt-Branch bereitgestellt werden, und es ist einfacher zu steuern, wann das Feature aktiviert wird. So lässt sich der Code weit vor dem Zeitpunkt bereitstellen, zu dem das Feature für Endbenutzer zur Verfügung gestellt wird.

Aufgaben-Branching​

Jedes Unternehmen hat eine natürliche Methode, in einem Vorgangs-Tracker in einzelne Aufgaben aufzuteilen. Vorgänge werden bei diesem Teil der Arbeit dann zum zentralen Kontaktpunkt des Teams. Beim Aufgaben-Branching, auch Vorgangs-Branching genannt, werden diese Vorgänge direkt mit dem Quellcode verbunden. Jeder Vorgang wird in seinem eigenen Branch implementiert und der Vorgangsschlüssel ist in den Branch-Namen integriert. Es ist leicht zu sehen, welcher Code welchen Vorgang implementiert: Du musst nur nach dem Vorgangsschlüssel im Branch-Namen suchen. Durch diese Transparenz ist es einfacher, bestimmte Änderungen am Haupt-Branch oder an einem beliebigen älteren Release-Branch vorzunehmen. Da Agile auf User Storys aufbaut, passen Task-Branches gut zur Agile-Entwicklung. Jede User Story (bzw. jeder Bugfix) bleibt in einem eigenen Branch, damit leicht ersichtlich ist, welche Vorgänge noch bearbeitet werden und welche zum Release bereit sind.

C. Git Flow: Structured Approach for Complex Projects​

Source = https://www.flagship.io/git-branching-strategies/

The Git Flow branching strategy provides a structured approach for managing complex projects, offering clear guidelines for organizing branches, releases, and hotfixes. This strategy builds on the foundation of Feature Branching, integrating two primary long-lived branches, “main” and “develop,” along with short-lived branches for feature development, release preparation, and addressing critical issues. By following the Git Flow methodology, teams can achieve a predictable development flow and ensure the stability of their codebase.

Branches are primarily used as a means for teams to develop features giving them a separate workspace for their code. These branches are usually merged back to a master branch upon completion of work. In this way, features (and any bug and bug fixes) are kept apart from each other allowing you to fix mistakes more easily. This means that branches protect the mainline of code and any changes made to any given branch don’t affect other developers.

info

A branching strategy, therefore, is the strategy that software development teams adopt when writing, merging and deploying code when using a version control system. It is essentially a set of rules that developers can follow to stipulate how they interact with a shared codebase.

This branching strategy Git Flow consists of the following branches:

  1. Main-Branch, master or production.
  2. Hotfixes-Branch to production. Hotfix - also helps prepare for a release but unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved; it enables developers to keep working on their own changes on the develop branch while the bug is being fixed.
  3. Release-Branches (with Date-Versioning). Release- help prepare a new production release; usually branched from the develop branch and must be merged back to both develop and master.
  4. Develop-Branches
  5. Feature-Branches to develop new features that branches off the develop branch.
  6. Idea-Branches to develop new future features that branches off the develop branch.

branching strategy

Abbildung Git branching strategy (source = https://www.flagship.io/git-branching-strategies/)

Verweise​