Der letzte Tag der Arbeitswoche ging zu Ende ...

Der letzte Tag der Arbeitswoche endete. Ich machte mir Kaffee in der Büroküche und fragte mich, wie wir die Warteschlange des Anforderungspools reduzieren könnten, der nach der Einführung des Überprüfungsleitfadens expansiv gewachsen ist . Es scheint, dass einfache Regeln eine lange Korrespondenz in den Kommentaren zum Pool der Anfragen zwischen Mitgliedern des Überprüfungsteams und den Entwicklern des Frameworks verursacht haben.

Nichts ahnte. Es wurde dunkel.

Plötzlich raschelte ein funktionierender Chat mit Nachrichten:
- Warum wurde meine Pull-Anfrage entfernt?
- Und meine Pull-Anfragen knallten!
- Und meins!

Nach nur wenigen Minuten Investition stellten wir fest, dass dies geschah, weil jemand den Bootstrap-Arbeitszweig gelöscht hatte, in den mehr als 40 Personen mehr als drei Monate lang eingeschmuggelt hatten. Noch einmal, um das volle Ausmaß des Problems erkennen zu können, haben vierzig Leute mehr als drei Monate lang Code dort eingegossen.



Die Kollegen schwärmten sofort von der Idee, dass wir alle lokale Kopien dieses Zweigs haben, und lassen Sie uns diesen Zweig von Grund auf neu erstellen.

Aus eigener Erfahrung weiß ich, dass hastige Entscheidungen und Improvisationen zu nichts Gutem führen. Deshalb habe ich alle gebeten, keine Maßnahmen zu ergreifen und buchstäblich "die Hände von der Tastatur zu nehmen".



Die Disposition ist also Freitag, Abend, ein fast leeres Büro, eine verlorene Filiale mit einer riesigen Codebasis. Wenn Sie dieses Problem hier und jetzt nicht lösen, besteht die Möglichkeit, dass sich die Situation verschlechtert, wenn andere Entwickler, die die aktuelle Situation nicht kennen, am Wochenende mit der Arbeit verbunden werden (wir alle lesen den Arbeitschat sorgfältig durch, oder? ).

Ich habe im Chat höflich gefragt, wer den Bootstrap-Zweig gelöscht hat, und ein junger Entwickler, der kürzlich in die Arbeit aufgenommen wurde, gab zu, dass er es versehentlich getan hat. "Es tut uns leid".



Ich schnappe mir einen Spezialisten, der erfolgreich am Arm aufgetaucht ist, und wir eilen zu einem jungen Entwickler, der sich gerade in einer existenziellen Krise befindet und dessen Arbeitsplatz sich glücklicherweise im selben Büro wie wir befindet.

Natürlich haben wir den Zweig restauriert - ein bisschen Git-Magie, und alles hat geklappt. Sie können nicht über mehr als 20 Pull-Anfragen sagen, die im Darm von GitHub verschwunden sind. Unangenehm, aber nicht tödlich.
Zeit, Luft zu holen, herauszufinden, was passiert ist, und einige Schlussfolgerungen zu ziehen.



Die Hauptfrage ist warum? Die Antwort ist im Allgemeinen trivial - aus Versehen. Mit dem Code, der für seinen eigenen Arbeitszweig festgeschrieben wurde, stimmte etwas nicht - nichts Kriminelles, es war nur hässlicher Code, und selbst wenn Sie das Festschreiben umkehren, bleibt er in der Geschichte. Aus diesem Grund hat der Entwickler beschlossen, seinen gesamten Arbeitszweig abzureißen und neu zu erstellen. Von Grund auf neu. Und der Bootstrap-Zweig geriet unter eine heiße Hand. Freitag. Abend. Misklik, ja.



Mit GitHub können Sie den Löschvorgang abbrechen, jedoch nur, bis die Seite aktualisiert wurde und diese Chance nicht genutzt wurde.

Könnte diese Situation vermieden worden sein? Ja, du kannst. Standardmäßig kann jeder mit Schreibzugriff auf Ihr Repository jeden Zweig löschen. Mit GitHub können Sie jedoch eine Zweigschutzregel für einen oder mehrere Zweige erstellen.



Wo es wichtig ist sicherzustellen, dass das entsprechende Kontrollkästchen nicht aktiviert ist.



Dies wurde nicht für den Bootstrap-Zweig durchgeführt und hat uns eingeholt.

Im trockenen Rückstand:

1. Sie haben den Zweig gerettet.
2. Jetzt installieren wir in jedem Zweig, in dem mehr als eine Person Beiträge leistet, die Schutzregel. Was ich empfehle, nicht zu vergessen, alles zu tun.
3. Die Unterstützung für das BootStrap- Paket in JDI Light wurde schließlich implementiert und eingeführt. Aber was es ist und warum - das ist eine andere Geschichte ...