Git Branches und Commits?

2 Antworten

Hi! Interessante Frage.

Zunächst ist zu sagen, dass es keinen allgemeingültigen Ansatz gibt, git zu nutzen. Je nach Projekt und Team kann es ganz verschieden aussehen; da sollten Programmierer auch flexibel sein. Am besten einigt ihr euch in euer Arbeitsgruppe gemeinsam auf einen Stil, welchen ihr konsequent befolgen wollt (aber natürlich anpasst, wenn es Probleme gibt).

Es ist üblich, bei komplett unabhängigen Features in verschiedenen Branches zu arbeiten. So könnt ihr euch komplett auf einen Bereich konzentrieren und parallel arbeiten, ohne einander in die Quere zu kommen. Sonst können Branches auch auf dem Level von Systemen oder auch Teams organisiert sein. Im "main" Branch geschehen in der Regel Hotfixes, Wartungsarbeiten, Änderungen an projektbezogenen Sachen wie der README, und natürlich das Mergen von Features.

Ein Commit wird üblicherweise gemacht, sobald eine "Einheit" fertig ist, welche grundsätzlich an sich funktioniert. Sonst wird es für andere schnell unübersichtlich. Wie ihr diese definiert, kommt darauf an, mit welcher Technologie ihr arbeitet und wie ihr kollaborieren wollt. Es muss kein komplettes Feature sein, sollte aber mindestens neue Struktur in die Sache bringen und erfolgreich kompilieren.

Wenn du für dich in kleineren Schritten, auf dem Level von Zeilen oder x Minuten arbeiten möchtest (um z. B. Arbeit zu sichern), würde ich diese Experimente keinesfalls in die Versionshistorie pushen, sondern vorher in ein funktionierendes commit "squash"en / als "fixup commits" zusammenführen. So kann später herumgesprungen werden, ohne jemals komplett kaputten Code zu haben. An sich interessante Experimente, welche ihr ausbauen wollt, aber von der sonstigen Arbeit abweichen, gehören (meiner Meinung nach) in separate Branches.

Die Frage ist etwas verwickelt, ich hoffe, ich bin auf alles eingegangen. Du darfst natürlich gerne Nachfragen stellen. Ich wünsche viel Erfolg!

Überlegt sich jedes Team selbst.

Wir haben z.B. folgende Branch-Schemata:

master bzw. main
Aktueller Entwicklungsstand im Live-System

develop
Aktueller Entwicklungsstand

develop-Großes-Feature
Quasi ein "Hauot"-Feature-Branch, wird auf Basis von develop erstellt, dort wird dann das nächste große Ding entwickelt.

release/x.y.z
Alle Releases, die veröffentlicht wurden, so können wir bei Bedarf zurück gehen und schauen, was war und ggf. auch etwas ändern.

test-release/x.y.z
Das gleiche wie release/x.y.z, nur für das Test-System

nuget/x.y.z
In Ausnahmefällen gibt's Systeme, für die auch eine API zusätzlich zum eigentlichen System über den internen NuGet-Server verteilt werden, diese API-Packages bekommen dann eine eigen Version und einen eigenen Branch.

feature/Mein-Cooles-Feature
Wenn ein Feature zu groß ist, um es in einem Commit zu behandeln, aber zu klein, um einen "Haupt"-Feature-Branch daraus zu machen

ticket/Ticket-Nummer
Wenn eine bestimmte Kundenanfrage aus irgendwelchen Gründen nicht direkt in develop oder master bzw. main bearbeitet werden kann/sollte, wird dafür ein Ticket-Branch erstellt

Woher ich das weiß:Berufserfahrung – C#.NET Senior Softwareentwickler