Vytvoření repozitáře, rebase a tajné údaje

Tento článek propojuje tři témata, na která narazíte, když už základní práci s Gitem zvládáte: jak vytvořit repozitář (pomocí git init nebo v IDE), v čem se rebase liší od merge a jak správně odstranit tajný údaj, který se omylem dostal do historie. Všechna tři se hodí i při práci s Claude Code - tyto operace provádí pomocí příkazů a je dobré vědět, co se za nimi skrývá.

Příklady a snímky rozhraní pocházejí z IDE JetBrains; názvy a umístění akcí se ve vaší verzi mohou lišit. Pro cvičení použijte samostatný výukový repozitář. V pracovním projektu dodržujte jeho pravidla pro větve, commity a odesílání změn.

Vytvoření repozitáře - git init a v IDE

Pokud už je projekt na GitHubu, můžete ho naklonovat. Jiný případ nastane, když máte místní adresář s kódem. git init v něm vytvoří interní data Gitu, ale ne první commit. Následující příklad předpokládá, že README.md a .gitignore už existují a jsou zkontrolované; ostatní potřebné soubory přidáte zvlášť.

git init
git status
# po kontrole README a pravidel ignorování
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

Pro místní repozitář v IDE použijte akci pro vytvoření Git repozitáře nebo zapnutí správy verzí. Share Project on GitHub je samostatný postup: vytvoří také vzdálený repozitář a nabídne odeslání změn. Než je odešlete, zkontrolujte vybrané soubory, historii a viditelnost.

Public nebo private

Při vytváření repozitáře zvolíte jeho viditelnost:

• public - repozitář je viditelný všem na internetu a kdokoli si může prohlédnout jeho kód. Hodí se pro portfolio a open source;
• private - přístup máte jen vy a lidé, které jste pozvali. Pro pracovní a výukový kód, který nemá být veřejný, je to výchozí volba.

Viditelnost není neměnná - později ji můžete změnit v nastavení repozitáře na GitHubu.

rebase vs merge - jaký je rozdíl

merge i rebase řeší stejný úkol - přenést práci z jedné větve do druhé. Každý to ale dělá jinak a na tom závisí, jak bude historie projektu vypadat.

merge spojí historie. Pokud se jejich cesty rozešly, obvykle vznikne merge commit se dvěma rodiči. Jestliže je aktuální větev předkem jiné, Git může provést fast-forward bez nového commitu. Diagram níže ukazuje právě větve, které se rozešly.

merge zachová obě linie a přidá merge commit - z historie je jasně vidět, že existovala samostatná větev feature.

rebase přesune vaše commity tak, jako byste začali pracovat od aktuálního konce cílové větve. Historie pak tvoří přímou řadu. Má to ale svou cenu: rebase přepíše vaše commity - místo původních vzniknou nové s jinými hashi.

Po rebase vypadají commity C a D, jako by vznikly nad E: historie je lineární, ale jde o nové commity (C2, D2) s jinými hashi.

Jak si vybrat:

• merge - když chcete zachovat skutečný průběh historie nebo pracujete se sdílenou větví. Bezpečná výchozí volba;
• rebase - chcete-li před pull requestem uklidit vlastní větev: lineární historie se čte snáz.

Odstranění tajných údajů z repozitáře

Smazání souboru v novém commitu neodstraní tajný údaj z předchozích commitů. Pokud se heslo nebo token dostal k ostatním, nejprve ho u služby, která ho vydala, zneplatněte nebo vyměňte. Vyčištění historie neodstraní kopie, které už někdo vytvořil.

GitHub popisuje postup čištění pomocí git-filter-repo. Konkrétní příkazy závisí na tom, zda chcete odstranit celý soubor, nebo nahradit tajný řetězec, kde se vyskytoval a kam se historie dostala. Řiďte se oficiálním návodem k odstranění citlivých údajů, včetně vytvoření čerstvé kopie, kontroly výsledku, aktualizace vzdálených referencí a pokynů pro kolegy.

Samotné vyčištění místní kopie server nezmění. Vynucené odeslání přepsané historie je samostatný krok, na kterém se musíte dohodnout; univerzální příkaz pro všechny větve tu spouštět nemusíte. Kopie v cizích klonech a forkech nemáte pod kontrolou; pro odkazy a mezipaměti, které jsou na GitHubu stále dostupné, platí podmínky kontaktování Supportu uvedené ve stejném návodu.

Jak snížit riziko, že se to bude opakovat:

• uchovávejte tajné hodnoty mimo kód, například v proměnných prostředí;
• přidejte místní soubory jako .env do .gitignore ještě před jejich sledováním;
• před commitem zkontrolujte vybrané soubory a výstup git diff --cached;
• pokud repozitář podporuje secret scanning a push protection, zapněte je jako další kontrolu. Neodhalí ale všechny možné tajné údaje.

Jak to funguje s Claude Code

Na všechna tři témata narazíte, když s repozitářem pracuje Claude Code. Na co si dát pozor:

• může inicializovat repozitář (git init) a připravit první commit - při vytváření na GitHubu sami zvolíte public, nebo private;
• navrhne způsob sloučení podle pravidel projektu; důsledky merge a rebase si ověřte ještě před spuštěním;
• vidí soubory, které se dostanou do commitu, ale za to, že se do něj nevloudí tajný údaj, odpovídáte nakonec vy.

Předchozí článek: Vrácení a obnovení změn v Gitu