Sollte jede GIT-Verpflichtung das Projekt in einem funktionierenden Zustand belassen?

Ich bin neugierig, was die vorherrschenden Best Practices sind. Sollten Git-Commits so erzwungen werden, dass sich das Projekt in einem funktionierenden Zustand befindet (ordnungsgemäß erstellt, alle Tests bestanden usw.), oder ist das Festschreiben von fehlerhaftem Code in Ordnung?

Wenn Sie beispielsweise auf diese Anforderung verzichten, können Sie bei Commits flexibler sein (verwenden Sie sie als logische Chunks, auch wenn die App nicht in einem funktionsfähigen Zustand ist usw.). Wenn Sie es jedoch durchsetzen, erhalten Sie die Flexibilität, später ein bestimmtes Commit auswählen zu können ...

Ich folge normalerweise dieser Regel:

• Bei jedem Zusammenführen in einen masterZweig muss das Projekt in einem funktionsfähigen Zustand bleiben.
• Jeder Zusammenschluss mit einem developHauptzweig sollte das Projekt in einem funktionierenden Zustand belassen (und es muss mindestens erstellt werden).
• Jeder einzelne Commit hat das primäre Ziel, zu erklären, warum die Änderung vorgenommen wird, wozu sie dient und welche Teile des Projekts davon betroffen sind. Alle anderen Ziele, wie das Verlassen des Projekts in einem Arbeitszustand, sind optional.

Verwenden Sie Ihren lokalen Klon des Repositorys, um sich während der Entwicklung wohl zu fühlen.

Ich gebe regelmäßig fehlerhaften Code ein, und wenn ich bereit bin, den Code anderen Entwicklern zur Verfügung zu stellen, verwende ich eine großartige Funktion:

git rebase -i HEAD~4

Dadurch kann ich mein Intermediate-Commit (in diesem Fall 4 von ihnen), das möglicherweise fehlerhaft ist, zu einem guten Commit komprimieren. Sie erhalten einen Editor, in dem Sie auswählen können, wie diese Commits komprimiert werden sollen. Normalerweise habe ich das erste Festschreiben als "Auswählen" und das andere als "Kürbis" markiert.

Dann kann ich dieses eine atomare Commit pushen, oder tatsächlich, was ich tue, wenn meine neue Funktion wirklich fertig ist, ist 'git cvsexportcommit', um meine Arbeit in das bestehende CVS-Repo zu übernehmen.

Zwei der großen Vorteile der Versionskontrolle sind, dass Entwickler frühere Versionen ihrer Arbeit wiederherstellen und gleichzeitig verschiedene, möglicherweise widersprüchliche Änderungen ausprobieren können. Die Versionskontrolle gibt Entwicklern die Freiheit, Ideen auszuprobieren, die fehlschlagen könnten.

Entwickler sollten ermutigt werden, ihre Arbeit regelmäßig zu verzweigen und zu verrichten, unabhängig davon, ob sie erstellt wird oder nicht. Wenn Sie es ablehnen, Verzweigungen oder unterbrochene Commits zuzulassen, belasten Sie Ihre Entwickler und setzen Ihre Tools nur unzureichend ein.

Das heißt, es ist eine hervorragende Praxis zu verlangen, dass Commits zu bestimmten Zweigen immer aufgebaut werden. Viele Organisationen gehen noch weiter und verbieten Entwicklern, sich überhaupt auf bestimmte Branchen festzulegen. Beispielsweise müssen Entwickler ihre Arbeit möglicherweise wieder in den Hauptentwicklungszweig einbinden, aber nur der leitende Entwickler darf diese Änderungen von der Entwicklung in den Produktionszweig einbinden.

Wir verfolgen grundsätzlich beide Ansätze. Im lokalen Repository auf meiner Box gebe ich alles ein, was ich will. Wenn es Zeit ist, auf das zentrale Repo meines Teams zuzugreifen, führe ich zuerst eine interaktive Rebase durch und forme meine Commits zu logischen Paketen. In der Regel ein Commit pro Story, wobei die Story- (oder Fehler-) ID im Kommentar enthalten ist (wir sind ein auf Kanban basierender Shop).

Dann haben wir auf unserem zentralen Repro Jenkins zugehört und es startet den Build und alle Tests. Wenn irgendetwas fehlschlägt, können die Leute im Allgemeinen versuchen, den Build mit einem anderen Commit zu reparieren. Wenn es nicht gut aussieht, ist es einfach, das fehlerhafte Commit zurückzusetzen.

Schon seit git commit nur Ihre eigene Kopie des Repository betroffen ist, muss sich das Projekt nicht nach jedem Commit in einem funktionsfähigen Zustand befinden. Machen Sie weiter und verpflichten Sie sich, wann immer Sie Ihre geleistete Arbeit speichern möchten. Eine gute Faustregel ist wahrscheinlich, dass ein Commit angemessen ist, wenn Sie die Änderungen beschreiben können, die Sie in der Commit-Nachricht vorgenommen haben.

Dies git pushbetrifft andere Benutzer. Die Richtlinien für das, was weiterentwickelt werden soll, müssen von Ihrem Entwicklungsteam festgelegt werden. Das Pushen von nicht funktionierendem Code in den Hauptzweig ist vermutlich ein Nein-Nein, aber es ist wahrscheinlich in Ordnung, nicht funktionierenden Code in einen separaten Zweig zu pushen (solange niemand anderes versucht, einen Build aus diesem Zweig zu erstellen).

Wir verwenden bei der Arbeit Git Flow , und wir schreiben auch unvollendeten oder fehlerhaften Code ein, da dieser nur in lokalen oder entfernten Zweigen landet, die für dieses spezielle Problem entwickelt wurden. Erst wenn die Aufgabe abgeschlossen ist, wird sie in den Entwicklungszweig (der die aktuelle Arbeitskopie im Ablaufmodell darstellt) eingebunden. Auf diese Weise können wir auch am Code mitarbeiten (einige Mitarbeiter befinden sich in einer anderen Stadt, einschließlich des Projektleiters) und uns gegenseitig helfen.

Es kommt jedoch darauf an, wie Sie und Ihre Mitarbeiter denken. Persönlich denke ich, dass Branch Commits in Ordnung sind, da Sie möglicherweise eine Änderungshistorie mit einem größeren Refactor oder ähnlichem benötigen.

Letztendlich liegt es an dir und den Leuten, mit denen du arbeitest oder für die du arbeitest, da git keine Regeln auferlegt.

Meine Praxis ist es, Commits zu vermeiden, die das System absichtlich erheblich verschlechtern. Bei jedem Commit sollte es sich entweder um ein Refactoring handeln oder um die Implementierung einer bestimmten Anforderung. Wenn ich ein schlechtes Commit mache und es entdecke, bevor ich es weitergebe, werde ich es ändern oder neu definieren, um es aus dem Verlauf zu entfernen.

Ich denke, dies erleichtert das Lesen des Git-Protokolls in einer Pull-Anforderung, da jedes Commit für sich entweder als Refactoring oder als Implementierung einer bestimmten Anforderung stehen sollte. Das Hinzufügen von totem Code, der in naher Zukunft zum Leben erweckt wird, gilt als Umgestaltung. Das sind meine "logischen Brocken".

Sie können weiterhin flexibel sein, wie Sie Ihre Commits strukturieren. Beispielsweise können Sie Tests im Voraus schreiben, sie jedoch beim ersten Festschreiben als übersprungen markieren, damit Ihre Testsuite keinen Fehler meldet, und sie nach Abschluss der Implementierung wieder entfernen.

Angenommen, Sie verwenden Verzweigungen und gute Festschreibungsnachrichten. Das Festschreiben von "defektem" Code in einer Verzweigung mit einer Festschreibungsnachricht, die dies deutlich macht, ist in Ordnung, sofern Ihr Team zustimmt, dass dies eine gute Arbeitspraxis ist.

Sie klonen das Git-Repository auch lokal, sodass Sie möglicherweise nur eine lokale Verzweigung mit lokalen Commits haben, die nicht an den Ursprung übertragen werden, an dem Sie im Laufe der Zeit "defekten" Code festschreiben. Wenn alles funktioniert, können Sie es in einem Master oder einem anderen Zweig zusammenführen und Ihren Arbeitszweig mit den verschiedenen "defekten" Commits löschen.

Für mich geht es darum, mit Ihrem Team abzustimmen, was akzeptabel ist. Einige Teams akzeptieren selbst in einem Zweig keinen fehlerhaften Code, andere nicht.