Používání gitu při zběsilém refactoringu rubrika: Nástroje: Verzování

2 Andreaw Fean
položil/-a 26.12.2015

Mám nějaký projekt, který obsahuje různé třídy. Na každou třídu mám testy.

To takhle různě refaktoruji, a zjišťuji, že něco by bylo lepší takhle, a něco zase jinak, a že tady jsem zapomněl dokumentační komentář, a tady u metody nějaké chování. A tak dále.

Což jsou různé případy:

  1. Měním chování více tříd, které mezi sebou na sobě závisejí.
  2. Upravuji nebo doplňuji chování k existujícím třídám a metodám a testům.

Jak toto zohlednit v git-flow? To upravování (bod 2) chci spíše amendovat do nějakého předchozího komitu, ve kterém jsem tu třídu vytvářel. Pro změnu chování (bod 1) chci nový komit, nebo amedovat do jiného komitu než u bodu 2.

Co byste mi poradili? Jak k tomu přistupujete?

odkaz
12 Kit
odpověděl/-a 27.12.2015

Můžeš vyvíjet nebo refaktorovat. Obojí současně je rizikové a vede k popisovanému stavu zmatení. Mezi jednotlivými commity tedy buď vyvíjej, anebo refaktoruj. Nikdy obojí. Do komentáře commitu vždy uveď, co jsi vyvinul nebo refaktoroval. Měla by ti na to stačit jedna věta - pokud by jich mělo být víc, zapomínáš dělat commity.

  • Uděláš novou větev
  • Vždy se refaktoruje jedna záležitost v jedné třídě tak, aby to nemělo vliv na zbytek aplikace. Test. Commit.
  • Závislé třídy se poté upraví tak, aby tu třídu používaly novým způsobem. Test. Commit.
  • Pokud je to potřeba, odstraníš z původní třídy tu část, na které už ty závislé třídy nejsou závislé. Testy. Commit.
  • Provedeš rebase práce ostatních uživatelů do své vývojové větve
  • Testy, testy, testy, merge do své hlavní větve a push na server
  • Odstraníš vývojovou větev

Zatím jsem nepřišel na to, k čemu bych potřeboval amendování. Možná k vytvoření zmatku.

Komentáře

  • vaclav : Skvělý komentář. Někdy píši širší popis (doplňuji například konkrétní důvod refaktorizace, ikdyž zlepšení je zjevné z kódu). - Ovšem ne do předmětu, nýbrž do těla commit message. Co si o tom myslíš? 27.12.2015
  • Kit : Tím komentářem commitu jsem měl na mysli -m "commit message". Je dobré, pokud se message vejde na jeden řádek, protože v logu (zejména jednořádkovém) to pak vypadá přehledněji. 27.12.2015
  • Taco : Z popisu úkolu vyplývá, že vůbec nemyslí refactoring, ale redesign. 27.12.2015
  • Andreaw Fean : @Taco: co? jakej je mezi tím rozdíl? @Kit: Díky za příspěvek. Přesně takto to dělám, a přesně takto to dělat nechci. Ptám se, jak to dělat líp. 27.12.2015
  • Taco : @Andreaw Fean: Při refaktoringu se nemění chování kódu, ale jen implementace. Z čehož vyplývá, že testy by po refactoringu měli procházet, aniž by si na ně šáhnul. 27.12.2015

Pro zobrazení všech 3 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.