Dotaz: GIT - par otazek

[petrfm]

Ahoj, zacinam si hrat s gitem. Mam ho na linuxu a zkousim si nejake upravy v home adresari.

Nasel jsem oficialni preklad manualu a jedu podle nej, ale je dost obsahly, proto mam par otazek, protoze jsem nenasel odpoved :

1) pokud provedu git init, tak VSECHNY soubory k danemu projektu jsou v .git? Cili pro zalohovani daneho projektu vcetne historie GITu mi staci zkopirovat jej vcetne .git, nebo se soubory ukladaji i nekam na disk, treba do /var..?

2) premyslim spravne, ze kdyz mam na serveru zkusebni LAMP, tak mi staci, udelat si git init v adresari s projektem a muzu prepinanim branche jednoduse testovat zmeny? Nebo to apachi a php nejak vadi?

3) souvisi se 2 - git vytvari virtualni soborovy system, nebo soubory maze a prekopirovava? nebo jak to funguje, ze prepnutim vetve se mi okamzite zmeni obsah adresare?

4) cetl jsem, ze muzu provozovat vlastni git server. Cili kdyz delam vyvoj ruznych veci z ruznych PC, muzu mit na serveru centralni uloziste a projekty mit na nem, je to tak? Existuje neco, co vypada jako github, tzn, ze verejne projekty se daji volne pres web prochazet a pres git sdilet?

5) no a nejdulezitejsi vec - prece jen jsem clovek s fotografickou pameti a lepe se mi orientuje v grafice nez prikazovem radku. GIT je udelany celkem dobre a dela se mi s nim dobre, ale na kubuntu jsem zkousel qgit a libilo se mi to pro rychle zorientovani se v projektu. Dela se neco takoveho i pro terminal? Nejaky pruzkumnik repozitare s lehkou grafikou, treba na styl Midnight Commanderu, nebo top? Nebo je gui pro git jen pro xka?

6) pokud neni gui, da se nejak jednoduse zorientovat v projektu, pripadne zobrazit si na danem pc vsechny repozitare? Kdyz pracuji lokalne, tak repozitare vlastne nemam, ze? Mam jenom lokalne ulozene .git slozky, tak daji se nejak zobrazit, uklada se nekam "seznam mych projektu", nebo si to musim resit sam?

 

Diky za odpoved na aspon nejakou otazku,

P.

---

---

Odpovědi

[chrono]

1. Samotný príkaz git init žiadne súbory nikam neukladá ( na to slúži git add + git commit).

3. Git súbory maže a vytvára (a nastaví im aktuálny čas, aby napr. program Makefile vedel, že súbor bol zmenený).

4. Server na distribuovanie repozitára nie je potrebný (na servery stačí napr. ssh prístup a takým spôsobom je možné tam používať git repozitár).

5. tig

6. Adresár .git je repozitár a zoznam sa nikam neukladá.

[chrono]

A zabudol som napísať, že by bolo vhodné si o git (alebo všeobecne o DVCS) niečo prečítať (existuje napr. český preklad knihy PRO GIT).

[petrfm]

diky moc, ucim se to podle prekladu manualu z git-scm.com, ale jsem v polovine a moc mne tyhle veci zajimaly. Nainstaloval jsem tig, je SUPER, konecne se da jednoduse projekt prolezat a videt vetve, jednotlive commity a seznam zmen bez neustaleho psani prikazu Zkousim to doma na W7 a jsem pres ssh pripojeny na server, takze je idealni, mit takovy nastroj, ktery neni nutne instalovat a muze byt primo na serveru. Pomoci screenu se pak da hezky pracovat "v oknech" i kdyz mam pomale pripojeni a nemusim se trapit instalaci nejakych gitovych gui na windows, ktere stejne brzy poleti pryc.

[xkucf03]

alebo všeobecne o DVCS

Seriál: Distribuované verzovací systémy

[Fuky]

Odpovědi na všechny Tvé otázky jsou v manuálu, který čteš. Edice CZ.NIC poskytuje PDF "Pro Git", Scott Chacon i lze objednat papírovou verzi. Vše co čteš si rovnou zkoušej, ať se Ti to dostane pod kůži a lépe to pochopíš.

1) Git na serveru - Jak umístit Git na server

2) Ano, můžeš takto přepínat mezi různými revizemi.

3) Pokud se přepneš na jinou revizi, tak se Ti z pracovního adresáře odstraní soubory, které do ní nepatří a z adresáře .git se načtou ty, které tam patří.

4) Git na serveru - GitWeb

6) Adresář .git je plnohodnotný repozitář s kompletní historií všech větví, které jsi si do něho stáhnul. Ten samý budeš mít i na serveru, jenomže tam to bude takzvaný "holý repozitář" tj. bez pracovního adresáře viz odkaz v bodě 1).

[petrfm]

Diky za odpovedi, postupne se k tomu prokousavam, az po zkouseni jsem to pochopil, jak to funguje. Prijde mi, ze to v tom prekladu PRO GIT je popsano hodne slozite. Autor casto preskakuje z jedne veci na druhou a pak utika myslenka. Cetl jsem uz hodne materialu, ale tady mi chvili trvalo, uvedomit si, jak to vlastne funguje, ze to jsou defakto snapshoty, jako u virtualu a odkazy na ne.

Jeden posledni dotaz z praxe - jak to delate, kdyz treba mate v gitu nejaky web? Jde mi o git ignore. Cetl jsem, ze je dobre, ignorovat treba config soubory, atd. (je to predevsim moudre) U nejakych RS pak zase treba galerii obrazku a medialnich souboru, pokud napriklad pracuji na ostrem webu, kde uz mam sve clanky a jejich obrazky, ale nechci je samozrejme cpat do repozitare.

Ale, tady je ten kamen urazu a moje otazka - soucasti vetsiny projektu je preci vzorovy config.php soubor (pravda, ne vzdy, nekdy se generuje pri instalaci z install.php). Je na to nejaky figl, jak dosahnout toho, aby se do repozitare ulozil ten "falesny, tovarni config.php", ale pritom abych v pracovnim adresari mel ten svuj, s realnymi udaji? Proste da se nejak podstrcit jiny soubor, ktery se bude commitovat, nebo jak se tohle dela?

P.

[Josef Kufner]

Do .gitignore dáš adresář s daty nebo naopak aplikaci dáš do samostatného adresáře vedle dat.

Konfigurační soubory jsou trošku zákeřné. Občas se to řeší tak, že v repositáři je příklad a ten si při instalaci zkopíruješ a upravíš dle libosti. Tedy commitnutý je config.example.php, ale skutečný config.php je v .gitignore. Druhá možnost je mít konfiguráků několik a při načítání je položit přes sebe. Pak ten úplně spodní můžeš mít commitnutý, neboť obsahuje výchozí hodnoty a ten horní bude v .gitignore. Může jich být i více, záleží na aplikaci.

Docela se mi osvědčil přístup s třemi konfiguráky, kdy default je někde ve frameworku, přes to se položí konfigurace aplikace a teprve ten třetí je v .gitignore a obsahuje volby specifické pro instalaci, například heslo k databázi. V PHP je na to dobré použít array_replace_recursive(). Pokud se bojíš o výkon, koukni na APCU a sestavenou konfiguraci si ulož v paměti.

[Fuky]

Ignoring versioned files
GIT: ignoring changes in tracked files

$ git update-index --assume-unchanged path/to/file.txt
$ git ls-files -v |grep '^h'
$ git update-index --no-assume-unchanged path/to/file.txt

[Josef Kufner]

2) premyslim spravne, ze kdyz mam na serveru zkusebni LAMP, tak mi staci, udelat si git init v adresari s projektem a muzu prepinanim branche jednoduse testovat zmeny? Nebo to apachi a php nejak vadi?

Git se občas používá na deploy. Prostě jako post-update hook na serevru nastavíš script, který checkoutne aktuální verzi zvolené větve na server. Přesněji: git fetch && git checkout větev --force && ./nějaký-post-upgrade-script.

Funguje to tak, že máš dva repositáře, do jednoho uděláš push a ten druhý se z něj zaktualizuje. Existuje i trik s GIT_DIR, jak to udělat s jedním repositářem, ale obvykle je lepší to nekomplikovat.

Pokud ti přijde divné proč checkout místo pull, tak je to kvůli případným lokálním změnám. Ten checkout je prostě přepíše a funguje to dál, kdežto pull se šprajcne.

[Josef Kufner]

... jo a tomu Apachi i PHP je to úplně jedno. Jen měj na paměti, že operace Gitu nejsou atomické a může být vhodné ten web vypnout na dobu aktualizace.

[Josef Kufner]

4) cetl jsem, ze muzu provozovat vlastni git server. Cili kdyz delam vyvoj ruznych veci z ruznych PC, muzu mit na serveru centralni uloziste a projekty mit na nem, je to tak? Existuje neco, co vypada jako github, tzn, ze verejne projekty se daji volne pres web prochazet a pres git sdilet?

Jednoduché řešení: gitolite + git-web nebo cgit.

Výhodou je jednoduchost. Přístup je po ssh, autentikace klíčema. Snadné přidávání libovolného počtu uživatelů (commitne se klíč do speciálního repositáře). Je potřeba jeden unixový uživatel (gitolite pozná uživatele podle použitého klíče). Umí to celkem jemné nastavování oprávnění a každý uživatel může mít svůj jmenný prostor pro své repositáře.

Je to velmi nenáročné na prostředky serveru. Pár souborů na disku, a po SSH spuštěný git, když je potřeba.

Nevýhodou je, že je to opravdu jen o repositářích...

Složitější řešení: GitLab

Plnohodnotná opensource náhrada Githubu. Pěkné webové rozhraní, možnost mít u každého projektu issues, milestony, wiki, pull requesty, komentáře, ...

Instalace má do triviální daleko, ale není to nic strašného. Balíčky pro Debian a Fedoru se pozvolna chystají.

Ukousne si to na serveru cca 300 MB paměti a potřebuje to PostgerSQL. Samotná aplikace má cca 20 MB a dalších 300 MB gemů (je to v Ruby).

Výhody: Je to fakt pěkné. Pokud chceš mít něco jako GitHub, ale na svém serveru, je to asi nejlepší cesta. Každý měsíc vychází nová verze.

[petrfm]

Panove, diky za extra vyzivne vlakno, odpovedeli jste mi vycerpavajicicm zpusobem na vsechny me dotazy. Ta finta s prejmenovanycm konfigurakem je super, casto to vidam u ruznych projektu, takze se to pouziva a me, jakozto GIT zacatecnikovi to prijde nesrozumitelnejsi a nejjednodussi.

K tem serverum, ta analogie githubu je hezka, nasel jsem i v PRO GIT manualu odkaz na nejakou lehci webovou verzi, ta je taky fajn, ale zatim mi asi bude nejvice vyhovovat klasicky pristup k serveru pres ssh - nevyvijim v tymu, takze mi jde spise o to, mit nekde centralizovane ulozene repozitare k projektum. Ale vzdycky je dobre mit prehled o tom, jake jsou moznosti, zitra se to muze hodit, do budoucna mam par napadu, ktere bych rad uverejnil jako opensource, takze tam uz mi takovy system s webovym rozhranim pomuze - da se zakomponovat do webu k dane aplikaci.

Cili diky moc a verim, ze nekdy tohle vlakno pomuze i jinym.