Git

  • pomáhá ukládat různé verze vašich souborů a kódu, spolupracovat s ostatními, sledovat změny a opravovat chyby
  • je populární systém pro správu verzí
  • vytvořil Linus Torvalds v roce 2005 a od té doby jej spravuje Junio ​​Hamano

Kde používat Git?

Funguje na vašem počítači, ale můžete ho také použít s online službami, jako je GitHub, GitLab nebo Bitbucket, ke sdílení vaší práce s ostatními. Tyto služby se nazývají vzdálené repozitáře.

V tomto tutoriálu se naučíte, jak používat Git pro své vlastní projekty a jak se připojit ke vzdáleným repozitářům online.

Učení se na příkladech

Ukážeme si příkazy Gitu, jako je tento:

Řádky začínající user@localhost:~$ … jsou vstupní s příkazy, které zadáváme.

Nováčkům se používání terminálu může zdát složité, ale učení tímto způsobem vám poskytne dobrou představu o tom, jak Git funguje.

Používá se k

  • sledování změn kódu
  • sledování, kdo provedl změny
  • spolupráci na kódování

Klíčové koncepty

  • Repository: Složka, kde Git sleduje váš projekt a jeho historii.
  • Clone: Vytvoření kopie vzdáleného repozitáře na vašem počítači.
  • Stage: Sdělení Gitu, které změny chcete uložit jako další.
  • Commit: Uložení snímku vašich provedených změn.
  • Branch: Práce na různých verzích nebo funkcích současně.
  • Merge: Sloučení změn z různých větví.
  • Pull: Získání nejnovějších změn ze vzdáleného repozitáře.
  • Push: Odeslání změn do vzdáleného repozitáře.

Práce s Gitem

  • Inicializace Gitu ve složce a její označení jako repozitáře
  • Git nyní vytvoří skrytou složku pro sledování změn v této složce
  • Když je soubor změněn, přidán nebo smazán, je považován za upravený
  • Vyberete upravené soubory, které chcete přidat do Stage
  • Přidané Stage soubory jsou Commitovány, což vyzve Git k uložení trvalého snímku souborů
  • Git vám umožňuje zobrazit úplnou historii každého commitu.
  • Můžete se vrátit k jakémukoli předchozímu commitu.
  • Git neukládá samostatnou kopii každého souboru v každém commitu, ale sleduje změny provedené v každém commitu!

Proč Git?

  • Používá ho více než 70% vývojářů!
  • Vývojáři mohou spolupracovat odkudkoli na světě
  • vidět úplnou historii projektu
  • vrátit se k dřívějším verzím projektu

Instalace

Git můžete stáhnout zdarma z git-scm.com.

  • Windows: Stáhněte a spusťte instalační program. Kliknutím na „Další“ potvrďte doporučená nastavení. Tím nainstalujete Git a Git Bash.
  • macOS: Pokud používáte Homebrew, otevřete Terminál a zadejte brew install git. Nebo stáhněte soubor .dmg a přetáhněte Git do složky aplikace.
  • Linux: Otevřete terminál a použijte správce balíčků. Například v Ubuntu: sudo apt-get install git

Po instalaci budete moci používat Git z terminálu nebo příkazového řádku.

Tip: Instalace Gitu je bezpečná a v případě potřeby jej můžete kdykoli později odinstalovat.

Git Bash

  • je terminál pro Windows, který umožňuje používat příkazy Gitu
  • je po instalaci v nabídce Start
  • můžete používat stejně jako příkazový řádek, ale s dalšími Unixovými příkazy (jako ls a pwd).

Otevření Git Bash

Klikněte na Start, zadejte „Git Bash“ a otevřete aplikaci.

Vypíše soubory ve vaší aktuální složce.

Ověření instalace

Po instalaci zkontrolujte, zda Git funguje, otevřením terminálu (nebo Git Bash ve Windows) a spuštěním:

Pokud je Git nainstalován, zobrazí se vám něco jako git version X.Y.Z

Pokud se zobrazí chyba, zkuste zavřít a znovu otevřít terminál nebo zkontrolujte, zda je Git ve vaší cestě PATH.

Výchozí editor

Během instalace vás Git požádá o výběr výchozího textového editoru, který se otevře, když potřebujete psát zprávy (například pro commity).

Příklad: Nastavení VS Code jako výchozího editoru

Pokud si nejste jisti, vyberte výchozí nastavení (Poznámkový blok ve Windows). Toto nastavení můžete později kdykoli změnit.

Příklad: Nastavení Poznámkového bloku jako výchozího editoru

PATH Prostředí

Volbou přidání Gitu do cesty PATH můžete používat příkazy Gitu v jakémkoli okně terminálu.

Většině uživatelů se důrazně doporučuje provést tento krok během instalace.

Pokud tento krok přeskočíte, budete moci Git používat pouze v Git Bash (ve Windows) nebo Terminálu (v macOS a Linuxu).

Jak přidat Git do cesty PATH po instalaci

  • Windows:
    1. Pokud jste tuto možnost během instalace přehlédli, vyhledejte v nabídce Start položku „Proměnné prostředí“ a otevřete ji.
    2. Klikněte na „Proměnné prostředí…“ a v části „Systémové proměnné“ vyhledejte proměnnou „Path“.
    3. Klikněte na „Upravit“, poté na „Nový“ a přidejte cestu ke složkám Git bin a cmd (např. C:\Program Files\Git\bin a C:\Program Files\Git\cmd).
    4. Klikněte na OK pro uložení. Restartujte terminál.
  • macOS:
    1. Pokud jste instalovali s Homebrew, vaše PATH se obvykle nastaví automaticky.
    2. Pokud ne, otevřete Terminál a přidejte tento řádek do ~/.zshrc nebo ~/.bash_profile:
    3. export PATH="/usr/local/bin:$PATH"
    4. Uložte soubor a spusťte source ~/.zshrc nebo source ~/.bash_profile.
  • Linux:
    1. Většina správců balíčků přidá Git do PATH automaticky.
    2. Pokud ne, přidejte tento řádek do ~/.bashrc nebo ~/.profile.
    3. export PATH="/usr/bin:$PATH"
    4. Uložte soubor a spusťte source ~/.bashrc nebo source ~/.profile.

Po přidání Gitu do vaší cesty otevřete nové okno terminálu a spusťte git --version, abyste zkontrolovali, zda funguje všude.

    Konce řádků

    Git dokáže převést konce řádků v textových souborech.

    Ve Windows je obvykle nejlepší vybrat „Zkontrolovat ve stylu Windows, commit ve stylu Unix“.

    To pomáhá předcházet problémům při sdílení kódu s lidmi používajícími různé operační systémy.

    Aktualizace nebo odinstalace Gitu

    • Aktualizace: Stáhněte a spusťte nejnovější instalační program nebo použijte správce balíčků (např. brew upgrade git nebo sudo apt-get upgrade git).
    • Je vhodné udržovat Git aktuální, abyste měli nejnovější funkce a opravy zabezpečení.
    • Odinstalace: Použijte „Přidat nebo odebrat programy“ ve Windows nebo správce balíčků v systémech Mac/Linux.

    Řešení problémů s instalací Gitu

    Pokud narazíte na problémy s instalací nebo spuštěním Gitu, nebojte se!

    Zde jsou řešení některých nejčastějších problémů.

    Tip: Pokud něco nefunguje hned, zkuste zavřít a znovu otevřít terminál nebo restartovat počítač.

    Běžné problémy s instalací

    • „git není rozpoznán jako interní nebo externí příkaz“
      • Řešení: Git se nenachází v cestě vašeho systému. Ujistěte se, že jste nainstalovali Git a restartujte terminál.
      • V případě potřeby přidejte složku bin Gitu (obvykle C:\Program Files\Git\bin) do PATH.
      • Pokud to stále nefunguje, zkuste restartovat počítač.
    • Chyby oprávnění („Oprávnění odepřeno“)
      • Řešení: Ve Windows spusťte Git Bash nebo terminál jako správce.
      • V macOS/Linuxu v případě potřeby použijte sudo.
    • Chyby SSL nebo HTTPS při cloning/pushing
      • Řešení: Zkontrolujte připojení k internetu.
      • Ujistěte se, že máte aktuální verzi Gitu.
    • Špatná verze Gitu
      • Řešení: Zkontrolujte nainstalovanou verzi pomocí git --version.
      • V případě potřeby si stáhněte nejnovější verzi z git-scm.com.

    Konfigurace Gitu

    Nyní sdělte Gitu, kdo jste.

    Toto je důležité pro systémy správy verzí, protože každý commit Gitu používá tyto informace:

    Uživatelské jméno

    Vaše jméno bude připojeno k vašim commitům. Nastavte ho pomocí:

    E-mailová adresa

    Váš e-mail je také připojen k vašim commitům. Nastavte ho pomocí:

    Změňte uživatelské jméno a e-mail na své vlastní.

    Pravděpodobně to budete chtít použít i při pozdější registraci na GitHub.

    Pomocí parametru –global nastavte hodnotu pro každý repozitář v počítači.

    Pomocí parametru –local (výchozí nastavení) ji nastavte pouze pro aktuální repozitář.

    Proč konfigurovat Git?

    Git používá vaše jméno a e-mail k označení vašich commitů.

    Pokud je nenastavíte, Git vás k tomu při prvním pokusu o commit vyzve.

    Nyní jste přidali minimum konfigurace potřebné k zahájení používání Gitu.

    Takže klidně pokračujte v další kapitole.

    Pro více informací o konfiguraci nebo pokud chcete něco změnit, čtěte dále tuto stránku.

    Zobrazení konfigurace

    Všechna nastavení Gitu si můžete prohlédnout pomocí:

    Příklad: Výpis všech nastavení
    git config –list
    user.name=Vaše jméno
    user.email=you@example.com
    core.editor=code –wait
    alias.st=status
    init.defaultbranch=main

    Chcete-li zobrazit konkrétní hodnotu, použijte:

    Příklad: Zobrazení konkrétního nastavení
    git config user.name
    Vaše jméno

    Změna nebo zrušení nastavení hodnot konfigurace

    Chcete-li změnit hodnotu, spusťte znovu příkaz git config s novou hodnotou.

    Chcete-li odebrat nastavení, použijte –unset:

    Příklad: Zrušení nastavení aliasu
    git config –global –unset code.editor

    Výchozí název větve

    Nastavte výchozí název větve pro nové repozitáře (například main místo master):

    Příklad: Nastavení výchozího názvu větve
    git config –global init.defaultBranch main

    Úrovně konfigurace

    Existují tři úrovně konfigurace:

    Systém (všichni uživatelé): git config –system
    Globální (aktuální uživatel): git config –global
    Lokální (aktuální repozitář): git config –local
    Pořadí priorit je:

    Lokální (aktuální repozitář)
    Globální (aktuální uživatel)
    Systém (všichni uživatelé)
    Důvodem pro použití různých úrovní je, že můžete nastavit různé hodnoty pro různé uživatele nebo repozitáře.

    To lze použít například k nastavení různých výchozích větví pro různé repozitáře a uživatele.

    Příklad: Nastavení lokální konfigurace
    Lokální nastavení platí pouze pro aktuální repozitář.

    git config user.name „Název projektu“
    Příklad: Nastavení globální konfigurace
    Globální nastavení platí pro všechny repozitáře aktuálního uživatele.

    git config –global user.name „Globální název“
    Příklad: Nastavení systémové konfigurace
    Systémová nastavení platí pro všechny repozitáře všech uživatelů.

    git config –system user.name „Název systému“

    Začínáme s Gitem
    Nyní, když je Git nainstalován a zná vaši identitu, můžete začít používat Git.

    #BE0000 #009e03

    Vytvořme si náš první repozitář

    Klíčové kroky k zahájení
    Vytvoření složky projektu
    Přejděte do složky
    Inicializace repozitáře Git
    Vytvoření složky Git
    Začněte vytvořením nové složky pro náš projekt:

    Příklad
    mkdir mujprojekt
    cd mujprojekt
    mkdir vytvoří nový adresář.

    cd změní náš pracovní adresář.

    Nyní jsme ve správném adresáři a můžeme inicializovat Git!

    Poznámka: Otevřete Git Bash zde (Windows)

    Pokud používáte Windows, můžete Git Bash otevřít přímo ve složce projektu:

    Klikněte pravým tlačítkem myši na složku v Průzkumníku souborů
    Vyberte Git Bash zde
    Tím se otevře okno terminálu ve správném umístění.

    Inicializace Gitu
    Nyní, když jsme ve správné složce, můžeme inicializovat Git v této složce:

    Příklad
    git init
    Inicializováno prázdné repozitář Git v /Users/user/myproject/.git/
    Právě jste vytvořili svůj první repozitář Git!

    Co je repozitář?
    Repozitář Git je složka, ve které Git sleduje změny.

    Repozitář ukládá veškerou historii a verze vašeho projektu.

    Co se stane, když spustíte git init?
    Git vytvoří uvnitř vašeho projektu skrytou složku s názvem .git.

    Zde Git ukládá všechny informace, které potřebuje ke sledování vašich souborů a historie.

    Příklad: Zobrazit skrytou složku .git (Linux/macOS)
    ls -a
    . .. .git
    V systému Windows budete možná muset v Průzkumníku souborů povolit „Zobrazit skryté soubory“, abyste viděli složku .git.

    Řešení problémů
    git: příkaz nenalezen
    Řešení: Ujistěte se, že je Git nainstalován a přidán do vaší cesty PATH. V případě potřeby restartujte terminál.
    Přístup odepřen
    Řešení: Zkuste spustit terminál jako správce (Windows) nebo v případě potřeby použijte příkaz sudo (macOS/Linux).

    Co je to nový soubor?
    Nový soubor je soubor, který jste vytvořili nebo zkopírovali do složky projektu, ale Gitu jste neřekli, že ho má sledovat.

    Zde jsou klíčové informace, které je třeba vědět:

    Vytvoření nového souboru (pomocí textového editoru)
    ls – Vypíše soubory ve složce
    git status – Zkontroluje, které soubory jsou sledovány
    Pochopení nesledovaných a sledovaných souborů
    Vytvoření nového souboru
    Váš nový repozitář Git je prázdný.

    Přidejme soubor pomocí vašeho oblíbeného textového editoru a uložme ho do složky projektu.

    Pokud potřebujete pomoc s vytvořením souboru, podívejte se na naši stránku HTML editory.

    V tomto příkladu použijeme jednoduchý HTML soubor:

    Příklad: Jednoduchý HTML soubor


    Ahoj světe!

    Ahoj světe!

    Toto je první soubor v mém novém Git repozitáři.



    Uložte jej jako index.html do složky projektu.

    Vypis souborů v adresáři
    Chcete-li zjistit, které soubory jsou ve složce projektu, použijte příkaz ls:

    Příklad
    ls
    index.html
    ls vypíše všechny soubory v aktuální složce.

    Ve výstupu byste měli vidět index.html.

    Kontrola stavu souboru pomocí příkazu git status
    Nyní zkontrolujte, zda Git sleduje váš nový soubor:

    Příklad
    git status
    Na hlavní větvi

    Zatím žádné commity

    Nesledované soubory:
    (použijte „git add …“ pro zahrnutí do toho, co bude commitováno)
    index.html

    nic nebylo přidáno do commitu, ale existují nesledované soubory (použijte „git add“ pro sledování)
    Git vidí index.html, ale je nesledovaný (zatím není přidán do repozitáře).

    Co je nesledovaný soubor?

    Nesledovaný soubor je jakýkoli soubor ve složce vašeho projektu, který Git zatím nesleduje.

    To jsou soubory, které jste vytvořili nebo zkopírovali do složky, ale Gitu jste neřekli, že má sledovat.

    Co je sledovaný soubor?
    Sledovaný soubor je soubor, jehož změny Git sleduje.

    Chcete-li soubor sledovat, musíte jej přidat do pracovní oblasti (popsáno v další kapitole).

    Řešení problémů
    Soubor se nezobrazuje pomocí příkazu ls: Ujistěte se, že jste jej uložili do správné složky.
    Použijte příkaz pwd pro kontrolu aktuálního adresáře.
    Soubor není uveden ve stavu git: Ujistěte se, že jste ve správné složce a že jste soubor uložili.

    Co je pracovní prostředí?
    Pracovní prostředí (nebo pracovní oblast) je jako čekárna na vaše změny.

    Používáte ho k tomu, abyste Gitu přesně sdělili, které soubory chcete zahrnout do dalšího commitu.

    To vám dává kontrolu nad tím, co se uloží do historie vašeho projektu.

    Zde je několik klíčových příkazů pro pracovní prostředí:

    git add – Přidá soubor do pracovní oblasti
    git add –all nebo git add -A – Přidá všechny změny do pracovní oblasti
    git status – Zobrazí, co je připraveno
    git restore –staged – Zruší připravení souboru
    Přidá soubor do pracovní oblasti pomocí git add
    Chcete-li přidat soubor do pracovní oblasti, použijte git add :

    Příklad
    git add index.html
    Nyní je soubor index.html připraven. Můžete zkontrolovat, co je připraveno, pomocí příkazu git status:

    Příklad
    git status
    Na větvi master

    Zatím žádné commity

    Změny k potvrzení:
    (použijte „git restore –staged …“ pro zrušení připravenosti)
    nový soubor: index.html

    Připravit více souborů (git add –all, git add -A)
    Můžete přidat všechny změny (nové, upravené a smazané soubory) najednou:

    Příklad
    git add –all
    git add -A dělá totéž co git add –all.

    Kontrola připravených souborů pomocí git status
    Zjistěte, které soubory jsou připraveny k odeslání do přípravy a k potvrzení:

    Příklad
    git status
    Na hlavní větvi

    Zatím žádné commity

    Změny k potvrzení:
    (použijte „git restore –staged …“ k odeslání do přípravy)
    nový soubor: README.md
    nový soubor: bluestyle.css
    nový soubor: index.html
    Jak odeslat soubor z přípravy
    Pokud jste soubor omylem odeslali do přípravy, můžete jej z oblasti přípravy odebrat (odebrat ho) pomocí:

    Příklad
    git restore –staged index.html
    Soubor index.html nyní již není odeslán do přípravy. Stejný efekt můžete dosáhnout také pomocí git reset HEAD index.html.

    Řešení problémů
    Odeslán byl nesprávný soubor do přípravy? Pro jeho odeslání použijte git restore –staged .
    Zapomněli jste soubor odeslán do přípravy? Před potvrzením stačí znovu spustit git add .
    Nejste si jisti, co je odesláno do přípravy? Spusťte git status a podívejte se, co bude odesláno do přípravy.

    Co je to commit?
    Commit je něco jako bod uložení ve vašem projektu.

    Zaznamenává snímek vašich souborů v určitém čase se zprávou popisující, co se změnilo.

    V případě potřeby se můžete kdykoli vrátit k předchozímu commitu.

    Zde je několik klíčových příkazů pro commity:

    git commit -m „message“ – Potvrdí změny ve fázi se zprávou
    git commit -a -m „message“ – Potvrdí všechny sledované změny (přeskočí fázi)
    git log – Zobrazí historii commitu
    Jak provést commit se zprávou (-m)
    Chcete-li uložit změny ve fázi, použijte git commit -m „vaše zpráva“:

    Příklad
    git commit -m „První vydání Hello World!“
    [master (root-commit) 221ec6e] První vydání Hello World!
    3 změněné soubory, 26 vložených změn(+)
    create mode 100644 README.md
    create mode 100644 bluestyle.css
    create mode 100644 index.html
    Vždy pište jasnou zprávu, abyste vy i ostatní pochopili, co se změnilo.

    Potvrdit všechny změny bez stagingu (-a)
    Krok stagingu pro již sledované soubory můžete přeskočit pomocí git commit -a -m „message“.

    Tímto se commitují všechny upravené a smazané soubory, ale ne nové/nesledované soubory.

    Příklad
    git commit -a -m „Rychlá aktualizace README“
    [master 123abcd] Rychlá aktualizace README
    1 změněný soubor, 2 vložená nastavení(+)
    Varování: Přeskočení kroku stagingu může vést k zahrnutí nežádoucích změn. Používejte s opatrností.

    Poznámka: git commit -a nefunguje pro nové/nesledované soubory. Pro nové soubory musíte nejprve použít git add .

    Co se stane, když se pokusíte commitovat nový soubor pomocí -a?
    $ git commit -a -m „Zkusit commitovat nový soubor“
    Na hlavní větvi

    Zatím žádné commity

    Nesledované soubory:
    (použijte „git add …“ pro zahrnutí do toho, co bude commitováno)
    index.html

    nic nebylo přidáno do commitu, ale existují nesledované soubory (použijte „git add“ pro sledování)

    Psaní víceřádkových zpráv commitu
    Pokud jednoduše napíšete git commit (bez -m), otevře se váš výchozí editor, abyste mohli napsat podrobnou víceřádkovou zprávu:

    Příklad
    git commit
    Na první řádek napište krátké shrnutí, nechte prázdný řádek a poté níže přidejte další podrobnosti.

    Osvědčené postupy pro zprávy commitu:
    První řádek by měl být krátký (50 znaků nebo méně).
    Použijte rozkazovací způsob (např. „Přidat funkci“, nikoli „Přidaná funkce“).
    Za shrnutím nechte prázdný řádek a poté v případě potřeby přidejte další podrobnosti.
    Popište, proč byla změna provedena, ne jen co se změnilo.
    Další užitečné možnosti commitu
    Vytvořte prázdný commit:
    git commit –allow-empty -m „Spustit projekt“
    Použijte předchozí zprávu commitu (bez editoru):
    git commit –no-edit
    Rychle přidejte změny ve fázi do posledního commitu, zprávu zachovejte:
    git commit –amend –no-edit
    Řešení běžných chyb commitu
    Zapomněli jste přidat soubor do fáze?
    Pokud spustíte git commit -m „message“, ale zapomněli jste na git add soubor, stačí ho přidat a znovu provést commit. Nebo použijte git commit –amend k jeho přidání do posledního commitu.
    Překlep ve zprávě commitu?
    Použijte git commit –amend -m „Opravená zpráva“ k opravě poslední zprávy commitu.
    Omylem jste commitovali nesprávné soubory?
    Můžete použít git reset –soft HEAD~1 k vrácení posledního commitu a ponechání změn ve fázi.
    Zobrazení historie commitů (git log)
    Chcete-li zobrazit historii commitů pro repozitář, můžete použít příkaz git log:

    Příklad
    git log
    commit 09f4acd3f8836b7f6fc44ad9e012f82faf861803 (HEAD -> master)
    Autor: w3schools-test
    Datum: Pá 26. března 09:35:54 2021 +0100

    Aktualizován index.html o nový řádek

    commit 221ec6e10aeedbfd02b85264087cd9adc18e4b26
    Autor: w3schools-test
    Datum: Pá 26. března 09:13:07 2021 +0100

    První vydání Hello World!

    Pro kratší zobrazení použijte git log –oneline:

    Příklad
    git log –oneline
    09f4acd Soubor index.html byl aktualizován o nový řádek
    221ec6e První vydání Hello World!
    Chcete-li zobrazit, které soubory se v jednotlivých commitech změnily, použijte git log –stat:

    Příklad
    git log –stat

    Klíčové příkazy pro tagování
    git tag – Vytvoření odlehčeného tagu
    git tag -a -m „message“ – Vytvoření anotovaného tagu
    git tag – Označení konkrétního commitu
    git tag – Vypsání tagů
    git show – Zobrazení podrobností tagu
    Co je tag?
    Tag v Gitu je jako štítek nebo záložka pro konkrétní commit.

    Tagy se nejčastěji používají k označení důležitých bodů v historii projektu, jako jsou verze (v1.0 nebo v2.0).

    Tagy jsou jednoduchý a spolehlivý způsob, jak sledovat verze a sdílet je s vaším týmem nebo uživateli.

    Mezi běžné typy tagů patří:

    Vydání: Tagy vám umožňují označit, kdy je váš projekt připraven k vydání, takže vy (a ostatní) můžete vždy později najít tuto přesnou verzi.
    Milníky: Použijte tagy k zvýraznění hlavních milníků, například když je dokončena velká funkce nebo je opravena chyba.
    Nasazení: Mnoho nástrojů pro nasazení používá tagy k určení, kterou verzi kódu nasadit.
    Opravy: Pokud potřebujete opravit starou verzi, tagy usnadňují kontrolu a opravu správného kódu.
    Vytvořte lehký tag
    Lehký tag je pouze název pro commit.

    Je to rychlé a jednoduché, ale neukládá žádné další informace.

    Anotované vs. lehké tagy
    Anotovaný tag: Ukládá autora, datum a zprávu.
    Doporučeno pro vydání a sdílení s ostatními.
    Lehký tag: Pouze jednoduchý název pro commit (žádné další informace, jako záložka).
    Příklad
    git tag v1.0

    Vytvořte anotovaný tag (-a -m)
    Anotovaný tag ukládá vaše jméno, datum a zprávu.

    Toto se doporučuje pro většinu použití.

    Příklad
    git tag -a v1.0 -m „Verze 1.0“
    Označení konkrétního commitu
    Starší commit můžete označit zadáním jeho hashe:

    Příklad
    git tag v1.1 1a2b3c4d
    Nahraďte 1a2b3c4d hashem commitu, který chcete označit.

    Vypsat tagy
    Zobrazit všechny tagy ve vašem repozitáři:

    Příklad
    git tag
    Zobrazit podrobnosti o tagu (git show)
    Zobrazit podrobnosti o tagu a commitu, na který odkazuje:

    Příklad
    git show v1.0
    Odeslání tagů na vzdálený počítač
    Ve výchozím nastavení tagy existují pouze na vašem lokálním počítači.

    Pokud chcete, aby ostatní viděli vaše tagy, musíte je odeslat do vzdáleného repozitáře.

    Pokud své tagy neodešlete, uvidíte je pouze vy a pouze lokálně.

    Chcete-li odeslat jeden tag do vzdáleného repozitáře (například po vytvoření tagu vydání):

    Příklad: Odeslání jednoho tagu
    git push origin v1.0
    Věděli jste? Odeslání commitů pomocí git push neodešle vaše tagy!

    Tagy musíte odeslat explicitně, jak je uvedeno výše.

    Chcete-li odeslat všechny lokální tagy najednou na vzdálený server (užitečné, pokud jste vytvořili několik tagů):

    Příklad: Odeslat všechny tagy
    git push –tags
    Smazat tagy
    Lokálně smazat tag:

    Příklad
    git tag -d v1.0
    Smazat tag ze vzdáleného repozitáře:

    Příklad
    git push origin –delete tag v1.0
    Aktualizovat nebo nahradit tag (Vynutit odeslání)
    Pokud potřebujete přesunout tag do jiného commitu a aktualizovat vzdálený server, použijte –force:

    Příklad
    git tag -f v1.0
    git push –force origin v1.0
    Nejlepší postupy pro tagy
    Používejte tagy k označení vydání, hlavních milníků nebo stabilních bodů ve vašem projektu.
    Vždy používejte anotované tagy (s -a -m) pro cokoli veřejného nebo sdíleného.
    Tagy vytvářejte po absolvování všech testů nebo před nasazením/vydáním kódu.
    Řešení problémů
    Tag již existuje? Použijte git tag -d k jeho odstranění a poté jej znovu vytvořte.
    Odeslali jste nesprávný tag? Smažte ho lokálně i vzdáleně a poté odešlete správný tag.
    Tag se nezobrazuje na vzdáleném serveru? Nezapomeňte odeslat tagy pomocí git push origin nebo git push –tags.
    Potřebujete přepsat tag na vzdáleném serveru? Můžete vynutit odeslání tagu pomocí git push –force origin , ale buďte opatrní! Tím se tag přepíše všem uživatelům vzdáleného serveru.

    Klíčové příkazy pro ukládání změn
    git stash – Uložení změn
    git stash push -m „message“ – Uložení se zprávou
    git stash list – Výpis všech ukládání
    git stash branch – Vytvoření větve ze ukládání
    Co je Git Stash? Proč ho používat?
    Někdy potřebujete rychle přepnout úkoly nebo opravit chybu, ale nejste připraveni commitnout svou práci.

    git stash vám umožňuje uložit nepotvrzené změny a vrátit se do čistého pracovního adresáře.

    Můžete se později vrátit a obnovit své změny.

    Zde je několik běžných případů použití:

    Bezpečné přepínání větví: Uložte si práci před změnou větví.
    Řešení nouzových situací: Uložte si práci, abyste opravili něco naléhavého, a poté ji obnovte.
    Udržujte svou rozpracovanou práci v bezpečí: Vyhněte se chaotickým commitům nebo ztrátě změn.
    Uložení změn (git stash)
    Uložte si aktuální změny (stagedované i nestagedované sledované soubory) pomocí:

    Co se ukládá?
    Sledované soubory (připravené i nepřipravené) jsou ve výchozím nastavení ukládány do složky.
    Nesledované soubory (nové soubory, které ještě nebyly přidány do Gitu) nejsou ve výchozím nastavení ukládány do složky. Chcete-li uložit i nesledované soubory, použijte git stash -u (nebo –include-untracked).
    Příklad: Uložení vaší práce
    git stash
    Uložený pracovní adresář a stav indexu WIP na main: 1234567 Přidat novou funkci
    Tento příkaz ukládá vaše změny a čistí váš pracovní adresář, abyste mohli bezpečně přepínat mezi úlohami nebo větvemi.

    Vaše změny jsou nyní uloženy v zásobníku.

    Co je zásobník pro ukládání?

    Pokaždé, když spustíte git stash, vaše změny se ukládají na vrchol „zásobníku“.

    Nejnovější ukládání je nahoře a můžete použít nebo odstranit ukládání shora dolů nebo vybrat konkrétní ze seznamu.

    Váš pracovní adresář je čistý a můžete bezpečně přepínat mezi větvemi nebo stahovat aktualizace.

    Uložit se zprávou (git stash push -m)
    Přidat zprávu, která si zapamatuje, co jste uložili:

    Příklad: Uložit se zprávou
    git stash push -m „WIP: redesign homepage“
    Uložený pracovní adresář a stav indexu Na hlavní stránce: WIP: redesign homepage
    Tento příkaz umožňuje přidat do vaší uložené … 2 +-
    1 soubor změněn, 1 vložení(+), 1 smazání(-)
    Tento příkaz poskytuje souhrn souborů a změn ve vaší poslední ukládací schránce.

    Pro zobrazení úplného rozdílu:

    Příklad: Zobrazit úplný rozdíl
    git stash show -p
    diff –git a/src/index.html b/src/index.html
    index 1234567..89abcde 100644
    — a/src/index.html
    +++ b/src/index.html
    @@ …
    Tento příkaz zobrazuje přesné řádky, které byly ve vaší poslední ukládací schránce změněny.

    Použít nejnovější stash (git stash apply)
    Obnovení vašich nejnovějších změn v stashu (stash se ponechá v zásobníku):

    Příklad: Použít nejnovější stash
    git stash apply
    Ve větvi main
    Změny, které nebyly připraveny pro commit:
    (použijte „git add …“ k aktualizaci toho, co bude commitnuto)
    (použijte „git restore …“ k zahození změn v pracovním adresáři)
    upraveno: src/index.html
    Tento příkaz obnoví vaše nejnovější změny v stashu, ale stash se ponechá v seznamu, abyste ho mohli v případě potřeby znovu použít.

    Použít specifický stash (git stash apply stash@{n})
    Obnovení specifického stashu ze seznamu:

    Příklad: Použít specifický stash
    git stash apply stash@{1}
    Ve větvi main
    Změny, které nebyly připraveny pro commit:
    upraveno: src/index.html
    Tento příkaz umožňuje obnovit specifický stash ze seznamu, nejen ten nejnovější.

    Odebrat Stash (git stash pop)
    Použije nejnovější stash a odebere ho ze zásobníku:

    Příklad: Odebrat Stash
    git stash pop
    Ve větvi main
    Změny, které nebyly připraveny pro commit:
    upraveno: src/index.html
    Odstraněny refs/stash@{0} (abc1234d5678)
    Tento příkaz obnoví váš nejnovější stash a zároveň ho odebere ze seznamu.

    Odstranění Stash (git stash drop)
    Odstranění konkrétního stashe, když ho již nepotřebujete:

    Příklad: Odstranění Stash
    git stash drop stash@{0}
    Odstraněný stash@{0} (abc1234d5678)
    Tento příkaz odstraní konkrétní stash ze seznamu, když ho již nepotřebujete.

    Vymazat všechny stashe (git stash clear)
    Smazat všechny vaše stashe najednou:

    Příklad: Vymazat všechny stashe
    git stash clear
    Tento příkaz smaže všechny vaše stashe najednou. Buďte opatrní! Tuto akci nelze vrátit zpět!

    Větev ze stashe (git stash branch)
    Vytvořte novou větev a aplikujte na ni stash.

    Užitečné, pokud by se vaše uložené dílo mělo stát samostatnou větví funkcí:

    Příklad: Větev ze stashe
    git stash branch new-feature stash@{0}
    Přepnuto na novou větev ‚new-feature‘
    Na větvi new-feature
    Změny nebyly připraveny pro commit:
    upraveno: src/index.html
    Zrušeno stash@{0} (abc1234d5678)
    Tento příkaz vytvoří novou větev a aplikuje na ni vaše uložené změny.

    To je užitečné, pokud se rozhodnete, že by se vaše dílo mělo stát samostatnou větví funkcí.

    Nejlepší postupy pro ukládání
    Při ukládání používejte jasné zprávy: git stash push -m „WIP: feature na

    Co je historie Gitu? Proč ji používat?
    Git uchovává podrobný záznam o každé změně provedené ve vašem projektu.

    Příkazy history můžete použít k zobrazení toho, co se změnilo, kdy a kdo změnu provedl.

    To je užitečné pro sledování pokroku, hledání chyb a pochopení vývoje vašeho projektu.

    Klíčové příkazy pro zobrazení historie
    git log – Zobrazit celou historii commitů
    git log –oneline – Zobrazit souhrn commitů
    git show – Zobrazit podrobnosti o konkrétním commitu
    git diff – Zobrazit nestagedované změny
    git diff –staged – Zobrazit stagedované změny
    Nejlepší postupy pro zobrazení historie
    Provádějte časté a smysluplné commity, aby vaše historie byla přehledná.
    Pište jasné zprávy o commitech, abyste vy a váš tým později pochopili změny. Použijte git log –oneline pro rychlý přehled historie vašich commitů.
    Před commitem použijte git diff pro kontrolu vaší práce.
    Zobrazit historii commitů (git log)
    Zobrazit podrobný seznam všech commitů ve vašem repozitáři:

    Příklad: Úplná historie commitů
    git log
    commit 09f4acd3f8836b7f6fc44ad9e012f82faf861803 (HEAD -> master)
    Autor: w3schools-test
    Datum: Pá 26. března 09:35:54 2021 +0100

    Soubor index.html byl aktualizován o nový řádek
    Tento příkaz zobrazí všechny commity, včetně autora, data a zprávy.

    Pomocí kláves se šipkami posouvejte a stisknutím klávesy q ukončete.

    Tip: Při prohlížení logu můžete vyhledat slovo zadáním znaku / a následně hledaným výrazem
    (například /fix) a stisknutím klávesy n přejít na další shodu.

    Stisknutím klávesy q kdykoli ukončíte.

    Zobrazit podrobnosti commitu (git show )
    Zobrazí všechny podrobnosti a změny pro konkrétní commit:

    Příklad: Zobrazit podrobnosti commitu
    git show 09f4acd
    commit 09f4acd3f8836b7f6fc44ad9e012f82faf861803 (HEAD -> master)
    Autor: w3schools-test
    Datum: Pá 26. března 09:35:54 2021 +0100

    Aktualizován index.html o nový řádek

    diff –git a/index.html b/index.html
    index 1234567..89abcde 100644
    — a/index.html
    +++ b/index.html
    @@ …
    +Nový název
    Tento příkaz zobrazí vše o commitu: kdo ho vytvořil, kdy, zprávu a přesné změny.

    Porovnání změn (git diff)
    Zjistěte, co se liší mezi vaším pracovním adresářem a posledním commitem (nepřipravené změny):

    Příklad: Viz Nepřipravené změny
    git diff
    diff –git a/index.html b/index.html
    index 1234567..89abcde 100644
    — a/index.html
    +++ b/index.html
    @@ …
    -Starý název
    +Nový název
    Tento příkaz zobrazuje změny, které jste provedli, ale ještě nebyly připraveny pro commit.

    Porovnání změn ve fázi (git diff –staged)
    Podívejte se, co se liší mezi vašimi soubory ve fázi a posledním commitem:

    Příklad: Viz změny ve fázi
    git diff –staged
    diff –git a/index.html b/index.html
    index 1234567..89abcde 100644
    — a/index.html
    +++ b/index.html
    @@ …
    -Starý název
    +Nový název
    Tento příkaz zobrazuje změny, které jsou ve fázi a připraveny k potvrzení.

    Porovnání dvou commitů (git diff )
    Zobrazení změn mezi libovolnými dvěma commity:

    Příklad: Porovnání dvou commitů
    git diff 1234567 89abcde
    diff –git a/index.html b/index.html
    index 1234567..89abcde 100644
    — a/index.html
    +++ b/index.html
    @@ …
    -Starý název
    +Nový název
    Tento příkaz zobrazuje rozdíly mezi dvěma konkrétními commity.

    Zobrazení souhrnu commitů (git log –oneline)
    Zobrazení krátkého shrnutí každého commitu (skvělé pro rychlý přehled):

    Příklad: Jednořádkový protokol
    git log –oneline
    09f4acd Aktualizace index.html o nový řádek
    8e7b2c1 Přidání stránky o nás
    1a2b3c4 Počáteční commit
    Tento příkaz zobrazuje každý commit na jednom řádku pro snadné čtení.

    Zobrazit commity podle autora (git log –author=“Alice“)
    Zobrazit pouze commity provedené konkrétním autorem:

    Příklad: Commity podle autora
    git log –author=“Alice“
    commit 1a2b3c4d5e6f7g8h9i0j
    Autor: Alice
    Datum: Po 22. března 10:12:34 2021 +0100

    Přidat stránku s informacemi
    Tento příkaz filtruje protokol tak, aby zobrazoval pouze commity od autora, kterého zadáte.

    Zobrazit nedávné commity (git log –since=“před 2 týdny“)
    Zobrazit pouze commity provedené v posledních dvou týdnech:

    Příklad: Nedávné commity
    git log –since=“před 2 týdny“
    commit 09f4acd3f8836b7f6fc44ad9e012f82faf861803
    Autor: w3schools-test
    Datum: Pá 26. března 09:35:54 2021 +0100

    Soubor index.html byl aktualizován o nový řádek
    Tento příkaz zobrazuje pouze commity provedené v nedávném časovém rámci.

    Zobrazit soubory změněné v každém commitu (git log –stat)
    Zobrazí, které soubory byly v každém commitu změněny a kolik řádků bylo přidáno nebo odebráno:

    Příklad: Záznam se statistikami
    git log –stat
    commit 09f4acd3f8836b7f6fc44ad9e012f82faf861803
    Autor: w3schools-test
    Datum: Pá 26. března 09:35:54 2021 +0100

    Soubor index.html byl aktualizován o nový řádek

    index.html | 2 +-
    1 soubor změněn, 1 vložení(+), 1 smazání(-)
    Tento příkaz přidá souhrn změn souborů ke každému commitu v protokolu.

    Zobrazit graf větví (git log –graph)
    Zobrazit jednoduchý ASCII graf historie vaší větve (skvělé pro vizualizaci slučování):

    Příklad: Záznam s Graphem
    git log –graph –oneline

    • ​​09f4acd Aktualizován index.html o nový řádek
    • 8e7b2c1 Přidat stránku o nás
      |\
      | * aabbccd Sloučit větev ‚feature-x‘
      |/
      Tento příkaz zobrazí jednoduchý graf historie vaší větve a slučování.

    Řešení problémů
    Nevidíte své změny? Ujistěte se, že jste svou práci potvrdili. Nepotvrzené změny se v historii nezobrazí.
    Záznam je příliš dlouhý? Použijte git log –oneline

    Proč a kdy používat nápovědu Gitu?
    Git má mnoho příkazů a možností.

    Pokud zapomenete, jak příkaz funguje, nebo se chcete dozvědět o jeho možnostech, můžete použít vestavěnou nápovědu Gitu.

    Toto je nejrychlejší způsob, jak získat odpovědi, aniž byste museli opustit terminál.

    Klávesové příkazy pro získání nápovědy
    git help – Viz manuálová stránka pro příkaz
    git –help – Viz nápověda pro příkaz (stejné jako výše)
    git -h – Viz stručný přehled možností
    git help –all – Vypíše všechny možné příkazy Gitu
    git help -g – Vypíše průvodce a koncepty
    Viz nápověda pro konkrétní příkaz (git help )
    Zobrazí celou manuálovou stránku pro konkrétní příkaz, včetně všech možností a příkladů:

    Příklad: Viz nápověda pro Commit
    git help commit
    GIT-COMMIT(1)
    NÁZEV
    git-commit – Zaznamená změny do repozitáře
    SYNOPSIS
    git commit [možnosti] [–] …
    POPIS
    Uloží aktuální obsah indexu do nového commitu
    spolu se zprávou protokolu od uživatele s popisem změn.

    Tento příkaz otevře celou dokumentaci k git commit ve vašem terminálu.

    Tip: Při prohlížení stránek nápovědy:
    Používejte klávesy se šipkami nebo mezerník pro posun dolů, b pro posun nahoru.
    Zadejte / následované slovem, které chcete vyhledat (např. /option), a poté n pro další shodu.
    Stisknutím q kdykoli ukončíte zobrazení nápovědy.
    Viz Nápověda k –help (git –help)
    Toto dělá totéž jako git help . Většina uživatelů preferuje tento tvar:

    Příklad: Viz Nápověda k příkazu Status
    git status –help
    GIT-STATUS(1)
    NÁZEV
    git-status – Zobrazí stav pracovního stromu
    SYNOPSIS
    git status [možnosti] [–] [specifikace cesty…]
    POPIS
    Zobrazí cesty, které se liší mezi indexovým souborem a aktuálním HEAD commitem.

    Tento příkaz otevře manuálovou stránku pro git status.

    Stručný přehled s -h (git -h)
    Zobrazí krátký přehled možností příkazu přímo v terminálovém okně (neotevře kompletní manuál):

    Příklad: Rychlá nápověda pro Add
    git add -h
    použití: git add [možnosti] [–] …
    -n, –dry-run dry run
    -v, –verbose podrobný popis
    -i, –interactive interaktivní výběr
    -p, –patch interaktivně vybírá položky
    -e, –edit upravit aktuální rozdíl a použít
    -u, –update aktualizovat sledované soubory
    -A, –all přidat změny ze všech sledovaných a nesledovaných souborů

    Tento příkaz vám poskytne stručný přehled dostupných možností pro příkaz.

    Vypsat všechny příkazy Gitu (git help –all)
    Vypíše všechny příkazy Gitu dostupné ve vašem systému, seskupené podle kategorie:

    Varování: Zobrazí se velmi dlouhý seznam příkazů

    Příklad
    $ git help –all
    Viz ‚git help‘ pro informace o konkrétním dílčím příkazu

    Hlavní příkazy Porcelain

    add Přidat obsah souboru do indexu
    am Použít sérii záplat z poštovní schránky
    archive Vytvořit archiv souborů z pojmenovaného stromu
    bisect Použít binární vyhledávání k nalezení commitu, který zavedl chybu
    branch Vypsat, vytvořit nebo odstranit větve
    bundle Přesunout objekty a reference podle archivu
    checkout Přepnout větve nebo obnovit soubory pracovního stromu
    cherry-pick Použít změny zavedené některými existujícími commity
    citool Grafická alternativa k git-commit
    clean Odebrat nesledované soubory z pracovního stromu
    clone Klonovat repozitář do nového adresáře
    commit Zaznamenat změny v repozitáři
    describe Dát objektu lidsky čitelný název na základě dostupné reference
    diff Zobrazení změn mezi commity, commitem a pracovním stromem atd.
    fetch Stahování objektů a referencí z jiného repozitář format-patch Příprava záplat pro odeslání e-mailem gc Vyčištění nepotřebných souborů a optimalizace lokálního repozitáře gitk Prohlížeč repozitářů Git grep Výpis řádků odpovídajících vzoru gui Přenosné grafické rozhraní pro Git init Vytvoření prázdného repozitáře Git nebo reinicializace existujícího log Zobrazení protokolů commitů maintenance Spuštění úloh pro optimalizaci dat repozitáře Git merge Spojení dvou nebo více historií vývoje mv Přesunutí nebo přejmenování souboru, adresáře nebo symbolického odkazu notes Přidání nebo kontrola objektu notes pull Načtení z jiného repozitáře nebo lokální větve a integrace s ním push Aktualizace vzdálených referencí spolu s přidruženými objekty range-diff Porovnání dvou rozsahů commitů (např. dvou verzí větve) rebase Znovu použití commitů na jiný základní tip reset Obnovení aktuálního HEAD do zadaného stavu restore Obnovení souborů pracovního stromu revert Vrácení některých existujících commitů rm Odebrání souborů z pracovního stromu a z indexu shortlog Shrnutí výstupu ‚git log‘ show Zobrazit vario

    Co je větev Gitu?
    V Gitu je větev jako samostatný pracovní prostor, kde můžete provádět změny a zkoušet nové nápady, aniž byste ovlivnili hlavní projekt. Představte si ji jako „paralelní vesmír“ pro váš kód.

    Proč používat větve?
    Větve vám umožňují pracovat na různých částech projektu, jako jsou nové funkce nebo opravy chyb, aniž byste zasahovali do hlavní větve.

    Běžné důvody pro vytvoření větve
    Vývoj nové funkce
    Oprava chyby
    Experimentování s nápady
    Příklad: S Gitem a bez Gitu
    Řekněme, že máte velký projekt a potřebujete aktualizovat jeho design.

    Jak by to fungovalo bez Gitu a s Gitem:

    Bez Gitu:
    Vytvořte kopie všech relevantních souborů, abyste předešli ovlivnění živé verze
    Začněte pracovat s designem a zjistěte, že kód závisí na kódu v jiných souborech, které je také třeba změnit!
    Vytvořte také kopie závislých souborů. Ujistěte se, že každá závislost souboru odkazuje na správný název souboru
    NOUZOVÉ! V projektu je někde jinde nesouvisející chyba, kterou je třeba co nejdříve opravit!

    Uložte si všechny soubory a poznamenejte si názvy kopií, na kterých jste pracovali.
    Pracujte na nesouvisející chybě a aktualizujte kód, abyste ji opravili.
    Vraťte se k návrhu a dokončete práci tam.
    Zkopírujte kód nebo přejmenujte soubory tak, aby aktualizovaný návrh byl v živé verzi.
    (o 2 týdny později si uvědomíte, že nesouvisející chyba nebyla v nové verzi návrhu opravena, protože jste soubory zkopírovali před opravou).
    S Gitem:
    S novou větví s názvem new-design upravte kód přímo, aniž byste ovlivnili hlavní větev.
    NOUZOVÝ STAV! V projektu je někde jinde nesouvisející chyba, kterou je třeba co nejdříve opravit!
    Vytvořte novou větev z hlavního projektu s názvem small-error-fix
    Opravte nesouvisející chybu a sloučte větev small-error-fix s hlavní větví
    Vrátíte se do větve new-design a dokončíte práci tam
    Sloučíte větev new-design s hlavní větví (a budete upozorněni na opravu malé chyby, kterou jste zmeškali)
    Větve vám umožňují pracovat na různých částech projektu, aniž by to ovlivnilo hlavní větev.

    Po dokončení práce lze větev sloučit s hlavním projektem.

    Můžete dokonce přepínat mezi větvemi a pracovat na různých projektech, aniž by se vzájemně rušily.

    Větvení v Gitu je velmi snadné a rychlé!

    Vytvoření nové větve
    Řekněme, že chcete přidat novou funkci. Můžete pro ni vytvořit novou větev.

    Přidejme několik nových funkcí na naši stránku index.html.

    Pracujeme v našem lokálním repozitáři a nechceme narušit nebo případně zničit hlavní projekt.

    Takže vytvoříme novou větev:

    Příklad
    git branch hello-world-images
    Nyní jsme vytvořili novou větev s názvem „hello-world-images“

    Výpis všech větví
    Potvrdíme, že jsme vytvořili novou větev.

    Pro zobrazení všech větví ve vašem repozitáři použijte:

    Příklad
    git branch
    hello-world-images

    • master
      Novou větev vidíme s názvem „hello-world-images“, ale * vedle master určuje, že se na této větvi aktuálně nacházíme.

    Přepínání mezi větvemi
    checkout je příkaz používaný k checkoutu větve.

    Přesune nás z aktuální větve do větve uvedené na konci příkazu:

    Příklad
    git checkout hello-world-images
    Přepnuto na větev ‚hello-world-images‘
    Nyní můžete pracovat ve své nové větvi, aniž byste ovlivnili hlavní větev.

    Práce ve větvi
    Nyní jsme přesunuli náš aktuální pracovní prostor z větve master do nové větve

    Otevřete svůj oblíbený editor a proveďte nějaké změny.

    V tomto příkladu jsme do pracovní složky přidali obrázek (img_hello_world.jpg) a do souboru index.html řádek kódu:

    Příklad


    Ahoj světe!

    Ahoj světe!

    Ahoj světe z vesmíru

    Toto je první soubor v mém novém Git repozitáři.

    Nový řádek v našem souboru!



    Provedli jsme změny v souboru a přidali nový soubor do pracovního adresáře (stejný adresář jako hlavní větev).

    Nyní zkontrolujte stav aktuální větve:

    Příklad
    git status
    Na větvi hello-world-images
    Změny nebyly připraveny pro commit:
    (použijte „git add …“ k aktualizaci toho, co bude commitováno)
    (použijte „git restore …“ k zahození změn v pracovním adresáři)
    upraveno: index.html

    Nesledované soubory:
    (použijte „git add …“ k zahrnutí do toho, co bude commitováno)
    img_hello_world.jpg

    žádné změny nebyly přidány do commitu (použijte „git add“ a/nebo „git commit -a“)
    Pojďme si tedy projít, co se zde děje:

    V našem souboru index.html došlo ke změnám, ale soubor není připraven pro commit
    img_hello_world.jpg není sledován
    Takže musíme oba soubory přidat do pracovního prostředí pro tuto větev:

    Příklad
    git add –all
    Použití –all místo jednotlivých názvů souborů připraví všechny změněné (nové, upravené a smazané) soubory.

    Zkontrolujte stav větve:

    Příklad
    git status
    Na větvi hello-world-images
    Změny k potvrzení:
    (použijte „git restore –staged …“ k odstranění z větve)
    nový soubor: img_hello_world.jpg
    upraveno:

    Co je slučování v Gitu?
    Slučování v Gitu znamená kombinování změn z jedné větve do druhé.

    Takto sjednotíte svou práci po samostatné práci na různých funkcích nebo opravách chyb.

    Běžné možnosti slučování v Gitu
    git merge – Sloučit větev do vaší aktuální větve
    git merge –no-ff – Vždy vytvořit commit sloučení
    git merge –squash – Sloučit změny do jednoho commitu
    git merge –abort – Zrušit probíhající slučování
    Slučování větví (git merge)
    Chcete-li kombinovat změny z jedné větve do druhé, použijte git merge.

    Obvykle nejprve přepnete na větev, do které chcete sloučit (často main nebo master), a poté spusťte příkaz merge s názvem větve, do které chcete sloučit.

    Nejprve se musíme přepnout na větev master:

    Příklad
    git checkout master
    Přepnuto na větev ‚master‘
    Nyní sloučíme aktuální větev (master) s emergency-fix:

    Příklad
    git merge emergency-fix
    Aktualizace 09f4acd..dfa79db
    Přesun vpřed
    index.html | 2 +-
    1 soubor změněn, 1 vložení(+), 1 smazání(-)
    Protože větev emergency-fix pochází přímo z master a během naší práce nebyly v master provedeny žádné další změny, Git to vnímá jako pokračování master.

    Může se tedy „přesunovat vpřed“, pouze ukazuje master i emergency-fix na stejný commit.

    Osvědčené postupy pro slučování větví
    Před zahájením slučování vždy proveďte commit nebo uložení změn.
    Pravidelně slučujte z větve main do větve feature, abyste minimalizovali konflikty.
    Pečlivě si přečtěte a vyřešte konflikty – nepřijímejte všechny změny slepě.
    Pište jasné a popisné zprávy o sloučení (merge commitu).
    Praktické příklady
    Přerušení sloučení: git merge –abort
    Zkontrolujte stav během sloučení: git status
    Vyřešte konflikt a dokončete sloučení: Upravte konfliktní soubor (soubory), poté git add file a git commit
    Rychlé sloučení vpřed: Probíhá, když se žádné nové commity nerozdělily – Git pouze přesune ukazatel větve vpřed.
    Bez rychlého sloučení vpřed: Použijte git merge –no-ff branch pro vždy vytvoření sloučeného commitu a zachování historie větví.
    Protože master a emergency-fix jsou nyní v podstatě stejné, můžeme emergency-fix smazat, protože již není potřeba:

    Příklad
    git branch -d emergency-fix
    Smazána větev emergency-fix (byla dfa79db).

    Sloučení bez rychlého přehrávání vpřed (git merge –no-ff)
    Ve výchozím nastavení, pokud lze vaši větev sloučit s rychlým přehráváním vpřed (žádné nové commity na základně), Git pouze přesune ukazatel větve dopředu.

    Pokud chcete vždy vytvořit commit pro sloučení (aby byla historie přehlednější), použijte git merge –no-ff název_větve.

    Příklad
    git merge –no-ff feature-branch
    Sloučení provedené „rekurzivní“ strategií.
    index.html | 2 +-
    1 soubor změněn, 1 vložení(+), 1 smazání(-)
    Squash Merge (git merge –squash)
    Pokud chcete sloučit všechny změny z větve do jednoho commitu (místo uchování každého commitu), použijte git merge –squash název_větve.

    To je užitečné pro vyčištění historie commitu před sloučením.

    Příklad
    git merge –squash feature-branch
    Squash commit — neaktualizuje se HEAD
    Automatické sloučení proběhlo dobře; zastaveno před potvrzením změn dle požadavku
    Přerušení sloučení (git merge –abort)
    Pokud během sloučení narazíte na problém (například na konflikt, který nechcete vyřešit), můžete sloučení zrušit a vrátit se k předchozímu stavu pomocí příkazu git merge –abort.

    Příklad
    git merge –abort
    Co je to konflikt sloučení?
    Konflikt sloučení nastává, když se změny ve dvou větvích dotknou stejné části souboru a Git neví, kterou verzi si má ponechat.

    Představte si to jako dva lidi, kteří upravují stejnou větu v dokumentu různými způsoby – Git potřebuje vaši pomoc s rozhodnutím, kterou verzi použít.

    Jak vyřešit konflikt sloučení
    Git označí konflikt ve vašem souboru.

    Soubor musíte otevřít, vyhledat řádky jako <<<<<<< HEAD a ======= a rozhodnout se, jaká by měla být finální verze.

    Poté připravte a potvrďte změny.

    Řešení problémů a tipy
    Pokud chcete sloučení zrušit, použijte příkaz git merge –abort.
    Před zahájením slučování vždy proveďte potvrzení (commit) nebo uložení změn.
    Pečlivě si přečtěte značky konfliktů a po vyřešení problému je odstraňte.
    Pomocí příkazu git status zjistěte, které soubory vyžadují vaši pozornost.
    Pokud si nejste jisti, zeptejte se kolegy nebo si vyhledejte chybovou zprávu.
    Příklad konfliktu sloučení
    Nyní se můžeme přesunout k souboru hello-world-images z minulé kapitoly a pokračovat v práci.

    Přidejte další soubor s obrázkem (img_hello_git.jpg) a změňte index.html, aby se zobrazoval:

    Příklad
    git checkout hello-world-images
    Přepnuto na větev ‚hello-world-images‘
    Příklad


    Ahoj světe!

    Ahoj světe!

    Ahoj světe z vesmíru

    Toto je první soubor v mém novém Git repozitáři.

    Nový řádek v našem souboru!

    Ahoj Git



    Nyní jsme s naší prací hotovi a můžeme připravit a commitovat tuto větev:

    Příklad
    git add –all
    git commit -m „přidán nový obrázek“
    [hello-world-images 1f1584e] přidán nový obrázek
    2 soubory změněny, 1 vložen

    Přehled příkazů Git Workflow
    Pracovní adresář – Místo, kde provádíte změny
    git add – Připravování změn do fáze
    git commit – Ukládání změn do repozitáře
    git push – Sdílení změn s ostatními
    git status – Kontrola aktuálního stavu
    Undo/Amend – Oprava chyb (git restore, git reset, git commit –amend)
    Viz také: GitHub Flow je oblíbený kolaborativní workflow pro týmy používající GitHub.

    Pokud pracujete s GitLab nebo Bitbucket, tyto platformy mají také své vlastní workflow. Zjistěte více o GitHub Flow »

    Pochopení workflowu Git
    Git používá distribuovaný workflow, který vám umožňuje pracovat na vašem kódu, připravovat změny a potvrzovat je do vašeho lokálního repozitáře před sdílením s ostatními.

    Pochopení tohoto workflow je nezbytné pro efektivní správu verzí.

    Tři oblasti Gitu
    Pracovní adresář: Místo, kde provádíte změny ve vašich souborech.
    Oblast přípravy (index): Místo, kde připravujete změny před potvrzením.
    Repozitář: Místo, kde je uložena historie potvrzení.
    Diagram pracovního postupu
    [Pracovní adresář] –git add–> [Oblast přípravy] –git commit–> [Repozitář]

    Nejlepší postupy pro pracovní postup Git
    Často se commitujte s jasnými a smysluplnými zprávami.
    Často kontrolujte svůj stav pomocí git status, abyste se vyhnuli překvapením.
    Připravujte pouze to, co chcete commitovat. Pro přesnost použijte git add .
    Pravidelně odesílejte soubory, abyste si je mohli zálohovat a sdílet s ostatními.
    Před potvrzením změn zkontrolujte změny pomocí git diff.

    Pracovní adresář
    Zde provádíte změny ve svých souborech.

    Představte si to jako svůj pracovní prostor nebo stůl.

    Soubory zde mohou být nové, upravené nebo smazané, ale Git tyto změny neuloží, dokud je nepřipravíte a nepotvrdíte.

    Připravování změn (git add)
    Když jste se změnami spokojeni, „připravíte“ je pomocí git add.

    Tím se vaše změny umístí do oblasti přípravy, jako byste vložili hotový dopis do obálky.

    Příklad
    git add index.html
    Pro přidání všech změn (nových, upravených a smazaných souborů):

    git add .
    Potvrzení změn (git commit)
    Potvrzení uloží vaše upravené změny do vašeho lokálního repozitáře.

    Je to jako odeslání dopisu poštou – po odeslání jej již nelze změnit!

    Příklad
    git commit -m „Popište své změny“
    Můžete také použít git commit -a -m „message“ k přidání a potvrzení všech upravených a smazaných souborů v jednom kroku (ale ne nových souborů).

    Odeslání změn (git push)
    Po potvrzení jsou vaše změny pouze ve vašem lokálním repozitáři.

    Pomocí git push odešlete své commity do vzdáleného repozitáře (jako je GitHub nebo Bitbucket), aby je ostatní mohli vidět.

    Příklad
    git push
    Kontrola stavu (git status)
    Pomocí git status zjistěte, které soubory jsou připraveny, nestagovány nebo nesledovány.

    To vám pomůže sledovat, co ještě potřebujete přidat nebo potvrdit.

    Příklad
    git status
    Vrácení a úprava změn
    Udělali jste chybu? Git vám umožňuje opravit věci před odesláním!

    git restore – Vrátí změny ve vašem pracovním adresáři (před přidáním do stagingové oblasti).
    git restore –staged – Zruší přidání souboru (přesune ho mimo stagingovou oblast).
    git reset HEAD~ – Vrátí zpět poslední commit (uchová změny ve vašem pracovním adresáři).
    git commit –amend – Změní poslední zprávu commitu nebo přidá soubory do posledního commitu.
    Příklad: Zrušení přidání souboru do stagingové oblasti
    git restore –staged index.html
    Tipy a řešení problémů
    Používejte git status často, abyste viděli, co se děje.
    Pokud commitujete něco špatného, ​​použijte git reset nebo git commit –amend před přidáním.
    Připravujte pouze to, co chcete commitovat – pro konkrétní soubory použijte git add .
    Nezapomeňte po commitu odeslat změny, jinak se vaše změny nezobrazí ostatním.
    Pokud si nejste jisti, požádejte o pomoc nebo si vyhledejte chybovou zprávu – každý dělá chyby!

    Souhrn osvědčených postupů pro Gity
    Často commitovat
    Pište jasné commit zprávy
    Používejte větve
    Před odesláním stahujte
    Před commitem kontrolujte změny
    Udržujte malé repozitáře
    Používejte .gitignore
    Vydání tagů
    Často commitovat
    Vytvářejte malé, časté commity pro zaznamenávání vašeho pokroku.

    To usnadňuje sledování změn a hledání chyb.

    Příklad
    git add .
    git commit -m „Přidat logiku ověřování uživatelů“
    Pište jasné commit zprávy
    Používejte popisné zprávy, které vysvětlují, proč byla změna provedena, ne jen co se změnilo.

    Dobré commit zprávy vám a vašemu týmu pomohou pochopit historii projektu.

    Buďte konkrétní: Řekněte co a proč, ne jen „Aktualizovat“ nebo „Opravit“.
    Používejte rozkazovací způsob: Například „Přidat ověření přihlášení“ místo „Přidáno ověření přihlášení“.
    Příklad
    git commit -m „Opravit chybu v ověření přihlášení uživatele“

    Používejte větve
    Vytvářejte větve pro funkce, opravy a experimenty, abyste udrželi vaši hlavní větev stabilní.

    Tímto způsobem můžete pracovat na nových nápadech, aniž byste ovlivnili hlavní kódovou základnu.

    Proč? Větve vám umožňují testovat a vyvíjet nezávisle a zvyšují bezpečnost spolupráce.
    Jasně pojmenujte větve: Například feature/login-form nebo bugfix/user-auth.
    Příklad
    git checkout -b feature/login-form
    Pull Before You Push
    Před odesláním vždy použijte git pull.

    Tím se aktualizuje vaše lokální větev o změny od ostatních, pomůže se vyhnout konfliktům a zajistí se, že vaše odeslání bude úspěšné.

    Proč? Pokud od vašeho posledního odeslání změn odeslal někdo jiný, vaše odeslání může být odmítnuto nebo způsobit konflikty.

    Před odesláním použijte příkaz pull first.

    Příklad
    git pull origin main
    git push origin main
    Zkontrolujte změny před potvrzením
    Použijte git status a git diff ke kontrole změn před potvrzením.

    To vám pomůže včas odhalit chyby.

    Příklad
    git status
    git diff
    Udržujte repozitáře malé
    Vyhněte se přidávání velkých souborů nebo zbytečných závislostí.

    Díky tomu bude váš repozitář rychlý a snadno klonovatelný.

    Tip: Pro velké soubory (jako jsou videa nebo datové sady) použijte Git LFS (Large File Storage) namísto jejich přímého přidávání do repozitáře.
    Použijte .gitignore
    Vyloučte soubory, které by neměly být sledovány (jako jsou artefakty sestavení, soubory protokolů nebo tajné kódy), jejich přidáním do souboru .gitignore.

    Poznámka: .gitignore zabraňuje sledování pouze nových souborů.

    Soubory, které již Git sleduje, zůstanou v repozitáři, dokud je neodstraníte pomocí git rm –cached .

    Příklad: .gitignore

    .gitignore

    node_modules/
    *.log
    .env
    Označení vydání
    Používejte značky k označení bodů vydání (jako v1.0), abyste mohli snadno najít a odkazovat na důležité verze.

    To vám pomůže sledovat historii vašeho projektu a v případě potřeby usnadní návrat k předchozím verzím.

    Příklad
    git tag v1.0
    git push origin v1.0
    Poznámka: Dobré návyky v Gitu usnadňují vašemu týmu (a vám budoucímu já) pochopení vaší práce a její další rozvoj.

    Glosář Git
    Tento glosář zahrnuje běžné termíny a koncepty Gitu. Používejte jej jako praktickou referenci při učení se a práci s Gitem.

    Shrnutí termínů Gitu
    Větev
    Rezervace
    Klonování
    Kommit
    Konflikt
    Načtení
    Fork
    HEAD
    Index (oblast přípravy)
    Sloučení
    Původ
    Načtení
    Odeslání
    Rebase
    Vzdálené
    Repozitář (Repo)
    Stash
    Tag
    Upstream
    Pracovní adresář
    Větev
    Větev je paralelní verze vašeho repozitáře. Používá se k nezávislému vývoji funkcí.

    Více se dozvíte na naší stránce Větev Git

    Příklad
    funkce/přihlášení větve git
    Rezervace
    Přepnutí na jinou větev nebo commit.

    Více se dozvíte na naší stránce Checkout Git

    Příklad
    git checkout main

    Klonování
    Vytvoření lokální kopie vzdáleného repozitáře.

    Více se dozvíte na naší stránce Git Clone

    Příklad
    git clone https://github.com/user/repo.git
    Commit
    Snímek vašich změn v repozitáři.

    Více se dozvíte na naší stránce Git Commit

    Příklad
    git commit -m „Přidat funkci přihlášení“
    Konflikt
    Když Git nemůže automaticky sloučit změny z různých commitů nebo větví. Rozdíly musíte vyřešit ručně.

    Více se dozvíte na naší stránce Git Branch Merge

    Příklad

    Příklad: Zpráva o konfliktu sloučení

    KONFLIKT (obsah): Konflikt sloučení v souboru file.txt

    Fetch
    Stažení změn ze vzdáleného repozitáře bez sloučení.

    Více se dozvíte na naší stránce Git Pull from Remote

    Příklad
    git fetch origin
    Fork
    Osobní kopie repozitáře někoho jiného, ​​obvykle na platformě jako GitHub.

    Více se dozvíte na naší stránce Git Remote Fork

    Příklad

    Použití rozhraní GitHub k vytvoření forku repozitáře

    Index (oblast pro přípravu)
    Index (nazývaný také oblast pro přípravu) je místo, kde se připravují změny před potvrzením (commitem).

    Více se dozvíte na naší stránce Git Staging Area

    Příklad
    git add file.txt
    Merge
    Sloučení změn z různých větví.

    Více se dozvíte na naší stránce Git Merge

    Příklad
    git merge feature/login
    Origin
    Výchozí název vašeho hlavního vzdáleného repozitáře. V případě potřeby můžete repozitář přejmenovat nebo jich mít více.

    Více se dozvíte na naší stránce Git Remote

    Příklad
    git remote add origin https://github.com/user/repo.git
    Pull
    Načtení a sloučení změn ze vzdáleného repozitáře.

    Více se dozvíte na naší stránce Git Pull from Remote

    Příklad
    git pull origin main
    Push
    Nahrání vašich commitů do vzdáleného repozitáře.

    Více se dozvíte na naší stránce Git Push to Remote

    Příklad
    git push origin main
    Rebase
    Přesunutí nebo sloučení sekvence commitů do nového základního commitu.

    Více se dozvíte na naší stránce Git Rebase

    Příklad
    git rebase main
    Remote
    Verze vašeho repozitáře hostovaná na internetu nebo v síti.

    Více se dozvíte na naší stránce Git Set Remote

    Příklad
    git remote -v
    Repozitář (Repo)
    Databáze, kde je uložena historie vašeho projektu.

    Více se dozvíte na naší stránce Git Get Get Started

    Příklad
    git init
    Stash
    Dočasné uložení změn, které nejsou připraveny k commitu.

    Více se dozvíte na naší stránce Git Stash

    Příklad
    git stash
    Tag
    Označení konkrétního commitu jako důležitého, obvykle pro vydání.

    Více se dozvíte na naší stránce Git Tag

    Příklad
    git tag v1.0
    Poznámka: Kdykoli narazíte na neznámý termín z Gitu, podívejte se na tento glosář!

    HEAD
    HEAD je odkaz na aktuální commit, na kterém je založen váš pracovní adresář. Obvykle ukazuje na nejnovější commit ve vaší aktuální větvi.

    Příklad
    git log –oneline

    První položka je HEAD

    Upstream
    Větev „upstream“ je výchozí větev, kterou vaše větev sleduje a z níž stahuje data, obvykle na vzdáleném repozitáři.

    Příklad
    git push –set-upstream origin main

    Začínáme s GitHubem
    Vítejte! Tato stránka vás provede prvními kroky používání GitHubu pro správu verzí a spolupráci.

    1. Registrace na GitHubu
      Přejděte na GitHub a vytvořte si bezplatný účet:

    Snímek obrazovky zobrazující registrační stránku GitHubu

    Poznámka: Použijte stejnou e-mailovou adresu, kterou plánujete použít pro konfiguraci Gitu.

    1. Vytvoření repozitáře
      Po přihlášení klikněte na tlačítko Nový a vytvořte nový repozitář:

    Snímek obrazovky zobrazující, jak vytvořit nový repozitář na GitHubu

    Vyplňte podrobnosti o repozitáři (název, popis, veřejné/soukromé atd.) a klikněte na Vytvořit repozitář:

    Snímek obrazovky zobrazující formulář pro vytvoření nového repozitáře na GitHubu

    1. Co je to vzdálený repozitář?
      Vzdálený repozitář je verze vašeho projektu hostovaná na internetu. GitHub je oblíbená platforma pro hostování vzdálených repozitářů, která vám umožňuje spolupracovat s ostatními a zálohovat váš kód.

    Dále se naučíte, jak bezpečně připojit počítač ke GitHubu pomocí SSH.

    Co je SSH?
    SSH (Secure Shell) je způsob bezpečného připojení ke vzdáleným počítačům a službám, jako jsou repozitáře Git.

    SSH používá dvojici klíčů (veřejný a soukromý), aby se zajistilo, že k vašemu kódu máte přístup pouze vy.

    Shrnutí konceptů a příkazů SSH
    Pár klíčů SSH – Veřejný a soukromý klíč pro bezpečný přístup
    ssh-keygen – Generování nového páru klíčů SSH
    ssh-add – Přidání vašeho soukromého klíče k agentovi SSH
    ssh -T git@github.com – Testování připojení SSH
    ssh-add -l – Zobrazení seznamu načtených klíčů SSH
    ssh-add -d – Odebrání klíče z agenta
    Jak fungují klíče SSH
    Klíče SSH se dodávají v párech: veřejný klíč (jako zámek) a soukromý klíč (jako váš vlastní klíč).

    Veřejný klíč sdílíte se serverem (jako GitHub nebo Bitbucket), ale soukromý klíč bezpečně uchováváte ve svém počítači.

    Pouze někdo se soukromým klíčem má přístup k tomu, co je uzamčeno veřejným klíčem.

    První nastavení klíče SSH
    Pokud jste klíče SSH nikdy předtím nepoužívali, postupujte podle tohoto kroku a povolte agenta SSH ve svém operačním systému:

    Příklad: Povolení agenta SSH
    eval $(ssh-agent -s)
    Generování páru klíčů SSH
    Chcete-li vytvořit nový pár klíčů SSH, použijte tento příkaz v terminálu (Linux, macOS nebo Git Bash pro Windows):

    Příklad: Generování klíče SSH
    ssh-keygen -t rsa -b 4096 -C „vase@email.com“
    Postupujte podle pokynů a vyberte umístění souboru (stisknutím klávesy Enter použijte výchozí nastavení) a nastavte heslo (volitelné, ale doporučené pro větší zabezpečení).

    Přidání klíče k SSH agentovi
    Po vytvoření klíče jej přidejte k SSH agentovi, aby ho Git mohl použít:

    Příklad: Přidání klíče k SSH agentovi
    ssh-add ~/.ssh/id_rsa

    Kopírování veřejného klíče
    Chcete-li používat SSH s hostingovými službami Git, musíte zkopírovat svůj veřejný klíč a přidat ho do nastavení svého účtu na GitHubu, GitLabu nebo Bitbucketu.

    V systému macOS: pbcopy < ~/.ssh/id_rsa.pub
    V systému Windows (Git Bash): clip < ~/.ssh/id_rsa.pub
    V systému Linux: cat ~/.ssh/id_rsa.pub (poté zkopírujte ručně)
    Výpis a odebrání klíčů SSH
    Zjistěte, které klíče jsou načteny ve vašem agentovi SSH:

    Příklad: Výpis načtených klíčů SSH
    ssh-add -l
    Odebrání klíče z agenta:

    Příklad: Odebrání klíče SSH z agenta
    ssh-add -d ~/.ssh/id_rsa
    Řešení problémů s SSH
    Pokud se zobrazí zpráva „Oprávnění odepřeno“, ujistěte se, že váš veřejný klíč je přidán do vašeho hostitele Git a váš soukromý klíč je načten v agentu.
    Zkontrolujte oprávnění k souborům: soukromé klíče by měly být čitelné pouze pro vás (chmod 600 ~/.ssh/id_rsa).
    Pro ladění problémů použijte ssh -v pro podrobný výstup.
    Ujistěte se, že pro vzdálené připojení používáte správnou SSH URL adresu (začíná na git@).

    Tip: Nikdy s nikým nesdílejte svůj soukromý klíč. Pro větší zabezpečení použijte heslo.

    Pokud je váš soukromý klíč někdy odhalen, vygenerujte nový pár klíčů a okamžitě aktualizujte hosting Git.

    Přidání SSH do GitHubu
    Nyní, když jste si vygenerovali klíč SSH, je třeba přidat veřejný klíč do vašeho účtu GitHub.

    Zkopírujte svůj veřejný klíč SSH
    Ve Windows (Git Bash): clip < ~/.ssh/id_rsa.pub
    V macOS: pbcopy < ~/.ssh/id_rsa.pub
    V Linuxu: cat ~/.ssh/id_rsa.pub (poté zkopírujte ručně)
    Důležité: Před pokusem o odeslání, stažení nebo klonování pomocí SSH dokončete tyto kroky. Tato stránka předpokládá, že jste již klíč SSH vygenerovali a přidali ho do svého agenta SSH. Pokud ne, vraťte se do části nastavení SSH v příručce Začínáme.

    Přidání klíče do GitHubu
    Přejděte na GitHub, klikněte na svůj profil v pravém horním rohu a vyberte Nastavení:
    Nastavení profilu GitHubu

    V postranním panelu vyberte Klíče SSH a GPG a klikněte na tlačítko Nový klíč SSH.
    Nastavení profilu GitHub SSH

    Dejte klíči popisný název, vložte svůj veřejný klíč SSH do pole „Klíč“ a klikněte na Přidat klíč SSH.

    Nastavení profilu GitHub SSH Přidat klíč

    Můžete být vyzváni k zadání hesla GitHub nebo k potvrzení přidání pomocí 2FA.

    V seznamu uvidíte svůj nový klíč SSH:

    Nastavení profilu GitHub SSH Přidaný klíč

    Dále otestujete připojení SSH a nastavíte vzdálený zdroj GitHub pomocí SSH.

    Nastavení vzdáleného původu GitHubu
    Nyní, když je váš SSH klíč přidán do GitHubu, můžete bezpečně připojit svůj lokální repozitář k GitHubu pomocí SSH.

    Otestujte své SSH připojení
    Nejprve otestujte, zda vaše SSH připojení k GitHubu funguje:

    Příklad
    ssh -T git@github.com
    Autenticitu hostitele ‚github.com (140.82.121.3)‘ nelze ověřit.
    Otisk klíče RSA je SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
    Jste si jisti, že chcete pokračovat v připojování (ano/ne/[otisk])? ano
    Varování: ‚github.com,140.82.121.3‘ (RSA) trvale přidán do seznamu známých hostitelů.
    Ahoj vaše-uživatelské-jméno! Úspěšně jste se ověřili, ale GitHub neposkytuje přístup k shellu.
    Pokud poslední řádek obsahuje vaše uživatelské jméno na GitHubu, jste úspěšně ověřeni!

    Získejte SSH adresu svého repozitáře
    Na GitHubu přejděte do svého repozitáře a klikněte na tlačítko Kód. Ujistěte se, že je vybrána možnost SSH, a poté zkopírujte URL adresu SSH (začíná na git@github.com:):

    GitHub Získání SSH kódu

    Přidání nebo aktualizace vzdáleného zdroje
    Přidání vzdáleného zdroje (poprvé):

    Příklad
    git remote add origin git@github.com:vaše-uživatelské-jméno/vaše-repozitář.git
    Aktualizace existujícího vzdáleného zdroje pro použití SSH:

    Příklad
    git remote set-url origin git@github.com:vaše-uživatelské-jméno/vaše-repozitář.git
    Gratulujeme! Nyní jste připraveni používat GitHub s SSH.

    Úprava kódu na GitHubu
    GitHub umožňuje upravovat soubory přímo v prohlížeči.

    To je užitečné pro rychlé změny bez nutnosti používat Git na počítači.

    Úprava libovolného souboru
    Chcete-li upravit soubor (například README.md), klikněte na název souboru ve vašem repozitáři a poté klikněte na tlačítko Upravit (ikona tužky):

    Upravit soubor na GitHubu

    Nyní můžete v souboru provádět změny v editoru. Můžete upravovat libovolný soubor, nejen README.md.

    Napište zprávu o potvrzení
    Po úpravě přejděte dolů do sekce Změny potvrzení.

    Do pole zprávy o potvrzení přidejte krátký a jasný popis toho, co jste změnili.

    To pomůže ostatním pochopit vaši aktualizaci. Další informace o potvrzeních

    Změny potvrzení na GitHubu

    Náhled změn
    Před uložením můžete kliknout na Náhled změn a zobrazit, co se v souboru změní.

    To vám pomůže zkontrolovat úpravy před potvrzením.

    Potvrzení do větve
    Ve výchozím nastavení můžete provést potvrzení přímo do hlavní (nebo hlavní) větve.

    Pro větší změny je nejlepší vytvořit novou větev.

    Vyberte možnost Vytvořit novou větev pro tento commit a spusťte pull request pro bezpečnou práci. Více informací o větvích

    Vytvoření nové větve z editoru
    Když se rozhodnete vytvořit novou větev, GitHub automaticky navrhne název větve.

    Po commitu můžete otevřít pull request a navrhnout své změny. Více informací o pull requestech

    Takto upravujete kód přímo v GitHubu!

    Stahování dat ze vzdáleného úložiště
    V posledních kapitolách jsme si vytvořili účet na GitHubu a nastavili SSH.

    Poté jsme provedli několik změn přímo na GitHubu.

    Nyní chceme aktualizovat náš lokální repozitář změnami z GitHubu.

    Klíčové příkazy pro stahování dat
    Fetch
    Merge
    Pull
    Fetch, Pull a Merge
    Při práci v týmu na projektu je důležité, aby všichni byli informováni o aktuálním stavu.

    Kdykoli začnete pracovat na projektu, měli byste si nejnovější změny přenést do své lokální kopie.

    S Gitem to můžete udělat pomocí příkazu pull.

    pull je kombinací 2 různých příkazů:

    fetch
    merge
    Pojďme se blíže podívat na to, jak fungují příkazy fetch, merge a pull.

    Git Fetch
    git fetch stahuje nová data ze vzdáleného repozitáře, ale nemění vaše pracovní soubory ani větve. Umožňuje vám vidět, co ostatní nahráli, než provedete sloučení nebo stahování dat.

    Příklad
    git fetch origin
    remote: Výčet objektů: 5, hotovo.
    remote: Počítání objektů: 100 % (5/5), hotovo.
    remote: Komprimace objektů: 100 % (3/3), hotovo.
    remote: Celkem 3 (delta 2), znovu použito 0 (delta 0), znovu použito zabaleno 0
    Rozbalování objektů: 100 % (3/3), 733 bajtů | 3,00 KiB/s, hotovo.
    Z https://github.com/w3schools-test/hello-world
    e0b6038..d29d69f master -> origin/master
    Nyní, když máme poslední změny, můžeme zkontrolovat náš stav:

    Příklad
    git status
    Na větvi master
    Vaše větev je o 1 commit za ‚origin/master‘ a lze ji rychle přetočit.
    (použijte „git pull“ pro aktualizaci vaší lokální větve)

    nic k commitu, funkční strom čistý
    Jsme o 1 commit za origin/master. To by měl být aktualizovaný soubor README.md, ale zkontrolujme to dvakrát v logu:

    Příklad
    git log origin/master
    commit d29d69ffe2ee9e6df6fa0d313bb0592b50f3b853 (origin/master)
    Autor: w3schools-test <77673807+w3schools-test@users.noreply.github.com>
    Datum: Pá 26. března 14:59:14 2021 +0100

    Soubor README.md byl aktualizován o řádek o GitHubu

    commit e0b6038b1345e50aca8885d8fd322fc0e5765c3b (HEAD -> master)
    Sloučení: dfa79db 1f1584e
    Autor: w3schools-test
    Datum: Pá 26. března 12:42:56 2021 +0100

    sloučeno s hello-world-images po opravě konfliktů



    To vypadá podle očekávání, ale můžeme si to také ověřit zobrazením rozdílů mezi naším lokálním masterem a origin/masterem:

    Příklad
    git diff origin/master
    diff –git a/README.md b/README.md
    index 23a0122..a980c39 100644
    — a/README.md
    +++ b/README.md
    @@ -2,6 +2,4 @@
    Repozitář Hello World pro tutoriál Git
    Toto je příklad repozitáře pro tutoriál Git na https://www.w3schools.com

    – Tento repozitář je krok za krokem vytvořen v tutoriálu.

    • Nyní obsahuje kroky pro GitHub
    • Tento repozitář je krok za krokem vytvořen v tutoriálu.
      \ Žádný nový řádek na konci souboru
      To vypadá přesně tak, jak se očekávalo! Nyní můžeme bezpečně sloučit.

    Git Merge
    merge kombinuje aktuální větev se zadanou větví.

    Potvrdili jsme, že aktualizace jsou podle očekávání a můžeme sloučit naši aktuální větev (master) s origin/master:

    Příklad
    git merge origin/master
    Aktualizace e0b6038..d29d69f
    Přetočení vpřed
    README.md | 4 +++-
    1 soubor změněn, 3 vložení(+), 1 smazání(-)
    Znovu zkontrolujte náš stav, abyste se ujistili, že jsme aktuální:

    Příklad
    git status
    Na větvi master
    Vaše větev je aktuální s ‚origin/master‘.

    není co commitovat, funguje čistý strom
    Hotovo! Váš lokální git je aktuální!

    Git Pull
    Ale co když chcete jen aktualizovat svůj lokální repozitář, aniž byste museli procházet všemi těmito kroky?

    pull je kombinací fetch a merge.

    Používá se k načtení všech změn ze vzdáleného repozitáře do větve, na které pracujete.

    Proveďte další změnu v souboru Readme.md na GitHubu.

    Aktualizace souboru Readme na GitHubu

    Použijte příkaz pull k aktualizaci našeho lokálního Gitu:

    Příklad
    git pull origin
    remote: Výčet objektů: 5, hotovo.
    remote: Počítání objektů: 100 % (5/5), hotovo.
    remote: Komprimace objektů: 100 % (3/3), hotovo.
    remote: Celkem 3 (delta 1), znovu použito 0 (delta 0), zabaleno a znovu použito 0
    Rozbalování objektů: 100 % (3/3), 794 bajtů | 1024 bajtů/s, hotovo.
    Z https://github.com/w3schools-test/hello-world a7cdd4b..ab6b4ed master -> origin/master
    Aktualizace a7cdd4b..ab6b4ed
    Přetočení vpřed README.md | 2 ++
    1 soubor změněn, 2 vložení (+)
    Takto udržujete svůj lokální Git aktuální ze vzdáleného repozitáře. V další kapitole se blíže podíváme na to, jak funguje push na GitHubu.

    Odeslání změn z Gitu na GitHub
    Po provedení lokálních změn chceme aktualizovat náš vzdálený repozitář těmito změnami.

    Přenos lokálních změn na vzdálený repozitář se provádí pomocí příkazu push.

    Existuje několik příkazů, které můžeme použít k odeslání změn na GitHub.

    Klávesa Příkazy pro odeslání změn
    Základní odeslání
    Vynucené odeslání
    Značky odeslání
    Řešení problémů
    Základní odeslání
    Tento příkaz odešle vaši aktuální větev do vzdáleného repozitáře s názvem origin:

    Příklad
    git push origin
    Tímto se nahrají vaše lokální commity na GitHub.

    Změny jste již museli odeslat pomocí git commit.

    Vynucené odeslání
    Pokud je vaše odeslání odmítnuto z důvodu aktualizací, které nepodporují rychlé přesměrování (například po rebase), můžete odeslání vynutit.

    Varování: Toto může přepsat změny ve vzdáleném repozitáři. Používejte opatrně!

    Příklad
    git push –force origin feature-branch
    Použijte –force-with-lease pro bezpečnější vynucené odeslání:

    Příklad
    git push –force-with-lease origin feature-branch
    Odeslání tagů
    Pro odeslání všech lokálních tagů na GitHub:

    Příklad
    git push –tags
    Pro odeslání konkrétního tagu:

    Příklad
    git push origin v1.0
    Řešení problémů
    Chyba nepřetáčení: Stane se, pokud do větve odeslal soubor někdo jiný. Před dalším odesláním spusťte git pull –rebase.
    Ověření selhalo: Ujistěte se, že máte přístup k repozitáři a že vaše přihlašovací údaje jsou správné.
    Přejděte na GitHub a ověřte, že repozitář má nový commit:

    GitHub Nový commit

    Nyní začneme pracovat na větvích na GitHubu.

    Vytvoření větve
    Na GitHubu přejděte do svého repozitáře a klikněte na tlačítko větve „master“.

    Zde můžete vytvořit novou větev. Zadejte popisný název a klikněte na Vytvořit větev:

    GitHub Vytvořit novou větev

    Větev by nyní měla být vytvořena a aktivní. Na které větvi pracujete můžete ověřit pohledem na tlačítko větve. Vidíte, že nyní ukazuje „html-skeleton“ místo „main“?

    GitHub Nová větev vytvořena

    Začněte pracovat na existujícím souboru v této větvi. Klikněte na soubor „index.html“ a začněte s úpravami:

    GitHub Upravit soubor

    Po dokončení úprav souboru můžete kliknout na kartu „Náhled změn“ a zobrazit zvýrazněné provedené změny:

    Náhled změn a potvrzení

    Pokud jste se změnou spokojeni, přidejte komentář, který vysvětluje, co jste udělali, a klikněte na Potvrdit změny.

    Nyní máte na GitHubu novou větev aktualizovanou o několik změn!

    Přepnout větev
    Chcete-li přepnout na jinou větev ve webovém rozhraní GitHubu, klikněte na rozbalovací nabídku větví a vyberte větev, na které chcete pracovat.

    Přepnout větve pomocí příkazového řádku:

    Příklad
    git switch název-větve
    Smazat větev
    Chcete-li smazat větev na GitHubu, přejděte na stránku větví, vyhledejte svou větev a klikněte na ikonu smazání (koš).

    Smazat větev pomocí příkazového řádku:

    Příklad
    git branch -d název-větve
    Smazat vzdálenou větev:

    Příklad
    git push origin –delete název-větve
    Přejmenovat větev
    Chcete-li přejmenovat větev pomocí příkazového řádku:

    Příklad
    git branch -m starý-název nový-název
    Sloučit větev
    Chcete-li sloučit větev s jinou na GitHubu, otevřete žádost o změnu (PR) a postupujte podle pokynů ke sloučení.

    Sloučení pomocí příkazového řádku:

    Příklad
    git merge název-větve
    Zobrazit větve
    Chcete-li zobrazit všechny větve ve vašem repozitáři na GitHubu, klikněte na rozbalovací nabídku větví v horní části seznamu souborů.

    Zobrazení větví pomocí příkazového řádku:

    Příklad
    git branch
    Chráněné větve
    Některé větve (například main) mohou být chráněné, což znamená, že je nelze smazat ani do nich vynutit odeslání bez zvláštních oprávnění.

    To pomáhá zabránit nechtěným změnám důležitých větví.

    Stažení větve z GitHubu
    Nyní pokračujte v práci na naší nové větvi v našem lokálním Gitu.

    Znovu stahujeme kód z našeho repozitáře GitHub, aby byl náš kód aktuální:

    Příklad
    git pull
    remote: Výčet objektů: 5, hotovo.
    remote: Počítání objektů: 100 % (5/5), hotovo.
    remote: Komprimace objektů: 100 % (3/3), hotovo.
    remote: Celkem 3 (delta 2), znovu použito 0 (delta 0), znovu použito zabaleno 0
    Rozbalování objektů: 100 % (3/3), 851 bajtů | 9,00 KiB/s, hotovo.
    Z https://github.com/w3schools-test/hello-world

    • [nová větev] html-skeleton -> origin/html-skeleton
      Již aktuální.
      Nyní je naše hlavní větev aktuální. A vidíme, že na GitHubu je k dispozici nová větev.

    Proveďte rychlou kontrolu stavu:

    Příklad
    git status
    Na větvi master
    Vaše větev je aktuální s ‚origin/master‘.

    nic k commitu, funkční strom čistý
    A potvrďte, které větve máme a kde momentálně pracujeme:

    Příklad
    git branch

    • master
      Takže novou větev nemáme na našem lokálním Gitu. Ale víme, že je k dispozici na GitHubu. Můžeme tedy použít volbu -a k zobrazení všech lokálních a vzdálených větví:

    Příklad
    git branch -a

    • master
      remotes/origin/html-skeleton
      remotes/origin/master
      Poznámka: branch -r je pouze pro vzdálené větve.

    Vidíme, že větev html-skeleton je k dispozici vzdáleně, ale ne na našem lokálním Gitu. Pojďme se na to podívat:

    Příklad
    git checkout html-skeleton
    Přepnuto na novou větev ‚html-skeleton‘
    Větev ‚html-skeleton‘ nastavena pro sledování vzdálené větve ‚html-skeleton‘ z ‚origin‘.
    A zkontrolujeme, zda je vše aktuální:

    Příklad
    git pull
    Již aktuální.
    Které větve nyní máme a odkud pracujeme?

    Příklad
    git branch

    • html-skeleton
      master
      Nyní otevřete svůj oblíbený editor a potvrďte, že se změny z větve GitHub přenesly.

    Takto se stáhne větev GitHub do vašeho lokálního Gitu.

    Odeslání větve na GitHub
    Tato kapitola vysvětluje, jak odeslat větev z vašeho lokálního počítače na GitHub.

    Odeslání větve na GitHub
    Vytvořme novou lokální větev, provedeme změnu a odešleme ji na GitHub.

    Příklad
    git checkout -b update-readme
    Přepnuto na novou větev ‚update-readme‘
    Upravte soubor a poté zkontrolujte jeho stav:

    Příklad
    git status
    Přidejte a potvrďte změny:

    Příklad
    git add README.md
    git commit -m „Aktualizovat readme pro GitHub“
    Odešlete svou větev na GitHub:

    Příklad
    git push origin update-readme
    GitHub Nová větev

    Odešlete a nastavte upstream
    Použijte to, pokud vaše větev na GitHubu ještě neexistuje a chcete ji sledovat:

    Příklad
    git push –set-upstream origin update-readme
    Vynutit odeslání
    Varování: Toto přepíše větev na GitHubu vašimi lokálními změnami. Používejte pouze v případě, že rozumíte rizikům.

    Příklad
    git push –force origin update-readme
    Smazat vzdálenou větev
    Odebrat větev z GitHubu:

    Příklad
    git push origin –delete update-readme
    Odeslat všechny větve
    Odeslat všechny lokální větve na GitHub:

    Příklad
    git push –all origin
    Odeslat tagy
    Odeslat všechny tagy na GitHub:

    Příklad
    git push –tags
    Řešení problémů
    Odmítnuto odeslání (bez rychlého přetáčení): Někdo jiný odeslal změny před vámi. Nejprve spusťte git pull –rebase a zkuste to znovu.
    Ověření selhalo: Ujistěte se, že jste přihlášeni a máte oprávnění k odeslání do repozitáře.
    Vzdálená větev nenalezena: Zkontrolujte název větve a pravopis.

    Co je GitHub Flow?
    GitHub Flow je jednoduchý a efektivní pracovní postup pro spolupráci na kódu pomocí Gitu a GitHubu.

    Pomáhá týmům hladce spolupracovat, bezpečně experimentovat a rychle dodávat nové funkce nebo opravy.

    Zde je návod, jak GitHub Flow funguje krok za krokem:

    Vytvořit větev: Zahájit novou práci bez ovlivnění hlavního kódu.
    Provést commity: Uložit postup při provádění změn.
    Otevřít Pull Request: Požádat ostatní o kontrolu vaší práce.
    Kontrolovat: Společně diskutovat o změnách a vylepšovat je.
    Nasadit: Otestovat změny před sloučením.
    Sloučit: Přidat hotovou práci do hlavní větve.
    Tento pracovní postup je navržen tak, aby byl snadný pro začátečníky a výkonný pro týmy všech velikostí.

    Vytvořit novou větev
    Větvení je klíčovým konceptem v Gitu. A funguje kolem pravidla, že hlavní větev je VŽDY nasaditelná.

    To znamená, že pokud chcete vyzkoušet něco nového nebo experimentovat, vytvoříte novou větev!

    Větvení vám poskytuje prostředí, kde můžete provádět změny, aniž by to ovlivnilo hlavní větev.

    Když je vaše nová větev připravena, lze ji zkontrolovat, prodiskutovat a sloučit s hlavní větví.

    Když vytváříte novou větev, budete ji (téměř vždy) chtít vytvořit z hlavní větve.

    Poznámka: Mějte na paměti, že spolupracujete s ostatními.

    Používejte popisné názvy pro nové větve, aby každý pochopil, co se děje.

    Provádějte změny a přidávejte commity
    Po vytvoření nové větve je čas se pustit do práce.

    Provádějte změny přidáváním, úpravou a mazáním souborů.

    Kdykoli dosáhnete malého milníku, přidejte změny do své větve pomocí commitu.

    Přidávání commitu sleduje vaši práci.

    Každý commit by měl obsahovat zprávu vysvětlující, co se změnilo a proč.

    Každý commit se stává součástí historie větve a bodem, ke kterému se můžete v případě potřeby vrátit.

    Poznámka: Zprávy commitu jsou velmi důležité! Dejte všem vědět, co se změnilo a proč.

    Zprávy a komentáře vám i ostatním lidem výrazně usnadňují sledování změn.

    Otevření žádosti o změnu (Pull Request)
    Žádosti o změnu (Pull Request) jsou klíčovou součástí GitHubu.

    Žádost o změnu (Pull Request) upozorňuje lidi, že máte připravené změny k posouzení nebo kontrole.

    Můžete požádat ostatní, aby si vaše změny zkontrolovali, nebo stáhnout váš příspěvek a sloučit ho do své větve.

    Recenze
    Když je žádost o změnu vytvořena, může ji zkontrolovat kdokoli, kdo má k dané větvi příslušný přístup.

    Tady probíhají dobré diskuse a revize změn.

    Žádosti o změnu jsou navrženy tak, aby lidem umožnily snadnou spolupráci a společným dosahováním lepších výsledků!

    Pokud obdržíte zpětnou vazbu a budete své změny nadále vylepšovat, můžete je odeslat s novými commity, což umožní další revize.

    Poznámka: GitHub zobrazuje nové commity a zpětnou vazbu v „jednotném zobrazení žádosti o změnu“.

    Nasazení
    Když je žádost o změnu zkontrolována a vše vypadá dobře, je čas na finální testování.

    GitHub umožňuje nasazení z větve pro finální testování v produkčním prostředí před sloučením s větví master.

    Pokud se vyskytnou nějaké problémy, můžete změny vrátit zpět opětovným nasazením větve master do produkčního prostředí!

    Poznámka: Týmy často používají specializovaná testovací prostředí pro nasazení větví.

    Sloučení
    Po důkladném testování můžete kód sloučit s větví master!

    Pull Requesty uchovávají záznamy o změnách ve vašem kódu a pokud jste změny dobře okomentovali a pojmenovali, můžete se k nim vrátit a pochopit, proč byly změny a rozhodnutí provedeny.

    Poznámka: Do svého pull requestu můžete přidat klíčová slova pro snazší vyhledávání!

    Povolení stránek GitHubu
    Stránky GitHubu vám umožňují publikovat webové stránky přímo z vašeho repozitáře. Chcete-li je povolit:

    Vytvořte nový repozitář s názvem vaše-uživatelské_jméno.github.io.
    Přidejte soubory vašeho webu (například index.html) do repozitáře.
    Odešlete změny na GitHub.
    Vytvoření nového repozitáře na GitHubu

    Pravidla pro pojmenování stránek GitHubu

    Příklad
    git remote add origin https://github.com/vaše-uživatelské_jméno/vaše-uživatelské_jméno.github.io.git
    git push -u origin master
    Nastavení zdrojové větve/složky
    Můžete si vybrat, kterou větev a složku chcete publikovat. Ve výchozím nastavení GitHub používá hlavní (nebo hlavní) a kořenovou složku. Chcete-li to změnit:

    Přejděte do svého repozitáře na GitHubu.
    Klikněte na Nastavení > Stránky.
    V části Zdroj vyberte větev a složku (např. hlavní a dokumentace).
    Klikněte na Uložit.
    Zobrazení vašeho webu
    Po povolení stránek GitHub bude váš web dostupný na adrese https://vaše-uživatelské-jméno.github.io/ (nebo ve vaší vlastní doméně).

    Přejděte na kartu Stránky a podívejte se na svou URL adresu

    Klikněte na odkaz a zobrazí se vám váš web!

    Zakázat stránky GitHub
    Chcete-li vypnout web Stránky:

    Přejděte do Nastavení > Stránky.
    Klikněte na Odstranit nebo odeberte zdrojovou větev/složku.
    Volitelně můžete repozitář smazat, pokud ho již nepotřebujete.
    Příklad
    git push origin –delete gh-pages

    Proč používat klienta s grafickým uživatelským rozhraním?
    Klienti s grafickým uživatelským rozhraním Gitu vám umožňují používat Git s tlačítky a nabídkami namísto psaní příkazů.

    Jsou skvělí pro začátečníky, usnadňují sledování dění a pomáhají vám vyhnout se běžným chybám.

    Vizuálně si prohlížejte větve a změny
    Připravujte, potvrzujte a odesílejte změny kliknutími
    Řešte konflikty sloučení pomocí užitečných nástrojů
    Není třeba si pamatovat možnosti příkazového řádku
    Oblíbení klienti s grafickým uživatelským rozhraním Gitu
    GitHub Desktop
    GitKraken
    Sourcetree
    Git GUI
    VS Code Git
    Ostatní klienti
    GitHub Desktop
    GitHub Desktop je bezplatná aplikace pro začátečníky, vhodná pro Windows a Mac.

    Funguje nejlépe s GitHubem, ale můžete ji používat i s jinými repozitáři.

    Výhody: Jednoduché a čisté rozhraní. Skvělé pro uživatele GitHubu.
    Nevýhody: Méně pokročilých funkcí. Není tak flexibilní pro platformy mimo GitHub.
    Příklad pracovního postupu

    1. Klonování repozitáře z GitHubu
    2. Provádění změn v souborech
    3. Zobrazení změn v aplikaci
    4. Přidání a commit pomocí zprávy
    5. Odeslání na GitHub jedním kliknutím

    GitKraken
    GitKraken je výkonný multiplatformní Git klient s moderním rozhraním.

    Podporuje GitHub, GitLab, Bitbucket a další.

    Výhody: Vizuální graf commitů, vestavěné nástroje pro slučování/konflikty, funguje s mnoha platformami.
    Nevýhody: Některé funkce vyžadují placenou licenci.
    Příklad pracovního postupu

    1. Otevření repozitáře
    2. Přetažením vytvořte větve
    3. Zobrazení historie a vizuální sloučení
    4. Řešení konfliktů pomocí vestavěných nástrojů
    5. Odeslání změn na vzdálené místo
      Sourcetree
      Sourcetree je bezplatný Git klient od společnosti Atlassian, oblíbený pro Bitbucket, ale funguje s jakýmkoli Git repozitářem.

    Výhody: Zdarma, plně vybavený, vhodný pro pokročilé uživatele.
    Nevýhody: Rozhraní může být pro začátečníky ohromující.
    Příklad pracovního postupu

    1. Přidání repozitáře
    2. Příprava a potvrzení změn
    3. Použití zobrazení protokolu/historie pro zobrazení všech commitů
    4. Odesílání a stahování pomocí tlačítek
      GUI Git
      GUI Git je základní grafický nástroj, který je součástí Gitu pro Windows.

    Je jednoduchý, ale pokrývá základy.

    Výhody: Vždy dostupný, lehký, není nutná žádná další instalace.
    Nevýhody: Základní rozhraní, méně funkcí než u jiných klientů.
    Příklad pracovního postupu

    1. Otevřete GUI Git z nabídky Start
    2. Vyberte složku repozitáře
    3. Příprava souborů, napsání zprávy o potvrzení a potvrzení
    4. Odeslání na vzdálené zařízení pomocí nabídky
      VS Code Git
      Visual Studio Code má vestavěnou podporu Gitu.

    Panel Správa zdrojového kódu můžete použít k přípravě, potvrzení, odesílání, stahování a řešení konfliktů – to vše v editoru kódu.

    Výhody: Integrováno s editorem, snadno se používá, funguje s rozšířeními.
    Nevýhody: Není tak vizuální pro historii/větve jako u specializovaných aplikací.
    Příklad pracovního postupu

    1. Otevření složky ve VS Code
    2. Provedení změn v souborech
    3. Použití panelu Správa zdrojového kódu k přípravě a potvrzení změn
    4. Push and Pull pomocí tlačítek
      Další klienti
      Existuje mnoho dalších klientů Git GUI, včetně:

    Fork
    Tower
    SmartGit
    Aurora
    Git-Cola
    Většina z nich funguje podobným způsobem: otevřete repozitář, zobrazíte změny a použijete tlačítka pro akce Gitu.

    Řešení problémů
    Problémy s ověřováním: V případě potřeby se ujistěte, že jste nastavili klíče SSH nebo osobní přístupové tokeny.
    Změny se nezobrazují: Obnovte nebo znovu prohledejte repozitář v klientovi.
    Konflikty: Použijte nástroje pro slučování/řešení konfliktů zabudované v klientovi nebo se v případě problémů vraťte k příkazovému řádku.

    Přidání do repozitáře někoho jiného
    Srdcem Gitu je spolupráce.

    Git vám však neumožňuje přidávat kód do repozitáře někoho jiného bez přístupových práv.

    V následujících 3 kapitolách vám ukážeme, jak kopírovat repozitář, provádět v něm změny a navrhovat implementaci těchto změn do původního repozitáře.

    Na konci těchto kapitol budete mít možnost přidat zprávu na naši veřejnou stránku GitHub: https://w3schools-test.github.io/

    Fork repozitáře
    Fork je kopie repozitáře.

    To je užitečné, když chcete přispět do projektu někoho jiného nebo spustit vlastní projekt založený na jejich projektu.

    fork není příkaz v Gitu, ale něco, co je nabízeno na GitHubu a jiných hostitelích repozitářů.

    Začněme přihlášením na GitHub a vytvořením forku našeho repozitáře:
    https://github.com/w3schools-test/w3schools-test.github.io

    Fork GitHubu

    Nyní máme vlastní kopii w3schools-test.github.io:

    Fork GitHubu dokončen

    Nyní se podívejme, jak přidáme lokální kopii, se kterou budeme moci pracovat.

    Klonování forku z GitHubu
    Nyní máme vlastní fork, ale pouze na GitHubu. Chceme také klon na našem lokálním Gitu, abychom na něm mohli dále pracovat.

    Klon je úplná kopie repozitáře, včetně veškerého logování a verzí souborů.

    Vraťte se do původního repozitáře a kliknutím na zelené tlačítko „Kód“ získejte URL adresu pro klonování:

    URL adresy klonu GitHubu

    Otevřete Git bash a naklonujte repozitář:

    Příklad
    git clone https://github.com/w3schools-test/w3schools-test.github.io.git
    Klonování do ‚w3schools-test.github.io’…
    remote: Výčet objektů: 33, hotovo.
    remote: Počítání objektů: 100 % (33/33), hotovo.
    remote: Komprimace objektů: 100 % (15/15), hotovo.
    vzdálené: Celkem 33 (delta 18), znovu použito 33 (delta 18), znovu použito zabaleno 0
    Příjem objektů: 100 % (33/33), 94,79 KiB | 3,16 MiB/s, hotovo.
    Řešení delt: 100 % (18/18), hotovo.
    Podívejte se do svého souborového systému a uvidíte nový adresář pojmenovaný po klonovaném projektu:

    Příklad
    ls
    w3schools-test.github.io/
    Poznámka: Chcete-li zadat konkrétní složku, do které se má projekt klonovat, přidejte název složky za URL adresu repozitáře, například takto: git clone https://github.com/w3schools-test/w3schools-test.github.io.git myfolder

    Přejděte do nového adresáře a zkontrolujte stav:

    Příklad
    cd w3schools-test.github.io
    git status
    Na větvi master
    Vaše větev je aktuální s adresou ‚origin/master‘.

    nic k commitu, funkční strom čistý
    A zkontrolujte log, abyste se ujistili, že máme kompletní data repozitáře:

    Příklad
    git log
    commit facaeae8fd87dcb63629f108f401aa9c3614d4e6 (HEAD -> master, origin/master, origin/HEAD)
    Sloučení: e7de78f 5a04b6f
    Autor: w3schools-test
    Datum: Pá 26. března 15:44:10 2021 +0100

    Sloučení větve ‚master‘ z https://github.com/w3schools-test/hello-world

    commit e7de78fdefdda51f6f961829fcbdf197e9b926b6
    Autor: w3schools-test
    Datum: Pá 26. března 15:37:22 2021 +0100

    Aktualizován index.html. Změněna velikost obrázku

    …..
    Nyní máme plnou kopii původního repozitáře.

    Konfigurace vzdálených serverů
    V podstatě máme plnou kopii repozitáře, jehož origin nemůžeme měnit.

    Podívejme se, jak jsou nastaveny vzdálené servery tohoto Gitu:

    Příklad
    git remote -v
    origin https://github.com/w3schools-test/w3schools-test.github.io.git (fetch)
    origin https://github.com/w3schools-test/w3schools-test.github.io.git (push)
    Vidíme, že origin je nastaven na původní repozitář „w3schools-test“, chceme také přidat vlastní fork.

    Nejprve přejmenujeme původní origin remote:

    Příklad
    git remote rename origin upstream
    git remote -v
    upstream https://github.com/w3schools-test/w3schools-test.github.io.git (fetch)
    upstream https://github.com/w3schools-test/w3schools-test.github.io.git (push)
    Poté načteme URL adresu našeho vlastního forku:

    URL klonu GitHubu

    A přidáme ji jako origin:

    Příklad
    git remote add origin https://github.com/kaijim/w3schools-test.github.io.git
    git remote -v
    origin https://github.com/kaijim/w3schools-test.github.io.git (fetch)
    origin https://github.com/kaijim/w3schools-test.github.io.git (push)
    upstream https://github.com/w3schools-test/w3schools-test.github.io.git (fetch)
    upstream https://github.com/w3schools-test/w3schools-test.github.io.git (push)
    Poznámka: Podle konvencí pojmenování Gitu se doporučuje pojmenovat vlastní repozitář origin a ten, který jste forkovali, pro upstream.

    Nyní máme 2 vzdálené repozitáře:

    origin – náš vlastní fork, kde máme přístup pro čtení a zápis
    upstream – originál, kde máme přístup pouze pro čtení
    Nyní provedeme několik změn v kódu. V další kapitole se budeme zabývat tím, jak tyto změny navrhujeme v původním repozitáři.

    Odeslání změn do našeho forku GitHub
    Provedli jsme spoustu změn v našem lokálním Gitu.

    Teď je odešleme do našeho forku GitHub:

    commit změn:

    Příklad
    git push origin
    Výčet objektů: 8, hotovo.
    Počítání objektů: 100 % (8/8), hotovo.
    Delta komprese s využitím až 16 vláken
    Komprese objektů: 100 % (5/5), hotovo.
    Zápis objektů: 100 % (5/5), 393,96 KiB | 32,83 MiB/s, hotovo.
    Celkem 5 (delta 0), znovu použito 0 (delta 0), znovu použito 0
    Na https://github.com/kaijim/w3schools-test.github.io.git
    facaeae..ebb1a5c master -> master
    Přejdeme na GitHub a vidíme, že repozitář má nový commit. A můžeme poslat Pull Request do původního repozitáře:

    GitHub Fork Pull Request

    Klikněte na to a vytvořte pull request:

    GitHub Fork Create Pull Request

    Nezapomeňte přidat vysvětlení pro administrátory.

    GitHub Fork Create Pull Request Comment

    Pull Request je odeslán:

    GitHub Fork Pull Request odeslán

    Approving Pull Requests
    Nyní může každý člen s přístupem vidět Pull Request, když vidí původní repozitář:

    GitHub New Pull Request

    A může vidět navrhované změny:

    Přehled GitHub Pull Requests

    Komentář ke změnám a sloučení:

    GitHub Pull Request Merge

    Confirm:

    GitHub Pull Request Confirm Merge

    A změny byly sloučeny s masterem:

    GitHub Pull Request Merged

    Teď to zkuste!

    Co dělá Git Revert?
    Příkaz git revert vrátí předchozí commit vytvořením nového commitu, který vrátí změny zpět.

    Tím se zachová historie commitů nedotčená a je to nejbezpečnější způsob, jak vrátit zpět změny ve sdíleném repozitáři.

    Shrnutí příkazů a možností Git Revert
    git revert HEAD – Vrátí nejnovější commit
    git revert – Vrátí konkrétní commit
    git revert HEAD~2 – Vrátí commit dále v historii
    git revert –no-edit – Přeskočí editor zpráv commitu
    git log –oneline – Zobrazit historii commitu
    Jak najít commit k vrácení
    Nejprve musíte najít commit, který chcete vrátit zpět.

    Použijte git log –oneline pro zobrazení souhrnu historie vašich commitů:

    Příklad
    git log –oneline
    52418f7 (HEAD -> master) Jen běžná aktualizace, rozhodně zde žádné nehody…
    9a9add8 (origin/master) Přidán .gitignore
    81912ba Opravena pravopisná chyba
    3fdaa5b Sloučit pull request #1 z w3schools-test/update-readme
    836e5bf (origin/update-readme, update-readme) Aktualizován readme pro větve GitHubu
    daf4f7c (origin/html-skeleton, html-skeleton) Aktualizován index.html se základními meta
    facaeae (gh-page/master) Sloučit větev ‚master‘ z https://github.com/w3schools-test/hello-world
    e7de78f Aktualizován index.html. Změněná velikost obrázku
    5a04b6f Soubor README.md aktualizován o řádek o fokusu
    d29d69f Soubor README.md aktualizován o řádek o GitHubu
    e0b6038 sloučen s hello-world-images po opravě konfliktů
    1f1584e přidán nový obrázek
    dfa79db aktualizován index.html s nouzovou opravou
    0312c55 Přidán obrázek do Hello World
    09f4acd Aktualizován index.html o nový řádek
    221ec6e První vydání Hello World!

    Spusťte Git Revert
    Jakmile najdete commit, který chcete vrátit zpět, použijte git revert k vytvoření nového commitu, který vrátí změny zpět:

    Příklad
    git revert HEAD –no-edit
    [master e56ba1f] Revert „Jen běžná aktualizace, rozhodně žádné nehody…“
    Datum: Čt 22. dubna 10:50:13 2021 +0200
    1 soubor změněn, 0 vložených (+), 0 smazání (-)
    create mode 100644 img_hello_git.jpg
    Zkontrolujte změny po Git Revert
    Po spuštění git revert zkontrolujte změny, abyste se ujistili, že je vše podle očekávání:

    Příklad
    git log –oneline
    e56ba1f (HEAD -> master) Revert „Jen běžná aktualizace, rozhodně žádné nehody…“
    52418f7 Jen běžná aktualizace, rozhodně žádné nehody…
    9a9add8 (origin/master) Přidáno .gitignore
    81912ba Opraven pravopis chyba
    3fdaa5b Žádost o sloučení pull request #1 z w3schools-test/update-readme
    836e5bf (origin/update-readme, update-readme) Aktualizovaný readme pro větve GitHubu
    daf4f7c (origin/html-skeleton, html-skeleton) Aktualizován index.html se základními metadaty
    facaeae (gh-page/master) Sloučena větev ‚master‘ z https://github.com/w3schools-test/hello-world
    e7de78f Aktualizován index.html. Změněná velikost obrázku
    5a04b6f Soubor README.md aktualizován o řádek o fokusu
    d29d69f Soubor README.md aktualizován o řádek o GitHubu
    e0b6038 sloučen s hello-world-images po opravě konfliktů
    1f1584e přidán nový obrázek
    dfa79db aktualizován index.html s nouzovou opravou
    0312c55 Přidán obrázek do Hello World
    09f4acd Soubor index.html aktualizován o nový řádek
    221ec6e První vydání Hello World!
    Tipy a osvědčené postupy
    Zde je několik tipů a osvědčených postupů, které je třeba mít na paměti při používání Git Revert:

    Pokud chcete vrátit zpět předchozí commit, ale zároveň zachovat historii commitů neporušenou, použijte git revert místo git reset.
    Pomocí git log –oneline vyhledejte commit, který chcete vrátit zpět.
    Pomocí git revert HEAD –no-edit vytvořte nový commit, který vrátí změny zpět.
    Řešení problémů
    Zde je několik běžných problémů, se kterými se můžete setkat při používání Git Revert:

    Pokud se zobrazí chybová zpráva „chyba: nelze vrátit…“, zkuste použít git revert –abort k přerušení procesu vrácení.

    Pokud se zobrazí chybová zpráva „chyba: nelze použít…“, zkuste použít git revert –continue k pokračování procesu vrácení.

    Co dělá příkaz Git Reset?
    Příkaz git reset přesune vaši aktuální větev (HEAD) do jiného commitu.

    V závislosti na zvolené volbě může také změnit, které změny budou uchovávány, nebo dokonce smazat změny z vašeho pracovního adresáře.

    Používá se k vrácení commitů zpět, odstavení souborů nebo k vyčištění historie.

    Shrnutí příkazů a voleb Git Reset
    git reset –soft – Přesune HEAD do commitu, ponechá změny uchovávány
    git reset –mixed – Přesune HEAD do commitu, odstavení změn (výchozí)
    git reset –hard – Přesune HEAD do commitu, zahodí všechny změny
    git reset – Odstavení souboru
    git log –oneline – Zobrazit historii commitů
    Jak najít commit, na který chcete resetovat
    Nejprve musíte najít commit, ke kterému se chcete vrátit.

    Pomocí příkazu git log –oneline zobrazíte souhrn historie vašich commitů:

    Git Reset Krok 1

    Krok 2: Přesunutí repozitáře zpět do daného kroku:

    Git Reset Krok 2

    Po předchozí kapitole máme v historii commitů část, ke které se můžeme vrátit.

    Zkusme to udělat pomocí příkazu reset.

    Git Reset Najít commit v logu
    Nejprve musíme najít bod, ke kterému se chceme vrátit.

    K tomu musíme projít log.

    Abychom se vyhnuli velmi dlouhému seznamu logů, použijeme volbu –oneline, která na commit zobrazí pouze jeden řádek:

    Prvních sedm znaků hashe commitu – na to se musíme odkazovat v našem příkazu reset.
    zpráva commitu
    Takže najděme bod, na který chceme obnovit:

    Příklad
    git log –oneline
    e56ba1f (HEAD -> master) Vrátit „Jen běžná aktualizace, rozhodně žádné nehody…“
    52418f7 Jen běžná aktualizace, rozhodně žádné nehody…
    9a9add8 (origin/master) Přidán .gitignore
    81912ba Opravena pravopisná chyba
    3fdaa5b Sloučit pull request #1 z w3schools-test/update-readme
    836e5bf (origin/update-readme, update-readme) Aktualizován readme pro větve GitHubu
    daf4f7c (origin/html-skeleton, html-skeleton) Aktualizován index.html se základními meta
    facaeae (gh-page/master) Sloučit větev ‚master‘ z https://github.com/w3schools-test/hello-world
    e7de78f Aktualizován index.html. Změněná velikost obrázku
    5a04b6f Soubor README.md aktualizován o řádek o fokusu
    d29d69f Soubor README.md aktualizován o řádek o GitHubu
    e0b6038 sloučen s hello-world-images po opravě konfliktů
    1f1584e přidán nový obrázek
    dfa79db aktualizován index.html s nouzovou opravou
    0312c55 Přidán obrázek do Hello World
    09f4acd Soubor index.html aktualizován o nový řádek
    221ec6e První vydání Hello World!
    Chceme se vrátit ke commitu: 9a9add8 (origin/master) Přidán .gitignore, poslední, než jsme s tím začali hrát.

    Git Reset –soft
    git reset –soft přesune HEAD na zadaný commit, ale všechny vaše změny ponechá ve fázi (v indexu).

    To je užitečné, pokud chcete sloučit několik commitů do jednoho, nebo chcete jen přepsat historii, ale zároveň si práci ponechat připravenou k commitu.

    Příklad
    git reset –soft 9a9add8
    Všechny změny po 9a9add8 jsou nyní připraveny k novému commitu.

    Git Reset –mixed (výchozí)
    git reset –mixed (nebo jen git reset ) přesune HEAD na zadaný commit a zruší všechny změny, ale ponechá je ve vašem pracovním adresáři.

    Toto je výchozí možnost a je užitečná, pokud chcete commit „vrátit zpět“, ale zachovat změny pro úpravy nebo opětovné commitování.

    Příklad
    git reset –mixed 9a9add8
    Všechny změny po 9a9add8 jsou nyní nezrušeny, ale stále ve vašich souborech.

    Kontrola změn
    Po spuštění Git Reset zkontrolujte své změny, abyste se ujistili, že je vše podle očekávání.

    Tipy a osvědčené postupy
    Git Reset používejte opatrně, protože může přepsat historii vašich commitů.

    Před provedením změn ve vzdáleném repozitáři se ujistěte, že jste se spojil se svým týmem.

    Řešení problémů
    Pokud narazíte na problémy s funkcí Git Reset, zkuste použít příkaz git status k zobrazení aktuálního stavu vašeho repozitáře.

    Upozornění
    Při používání funkce Git Reset buďte opatrní, protože může smazat změny a přepsat historii commitů.

    Používejte ji pouze v nezbytných případech.

    Co je Git Amend?
    Git Amend je příkaz, který umožňuje upravit nejnovější commit.

    Můžete ho použít k opravě překlepů, přidání nebo odebrání souborů nebo ke změně zprávy commitu.

    Kdy použít Git Amend
    Použijte Git Amend, když potřebujete provést malé změny v posledním commitu.

    Je ideální pro opravu chyb, přidání zapomenutých souborů nebo aktualizaci zprávy commitu.

    Oprava zprávy posledního commitu
    Chcete-li změnit zprávu posledního commitu, postupujte takto:

    Otevřete terminál a přejděte do svého repozitáře.
    Zadejte git commit –amend -m „Nová zpráva“ pro změnu zprávy commitu.
    Stiskněte Enter pro uložení změn.
    Příklad
    git commit –amend -m „Opravená zpráva commitu“
    Přidat soubory do posledního commitu
    Chcete-li přidat soubory do posledního commitu, postupujte takto:

    Otevřete terminál a přejděte do svého repozitáře.
    Zadejte git add pro přidání souboru do pracovní oblasti.
    Zadejte git commit –amend pro přidání souboru do posledního commitu.
    Stiskněte Enter pro uložení změn.
    Příklad
    git add forgotten.txt
    git commit –amend

    Odstranění souborů z posledního commitu
    Chcete-li odstranit soubory z posledního commitu, postupujte takto:

    Otevřete terminál a přejděte do svého repozitáře.
    Zadejte git reset HEAD^ — pro odstranění souboru z pracovní oblasti.
    Zadejte git commit –amend pro odstranění souboru z posledního commitu.
    Stiskněte Enter pro uložení změn.
    Příklad
    git reset HEAD^ — unwanted.txt
    git commit –amend
    1 soubor změněn, 3 vložení(+), 1 smazání(-)
    Nyní se podívejme na log:

    Příklad
    git log –oneline
    07c5bc5 (HEAD -> master) Přidání čar do reddme
    9a9add8 (origin/master) Přidán .gitignore
    81912ba Opravena pravopisná chyba
    3fdaa5b Sloučit pull request #1 z w3schools-test/update-readme
    836e5bf (origin/update-readme, update-readme) Aktualizován readme pro větve GitHubu
    daf4f7c (origin/html-skeleton, html-skeleton) Aktualizován index.html se základními meta
    facaeae (gh-page/master) Sloučit větev ‚master‘ z https://github.com/w3schools-test/hello-world
    e7de78f Aktualizován index.html. Změněná velikost obrázku
    5a04b6f Soubor README.md aktualizován o řádek o fokusu
    d29d69f Soubor README.md aktualizován o řádek o GitHubu
    e0b6038 sloučen s hello-world-images po opravě konfliktů
    1f1584e přidán nový obrázek
    dfa79db aktualizován index.html s nouzovou opravou
    0312c55 Přidán obrázek do Hello World
    09f4acd Aktualizován index.html o nový řádek
    221ec6e První vydání Hello World! Ale ne! Zpráva o potvrzení je plná pravopisných chyb.

    Trapné. Opravme to:

    Příklad
    git commit –amend -m „Přidány řádky do README.md“
    [master eaa69ce] Přidány řádky do README.md
    Datum: Čt 22. dubna 12:18:52 2021 +0200
    1 soubor změněn, 3 vložení (+), 1 smazání (-))
    A znovu zkontrolujte protokol:

    Příklad
    git log –oneline
    eaa69ce (HEAD -> master) Přidány řádky do README.md
    9a9add8 (origin/master) Přidán .gitignore
    81912ba Opravena pravopisná chyba
    3fdaa5b Request na sloučení #1 z w3schools-test/update-readme
    836e5bf (origin/update-readme, update-readme) Aktualizován readme pro větve GitHubu
    daf4f7c (origin/html-skeleton, html-skeleton) Aktualizován index.html se základními metadaty
    facaeae (gh-page/master) Sloučení větve ‚master‘ z https://github.com/w3schools-test/hello-world
    e7de78f Aktualizován index.html. Změněna velikost obrázku
    5a04b6f Aktualizován README.md s řádkem o fokusu
    d29d69f Aktualizován README.md s řádkem o GitHubu
    e0b6038 sloučen s hello-world-images po opravě konfliktů
    1f1584e přidán nový obrázek
    dfa79db aktualizován index.html s nouzovou opravou
    0312c55 Přidán obrázek do Hello World
    09f4acd Aktualizován index.html s novým řádkem
    221ec6e První vydání Hello World!
    Vidíme, že předchozí commit je nahrazen naším upraveným!

    Varování: Zasahování do historie commitů repozitáře může být nebezpečné.

    Obvykle je v pořádku provádět tyto druhy změn ve vašem vlastním lokálním repozitáři.

    Měli byste se však vyhnout provádění změn, které přepisují historii do vzdálených repozitářů, zejména pokud s nimi pracují jiní.

    Git Amend Files
    Přidávání souborů pomocí –amend funguje stejně jako výše.

    Před potvrzením změn je stačí přidat do testovacího prostředí.

    Co je Git Rebase?
    Rebase přesouvá nebo kombinuje sekvenci commitů do nového základního commitu.

    Často se používá k udržení čisté, lineární historie projektu.

    Rebase může usnadnit čtení historie vašich commitů tím, že se vyhne zbytečným merge commitům.

    Kdy použít Git Rebase
    Použijte Git Rebase k:

    Udržení čisté, lineární historie projektu
    Vyhnutí se zbytečným merge commitům
    Sloučení více commitů do jednoho
    Úpravě nebo změně pořadí commitů
    Základní Rebase
    Chcete-li přesunout aktuální větev nad jinou větev (např. aktualizovat větev feature s nejnovější main):

    Příklad: Rebase na main
    git checkout feature-branch
    git rebase main
    Tímto se změny větve feature znovu aplikují na nejnovější větev main.

    Interaktivní Rebase
    git rebase -i umožňuje upravovat, měnit pořadí, shlukovat nebo opravovat commity před určitým bodem.

    To je užitečné pro vyčištění historie commitů před jejím sdílením s ostatními.

    Příklad: Spustit interaktivní rebase
    git rebase -i HEAD~3
    Otevře se editor, kde můžete:

    pick: ponechat commit tak, jak je
    squash: sloučit commity
    edit: pozastavit pro změnu commitu
    reword: změnit pouze zprávu commitu
    Postupujte podle těchto kroků:

    Upravit zprávu commitu nebo zvolit akci (pick, squash, edit, reword)
    Uložit a zavřít editor
    Git použije změny a umožní vám zkontrolovat výsledky
    Pokračovat, Zrušit nebo Přeskočit
    Pokud narazíte na konflikt nebo potřebujete dokončit úpravu commitu, použijte po vyřešení problému git rebase –continue.

    Toto říká Gitu, aby pokračoval v procesu rebase.

    Příklad
    git add fixed_file.txt
    git rebase –continue
    Pokud se něco pokazí nebo chcete zastavit rebase, použijte git rebase –abort.

    Toto vrátí vaši větev zpět do stavu, v jakém byla před zahájením rebase.

    Příklad
    git rebase –abort
    Pokud nelze během rebase opravit commit (například pokud nelze vyřešit konflikt), můžete jej přeskočit pomocí git rebase –skip.

    Git tento commit vynechá a přesune se k dalšímu.

    Příklad
    git rebase –skip
    Zkontrolujte změny
    Po dokončení rebase zkontrolujte provedené změny a ujistěte se, že je vše v pořádku.

    Tipy a osvědčené postupy
    Rebase přepisuje historii commitů.

    Vyhněte se rebaseování commitů, které jste již odeslali do sdíleného repozitáře.

    K úpravě, změně pořadí, shrnutí nebo opravě commitů před určitým bodem použijte git rebase –continue.

    Ke zrušení probíhajícího rebase použijte git rebase –abort.

    Řešení problémů
    Pokud se během rebase setkáte s konflikty, vyřešte je a poté použijte git rebase –continue k pokračování procesu rebase.

    Pokud nemůžete opravit commit během rebase, použijte git rebase –skip k jeho přeskočení.

    Poznámka: Rebase přepisuje historii commitů.

    Vyhněte se rebaseování commitů, které jste již odeslali do sdíleného repozitáře.

    Co je Git Reflog?
    git reflog zaznamenává aktualizace větví a HEAD.

    Umožňuje vám vidět, kde se vaše větev a HEAD nacházely, a to i změny, které jste provedli omylem.

    To je užitečné pro obnovení ztracených commitů nebo vrácení zpět resetu.

    Kdy použít Git Reflog
    Použijte git reflog, když potřebujete:

    Obnovit ztracené commity nebo změny
    Vrátit zpět reset nebo sloučení
    Zobrazit historii vaší větve a HEAD
    Zobrazit Reflog
    Chcete-li zobrazit historii, kam HEAD a větve ukazovaly, použijte:

    Příklad
    git reflog
    e56ba1f (HEAD -> master) HEAD@{0}: commit: Vrátit „Jen běžná aktualizace, rozhodně žádné nehody…“
    52418f7 HEAD@{1}: commit: Jen běžná aktualizace, rozhodně žádné nehody…
    9a9add8 (origin/master) HEAD@{2}: commit: Přidán .gitignore
    81912ba HEAD@{3}: commit: Opravena pravopisná chyba
    3fdaa5b HEAD@{4}: merge: Request na sloučení #1 z w3schools-test/update-readme
    836e5bf HEAD@{5}: commit: Aktualizovaný readme pro větve GitHubu

    Zde je uveden seznam nedávných pozice HEAD, takže můžete vidět akce jako commity, resety, sloučení a checkouty.

    Nalezení a obnovení ztracených commitů
    Pokud omylem resetujete nebo smažete commity, můžete k nalezení a obnovení commitu použít reflog.

    Každá položka v reflogu má odkaz, například HEAD@{2}.

    Příklad: Vrácení hard resetu
    git reflog
    e56ba1f (HEAD -> master) HEAD@{0}: commit: Vrátit „Jen běžná aktualizace, rozhodně žádné nehody…“
    52418f7 HEAD@{1}: commit: Jen běžná aktualizace, rozhodně žádné nehody…
    9a9add8 (origin/master) HEAD@{2}: commit: Přidáno .gitignore
    81912ba HEAD@{3}: commit: Opravena pravopisná chyba

    git reset –hard HEAD@{2}
    HEAD je nyní na 9a9add8 Přidáno .gitignore
    Tím se vaše větev vrátí do stavu, ve kterém byla v daném okamžiku.

    Vyčištění reflogu
    Reflog je automaticky čištěn Gitem, ale v případě potřeby můžete ručně ukončit platnost starých položek:

    Příklad
    git reflog expire –expire=30.days refs/heads/main
    git gc –prune=now
    Počítání objektů: 15, hotovo.
    Komprimace objektů: 100 % (10/10), hotovo.
    Prořezávání objektů
    Tímto se odstraní položky reflogu starší než 30 dní pro hlavní větev a spustí se garbage collection.

    Tipy a osvědčené postupy
    Pravidelně používejte git reflog pro sledování změn
    Používejte git reflog pro obnovení ztracených commitů nebo změn
    Používejte git reflog expire pro vyčištění starých položek
    Řešení problémů
    Pokud narazíte na problémy s git reflog, zkuste:

    Vyhledejte další informace v dokumentaci k Gitu
    Vyhledejte online řešení konkrétních problémů
    Vyhledejte pomoc od experta nebo komunity Git
    Varování
    Při používání git reflog k obnovení ztracených commitů nebo změn buďte opatrní, protože může přepsat existující změny.

    Co je Git Recovery?
    Git Recovery znamená obnovení ztracených commitů, větví nebo souborů.

    Git uchovává záznamy o nedávných změnách, takže můžete chyby vrátit zpět – i po resetu nebo smazání.

    Kdy použít Git Recovery
    Git Recovery použijte, když:

    Náhodou smažete větev nebo soubor
    Obnovíte větev na předchozí commit a ztratíte změny
    Potřebujete obnovit ztracené commity nebo změny
    Obnovíte ztracené commity pomocí git reflog
    git reflog zaznamenává změny na konci větví a umožňuje vám najít ztracené commity.

    Příklad: Zobrazit reflog
    git reflog
    e56ba1f (HEAD -> master) HEAD@{0}: commit: Vrátit „Jen běžná aktualizace, rozhodně žádné nehody…“
    52418f7 HEAD@{1}: commit: Jen běžná aktualizace, rozhodně žádné nehody…
    9a9add8 (origin/master) HEAD@{2}: commit: Přidán .gitignore
    81912ba HEAD@{3}: commit: Opravena pravopisná chyba
    3fdaa5b HEAD@{4}: merge: Request na sloučení #1 z w3schools-test/update-readme
    836e5bf HEAD@{5}: commit: Aktualizovaný readme pro větve GitHubu

    Vyhledejte hash commitu, který chcete obnovit, ze seznamu.

    Obnovení smazané větve
    Pokud jste smazali větev, ale commity jsou stále v reflogu, můžete ji znovu vytvořit:

    Příklad: Obnovení větve
    git checkout -b branch-name
    Přepnuto na novou větev ‚branch-name‘
    Tímto se vrátí větev na vámi zadaný commit.

    Obnovení smazaného nebo změněného souboru
    Pokud jste smazali nebo změnili soubor a chcete ho získat zpět, použijte git restore:

    Příklad: Obnovení souboru
    git restore filename.txt
    Tímto se vrátí soubor z posledního commitu.

    Obnova po tvrdém resetu
    Pokud jste použili git reset –hard a ztratili commity, můžete k jejich nalezení a obnovení použít reflog:

    Příklad: Vrácení tvrdého resetu
    git reflog
    e56ba1f (HEAD -> master) HEAD@{0}: commit: Vrátit „Jen běžná aktualizace, rozhodně žádné nehody…“
    52418f7 HEAD@{1}: commit: Jen běžná aktualizace, rozhodně žádné nehody…
    9a9add8 (origin/master) HEAD@{2}: commit: Přidán .gitignore
    81912ba HEAD@{3}: commit: Opravena pravopisná chyba
    3fdaa5b HEAD@{4}: merge: Request na sloučení #1 z w3schools-test/update-readme
    836e5bf HEAD@{5}: commit: Aktualizován readme pro větve GitHubu

    git reset –hard HEAD@{2}
    HEAD je nyní na 9a9add8 Přidán .gitignore
    Toto vloží vaši větev zpět do stavu, ve kterém se v daném okamžiku nacházela.

    Tipy a osvědčené postupy
    Pravidelně potvrzujte změny, abyste se vyhnuli ztrátě práce
    Používejte git reflog k nalezení ztracených commitů
    Používejte git restore k obnovení smazaných nebo změněných souborů

    Co je .gitignore?
    Soubor .gitignore říká Gitu, které soubory a složky má ignorovat (nesledovat).

    To je užitečné pro udržení souborů protokolů, dočasných souborů, artefaktů sestavení nebo osobních souborů mimo váš repozitář.

    Příklady souborů, které je třeba ignorovat: soubory protokolů, dočasné soubory, skryté soubory, osobní soubory, soubory operačního systému/editoru atd.
    Samotný soubor .gitignore je sledován Gitem, takže všichni, kteří repozitář používají, ignorují stejné soubory.

    Kdy použít .gitignore
    Kdy chcete do svého repozitáře uchovat citlivé, lokální nebo nepotřebné soubory
    Při sdílení projektu s ostatními a chcete se vyhnout zahlcení historie Gitu
    Při práci s nástroji pro sestavení nebo editory, které vytvářejí další soubory
    Vytvořte soubor .gitignore
    Přejděte do kořenového adresáře vašeho lokálního repozitáře Git.
    Vytvořte soubor s názvem .gitignore:
    Příklad
    touch .gitignore
    Ignorování složek
    Chcete-li ignorovat složku a vše v ní, použijte koncové lomítko:

    temp/
    Tímto se ignoruje jakákoli složka s názvem temp kdekoli ve vašem projektu.

    Zástupné znaky a vzory
    Zástupné znaky umožňují porovnávat více souborů nebo složek najednou:

    • odpovídá libovolnému počtu znaků
      ? odpovídá jednomu znaku
      [abc] odpovídá libovolnému znaku v sadě
      [!abc] odpovídá libovolnému znaku, který není v sadě
      *.tmp # všechny soubory .tmp
      my?ile.txt # odpovídá my1ile.txt, myAile.txt atd.
      log[0-9].txt # log1.txt, log2.txt, … log9.txt
      Negace (!)
      Použijte !, abyste neignorovali něco, co by jinak bylo ignorováno. Tomu se říká výjimka:

    *.log
    !important.log
    Tímto se ignorují všechny soubory .log kromě important.log.

    Komentáře a prázdné řádky
    Řádky začínající znakem # jsou komentáře a Git je ignoruje. Prázdné řádky jsou také ignorovány. Použijte komentáře k vysvětlení vašich pravidel:

    Ignorovat soubory protokolu

    *.log

    Ignorovat dočasné složky

    temp/
    Lokální a osobní pravidla ignorování
    Pokud chcete ignorovat soubory pouze pro sebe (ne pro všechny, kteří používají repozitář), přidejte je do .git/info/exclude. Funguje to stejně jako .gitignore, ale není to sdílené.

    Globální .gitignore (úroveň uživatele)
    Můžete nastavit globální soubor .gitignore pro všechny vaše projekty. To je skvělé pro ignorování souborů OS nebo editoru všude (například .DS_Store nebo Thumbs.db):

    git config –global core.excludesfile ~/.gitignore_global
    Poté přidejte své vzory do ~/.gitignore_global.

    Jak zastavit sledování souboru
    Pokud přidáte soubor do .gitignore, ale Git ho stále sleduje, musíte Gitu říct, aby zastavil:

    git rm –cached název_souboru.txt
    Tímto se soubor odstraní z repozitáře, ale ponechá se ve vašem počítači. Při příštím commitu ho Git ignoruje.

    Tipy a řešení problémů
    Zkontrolujte překlepy – .gitignore rozlišuje velká a malá písmena!
    Pokud je soubor již sledován, použijte git rm –cached k zastavení jeho sledování.
    Použijte komentáře (#) k vysvětlení složitých pravidel pro své kolegy.
    Použijte git status, abyste zjistili, zda jsou vaše ignorované soubory sledovány.
    Pamatujte: .gitignore ovlivňuje pouze soubory, které Git ještě nesleduje.
    Syntaxe vzoru
    Zde jsou některé běžné vzory a jak se shodují:

    Vysvětlení vzoru/Příklady shod
    Prázdné řádky jsou ignorovány

    text comment Řádky začínající znakem # jsou ignorovány

    name Všechny soubory name, složky name a soubory a složky v libovolné složce name /name.log
    /name/file.txt
    /lib/name.log
    name/ Končící znakem / určuje, že vzor je pro složku. Hledá všechny soubory a složky v libovolné složce s názvem /name/file.txt
    /name/log/name.log

    neshoda:
    /name.log
    name.file Všechny soubory s názvem name.file /name.file
    /lib/name.file
    /name.file Počínaje / určuje vzor, ​​který odpovídá pouze souborům v kořenové složce /name.file

    neshoda:
    /lib/name.file
    lib/name.file Vzory určující soubory v konkrétních složkách jsou vždy relativní vůči kořenovému adresáři (i když nezačínáte s / ) /lib/name.file

    neshoda:
    name.file
    /test/lib/name.file
    **/lib/name.file Počínaje ** před / určuje, že odpovídá jakékoli složce v repozitáři. Nejen v kořenovém adresáři. /lib/name.file
    /test/lib/name.file
    /name Všechny složky s názvem a soubory a složky v libovolné složce s názvem /name/log.file /lib/name/log.file /name/lib/log.file /lib//name Všechny složky s názvem a soubory a složky v libovolné složce s názvem ve složce lib. /lib/name/log.file
    /lib/test/name/log.file
    /lib/test/ver1/name/log.file

    žádná shoda:
    /name/log.file
    *.file Všechny soubory s příponou .file /name.file
    /lib/name.file
    *name/ Všechny složky končící na název /příjmení/log.file
    /jméno/log.file
    name?.file ? odpovídá jednomu nespecifickému znaku /names.file
    /name1.file

    neshoda:
    /names1.file
    name[a-z].file [range] odpovídá jednomu znaku v zadaném rozsahu (v tomto případě znaku v rozsahu a-z a také číselnému.) /names.file
    /nameb.file

    neshoda:
    /name1.file
    name[abc].file [set] odpovídá jednomu znaku v zadané sadě znaků (v tomto případě a, b nebo c) /namea.file
    /nameb.file

    neshoda:
    /names.file
    name[!abc].file [!set] odpovídá jednomu znaku, s výjimkou znaků specifikovaných v sadě znaků (v tomto případě a, b nebo c) /names.file
    /namex.file

    neshoda:
    /namesb.file
    *.file Všechny soubory s příponou .file /name.file
    /lib/name.file
    name/
    !name/secret.log ! určuje negaci nebo výjimku. Odpovídá všem souborům a

    Co je .gitattributes?
    Soubor .gitattributes je speciální soubor, který říká Gitu, jak má zacházet s konkrétními soubory ve vašem repozitáři.

    Řídí věci, jako jsou konce řádků, typy souborů, chování při slučování, vlastní nástroje pro porovnávání rozdílů a další.

    Všichni členové vašeho týmu mají stejná nastavení, protože tento soubor je verzován s vaším projektem.

    Více informací o Git LFS naleznete na příslušné stránce.

    Kdy použít .gitattributes
    Pro vynucení konzistentních zakončení řádků v různých operačních systémech
    Pro označení souborů jako binárních (aby se Git nepokoušel je slučovat ani měnit)
    Pro povolení Git LFS pro velké soubory
    Pro nastavení vlastních nástrojů pro porovnávání nebo slučování pro speciální typy souborů
    Pro řízení exportu souborů v archivech
    Vytvoření nebo úprava .gitattributes
    Přejděte do kořenového adresáře repozitáře (nebo do podsložky pro lokální pravidla).
    Vytvořte nebo upravte soubor .gitattributes.
    Přidejte pravidla, jedno na řádek, pro to, jak má Git zacházet se soubory.
    Příklad: Vynucení ukončení řádků v systému Unix pro všechny textové soubory
    *.txt text eol=lf

    Ovládání ukončení řádků
    Standardizace ukončení řádků, aby se předešlo konfliktům sloučení a poškozeným souborům v různých operačních systémech.

    Příklad: Nastavení LF pro skripty Shell
    *.sh text eol=lf
    Označení souborů jako binárních
    Řekněte Gitu, které soubory jsou binární (ne textové).

    To zabrání Gitu v pokusu o sloučení nebo změnu ukončení řádků pro tyto soubory.

    Příklad: Označení souborů PNG jako binárních
    *.png binární
    Povolení LFS pro typy souborů
    Používejte Git LFS pro velké soubory, jako jsou obrázky nebo datové sady.

    Toto říká Gitu, aby pro tyto soubory použil LFS:

    Příklad: Sledování souborů PSD pomocí LFS
    *.psd filter=lfs diff=lfs merge=lfs -text
    Vlastní nastavení rozdílů
    Řekněte Gitu, aby pro porovnání určitých typů souborů (například poznámkové bloky Markdown nebo Jupyter) použil speciální nástroj:

    Příklad: Vlastní rozdíly pro Markdown
    *.md diff=markdown
    Kontrola atributů
    Zobrazení atributů nastavených pro soubor:

    Příklad: Kontrola atributů souboru
    git check-attr –all README.md
    Pokročilé použití
    Strategie slučování: Nastavení vlastních ovladačů slučování pro složité soubory (například soubory zámků nebo poznámkové bloky).
    Export-ignore: Vyloučení souborů z archivů tar/zip vytvořených programem git archive:
    Příklad: Ignorování souborů při exportu
    docs/* export-ignore
    Tipy a osvědčené postupy
    Vzory fungují jako .gitignore (zástupné znaky atd.).
    Vložte .gitattributes do podsložek pro pravidla, která platí pouze tam.
    Změna souboru .gitattributes zpětně neopraví již commitované soubory – pro jejich aktualizaci je nutné soubory znovu přidat.
    K ladění problémů s atributy použijte příkaz git check-attr.
    Poznámka: Soubor .gitattributes je verzován s vaším projektem, takže všichni členové vašeho týmu mají stejná nastavení.

    Co je Git LFS?
    Git LFS (Large File Storage) je rozšíření pro Git, které vám pomáhá efektivně spravovat velké soubory (jako jsou videa, obrázky nebo datové sady).

    Namísto ukládání velkých souborů přímo do repozitáře ukládá LFS malý ukazatelový soubor do repozitáře a skutečný obsah uchovává na samostatném LFS serveru.

    Díky tomu je váš repozitář rychlý a malý, i když pracujete s obrovskými soubory.

    Každý, kdo naklonuje repozitář, dostane ukazatel a Git LFS podle potřeby načte skutečný obsah souboru.

    Více informací o atributech .git naleznete na příslušné stránce.
    Kdy použít Git LFS
    Kdy potřebujete verzovat velké soubory (média, datové sady, binární soubory)
    Kdy váš projekt překračuje limity velikosti souborů standardního hostingu Git
    Kdy chcete zachovat spravovatelnou a rychlou velikost repozitáře
    Instalace Git LFS
    Stáhněte si a nainstalujte Git LFS z git-lfs.github.com.
    Inicializace LFS ve vašem repozitáři:
    Příklad
    git lfs install

    Sledování souborů pomocí LFS
    Řekněte Gitu LFS, které soubory má spravovat, jejich „sledováním“. Například pro sledování všech souborů Photoshopu:
    Příklad: Sledování souborů .psd
    git lfs track „*.psd“
    Můžete sledovat jakýkoli typ souboru. Zde jsou další příklady:

    git lfs track „.zip“ git lfs track „data/.csv“
    git lfs track „images/*.{png,jpg}“
    Jak funguje LFS (.gitattributes a ukazatele)
    Když sledujete typ souboru pomocí LFS, Git přidá do souboru .gitattributes pravidlo. To Gitu řekne, aby pro tyto soubory používal LFS.

    Příklad: Záznam .gitattributes
    *.psd filter=lfs diff=lfs merge=lfs -text
    Když přidáte a commitnete sledovaný soubor, Git uloží do vašeho repozitáře malý soubor „ukazatel“. Skutečný obsah se nahraje na server LFS.

    Pokud naklonujete nebo stáhnete repozitář se soubory LFS, Git stáhne skutečný obsah ze serveru LFS (pokud máte nainstalovaný LFS).

    Přidání, potvrzení a odeslání souborů LFS
    Přidání souborů jako obvykle: git add largefile.psd
    Potvrzení: git commit -m „Přidat velký soubor“
    Odeslání: git push origin main
    Skutečná data souborů jsou uložena na serveru LFS, zatímco váš repozitář obsahuje soubor ukazatele.

    Zkontrolujte stav LFS
    Zjistěte, které soubory ve vašem repozitáři spravuje LFS:

    Příklad: Seznam souborů LFS
    git lfs ls-files
    Zrušení sledování/odebrání souborů z LFS
    Upravte .gitattributes a odeberte nebo změňte příslušný řádek.
    Spusťte příkaz untrack:
    Příklad: Zrušení sledování souboru
    git lfs untrack „*.psd“
    git add .gitattributes
    Potvrdte změnu. Soubor již nebude spravován systémem LFS (ale existující verze jsou stále uloženy v LFS).

    Tipy a osvědčené postupy
    Používejte LFS pouze pro soubory, které jsou pro běžný Git příliš velké nebo se příliš často mění.
    Před použitím zkontrolujte, zda váš poskytovatel hostingu podporuje LFS (zejména pro soukromá repozitáře).
    Sledujte svou kvótu úložiště LFS. Bezplatné tarify jsou často omezené.
    Řešení problémů
    Pokud naklonujete repozitář a místo skutečného obsahu vidíte soubory ukazatelů, ujistěte se, že je nainstalován Git LFS, a spusťte příkaz git lfs pull.
    Pokud odešlete soubor na vzdálený server, který LFS nepodporuje, zobrazí se chyba.
    Některé soubory se nemusí nahrát, pokud překročíte svou kvótu LFS.
    Varování
    Ne všichni poskytovatelé hostingu podporují LFS. Před použitím to zkontrolujte.
    Úložiště LFS je u bezplatných tarifů často omezené.

    Co je podepisování commitu?
    Podepsání commitu je jako vložení osobního podpisu na vaši práci.

    Dokazuje to, že jste změnu skutečně provedli, a pomáhá to ostatním důvěřovat vašemu kódu.

    Na platformách jako GitHub nebo GitLab podepsané commity často získají odznak Ověřeno.

    Co je GPG?
    GPG (GNU Privacy Guard) je nástroj, který vám umožňuje vytvořit digitální klíč, něco jako tajné heslo, k podepisování věcí.

    Git používá klíče GPG k podepisování commitu a tagů.

    To pomáhá prokázat vaši identitu a zajistit, aby s vaším kódem nebyla manipulována.

    Proč a kdy byste měli podepisovat commity?
    Abyste dokázali, že vaše commity skutečně pocházejí od vás
    Aby ostatní mohli důvěřovat vašemu kódu (zejména v open source projektech)
    Některé společnosti nebo projekty vyžadují podepsané commity z bezpečnostních důvodů
    Pokud je nepodepíšete, vaše commity jsou stále platné, jen ne ověřené
    Jak nastavit podepisování commitů
    Vytvořte si GPG klíč (pokud ho nemáte):

    Příklad: Generování nového GPG klíče
    gpg –full-generate-key
    Postupujte podle pokynů k vytvoření klíče.

    Najděte ID svého klíče:

    Příklad: Seznam GPG klíčů
    gpg –list-secret-keys –keyid-format=long
    Hledejte řádek jako sec rsa4096/1234ABCD5678EFGH. Část za lomítkem je vaše ID klíče.

    Řekněte Gitu, aby použil váš klíč:

    Příklad: Nastavení podpisového klíče
    git config –global user.signingkey

    Jak podepisovat commity a tagy
    Chcete-li podepsat commit, použijte:

    git commit -S -m „message“
    Chcete-li podepsat tag, použijte:

    git tag -s v1.0 -m „version 1.0“
    Automaticky podepsat všechny commity
    Pokud chcete, aby Git ve výchozím nastavení podepsal každý commit, spusťte:

    git config –global commit.gpgSign true
    Jak zkontrolovat, zda je commit podepsán
    Chcete-li se v Gitu podepsat, spusťte:

    git log –show-signature
    Na GitHubu nebo GitLabu hledejte vedle svého commitu nebo tagu odznak Ověřeno.

    Příklad: Podepsaný commit v protokolu Git
    commit 1234abcd5678efgh
    gpg: Podpis vytvořen …
    gpg: Dobrý podpis od „Vaše jméno „
    Autor: Vaše jméno
    Datum: …
    Řešení problémů s podepsanými commity
    GPG se nepodařilo podepsat data: Ujistěte se, že váš agent GPG běží a váš klíč je načten.
    Použit nesprávný klíč: Zkontrolujte ID klíče, které jste nastavili v Gitu.
    Stále se mýlíte? Zkuste vyhledat chybovou zprávu online nebo zkontrolujte instalaci Gitu a GPG.
    Poznámka: Podepsané commity a tagy pomáhají zajistit, aby váš kód nebyl pozměněn, a potvrzují vaši identitu jako autora.

    Některé platformy mohou vyžadovat další nastavení pro rozpoznání vašeho podpisu (například nahrání vašeho veřejného klíče na GitHub nebo GitLab).

    Co je Cherry-pick?
    Cherry-pick umožňuje kopírovat jeden commit z jedné větve do druhé. Je užitečný, když chcete pouze jednu (nebo několik) změn, ne vše z jiné větve.

    Co je Patch?
    Patch je soubor se změnami z jednoho nebo více commitů. Patch můžete sdílet nebo jej aplikovat na jiný repozitář, i když s vaším vlastním nesouvisí.

    Kdy použít který
    Použijte cherry-pick ke kopírování commitu mezi větvemi ve stejném repozitáři.
    Používejte patche ke sdílení změn jako souborů nebo při práci napříč různými repozitáři.
    Jak použít Cherry-pick Commit
    Zkopírujte konkrétní commit z jiné větve do vaší aktuální větve:

    Příklad: Cherry-pick a Commit
    git cherry-pick abc1234
    Tímto se vytvoří nový commit ve vaší větvi se stejnými změnami.

    Úprava zprávy commitu
    Pomocí –edit můžete změnit zprávu commitu během výběru:

    Příklad: Upravit zprávu commitu
    git cherry-pick abc1234 –edit
    Použít bez commitu
    Použít –no-commit (nebo -n) můžete změny aplikovat, ale ještě nevytvořit commit. To vám umožní provést další změny před commitem:

    Příklad: Cherry-pick bez commitu
    git cherry-pick abc1234 –no-commit
    Přidat původ commitu
    Použít -x můžete do zprávy commitu přidat řádek s uvedením původu commitu:

    Příklad: Cherry-pick s původem
    git cherry-pick abc1234 -x
    Řešení konfliktů
    Pokud dojde ke konfliktům, Git se pozastaví a požádá vás o jejich opravu. Po opravě spusťte:

    Příklad: Pokračovat po konfliktu
    git add .
    git cherry-pick –continue
    Chcete-li zrušit výběr cherry-pick, použijte:

    Příklad: Zrušit výběr cherry-pick
    git cherry-pick –abort
    Jak vytvořit záplatu
    Vytvořit soubor záplaty z commitu:

    Příklad: Vytvořit záplatu
    git format-patch -1 abc1234
    Pro více commitů:

    Příklad: Více commitů
    git format-patch HEAD~3
    Jak použít záplatu
    Použití souboru záplaty na aktuální větev:

    Příklad: Použití záplaty
    git apply 0001-some-change.patch
    Použití záplaty a zachování metadat
    Použití záplaty a zachování původního autora a zprávy pomocí git am:

    Příklad: Použití záplaty s metadaty
    git am 0001-some-change.patch
    Vrácení záplaty
    Vrácení změn v souboru záplaty:

    Příklad: Vrácení záplaty
    git apply -R 0001-some-change.patch
    Tip: Použijte cherry-pick pro kopírování jednoho commitu do stejného repozitáře.

    Používejte záplaty ke sdílení změn jako souborů nebo k práci napříč repozitáři.

    Pokud chcete zachovat historii commitů a autory, použijte git am místo git apply.

    Řešení problémů a osvědčené postupy
    Konflikty typu „cherry-pick“: Pokud se vyskytnou konflikty, opravte je a poté spusťte git cherry-pick –continue.
    V případě potřeby přerušte operaci pomocí git cherry-pick –abort.
    Záplata se neaplikuje čistě: Ujistěte se, že záplata odpovídá vaší kódové základně. Někdy může být nutné provést ruční úpravy.
    Udržujte své větve aktuální: Před výběrem nebo aplikací záplat stáhněte nejnovější změny.

    Co je to konflikt sloučení?
    Konflikt sloučení nastává, když dvě větve změní stejnou část souboru.

    Git se nedokáže rozhodnout, kterou změnu ponechat, takže si musíte vybrat vy.

    Než budete moci sloučení dokončit, musíte konflikt vyřešit.

    Proč dochází ke konfliktům sloučení?
    Konflikty sloučení obvykle nastávají, když sloučíte větve, které změnily stejné řádky v souboru.

    To je běžné u kolaborativních projektů nebo při práci na dlouhotrvajících větvích.

    Jak zobrazit a vyřešit konflikty sloučení
    Když sloučíte větev a dojde ke konfliktním změnám, Git pozastaví a označí soubory konflikty.

    Příklad: Sloučení větve
    git merge feature-branch
    Pokud dojde ke konfliktům, Git vám sdělí, které soubory jsou ovlivněny.

    Zobrazení konfliktních souborů
    Použijte příkaz git status k zobrazení souborů, které vyžadují vaši pozornost:

    Příklad: Kontrola stavu
    git status

    Zobrazení rozdílů
    Použijte příkaz git diff k zobrazení změn a k rozhodnutí, jak konflikt vyřešit:

    Příklad: Zobrazení rozdílů
    git diff
    Úprava značek konfliktů
    Otevřete konfliktní soubor. Zobrazí se vám sekce podobné této:

    Značky konfliktů
    <<<<<<< HEAD

    Vaše změny zde

    Změny v dalších větvích

    feature-branch
    Upravte soubor tak, aby zachoval požadované změny, a poté odstraňte značky konfliktů (<<<<<<<, =======, >>>>>>>).

    Označit jako vyřešené
    Po opravě souboru jej označte jako vyřešený:

    Příklad: Označit jako vyřešené
    git add název_souboru.txt
    Dokončit sloučení
    Dokončit sloučení pomocí commitu (pokud to Git neprovede automaticky):

    Příklad: Dokončit sloučení
    git commit
    Zrušit sloučení
    Pokud chcete sloučení zastavit a vrátit zpět:

    Příklad: Zrušit sloučení
    git merge –abort
    Použití vizuálního nástroje pro sloučení
    Pokud chcete, můžete k řešení konfliktů použít vizuální nástroj:

    Příklad: Použití nástroje Mergetool
    git mergetool
    Vybrat změny jedné strany
    Pokud chcete zachovat pouze vaše změny nebo pouze změny druhé větve:

    Příklad: Zachovat naše změny
    git checkout –ours název_souboru.txt
    Příklad: Zachovat jejich změny
    git checkout –theirs název_souboru.txt
    Řešení problémů a osvědčené postupy
    Pokud se zaseknete, můžete vždy použít git merge –abort k opětovnému zahájení.
    Před označením konfliktu jako vyřešeného se ujistěte, že jste odstranili všechny značky konfliktu.
    Pokud použijete git mergetool a výsledek se vám nelíbí, můžete soubory stále upravovat ručně.

    Co je CI/CD?
    CI/CD je zkratka pro Continuous Integration a Continuous Deployment/Delivery (Kontinuální integrace a Kontinuální nasazení/dodání).

    To znamená, že váš kód je automaticky testován a nasazen při každém odeslání.

    To vám pomůže odhalit chyby včas a dodat funkce rychleji s menší manuální prací.

    Proč používat CI/CD?
    CI/CD automatizuje proces testování a nasazení vašeho kódu. To znamená:

    Najít chyby dříve, než se dostanou k uživatelům
    Nasadit změny rychleji a bezpečněji
    Omezit manuální kroky a chyby
    Získat rychlou zpětnou vazbu při každém odeslání
    Jak CI/CD funguje s Gitem?
    Pokaždé, když odešlete kód do svého repozitáře Git:

    Služba CI/CD (jako GitHub Actions nebo GitLab CI) detekuje změnu
    Spustí testy, sestaví váš projekt a může jej automaticky nasadit
    Pokud se něco nezdaří, budete okamžitě upozorněni
    Příklad pracovního postupu
    [Vývojář] –push–> [Git Repository] –triggers–> [CI/CD Pipeline: Test, Build, Deploy]
    Populární služby CI/CD
    GitHub Actions: Vestavěné do GitHubu, používají soubory YAML v .github/workflows/
    GitLab CI/CD: Vestavěné do GitLabu, používá .gitlab-ci.yml
    CircleCI: Funguje s GitHub/GitLab, snadné nastavení pro mnoho jazyků
    Travis CI: Populární pro open-source, používá .travis.yml
    Azure Pipelines: Funguje s Azure DevOps a GitHub, podporuje mnoho platforem
    Klíčové koncepty CI/CD
    Zde jsou některé důležité pojmy:

    Pracovní postup: A série úloh, které běží společně
    Úloha: Skupina kroků, které běží společně
    Krok: Jeden úkol, například kontrola kódu nebo spuštění testů
    Běžec: Počítač/server, který spouští vaše úlohy
    Spouštěč: Rozhoduje, kdy se váš pracovní postup spustí
    Proměnné prostředí: Nastavení pro váš pracovní postup
    Tajemství: Hesla nebo klíče API
    Úlohy
    Úloha je skupina kroků, které běží společně. Každá úloha běží na běžci (serveru).

    Příklad: Úloha v GitHubu Akce
    jobs:
    build:
    runs-on: ubuntu-latest
    steps:

    kroků sem

    Kroky
    Každý krok je jeden úkol, například kontrola kódu nebo spuštění testů.

    Příklad: Kroky
    steps:

    • použití: actions/checkout@v3
    • název: Spustit testy
      run: npm test
      Běžeci
      Běžec je počítač/server, který spouští vaše úlohy.

    Můžete použít běžce služby nebo si nastavit vlastní pro větší kontrolu.

    Příklad: Zadejte běžec
    runs-on: ubuntu-latest
    Spouštěče
    Spouštěč určuje, kdy se váš pracovní postup spustí.

    Běžné spouštěče jsou push (každé push) a pull_request (při otevření nebo aktualizaci požadavku na pull).

    Příklad: Spouštěč při požadavku na push nebo pull
    on:

    push:

    pull_request:

    Proměnné a tajné identifikátory prostředí
    Pro nastavení používejte proměnné prostředí a tajné identifikátory pro hesla nebo klíče API.

    Nikdy nezakódujte tajné identifikátory napevno ve svém kódu!

    Příklad: Použijte tajný identifikátor
    env:
    NODE_ENV: production
    API_KEY: ${{ secrets.API_KEY }}
    Záznamy sestavení
    Nástroje CI/CD zobrazují protokoly pro každou úlohu a krok. Zkontrolujte protokoly, abyste zjistili, co se stalo, nebo abyste ladili chyby.

    V Akcích GitHubu klikněte na spuštění pracovního postupu a zobrazte protokoly pro každou úlohu/krok.

    Přeskočení CI
    CI/CD můžete pro commit přeskočit přidáním [skip ci] do zprávy commitu.

    Toto je užitečné pro dokumentaci nebo drobné změny.

    Příklad: Přeskočit CI
    git commit -m „Aktualizovat dokumentaci [skip ci]“
    Odznaky
    Přidejte do souboru README odznak, který ukazuje stav CI/CD.

    To umožňuje ostatním vidět, zda vaše nejnovější sestavení prošlo.

    Příklad: Odznak akcí GitHub
    CI
    Příklad: Soubor workflow akcí GitHub (vysvětlení)

    .github/workflows/ci.yml

    Tento soubor říká akcím GitHub, jak spustit CI pro váš projekt

    name: CI # Název workflowu (zobrazuje se v GitHubu)
    on: [push] # Trigger: spustit tento workflow při každém push
    jobs:
    build: # Název úlohy (může být jakýkoli)
    runs-on: ubuntu-latest # Runner: použít nejnovější server Ubuntu
    steps:

    • uses: actions/checkout@v3 # Step: zkontrolovat kód z repozitáře
    • name: Spustit testy # Step: pojmenovat tento krok
      run: npm test # Step: spustit testy vašeho projektu

    name: Nastaví zobrazovaný název workflowu v GitHubu.
    on: Rozhoduje o spuštění pracovního postupu (zde: každé načtení).
    jobs: Seskupuje kroky, které se spouštějí na běžci.
    build: Název této úlohy (může být libovolný).
    runs-on: Vybírá typ serveru (zde: Ubuntu Linux).
    steps: Každý krok provádí jednu věc, například kontrolu kódu nebo spuštění testů.
    uses: Používá předpřipravenou akci GitHubu (zde: kontroluje váš kód).
    name: (v části steps) Dává kroku popisek.
    run: Spustí příkaz shellu (zde: npm test pro spuštění testů).
    Řešení problémů a osvědčené postupy
    Pokud sestavení selže, zkontrolujte protokoly, zda neobsahují chybové zprávy.
    Ujistěte se, že jsou vaše tajné kódy a proměnné prostředí správně nastaveny. Neúspěšné úlohy můžete znovu spustit z dashboardu CI/CD. Další pomoc naleznete v dokumentaci k vaší službě CI/CD.
    Začněte v malém: nejprve automatizujte testy a poté přidejte nasazení, až budete připraveni.
    Udržujte tajné kódy mimo kód a nikdy neposkytujte klíče API.
    Používejte odznaky k zobrazení stavu sestavení v souboru README.
    Poznámka: CI/CD pomáhá včas odhalit chyby a urychluje dodání. Automatizace může prospět i malým projektům!

    Co jsou Git Hooky?
    Git Hooky jsou skripty, které se spouštějí automaticky, když dojde k určitým událostem v Gitu, jako je vytvoření commitu nebo odeslání kódu.

    Proč používat hooky?
    Hooky vám pomáhají automatizovat opakující se úkoly, vynucovat standardy kódování a včas odhalovat problémy.

    Můžete například:

    Spouštět testy před každým commitem nebo odesláním
    Automaticky kontrolovat styl kódu
    Blokovat zprávy o chybných commitech
    Vynucovat pravidla pro všechny členy vašeho týmu
    Kde se hooky nacházejí?
    Hooky jsou uloženy v souboru .git/hooks ve vašem repozitáři.

    Ve výchozím nastavení se zobrazí ukázkové skripty končící na .sample.

    Příklad: Seznam dostupných hooků
    ls .git/hooks
    Jak povolit hook
    Chcete-li povolit hook, odeberte příponu .sample a nastavte skript jako spustitelný.

    Například pro povolení pre-commitu:

    Příklad: Povolení pre-commitu (Linux/macOS)
    mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
    chmod +x .git/hooks/pre-commit
    Ve Windows stačí soubor přejmenovat na pre-commit a ujistit se, že jej lze spustit vaším shellem (např. v případě potřeby použijte .bat nebo .ps1).

    Typy hooků
    Existuje mnoho typů hooků, ale nejběžnější jsou:

    pre-commit
    commit-msg
    pre-push
    pre-receive
    post-receive
    pre-commit Hook
    Hook pre-commit se spustí před provedením commitu.

    Můžete ho použít ke kontrole stylu kódu, spuštění testů nebo zastavení commitu, pokud je něco špatně.

    Příklad: Jednoduchý hook pre-commit

    !/bin/sh

    Zastavit commit, pokud jakýkoli soubor .js obsahuje „console.log“

    grep -r ‚console.log‘ *.js && {
    echo „Odebrat console.log před commitem!“
    exit 1
    }
    hook commit-msg
    Hook commit-msg kontroluje nebo upravuje zprávu commitu.

    Může například blokovat commity bez čísla tiketu.

    Příklad: hook commit-msg

    !/bin/sh

    Blokovat commit, pokud zpráva neobsahuje číslo tiketu

    if ! grep -qE ‚JIRA-[0-9]+‘ „$1“; then
    echo „Zpráva commitu musí mít číslo tiketu (např. JIRA-123)“
    exit 1
    fi
    hook pre-push
    Hook pre-push se spustí před odesláním kódu na vzdálený server.

    Můžete jej použít ke spuštění testů nebo kontrol před sdílením kódu.

    Příklad: pre-push Hook

    !/bin/sh

    npm test || exit 1
    Serverové hooky
    Některé hooky (například pre-receive) běží na serveru Git, nikoli na vašem počítači.

    Ty mohou vynutit pravidla pro každého, kdo odesílá data do repozitáře.

    Příklad: pre-receive Hook

    !/bin/sh

    Blok odesílá data do hlavní větve

    grep refs/heads/main || exit 1
    Vlastní hooky
    Jako hook můžete napsat libovolný vlastní skript.

    Stačí ho vložit do .git/hooks a nastavit ho jako spustitelný.

    Příklad: Vlastní hook

    !/bin/sh

    echo „Zdravím z mého vlastního hooku!“
    Ladění a osvědčené postupy
    Ujistěte se, že váš hook skript je spustitelný (chmod +x název_skriptu).
    Přidejte příkazy echo, abyste viděli, co váš skript dělá.
    Zkontrolujte kód ukončení: exit 0 znamená úspěch, exit 1 znamená selhání.
    Ve Windows v případě potřeby použijte skripty .bat nebo .ps1.
    Udržujte hooky jednoduché a rychlé – pomalé hooky zpomalují váš pracovní postup. Sdílejte užitečné hooky se svým týmem (ale nezapomeňte: hooky nemají ve výchozím nastavení verzovací kód). Poznámka: Hooky jsou účinné pro automatizaci kontrol (jako je linting nebo testování) a vynucování standardů týmu. Hooky na straně klienta běží na vašem počítači. Hooky na straně serveru běží na serveru Git.

    Co jsou submoduly Gitu?
    Submoduly Gitu umožňují vložit jeden repozitář Gitu do jiného jako podadresář.

    To je užitečné pro přidávání knihoven nebo závislostí spravovaných v samostatných repozitářích a zároveň zachovat oddělenou historii jejich commitu.

    Proč používat submoduly?
    Submoduly jsou užitečné, když chcete:

    Znovu použít kód z jiného projektu
    Sledovat knihovnu nebo závislost v konkrétním commitu
    Uchovávat oddělenou historii projektů
    Jak přidat submodul
    Chcete-li do projektu přidat submodul, použijte:

    Příklad: Přidání submodulu
    git submodule add https://github.com/example/library.git libs/library
    Tím se vytvoří podadresář libs/library a aktualizuje se soubor .gitmodules informacemi o submodulu.

    Jak klonovat repozitář se submoduly
    Když klonujete repozitář se submoduly, musíte načíst jejich obsah samostatně:

    Příklad: Inicializace a aktualizace submodulů
    git submodule init
    git submodule update
    Nebo to proveďte najednou při klonování:

    Příklad: Klonování se submoduly
    git clone –recurse-submodules https://github.com/user/repo.git

    Jak zkontrolovat stav submodulu
    Chcete-li zobrazit aktuální commit a stav vašich submodulů, použijte:

    Příklad: Stav submodulu
    git submodule status
    Jak spustit příkazy ve všech submodulech
    Příkaz můžete spustit v každém submodulu. Například pro kontrolu jejich stavu:

    Příklad: foreach
    git submodule foreach git status
    Jak aktualizovat submoduly
    Pro aktualizaci submodulů na nejnovější commit z jejich vzdáleného repozitáře:

    Příklad: Aktualizovat všechny submoduly
    git submodule update –remote
    Jak odebrat submodul
    Pro odebrání submodulu:

    Smažte příslušnou sekci ze souboru .gitmodules
    Odstraňte adresář submodulů z pracovního stromu
    Spusťte git rm –cached cesta/k/submodule
    O souboru .gitmodules
    Soubor .gitmodules sleduje všechny submoduly a jejich cesty. Upravte tento soubor, pokud submoduly přesouváte nebo odebíráte.

    Příklad: Soubor .gitmodules
    [submodule „libs/library“]
    path = libs/library
    url = https://github.com/example/library.git
    Řešení problémů a osvědčené postupy
    Pokud jsou submoduly po klonování prázdné, spusťte git submodule update –init –recursive.
    Pokud změníte URL submodulu, aktualizujte soubory .gitmodules i .git/config.
    Submoduly vždy odkazují na konkrétní commit, ne vždy na nejnovější – nezapomeňte je aktualizovat, pokud chcete nové změny.
    Submoduly pro externí projekty, které chcete sledovat, ponechte v pevné verzi. Pro jednodušší potřeby zvažte alternativy, jako je Git subtree nebo kopírování souborů.
    Poznámka: Submoduly jsou výkonné, ale jejich správa může být složitá.

    Používejte je pouze v případě, že skutečně potřebujete sledovat jiný projekt v konkrétním commitu.

    Co jsou Git Remotes?
    Vzdálené moduly odkazují na vzdálené repozitáře.

    Umožňují vám spolupracovat, načítat a odesílat kód do sdílených projektů na službách jako GitHub, GitLab nebo Bitbucket.

    Proč používat více vzdálených modulů?
    Do projektu můžete přidat více než jeden vzdálený modul. Toto je užitečné pro:

    Spolupráci s různými týmy (např. váš fork a hlavní projekt)
    Zrcadlení repozitářů
    Údržbu záloh
    Jak přidat vzdálený úložiště
    Chcete-li přidat nové vzdálené repozitář:

    Příklad: Přidat vzdálený úložiště
    git remote add upstream https://github.com/other/repo.git
    Jak odebrat vzdálený úložiště
    Chcete-li odebrat vzdálený repozitář:

    Příklad: Odebrat vzdálený úložiště
    git remote remove upstream
    Jak přejmenovat vzdálený úložiště
    Chcete-li změnit název existujícího vzdáleného úložiště (například přejmenováním origin na main-origin):

    Příklad: Přejmenovat vzdálený úložiště
    git remote rename origin main-origin

    Jak zobrazit seznam všech vzdálených úložiště
    Zobrazit všechny vzdálené úložiště a jejich adresy URL:

    Příklad: Zobrazit seznam vzdálených úložiště
    git remote -v
    Jak zobrazit podrobnosti o vzdáleném úložišti
    Získejte podrobné informace o konkrétním vzdáleném úložišti (například adresy URL pro načtení/odeslání a sledované větve):

    Příklad: Zobrazit informace o vzdáleném úložišti
    git remote show upstream
    Jak načíst ze vzdáleného úložiště
    Načíst změny z libovolného vzdálené:

    Příklad: Načtení z Upstreamu
    git fetch upstream
    Jak odeslat na vzdálený server
    Odešlete svou lokální větev do konkrétního vzdáleného repozitáře:

    Příklad: Odešlete na vzdálený server
    git push upstream main
    Jak sledovat vzdálenou větev
    Chcete-li nastavit lokální větev pro sledování větve ze vzdáleného serveru:

    Příklad: Sledování vzdálené větve
    git checkout -b new-feature upstream/new-feature
    Poznámka: Správa více vzdálených serverů je běžná v open source projektech (např. origin pro váš fork, upstream pro hlavní projekt).

    Řešení problémů a osvědčené postupy
    Pokud se vám zobrazí zpráva „remote not found“ (vzdálený server nenalezen), zkontrolujte pravopis názvu vzdáleného serveru pomocí git remote -v.
    Pokud načtení nebo odeslání selže, ujistěte se, že máte přístup ke vzdálenému repozitáři.
    Pro zobrazení podrobností a řešení problémů použijte git remote show .
    Pokud se nemůžete dostat ke vzdálenému serveru, zkontrolujte síťové připojení.
    Pro vzdálené servery používejte jasné a popisné názvy (např. origin, upstream, backup).
    Odstraňte nepoužívané vzdálené servery, abyste udrželi projekt v pořádku.

    Osnova Git
    Úvod
    Tutoriál W3Schools Git je komplexní a vhodný pro začátečníky.

    Poskytne vám základní znalosti o správě verzí v Gitu.

    Je určen pro začátečníky a nevyžaduje žádné předchozí zkušenosti se správou verzí.

    Obsah byl pečlivě vytvořen tak, aby byl stručný, jednoduchý a snadno srozumitelný.

    Obsah byl v průběhu let ověřen miliony uživatelů. Je často aktualizován a vylepšován.

    Osnova osnov a jejich posloupnost jsou strukturovány tak, abyste se mohli Git učit krok za krokem, od úvodu až po pokročilé funkce.

    Výukové cíle
    Pochopte základní koncepty správy verzí pomocí Gitu.
    Vytvářejte a spravujte repozitáře Git.
    Sledujte změny a spravujte verze souborů.
    Práce s větvemi a slučováním.
    Spolupráce s ostatními vývojáři.
    Efektivně používejte příkazy Gitu.
    Řešte konflikty a řešení problémů.
    Práce se vzdálenými repozitáři.
    Poznámka: Jste učitel, který vyučuje Git? W3Schools Academy je sada nástrojů, které vám mohou pomoci s výukou. Nabízí funkce pro výuku, jako jsou předpřipravené studijní plány, administrace výuky a mnoho dalšího. Více o Akademii si přečtěte zde.

    Pro které předměty je Git relevantní?
    Vývoj softwaru:
    Git je nezbytný pro správu verzí kódu a spolupráci.
    DevOps:
    Git je základem pro průběžnou integraci a nasazování.
    Řízení projektů:
    Git pomáhá sledovat změny a příspěvky v projektech.
    Týmová spolupráce:
    Git umožňuje spolupráci více vývojářů.
    Revize kódu:
    Git poskytuje nástroje pro kontrolu a diskusi o kódu.
    Dokumentace:
    Git pomáhá udržovat verze dokumentace.
    Open Source:
    Git je klíčový pro vývoj s otevřeným zdrojovým kódem.

    Aktivity
    V tomto tutoriálu nabízíme různé aktivity, abyste se mohli zdarma naučit Git:

    Lekce
    Cvičení
    Kvízy
    Přihlaste se pro sledování pokroku
    Můžete si také vytvořit bezplatný účet pro sledování svého pokroku.

    Jako přihlášený uživatel získáte přístup k funkcím, jako jsou:

    Výukové programy
    Prostředí sandbox a laboratorní prostředí
    Úspěchy
    A mnohem více!

    Přehled modulů
    DOMŮ Git
    Úvod do Gitu
    Začínáme s Gitem
    Nové soubory v Gitu
    Prostředí pro testování Gitu
    Git Commit
    Nápověda k Gitu
    Větev Git
    Sloučení větví Git
    Začínáme s GitHubem
    Úprava kódu na GitHubu
    Stažení z GitHubu
    Odeslání na GitHub
    Větev GitHubu
    Stažení větve z GitHubu
    Odeslání větve na GitHub
    Tok GitHubu
    Stránky GitHubu
    Fork GitHubu
    Klonování Gitu z GitHubu
    Odeslání žádosti o stažení z GitHubu
    Git .gitignore
    Zabezpečení Gitu SSH
    Přidání SSH na GitHub
    Obnovení Gitu
    Reset Gitu
    Úprava Gitu

    Sandbox a laboratorní prostředí
    Pokud chcete hostovat svůj projekt, máme funkci s názvem Spaces, která vám umožní procvičovat si příkazy Gitu a spravovat repozitáře.

    Zde získáte bezpečné sandboxové prostředí s názvem Spaces, které se integruje s GitHubem, kde si můžete procvičovat Git a testovat příkazy v reálném čase.

    Spaces vám umožňuje testovat, commitovat a spravovat repozitáře. To zahrnuje subdoménu W3Schools, hosting a zabezpečené SSL certifikáty.

    Spaces nevyžadují žádnou instalaci a běží přímo v prohlížeči.

    Funkce zahrnují:

    Spolupráce
    Navigátor souborů
    Terminál a protokol
    Správce balíčků
    Databáze
    Správce prostředí
    Analytika
    Dynamické Spaces

    Certifikace Git
    W3Schools nabízí certifikační program na konci cesty.

    Zde můžete složit zkoušky pro získání certifikace.

    Zkouška Git je test, který shrnuje osnovy W3Schools Git.

    Po složení zkoušky získáte certifikaci „Certifikovaný vývojář Git“.

    Certifikační zkouška je adaptivní a hodnocená; studenti získají známku od středně pokročilého, pokročilého až po profesionálního.