Grundlegendes zur Quellcodeverwaltung

Quellcodeverwaltung (SCM) hilft Entwickler(inne)n, parallel zu arbeiten, ohne die Arbeit der jeweils anderen Person zu verlieren. Teams können Branches erstellen, Änderungen in Commits aufzeichnen, vorgeschlagene Updates überprüfen, Konflikte lösen und bei Bedarf zu einer früheren Version zurückkehren. In der modernen Softwareentwicklung ist SCM eng mit Versionskontrolle, Code Review, Sicherheit und CI/CD verbunden. Die Quellcodeverwaltung verwendet ein Repository und ein Versionskontrollsystem, um Änderungen an einem Projekt zu organisieren. Das Repository speichert den Quellcode und kann auch Konfigurationen, Build-Skripte, Tests, Dokumentationen und andere Dateien enthalten, die zur Entwicklung und Bereitstellung der Software benötigt werden. SCM wird häufig als Synonym für Versionskontrolle verwendet. In der Praxis beschreibt die Versionskontrolle das System, das Revisionen aufzeichnet. Die SCM hingegen berücksichtigt auch die weiter gefassten Workflows für Zusammenarbeit und Bereitstellung, die um diese Revisionen herum aufgebaut sind. Ein gut verwaltetes Repository wird zu einer zentralen Anlaufstelle für das Projekt. Entwickler(innen) können den aktuellen Zustand des Codes inspizieren, Revisionen vergleichen, den Kontext hinter einer Änderung nachvollziehen und zusammenarbeiten, ohne sich auf manuell ausgetauschte Dateien oder nicht dokumentierte Übergaben verlassen zu müssen.

Ein SCM-Workflow verbindet einzelne Änderungen zu einem überprüften und nachverfolgbaren Ergebnis. Zwar nutzt jedes Team eigene Befehle und ein eigenes Branching-Modell, aber der grundlegende Prozess besteht in der Regel aus den folgenden Schritten:

1. Repository erstellen oder klonen

Ein Team erstellt ein Repository für ein Projekt oder klont ein bestehendes Repository in eine lokale Entwicklungsumgebung. Alle Entwickler(innen) können mit den für ihre Aufgabe benötigten Dateien und dem Verlauf arbeiten und dabei eine Verbindung zum gemeinsamen Projekt aufrechterhalten.

2. Branch für eine Änderung erstellen

Ein Branch ermöglicht eine separate Entwicklungslinie. Entwickler(innen) können an einem Feature, einem Fix oder einem Experiment arbeiten, ohne den gemeinsamen Standard-Branch zu ändern, bevor die Arbeit fertig ist. Kurzlebige Branches erleichtern den Review von Änderungen und verringern das Risiko, dass nicht zusammenhängende Tätigkeiten miteinander verschmelzen.

3. Fortschritte in Commits aufzeichnen

Ein Commit zeichnet eine Reihe zusammengehöriger Änderungen zu einem bestimmten Zeitpunkt auf. Zielgerichtete Commits erleichtern es Teammitgliedern, die Änderung zu verstehen, sie zu überprüfen, den Grund für eine Regression zu identifizieren oder das Projekt in einen früheren Zustand zurückzusetzen. Eine nützliche Commit-Nachricht beschreibt, was geändert wurde und warum. Dieser Kontext hilft zukünftigen Mitwirkenden, den Projektverlauf nachzuvollziehen, ohne die Entscheidung von Grund auf neu rekonstruieren zu müssen.

4. Änderung freigeben und überprüfen

Entwickler(innen) pushen ihren Branch in das gemeinsame Repository und öffnen einen Merge Request. Durch einen Merge Request erhalten Prüfer(innen) einen Ort, an dem sie die vorgeschlagenen Änderungen prüfen, Implementierungsdetails besprechen, automatisierte Ergebnisse zu überprüfen und bestätigen können, dass das Update den teaminternen Standards entspricht. In GitLab können Merge Requests mit Approvalregeln, geschützten Branches und automatisierten Pipelines kombiniert werden, um einen kontrollierten Weg in den Standard-Branch zu schaffen. Erfahre mehr über die Quellcodeverwaltung in GitLab.

5. Konflikte lösen und zusammenführen

Wenn zwei Branches überlappende Teile eines Projekts ändern, kann das SCM-System einen Konflikt erkennen. Die betroffenen Mitwirkenden können die konkurrierenden Änderungen überprüfen, entscheiden, welches Ergebnis korrekt ist, und den Branch aktualisieren, bevor sie sie zusammenführen. Sobald die Änderung genehmigt und die erforderlichen Prüfungen bestanden sind, können sie im gemeinsamen Branch zusammengeführt werden. Der resultierende Verlauf liefert einen Nachweis der Änderung und deren Review-Kontextes.

6. Validieren, veröffentlichen und wiederherstellen

SCM kann eine Änderung mit automatisierten Builds, Tests, Sicherheitsprüfungen und Bereitstellungs-Workflows verknüpfen. Wenn ein Update ein unerwartetes Problem verursacht, kann das Team anhand des Projektverlaufs Revisionen vergleichen, eine Änderung rückgängig machen oder einen bekannten guten Zustand wiederherstellen.

SCM reduziert das operative Risiko der kollaborativen Softwareentwicklung und gibt Teams eine wiederholbare Methode zur Änderungsverwaltung an die Hand.

Zusammenarbeiten, ohne Arbeit zu überschreiben

Mehrere Entwickler(innen) können an separaten Branches arbeiten und ihre Änderungen durch Review und Merging zusammenführen. Das ist sicherer und transparenter als der manuelle Austausch von Dateien oder die Abhängigkeit von informeller Koordination.

Verstehen, was sich geändert hat und warum

Ein Repository-Verlauf zeichnet Änderungen im Laufe der Zeit auf. Teams können mithilfe von Commits, Branches, Merge Requests und damit verbundenen Diskussionen nachvollziehen, wie ein Feature entstanden ist und wo möglicherweise ein Fehler enthalten ist.

Qualität durch Review und Automatisierung verbessern

SCM macht Code-Änderungen sichtbar, bevor sie den gemeinsamen Branch erreichen. Die Kombination von Reviews mit automatisierten Tests und anderen Prüfungen hilft Teams, Probleme früher zu erkennen und einheitliche Standards anzuwenden.

Fehler rückgängig machen

Da Revisionen gespeichert werden, können Teams den aktuellen Zustand mit früheren Versionen vergleichen und Änderungen bei Bedarf rückgängig machen. Dies fungiert als Schutz für Experimente und die Wiederherstellung nach Vorfällen.

Governance und Rechenschaftspflicht etablieren

SCM kann Steuerungsmöglichkeiten darüber bieten, wer geschützte Branches ändern darf, wer Updates genehmigen muss und welche Prüfungen vor einem Merge bestanden werden müssen. Die Prüfprotokolle können Teams auch dabei helfen, wichtige Aktionen in einem Projekt zu verstehen.

Diese Begriffe überschneiden sich, können sich aber verschiedene Teile des Entwicklungsablaufs beziehen.

Versionskontrollsysteme sind in der Regel zentralisiert oder verteilt.

Zentralisierte Versionskontrolle

Ein zentralisiertes System speichert den primären Projektverlauf in einem zentralen Repository. Entwickler(innen) verbinden sich in der Regel mit diesem System, um Dateien abzurufen und Änderungen einzureichen. Dieses Modell ist möglicherweise einfacher zu verstehen und zu verwalten, aber die Arbeit kann stärker vom Netzwerkzugriff und dem zentralen Dienst abhängen.

Verteilte Versionskontrolle

Ein verteiltes System gibt Entwickler(inne)n eine lokale Kopie des Repositorys und dessen Verlauf an die Hand. Entwickler(innen) können Branches erstellen, den Verlauf einsehen und viele Änderungen lokal vornehmen, bevor sie sie an das Remote-Repository weitergeben. Git ist ein verteiltes Versionskontrollsystem und wird für die kollaborative Softwareentwicklung weitverbreitet eingesetzt.

Ein Modell auswählen

Das richtige Modell hängt vom Workflow des Teams, der Größe des Repositorys, der Konnektivität, den Governance-Anforderungen und den operativen Einschränkungen ab. Für viele moderne Teams besteht die wichtige Entscheidung nicht nur darin, wie Revisionen gespeichert werden, sondern auch darin, wie Repository-Zugriff, Code Review, Automatisierung, Sicherheit und Compliance rund um diese Revisionen ineinandergreifen.

Wie verändert KI die Quellcodeverwaltung? Erfahre mehr über die Quellcodeverwaltung der nächsten Generation, damit Softwareteams mit Menschen und mit KI-Agents arbeiten können.

Bei der Bewertung einer SCM-Plattform solltest du den gesamten Workflow und nicht nur die Speicherung im Repository berücksichtigen.

Repository- und Branching-Funktionen

Achte auf zuverlässigen Git-Support, klare Repository-Organisation, praktische Branching-Workflows und Tools, die Teams dabei helfen, mit der aktuellen Version eines Projekts zu arbeiten.

Code Review und Approvals

Der Review sollte Teil des Änderungs-Workflows sein. Berücksichtige Merge oder Pull Requests, Inline-Diskussionen, erforderliche Approvals, die Zuweisung von Prüfer(inne)n und die Sichtbarkeit wieder gestarteter Feedbacks.

Zugriffskontrolle und Governance

Teams benötigen möglicherweise granulare Berechtigungen, geschützte Branches, Approval Policies, Audit Events und Compliance-Steuerungen. Diese Funktionen helfen Unternehmen, einheitliche Regeln anzuwenden, ohne sich vollständig auf manuelle Durchsetzung verlassen zu müssen.

Integrierte CI/CD und automatisierte Prüfungen

Quellcodeänderungen sollten mit automatisierten Builds, Tests, Sicherheitsscans und Bereitstellungs-Workflows leicht validiert werden können. Ein zusammenhängender Workflow reduziert das Risiko, dass Code Reviews und Bereitstellungen als getrennte Prozesse ablaufen.

Sicherheit und Schutz von Geheimnissen

Sieh dir an, wie die Plattform Quellcode und sensible Daten schützt. Relevante Funktionen können das Berechtigungsmanagement, die Erkennung von Geheimnissen, das Testen von Sicherheitslücken und Steuerungen darüber umfassen, wer Änderungen pushen oder zusammenführen kann.

Entwicklererfahrung und Integrationen

Berücksichtige, wie einfach Entwickler(innen) klonen, bearbeiten, überprüfen und beitragen können. Webbasierte Entwicklungswerkzeuge, Integrationen, die Repository-Spiegelung und die Unterstützung bestehender Workflows können die Akzeptanz verbessern.

Skalierbarkeit und Bereitstellungsflexibilität

Große oder verteilte Organisationen sollten Performance, Verwaltung, Verfügbarkeit, Datenanforderungen und Bereitstellungsoptionen von Repositorys beurteilen. GitLab unterstützt Cloud-gehostete, Self-Managed- und Single-Tenant-Bereitstellungsmodelle für unterschiedliche Bedürfnisse von Unternehmen. Erkunde die GitLab-Plattform.

SCM bietet die Änderungsverlauf- und Kollaborationsebene, auf die die automatisierte Softwarebereitstellung angewiesen ist. Ein Commit oder ein Merge Request können eine Pipeline auslösen, die die Anwendung entwickelt, Tests ausführt, Sicherheitsprüfungen durchführt, Artefakte verpackt und in einer Umgebung bereitstellt. Durch diese Verknüpfung können Teams den Weg von einer Codeänderung bis zu ihrer Validierung und Bereitstellung nachvollziehen. Sie hilft Teams auch zu erkennen, ob eine Änderung die erforderlichen Prüfungen bestanden hat, bevor sie einen geschützten Branch oder die Produktionsumgebung erreicht. GitLab beinhaltet Quellcodeverwaltung und CI/CD in derselben Anwendung. Die öffentlichen Informationen zu CI/CD beschreiben das Repository als den Ort für Quellcode, Konfiguration, Bibliotheken, Tests und Build-Skripte. In den Implementierungsinformationen werden Git-Repositorys, Branching, Merge Approvals, geschützte Branches und integrierte CI/CD miteinander verbunden.

Eine praktische Umsetzung kann klein beginnen und sich im Laufe der Zeit entwickeln.

1. Ein Git-Repository erstellen oder migrieren

Wähle die Projektstruktur, den Standard-Branch, das Eigentumsmodell und die Repository-Einstellungen. Wenn Code im Rahmen einer Umstellung bei einem anderen Git-Anbieter verbleibt, lege fest, wie Repositorys und Bereitstellungs-Workflows synchronisiert bleiben.

2. Branching- und Merge-Strategie wählen

Wähle einen Workflow, der zum Veröffentlichungsrhythmus und zum Risikoprofil des Teams passt. Lege fest, wann Branches erstellt werden, wie lange sie erhalten bleiben sollen und wie Änderungen zum Standard-Branch zurückgeführt werden.

3. Review- und Schutzregeln festlegen

Verwende Merge Requests für kollaborative Änderungen. Lege erforderliche Prüfer(innen), Approvalregeln, geschützte Branches, Eigentumsverantwortlichkeiten und die Bedingungen fest, die erfüllt sein müssen, bevor zusammengeführt wird.

4. Validierung mit CI/CD automatisieren

Füge Pipelines hinzu, die Änderungen einheitlich aufbauen und testen. Erweitere die Pipeline im Laufe der Zeit mit Sicherheitsprüfungen, Verpackungs-, Umgebungvalidierungs- und Bereitstellungsschritten, die den Anforderungen des Projekts entsprechen.

5. Sicherheits- und Compliance-Kontrollen anwenden

Schütze Zugangsdaten und sensible oder vertrauliche Einstellungen, schränke Aktionen mit großen Auswirkungen ein und dokumentiere die Richtlinien, die für Repositorys und Bereitstellungs-Workflows gelten. Die richtigen Kontrollen hängen von der Organisation, dem Projekt und dee regulatorischen Umgebung ab.

6. Workflow messen und verbessern

Prüfe Signale wie Zeit bis zum Review, Zeit vom Approval bis zum Merge, fehlgeschlagene Änderungen, Rollback-Häufigkeit und Bereitstellungsleistung. Nutze diese Maßnahmen für die Suche nach Engpässen und nicht, um Teams für Aktivitätssteigerungen zu belohnen.

• Committe fokussierte, zusammenhängende Änderungen häufig genug, damit du nützliche Prüfpunkte schaffst. * Verfasse Commit-Nachrichten, die die Absicht und den Kontext der Änderung erklären. * Beginne die Arbeit an einer aktuellen Version des Repository. * Nutze Branches, um Änderungen zu isolieren, und Merge Requests, um sie zu überprüfen. * Halte den Standard-Branch stabil und schütze ihn vor ungeprüften Änderungen. * Automatisiere wiederholbare Tests und Prüfungen vor dem Zusammenführen. * Lege Eigentums- und Approvalverantwortlichkeiten für wichtigen Code fest. * Schütze Geheimnisse, Zugangsdaten und sensible oder vertrauliche Projekteinstellungen. * Vereinbare einen Branching- und Merge-Workflow, dem das Team einheitlich folgen kann. * Nutze den Repository-Verlauf, um Regressionen zu untersuchen und zukünftige Änderungen zu verbessern.

GitLab vereint Git-basierte Quellcodeverwaltung, Code Reviews, CI/CD, Sicherheit und Governance in einer Plattform. Teams können bei den notwendigen Kontrollen und Automatisierungen ein gemeinsames Repository und einen Branching-Workflow nutzen, um Software von der Änderung zur Bereitstellung zu überführen.

Erkunde die Quellcodeverwaltung in GitLab