Git Zusammenführen in eine verwaiste Verzweigung

8

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%     
Xtremefaith 24.12.2014, 19:23
quelle

2 Antworten

6

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.

    
Matthieu Moy 24.04.2015, 20:57
quelle
13

Mit git 2.9 (Juni 2016) ist das Verschmelzen von Orphan-Zweigen weiterhin möglich, aber nur mit der Option --allow-unrelated-histories :

%Vor%

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   Auch git pull übergibt diese Option nicht an git merge (stattdessen, du git fetch zuerst, untersuche, was du zusammenführen willst und dann git 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)

  

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:

%Vor%     
VonC 10.04.2016 10:22
quelle

Tags und Links