Git fehlt Code nach dem Zusammenführen

Wir haben ein Problem mit unserem GitHub-Repository. Ich werde unseren Workflow erklären:Git fehlt Code nach dem Zusammenführen

Entwickler erstellen Feature/Bug-Fix-Filialen aus der Haupt-Zweigstelle. Sie ziehen ihre Änderungen an, um sie wieder zusammenzuführen. Sie können von der Hauptniederlassung rebasen, um die neuesten Aktualisierungen von ihnen zu erhalten, wenn sie funktionieren. Nach einer Rebase drücken sie --force auf ihren Feature-Zweig.

Zwei Pull-Requests wurden kürzlich über die GitHub-Webschnittstelle automatisch zusammengeführt. Anschließend - etwa zwei Tage nach dem Zusammenführen der Anfrage - wurde festgestellt, dass die Änderungen in diesen Commits nicht im Code waren. Nichts in der Geschichte deutet darauf hin, dass diese Änderungen rückgängig gemacht oder überschrieben wurden. Die Zusammenführungen selbst erscheinen nicht in der Commit-Historie und die einzelnen Commits selbst erscheinen auch nicht. Aber die Pull-Anforderung wurde erfolgreich zusammengeführt. Einer der fehlenden Commits steht nicht mehr zur Verfügung. Wenn wir es versuchen, erhalten wir eine fatal - bad object Meldung.

Wir vermuten, dass etwas Neuschreiben der Geschichte passiert ist. Wie können wir herausfinden und wie können wir dies verhindern? Gibt es etwas grundsätzlich falsch mit unserem Workflow?

Quelle

2012-11-17 Daniel Jones

Haben Sie den Reflog um die Zeit inspiziert, dass dies passiert ist? Es könnte einige Hinweise darauf geben, was vor sich geht. Im Allgemeinen gilt Force Push jedoch als eine schlechte Idee. Wenn sie nach der Zusammenführung zum Feature-Zweig gedrängt werden, bin ich mir nicht sicher, was passieren würde, obwohl ich denken würde, dass sie das Commit auf dem Master-Zweig nicht verlieren sollte. Erinnert sich jemand daran, dass er versehentlich zur Hauptlinie gedrängt wurde - kann er keine andere offensichtliche Möglichkeit sehen, die passieren könnte. – MattJenko

Ich habe kürzlich Github gemailt wegen eines ähnlichen Problems (einer der anderen Entwickler hat gedrängt, ohne jemanden zu fragen), ob es möglich ist, Force Push in Github Repo zu verbieten, sie sagten, dass es jetzt nicht konfigurierbar ist, aber wenn wir verloren haben Einige Commits, wir können GH kontaktieren, um Hilfe zu holen, um sie wiederherzustellen. Normalerweise sollten alle verwaisten Commits im Reflog in GH sowie im lokalen Repo des Entwicklers sein, der die Pull-Anfrage initiiert hat - bis der Müll automatisch oder manuell gesammelt wird. –

Siehe hier für ähnliche Sache: http://StackOverflow.com/Questions/5094524/Github-prevent-colaborator-from-Push-F Scheint GitHub ist nicht sehr daran interessiert, es zu implementieren. Für die Zukunft können Sie entweder 1) Zwischen Repo, Empfangen von Dingen, mit verschiedenen Haken eingerichtet, die nach Github drücken, wenn alles in Ordnung ist, 2) Beschränke die Anzahl der Personen erlaubt zu zentralen Repo (vielleicht nur 1 Person, rotieren jeweils Woche usw.). Ich bin mir bewusst, dass diese Antwort möglicherweise nicht zufriedenstellend ist. –

Das Problem, mit dem Sie konfrontiert sind, hat damit zu tun, dass Ihre Entwickler von der Hauptniederlassung wechseln und dann gezwungen sind, ihre Filialen zu pushen. Was git rebase tatsächlich tut, ist es uncommits alle Änderungen, die Sie vorgenommen haben, führen Sie die Hauptzweig, dann gilt wieder Ihre Commits (als ob sie Patch-Dateien sind). Dies würde einen komplett neuen Git Commit mit einem komplett neuen Hash erzeugen.

Kurz gesagt, das alte Commit wurde verloren und ein neues identisches Commit wurde erstellt.

Deshalb ist es extrem entmutigt, jede Arbeit, die öffentlich ist, neu zu erstellen, weil Sie Geschichte effektiv ändern. Alle Menschen, die von Ihrer Arbeit abzweigen, werden einen sehr schlechten Tag haben, wenn ihre Arbeit auf Änderungen basiert, die nicht mehr verfügbar sind.

edit: das Commit ist per se nicht verloren, es existiert immer noch in Ihrem Repo. Es ist jedoch nicht mehr verfügbar in der Filiale zur Hand

Quelle

2013-12-23 15:40:26 Faisal

Nun, nein. Es ist nicht "uncommit", und das ist nicht der Grund, warum eine umgestufte Branche nicht gedrückt werden sollte. – jthill

@jthill: kümmern sich um mehr? Sie haben nur das negiert, was ich gesagt habe, und haben nicht erklärt, warum das, was ich gesagt habe, falsch ist. Auch, http://git-scm.com/book/ch3-6.html, die Gefahren des Rebasing-Teils erklären es auf die gleiche Weise, wie ich es tat. Vielleicht habe ich etwas verpasst? – Faisal

Ihre Erklärung ist nicht die gleiche wie Ihre. Das Wort "commit", das du benutzt, erscheint dort nie, und deine Antwort hat noch stärkere Implikationen als die schon etwas übertriebene Beschreibung dort. Alle älteren Commits sind nach einer Rebase noch in Ihrem Repo, sie sind * nicht * verloren. – jthill

Git fehlt Code nach dem Zusammenführen

Antwort

Verwandte Themen