Also bin ich durch viele Reifen gesprungen, um den Fork/Rebase/Pull-Request-Git-Workflow für Entwickler in meinem Team schmackhaft zu machen, die Versionskontrolle und die Befehlszeile fürchten.Force git, um während der Rebase No-Op-Commits zu machen
ein rebase Artikel zu unserer Entwicklung Wiki Bei der Zugabe, ich habe gerade an dem Punkt, wo ich sage, „Do git rebase. Wenn es irgendwelche Konflikte fusionieren, reparieren sie. Dann tun ein git add. Dann git rebase --continue tun.“
Aber in der Arbeit durch das Beispiel und die Aufnahme von Schnappschüssen, wurde ich daran erinnert, dass, wenn es ein merge Konflikt, und ich kann es für den Upstream-Zweig lösen, ein git rebase --continue in der Tat zu tun weigert fortzusetzen und einen Fehler gibt:
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.
Es gibt eine ausgezeichnete Diskussion über die technischen Details hier: Git rebase: conflicts keep blocking progress
Aber was ich mag würde, ist dieses Verhalten Stop zu machen.
Ich nehme an, es gibt einen guten Entwurf Grund, warum dies passiert (wahrscheinlich im Zusammenhang mit Rebase nur mit der normalen Commit-Maschinerie, wo dieses Verhalten wahrscheinlich sinnvoll ist) aber in dieser Situation ist es verwirrend und unintuitiv und macht die Konfliktlogik: "Fix the Wenn Ihr Fix genau so aussieht wie der vorgelagerte Zweig, machen Sie eine git rebase --skip. In allen anderen Fällen tun Sie eine git rebase --continue. "
Gibt es eine Möglichkeit, dieses Verhalten zu unterdrücken, entweder mit einem Flag zum Rebasieren oder in einer versionsgesteuerten Konfigurationsdatei (ich muss es also nicht auf dem Computer jedes Entwicklers einrichten oder Anweisungen dafür geben)?
Ich glaube nicht, dass dies ein Duplikat dieser Frage ist. Das OP dort drüben fragt, wie man das Umbasieren von leeren Commits überspringt, während OP hier fragt, wie man 'git rebase' erlaubt, leere Commits zu erstellen. –
Aber warum willst du ein leeres Commit? Ein leeres Commit bedeutet, dass die gesamte Arbeit in einem Commit aus dem Zweig eingeführt wurde, auf den rebased wurde. In diesem Fall muss das gesamte Commit entfernt werden. Das könnte nach der Tat gemacht werden (etwa durch Verwendung eines interaktiven Rebases und Weglassen des unerwünschten Commits) oder durch andere Methoden, aber es ist sicherlich "falsch", ein leeres Commit zu haben. – ErikE