Wpis z mikrobloga

mirki macie pomysł jak zrobić taki myk -

mam brancha master i feature:

|
|
|\
| \
| |
| f
m

w pmomencie m weszła do mastera poprawka na coś co znacznie ułatwi mi pracę i chciałbym sobie domerge'ować zmiany z mastera do feature master ma być nietknięty. A i mam nie używać rebase.

czy mój pomysł :

git checkout feature
git merge master

nie dotknie mastera?

#programowanie #git
  • 14
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@d__k: nie dotkniesz. Dlaczego miałbyś dotknąć? Czy jak mergujesz feature do mastera to martwisz się o takie rzeczy? :)
Zresztą, zrób sobie test na githubie. Będziesz miał przynajmniej czyste sumienie.
  • Odpowiedz
@d__k: Nie dotkniesz. Dzialaj bezpiecznie. Jezeli masz czas to mozesz sobie zrobic brancha testowego (nie zajmie Ci to wiecej niz 1 minute #git4life), tak jak mowi saul, dla czystosci sumienia.
  • Odpowiedz
@d__k:

Opcja 1:

git checkout feature – przełączasz się do brancha feature
git merge master – przenosisz wszystkie commity z mastera do feature, których feature nie posiada i na wierzch ląduje commit miksujący Twoje dotychczasowe zmiany z feature i „nowe”
  • Odpowiedz
@Almagest: niw zamierzałem nawet

git rebase master - przenosisz wszystkie zmiany z mastera na feature branch pod komity z feature, bez dodatkowego merge commita. Zachowujesz ładną, liniową historię.


@LOLWTF: ostatnio jak próbowałem rebase to rozeiązywanie konfliktów powodowało nowe :/
  • Odpowiedz
Zamierzasz kiedyś nanieść zmiany z feature na mastera? Jeżeli tak to raczej nie ruszaj cherry-picka.


@Almagest: Czemu?

ostatnio jak próbowałem rebase to rozeiązywanie konfliktów powodowało
  • Odpowiedz
@Almagest: Czemu?

@MacDada: Commit przeniesiony na feature z mastera przez cherry-pick dostanie inny hash, nie licząc idealnej sytuacji, gdy na feature nie ma jeszcze żadnych commitów, a ten przenoszony commit jest pierwszym, który się pojawił na masterze od momentu rozgałęzienia. Gdyby @d__k próbowałby potem dokonać merge feature w mastera, to ten cherry-pickowany commit znalazłby się w historii dwukrotnie, do tego wszedłby w konflikt ze swoją kopią. Chyba
  • Odpowiedz