push po rebase --interactive

Witam.
Nie wiedziałem gdzie temat z gita umieścić.
Chodzi o to, że zrobiłem commita na branchu odbitym od brancha bazowego, którego wypchnąłem. Następnie wprowadziłem poprawki, które zakomitowałem. Problem w tym, że wszystko powinno pójść jednym commitem, więc zrobiłem rebase --interactive i połączyłem 2 commity w jeden, ale teraz mam problem z wypchnięciem tego:

error: failed to push some refs to 'xxx'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Można zrobić --force push, ale wolę tego uniknąć.
Jest jakiś sposób aby to ogarnąć?

Za mało info. Czemu jesteś behind remote? Co mówi git status? Jeśli ktoś coś spushował w międzyczasie, to git pull zrobi auto-merge. Albo git pull --rebase, który nałoży Twoje commity na szczyt. A jeśli zrobiłeś git rebase --interactive na commitach, które już były spushowane do remote, to fail, bo rebase jest operacja destruktywną, tzn zmienia historię. Push --force wywali wtedy historię całemu zespołowi.

Nie ma opcji by przepisać historię wypchniętych commitów bez force pusha. Ja robię tak, że pracuję na branchu w pojedynkę i robię na nim force push jeśli trzeba. Jeśli zrobisz force push na branchu to nie musisz potem robić force push na masterze. Force push na branchu jest do przyjęcia, ale force push na masterze to już przegięcie.

Jeśli dwie osoby u nas robią na jednym branchu to jest to podczas programowania w parze, czyli dwie osoby siedzą przy jednym komputerze. W takim przypadku nie ma problemu z rozjazdem historii commitów, bo przecież w dowolnym momencie pracuje się maksymalnie z jednego komputera na tym jednym branchu.

Karister napisał(a):

Za mało info. Czemu jesteś behind remote? Co mówi git status? Jeśli ktoś coś spushował w międzyczasie, to git pull zrobi auto-merge. Albo git pull --rebase, który nałoży Twoje commity na szczyt. A jeśli zrobiłeś git rebase --interactive na commitach, które już były spushowane do remote, to fail, bo rebase jest operacja destruktywną, tzn zmienia historię. Push --force wywali wtedy historię całemu zespołowi.

Tak, jeden commit był już na zdalnym repo, drugi nie.

Branch jest tylko mój tzn. nikt inny na niego nie pcha. Opcja pushowania zmian jako nowy branch też odpada. Ostatecznie dziś rano zrobiłem push --force.
Tak się tylko zastanawiałem czy można zrobić coś innego, bo taka sytuacja przytrafia mi się nie pierwszy raz. Push --force działa, ale problem pojawia się gdy współdzielimy brancha z innymi developerami.

Rebase jest od przepisywania historii, a zdalnie przepisać historię da się tylko przez force push. Musisz się zdecydować czy chcesz przepisywać historię czy nie. Jeśli nie chcesz to masz merge, jeśli chcesz to masz rebase na branchu. Nie widzę problemu w force pushu na feature branchu.

Jeśli wielu programistów pracuje na jednym feature branchu i wchodzą sobie w paradę to problem nie leży w wersjonowaniu tylko w zarządzaniu zespołem. Każdy dojrzały projekt jest na tyle duży, że można spokojnie podzielić pracę i nie wchodzić sobie w paradę. Jeśli coś trzeba zrobić szybciej to programuje się w parze - nie tylko jest szybciej, ale też następuje wymiana wiedzy między członkami zespołu.