git

Drupal oznámil partnerství se službou GitLab

petr — Tue, 21 Aug 2018 17:02:17 +0000

Drupal oznámil partnerství se službou GitLab

Oznámení je součástí dlouhodobého procesu hledání vylepšení infrastruktury pro všechny Drupal vývojáře. Po přesunu kódu na GitLab se postupně otevřou nové, snažší možnosti pro spolupráci.

Minulý rok byl připraven scénář výběru "Drupal Flow" nejvhodnějšího nástroje. Byl zpracován bez ohledu na stávající možnosti/vlastnosti nejznámějších služeb. Scénář byl pak s představitely těchto služeb (GitHub, BitBucket a GitLab) probrán a u každého byly sepsány jeho klady a zápory. Výsledekem zmíněného šetření byl výběr BitBucketu, který jako jediný neměl velké překážky pro integraci.

Nicméně, tým GitLabu se obrátil přímo na Drupal Asociaci, s tím, že má zájem uvedené problémy vyřešit. Šanci dostal mj. díky tomu, že integraci s GitLabem byla více nakloněna i Drupal komunita. GitLab navíc nabídl technickou a finanční podporu pro celý proces migrace a další podpory pro Drupal jako takový.

Celá migrace se nyní připravuje a je rozdělena na tři části:

1) Nahrazení vlastní Drupal Git infrastruktury GitLabem

Některé z nových funckí (jako třeba inline editace kódu) budou v této fázi přístupné jen maintainerům projektů. Jiné (např. lepší zobrazení kódu) budou přístupné všem.

2) Zapnutí Merge requestů, Inline editace kódu a review kódu přímo v prohlížeči

Merge requesty přinesou známý proces, a tím usnadní práci všem vývojářům. Jednoduché úpravy v kódu (překlepy atp.) bude možné opravit přímo v prostředí prohlížeče. Issues na drupal.org by měly být synchroní s těmi na GitLabu.

3) Zhodnocení dalších funkcí

Po prvních dvou fázích přijde prostor pro komunitu a její návrhy na přidávání dalších funkcí. Chceme nahradit Drupal CI pomocí GitLab CI?

Již probíhající změny v Git Remote

Ověřování heslem pro Git je zastaralé. Doporučujeme, aby všichni uživatelé začli používat ověřování klíčem SSH.

Byly změněny vzdálené adresy URL pro push do plných projektů:
Pokud máte vytvořený Git remote ve formátu
<username> @ git.drupal.org: project / <yourproject> .git
formát by měl být změněn na:
[email protected]: project / <yourproject> .git
HTTPS adresy pro plné projekty zůstavají beze změn.
HTTPS adresy a Git remote URL pro sandbox projekty se změnily:
Pro Remote:
<username> @ git.drupal.org: sandbox / <username> / <node-id> .git
formát by měl být změněn na:
[email protected]: sandbox / <username> - <nodeid> .git
HTTPS url se budou měnit z:
https://git.drupal.org/sandbox/<username>/<nodeid>.git
na formát:
https://git.drupal.org/sandbox/<username>-<nodeid>.git

Důležité: Pokud máte libovolné automatizované systémy, které se autentizují na Git, jako jsou CI Pipelines nebo zrcadlení repozitářů, ujistěte se, že jsou také aktualizovány.

Podrobnější informace o těchto změnách, stejně jako instrukce pro změnu Git remote nebo nastavení klíčů SSH, naleznete v těchto pokynech: https://drupal.org/gitauth

Originální článek v angličtině.

petr Út, 08/21/2018 - 19:02

drupal

git

gitlab

Přidat komentář

Git - používání větví

pepino710 — Sun, 04 Mar 2018 20:40:18 +0000

Git - používání větví pepino710 Ne, 03/04/2018 - 21:40

Koncept tzv. větví či větvení (anglicky branches) je pro Git naprosto esenciální. Jakmile příkazem git init založíte nový lokální repozitář, Git pro vás na pozadí automaticky vytvoří první větev kódu - master.

Koncept větví si můžete jednoduše představit jako strom. Větev master, jakožto první větev, představuje pomyslný kmen a z něj je možné vytvořit neomezené množství větví, a stejně tak z těchto větví je možné vytvořit neomezené množství dalších větví, atd.

Každá větev představuje svůj vlastní prostor, ve kterém probíhá verzování kódu. Tzv. odvětvením přebírá nová větev aktuální stav kódu v původní větvi, nicméně další verzování na této větvi je zcela nezávislé na větvi původní.

Git umožňuje velmi jednoduše větve vytvářet, přejmenovávat, mazat, ale především umožňuje větve (resp. kód z těchto větví) slučovat. Právě možnost slučování kódu má velké praktické využití.

I když web vyvíjí jednotlivec, je velmi bezpečné vyvíjet všechny nové funkce na vlastních větvích a přitom mít v hlavní větvi, masteru, zachovaný funkční kód.
Jakmile pracujete v týmu, je používání větví naprosto nezbytnou záležitostí: jen tak má totiž každý vývojář jistotu, že nepřepisuje kód někomu jinému. V současnosti existuje mnoho metodologií definujících tzv. development workflow, kterými se můžete inspirovat.

Na závěr tohoto teoretického úvodu bych ještě rád zmínil, že kód každé větve lze poslat do vzdáleného repozitáře způsobem, jakým to bylo popsáno v předešlé kapitole, nicméně větev stejného názvu nemůže ve vzdáleném repozitáři existovat vícekrát. To znamená, že pokud budou mít dva nebo více vývojářů lokálně stejně pojmenované větve, bude moci do vzáleného repozitáře tzv. pushnout svou lokální větev jen jeden z nich (ostatní si budou muset své lokální větve přejmenovat). Aby k těmto konfliktům nedocházelo, je vhodné definovat si v rámci týmu určitou jmennou konvenci.

Syntaxe

Pokud volně navážeme na příklad repozitáře test z první kapitoly, nacházíte se ve stavu, kdy ve výchozí větvi master máte provedených několik commitů. Předpokládejme, že se ve složce projektu (test) se nacházejí verzované soubory a.txt, b.pdf, c.php.

Rozhodnete se pokračovat ve vývoji, nicméně tentokrát v nové větvi s názvem devel_css. Novou větev vytvoříte a zároveň se na ni přepnete pomocí příkazu git checkout -b devel_css.
V rámci nové větve přidáte soubory d.css a e.js a provedete commit, a to pomocí příkazů:

> d.css e.js
git add .
git commit -m “Added files d.css and e.js.”

Po provedení commitu jste tedy v nové větvi devel_css o jeden commit napřed oproti původní větvi master. Stav můžete zkontrolovat standardně pomocí příkazů git status a git log -n 5. Přehled všech existujících lokálních větví získáte příkazem git branch. Případně přehled všech vzdálených větví (větve ze vzdáleného repozitáře) příkazem git branch -r. Přehled všech větví, tedy lokálních a vzdálených, získáte příkazem git branch -a.

Přepínat se mezi existujícími větvemi můžete jednoduše příkazem git checkout [název větve]. V našem případě se zpět na větev master přepnete pomocí příkazu git checkout master.
Všimněte si, že po přepnutí na větev master se ze složky projektu ztratily soubory d.css a e.js. Je to jednoduše proto, že tyto soubory ve větvi master neexistují.

Při přepínání mezi větvemi musí být vaše pracovní složka (working directory) čistá - tedy ve stavu, kdy příkaz git status vrací hlášku nothing to commit, working directory clean.
Pokud jsou v pracovním adresáři modifikované nebo staged soubory, git vám nedovolí se přepnout na jinou větev, dokud na aktivní větvi neprovedete commit. Příkaz git checkout [název existující větve] vám v takovém případě vrátí chybovou hlášku Your local changes to the following files would be overwritten by checkout.

V případě nových, dosud neverzovaných souborů (tzv. untracked files) vám ovšem git přepnutí na jinou větev dovolí. Je to tím, že neverzovaný soubor dosud nepatří do žádné větve, a tudíž na něj přepínání větví nemá vliv.

Ve větvi master nyní vytvořte další nový soubor s názvem f.yaml a znovu proveďte commit. Tím se dostanete do stavu, kdy je v obou větvích nový commit, avšak v každé větvi jde o úplně jinou věc, resp. jiný kód.

Předpokládejme nyní, že jste změnili názor a chcete větev devel_css přejmenovat na devel1. Provedete to jednoduše příkazem git branch -m [původní název větve] [nový název větve]. V našem případě git branch -m devel_css devel1.

V zápětí jste ovšem znovu změnili názor a rozhodli se, že ve větvi devel1 již pokračovat nebudete. Kód z této větve chcete sloučit do větve master, a následně větev devel1 smazat.

Pro sloučení kódu je nutné, abyste se nacházeli ve větvi master, což byste nyní měli. Samotné sloučení (merge) kódu provedete příkazem git merge [název slučované větve]. V našem případě tedy příkaze git merge devel1.
Jelikož samotný merge představuje pro Git jen další commit, otevře Git po provedení příkazu v rámci příkazové řádky editor (nano, vim), abyste si mohli upravit tzv. commit message. Zároveň pro vás tuto hlášku předepíše - v tomto případě by hláška měla podobu Merge branch 'devel1' into master. Editaci hlášky ukončíte způsobem standardním pro daný editor. Např. u nano editoru pomocí kláves ctrl-x.
Pokud nyní zkontrolujete složku projektu, měly by se v ní nově nacházet soubory d.css a e.js.

Smazání větve devel1 provedete příkazem git branch -D devel1.

A to je víceméně vše, co o používání větví obecně potřebujete vědět.

Konflikty při slučování kódu

Možná vás napadlo, co se stane, když je na každé větvi modifikován stejný soubor, anebo když je v každé větvi přidán soubor stejného jména, ale s jiným obsahem? Vznikne tzv. merge conflict.

Jak jsme výše uvedli, sloučení kódu představuje pro Git jen další commit. Git se v této situaci zachová tak, že všechny modifikované či nové soubory, u kterých žádný konflikt není, umístí do stavu staged a konfliktní soubory se pokusí sloučit. Příkaz git status uvádí u konfliktních souborů hlášku “both modified”.

Tato situace může zejména pro začátečníka vypadat velmi složitě a nepříjemně, není však důvod k panice. Jednak se časem naučíte konfliktům z vetší části předcházet, zadruhé není tak těžké konflikt vyřešit. Otevřete si konkrétní soubory, do nichž Git na úrovni jednotlivých řádků umístil vlastní značky - ty říkají, jaký kód byl v souboru původně a jaký je nový. V tuto chvíli je tedy na vás, abyste manuálně prošli dokument, zachovali chtěný kód a smazali zastaralý/nechtěný kód. Jakmile jsou úpravy kódu hotovy, provedete zaverzování klasickým způsobem - to příkazy git add . a git commit -m “[commit message]”.

Pozn.: Pro editaci konfilktních souborů doporučujeme používat software typu IDE, např. PhpStorm, který má podporu pro Git a pomocí formátování textu vám vizuálně napovídá, jaké části kódu je potřeba editovat.

Přepínání větví a vývoj Drupalu

Jak již zřejmě víte, Drupal není jen kód, ale také databáze. Přepínání mezi větvemi se týká výhradně kódu, přičemž databáze zůstává stejná.

Po každém sloučení kódu obsahujícího změny v konfiguraci je tedy důležité updatovat také stav databáze, a to příkazem drush cim -y, který do databáze importuje novou konfiguraci z kódu.

Pozn.: Výše popsaný Import konfigurace se týká výhradně Drupal 8. V Drupal 7 se pro tyto účely používal modul features.

Pokud nový kód přidává nové moduly či upravuje strukturu databáze, je třeba provést také update databáze. K tomu slouží příkaz drush updb -y.

Pro vývoj na určité větvi může být vhodné vytvořit si duplikát databáze. Jedná se zpravidla o situace, kdy vývojář potřebuje více experimentovat či měnit konfiguraci na různých místech a zároveň chce mít jistotu, že neovlivní stávající funkční konfiguraci. V tomto případě nezapomeňte manuálně upravit údaje pro připojení k databázi v konfiguračním souboru settings.php.

Git - používání vzdálených repozitářů

pepino710 — Tue, 27 Feb 2018 05:42:29 +0000

Git - používání vzdálených repozitářů pepino710 Út, 02/27/2018 - 06:42

V praxi je obecně krajně nevýhodné mít pouze lokální zálohy souborů, a proto existuje mnoho služeb, které umožňují vytvářet zálohy na vzdálených serverech, a tím pro majitele rozložit riziko ztráty dat. Ve světě vývoje aplikací je běžným standardem mít kód uložený v tzv. vzdálených repozitářích. Ve spojení s Gitem patří mezi nejznámější poskytovatele těchto služeb např. Github, Bitbucket, GitLab, apod.

Účty jednotlivců jsou na těchto serverech zpravidla vedeny zcela zdarma, a tak vám nic nebrání si jeden takový založit. Proces se podobá založení online emailu.

Pokud máte založený účet na jedné z těchto služeb, můžeme pokračovat dále.

V tuto chvíli vás budou zajímat v zásadě 2 situace:

Potřebujete poslat kód z lokálního repozitáře do vzdáleného repozitáře.
Potřebujete si do svého počítače natáhnout kód z nějakého vzdáleného repozitáře, a vytvořit si tak ve svém počítači lokální kopii.

Pozn.: Git je tzv. distribuovaný verzovací systém, což v praxi znamená, že defaultně každá kopie repozitáře obsahuje veškerou historii všech revizí. Tato vlastnost je další z mnoha výhod gitu, která výrazně snižuje pravděpodobnost, že o svůj kód můžete přijít.

Tento tutoriál navazuje a předpokládá znalosti z tutoriálu Git - základy. Níže popsané úkony jsou prováděny na příkazové řádce, tzv. CLI.

Cílem je vysvětlit následující:

Vytvoření vzdáleného repozitáře u jednoho z poskytovalelů těchto služeb (Github, Bitbucket, Gitlab, apod).
Přesouvání kódu z lokálního repozitáře do vzdáleného a naopak.

Poslání kódu do vzdáleného repozitáře

Posílat kód do vzdálených repozitářů je možné pouze skrze zabezpečený protokol git, přičemž zabezpečení zajišťuje samostatná technologie ssh. (Pokud tuto technologii nepoužíváte, začněte: ve světě technologií se jedná o běžný standard, bez kterého se dříve či později stejně neobejdete. Přečtení našeho tutoriálu by vám nemělo zabrat více než deset minut).

K funkčnímu zabezpečenému spojení mezi vaším počítačem a vzdáleným repozitářem potřebujete:

svůj soukromý a veřejný klíč ve složce ~/.ssh na vašem počítači (linux),
svůj veřejný klíč uložený do evidenci přísupových klíčů skrze online administraci poskytovatele vzdáleného repozitáře.

Pokud se držíte tohoto tutoriálu, máte nyní ve složce test svůj lokální repozitář s několika testovacími revizemi (commity). Postup přesunu kódu do vzdáleného repozitáře je nyní následující:

Skrze online administraci poskytovatele vytvořte nový repozitář se stejným názvem (test). Po kliknutí na tlačítko uložit budete mít ve vzdáleném repozitáři nový prázdný repozitář a především odkaz na tento repozitář. Odkaz může vypadat např. následovně [email protected]:[username]/test.git.
Lokální repozitář napojíte na vzdálený příkazem git remote add origin [email protected]:[username]/test.git.
Nyní můžete zkontrolovat, že byl vzálený repozitář napojen na lokální, a to pomocí příkazu git remote -v, který vypíše všechny napojené vzdálené repozitáře.Nyní už zbývá jen poslední krok, a to poslat lokální kód na vzdálený server. To provedete příkazem git push -u origin master. Atribut -u v tomto případě říká, že se má ve vzdáleném repozitáři, tzv. origin, vytvořit větev kódu, která ponese stejné jméno jako lokální větev, tedy master.

Ověřit si, která lokální větev se mapuje na kterou vzdálenou větev, můžete pomocí příkazu git remove show origin. V tomto případě dostanete informaci, že master merges with remote master.

Pozn.: Bližší informace o větvích gitu v následující části tohoto tutoriálu.

Naklonování vzdáleného repozitáře

Naklonování, resp. vytvoření lokální kopie vzdáleného repozitáře provedete jedním příkazem, viz. např. instrukce pro stažení Drupal 8:

git clone --branch 8.4.x https://git.drupal.org/project/drupal.git [název cílove složky]

K příkazu bych rád vysvětlil následující:

Pozn.: Výše uvedený postup je z hlediska instalace Drupalu zcela validní, viz např. Instalace Drupalu skrze Git, nicméně mnohem výhodnější bude pro tento účel použít instalaci Drupalu skrze Composer.

--branch 8.4.x. Tento atribut říká, jakou verzi drupalu chceme stáhnout.
Protokol http(s). Klonování repozitáře skrze tento protokol je pouze jednosměrná záležitost. V praxi toto znamená, že si budete v čase moci dotahovat nově vydané verze (více viz dále), nicméně vámi upravený kód nebude možné do vzdáleného repozitáře poslat zpět.

Představme si v tuto chvíli, že máte 2 počítače (desktop a laptop) a předpokládejme, že lokální repozitář máte ve svém desktopu a nově také ve vzdáleném repozitáři. Někam cestujete a rádi byste si vzali s sebou laptop a pokračovali v práci na něm.

V této situaci do laptopu jednoduše naklonujete repozitář pomocí příkazu git clone [email protected]:[username]/test.git.

Protocol git. Tou zásadní změnou v tomto případě je to, že jste nyní použili protocol git, který vám umožní oboustrannou výměnu dat se vzdáleným repozitářem. Cokoliv, co nyní na svém laptopu uděláte, budete nakonec moci poslat zpět do vzdáleného repozitáře.

Pozn.: Aby vám fungovalo zabezpečené připojení, budete muset také v laptopu nastavit svůj ssh klíč. Zde máte 2 možnosti:

Použijete stejné klíče, které již máte v desktopu. Neboli manuálně soubory přesunete z jednoho počítače do druhého.
Vytvoříte si v laptopu nové klíče (viz. tutoriál ssh) a v adminstraci poskytovatele vzdáleného repozitáře si v příslušné sekci přidáte svůj nový klíč.

K práci se vzdáleným repozitářem je ještě vhodné zmínit význam souboru .gitignore. Jak název napovídá, soubor obsahuje instrukce, co má git “ignorovat”, tedy vynechat ze sledování. Typickým příkladem pro práci s Drupalem je soubor .htaccess v rootu webu (obvykle se liší pro různá prostředí), soubor settings.php (kromě toho, že se v různých prostředích liší, obsahuje důvěrné údaje, které nechcete sdílet) či složka sites/default/files (např. soubory, které nahráváte na web k testovacímu obsahu, nechcete sdílet se vzdáleným repozitářem).

A to je vše. Nyní umíte používat základní příkazy gitu. Umíte verzovat lokální kód, umíte si lokální verze zálohovat ve vzdáleném repozitáři a umíte kód získávat ze vzdálených repozitářů.

Git - základy

pepino710 — Thu, 22 Feb 2018 05:21:52 +0000

Git - základy pepino710 Čt, 02/22/2018 - 06:21

Git je v součastnosti jedním z nejpopulárnějších nástrojů na zálohování a verzování kódu. Pro vývojáře je tento nástroj naprosto nepostradatelný. Rozhodně však dlouhodobě ušetří spoustu času a starostí i lidem z řad hobbistů, kterých je v každé komunitě mnoho.

Neumíte si představit, k čemu přesně je Git dobrý?

Při vývoji je zcela běžnou praxí, že experimentujete. Píšete vlastní kód, upravujete kód někoho jiného, instalujete a konfigurujete různé moduly, zkrátka hrajete si se systémem, a tím ho poznáváte. Proto je zároveň běžnou praxí, že něco rozbijete, což ovšem není problém, pokud se jednoduše, např. jedním příkazem na příkazové řádce, dokážete vrátit zpět do stavu, kdy bylo vše funkční.
Máte více počítačů, např. desktop a laptop, a potřebujete nástroj, pomocí něhož budete moci aktuální verzi systému přesunout z jednoho na druhý a naopak. To, co určitě nechcete, je kopírovat soubory manuálně.
Jakmile něco na svém lokálním serveru vytvoříte, potřebujete zpravidla svou aplikaci přesunout na jiný server, odkud bude dostupná online. Někdy také můžete potřebovat pomoc či konzultaci od jiného vývojáře a budete chtít jednoduše přesunout kód/web do jeho počítače.
Na vývoji jedné aplikace v praxi většinou pracuje více vývojářů. Pracují na svých počítačích, a následně potřebují kód, který každý z nich vytvořil, sloučit či spojit dohromady.

To bylo jen pár základních situací, kdy velmi oceníte verzovací systém. Pro začátek vám bude stačit několik základních dovedností, které vám výrazně usnadní a zpříjemní život. Časem zjistíte, že Git je mocný nástroj, který toho umí mnohem a mnohem více.

Git se ovládá buď v terminálu přes příkazovou řádku, anebo je možné využít některou z dostupných aplikací - SmartGit, TortoiseGit, SourceTree, apod.

V tomto tutoriálu budeme instalovat o ovládat git skrze příkazovou řádku, neboli CLI (Command Line Interface).

Naším cílem bude vysvělit si následující:

Instalaci Gitu.
Vytvoření lokálního repozitáře.
Verzování, resp. vytváření zálohy kódu.

Instalace Gitu

Git nainstalujete jednoduše následujícími příkazy:

sudo apt-get update
sudo apt-get install git-all

Pokud nyní napíšete v příkazové řádce git, měly by se vám vypsat příkazy, které je možné použít.

Víte, jak nainstalovat Git na rpm-based linux distribuci? Přispějte do komunity a pomožte těm, kteří by rádi věděli, jak na to.

Pokud potřebujete přístupy do adminstrace webu, obraťte se na někoho z Drupal týmu.

Víte, jak nainstalovat Git na počítačích Apple? Přispějte do komunity a pomožte těm, kteří by rádi věděli, jak na to.

Pokud potřebujete přístupy do adminstrace webu, obraťte se na někoho z Drupal týmu.

Víte, jak nainstalovat Git na počítačích s operačním systémem Windows? Přispějte do komunity a pomožte těm, kteří by rádi věděli, jak na to.

Pokud potřebujete přístupy do adminstrace webu, obraťte se na někoho z Drupal týmu.

Vytvoření lokálního repozitáře

Přestože Git je zpravidla používán vývojáři, jedná se o obecný nástroj na verzování souborů.

Představte si, že máte v počítači adresář s názvem test a uvnitř něho soubory a.txt, b.pdf a c.php. Pokud chcete složku verzovat pomocí gitu, stačí se do ní přesunout a založit git repozitář. To provedete pomocí příkazů:

cd [cesta-k-adresari]/test
git init

A to je vše. Co se stalo?

Uvnitř složky test se nyní nachází skrytá složka .git, do které si Git uložil základní informace o právě vytvořeném repozitáři.
Složku test je možné kopírovat či přesouvat a dokud bude ve složce existovat podsložka .git, bude repozitář stále aktivní.
Smazat git repozitář můžete jednoduše tak, že složku .git smažete.

Vhodným druhým krokem po instalaci gitu je ještě nastavení informace o sobě samém (tzv. git credentials). Konkrétně jde o konfiguraci emailu a jména. Bez tohoto nastavení vám git nedovolí verzovat, viz dále.

Pozn.: Nutno podotknout, že pokud git pouze zkoušíte, nemusí být email ani jméno skutečné.

Git credentials je možné nastavit jak globálně pro všechny projekty, tak lokálně pro každý jednotlivý projekt zvlášť. Příkazy uvádím pro globální nastavení, nicméně pro lokální se místo atributu --global pouze použijte attribut --local:

git config --list. Příkaz vypíše aktuální konfiguraci gitu pro daný repozitář.
git config --global user.name “[jméno příjmení]”
git config --global user.email "[email]"

Verzování pomocí Gitu

Nyní máte existující repozitář, ale ten je prozatím prázdný. Jak tedy začít soubory verzovat?

Základním příkazem gitu je git status, který vypíše stav repozitáře. (Jednou z velkých výhod gitu je, že vám vypisuje nápovědu přímo do terminálu, takže často stačí pouze následovat nápovědu.)

Po založení nového repozitáře jsou všechny soubory ve složce považovány gitem za tzv. untracked files, neboli nesledované soubory. V praxi to znamená, že git o těchto souborech sice ví, ale neverzuje je.

Pokud chceme začít soubory verzovat, zařadíme je mezi sledované příkazem:

git add [název souboru]. Pro soubory v podsložkách je nutné uvádět relativní cestu.

Existují situace, kdy chcete přidat mezi sledované všechny soubory ve složce. K tomu slouží příkaz git add . (tečka zde reprezentuje všechny soubory).

Zaverzování samotné pak probíhá pomocí příkazu git commit -m “[commit message]”. Provedení tzv. commitu uloží novou revizi kódu a příkaz git status vrací hlášku “nothing to commit”.

Přehled revizí je možné v terminálu vypsat pomocí příkazu git log -n [počet commitů zpět], např. 5 vypíše 5 posledních revizí.

Poslední z běžných úkonů , o kterém se chci zmínit, je mazání souborů. Pokud je soubor verzován a fyzicky ho smažete, začne vám to git hlásit. K odebrání souboru z verzování slouží příkaz git rm [název-souboru]. Tímto příkazem soubor fyzicky nemažete z file systému, ale v rámci gitu ho dáváte do stavu staged. Po následném commitu dojde k jeho odstranění z verzování a soubor se po příkazu git status bude vypisovat mezi nesledovanými soubory. Odstranění souboru z gitu tedy nemaže soubor z file systému.

Pokud je pro vás git nový, vyzval bych vás v tomto bodě k tomu, abyste si s ním trochu pohráli. Pokud máte založený testovací repozitář, zkuste si udělat několik dalších testovacích commitů, např.

přidat do složky nové soubory a zaverzovat,
změnit existující a zaverzovat,
přidat soubor do stavu staged a následně ho modifikovat,
odebrat soubor ze stavu staged zpět do stavu not staged,
verzovaný soubor smazat z file systému a (za pomoci nápovědy) vyřešit konflikt, který tím v gitu vznikne.

Po každé akci používejte git status, a tím si kontrolujte, jak git reaguje na vaše jednotlivé akce.