Cześć, od dluzszego czasu robie sobie na wlasnej branchy - dev
. W miedzyczasie doszlo duzo zmian na mastera
ktore chcialbym miec na swojej branchce - dev
. Jak to zrobic jednoczesnie nie tracac zmian na dev
?
git fetch
git merge origin/master
(będąc na branchu dev)
# przygotowanie
git checkout master
git pull --rebase
git checkout dev
# właściwa komenda
git rebase master
# podzielenie się zmianą jeśli nastąpiło przepisanie historii
git push --force
@KamilAdam: a jak zrobie tak to bedzie ok?
git checkout master
git pull
git checkout dev
git merge master
HelloKitty napisał(a):
@KamilAdam: a jak zrobie tak to bedzie ok?
git checkout master git pull git checkout dev git merge master
Polecam poczytać o wyższości rebase
nad merge
3.6 Gałęzie Gita - Rebasing. Zwykle w firmach chcą żeby unikać zbędnych comitów
git fetch origin master:master
git merge master
I nie trzeba ani się przęłączać ani psuć historii.
(Abstrahując już od tego, że oddzielny dev
i master
zazwyczaj zwiastują ostrą patologię.)
KamilAdam napisał(a):
Polecam poczytać o wyższości
rebase
nadmerge
3.6 Gałęzie Gita - Rebasing. Zwykle w firmach chcą żeby unikać zbędnych comitów
rebase można używać tylko na branchu którego jeszcze nie zapushowałeś, a najlepiej robić pusha przynajmniej raz dziennie w razie "w" (w obecnej firmie w której pracuję nawet wymagają żeby zapushować co najmniej jeden commit dziennie :| ) więc jest mało użyteczny bo później trzeba pushować z --force co jest zazwyczaj zablokowane (albo usunąć branch i stworzyć na nowo ;) ).
W wielu firmach pracujesz w osobnym branchu, na końcu robisz pull request którego akceptacja automatycznie robi squasha, merguje do mastera i usuwa branch, więc nie ma znaczenia ile commitów zrobiłeś w branchu bo ostatecznie skończy jako pojedynczy commit.
rebase to zuo.
zazwyczaj.
squash tak samo.
KamilAdam napisał(a):
HelloKitty napisał(a):
@KamilAdam: a jak zrobie tak to bedzie ok?
git checkout master git pull git checkout dev git merge master
Polecam poczytać o wyższości
rebase
nadmerge
3.6 Gałęzie Gita - Rebasing. Zwykle w firmach chcą żeby unikać zbędnych comitów
U mnie stosuje się taktykę, gdzie master merguje się do swojego feature brancha. Przed puszczeniem czegokolwiek do mastera, po prostu z deva robi się merge --squash do mastera i ma się 1 commit i historia i mergowanie występuje bez konfliktów. Wszystko jest wtedy uporządkowane.
Po co stosować w takiej sytuacji rebase jeszcze?
Ja to z dev robię zazwyczaj
git pull - -rebase origin master
Rebase na localu (zanim wypchniesz commity): beautiful magic
Rebase na remocie: zło. szatan. nie rób. (chyba że dasz sobie rękę uciąć że nikt jeszcze nie zrobił pulla).