[w011]

jak ogarnąć coś takiego w git:

mam jedną główną gałąź oprogramowania, która będzie aktualizowana
od tej gałęzi mogą powstawać odnogi (czyli np. powstanie gałąź główna.zmodyfikowna1, główna.zmodyfikowana2 itd.)
zmiany w odnogach będą specyficzne dla nich

teraz pytanie, jak to wygląda od strony git jeżeli nastąpią zmiany w gałęzi główna? w jaki sposób łączy się modyfikacje tak aby kod w główna.zmodyfikowana1 itd była aktualny?

#git #programowanie

[w.....j]

@w011: automatycznie się nie łączą, na tym polega gałąź że rozwiąż ja oddzielnie

[zly_dzien]

@w011: poczytaj o git flow. To normalne i wskazane by mieć brancha na wersję stable, oddzielnego do rc i np na każdy feature oddzielny branch. Grunt to odpowiednie mergowanie. Czyli np. masz na stałe branche stable i rc, za każdym razem gdy robisz nową funkcjonalność z rc robisz nowego brancha pod feature. Po ukończeniu prac nad danym zagadnieniem zmiany mergujesz do rc. W tym samym czasie może polecieć x commitów do

[w011]

@zly_dzien dzięki, poczytam.

Nie chciałbym tego rozbijać aż tak bardzo (każdy ficzer = osobny branch). Wyobraź sobie, że masz kilka strona na WordPress. Główna gałąź to czysty WordPress. Tworząc stronę dla pierwszego klienta tworzysz również nowy branch (główna.modyfikacja1). Gdy pojawia się druga strona do zrobienia znowu tworzysz branch (główna.modyfikacja2). Gdy pojawi się aktualizacja WP robisz ją w głównej gałęzi i później robisz merge do odnóg.

Coś takiego chcę osiągnąć. Jeszcze raz dzięki

[ponton]

@w011: Jak zmieni Ci się coś w gałęzi głównej i chcesz to zmiany mieć w zmodyfikowanej, to robisz:

git checkout zmodyfikowana
git merge glowna

[zly_dzien]

@w011:
@ponton dobrze pisze, a jak nie bardzo radzisz sobie ze składnią gita to ściągnij np. SourceTree, ale nawet żeby coś wyklikać to musisz znać teorię.
Do ćwiczenia komend gita polecam taką gierę http://pcottle.github.io/learnGitBranching/

[laki1]

Główna gałąź to czysty WordPress. Tworząc stronę dla pierwszego klienta tworzysz również nowy branch (główna.modyfikacja1).

@w011: xDDDDDDDDDDDDDDDDDDDDDDD

Nie rób tak, to nie o to chodzi.

[w011]

@laki1 why? :(

[w011]

albo nvm, zabieram się za lekturę...

[Nativo]

@w011: jeśli merge zrobi za dużo syfu (a czasem się zdarza) to możesz po skomitowaniu zmian do głównej robić rebase gałęzi zmodyfikowanych na główną - czystsza historia, ale czasem też potrafi nabałaganić

[frax]

@laki1: Czemu? To wygląda na całkiem sensowe rozwiązanie (pod pewnymi warunkami). Co najwyżej trzymanie tego w jednym repo może być dziwne, ale też bez przesady.

@w011: Z drugiej strony, trzymanie osobnych projektów w osobnych repozytoriach jest jednak naturalniejsze. Być może dobrze byłoby trzymać 1 repozytorium tylko z tym wordpressowym "pniem", i osobne repozytoria z każdym projektem i jego odgałęzieniami (i, siłą rzeczy, kopią "pnia").

@Nativo: Za dużo syfu? Tzn.

[laki1]

@frax: Jeżeli chce to wszystko trzymać w jednym repo to jest to na pewno złe rozwiązanie.

Mógłby to robić jako jedno repo WPCore, a reszta projektów jako forki z tego głównego, wtedy bardzo na plus takie rozwiązanie

[w011]

@frax dzięki za info

@laki1 dlaczego?

[frax]

@laki1: Możesz to jakoś uzasadnić? Jasne, jedno working directory do wielu projektów nie brzmi za dobrze, ale jeżeli projekty są blisko spokrewnione, to nie musi być taki wielki problem.

[w011]

różnice między projektami będą opierały się na tym, że w jednym będzie inny szablon niż w drugim, inny będzie też zestaw zainstalowanych pluginów

[Nativo]

@frax dużo zależy od sytuacji i w przytoczonym wypadku merge raczej powinien bezproblemowo wchodzić, syf się robi gdy próbujesz coś pomanewrować w historii a mergowałeś bez rebase (dlatego napisałem 'jeśli'), warto wiedzieć o rebase jako alternatywie do samego tylko merge, umiejętne połączenie jednego i drugiego przy większych repozytoriach pozwala uniknąć wielu straconych godzin

[frax]

@Nativo: Wydaje mi się, że sytuacja o której mówisz, to już są konsekwencje rebase'owania (ewentualnie amendowania). Dopóki rebase'a nie używasz wcale, to merge nie powinny być problematyczne. Na commit --amend trzeba uważać, bo to jest taki mini rebase, nie można go nadużywać.

[w011]

@frax @laki1 coś stało to działa. Próbowałem zrobić marge dwóch repozytoriów. W jednym był WP 4.2.1 w drugim 4.2.2, wyskoczyło sporo konfliktów

[w011]

hmm, czy taki fix jest ok?

grep -lr '<<<<<<<' . | xargs git checkout --theirs

[frax]

@w011: Nie jest ok, bo to zamieni całe pliki, a być może jakieś inne (niekonfliktujące) zmiany chcesz zostawić. Jeżeli chcesz we wszystkich konfliktach użyć wersji z mergowanej gałęzi, anuluj tego aktualnego merdża (merge --abort) i użyj merge -s recursive -X theirs. Chyba, że jednak chcesz z jakiegoś powodu zamienić całe pliki.

A te konflikty są między twoimi plikami, czy masz tam w repo jakieś pliki wordpressa, których sam

[w011]

@frax konflikty pojawiły się w plikach samego WP. Symulowałem sobie sytuację, gdy pojawia się aktualizacja WP. Aktualizuję główne repozytorium i później chcę 'wmergować' zmiany do pozostałych repozytoriów.