Ich bin neugierig zu wissen, ob Sie KÖNNEN und ob etwas mit dem Verschmelzen von Commits in meine Waisen-Filiale falsch ist. Für diese spezifische Instanz hat mein Salesforce-Repository einen Master-Zweig und einen Pre-Release-Zweig, aber da unsere Sandbox-Umgebung häufig Metadaten enthält, die nicht Teil der Produktion sind, möchten wir sie dennoch versionieren, aber ausreichend von unserem Clean-Pre-Release-Zweig trennen / p>
So wie es ist, haben wir folgendes:
%Vor%Das Zusammenführen von Commits, die keinen gemeinsamen Root-Commit haben, ist mit Git erlaubt. Das Ergebnis enthält die Vereinigung der Dateien, die in beiden Zweigen vorhanden sind. Dies ist eine gängige Praxis, um zwei Projekte zu einem einzigen Repository zusammenzuführen (zum Beispiel wurde das Git-Projekt selbst an e83c51633 , gitk wurde unter 1db95b00 gestartet, und beide Projekte wurden später bei 5569bf9bb zusammengeführt.
Nun, ob Sie das wirklich wollen, hängt wirklich vom Inhalt der Zweige ab. Wenn Sie Ihren Sandbox-Zweig in Ihren Feature-Zweig zusammenführen, bringt das Zusammenführen des Feature-Zweiges in den Master Ihren Sandbox-Code ebenfalls in den Master, was Sie wahrscheinlich nicht möchten.
Mit git 2.9 (Juni 2016) ist das Verschmelzen von Orphan-Zweigen weiterhin möglich, aber nur mit der Option --allow-unrelated-histories
:
Siehe committe e379fdf (18. März 2016) von Junio C Hamano ( gitster
) .
(Zusammengeführt von Junio C Hamano - gitster
- in commit d04aa7e , 08 Apr 2016)
merge: weigere dich, standardmäßig eine zu coole Zusammenführung zu erstellen
Es ist zwar sinnvoll, die Verknüpfung von zwei Geschichten zu erlauben Projekte, die unabhängig voneinander in einer Weise begonnen haben, wie "
>gitk
" war fusioniert zu "git
" selbst aka "die coolste Fusion aller Zeiten" , so eine Zusammenführung ist immer noch ein ungewöhnliches Ereignis. Schlimmer noch, wenn jemand eine unabhängige Geschichte erstellt, indem er von einem Tarball eines etablierten Projekts ausgeht und eine Pull-Anfrage an das ursprüngliche Projekt sendet, erstellt "git merge
" glücklich eine solche Zusammenführung, ohne dass etwas Ungewöhnliches passiert.Teach "
git merge
", um die Erstellung einer solchen Zusammenführung standardmäßig zu verweigern, es sei denn, der Benutzer übergibt eine neue "--allow-unrelated-histories
" -Option an Sagen Sie ihm, dass dem Benutzer bewusst ist, dass es zwei nicht verwandte Projekte sind verschmolzen.Weil solch eine "Zwei-Projekt-Zusammenführung" ein seltenes Ereignis ist, eine Konfiguration Option, um eine solche Zusammenführung immer zuzulassen, wird nicht hinzugefügt.
git merge
doc erwähnt:
Standardmäßig verweigert der Befehl
git merge
das Zusammenführen von Historien, die keinen gemeinsamen Vorfahren haben. Diese Option kann verwendet werden, um diese Sicherheit beim Zusammenführen von Historien von zwei Projekten, die ihr Leben unabhängig voneinander begonnen haben, zu überschreiben.
Da dies eine sehr seltene Gelegenheit ist, gibt es keine Konfigurationsvariable, die standardmäßig aktiviert werden kann. Sie wird nicht hinzugefügt, und die Liste der Optionen oben in dieser Dokumentation erwähnt diese Option nicht Auchgit pull
übergibt diese Option nicht angit merge
(stattdessen, dugit fetch
zuerst, untersuche, was du zusammenführen willst und danngit merge
lokal mit dieser Option).
Siehe commit de22496 (21 Apr 2016) von Junio C Hamano ( gitster
) .
(Zusammengeführt von Junio C Hamano - gitster
- in committe 175008d , 29 Apr 2016)
%Vor%
pull
: Übergeben Sie--allow-unrelated-histories
an "git merge
"Anstelle von:
%Vor%Wenn jemand geneigt ist, eine solche Option hinzuzufügen, aktualisiert dies die Tests Änderungen müssen zurückgestellt werden auf: