Versionsverwaltung - zwei große Branches zusammenführen, aber wie?

[DieDolly]

Bald ist es soweit und ich muss zwei Branches zusammenführen.
Ich habe einen Hauptbranch in dem ich arbeite, einen weiteren in dem ich Neuerungen ins Programm einbaue und einen master Branch.

Mein Neuerungen-Branch unterscheidet sich mittlerweile sehr stark vom Hauptbranch. Es gibt so gut wie keine Unit im Programm die ich nicht geändert habe.
Wie führe / merge ich beide Branches ohne Kopfschmerzen, Hunderten von Konflikten und einem eventuellen Datenverlust? Mein Hauptbranch liegt mittlerweile 17 Commits und weitere 53 geänderte noch un-committete Dateien zurück.

[jfheins]

Schwierig. Hast du mal ein "git merge" laufen lassen, um zu gucken ob es überhaupt so viele Konflikte gibt?

Die Möglichkeiten sehe ich grob wie folgt:
1) Hauptbranch einstellen, Neuerungen als nächste Version bringen.
1a) Du kannst den Merge einfach lösen, indem du stumpf eine Seite nimmst. Ist nachher leider nicht so transparent.
1b) Du benennst den Hauptbranch um in "Version 1.2" (oder was es inzwischen ist) und ernennst den anderen zum neuen Hauptbranch.
2) Durchbeißen und alle Mergekonflikte einzeln lösen

Um die auch Tipps zu geben, so etwas in Zukunft zu vermeiden:
1. Besser sind viele kleine Commits. "53 geänderte noch un-committete Dateien" wären für mich schon per se ein Alptraum. Sowas kommt vielleicht mal vor, wenn man eine Unit umbenannt hat - dann sollte man aber schnell einen commit machen :wink:
2. Viele Feature-Branches statt eines großen. Du kannst die Bugfixes für deinen Hauptbranch ja in einem kleinen Branch machen, dort hinein mergen und dann (nach eventuellen Anpassungen) auch in den Neuerungen-Branch.

[DieDolly]

Zitat:

1. Besser sind viele kleine Commits. "53 geänderte noch un-committete Dateien" wären für mich schon per se ein Alptraum. Sowas kommt vielleicht mal vor, wenn man eine Unit umbenannt hat - dann sollte man aber schnell einen commit machen
2. Viele Feature-Branches statt eines großen.

zu 1 - genau das musste ich leider oft machen
zu 2 - ich arbeite an einem einzigen Feature aktuell. Ist aber leider ein Monster-Teil.

Ich arbeite mit SmartGit. Kann irgendwas gewaltig schief gehen, wenn ich mal nur zum Spaß Feature mit Haupt mergen möchte?

[Aviator]

Naja mit GIT kannst du ja prinzipiell immer wieder zurück gehen. Was du nicht machen solltest, wäre ein Push auf ein evlt. vorhandenes remote Repository. Denn dort wird es schwierig bis unmöglich, ungewollte Änderungen wieder rauszunehmen.

Was ich in solchen Fällen oft mache in denen ich mir unsicher bin ist, dass ich mir ein Backup des Projektordners mache und dann (in der Kopie oder eben im Original) den Test durchführe. Wenn danach noch alles funktioniert, dann ist alles wunderbar. Wenn nicht, wird eben das Backup wiederhergestellt.

[DieDolly]

Zitat:

Was ich in solchen Fällen oft mache ich denen ich mir unsicher bin ist, dass ich mir ein Backup des Projektordners mache und dann (in der Kopie oder eben im Original) den Test durchführe. Wenn danach noch alles funktioniert, dann ist alles wunderbar. Wenn nicht, wird eben das Backup wiederhergestellt.

Ich denke so mache ich es. Ist zwar aufwendig und dauert etwas länger als einfach einen Test-Merge zu machen aber ich denke ich würde mich in den eigenen Hintern beißen wenn ich durch einen Fehler alles verliere.

Erst letzte Woche habe ich git diff --shortstat ausgeführt. Schon dutzende Male gemacht aber dieses mal ratterten die Dateinamen nur so durch die Konsole und Delphi meckerte dann, dass sich Dateien geändert hätten (das waren nach ein paar Prüfungen aber nur Datumswerte wie letzter Zugriff, Modifikation). Seit dem bin ich vorsichtiger.

[Sherlock]

Schief gehen kann erstmal nichts, Du kannst ja immer noch zurück. Andererseits scheinst Du aber noch nicht so ganz auf git-Linie zu arbeiten. Versuch möglichst oft zu committen, zB nach jedem Refactoring, jedem Bugfix etc. Du musst ja nicht alles gleich pushen, falls Du nicht alleine an dem Projekt arbeitest. Aber häufige commits sind das A und O.

Sherlock

[DieDolly]

Zitat:

Schief gehen kann erstmal nichts, Du kannst ja immer noch zurück. Andererseits scheinst Du aber noch nicht so ganz auf git-Linie zu arbeiten. Versuch möglichst oft zu committen, zB nach jedem Refactoring, jedem Bugfix etc.

Ich pushe nichts. Alles bleibt lokal auf meiner Entwicklermaschine. Nichts kommt auf Github.
Mein aktueller Refactor dauert schon 20 Committs und Hunderte Änderungen.

[DieDolly]

Demnächst steht mein großer Merge an.
Ich habe eben noch eine andere Idee gehabt, wie ich das ohne Probleme machen kann. Was sagt ihr dazu?

Branches: dev, featureX, master.
featureX ist etwa 30 commits weiter als dev und master.

Ich bleibe in featureX, kopiere das gesamte Projektverzeichnis, checke dev aus, überschreibe das dev-Projektverzeichnis mit dem featureX-Projektverzeichnis und commite die Änderungen als meinen eigenen manuellen Merge.

[Aviator]

Ganz ehrlich? Was bringt dir ein neuer Branch, wenn du den alten sowieso überschreiben willst? Beim Überschreiben der Dateien gehen dir sämtliche Änderungen im Dev Branch verloren. Dann hättest du den FeatureX Branch auch nicht anlegen müssen. Wenn du sowieso alle Änderungen von Dev überschreiben bzw. FeatureX den Vorrang lassen willst, dann mach ein git merge FeatureX aus dem Dev Branch heraus. Laut deiner Logik dürfte dann auch kein Merge Conflict entstehen. Falls doch, siehst du wenigstens, wo du evtl. Änderungen im Dev Branch nicht mehr beachtet hast. Das kann aufwendig sein, aber immer besser als sich die Arbeit von einigen Tagen zunichte zu machen.

[DieDolly]

Ich fahre seit einigen Monaten zweigleisig. Ich möchte regelmäßige Updates nicht vernachlässigen und dafür ist der dev Branch da. Der featureX Branch bekommt alles einverleibt, was ich seit einigen Monaten einbaue aber noch nicht reif für das wilde WWW ist.
Der dev branch soll schon noch der Hauptbranch nach master sein. Den featureX branch lösche ich, sobald das erledigt ist was ich da mache.