Verzování 100krát jinak Doporučený
Programování se věnuji již mnoho let. S weby, u kterých jsem začínal, jsem ale nikdy nepotřeboval řešit nějaké verzování projektů. Bylo to prakticky zbytečné. Postupem času jsem se ae začal věnovat mnohem složitějším projektům, kde již verzování je pomalu nutnost. Říkám pomalu, protože jsem aplikace vyvíjel sám nebyl problém sledovat / značit si změny. Takto jsem vytvořil i jednouduchý POS systém zcela bez problémů. Ale i tak jsem věděl, že verzování je nutnost a je třba zvolit nějakou metodu.
1. Verzování ( ZIP )
Začátky jsou vždy těžké, ale v tu chvíli bylo důležitejší, že verzuji.
I když špatně, tak jsem alespoň trochu jsem verzoval.
Verzování jsem prováděl tvorbou zip souborů s oddělenými verzemi. Do souboru jsem popisoval, o jaké změny se jedná. Pro porovnání souborů jsem používal linuxový diff. Řešení to nebylo optimální, ale jako začátek to bylo alepoň trochu dostatečné.
Toto řešení mělo jednu pěknou věc: changelog. Changelog jsem sice evidoval pouze ručně, ale velice pěkně se zobrazoval v aplikaci ( pěkně jsem si to v css nastyloval ). Typy změn jsem evidoval takto:
! oprava chyby
* nová funkce
+ rozšíření funkce
- odstranění funkce
Tyto 4 stavy mi stačily na celý changelog.
2. Verzování - SVN
Když jsem se rozhodoval, jaký profesionální software použít, volba nakonec padla na SVN. V té době ještě neexistoval GIT, takže jsem zvolil toto řešení, které mi v principu vyhovovalo.
V té době jsem pro vývoj používal NetBeans - výborná aplikace na vývoj, která SVN velice dobře implementovala.
Bohužel při samotné realizaci jsem nikdy SVN plně nevyužil, až ve výsledku jsem SVM zrušil. Tímto nechci říct, že by mi SVN nevyhovovalo, ale nepoužíval jsem ho a následně jsem měl více webových projektů, kde verzování nebylo nikdy potřeba.
3. GIT poprvé
GIT mě zaujal hned po vydání. Jeho základní myšlenka verzování se mi mnohem více líbila než u SVN - vždy se posílají pouze změny, ne celé soubory. Prostě geniální řešení.V rámci testů jsem si nasadil na jeden webový projekt. Fungovalo to, ale na one man projekt je to celkem zbytečné.
Následně nenásledovaly žádné projekty, které by byly vhodné k verzování a tak jsem opět verzovat nezačal.
4. GIT podruhé
To že GIT je pro mě geniální jsem věděl už dávno. Konečně ale došlo na reálné nasazení a používání. Prvně pro jednoduché aplikace, ale s delším vývojem a bylo důležité evidovat jednotlivé změny. Díky tomu jsem se s gitem seznámil mnohem lépe a podrobněji.
Jako linuxář, používal jsem pouze konzoli, což mi ale ve výsledku úplně nestačilo.
Zvoli vhodné gui nebylo vůbec jednoduché. Prvně jsem vyzkoušel nativní linuxové gui aplikace jako gitg, git-cola, giggle ... a další. Nejvíce mi vyhovoval giggle, ale i tak jsem ítil, že to není úplně ideální řešení. Stále jsem používal pouze git na lokále.
Další krok, byl jasný = GIT server.
Ale jaký?
První pokusy byly s čistou instalací linuxového serveru s git-web. Fungovalo to, ale administračně to bylo velmi složité. Zbytečně složité. Pak jsem narazil na zajímavý projekt Gitlab. Ten mě vysloveně nadchnul. Splňoval vše co jsem potřeboval, hlavně v momentě, kdy jsme rozšiřovali náš tým.
Pokud uvažujete, jaký GIT server zvolit, tak gitlab mohu jen doporučit. Používáme jej aktivně skoro rok a nemůžeme si jej vynachválit.
Více informací o GitLabu naleznete na oficiálních stránkách projektu: about.gitlab.com/gitlab-ce/
