přejít na obsah přejít na navigaci

Linux E X P R E S, Správa linuxového serveru: Git na vlastním serveru

Správa linuxového serveru: Git na vlastním serveru

debain_notext.png

Systémy pro správu verzí jako Git nacházejí široká uplatnění, nejenom v rámci programování. V tomto článku se dozvíte něco málo o Gitu, zejména jak vytvořit centrální úložiště pro Git repozitář na vlastním serveru.


reklama

Úvod

Systém pro správu verzí (známý pod zkratkami SCM nebo VCS) je software, který spravuje změny ve vašich (zejména textových) datech. Můžete tak snadno zjistit, ve kterých souborech se co změnilo, kdy se to změnilo a kdo to změnil. Pomocí SCM se organizují práce vývojářů na softwarových projektech. Ale SCM poslouží na jakákoliv textová data, nejen na zdrojový kód. V unixových systémech to často bývají konfigurační soubory, které mají v těchto systémech textový charakter. Mohou to ale také být třeba zdrojové kódy rozsáhlejšího dokumentu tvořeného v LaTeXu či za pomoci konverzních nástrojů typu Asciidoc, Pandoc, txt2tags apod.

Git byl vyvinut pro potřeby vývoje linuxového jádra (kde nahradil komerční a nesvobodný Bitkeeper) a postupem času se stal jedním z nejpopulárnějších SCM nástrojů, alespoň ve světě svobodného softwaru.

Existuje řada služeb, které vám umožní vytvořit si svoje vlastní Git repozitáře, hostované na serveru příslušného poskytovatele. GitHub je zde nejznámějším, ale nikoliv jediným příkladem. Tyto služby však mohou být za určitých okolností zpoplatněné (např. když nechcete svůj repozitář vystavit světu) a samozřejmě podléhají určitým podmínkám, které se vám mohou, ale také nemusí líbit. Máte-li vlastní server, můžete si centrální úložiště pro Git repozitář(e) vytvořit na něm.

Pokud máte ještě v živé paměti články o zprovoznění Redmine na linuxovém serveru, dodám, že Redmine podporuje řadu SCM nástrojů a podpora Gitu samozřejmě nechybí.

Distribuovaný SCM a centrální úložiště

Git je distribuovaný SCM, což znamená, že nepotřebuje centrální bod, se kterým by musel udržovat spojení, aby byl schopen realizovat základní úkony (tím se liší od centralizovaných SCM jako CVS či SVN). Všechny základní operace prováděné Gitem jsou realizovány lokálně, v rámci vašeho souborového systému (konkrétně pak v podadresáři .git). Proto jsou také pekelně rychlé. Centrální server tedy v zásadě není nutný, ale má-li na projektu pracovat více lidí, nebo chcete-li online zálohu či centrální bod, abyste mohli snadno synchronizovat své změny napříč několika počítači, centrální server se vám může hodit.

Je třeba zmínit, že Git není jediným pod Linuxem dostupným distribuovaným SCM. Můžete použít např. Mercurial nebo Bazaar.

Základy práce s Gitem

Na Git jako takový se zde podrobněji zaměřovat nebudu, ale jakousi základní kuchařku vám přesto poskytnu.

Je-li to poprvé, co vůbec používáte Git, bylo by dobré se mu představit (ideálně ještě před prováděním commitů):

git config --global user.name 'Jméno Příjmení'
git config --global user.email mail@example_cz

Vytvoření Git repozitáře představuje jeden jediný příkaz, a to v adresáři, který chcete Gitem spravovat (samozřejmě včetně podadresářů):

git init

Tento příkaz vytvoří výše zmíněný .git podadresář s příslušnými výchozími konfiguračními soubory. Poté je třeba přidat příslušné soubory:

git add .

Výše uvedený příkaz přidá celý aktuální adresář včetně podadresářů. Můžete samozřejmě specifikovat konkrétní soubor nebo soubory:

git add soubor1.txt soubor2.txt

Následně můžete vytvořit první commit, tedy uložit aktuální stav sledovaných souborů do repozitáře:

git commit -m 'Popis commitu'

V tuto chvíli by měl být aktuální stav všech sledovaných souborů uložen. Jakmile provedete změny, můžete je uložit, tedy „commitnout“ buď automaticky (commitnou se všechny změněné soubory):

git commit -a -m 'Popis commitu'

Nebo můžete selektivně „commitnout“ jen něco:

git add soubor.txt
git commit -m 'Popis změny souboru soubor.txt'

Aktuální změny oproti poslednímu commitu je možné zjistit pomocí:

git status

Podrobnější přehled o změnách můžete zjistit pomocí:

git diff --stat

A konkrétní diff pak obdržíte pomocí:

git diff

Samotný git add ukládá daný soubor do tzv. staging area, tudíž pokud mezi tím příslušný soubor změníte a pak provedete commit, tak uložíte změny, které byly aktuální v době zadání git add. Soubory uložené ve „staging area“ můžete vyjmout pomocí git reset HEAD.

Existují také grafické nadstavby Gitu, které vám usnadní získání informací o změnách, popřípadě samotnou správu repozitáře, například gitk (měl by být součástí distribuce Gitu).

Chcete-li se o používání Gitu dozvědět více, podívejte se do závěru článku, kde je řada odkazů na zdroje o Gitu, a to i v češtině. Nechybí ani jedna velice užitečná kniha přeložená do češtiny.

Git přes SSH

V tomto dílu vám představím to nejjednodušší řešení centralizovaného Git repozitáře, které existuje. Na serveru vám k tomu stačí pouze běžící SSH server. Toto řešení je vhodné pro soukromé repozitáře, které nechcete nikde vystavovat a kde nepotřebujete přístup více osob. Na komplikovanější řešení se zaměřím v dalších dílech.

Nacházíte-li se v adresáři s Git repozitářem, jako první krok exportujte repozitář do správného „formátu“ a překopírujte jej na server. Předpokladem je, že v domovském adresáři vzdáleného uživatele uzivatel existuje adresář git.

git clone --bare .git /tmp/muj_repositar.git
scp -r /tmp/muj_repositar.git uzivatel@server_example_cz:/home/uzivatel/git/muj_repositar.git

Nyní je repozitář na serveru vytvořen. Stačí tedy Gitu říci, že tento vzdálený repozitář existuje:

git remote add origin ssh://uzivatel@server_example_cz/home/uzivatel/git/muj_repositar.git

V tuto chvíli máte možnost commitnuté změny poslat na server, popřípadě si změny z centrálního repozitáře stáhnout, a samozřejmě máte možnost vzdálený repozitář naklonovat třeba na nový počítač. Samotné publikování změn na server provedete takto:

git push

Máte-li na serveru dostupné změny, které nemáte k dispozici v lokálním repozitáři, můžete si je stáhnout a začlenit:

git pull

No a konečně, pokud se ocitnete na novém počítači, kde daný repozitář není k dispozici, můžete jeho aktuální stav naklonovat pomocí git clone, tímto způsobem:

git clone ssh://root@lucifer_krkavec_net/root/git/muj_repositar.git

Toto řešení je velmi jednoduché, ale v zásadě pokrývá pouze ty nejprostší potřeby. Máte-li více lidí a potřebujete-li definovat k repozitáři třeba read-only přístup, potřebujete mírně sofistikovanější řešení, kterým se budu zabývat v příštím dílu seriálu.

Nahoru

Odkazy

(Jako ve škole)
Průměr: 1,00 | Hodnotilo: 2
 

Top články z OpenOffice.cz

Příspěvky

Správa linuxového serveru: Git na vlastním serveru
Tom 8. 11. 2011, 18:06:37
Odpovědět  Odkaz 
Ahoj,

díky, těší se na pokračování. Uvedené řešení je super.

Tom
Správa linuxového serveru: Git na vlastním serveru
Jan 10. 11. 2011, 12:31:32
Odpovědět  Odkaz 
Díky za zajímavý článek. Dobrá práce.
Jen mě vždy mrzí, že když se mluví o Gitu a o tom jak je jednoduchý, vetšinou se ve článcích začnou popisovat příklady pomocí příkazů shellu. Proč se zaději neukáže jak jednoduché a rychlé je pracovat s Gitem pomocí GUI? Doufám, že řádkové příkazy nikdy použít nebudu muset. Proč něco dělat složitě když to jde jednodušeji? Pro porovnání obsahu dvou různých verzí souboru stačí 5 stisků klávesy a cca 3-5 vteřiny, ale většinou se popisují hrůzaostrašné hromady řádkových příkazů, kde si musíte pamatovat nejen jednotlivé příkazy (to není problém, to se při používání člověk naučí) ale čísla comitů, vše je nutné zdlouhavě do shellu vypsat, trvá to dlouho, je možné spoustu chyb.

Git je skvělý nástroj, umožňující ušetřit spoustu práce a starostí. Příkazová řádka je fajn ale proč jezdit na trakaři když můžeme jet autem? Proč neukázat ovládání pomocí GUI, které je v praxi daleko praktičtější než příkazová řádka?
Teď jsem asi mnoho lidí namíchl!
Správa linuxového serveru: Git na vlastním serveru
Pavel Šimerda (pavlix) 13. 11. 2011, 11:02:46
Odpovědět  Odkaz 
„Proč se zaději neukáže jak jednoduché a rychlé je pracovat s Gitem pomocí GUI?“

Podle mého skromného názoru je to protože cílovou skupinou Gitu číslo jedna jdou vývojáři software, kteří tak jako tak s příkazy pracovat umějí. Já osobě Git používám výhradně na příkazové řádce a GUI jsem prvně otevřel až když jsem zaváděl Git u neprogramátorů :).

Článek o Git GUI bych samozřejmě jenom uvítal, ale to přece neznamená, že by se článek o Gitu jako takovém měl příkazové řádce vyhýbat, spíš naopak.

„Pro porovnání obsahu dvou různých verzí souboru stačí 5 stisků klávesy a cca 3-5 vteřiny, ale většinou“

Většinou? Chápu to dobře, že to už není k článku, ale povzdech nad životem, světem a vesmírem?

„čísla comitů, vše je nutné zdlouhavě do shellu vypsat, trvá to dlouho, je možné spoustu chyb.“

Neznám nikoho, kdo by běžně do shellu vypisoval čísla commitů. Lidé, kteřé pracují s příkazovou řádkou Gitu čísla commitů kopírují, obvykle myší, a navíc je nekopírují celá, protože to není potřeba. Stačí se myší trefit na začátek hashe a pustit někde o kousek dál.

„Příkazová řádka je fajn ale proč jezdit na trakaři když můžeme jet autem? Proč neukázat ovládání pomocí GUI, které je v praxi daleko praktičtější než příkazová řádka?“

Protože je to přesně naopak :).

„Teď jsem asi mnoho lidí namíchl!“

Aha, to mě nenapadlo. Teď nevím, jestli jsem měl reagovat, původně jsem si myslel, že tě dané téma vážně zajímá. Ale co už, už jsem to napsal, tak to zahazovat nebudu, třeba to pomůže někomu jinému ;).

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Michal Dočekal

GNU/Linuxový nadšenec a zastánce svobodného softwaru. Jeho pracovní náplň zahrnuje správu několika linuxových serverů. Snaží se být aktivním členem linuxové komunity, dlouhodobě vytváří dokumentaci pro začínající uživatele Linuxu.


  • Distribuce: Arch Linux
  • Grafické prostředí: Awesome
  • Hodnocení autora: ****

| blog


CIO Agenda 2016

Redakční blog

Pavel Fric

Pavel Fric, 28. únor

Lollypop

Hudební lízátko k olízání


Pavel Fric

Pavel Fric, 29. listopad

Palapeli

Skládačka. Co je na obrázku? 


Pavel Fric

Pavel Fric, 19. listopad

Amarok

Připomenutí slavného přehrávače zvuku, vlastně dvou (slavných, přehrávačů, písniček)


Všechny blogy »

LibreOffice Conference 2016