Szenario: Habe eine Verzweigung pro (aktivem) Release in git,
Sequenz ist:
Jane muss R2 von shared holen und die Zusammenführung handhaben, bevor sie pushen kann. Aber sie weiß nicht, was sie mit Bobs Veränderungen machen soll.
Zweige: R1 , R2
%Vor%Bob und Jane nehmen Änderungen an R1
vorJane möchte dann R1 in R2 zusammenführen, um die neueste Version zu aktualisieren. Sie löst die Zusammenführungskonflikte, die durch ihre Änderungen verursacht wurden, jedoch weiß sie nicht, wie sie die durch die von Bob vorgenommenen Änderungen verursachten Konflikte lösen kann.
Gibt es eine Möglichkeit für Jane, Git zu benutzen und Bob die Zusammenführung abzuschließen?
Ich weiß, idealerweise hätte Bob seine Änderungen bereits in R2 zusammengeführt, aber angenommen, das ist nicht der Fall.
Mögliche Problemumgehungen (Suche nach etwas Besserem)
Angenommen, Bob ist blockiert und Jane ist bestrebt, das Problem zu lösen, macht Jane ihren besten Versuch, die Zusammenführung durchzuführen.
%Vor%Wip steht für work in progress und ist eine Konvention, die dem Team signalisiert, dass der Baum und die Geschichte einem radikalen Wandel unterliegen. Vielleicht möchte Jane wirklich, dass Bob ihre Auflösungen, die seinen Code von R1 beeinflussen, vor der Integration in die Baseline betrachtet. (Hinweis: Dies ist ein Anti-Pattern; ein besserer Ansatz wäre es, automatisierte Tests zu haben, die das gewünschte Verhalten für den neuen Code in R1 schützen und anderen Entwicklern als Bob erlauben, selbstbewusst zu verschmelzen.)
Jane macht ihren besten Versuch bei der Zusammenführung.
%Vor%Der Zweig wip / R2-with-R1 kann sogar mehrere Checkpoint-Style-Commits enthalten. Ein weiteres gutes Signal für jeden würde das Team wissen lassen, dass es spekulativ ist.
%Vor%Wenn sie bereit ist, dass Bob sie anschaut, schiebt sie sie zu einem Repository, das beide sehen können
%Vor% Die Option --set-upstream ist für den Fall vorhanden, dass sie gemeinsam an der neuen Verzweigung arbeiten müssen.
Sie startet dann ihren Mail User Agent.
%Vor%Nach Bobs Korrektur und einem Abruf ähnelt der Verlauf
%Vor%An diesem Punkt möchte Jane die Zusammenführung beibehalten, möchte aber die hässlichen Checkpoint-Commits nicht beibehalten. Zurück zu einem Merge-Commit zu komplimentieren erfordert nur ein wenig Sorgfalt.
%Vor%Dies hinterlässt eine Geschichte von
%Vor%und R2 hat jetzt den gleichen Baum wie Bobs letzten Baum.
Anders als Jane Bob zu ihrem Schreibtisch ruft und die Änderungen an ihrem Computer überprüft, glaube ich nicht, dass dies in git gemacht werden kann.
Wenn die Zusammenführung aufgelöst wird, erstellen Sie eine neue Festschreibung, und das geschieht alles lokal. Jane konnte die Zusammenführung vornehmen und sich entschließen, die Änderungen nicht auf die Fernbedienung zu übertragen. Bis der Merge-Commit übertragen wurde, gibt es keine Möglichkeit zu wissen, ob jemand anderes in ihre Kopie der Remote-Datei eingebunden wurde. Jane muss die Commits auflösen, um die Zusammenführung abzuschließen, und das geschieht nur lokal.
Eine unzusammenhängende Änderung in der Fernbedienung scheint sowieso eine schlechte Idee zu sein. Angenommen, ich beginne mit dem Repo zu arbeiten und ziehe Änderungen, bevor Bob die Konflikte gelöst hat. Was dann?
Der andere Weg für Jane zu wissen, ob sie die Commits gelöst hat, wäre, dass sie eine Test-Suite laufen hat. Dann weiß sie, dass sie einen Fehler gemacht hat, als die Tests fehlgeschlagen sind.
Wenn ich die Reihenfolge der Aktionen richtig verstehe, ist das wie folgt:
In dieser Situation könnten Jane und Bob Folgendes tun:
Jane kann eine Verzweigung erstellen, die ihre Änderungen in R2 enthält:
%Vor%Bob seufzt unzufrieden darüber, dass er es wieder tun muss , warum ist Jane immer so nervös, ihre Veränderungen mit seinen zu verschmelzen? Es ist dumm ... löst dann die Zusammenführung mit Janes Zweig vom Server auf:
%Vor%Jane entfernt ihren temporären Zweig vom Server:
%Vor%und antwortet dann zurück, um Bob zu danken. Und bitten Sie ihn, vielleicht irgendwann mal Kaffee zu trinken ...
(Natürlich könnte Bob auch Janes temporären Zweig auf dem Server löschen, aber das passte auch nicht zur Erzählung.)
Wir befinden uns in einer ähnlichen Situation.
Hier ist der Weg, den wir gefunden haben, funktioniert nach ein paar verschiedenen fehlgeschlagenen Vorgehensweisen. Der Punkt war, wie man die widersprüchlichen Hunks über das Remote-Repository verteilt.
Jane erstellt zwei Zweige von der Spitze von R2 und verbindet R1 mit ihnen mit einer Reihe von "komplementären" Merge-Strategien;
%Vor%Jetzt
%Vor%zeigt, dass R1 mit R2 in Konflikt gestanden hätte, weil '-s rekursiv -X unsere / ihre Merge-Strategie "zwingt, Konfliktstellen durch die Bevorzugung unserer Version automatisch sauber aufzulösen."
Jane nimmt notwendige Änderungen an wip / merging vor, um die "virtuellen" Konflikte zu lösen, die durch ihre vorherigen Änderungen verursacht wurden und lässt Bob unberührt.
Dann drückt Jane wip / referenz und wip / merging und ruft / IM / email / owlpost Bob um sie zu holen.
Bob prüft die virtuellen Konflikte und die halbwegs aufgelöste Jane gemacht und macht weitere Veränderungen gegen die Konflikte seiner Vergangenheit zu ändern verursacht.
Dann führt er wip / merging zurück zu R2, wenn er das Gefühl hat, alles sieht gut aus oder fragt George / Alice, weitere Resolutionen zu machen.
Wir untersuchen noch, wie sich das auf spätere Zusammenführungen auswirkt (d. h. wenn git rerere richtig funktioniert).
Tags und Links git