česky | english
Práce s Git
Toto je sbírka informací a praktických triků, které jsou užitečné při vývojových pracích v rámci pracovního postupu vývoje.
Viz též Software/DevelopmentWorkflow, která má stejné téma. Možná bychom někdy mohli tyto dvě stránky sloučit?
Software/Assessment/Documentation je dokument o aktuální praxi.
Contents
Několik souvislostí a infrastruktura
O úložištích
Společnost CAcert používá pro vývoj několik "oficiálních" úložišť. Z tohoto důvodu byste měli zvážit, zda se ve své pracovní kopii pohodlně naučíte pracovat s více "vzdálenými repozitáři", alespoň pokud se plánujete hlouběji zapojit.
Úložiště CAcert
Toto úložiště je na adrese git://git.cacert.org/cacert-devel.git. Může je číst každý, ale přístup k revizím mají pouze hodnotitelé softwaru.
Je to "hlavní" úložiště pro důležitější věci a záložní úložiště společnosti CAcert pro případ, že Github již nebude poskytovat své služby nebo že společnost CAcert již nebude považovat tuto službu za vhodnou.
Úložiště Github
Úložiště Github na adrese https://github.com/CAcertOrg/cacert-devel.git je "každodenním pracovním koněm" pro vývoj softwaru. Jakmile se s vámi blíže seznámíme a pokud vyjádříte určitý závazek k vývoji softwaru pro CAcert, váš účet na Githubu brzy získá přístup k revizím tohoto úložiště.
Toto úložiště můžete kdykoli rozvidlit (fork) do svého vlastního účtu a navrhovat změny vydáváním žádostí o stažení.
Ostatní projekty
Na adrese Git.cacert.org je kromě cacert-devel umístěno více projektů, kompletní seznam naleznete na stránce Software/DevelopmentWorkflow#Repositories.
Tato další úložiště mohou, ale nemusí být zrcadlena na účtu CAcert Github, prostě tak, jak se to v danou chvíli zdá vhodné. Úložiště na git.cacert.org by měla být v případě pochybností vždy považována za "master".
O větvích
Při práci na softwaru CAcert s Git byste měli mít alespoň základní znalosti o funkci některých větví v úložišti, jinak může být obtížné začlenit vaši změnu do produktivního softwaru.
release
Release sleduje stav softwaru, jak by měl být nainstalován v kritickém systému. Jakmile je změna nasazena v kritickém systému, je archiv TAR (tarball) z webové stránky importován zpět, aby se ověřilo, že vše proběhlo v pořádku.
Změny ve větvi "release" mohou provádět jen posuzovatelé softwaru (Software Assessors).
Toto je preferovaný základ pro větve oprav chyb (bugfix).
integrace
Integrační větev je "téměř" totožná s větví release, jediné rozdíly mezi oběma větvemi by měly být změny potřebné k tomu, aby se testserver stal testserverem (například barevná schémata, jiné certifikáty a podobné věci).
V dřívějších dobách měla větev "testserver-stable" (pravděpodobně) stejnou funkci, ale protože nebyla zdokumentovaná a pravděpodobně se časem zpřeházela, bylo rozhodnuto vytvořit nový základ.
Změny v této větvi by měli provádět pouze posuzovatelé softwaru (Software Assessors).
Větve pro opravy chyb mohou být založeny na integrační větvi, ale obvykle je vhodnější větev pro vydání.
bug-xxxx
Jde o větve pro opravy chyb, které obsahují změny kódu nutné k opravě jednoho problému sledovaného v nástroji pro sledování chyb https://bugs.cacert.org. Číslo větve je stejné jako číslo problému v bugtrackeru, takže existuje snadný způsob, jak oba systémy propojit.
Obvykle jsou tyto větve založeny na integrační větvi, ale někdy může mít smysl použít jako základ větev release.
Jste-li na volné noze ("freelancer") a chcete poskytnout návrh kódu na opravu chyby/vydání ze systému Bugtracker, usnadníte všem práci, pokud svůj návrh vložíte do větve, která dodržuje tyto konvence.
Větve s chybami mohou upravovat všichni vývojáři softwaru. Výjimkou z běžného pravidla je, že pro větve s chybami by mělo být úložiště (repozitář) Github považován za hlavní (master). Do úložiště CAcert budou převedeny, když to bude považováno za nezbytné, typicky při zahájení testování nebo před předáním opravy chyby do kritického stavu.
test-xxxx
Větve test-xxxx jsou dočasné větve pro testovací kampaně. Jsou založeny na integrační větvi a dostávají jednu (nebo více) větví s chybami, tedy sadu problémů, které se právě testují.
Podle konvence je číslo takové větve stejné jako číslo (první) větve s chybami, která je do ní začleněna, ale ve skutečnosti není nutné toto schéma dodržovat.
Při vytvoření testovací větve by měl být soubor pages/index/feed.rss navíc upraven tak, aby obsahoval poznámku, z níž bude zřejmé, do které větve patří. Tímto způsobem se testeři mohou snadno ujistit, že testserver má odškrtnutou správnou větev, stačí se podívat na první stránku. Historie změn má také smysl, ale není považována za nezbytnou.
Obvykle testovací větve spravují hodnotitelé softwaru, ale v zásadě je to také přijatelné, pokud tuto práci vykonávají zkušení vývojáři.
Obvykle bude mít testserver jednu z těchto testovacích větví zkontrolovanou. Tyto větve se obvykle nacházejí v úložišti CAcert z toho prostého důvodu, že se jedná o úložiště, ke kterému má standardní testserver nejsnadnější přístup.
signer
Tato větev obsahuje úpravy, které jsou nutné k tomu, aby mohl podepisovací program běžet ve stejném systému jako testovací server. Normálně není potřeba a v současné době (začátek roku 2019) nemusí být aktuální.
Měli by do ní zasahovat pouze posuzovatelé softwaru, a i ti by ji měli používat s opatrností. Možná, že tato větev nebude v budoucnu jako samostatná větev nutná, protože tyto změny mohou být také součástí integrační větve.
testserver
Tato větev je zastaralá, dříve se používala pro "status testserveru". Poté, co její rozdíly oproti větvi Release začaly být příliš velké na to, aby se s ní dalo rozumně pracovat, byla opuštěna ve prospěch konceptu testovací kampaně.
testserver-mods
Také zastaralá větev, v dnešní době by měl být rozdíl mezi release a integrační větví přesně takový.
Pro vývojáře na volné noze ("freelancers")
Freelanceři - volné nohy - jsou v tomto kontextu vývojáři, kteří nemají přístup k zápisu do úložiště Github společnosti CAcert. Může to být někdo, kdo právě objevil chybu v systému a myslí si, že ji může snadno opravit, nebo to může být jen začínající vývojář, který navrhuje svou první změnu.
Může to být i někdo, kdo chce propagovat nějakou knihovnu (nebo styl kódování či cokoli jiného) a může poskytnout podrobný kód, který software CAcert "vylepší".
Pokud spadáte do jedné z těchto kategorií, nejjednodušší způsob, jak poskytnout své návrhy změn, je následující:
Vytvořit problém v nástroji Bugtracker. K tomu si musíte vytvořit účet v bugtrackeru společnosti CAcert na adrese https://bugs.cacert.org. To je pravděpodobně nejdůležitější krok, protože žádná změna kódu nebude začleněna bez odpovídajícího problému v bugtrackeru. Bez legrace!
- Vytvořte si účet na Githubu, pokud jej ještě nemáte.
- Rozvidlete (fork), tj. zkopírujte si, repozitář CAcert na Githubu do svého účtu na Githubu.
Vložte své změny do nové větve podle výše uvedené specifikace.
- Pošlete požadavek na stažení na adresu CAcert
Pokud je pro vás tento postup nepřijatelný ((možná nesnášíte Github?)), obraťte se na vývojářskou konferenci pro možné alternativy.
Samozřejmě, pokud nechcete pracovat na změnách, které nikdo jiný nechce, může mít také smysl kontaktovat konferenci předem a diskutovat o navrhovaných změnách tam. Názory na "lepší software" se u různých lidí občas liší...
Pro vývojáře softwaru
Jak na to...
Jsou to krátké kontrolní seznamy, jak dělat konkrétní věci. Většinou to není jediný způsob, jak to udělat, takže pokud si myslíte, že máte lepší způsob, zkuste se o něj podělit!
Vytvoření nové větve pro chybu/funkci
Máte již místní klon repozitáře cacert-devel z git-dev a chcete založit novou větev.
Obvykle to dělají softwaroví asistenti s přístupem k revizím v repozitáři git-dev, ale může být užitečná i při zahájení vývoje v místním úložišti. V závislosti na nastavení nahraďte "origin" aliasem úložiště, na kterém chcete pracovat.
Nejdříve si pořiďte pracovní základnu. Není to nutné, pokud neděláte chyby, ale jinak je to užitečné...:
- git checkout integration
- git pull
Vytvořte větev na základě integrační větve serveru:
- git checkout -b bug-XXXX origin/integration
Nyní proveďte změny. Jste-li připraveni odevzdat změny, zadejte
- git commit -a
Samozřejmě místo použití přepínače -a můžete změny také jednotlivě rozfázovat, ale pak už nejspíš víte, co máte dělat.
Pokračujte ve zlepšování své práce a provádějte další revize. Jakmile jste připraveni sdílet svou práci a máte přístup k revizím v úložišti, proveďte tento krok:
- git push origin bug-XXXX
Pro hodnotitele softwaru (Software Assessors)
Jak...
Instalovat chybu na testový server
V místním vývojovém počítači proveďte:
- git checkout integration
- git pull
- git checkout -b test-XXXX origin/integration
- git merge bug-XXXX
- Pokud chcete do testovacího scénáře přidat další větve s chybami, můžete poslední krok zopakovat.
- git push
Toto jsou specifika testového serveru CAcert a mohou se lišit na vašem vlastním testovacím systému:
- Přihlaste se na testserver test.cacert.org
- Staňte se superuživatelem root příkazem "msu" (či sudo, kterýkoli je dostupný)
- Změňte adresář na /home/cacert/www/
- git pull
Sbalení a předání týmu kritických správců (Critical Admins) k instalaci
Toto mohou dělat jen posuzovatelé softwaru (Software Asessors).
git diff origin/integration...bug-XXXX > bug-XXXX.patch
- Zaslat bug-XXXX.patch na Critical Admins s návodem k instalaci
K chybě připojte poznámku do Bugs Database, že je vydána záplata (patch). Změňte stav chyby na "ready to deploy" (připraveno k nasazení)? V současné době se tento stav používá také k informování posuzovatelů softwaru (Software Assessors), že mají začít vytvářet opravu...
- Sloučení větve s chybou do integrační větve a možná také do větve pro vydání. Je to podobný postup jako při vytváření testovací větve výše, jen přeskočte vytvoření nové větve (git checkout -b test-XXXX origin/integration) a případně nahraďte "integration" za "release".