<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.it-core.eu/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=ONSCallie649922</id>
	<title>IT-Core - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://www.it-core.eu/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=ONSCallie649922"/>
	<link rel="alternate" type="text/html" href="https://www.it-core.eu/wiki/index.php?title=Special:Contributions/ONSCallie649922"/>
	<updated>2026-11-06T12:12:00Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.44.2</generator>
	<entry>
		<id>https://www.it-core.eu/wiki/index.php?title=Verzov%C3%A1n%C3%AD_k%C3%B3du_p%C5%99i_pr%C3%A1ci_na_v%C3%ADce_v%C4%9Btv%C3%ADch:_praktick%C3%BD_pr%C5%AFvodce&amp;diff=141410</id>
		<title>Verzování kódu při práci na více větvích: praktický průvodce</title>
		<link rel="alternate" type="text/html" href="https://www.it-core.eu/wiki/index.php?title=Verzov%C3%A1n%C3%AD_k%C3%B3du_p%C5%99i_pr%C3%A1ci_na_v%C3%ADce_v%C4%9Btv%C3%ADch:_praktick%C3%BD_pr%C5%AFvodce&amp;diff=141410"/>
		<updated>2026-08-21T18:26:14Z</updated>

		<summary type="html">&lt;p&gt;ONSCallie649922: Created page with &amp;quot;Prakticky doporučuji zavést automatizovaný skript, který ověří konzistenci verzí mezi všemi soubory projektu. Tento skript spusťte jako součást CI, tedy před každým nasazením. Měl by kontrolovat, že deklarované verze odpovídají skutečně použitým a že žádný modul neodkazuje na neexistující číslo. Dále nastavte pravidlo, že každá změna závislosti musí projít code review a musí být zapsána do changelogu. Tím se vyhnete situaci, k...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Prakticky doporučuji zavést automatizovaný skript, který ověří konzistenci verzí mezi všemi soubory projektu. Tento skript spusťte jako součást CI, tedy před každým nasazením. Měl by kontrolovat, že deklarované verze odpovídají skutečně použitým a že žádný modul neodkazuje na neexistující číslo. Dále nastavte pravidlo, že každá změna závislosti musí projít code review a musí být zapsána do changelogu. Tím se vyhnete situaci, kdy někdo tiše povýší knihovnu a až po měsíci se objeví problém v produkci.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Nakonec si zvykněte na práci s větvemi (branches). Vytvoříte si vlastní větev příkazem git branch nazev a přepnete se na ni pomocí git checkout nazev. Ve větvi můžete experimentovat bez ovlivnění hlavní verze. Po dokončení ji sloučíte zpět přes git merge. Tento postup je standardem v týmové spolupráci. Začněte s jednoduchými příklady, cvičte na vlastních projektech a Git se brzy stane přirozenou součástí vaší práce.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Když uděláte chybu, nezoufejte. Příkaz git status vám ukáže, co se děje, a git log zobrazí historii commitů. Pokud potřebujete vrátit zpět změny v necommitnutém souboru, použijte git checkout -- soubor. Pro vrácení posledního commitu slouží git revert – ale pozor, nevracejte se pomocí git reset, pokud si nejste jisti, protože to může smazat práci. Vždy si raději přečtěte dokumentaci.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Pravidelná synchronizace a komunikace v týmu Nejčastější chybou je ignorování hlavní větve po delší dobu. Doporučuji si denně (nebo alespoň po každé větší změně) aktualizovat svou větev o novinky z hlavní linie. Používejte příkazy jako `git fetch` a `git rebase` – tím přenesete své lokální změny na aktuální základ. Pozor na konflikty: řešte je ihned, neodkládejte na později. Pokud máte rozpracovanou větev déle než týden, je téměř jisté, že sloučení bude bolet.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Pokud testujete celý store, mějte na paměti, že integrační testy mají své místo, ale pro rychlost a čistotu jsou unit testy vhodnější. Pro reducery a async akce je izolace nejlepší, protože vám umožní rychle identifikovat, kde došlo k chybě. Pamatujte, že testy jsou také dokumentací chování. Pokud se stav změní způsobem, který není pokrytý testem, je to často první signál, že nová funkce přináší nečekané vedlejší účinky. Proto udržujte testy malé, zaměřené na jednu odpovědnost, a vždy je spouštějte při každé změně kódu.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Verzování kódu je pro každého programátora nezbytností. Git je nejrozšířenější nástroj, který vám umožní sledovat změny v projektech, vracet se k předchozím verzím a spolupracovat s týmem. Pokud s ním začínáte, nemusíte se bát – stačí pochopit pár základních principů a zvládnete první kroky.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Začněte tím, že si rozdělíte závislosti na tři skupiny: stabilní knihovny s dlouhodobou podporou, aktivně vyvíjené knihovny a interní moduly. U první skupiny používejte striktní verzování, tedy přesné číslo verze bez wildcardů. U druhé skupiny si definujte rozsah, který povoluje menší aktualizace, ale ne zásadní změny rozhraní. Třetí skupinu, interní moduly, spravujte jako samostatné projekty s vlastním číslem verze a zveřejňujte je do lokálního úložiště. Tím získáte přehled, která verze čeho je v sestavení použita.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Při výběru nezapomeňte na komunitu a dostupnost materiálů. Jazyk s rozsáhlou komunitou vám vždy pomůže, když uvíznete na problému. To ale neznamená, že musíte vybírat jen mezi největšími jmény. Existují menší jazyky, které mají skvělé kurzy a aktivní fóra. Zkuste si najít, kolik existuje českých návodů, videí a diskuzí – to vám usnadní první krůčky. Pokud je materiálů málo, budete odkázáni na angličtinu, což může být pro začátek překážka. Vyplatí se zvážit, jestli jste ochotni číst dokumentaci v angličtině, nebo chcete raději česky.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Častým problémem začátečníků je, že dělají commity příliš velké nebo je zapomenou odeslat. Ideální je commitovat po každé malé funkční změně – to usnadňuje hledání chyb. Další chybou je ignorování souborů, které nemají být sledovány, jako jsou dočasné soubory nebo složky s knihovnami. Vytvořte si soubor .gitignore a uveďte v něm, co má Git ignorovat, např. node_modules/ nebo .env. Tím předejdete zbytečnému nepořádku.&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;Když pracujete na více feature větvích současně, verzování kódu se stává kritickým bodem. Bez správného systému snadno dojde ke konfliktům, ztrátě práce nebo neočekávaným chybám. Základem je oddělit každou funkci do vlastní větve, ale to samo o sobě nestačí. Klíčové je udržovat větve aktuální vůči hlavní vývojové linii, ideálně pomocí rebase místo merge, aby historie zůstala lineární a přehledná.&lt;/div&gt;</summary>
		<author><name>ONSCallie649922</name></author>
	</entry>
	<entry>
		<id>https://www.it-core.eu/wiki/index.php?title=User:ONSCallie649922&amp;diff=141407</id>
		<title>User:ONSCallie649922</title>
		<link rel="alternate" type="text/html" href="https://www.it-core.eu/wiki/index.php?title=User:ONSCallie649922&amp;diff=141407"/>
		<updated>2026-08-21T18:26:11Z</updated>

		<summary type="html">&lt;p&gt;ONSCallie649922: Created page with &amp;quot;Autor blogu dílnou i obývákem sází na osvědčené tipy. Sdílím zde, jak si poradit v malém bytě. Nejvíc mě baví popisovat postupy krok za krokem.&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Autor blogu dílnou i obývákem sází na osvědčené tipy. Sdílím zde, jak si poradit v malém bytě. Nejvíc mě baví popisovat postupy krok za krokem.&lt;/div&gt;</summary>
		<author><name>ONSCallie649922</name></author>
	</entry>
</feed>