[p.....k]

cos nie idzie mi to mergowanie.

Jestem na "mybranch" a na "develop" zaszly zmiany ktore ciem w "mybranch"

piszę git merge develop
albogit merge --f-only
i nic "Already up to date".

#git #programista15k #programowanie

[p.....k]

@programista4k: a trzebababylo pull najmpierw zrobic na develop...
pisze cos o konfliktach... hm...

[Barstuk]

Najpierw git checkout develop później git pul origin develop później git checkout mybranch i dopiero wtedy Merge

[Boska_Klaudia]

@programista4k: ProGit przeczytany?

[Barstuk]

Konflikty to niestety ręcznie

[L.....k]

@programista4k: Koniecznie musi być merge? Raczej się robi rebase ze względu na czystszą historię.
git pull origin develop --rebase

[t.....l]

@programista4k: zaczynam sądzić, że trollujesz xD

[Stanislavv]

@Lunatik: to polecenie wykonać na feature branchu aby być na bieżąco z develope? I co to znaczy czystsza historia?

[L.....k]

@Stanislavv: Na feature, tu masz fajnie wyjaśnione https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd77c#:~:text=When%20you%20do%20rebase%20a,the%20master%20branch%20is%20changed.

[kochaj_albo_rzuc]

@programista4k:
git checkout mybranch
git rebase -i develop
git checkout develop
git pull
git checkout mybranch
git rebase -i develop

[draxgar]

@programista4k: git sam nie ściągnie tego co jest na zdalnym repozytorium, ale najszybciej będzie:
- będąc na mybranch
- git fetch
- git rebase origin/develop
Polecam rebase bo nie zostawia gównonicniemówiącychwhistorii merge-commitów. W drugim kroku merge też zadziała.

[p.....k]

@draxgar: wole miec merge comit i widziec co sie zmienilo w mergu, koliego

[draxgar]

@programista4k: taka informacja jest przydatna, tylko w drugą stronę: Gdy robisz merge swoich zmian do głównego/rozwojowego brancha. W przypadku merge z mastera czy innego głównego brancha do swojego 'feature branch' to tylko zaciemnianie historii. Jak twój feature branch znajdzie się w masterze, będą to tylko puste commity z wielce nic nie mówiącym opisem "merged master into feature brach". Takież moje zdanie, ty zrobisz co będziesz chciał.

[draxgar]

@programista4k: A tak mi się przypomniało: Jak chcesz wiedzieć co się zmieniło w 'develop', to zanim zrobisz rebase możesz sobie sprawdzić diff: git diff sha_pierwszego_commitu..sha_2go_commitu. Nie trzeba srać do historii zmian git-a.

Kolejny argument za rebase: zrobiwszy już merge twojegobranch-a do develop, ktoś stwierdza, że chce go wycofać. Mając historię po rebase jest to banalnie proste. Wycofujesz N najnowszych commitów @programista4k i elo, kawa. Mając historię

[p.....k]

@draxgar: :O ale to skomplikowane, a ja tylko programista 4k jestem i pracuje po 14 godzin by mnie nie wywalili i nie mam sil juz tego paczać bo jeszcze robię gierkę dla koliegów #przegryw :(