Git - mergowanie starej gałęzi do nowej

0

Hej, jest taka sytuacja. Mam oryginalne kody umieszczone w gałęzi "original_branch". Z tego powstała gałąź "master", na której robię swoje zmiany. Po jakimś czasie, dostaję od producenta zaktualizowane kody, więc wrzucam je do "original_branch". I teraz pytanie, jak te zaktualizowane kody zmergować do mastera w taki sposób, żeby nie stracić swoich zmian?

1

Probowałeś już zwykłego merdza?
Odbij od mastera gałąź test-master i spróbuj do niej zmerdzować original_branch to zobaczysz co się stanie

2

Chodzi o to, że może być sporo ręcznego mergowania i chciałbym uniknąć robienia tego kilka razy ;) Stąd moje pytanie, może ktoś przechodził już taką ścieżkę.

Taką ścieżkę przechodzi każdy kto trzyma długo żyjące feature brance. To nie jest żaden zarzut do ciebie bo ty nie masz wyboru, po prostu jest to dość częsta sytuacja. Ilość ręcznego merdzowania zależeć będzie od tego ile masz zmian w jednym i drugim kodzie. W ostateczności możliwe że wszystkie twoje zmiany będzie trzeba przepisać :(

0

No problem polega na tym, że to nie jest feature branch. Dostajemy od głównego producenta pełen system (około 500 projektów), który rozwijamy i do którego dorzucamy własne rzeczy. Po około roku producent daje nam zaktualizowaną wersję. I tak w kółko.

3

Ja bym próbował rebase bardziej niż merge ale cudów nie ma, trochę to zajmie.

0
Shalom napisał(a):

Ja bym próbował rebase bardziej niż merge

Przy merge rozwiązujesz konflikty raz, przy rebase co commit. Zawsze preferowałem rebase ze względu na czystszą historę, ale to chyba pierwszy raz jak wolałbym użyć merge. Poza tym to bardziej przypomina sytuację że zmienił ci się framework i musisz dostosować cały kod do nowej wersji, niż to że ktoś w międzyczasie wrzucił ci zmiany na mastera/developa :)

ale cudów nie ma, trochę to zajmie.

Skoro porównałem to do upgrade frameworka to się pochwalę że ostatni upgrade frameworka jaki robiłem zajął pół roku. Więc przygotujcie się na długiego taska

1

Jeśli git rebase ma za dużo konfliktów, a git merge ma ich jeszcze więcej, to może git-imerge da radę. A jeśli chcesz to robić samym git rebase/git merge to pamiętaj o rerere by oszczędzić sobie bólu rozwiązywania tych samych konfliktów raz za razem.

Alternatywnie jest jeszcze git cherry-pick jeśli tych commitów nie jest za dużo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1