[Gumaa]

Mam dwa branche w GITcie - mastera oraz jakąś poboczną gałąź (nazwijmy ją po prostu branch).
Jak prawidłowo wykonywać merge przy aktualizowaniu jednego względem drugiego? Tzn. chcę co jakiś czas wrzucać aktualną wersję plików z mastera na brancha oraz w drugą stronę - to co jest na branchu do mastera (nie występują konflikty bo edytowane są osobne foldery). Tak, żeby zarówno master i branch w pewnym momencie były identyczne i miały te same pliki.

Ostatnio zrobiłem to tak, że najpierw zaktualizowałem brancha wciągając to co jest w masterze wpisując na branchu "git merge master". Potem wrzuciłem zaktualizowanego brancha do mastera wpisując z poziomu mastera "git merge branch". Ale jak teraz patrzę w logach na GitLabie to jakoś to wymieszane się wydaje. Wbudowany graf się popsuł i cała historia zmian robiona na branchu jest traktowana jako czyste rasowo zmiany na masterze. A to co było w tym czasie zmieniane na masterze pojawia się jako osobna gałąź i nie pokazuje się na masterze. Pojawiły się jakieś dodatkowe odgałęzienia nie wiadomo skąd. Ogólnie to nie wiem o co chodzi.

#git #gitlab #programowanie #informatyka #pytanie #gumaapyta

[kiciek]

@Gumaa: Słaby jestem z gita, ale mergując z powrotem chyba parametr -no-ff by pomógł na graf.

[widaczew]

@Gumaa szukasz czegoś co pozwoli wziąć wybrane elementy z jednej gałęzi i wrzucić na inną gałąź? Cherrypick może pomóc.

[Gumaa]

@widaczew umm. Nie jestem pewny czy o to chodzi. Powiedzmy że są dwie gałęzie, jedna dla mnie, druga dla kolegi. W projekcie są dwie odrębne części, ja zmieniam jedną, kolega drugą. Każdy pracuje w swojej gałęzi, na swojej części projektu, nie ruszając części tej drugiej osoby. Co jakiś czas chce zaktualizować obie gałęzie tak, żebym ja na swoją gałąź dostał dostał to, co zrobił kolega i żeby on dostał to, co zrobiłem

[widaczew]

@Gumaa a, to wystarczy zrobić merge do mastera i zacząć nowe gałęzie. Czyli:
Robicie dwie gałęzie od mastera, które rozwijacie.
Uznajecie, że czas na merge, to obie gałęzie idą do mastera i od mastera otwieracie sobie nowe. W sensie nie tyle całkiem nowe, po prostu heady gałęzi trzeba przenieść w taki sposób, żeby były w tym samym miejscu przed kolejnym rozgałęzieniem. I tak w kółko. Może nie jest to rozwiązanie idealne, ale

[widaczew]

@Gumaa ech, tak to "wytłumaczyłem", że brzmi jakbym był chory psychicznie. Po prostu polecam rozwiązanie w którym dość często aktualizuje się mastera i od niego robi branche i do niego się merge'uje, zamiast dwóch branchy, które się przeplata. Łatwiej tak zachować porządek.

[leoha]

umm. Nie jestem pewny czy o to chodzi. Powiedzmy że są dwie gałęzie, jedna dla mnie, druga dla kolegi. W projekcie są dwie odrębne części, ja zmieniam jedną, kolega drugą. Każdy pracuje w swojej gałęzi, na swojej części projektu, nie ruszając części tej drugiej osoby. Co jakiś czas chce zaktualizować obie gałęzie tak, żebym ja na swoją gałąź dostał dostał to, co zrobił kolega i żeby on dostał to, co zrobiłem ja.

[Gumaa]

@widaczew
@leoha
Właśnie o tym samym pomyślałem przed snem, dzięki! ʕ•ᴥ•ʔ
Ale czy można robić merge bez usuwania gałęzi, czy to jest raczej niezalecane?

[leoha]

Ale czy można robić merge bez usuwania gałęzi

@Gumaa: oczywiście, że można, brancha usuwasz, kiedy już nie jest potrzebny co nie jest równoznaczne z mergem.

[MQs]

@Gumaa: Bawiłeś się tym? https://learngitbranching.js.org/

[Jurigag]

@Gumaa git pull po prostu te zmiany bez konfliktów zaciagnie a tam gdzie konflikty musisz merge zrobić, ja tak zawsze robię i działa, a jeśli chcesz wgrać zmiany z branch do master to ja to robię pr na githubie

[Jurigag]

@leoha albo fork robią xD I pracują na PR, ja wolę fork
@Gumaa

[Jurigag]

@Gumaa ogółem jak masz więcej niż 1 osobę to praca na forkach I PR I zablokowanie pushow do mastera na głównym repo najlepsze będzie

[leoha]

albo fork robią xD I pracują na PR, ja wolę fork

@Jurigag: przeciez funkcjonalnie to jest dokładnie to samo... branch integracyjny, do/z ktorego robią PR

[Jurigag]

@leoha niby tak ale nie do końca

[leoha]

niby tak ale nie do końca

@Jurigag: do końca, fork/PR to tylko sposób zarządzania, ale funkcjonalnie to wciąż jest jest "główny" branch ("integracyjny") i branche na feature'y albo per user albo kto jak już sobie tam ustali. Kwestia nomenklatury.

[Gumaa]

@leoha: @widaczew: gdybyście jeszcze mogli potwierdzić czy dobre rozumiem, powinienem zrobić coś takiego:

...jakieś tam zmiany na obu gałęziach...
Na masterze:

git merge branch1
git merge branch2

Teraz kiedy mam już mastera ze wszystkimi aktualizacjami:
Na pierwszej gałęzi:

git merge master

I to samo na drugiej gałęzi.

Dobrze rozumiem?
Przełączanie gałęzi w sumie załatwiam w VSCode więc nie wypisuje nawet git checkoutów i pulli.

@MQs: właśnie teraz się troche

[widaczew]

@Gumaa: no właśnie tak nie rób. W masterze już masz wszystko, teraz od tego "wszystko" zaczynasz. To jest taki trzon, podstawa. Tamte gałęzie możesz całkiem porzucić nawet i zrobić dwie kolejne dla siebie i kolegi od mastera. I tak co merge. Branche są jak kobiety, nie ma co się do nich przywiązywać, zawsze można szybko ogarnąć nową. ( ͡° ͜ʖ ͡°) Liczy się głównie master.

[Gumaa]

@widaczew: dlatego pytałem wyżej czy trzeba branche usuwać po mergu. Po prostu wydaje mi się że chyba wygodniej jest nie wywalać ich po każdym mergu i po prostu aktualizować, mniej klikania.

[widaczew]

@Gumaa: to zależy, takie aktualizowanie może wprowadzać niepotrzebne zamieszanie, bo masz 3 gałęzie, które traktujesz jak główne. Branchy nie musisz koniecznie usuwać, możesz je zostawić jak są, ale po jakimś czasie będziesz miał ich dużo i na przykład w jakimś GUI będzie się ich sporo wyświetlało, mimo że pracujecie głównie na dwóch + master. Jak masz już merge z masterem, to te gałęzie nie są już potrzebne, bo master zawiera to