Was Sie sagen, klingt unumstritten - wenn Sie regelmäßig Änderungen (von Backport) Änderungen aus dem Hauptzweig in einen Seitenzweig zusammenführen, dann, wenn die Zeit kommt, Ihren Seitenzweig wieder in den Main zu verschmelzen, werden Sie nicht haben so viel Arbeit zu tun.
Natürlich, oder? Im Laufe der Zeit divergieren Ihre Zweige. Und wie Sie heute Ihren Code schreiben, hängt davon ab, wie Sie ihn gestern geschrieben haben. Je mehr sich Ihre Filialen heute auseinander entwickelt haben, desto mehr werden sie sich morgen auseinander bewegen.
Sagen Sie, dass Sie in der Hauptzweig einige Code umgestalten. Sagen Sie, dass Sie im Seitenzweig ein neues Feature implementieren müssen, das den Code verwendet, der refaktoriert wurde. Wenn Sie diese neue Funktion schreiben, bevor Sie die Refactoring-Änderungen zusammenführen (rückportieren), müssen Sie, wenn Sie die neue Funktion in den Hauptzweig portieren möchten, entweder a) den vorbelegten Code in main einfügen oder b) Refaktorieren Sie das neue Feature. Wenn Sie das Refactoring bereits zusammengeführt (rückportiert) haben, kann Ihre neue Funktion ohne all diese Arbeit in main zusammengeführt werden.
Nicht ganz. Aber wenn du 'check checkout topic; git rebase master 'es wird alles gut funktionieren – glebm
Sie könnten seine hilfreiche finden: [Ein erfolgreiches Git-Verzweigungsmodell] (http://nvie.com/posts/a-successful-git-branching-model/) –
@glebm The OP erwähnt, dass es sich um einen _shared_ Zweig handelt. 'git rebase' mit geteilten Filialen kann zu einem Desaster führen, wenn Sie nicht aufpassen. Allerdings ist 'git rebase' in _local_ branches meine bevorzugte Methode. –