Ist die "Goldene Regel des Wiederaufbaus" so wichtig?

Ich hatte kürzlich eine Diskussion mit Leuten, die absolut gegen eine Rebase-Strategie von Feature-Branches auf GIT waren. Es scheint ein akzeptiertes Muster zu sein, Rebase nur für lokale, private Zweige zu verwenden, aber verwenden Sie es niemals, wenn mehrere Personen an derselben Funktion und demselben Zweig arbeiten, wie in dieser so genannten "Goldenen Regel des Rebasings" (wie hier erklärt: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

Ich bin nur überrascht, dass diesbezüglich ein Konsens besteht. Ich habe 3 Jahre mit einer vollständigen Umbasierungsstrategie gearbeitet, wobei ungefähr 20 Entwickler zusammengearbeitet haben und raten Sie mal, was funktioniert hat.

Der Prozess ist im Grunde:

• Sie erstellen Ihren Feature-Zweig, nennen ihn "myfeature" und verschieben ihn auf origin / myfeature
• Andere Leute können es ausprobieren und daran arbeiten
• Manchmal kann es vorkommen, dass Sie es vom Master zurücksetzen: von "myfeature", git rebase origin / master ; und dann, ja, müssen Sie es drücken.
• Was passiert, wenn andere Leute ihr Commit forcieren wollen? Sie lehnen es einfach ab: git rebase origin / myfeature . So sind sie jetzt im Schnellvorlauf und können ihn ohne Kraftaufwand schieben.

Das einzige Prinzip, das beachtet werden muss, ist, dass der Feature-Zweig jemandem gehört . Der Eigentümer ist der einzige, der Push-Force kann.

Also, ich gebe zu: Sobald Druck ausgeübt wird, besteht die Gefahr, dass Fehler gemacht werden. Das ist richtig. Aber es gibt auch viele Möglichkeiten, Fehler zu beheben, und in den letzten drei Jahren meiner Entwicklung habe ich nicht viele Fehler gesehen, die mich dazu veranlasst haben, und als es dazu kam, haben wir immer einen Weg gefunden, wie wir uns richtig erholen können.

Warum wird diese "Goldene Regel der Wiedergutmachung" so allgemein akzeptiert? Gibt es noch etwas, das ich vermisst habe? Ich verstehe, es erfordert ein Minimum an Organisation (jede Strategie erfordert eine Organisation), aber es funktioniert.

Das Problem beim erzwungenen Pushen betrifft nicht Ihren Feature-Zweig und den Master, sondern das Pushen Ihres Masters an den Master eines anderen Benutzers. Bei dieser Synchronisierung wird der Master mit Ihren Änderungen überschrieben, und es wird ignoriert, was auf dem Tipp steht.

In Anbetracht dieser Gefahr gibt es einen Grund, warum Sie es nicht verwenden sollten, es sei denn, die Dinge haben versagt und Sie müssen es unbedingt verwenden, um Reparaturen durchzuführen. Ein SCM-System sollte niemals so gezwungen werden müssen, wenn dies der Fall ist, weil etwas schrecklich schief gelaufen ist (und mein erster Ansatz in solchen Fällen wäre, Sicherungen wiederherzustellen und die Vorgänge zu wiederholen, um den Verlauf intakt zu halten).

Vielleicht ist die Frage, warum Sie überhaupt neu basieren? Für eine "saubere" Geschichte, wenn Features wieder zum Master zurückgebracht werden? Wenn ja, werfen Sie die ganze gute Geschichte der Verzweigung aus rein stilistischen Gründen raus. IMHO Fast-Forward-Zusammenführung ist auch keine bewährte Methode. Sie sollten den gesamten Verlauf beibehalten, damit Sie sehen können, was Sie wirklich getan haben, und anschließend keine bereinigte Version.

Rebase ist nicht wesentlich, wie Sie sagen, es ist meistens kosmetisch. Manchmal ist es viel einfacher als ein Zusammenführen. Es kann also einen "tatsächlichen" Wert haben, aber nur "manchmal".

Die unsachgemäße Verwendung von Rebase kann kostspielig sein. Es ist unwahrscheinlich, dass Sie Daten verlieren, wenn Sie genug wissen, um nicht in Panik zu geraten und nach Wiederherstellungsverfahren zu suchen, aber "Hey, ich muss eine Weile warten ..." ist nicht großartig. Es ist auch nicht unumgänglich, jemanden Zeit für die Wiederherstellung und das Testen von Forschungsergebnissen zu lassen, wenn er Funktionen hätte hinzufügen oder Fehler beseitigen können (oder mit der Familie zusammenleben).

Mit diesem Kompromiss ist es nicht sehr überraschend, dass "nur sehr wenige Menschen einen Rebase und Forced Push durchführen".

Einige Workflows können das Risiko verringern, z. B. auf "Null, solange Sie sich erinnern, welche Zweige Sie erzwingen dürfen und welche nicht". In Wirklichkeit mögen sie sicher genug sein, um das Risiko zu rechtfertigen, aber die Leute treffen häufig Entscheidungen auf der Grundlage größerer Folklore. Andererseits sind die Vorteile in der Realität ziemlich gering. Wie gering muss das Risiko wirklich sein?

So fügen Sie eine andere Stimme hinzu:

Ja, wenn Sie so arbeiten, wie Sie es beschreiben, gibt es keine Probleme bei der Verwendung rebaseund beim Drücken mit Gewalt. Der kritische Punkt ist: Sie haben eine Vereinbarung in Ihrem Team.

Die Warnungen über rebaseund Freunde gelten für den Fall, dass keine besondere Vereinbarung getroffen wurde. Normalerweise schützt git Sie automatisch, indem es zum Beispiel einen nicht schnellen Vorlauf nicht zulässt. Das Verwenden rebaseund Drücken von Gewalt übersteuert diese Sicherheit. Das ist in Ordnung, wenn Sie noch etwas an Ort und Stelle haben.

In meinem Team werden manchmal auch Feature-Zweige neu sortiert, wenn die Geschichte unübersichtlich geworden ist. Entweder löschen wir den alten Zweig und erstellen einen neuen Zweig mit einem neuen Namen oder wir koordinieren ihn nur informell (was möglich ist, weil wir ein kleines Team sind und sonst niemand in unserem Repository arbeitet).

Beachten Sie, dass das Git-Projekt selbst auch etwas Ähnliches tut: Sie haben einen Integrationszweig, der regelmäßig neu erstellt wird, "pu" ("vorgeschlagene Updates"). Es ist dokumentiert, dass dieser Zweig regelmäßig neu erstellt wird und dass Sie keine neuen Arbeiten darauf aufbauen sollten.

Also, ich gebe zu: Sobald Druck ausgeübt wird, besteht die Gefahr, dass Fehler gemacht werden. Das ist richtig. Aber es gibt auch viele Möglichkeiten, Fehler zu beheben, und in den letzten drei Jahren meiner Entwicklung habe ich nicht viele Fehler gesehen, die mich dazu veranlasst haben, und als es dazu kam, haben wir immer einen Weg gefunden, wie wir uns richtig erholen können.

Der Grund, warum Git-Benutzer dazu neigen, geteilte veränderbare Historien zu vermeiden, ist, dass es keine automatische Vermeidung oder Reparatur dieser Probleme gibt. Sie müssen wissen, was Sie tun, und Sie müssen alles manuell reparieren, wenn Sie es vermasseln. Es ist nicht intuitiv und widerspricht dem verteilten Design von Git, genau einer Person Force-Push zu erlauben. Was passiert, wenn diese Person in den Urlaub fährt? Besitzt vorübergehend jemand anderes die Niederlassung? Woher weißt du, dass sie nicht überall herumlaufen, was auch immer der ursprüngliche Besitzer tat? Und was passiert in der Open Source-Welt, wenn sich der Filialinhaber allmählich von der Community entfernt, ohne offiziell abzureisen? Sie könnten viel Zeit verlieren, wenn Sie darauf warten, das Eigentum an einer Zweigstelle an eine andere Person abzugeben.

Das eigentliche Problem ist jedoch Folgendes: Wenn Sie es vermasseln und es nicht sofort bemerken, verschwinden die alten Commits schließlich , wenn genügend Zeit verstrichen ist. An diesem Punkt kann das Problem möglicherweise nicht behoben werden (oder zumindest möglicherweise sehr schwer zu beheben, je nachdem, wie Ihre Backup-Story aussieht - sichern Sie alte Kopien Ihres Git-Repositorys, dh nicht nur Klone?).

Vergleichen Sie dies mit Mercurials Changeset-Entwicklungsarbeit (die, wie ich beachten sollte, noch nicht fertig oder stabil ist). Jeder kann beliebige Änderungen am Verlauf vornehmen, sofern die Änderungssätze nicht als öffentlich markiert sind. Diese Änderungen und Neuerungen können ungestraft durchgeführt werden, ohne dass ein Zweigstellenbesitzer erforderlich ist. Es werden niemals Daten gelöscht. Das gesamte lokale Repository kann nur angehängt werden. Nicht mehr benötigte Änderungssätze werden als veraltet markiert, aber auf unbestimmte Zeit aufbewahrt. Wenn Sie Ihren Verlauf durcheinander bringen (was als normaler Teil Ihres täglichen Workflows behandelt wird), gibt es schließlich einen raffinierten Befehl, um ihn automatisch für Sie zu bereinigen. Dies ist die Art von UX, die die Benutzer erwarten, bevor sie den gemeinsamen Verlauf ändern.