git, merge --no-ff a rebase

BoneFlute

  • *****
  • 1 745
    • Zobrazit profil
git, merge --no-ff a rebase
« kdy: 16. 05. 2021, 16:25:05 »
Ahoj.

Používám následující postup:
Mám branch master, ze které buildím produkční verzi aplikace. Z ní mi vychází něco jako verze branch, například v1.0. Z ní vychází feature branch, například v1.0-foo.
Vždycky, když mám feature branch (v1.0-foo) hotovou, tak ji mergnu do verze (v1.0) s přepínačem --no-ff. Když mám hotovou verzi, tak ji mergnu do master, opět s přepínačem --no-ff. Díky tomu tam mám pěkné kolejničky, které mi ty commity seskupují.

Mám problém s tím, že když rebasuju master do v1.0, a následně do v1.0-boo, v1.0-foo, tak mi ty kolejničky zmizí. Jako celkem chápu proč to je. A znám řešení - prostě musím všechny feature rebasnout, a zmergnout znova. Ale je to dost pracný, a přijde mi to trochu blbý.

Nevíte jak na to? Jak to dělat lépe?

Cíl je, abych tam měl kolejničky, rebasovat a mít méně práce.

Díky moc.


Re:git, merge --no-ff a rebase
« Odpověď #1 kdy: 16. 05. 2021, 17:12:06 »
"Cíl je, abych tam měl kolejničky, rebasovat a mít méně práce."

ja to nechapu, rebase delam, aby nemel zadne kolejnicky a master vetev byla jedna linearni rada commitu.

Re:git, merge --no-ff a rebase
« Odpověď #2 kdy: 16. 05. 2021, 18:25:31 »
Když chcete „nádraží“ používejte merge. Když chcete lineární historii, používejte rebase.

Re:git, merge --no-ff a rebase
« Odpověď #3 kdy: 16. 05. 2021, 18:39:40 »
Zatim jsem teda vzdy pracoval jen na mensich projektech (rekneme do peti vyvojaru) kde staci udrzovat nizke jednotky releasu ale... rebase jsem nepouzil uz 5+ let. Vubec proste neni potreba. Jedu jen merge nebo squash merge. A master vetev je super prehledna.

Re:git, merge --no-ff a rebase
« Odpověď #4 kdy: 16. 05. 2021, 18:52:34 »
Nechápu tedy proč master chcete rebasnout na v1.0 když jste v1.0 do masteru mergnul, ale
git rebase --rebase-merges
možná udělá to co chcete.  Já to tedy používám v situaci kdy chci nějaké merge pushnout do masteru a zjistím že mezitím do masteru ještě pushnul někdo jiný - a pak chci jen své merge posunout a ne je "klasicky rebasnout".  (Chápu že většina ostatních raději mačká zelená tlačítka která to "řeší sama".)


Re:git, merge --no-ff a rebase
« Odpověď #5 kdy: 16. 05. 2021, 20:12:21 »
Zatim jsem teda vzdy pracoval jen na mensich projektech (rekneme do peti vyvojaru) kde staci udrzovat nizke jednotky releasu ale... rebase jsem nepouzil uz 5+ let. Vubec proste neni potreba. Jedu jen merge nebo squash merge. A master vetev je super prehledna.
Rebase samozřejmě není potřeba, můžete používat merge. Rebase se používá kvůli přehlednější historii.

Re:git, merge --no-ff a rebase
« Odpověď #6 kdy: 16. 05. 2021, 21:22:20 »
Zatim jsem teda vzdy pracoval jen na mensich projektech (rekneme do peti vyvojaru) kde staci udrzovat nizke jednotky releasu ale... rebase jsem nepouzil uz 5+ let. Vubec proste neni potreba. Jedu jen merge nebo squash merge. A master vetev je super prehledna.
Rebase samozřejmě není potřeba, můžete používat merge. Rebase se používá kvůli přehlednější historii.

To je prave ono. O jake prehlednejsi historii je rec? Krome kolejnicek mezi master branch a release branches tam zadne jine koleje nejsou a tyhle kolejnicky jsou zadouci - nebo alespon ja to takhle vidim. Vsechen work-in-progress bordel se squashne a fast-forwardne, takze vysledkem je jeden jediny commit. Takze pokud by nebyly zadne release branches, tak master bude 100% linearni historie. Premyslim jak by se tohle dalo vice zprehlednit.


Re:git, merge --no-ff a rebase
« Odpověď #7 kdy: 17. 05. 2021, 01:01:46 »
Krome kolejnicek mezi master branch a release branches tam zadne jine koleje nejsou a tyhle kolejnicky jsou zadouci - nebo alespon ja to takhle vidim.
To právě záleží na přístupu – někomu tam možná ty merge vyhovují, někdo má raději lineární historii.

Vsechen work-in-progress bordel se squashne a fast-forwardne, takze vysledkem je jeden jediny commit.
Nemyslím si, že je dobré mít za každou cenu celou feature branch jako jeden commit. No a git squash je takový rebase na steroidech, takže tam ten rebase stejně děláte.

Re:git, merge --no-ff a rebase
« Odpověď #8 kdy: 17. 05. 2021, 08:20:39 »
Nemyslím si, že je dobré mít za každou cenu celou feature branch jako jeden commit.
Naopak, až na výjimky, kdy je ta změna natolik jednoduchá a přehledná, že nemá smysl ji rozdělovat, je to hodně špatný nápad.

Ink

  • ****
  • 416
    • Zobrazit profil
    • E-mail
Re:git, merge --no-ff a rebase
« Odpověď #9 kdy: 17. 05. 2021, 10:23:56 »
Vykašlal bych se na kolejničky: https://trunkbaseddevelopment.com/

Co se týče squashování, také si myslím, že to není moc žádoucí, pokud se jednotlivé commity dají logicky od sebe oddělit. Je samozřejmě otázkou, zda má vývojář dostatek disciplíny, aby se při pohledu na jednotlivé commity on nebo někdo další nepozvracel, ale to se dá vždycky vyladit.

Re:git, merge --no-ff a rebase
« Odpověď #10 kdy: 17. 05. 2021, 11:33:16 »
Vykašlal bych se na kolejničky: https://trunkbaseddevelopment.com/

Co se týče squashování, také si myslím, že to není moc žádoucí, pokud se jednotlivé commity dají logicky od sebe oddělit. Je samozřejmě otázkou, zda má vývojář dostatek disciplíny, aby se při pohledu na jednotlivé commity on nebo někdo další nepozvracel, ale to se dá vždycky vyladit.

Tady je to samý squash, squash, squash,... https://trunkbaseddevelopment.com/short-lived-feature-branches/

kimec

Re:git, merge --no-ff a rebase
« Odpověď #11 kdy: 17. 05. 2021, 12:53:33 »
Mám problém s tím, že když rebasuju master do v1.0, a následně do v1.0-boo, v1.0-foo, tak mi ty kolejničky zmizí. Jako celkem chápu proč to je. A znám řešení - prostě musím všechny feature rebasnout, a zmergnout znova. Ale je to dost pracný, a přijde mi to trochu blbý.

Nerozumiem na co je potrebne rebasovat master nad nejaku inu vetvu. Master je za normalnych okolnosti hlavna vetva a z povahy veci nie je dobre ju rebasovat uz len preto, ze bezne byva dostupna ako verejna vetva, na ktoru moze niekto iny odkazovat bez vasho vedomia.
Ked mu rebasenete takto master, dotycny nie je povinny sa premigrovat na vas novy master a moze naveky odkazovat na stary komit mastra pred rebasom. Preto sa master/main nerebasuje.

Ink

  • ****
  • 416
    • Zobrazit profil
    • E-mail
Re:git, merge --no-ff a rebase
« Odpověď #12 kdy: 17. 05. 2021, 14:12:19 »
Vykašlal bych se na kolejničky: https://trunkbaseddevelopment.com/

Co se týče squashování, také si myslím, že to není moc žádoucí, pokud se jednotlivé commity dají logicky od sebe oddělit. Je samozřejmě otázkou, zda má vývojář dostatek disciplíny, aby se při pohledu na jednotlivé commity on nebo někdo další nepozvracel, ale to se dá vždycky vyladit.

Tady je to samý squash, squash, squash,... https://trunkbaseddevelopment.com/short-lived-feature-branches/

Na odkazované stránce vidím to slovo jenom jednou. Na jiné stránce z toho samého webu je odstavec, který považuju za podstatný:

The short-lived feature branch may have received many commits before the developer initiated the pull request. Some developers will squash (rebase) the changes into a single commit before starting code review. Some teams have a policy in favor of or against squash/rebase.

Tedy je to na dohodě/politice daného týmu nebo firmy.

BoneFlute

  • *****
  • 1 745
    • Zobrazit profil
Re:git, merge --no-ff a rebase
« Odpověď #13 kdy: 21. 05. 2021, 00:33:51 »
git rebase --rebase-merges
možná udělá to co chcete.  Já to tedy používám v situaci kdy chci nějaké merge pushnout do masteru a zjistím že mezitím do masteru ještě pushnul někdo jiný - a pak chci jen své merge posunout a ne je "klasicky rebasnout".

Skvělé. To je přesně to co chci! Díky moc.