Ich benutze git, um Änderungen zu verfolgen, die von unserem Entwicklungsteam vorgenommen und in unser zentrales cvs-style-Repository übernommen wurden. Seit seiner cvs, verfolgt es Dateien und nicht commits, was es manchmal schwierig macht genau zu sagen, welche Dateien den vollständigen Patch für einen Bugfix darstellen. Ich bin gerade auf eines gestoßen und habe folgendes gemacht:
1) Trolling entlang, CVS-Logs prüfen und sie als vollständige Patches gittieren
%Vor%2) Eine andere Dateiänderung gefunden, die eigentlich für Ticket (B) war, also habe ich den aktuellen Zweig mit
auf B zurückgesetzt %Vor%3) Ich kopiere die Änderung und füge sie an commit (B) mit
an %Vor%4) zu meiner Überraschung liest der Baum jetzt
%Vor%mit commits (C) und (D) nur im Arbeitsbaum. Ihre Details sind aus den Logbüchern verschwunden und ich glaube nicht, dass ich sie zurückbekommen kann. Was habe ich falsch gemacht? Ist meine einzige Option, ein zusätzliches Commit auf (D) zu machen, und weiß nur, dass es wirklich Teil von (B) ist?
Sie meinen, ändern, nicht anhängen, oder? Ich werde so tun, als wäre dies in einem Zweig namens Master, aus Bequemlichkeit. So sieht Ihr Repository jetzt aus:
%Vor%Git-Commits hängen explizit von ihren Eltern ab - derselbe Patch über einem anderen Elternteil ist ein anderes Commit.
Sie können die vorherige Position auf verschiedene Arten wiederherstellen. Es gibt eine nette Abkürzung für vorherige Positionen, die Sie verwenden können, um es direkt auszuprobieren oder eine Verzweigung zu erstellen:
%Vor% Dies setzt voraus, dass es die erste vorherige Position ist. Es könnte die zweite sein ( master@{2} ) ... oder wenn Sie wissen, wann es war, können Sie master@{7:35} oder master@{23.hours.ago} verwenden. Eine Zusammenfassung dieser Formulare finden Sie im Abschnitt "Revisionen festlegen" von man git-rev-parse ( hier online ).
Wenn Sie nicht genau wissen, wie Sie es erreichen sollen, versuchen Sie
%Vor% Dies wird Ihnen eine Liste der vorherigen Positionen von master geben, und Sie sollten in der Lage sein, aus den Beschreibungen zu ersehen, welche Sie wollen (oder vielleicht ein paar ausprobieren). Sie können Hashes einfach aus der Liste kopieren und git checkout oder git branch wie oben verwenden.
Warnung: Die Bearbeitung des Verlaufs ist eine schlechte Idee, wenn sie bereits veröffentlicht wurde - in diesem Fall sollten Sie den Fehler einfach festschreiben. Ja, es ist ein bisschen hässlich, wenn es im Repository in zwei Commits aufgeteilt wird, aber andere Benutzer müssen in der Lage sein, dem zu vertrauen, was sie im öffentlichen Repo gesehen haben, um sich nicht zu ändern!
Das heißt, um diese besondere Art von History-Bearbeitung zu machen, wollen Sie interaktive Rebase:
%Vor% master~4 steht für das Commit von vier Commits vor der Spitze des Masters. Sie können hier jedes beliebige Formular verwenden - vielleicht ist es ein anderer Zweig, vielleicht ein Commit-Hash - was auch immer funktioniert.
Dies wird in einem Editor eine Liste der Commits öffnen, mit denen Sie spielen:
%Vor% Der auskommentierte Hilfetext ist ziemlich selbsterklärend. In diesem Fall möchten Sie die Auswahl in der Zeile von Commit B ändern, speichern und beenden. Die Rebase wird gestartet und nach dem Anwenden von B angehalten, damit Sie Änderungen vornehmen können. Sie tun, was Sie brauchen, fügen hinzu, verwenden git commit --amend und dann git rebase --continue . Es wird C und D anwenden, und Sie werden fertig sein. Wenn in der Mitte etwas schief geht, benutze git rebase --abort , um dorthin zurückzukehren, wo du angefangen hast.
Rebasing kann etwas beängstigend sein - zum Beispiel, nicht versehentlich Zeilen in dieser Liste entfernen! Wenn Sie sich noch nicht damit auskennen, ist es eine gute Idee, gitk und Backup-Zweignamen zu verwenden.
4) zu meiner Überraschung liest der Baum jetzt
A - B
Tatsächlich sieht das Protokoll (die Geschichte) so aus
A - B
als Commit ist anders als zuvor. Die Situation sieht folgendermaßen aus:
%Vor%Die Kette der Commits "B --- C --- D" (mit Original B) sieht verloren aus, weil es keinen Hinweis auf D gibt. Ihr Zweig zeigt jetzt auf Commit B '(modifiziertes Commit B). Sie können weiterhin über Reflog auf D zugreifen. es wäre HEAD @ {2} Ich denke ...
Wo bin ich falsch gelaufen?
Sie hätten " git rebase --interactive " verwenden sollen, indem Sie "pick" neben "commit B" auf "edit" setzen und dort einen Patch quetschen.
Das oder eine der Patch-Management-Schnittstellen oben auf Git wie StGIT oder Guilt .
Ihre Details sind aus den Logs verschwunden und ich glaube nicht, dass ich sie zurückbekommen kann.
Sehen Sie sich reflog an, d. h. " git reflog " oder " git log -g ". Dort sollten Sie Ihre "verlorenen" Commits sehen.
HTH
Tags und Links git version-control dvcs