git push wybranego commita a nie wszystko Opcje

[nospor]

Hej, jak w git mogę zrobić push do wybranego repozytorium ale push tylko wybranego commita lub wybranych commitow a nie wszystkich?
Po co mi to? Załóżmy że mam repozytorium core, z ktorego korzystają wszystkie nowe projekty. I gdy np. rozwijam projekt 3 i zrobie tam zmianę, która jest uniwersalna i ważna i powinna się znaleźć w innych projektach. Chcę więc ją wrzucic do core, by inny projekty mogły z tamtąd te ważną zmianę pociągnąć. Nie chcę jednak wrzucać innych commitow, ktore robiłem w projekt 3, gdyż one są zbędne w innych projektach

[tzm]

Kiedyś jak sobie wyrabiałem swój workflow który nie koniecznie pasował innym programistą z racji 12 tysięcy plików z node chciałem zrobić coś podobnego i niestety doszliśmy do wniosku że tak się nie da i powinno się raczej tworzyć submoduły które można dołączyć do wybranych projektów i opcjonalnie dociągać, innej drogi niestety nie znaleźliśmy więc podpinam się, może akurat ktoś zna rozwiązanie

@down, nospor : nie dziwie sie ze nikt u mnie nie wiedzial jak to poskladac.. jak nie wybuchlo to potestuje na jakims testowym repo, dzieki

Ten post edytował tzm 17.03.2015, 20:20:11

[nospor]

Aktualnie bawie się z branchami i cherry-pick. Byc moze to bedzie to. Jak obadam, dam znac

edit: dobra, mam:
By zrobic to co pisalem, to po zrobienia komitow w projekt 3, robie
1) nową galąż w projekt 3
2) pushuje tę gałąź do core
3) w core bedąc w master (bo chce to miec w galezi master) robie
git cherry-pick hashcommit
gdzie hashhcommit to hash commita z nowej galęzi, z ktorej chciałęm pobrac zmiany

I dziala

[pyro]

Co prawda cherry-pick zadziała do tego co mówisz (pozwala na aplikowanie konkretnych commitów), ale Twój opis świadczy o tym, że na 80-90% popełniasz błąd w przepływie pracy, więc pewnie chciałbyś jeszcze raz przeanalizować, to co chcesz zrobić

// ADD

Poza tym nie ten dział. Forum: Kontrola i zarzadzanie projektami . Przenoszę i zamykam temat.

Ten post edytował pyro 17.03.2015, 20:24:52

[nospor]

Faktycznie, nie ten dzial. Przenosze i nie zamykam

Skoro uwazasz, ze popelniam blad, chetnie wyslucham na czym on polega. Ewentualnie jak wg. Ciebie powinienem poprawnie zrealizować to co napisałem?

[tzm]

sugestia że nospor chciałby to przeanalizować boska, też chętnie poczytam sugestii pyro bo mam tożsamy problem.

[pyro]

Z opisu wyżej nie wywróżę struktury Twojego projektu i zmian, które wprowadzasz . W praktyce jednak cherry-pick używa się bardzo rzadko i najczęściej wynika to z błędu początkującego. Pracując nad kilkoma wielomiesięcznymi, z n-tysiącami commitów, projektami nie musiałem go użyc ani razu.

[nospor]

pyro czyli chyba nie zrozumiales tego co napisalem. Nie wiem jak to opisac bardziej czytelniej.

[pyro]

Jeżeli przeczytasz jeszcze raz pierwszy post tematu, to jednak chyba przyznasz, że jest to dość ogólny opis sytuacji, do którego ciężko dopasować konkretne rozwiązanie. Na jego podstawie ciężko nawet stwierdzić czy jest to problem natury obycia z GITem, czy może organizacji projektów.

Może jakiś przykład?

[nospor]

Wiekszosc moich projektow ma ten sam "core", czyli kod, ktory jest wpólny dla nich wszyskich: logowanie, rejestracja, zarządzanie uzytkownikami itp.
Czyli kazdy nowy projekt startuje na podstawie "core"

Zalozmy, ze mam projekty:
pr1
pr2
pr3
Wszystko startowały z "core". Każdy z nich rozwijam. I teraz nagle w pr3 zrobiłem coś, co po przemyśleniu okazuje się, żę powinno znaleźć się w "core", gdyż jest to funkcja, która docelowo powinna być we wszystkich projektach. Wiec do "core" chciałbym wrzucić tylko zmiany z danego commita, a nie wszystkie zmiany ktore robiłem w pr3 gdyż inne zmiany są typowe tylko dla pr3 i mają się nijak do innych projektów. Ale akurat ta jedna zmiana, co teraz zrobilem, jest na tyle ciekawa, ze chciałbym by była wszędzie.

edit: to co zrobilem teraz na branchu i cherry-pick można też zrealizować przy pomocy patchy

[pyro]

W takim razie ten "core" to jakiś zbiór gotowych narzędzi? Nie możesz w takim razie dołączać go do swoich projektów jako submoduł?

[nospor]

Nie, core to nie jest zbior narzedzi. core to core.

Jak masz fundamenty budynku, to one są fundamentami budynku, a nie garazem obok Dom budujesz na fundamencie, tak jak ja aplikacje buduje na core a nie obok.

[pyro]

Core jako core też może być submodułem

[nospor]

Tak, ale akurat nie w tym przypadku.
Rozumiem o czym mowisz, mam też takie "narzędzia", które leżą obok i z nich korzystają wszystkie projekty. Ale core w moim przypadku jest dość specyficzny i dlatego robie jak robie. Znalazłem na to dwa sposoby:
branch z cherry-pick lub patche
osiągnąłem co chciałem

[Pyton_000]

No taa ale już Kto Ci pomagał to ja nie powiem

Co do submodułów @pyro to ja nie jestem zwolennikiem. Jakoś mi to nie leży.

[pyro]

Co do submodułów @pyro to ja nie jestem zwolennikiem. Jakoś mi to nie leży.

Ja też nie. Jak dla mnie paczki powinny być paczkami i co prawda submoduł może być taką paczką, ale są do tego lepsze narzedzia, np. composer

[com]

No tak, @pyro niektórzy są jeszcze niezreformowani

[nospor]

No taa ale już Kto Ci pomagał to ja nie powiem

Tja.... w tym temacie wypowiedziales się jak juz bylo po wszystkim....
No dobra, twoje prywatne wskazówki byly nieocenione

[vokiel]

@nospor czyli Ty budujesz aplikację na core (modyfikując je/go), nie używasz go jako core nietykalnego, tak?

Jeśli core byłby nietykalny - czyli całkowity zakaz modyfikacji w obrębie projektu - dopuszczone tylko jego rozszerzanie (już w obrębie budowanej aplikacji). Wtedy byś mógł go łatwo wersjonować: core v1.0, core v1.0.1 itd.

Przy PR3 stwierdzasz, że dobrze byłoby coś dodać do samego core dla reszty projektów. Robisz wtedy nową wersję core i aktualizujesz ją w innych projektach. IMHO core powinieneś traktować jak każdą inną paczkę, np z composer'a.

[nospor]

@nospor czyli Ty budujesz aplikację na core (modyfikując je/go), nie używasz go jako core nietykalnego, tak?

Tak, kazdy projekt moze go sobie zmodyfikowac pod wlasne potrzeby.

Jeśli core byłby nietykalny - czyli całkowity zakaz modyfikacji w obrębie projektu - dopuszczone tylko jego rozszerzanie (już w obrębie budowanej aplikacji). Wtedy byś mógł go łatwo wersjonować: core v1.0, core v1.0.1 itd.

Przy PR3 stwierdzasz, że dobrze byłoby coś dodać do samego core dla reszty projektów. Robisz wtedy nową wersję core i aktualizujesz ją w innych projektach. IMHO core powinieneś traktować jak każdą inną paczkę, np z composer'a.

Hmm... jest to jakis pomysł. Jednak przy obecnej strukturze jaką mam, moze z tym być problem. Ale jak w przyszlosc bede zmieniał, będę miał to na uwadze