Verzování software, udržování forků a implementace oprav

[LambdaLover]

Zkráceně, nikdo dnes neví, jak to správně dělat, je to ongoing research.

Co tým/projekt, to jiné názory na verzování a vývoj, a to i když použijete například Git Flow nebo Trunk based development, nebo jiný přístup du jour.

Když půjdete níž do samotného verzovacího nástroje, což je dnes často git, tak i tam se budete hádat jestli merge nebo rebase, a jestli škaredá ale přesná historie, nebo jestli falešná ale líbivá.

V ČR se stal populární Git Flow, a dost developerů ho bude pravděpodobně znát, samozřejmě každý tým si to Git Flow implementuje po svém, takže to často není opravdové Git Flow.

V posledních letech se objevují různé kritiky na Git Flow a nabízejí se alternativy jako třeba Trunk a tak dále.

(Kolega výše zmínil feature flags, které ale taky mají svá úskalí.)

[Reklama]

[MalyTomi]

Tohle ne vzdy chces/muzes udelat, a ty duvody nemusi byt jen technicke.
Kazdopadne predpoklad je, ze si pro zakazniky dostatecne duveryhodny partner na to, aby vubec byli ochotni aplikaci aktualizovat.

Ano, nie vsetko sa da takto riesit. ale tych 90% sa da, pripadne, ak zakaznik pozaduje nieco dost odlisne, tak sa to robi ako samostatny modul. V principe su 2 moznosti: dat to do hlavneho modulu a nastavit nejaky konfig na aktivaciu, alebo samostatny modul, ktory ale musis udrzovat.
U nas nastastie su ludia, ktori u zakaznikov riesia aktualizacie, takze zakaznik nemusi nic.
Pri mensich projektoch sa to da aj samostatnou vetvou, kde ale pravidelne robis rebase. Pri vacsich, to uz moze byt problem.
Stale ide o to, zhodnotit pre danu vec, co je vyhodnejsie, nejake vseobecne pravidlo neexistuje.