Jak zaciągnąć zmiany z mastera na dev?

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 nad merge 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 nad merge 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).