[jan-kowalski668]

Mogę bez obawy zrobić rebase pull na publicznym branchu (mam dodany 1 niespushowany commit)? - chciałbym pobierać zmiany bez tworzenia merge commitów. Z tego co rozumiem to nie powinno zmienić historii dla tych commitów które już są w remote, tylko dla tego jednego co sam dodałem, dobrze myślę?
#git #programowanie

[Saly]

@jan-kowalski668: rebase zmienia tylko lokalną wersję brancha, bo git ma rozproszoną architekturę i brak automatycznej synchronizacji pomiędzy różnymi serwerami.

To co chcesz zrobić ma sens

[mk321]

@jan-kowalski668: zrób nowy branch z tym co masz, ten oryginalny zresetuj do tego co zdalnie (usuń swojego commita i zrób pulla), przełącz się na swojego brancha i zrób git rebase oryginalny branch.

Na przyszłość rób od razu swojego brancha, a na oryginalnym tylko pulla. Wtedy tylko rebase będziesz musiał zrobić bez czyszczenia tego.

[Saly]

@mk321: co to za fikołki, op może zrobić git fetch && git rebase origin/master

Na przyszłość rób od razu swojego brancha, a na oryginalnym tylko pulla. Wtedy tylko rebase będziesz musiał zrobić bez czyszczenia tego.

@mk321: nie widzę tu przewagi jak wiesz jak git działa. Moje flow jest takie, że zazwyczaj klepię sobie wesoło na masterze a jak chcę coś pushnąć to robię. git push origin HEAD:nazwa-brancha

[mk321]

@Saly: a no można. Ale dzięki tym fikołkom możesz szybko sprawdzić co jest na masterze a co u ciebie.

[Saly]

@mk321: git fetch && git log i widać po adnotacjach gdzie dany commit jest

[jan-kowalski668]

@Saly: @mk321: dzięki Panowie za pomoc, czyli jeżeli dobrze zrozumiałem to mogę zrobić tak jak napisałem albo 2 opcja utworzenie osobnego lokalnego branch i tam wykonanie rebase (bezpieczniejsza droga? ;d).

[mk321]

@Saly: logi tak, ale ja mówię o kodzie. Chcesz szybko zobaczyć jak wygląda kod w oryginalnej wersji? To przełączasz się na mastera, patrzysz i wracasz na swojego brancha.

A tak? Usuwasz commita? Musiałbyś go przerzucić na innego brancha. Szukasz sha commia przed twoim i na niego się chceckoutujesz?

@jan-kowalski668: chyba tak, o ile "rebase pull" to jest to co piszemy.

[jan-kowalski668]

@mk321: z sprawdzeniem kodu to można jeszcze ew. zrobić np. git diff master origin/master, no ale fakt żeby przeglądać oryginalny kod to najlepiej chyba to robić z niezmodyfikowanego brancha, tak rebase pull czyli pull z parametrem --rebase

[mk321]

@jan-kowalski668: tak, też pomyślałem o origin/master, tylko że jak zrobisz fetch to już masz tam najnowsze zmiany. A czasem chcę porównać z tym co było zanim ją zacząłem. Ciężko wytłumaczyć, więc przykład: Robię sobie coś, ale jest jakiś błąd. Nie wiem czy to moja zmiana go spowodowała czy już tak było. Przełączam się na mastera i widzę czy był ten błąd. Mógłbym się przełączyć na origin/master, ale jak zrobiłem fetch (żeby

[jan-kowalski668]

@mk321: rozumiem o co chodzi, pozatym git jest tak rozbudowany że jest jest milion sposobów żeby rozwiązać dany problem i o to chodzi jeżeli dany sposób poprawia wydajność/jakość pracy bo przecież to jest najważniejsze

nie wiem czy zrozumiałem pytanie ale origin/ zawiera po wykonaniu git fetch wszystkie zmiany z remote,
z git reset --hard trzeba uważać żeby sobie commitów nie usunąć, rzadko z tego korzystam, jeżeli już to git restore dla