Also habe ich eine Datei geändert, sie in unser Hauptrepo verschoben, dort gesehen. David zog aus diesem Repo und tat - nun, etwas - und konnte meine Veränderung nicht sehen. Da David ein typisches Microsoft-Opfer ist, bat ich ihn, das, was er hatte, ins Repo zu schieben, und ich würde es mir dort ansehen.
git log --name-only erzeugt
aber git log backend/theimportantfile.js erzeugt
Also wurde git backend/theimportantfile.js seit Wochen nicht mehr geändert, aber es wurde vor zwei Stunden auch mit dem afc2dec-Commit geändert. Wie kann ich herausfinden, was passiert ist?
Es scheint, dass Davids Verschmelzung das ist, was du getan hast. Ich sage das, weil die Verschmelzung deine Änderungen scheinbar zurückgenommen hat.
%Vor%Wenn dieser Befehl keine interessante Ausgabe liefert, dann fusionierte David vielleicht mit einer 'unserer' Strategie oder machte die clevere 'cp meine Dateien an einen temporären Ort; Git fusionieren; überschreiben widersprüchliche Dateien; git commit 'Workflow.
Unabhängig davon, wie dieser Zustand bei der Zusammenführung angekommen ist, muss er verworfen und neu erstellt werden, da er offensichtlich fehlerhaft ist. Sie können auch erwägen, Ihren Arbeitsablauf so zu ändern, dass David nicht mehr zusammenführen muss, sondern informelle (oder formale) "Pull Requests" einreicht und Sie sich um das Zusammenführen kümmern.
Ich bin mir nicht sicher, ob dies die Art Ihres Problems ist, aber git log filtert standardmäßig Commits heraus, von denen es denkt, dass sie nicht "nützlich" oder "interessant" sind, um den Endzustand zu verstehen ein Commit-Baum. Von die git log docs :
Manchmal sind Sie nur an Teilen der Geschichte interessiert, zum Beispiel an den Commits, die einen bestimmten & lt; Pfad & gt; ändern. Aber es gibt zwei Teile von History Simplification , ein Teil ist die Auswahl der Commits und der andere ist, wie es zu tun ist, da es verschiedene Strategien gibt, um die Geschichte zu vereinfachen.
Die folgenden Optionen beeinflussen die Art der Durchführung der Vereinfachung:
Default mode
Vereinfacht die Geschichte bis zur einfachsten Geschichte, die den Endzustand des Baumes erklärt. Am einfachsten, weil es einige Seitenzweige beschneidet, wenn das Endergebnis gleich ist (d. H. Zweige mit demselben Inhalt zusammenführen).
Anstatt den Standardmodus zu verwenden, können Sie das Flag --full-history in Ihrer Datei übergeben und sehen, ob das "fehlende" Commit so aussieht:
Von git log docs:
--full-history
Genau wie der Standardmodus, aber einige Geschichte nicht beschneidet.
Ich weiß, dass das manchmal funktioniert, weil ich eine Situation hatte, in der ich eine commit X in master hatte, die eine Änderung in einer Datei theFile enthielt. Commit X wurde dann von einem Mitarbeiter in anotherBranch übernommen, also nennen wir das neue Commit Y . Dann wurde anotherBranch in master zusammengeführt.
Als wir es taten
%Vor% wir würden Y nicht in der Liste der Commits sehen, nur X , aber wenn wir
nur dann würden sowohl X als auch Y angezeigt. Ich nehme an, dass Git% code_% standardmäßig nicht angezeigt hat, weil es eine identische Änderung in den Endzustand des Commit-Baums eingeführt hat, da es von Y ausgewählt wurde.
Es sieht so aus, als ob er einen Zusammenführungskonflikt hatte und es gelöst hat, indem er seine Version akzeptiert hat (die wahrscheinlich eine nicht existierende Datei war) statt Ihrer. Sie können die Datei zurückbringen. Siehe zum Wiederherstellen einer Datei oder eines Ordners
Tags und Links git