From 33b648fd1a1c1883a5b02e5856e8e34acf4776ac Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sun, 5 Jan 2014 19:42:17 +0100 Subject: [PATCH 001/291] [cs] Typos and formulation changes in Ch. 1 up to 1.3 included. --- cs/01-introduction/01-chapter1.markdown | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 44fdd2521..b1b60c735 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -3,7 +3,7 @@ Tato kapitola vám ve stručnosti představí systém Git. Začneme od samého začátku. Nahlédneme do historie nástrojů ke správě verzí, poté se budeme věnovat tomu, jak spustit systém Git ve vašem počítači, a nakonec se podíváme na možnosti úvodního nastavení. V této kapitole se dozvíte, k čemu Git slouží a proč byste ho měli používat. Kromě toho se také naučíte, jak Git nastavit podle svých potřeb. ## Správa verzí ## - +hi Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času, a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Příklady verzovaných souborů jsou v této knize ilustrovány na zdrojovém kódu softwaru, avšak ve skutečnosti lze verzování provádět téměř se všemi typy souborů v počítači. Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z angl. Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem. @@ -37,11 +37,11 @@ V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verz Insert 18333fig0103.png Obrázek 1-3. Diagram distribuované správy verzí -Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, a vy tak můžete v rámci jednoho projektu spolupracovat na různých úrovních s rozdílnými skupinami lidí. Díky tomu si můžete vytvořit několik typů pracovních postupů, což není v centralizovaných systémech (např. v hierarchických modelech) možné. +Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, takže můžete v rámci jednoho projektu různým způsobem spolupracovat s různými skupinami lidí najednou. Můžete zavést několik typů pracovních postupů, které nejsou v centralizovaných systémech možné — jako jsou například hierarchické modely. ## Stručná historie systému Git ## -Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software s otevřeným kódem a širokou škálou využití. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem Bit-Keeper. +Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software celkém velkého rozsahu, s otevřeným kódem. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem BitKeeper. V roce 2005 se zhoršily vztahy mezi komunitou, která vyvíjela jádro Linuxu, a komerční společností, která vyvinula BitKeeper, a společnost přestala tento systém poskytovat zdarma. To přimělo komunitu vývojářů Linuxu (a zejména Linuse Torvaldse, tvůrce Linuxu), aby vyvinula vlastní nástroj, založený na poznatcích, které nasbírala při užívání systému BitKeeper. Mezi požadované vlastnosti systému patřily zejména: @@ -55,7 +55,7 @@ Od svého vzniku v roce 2005 se Git vyvinul a vyzrál v snadno použitelný syst ## Základy systému Git ## -Jak bychom tedy mohli Git charakterizovat? Odpověď na tuto otázku je velmi důležitá, protože pokud pochopíte, co je Git a na jakém principu pracuje, budete ho bezpochyby moci používat mnohem efektivněji. Při seznámení se systémem Git se pokuste zapomenout na vše, co už možná víte o jiných systémech VCS, např. Subversion nebo Perforce. Vyhnete se tak nežádoucím vlivům, které by vás mohly při používání systému Git mást. Ačkoli je uživatelské rozhraní velmi podobné, Git ukládá a zpracovává informace poněkud odlišně od ostatních systémů. Pochopení těchto rozdílů vám pomůže předejít nejasnostem, které mohou vzniknout při používání systému Git. +Jak bychom tedy mohli Git charakterizovat? Odpověď na tuto otázku je velmi důležitá, protože pokud pochopíte, co je Git a na jakém principu pracuje, budete ho bezpochyby moci používat mnohem efektivněji. Při seznámení se systémem Git se pokuste zapomenout na vše, co už možná víte o jiných systémech VCS, např. Subversion nebo Perforce. Vyhnete se tak nežádoucím vlivům, které by vás mohly při používání systému Git mást. Ačkoli je uživatelské rozhraní velmi podobné, Git ukládá a zpracovává informace poněkud odlišně od ostatních systémů. Pochopení těchto rozdílů vám pomůže předejít nejasnostem, které mohou při používání systému Git vzniknout. ### Snímky, nikoli rozdíly ### @@ -69,31 +69,31 @@ Git zpracovává data jinak. Chápe je spíše jako sadu snímků (snapshots) vl Insert 18333fig0105.png Obrázek 1-5. Git ukládá data jako snímky projektu proměnlivé v čase. -Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git je tak z obyčejného VCS spíše povýšen na vlastní systém správy souborů s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3. +Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git se podobá malému systému souborů (spíše než obyčejnému VCS) s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3. ### Téměř každá operace je lokální ### Většina operací v systému Git vyžaduje ke své činnosti pouze lokální soubory a zdroje a nejsou potřeba informace z jiných počítačů v síti. Pokud jste zvyklí pracovat se systémy CVCS, kde je většina operací poznamenána latencí sítě, patrně vás při práci v systému Git napadne, že mu bohové rychlosti dali do vínku nadpřirozené schopnosti. Protože máte celou historii projektu uloženou přímo na svém lokálním disku, probíhá většina operací takřka okamžitě. -Pokud chcete například procházet historii projektu, Git kvůli tomu nemusí vyhledávat informace na serveru — načte ji jednoduše přímo z vaší lokální databáze. Znamená to, že se historie projektu zobrazí téměř neprodleně. Pokud si chcete prohlédnout změny provedené mezi aktuální verzí souboru a týmž souborem před měsícem, Git vyhledá měsíc starý soubor a provede lokální výpočet rozdílů, aniž by o to musel žádat vzdálený server nebo stahovat starší verzi souboru ze vzdáleného serveru a poté provádět lokální výpočet. +Pokud chcete například procházet historii projektu, Git kvůli tomu nemusí vyhledávat informace na serveru — načte je jednoduše přímo z vaší lokální databáze. Znamená to, že se historie projektu zobrazí téměř hned. Pokud si chcete prohlédnout změny provedené mezi aktuální verzí souboru a týmž souborem před měsícem, Git vyhledá měsíc starý soubor a provede lokální výpočet rozdílů, aniž by o to musel žádat vzdálený server nebo stahovat starší verzi souboru ze vzdáleného serveru a poté provádět lokální výpočet. -To také znamená, že je jen velmi málo operací, které nemůžete provádět offline nebo bez připojení k VPN. Jste-li v letadle nebo ve vlaku a chcete pokračovat v práci, můžete beze všeho zapisovat nové revize. Ty se odešlou ve chvíli, kdy se opět připojíte k síti. Jestliže přijedete domů a zjistíte, že VPN klient nefunguje, stále můžete pracovat. V mnoha jiných systémech je takový postup nemožný nebo přinejmenším obtížný. Například v systému Perforce toho lze bez připojení k serveru dělat jen velmi málo, v systémech Subversion a CVS můžete sice upravovat soubory, ale nemůžete zapisovat změny do databáze, neboť ta je offline. Možná to vypadá jako maličkost, ale divili byste se, jaký je to velký rozdíl. +To také znamená, že je jen velmi málo operací, které nemůžete provádět offline nebo bez připojení k VPN. Jste-li v letadle nebo ve vlaku a chcete pokračovat v práci, můžete beze všeho zapisovat nové revize. Ty odešlete až po opětovném připojení k síti. Jestliže přijedete domů a zjistíte, že VPN klient nefunguje, stále můžete pracovat. V mnoha jiných systémech je takový postup nemožný nebo přinejmenším obtížný. Například v systému Perforce toho lze bez připojení k serveru dělat jen velmi málo, v systémech Subversion a CVS můžete sice upravovat soubory, ale nemůžete zapisovat změny do databáze, neboť ta je offline. Možná to vypadá jako maličkost, ale divili byste se, jak velký je v tom rozdíl. ### Git pracuje důsledně ### -Než je v systému Git cokoli uloženo, je nejprve proveden kontrolní součet, který je potom používán k identifikaci uloženého souboru. Znamená to, že není možné změnit obsah jakéhokoli souboru nebo adresáře, aniž by o tom Git nevěděl. Tato funkce je integrována do systému Git na nejnižších úrovních a je v souladu s jeho filozofií. Nemůže tak dojít ke ztrátě informací při přenosu dat nebo k poškození souboru, aniž by to byl Git schopen zjistit. +Než je v systému Git cokoli uloženo, je nejprve proveden kontrolní součet, který je potom používán k identifikaci uloženého souboru. Znamená to, že není možné změnit obsah jakéhokoli souboru nebo adresáře, aniž by o tom Git nevěděl. Tato funkce je integrována do systému Git na nejnižších úrovních a je nedílnou součástí jeho filozofie. Nemůže tak dojít ke ztrátě informací při přenosu dat nebo k poškození souboru, aniž by to byl Git schopen zjistit. Mechanismus, který Git k tomuto kontrolnímu součtu používá, se nazývá otisk SHA-1 (SHA-1 hash). Jedná se o řetězec o 40 hexadecimálních znacích (0–9; a–f) vypočítaný na základě obsahu souboru nebo adresářové struktury systému Git. Otisk SHA-1 může vypadat například takto: 24b9da6552252987aa493b52f8696cd6d3b00373 -S těmito otisky se budete setkávat ve všech úložištích systému Git, protože je používá opravdu často. Neukládá totiž soubory podle jejich názvu, ale ve své databázi podle otisku (hashe) jeho obsahu. +S těmito otisky se budete setkávat ve všech úložištích systému Git, protože je používá opravdu často. Git nic neukládá podle názvu souboru. Místo toho používá databázi adresovatelnou hodnotou otisku, který odpovídá obsahu souboru. ### Git většinou jen přidává data ### Jednotlivé operace ve většině případů jednoduše přidávají data do Git databáze. Přimět systém, aby udělal něco, co nelze vzít zpět, nebo aby smazal jakákoli data, je velice obtížné. Stejně jako ve všech systémech VCS můžete ztratit nebo nevratně zničit změny, které ještě nebyly zapsány. Jakmile však jednou zapíšete snímek do systému Git, je téměř nemožné ho ztratit, zvlášť pokud pravidelně zálohujete databázi do jiného repozitáře. -Díky tomu vás bude práce se systémem Git bavit. Budete pracovat s vědomím, že můžete experimentovat, a neriskujete přitom nevratné zničení své práce. Podrobnější informace o tom, jak Git ukládá data a jak lze obnovit zdánlivě ztracenou práci, najdete v kapitole 9 „Git pod pokličkou“. +Díky tomu vás bude práce se systémem Git bavit. Budete pracovat s vědomím, že můžete experimentovat, a neriskujete přitom nevratné zničení své práce. Podrobnější informace o tom, jak Git ukládá data a jak lze obnovit zdánlivě ztracenou práci, najdete v kapitole 9. ### Tři stavy ### @@ -104,9 +104,9 @@ Z toho vyplývá, že projekt je v systému Git rozdělen do tří hlavních č Insert 18333fig0106.png Obrázek 1-6. Pracovní adresář, oblast připravených změn a adresář Git -V adresáři Git ukládá systém databázi metadat a objektů k projektu. Je to nejdůležitější část systému Git a zároveň adresář, který se zkopíruje, když klonujete repozitář z jiného počítače. +Adresář Git (repozitář) je místo, kde Git uchovává metadata a databázi objektů vašeho projektu. Je to nejdůležitější část systému Git a zároveň adresář, který se zkopíruje, když klonujete repozitář z jiného počítače. -Pracovní adresář obsahuje lokální kopii jedné verze projektu. Tyto soubory jsou staženy ze zkomprimované databáze v adresáři Git a umístěny na disk, abyste je mohli upravovat. +Pracovní adresář obsahuje lokální kopii jedné verze projektu. Tyto soubory jsou staženy ze zkomprimované databáze v adresáři Git a umístěny na disk, kde je můžete používat nebo upravovat. Oblast připravených změn je jednoduchý soubor, většinou uložený v adresáři Git, který obsahuje informace o tom, co bude obsahovat příští revize. Soubor se někdy označuje také anglickým výrazem „index“, ale oblast připravených změn (staging area) je už dnes termín běžnější. From 947da8c21f9c8023b27b55dfdc13e6c382c04e22 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Thu, 27 Feb 2014 14:52:11 +0100 Subject: [PATCH 002/291] [cs] changes to Chapter 1, section 1.4 --- cs/01-introduction/01-chapter1.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index b1b60c735..7ded7793c 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -3,7 +3,7 @@ Tato kapitola vám ve stručnosti představí systém Git. Začneme od samého začátku. Nahlédneme do historie nástrojů ke správě verzí, poté se budeme věnovat tomu, jak spustit systém Git ve vašem počítači, a nakonec se podíváme na možnosti úvodního nastavení. V této kapitole se dozvíte, k čemu Git slouží a proč byste ho měli používat. Kromě toho se také naučíte, jak Git nastavit podle svých potřeb. ## Správa verzí ## -hi + Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času, a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Příklady verzovaných souborů jsou v této knize ilustrovány na zdrojovém kódu softwaru, avšak ve skutečnosti lze verzování provádět téměř se všemi typy souborů v počítači. Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z angl. Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem. @@ -120,13 +120,13 @@ Nachází-li se konkrétní verze souboru v adresáři Git, je považována za z ## Instalace systému Git ## -Je načase začít systém Git aktivně používat. Instalaci můžete provést celou řadou způsobů — obvyklá je instalace ze zdrojových souborů nebo instalace existujícího balíčku, určeného pro vaši platformu. +Je načase začít systém Git aktivně používat. Instalaci můžete provést celou řadou způsobů. Většinou se využívá buď instalace ze zdrojových souborů, nebo instalace z existujícího balíčku, určeného pro vaši platformu. ### Instalace ze zdrojových souborů ### -Pokud je to možné, je nejvhodnější instalovat Git ze zdrojových souborů. Tak je zaručeno, že vždy získáte aktuální verzi. Každá další verze systému se snaží přidat nová vylepšení uživatelského rozhraní. Použití poslední verze je tedy zpravidla tou nejlepší cestou, samozřejmě pokud vám nedělá problémy kompilace softwaru ze zdrojových souborů. +Pokud je to možné, je nejvhodnější instalovat Git ze zdrojových souborů. Tak je zaručeno, že vždy získáte aktuální verzi. Každá další verze systému se snaží přidat nová vylepšení uživatelského rozhraní. Použití poslední verze je tedy zpravidla tou nejlepší cestou, samozřejmě pokud vám nedělá problémy kompilace softwaru ze zdrojových souborů. Skutečností také je, že mnoho linuxových distribucí obsahuje velmi staré balíčky. Takže pokud nepoužíváte velmi čerstvou distribuci, nebo pokud záměrně používáte starší verzi, bývá instalace ze zdrojových souborů nejlepší volbou. -Před instalcí samotného Gitu musí váš systém obsahovat následující knihovny, na nichž je Git závislý: curl, zlib, openssl, expat, a libiconv. Pokud používáte yum (např. Fedora) nebo apt-get (např. distribuce založené na Debianu), můžete k instalaci použít jeden z následujících příkazů: +Před instalací samotného Gitu musí váš systém obsahovat následující knihovny, na nichž je Git závislý: curl, zlib, openssl, expat, a libiconv. Pokud používáte systém s nástrojem yum (například u distribuce Fedora) nebo apt-get (například distribuce odvozené od Debianu), můžete k instalaci použít jeden z následujících příkazů: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel @@ -138,7 +138,7 @@ Po doinstalování všech potřebných závislostí můžete pokračovat stažen http://git-scm.com/download -Poté přistupte ke kompilaci a instalaci: +Poté spusťte kompilaci a instalaci: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 @@ -151,11 +151,11 @@ Po dokončení instalace můžete rovněž vyhledat aktualizace systému Git pro ### Instalace v Linuxu ### -Chcete-li nainstalovat Git v Linuxu pomocí binárního instalátoru, většinou tak můžete učinit pomocí základního nástroje pro správu balíčků, který byl součástí vaší distribuce. Ve Fedoře můžete použít nástroj yum: +Chcete-li nainstalovat Git v Linuxu pomocí binárního instalátoru, většinou tak můžete učinit pomocí základního nástroje pro správu balíčků, který je součástí vaší distribuce. Ve Fedoře můžete použít nástroj yum: $ yum install git-core -V distribuci založené na Debianu (např. Ubuntu) zkuste použít program apt-get: +V distribuci založené na Debianu (jako je například Ubuntu) zkuste použít program apt-get: $ apt-get install git From 77cce999f6025c7e3d0728bd54e91e1da62b1557 Mon Sep 17 00:00:00 2001 From: Changwoo Ryu Date: Sun, 2 Mar 2014 12:12:54 +0900 Subject: [PATCH 003/291] Fix typos --- ko/02-git-basics/01-chapter2.markdown | 2 +- ko/03-git-branching/01-chapter3.markdown | 2 +- ko/04-git-server/01-chapter4.markdown | 4 ++-- ko/05-distributed-git/01-chapter5.markdown | 2 +- ko/06-git-tools/01-chapter6.markdown | 6 +++--- ko/08-git-and-other-scms/01-chapter8.markdown | 4 ++-- ko/09-git-internals/01-chapter9.markdown | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown index 9353c88e3..5bf08bdfa 100644 --- a/ko/02-git-basics/01-chapter2.markdown +++ b/ko/02-git-basics/01-chapter2.markdown @@ -908,7 +908,7 @@ Git으로 커밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브 v0.1 v1.3 -이 명령은 알파벳 순서로 태그을 보여준다. 사실 순서는 별로 중요한 게 아니다. +이 명령은 알파벳 순서로 태그를 보여준다. 사실 순서는 별로 중요한 게 아니다. 검색 패턴을 사용하여 태그를 검색할 수 있다. Git 소스 저장소는 240여 개의 태그가 있다. 만약 1.4.2 버전의 태그들만 검색하고 싶으면 아래와 같이 실행한다: diff --git a/ko/03-git-branching/01-chapter3.markdown b/ko/03-git-branching/01-chapter3.markdown index 9a66a6841..cf5dade52 100644 --- a/ko/03-git-branching/01-chapter3.markdown +++ b/ko/03-git-branching/01-chapter3.markdown @@ -2,7 +2,7 @@ 모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다. -버전 관리 시스템에서 브랜치를 만드는 과정은 고생스럽다. 개발자가 수동으로 소스코드 디렉토리를 복사해서 브랜치를 만들어야 하고 소스코드의 양이 많으면 브린채를 만드는 시간도 오래 걸린다. +버전 관리 시스템에서 브랜치를 만드는 과정은 고생스럽다. 개발자가 수동으로 소스코드 디렉토리를 복사해서 브랜치를 만들어야 하고 소스코드의 양이 많으면 브랜치를 만드는 시간도 오래 걸린다. 사람들은 브랜치 모델이 Git의 최고의 장점이라고, Git이 다른 것들과 구분되는 특징이라고 말한다. 당최 어떤 점이 그렇게 특별한 것일까? Git의 브랜치는 매우 가볍다. 순식간에 브랜치를 새로 만들고 브랜치 사이를 이동할 수 있다. 다른 버전 관리 시스템과는 달리 Git은 브랜치를 만들어 작업하고 나중에 Merge하는 방법을 권장한다. 심지어 하루에 수십 번씩해도 괜찮다. Git 브랜치에 능숙해지면 개발 방식이 완전히 바뀌고 다른 도구를 사용할 수 없게 된다. diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown index 2755518da..9917fd92b 100644 --- a/ko/04-git-server/01-chapter4.markdown +++ b/ko/04-git-server/01-chapter4.markdown @@ -12,7 +12,7 @@ Git 서버를 운영하는 것은 어렵지 않다. 우선 사용할 전송 프 Git은 Local, SSH, Git, HTTP 이렇게 네 가지의 네트워크 프로토콜을 사용할 수 있다. 이 절에서는 각각 어떤 경우에 유용한지 살펴볼 것이다. -HTTP 프로토콜를 제외한 나머지들은 모두 Git이 서버에 설치돼 있어야 한다. +HTTP 프로토콜을 제외한 나머지들은 모두 Git이 서버에 설치돼 있어야 한다. ### 로컬 프로토콜 ### @@ -482,7 +482,7 @@ Gitosis의 접근제어 방법은 매우 단순하다. 만약 이 프로젝트 readonly = iphone_project members = john -이제 John은 프로젝트를 Clone하거나 Fetch할 수는 있지만, 프로젝트에 Push할 수는 없다. 다양한 사용자와 프로젝트가 있어도 필요한 만큼 그룹을 만들어 사용하면 된다. 그리고 members 항목에 사용자 대신 그룹명을 사용할 수도 있다. 그룹명 앞에 `@`를 붙이면 그 그룹의 사용자을 그대로 상속한다: +이제 John은 프로젝트를 Clone하거나 Fetch할 수는 있지만, 프로젝트에 Push할 수는 없다. 다양한 사용자와 프로젝트가 있어도 필요한 만큼 그룹을 만들어 사용하면 된다. 그리고 members 항목에 사용자 대신 그룹명을 사용할 수도 있다. 그룹명 앞에 `@`를 붙이면 그 그룹의 사용자를 그대로 상속한다: [group mobile_committers] members = scott josie jessica diff --git a/ko/05-distributed-git/01-chapter5.markdown b/ko/05-distributed-git/01-chapter5.markdown index c1ea7508a..11ec5df3c 100644 --- a/ko/05-distributed-git/01-chapter5.markdown +++ b/ko/05-distributed-git/01-chapter5.markdown @@ -466,7 +466,7 @@ Insert 18333fig0518.png ### 대규모 공개 프로젝트 ### -대규모 프로젝트은 보통 수정사항이나 Patch를 수용하는 자신만의 규칙을 마련해놓고 있다. 프로젝트마다 규칙은 서로 다를 수 있으므로 각 프로젝트의 규칙을 미리 알아둘 필요가 있다. 대규모 프로젝트는 대부분 메일링리스트를 통해서 Patch를 받아들이는데 예제를 통해 살펴본다. +대규모 프로젝트는 보통 수정사항이나 Patch를 수용하는 자신만의 규칙을 마련해놓고 있다. 프로젝트마다 규칙은 서로 다를 수 있으므로 각 프로젝트의 규칙을 미리 알아둘 필요가 있다. 대규모 프로젝트는 대부분 메일링리스트를 통해서 Patch를 받아들이는데 예제를 통해 살펴본다. 토픽 브랜치를 만들어 수정하는 작업은 앞서 살펴본 바와 거의 비슷하지만, Patch를 제출하는 방식이 다르다. 프로젝트를 Fork 하여 Push하는 것이 아니라 커밋 내용을 메일로 만들어 개발자 메일링리스트에 제출한다: diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown index 1af11f6b2..af810484d 100644 --- a/ko/06-git-tools/01-chapter6.markdown +++ b/ko/06-git-tools/01-chapter6.markdown @@ -223,7 +223,7 @@ Double Dot으로는 세 개 이상의 레퍼런스에 사용할 수 없지만 $ git log refA refB ^refC $ git log refA refB --not refC -이 조건을 잘 응용하면 작업 중인 브랜치와 다른 브랜치을 매우 상세하게 비교할 수 있다. +이 조건을 잘 응용하면 작업 중인 브랜치와 다른 브랜치를 매우 상세하게 비교할 수 있다. #### Triple Dot #### @@ -987,9 +987,9 @@ Merge해서 서브모듈의 HEAD 값이 변경됐다. 슈퍼프로젝트가 아 ### 슈퍼프로젝트 ### -프로젝트 규모가 크면 CVS나 Subversion에서는 모듈 프로젝트을 간단히 하위 디렉토리로 만들었다. 가끔 Git에서도 이런 Workflow을 사용하려는 개발자들이 있다. +프로젝트 규모가 크면 CVS나 Subversion에서는 모듈 프로젝트를 간단히 하위 디렉토리로 만들었다. 가끔 Git에서도 이런 Workflow을 사용하려는 개발자들이 있다. -Git에서는 각 하위 디렉토리를 별도의 Git 저장소로 만들어야 한다. 그리고 그 저장소을 포함하는 상위 저장소를 만든다. 슈퍼프로젝트의 태그와 브랜치를 이용해서 각 프로젝트의 관계를 구체적으로 정의할 수 있다는 것은 Git만의 장점이다. +Git에서는 각 하위 디렉토리를 별도의 Git 저장소로 만들어야 한다. 그리고 그 저장소를 포함하는 상위 저장소를 만든다. 슈퍼프로젝트의 태그와 브랜치를 이용해서 각 프로젝트의 관계를 구체적으로 정의할 수 있다는 것은 Git만의 장점이다. ### 서브모듈 사용할 때 주의할 점들 ### diff --git a/ko/08-git-and-other-scms/01-chapter8.markdown b/ko/08-git-and-other-scms/01-chapter8.markdown index 307c1a6d4..9ad050838 100644 --- a/ko/08-git-and-other-scms/01-chapter8.markdown +++ b/ko/08-git-and-other-scms/01-chapter8.markdown @@ -16,7 +16,7 @@ Git과 Subversion을 이어주는 명령은 `git svn` 으로 시작한다. 이 `git svn` 명령을 사용할 때는 절름발이인 Subversion을 사용하고 있다는 점을 염두하자. 우리가 로컬 브랜치와 Merge를 맘대로 쓸 수 있다고 하더라도 최대한 일직선으로 히스토리를 유지하는것이 좋다. Git 저장소처럼 사용하지 않는다. -히스토리를 재작성해서 Push하지 말아야 한다. Git을 사용하는 동료들끼기 따로 Git 저장소에 Push하지도 말아야 한다. Subversion은 단순하게 일직선 히스토리만 가능하다. 팀원중 일부는 SVN을 사용하고 일부는 Git을 사용하는 팀이라면 SVN Server를 사용해서 협업하는 것이 좋다. 그래야 삶이 편해진다. +히스토리를 재작성해서 Push하지 말아야 한다. Git을 사용하는 동료들끼리 따로 Git 저장소에 Push하지도 말아야 한다. Subversion은 단순하게 일직선 히스토리만 가능하다. 팀원중 일부는 SVN을 사용하고 일부는 Git을 사용하는 팀이라면 SVN Server를 사용해서 협업하는 것이 좋다. 그래야 삶이 편해진다. ### 설정하기 ### @@ -551,7 +551,7 @@ Mark는 정수 값을 사용해야 하기 때문에 디렉토리를 배열에 $author = 'Scott Chacon ' -이제 Importer에서 출력할 커밋 데이터는 다 준비했다. 이제 출력해보자. 사용할 브랜치, 해당 커밋과 관련된 Mark, 커미터 정보, 커밋 메시지, 이전 커밋를 출력한다. 코드로 만들면 아래와 같다: +이제 Importer에서 출력할 커밋 데이터는 다 준비했다. 이제 출력해보자. 사용할 브랜치, 해당 커밋과 관련된 Mark, 커미터 정보, 커밋 메시지, 이전 커밋을 출력한다. 코드로 만들면 아래와 같다: # print the import information puts 'commit refs/heads/master' diff --git a/ko/09-git-internals/01-chapter9.markdown b/ko/09-git-internals/01-chapter9.markdown index fcf02085b..a30e480e8 100644 --- a/ko/09-git-internals/01-chapter9.markdown +++ b/ko/09-git-internals/01-chapter9.markdown @@ -453,7 +453,7 @@ Git은 zlib으로 파일 내용을 압축하기 때문에 저장 공간이 많 $ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e 4102 .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e -피일을 수정하면 어떻게 되는지 살펴보자: +파일을 수정하면 어떻게 되는지 살펴보자: $ echo '# testing' >> repo.rb $ git commit -am 'modified repo a bit' From a335b61402bc3d5a13b8615258a8478b593e483a Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Thu, 27 Mar 2014 05:52:25 +0900 Subject: [PATCH 004/291] [ko] remove a slang. --- ko/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown index 9917fd92b..1f57aa7b7 100644 --- a/ko/04-git-server/01-chapter4.markdown +++ b/ko/04-git-server/01-chapter4.markdown @@ -16,7 +16,7 @@ HTTP 프로토콜을 제외한 나머지들은 모두 Git이 서버에 설치돼 ### 로컬 프로토콜 ### -가장 기본적인 것이 _로컬 프로토콜_ 이다. 리모트 저장소가 단순히 디스크의 다른 디렉토리에 있을 때 사용한다. 팀원들이 전부 한 시스템에 로그인하여 개발하거나 아니면 NFS같은 것으로 파일시스템을 공유하고 있을 때 사용한다. 전자는 문제가 될 수 있다. 모든 저장소가 한 시스템에 있기 때문에 한순간에 찌질해질 수 있다. +가장 기본적인 것이 _로컬 프로토콜_ 이다. 리모트 저장소가 단순히 디스크의 다른 디렉토리에 있을 때 사용한다. 팀원들이 전부 한 시스템에 로그인하여 개발하거나 아니면 NFS같은 것으로 파일시스템을 공유하고 있을 때 사용한다. 전자는 문제가 될 수 있다. 모든 저장소가 한 시스템에 있기 때문에 한순간에 모두 잃을 수 있다. 공유 파일시스템을 마운트했을 때는 로컬 저장소를 사용하는 것처럼 Clone하고 Push하고 Pull하면 된다. 일단 저장소를 Clone하거나 프로젝트에 리모트 저장소로 추가한다. 추가할 때 URL 자리에 저장소의 경로를 사용한다. 예를 들어 아래와 같이 로컬 저장소를 Clone한다: From ec085463a98c60c63a49af7733563d24f430205d Mon Sep 17 00:00:00 2001 From: Volkan Gezer Date: Mon, 14 Apr 2014 19:49:53 +0200 Subject: [PATCH 005/291] Update 01-chapter3.markdown --- tr/03-git-branching/01-chapter3.markdown | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown index 7eed43e7c..a9a150577 100644 --- a/tr/03-git-branching/01-chapter3.markdown +++ b/tr/03-git-branching/01-chapter3.markdown @@ -472,21 +472,21 @@ Diyelim ki uzak bir dalla yapacaklarınız bitti ve siz ile takım arkadaşları İşte bu! Artık sunucunuzda bu dal olmayacak. Bu sayfayı dikkatlice anlamak isteyebilirsiniz, çünkü muhtemelen bu komuta ihtiyacınız olacak ancak sözdizimini unutacaksınız. Bu komutu hatırlamanın bir yolu daha önceden biraz bahsedilen `git push [uzakadı] [yereldal]:[uzakdal]` sözdizimini hatırlamaktır. Eğer `[yereldal]` kısmını yazmazsanız, aslında dediğiniz şey “Benim tarafımdan bir şey alma ancak `[uzakdal]`dan al.” -## Rebasing (Tekrar Adresleme) ## Zemin, Kök, Temel +## Rebasing (Tekrar Adresleme) ## Git içerisinde, değişiklikleri bir daldan diğerine bütünleştirmek için iki temel yol bulunuyor: `merge` ve `rebase`. Bu bölümde sadece rebase komutunun ne olduğunu, nasıl yapılacağını, neden mükemmel bir araç olduğunu ve hangi durumlarda kullanmak istemeyeceğinizi öğreneceksiniz. -### The Basic Rebase ### +### Temel Tekrar Adresleme ### -If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches. +Birleştirme kısmındaki örneğe geri giderseniz (Figür 3-27'ye bakın), çalışmanızı ayırdığınızı ve iki farklı dal üzerinde gönderi yaptığınızı görebilirsiniz. Insert 18333fig0327.png -Figure 3-27. Your initial diverged commit history. +Figure 3-27. İlk ayrılan gönderi geçmişi. -The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28. +Dalları bütünlemenin en kolay yolu - daha önceden anlattığımız gibi - `merge` komutudur. Bu komut, en son iki dal bellek kopyası (C3 ve C4) ve ikisinin en yakın ortak atası (C2) arasında üç yönlü bir birleştirme yapar. Bunun sonucunda yeni bir bellek kopyası (ve gönderi) oluşturur. Bkz. Figür 3-28. Insert 18333fig0328.png -Figure 3-28. Merging a branch to integrate the diverged work history. +Figure 3-28. Ayrılmış çalışma geçmişini bütünleştirmek için bir dal birleştirmek. However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one. From 5a321321a9e04ad3d19b7978082ec5b809fdc50e Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Sun, 27 Apr 2014 20:53:28 +0200 Subject: [PATCH 006/291] Expl: in `git log --after=2008-10-01` the time defaults to the time the command is run. So e.g. the command is equiv to `git log --after="2008-10-01 09:00:00"` when run at 09:00:00 --- en/02-git-basics/01-chapter2.markdown | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 8090ba342..2d8793891 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -659,8 +659,11 @@ The lines must be formatted as follows For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and were not merges, you can run something like this: - $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ - --before="2008-11-01" --no-merges -- t/ + $ # get dates on-or-after "2008-10-01 00:00:00" + $ # and on-or-before "2008-11-01 00:00:00" + $ + $ git log --pretty="%h - %s" --author=gitster --after="2008-10-01 00:00:00" \ + --before="2008-11-01 00:00:00" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi @@ -670,6 +673,14 @@ For example, if you want to see which commits modifying test files in the Git so Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria. +When using `git log` without specifying time, + + git log --after=2008-10-01 --before=2008-11-01 + +then it defaults to using the time at the instant the command is executed. For example when the above command is executed at time 09:00:00, then the result is equivalent to doing: + + git log --after="2008-10-01 09:00:00" --before="2008-11-01 09:00:00" + ### Using a GUI to Visualize History ### If you like to use a more graphical tool to visualize your commit history, you may want to take a look at a Tcl/Tk program called `gitk` that is distributed with Git. Gitk is basically a visual `git log` tool, and it accepts nearly all the filtering options that `git log` does. If you type `gitk` on the command line in your project, you should see something like Figure 2-2. From 7a6b7d18d7bfbd6f027f4ed743ba3743f033cc1e Mon Sep 17 00:00:00 2001 From: Ciro Santilli Date: Mon, 28 Apr 2014 16:53:39 +0200 Subject: [PATCH 007/291] Set dummy merge driver merge ours .gitattributes. --- en/07-customizing-git/01-chapter7.markdown | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index 7029378e5..a71e44d53 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -535,6 +535,10 @@ This is helpful if a branch in your project has diverged or is specialized, but database.xml merge=ours +And then define a dummy `ours` merge strategy with: + + git config --global merge.ours.driver true + If you merge in the other branch, instead of having merge conflicts with the database.xml file, you see something like this: $ git merge topic From 949cfa3736c0891791d7d9da06591c47dd11d4b5 Mon Sep 17 00:00:00 2001 From: kanhua Date: Tue, 29 Apr 2014 23:15:31 +0100 Subject: [PATCH 008/291] imporve some zh-tw translation in git-diff section --- zh-tw/02-git-basics/01-chapter2.markdown | 27 ++++++++++++------------ 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown index 467ec27f8..2f80c92c1 100644 --- a/zh-tw/02-git-basics/01-chapter2.markdown +++ b/zh-tw/02-git-basics/01-chapter2.markdown @@ -1,6 +1,6 @@ # Git 基礎 # -若讀者只需要閱讀一個章節即可開始使用Git，這章就是你所需要的。 本章節涵蓋讀者大部份用到Git時需要使用的所有基本命令。 在讀完本章節後，讀者應該有能力組態及初始化一個儲存庫、開始及停止追蹤檔案、暫存及提交更新。 還會提到如何讓Git忽略某些檔案、如何輕鬆且很快地救回失誤、如何瀏覽讀者的專案歷史及觀看各個已提交的更新之間的變更、以及如何從遠端儲存庫`拉`更新下來或將更新`推`上去。 +讀完這一章，你就可以開始使用Git了。本章節涵蓋大部份最常被使用的Git基本指令。 在讀完本章節後，讀者應該有能力組態及初始化一個儲存庫(repository)、開始及停止追蹤檔案(track)、暫存(stage)及提交(commit)更新。 本章還會提到如何讓Git忽略某些檔案、如何輕鬆且很快地救回失誤、如何瀏覽讀者的專案歷史及觀看各個已提交的更新之間的變更、以及如何從遠端儲存庫`拉`(pull)更新下來或將更新`推`(push)上去。 ## 取得Git儲存庫 ## @@ -57,7 +57,7 @@ Insert 18333fig0201.png On branch master nothing to commit, working directory clean -這意謂著讀者有一份乾淨的工作目錄（換句話說，沒有未被追蹤或已被修改的檔案）。 Git未看到任何未被追蹤的檔案，否則會將它們列出。 最後，這個命令告訴讀者目前在哪一個分支。 到目前為止，一直都是master，這是預設的。 目前讀者不用考慮它。 下一個章節會詳細介紹分支。 +Wokring directory clean意謂著目前的工作目錄沒有未被追蹤或已被修改的檔案。Git未看到任何未被追蹤的檔案，否則會將它們列出。 最後，這個命令告訴讀者目前在哪一個分支(branch)。到目前為止，一直都是master，這是預設的。下一個章節會詳細介紹分支(branch)，目前我們先不考慮它。 假設讀者新增一些檔案到專案，如`README`。 若該檔案先前並不存在，執行 `git status` 命令後，讀者會看到未被追蹤的檔案，如下： @@ -71,15 +71,15 @@ Insert 18333fig0201.png nothing added to commit but untracked files present (use "git add" to track) -讀者可看到新增的`README`尚未被追蹤，因為它被列在輸出訊息的 Untracked files 下方。 除非讀者明確指定要將該檔案加入提交的快照，Git不會主動將它加入。 這樣就不會突然地將一些二進位格式的檔案或其它讀者並不想加入的檔案含入。 讀者的確是要新增 `README` 檔案，因此讓我們開始追蹤該檔案。 +我們可以看到新增的`README`尚未被追蹤，因為它被列在輸出訊息的 Untracked files 下方。 除非我們明確指定要將該檔案加入提交的快照，Git不會主動將它加入。這樣可以避免加入一些二進位格式的檔案或其它使用者不想列入追蹤的檔案。 不過在這個例子中，我們的確是要將 `README` 檔案加入追蹤: ### 追蹤新檔案 ### -要追蹤新增的檔案，讀者可使用`git add`命令。 欲追蹤`README`檔案，讀者可執行： +要追蹤新增的檔案，我們可以使用`git add`命令。例如:要追蹤`README`檔案，可執行： $ git add README -若讀者再度檢查目前狀態，可看到`README`檔案已被列入追蹤並且已被暫存： +如此一來，我們重新檢查狀態(status)時，可看到`README`檔案已被列入追蹤並且已被暫存： $ git status On branch master @@ -89,11 +89,11 @@ Insert 18333fig0201.png new file: README -因為它被放在Changes to be commited文字下方，讀者可得知它已被暫存起來。 若讀者此時提交更新，剛才執行`git add`加進來的檔案就會被記錄在歷史的快照。 讀者可能可回想一下先前執行`git init`後也有執行過`git add`，開始追蹤目錄內的檔案。 `git add`命令可接受檔名或者目錄名。 若是目錄名，會遞迴將整個目錄下所有檔案及子目錄都加進來。 +因為它被放在Changes to be commited文字下方，讀者可得知它已被暫存起來。 若讀者此時提交更新，剛才執行`git add`加進來的檔案就會被記錄在歷史的快照。 讀者可能可回想一下先前執行`git init`後也有執行過`git add`，開始追蹤目錄內的檔案。`git add`命令可接受檔名或者目錄名。 若是目錄名，Git會以遞迴(recursive)的方式會將整個目錄下所有檔案及子目錄都加進來。 ### 暫存已修改檔案 ### -讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前儲存庫的狀態。 讀者會看到類似以下文字： +讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前儲存庫的狀態。我們會看到類似以下文字： $ git status On branch master @@ -159,7 +159,7 @@ Insert 18333fig0201.png *.[oa] *~ -第一列告訴Git忽略任何檔名為`.o`或`.a`結尾的檔案，它們是可能是編譯系統建置讀者的程式碼時產生的目的檔及程式庫。 第二列告訴Git忽略所有檔名為~結尾的檔案，通常被很多文書編輯器，如：Emacs，使用的暫存檔案。 讀者可能會想一併將log、tmp、pid目錄及自動產生的文件等也一併加進來。 依據類推。 在讀者要開始開發之前將`.gitignore`設定好，通常是一個不錯的點子。 這樣子讀者不會意外地將真的不想追蹤的檔案提交到Git儲存庫。 +第一列告訴Git忽略任何檔名為`.o`或`.a`結尾的檔案，它們是可能是編譯系統建置讀者的程式碼時產生的目的檔及程式庫。 第二列告訴Git忽略所有檔名為~結尾的檔案，通常被很多文書編輯器，如：Emacs，使用的暫存檔案。 讀者可能會想一併將log、tmp、pid目錄及自動產生的文件等也一併加進來。 依據類推。在讀者要開始開發之前將`.gitignore`設定好，通常是一個不錯的點子。這樣子讀者不會意外地將真的不想追蹤的檔案提交到Git儲存庫。 編寫`.gitignore`檔案的規則如下： @@ -190,9 +190,10 @@ A `**/` pattern is available in Git since version 1.8.2. ### 檢視已暫存及尚未暫存的更動 ### -若`git status`命令仍無法清楚告訴讀者想要的資訊（讀者想知道的是更動了哪些內容，而不是哪些檔案）。 可使用`git diff`命令。 稍後我們會更詳盡講解該命令。 讀者使用它時通常會是為了瞭解兩個問題： 目前已做的修改但尚未暫存的內容是哪些？ 以及將被提交的暫存資料有哪些？ 雖然`git status`一般來說即可回答這些問題。 `git diff`可精確的顯示哪些列被加入或刪除，以修補檔方式表達。 +在某些情況下，`git status`指令提供的資訊就太過簡要。 +有的時候我們不只想知道那些檔案被更動，而是想更進一步知道被檔案的內容被做了那些修改，這時我們可以使用`git diff`命令。稍後我們會有更詳盡講解該命令。讀者使用它時通常會是為了瞭解兩個問題：目前已做的修改但尚未暫存的內容是哪些？以及將被提交的暫存資料有哪些？儘管`git status`指令可以大略回答這些問題，但`git diff`可顯示檔案裡的哪些列被加入或刪除，以修補檔(patch)方式表達。 -假設讀者編輯並暫存`README`，接者修改`benchmarks.rb`檔案，卻未暫存。 若讀者檢視目前的狀況，會看到類似下方文字： +假設讀者編輯並暫存(stage)`README`，接著修改`benchmarks.rb`檔案，卻未暫存。若讀者檢視目前的狀況，會看到類似下方文字： $ git status On branch master @@ -227,9 +228,9 @@ A `**/` pattern is available in Git since version 1.8.2. log = git.commits('master', 15) log.size -這命令比對目前工作目錄及暫存區域後告訴讀者哪些變更尚未被暫存。 +這命令會比對目前工作目錄(working directory)及暫存區域(stage area)的版本，然後顯示尚未被存入暫存區(stage area)的變更。 -若讀者想知道將被提交的暫存資料，使用`git diff --cached`（在Git 1.6.1及更新版本，也可以使用較易記憶的`git diff --staged` 命令）。 這命令比對暫存區域及最後一個提交。 +若讀者想比對暫存區域(stage)及最後一次提交(commit)的差異，可用`git diff --cached`指令（Git 1.6.1之後的版本，可用較易記的`git diff --staged` 指令）: $ git diff --cached diff --git a/README b/README @@ -244,7 +245,7 @@ A `**/` pattern is available in Git since version 1.8.2. + +Grit is a Ruby library for extracting information from a Git repository -很重要的一點是`git diff`不會顯示最後一次commit後的所有變更；只會顯示尚未暫存的變更。 這一點可能會混淆，若讀者已暫存所有的變更，`git diff`不會顯示任何資訊。 +很重要的一點是`git diff`不會顯示最後一次commit後的所有變更；只會顯示尚未存入暫存區(即unstaged)的變更。這麼說可能會混淆，舉個例子來說，若讀者已暫存(stage)所有的變更，輸入`git diff`不會顯示任何資訊。 舉其它例子，若讀者暫存`benchmarks.rb`檔案後又編輯，可使用`git diff`看已暫存的版本與工作目錄內版本尚未暫存的變更： From 1cf071f1e71c432de52c6c15479af72100f98182 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Fri, 2 May 2014 02:31:19 +0200 Subject: [PATCH 009/291] [es] Update chapter 1: translation of a new paragraph Translation of a paragraph added in bc3f922f about Windows Git usage --- es/01-introduction/01-chapter1.markdown | 2 ++ 1 file changed, 2 insertions(+) diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index 39830df0a..cfddccc5b 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -182,6 +182,8 @@ Instalar Git en Windows es muy fácil. El proyecto msysGit tiene uno de los proc Una vez instalado, tendrás tanto la versión de línea de comandos (incluido un cliente SSH que nos será útil más adelante) como la interfaz gráfica de usuario estándar. +Nota para el uso en Windows: Se debería usar Git con la shell provista por msysGit (estilo Unix), lo cual permite usar las complejas líneas de comandos de este libro. Si por cualquier razón se necesitara usar la shell nativa de Windows, la consola de línea de comandos, se han de usar las comillas dobles en vez de las simples (para parámetros que contengan espacios) y se deben entrecomillar los parámetros terminándolos con el acento circunflejo (^) si están al final de la línea, ya que en Windows es uno de los símbolos de continuación. + ## Configurando Git por primera vez ## Ahora que tienes Git en tu sistema, querrás hacer algunas cosas para personalizar tu entorno de Git. Sólo es necesario hacer estas cosas una vez; se mantendrán entre actualizaciones. También puedes cambiarlas en cualquier momento volviendo a ejecutar los comandos correspondientes. From cc734916180e16bf53519e08a28a0a5aeb28eb63 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Fri, 2 May 2014 03:02:20 +0200 Subject: [PATCH 010/291] [es] Update chapter 1: line change from english version From bfead6c2 "added another ubuntu dep" --- es/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index cfddccc5b..c5be3376e 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -132,7 +132,7 @@ Para instalar Git, necesitas tener las siguientes librerías de las que Git depe openssl-devel zlib-devel $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ - libz-dev + libz-dev libssl-dev Cuando tengas todas las dependencias necesarias, puedes descargar la versión más reciente de Git desde su página web: From 8ffdb47f1580407348822193eef7540690cb9c1d Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Fri, 2 May 2014 03:32:18 +0200 Subject: [PATCH 011/291] [es] Update chapter 1: change from english version From 33e9d89 "Reference whole chapter instead of a single section. " --- es/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index c5be3376e..c99ee0258 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -93,7 +93,7 @@ Verás estos valores hash por todos lados en Git, ya que los usa con mucha frecu Cuando realizas acciones en Git, casi todas ellas sólo añaden información a la base de datos de Git. Es muy difícil conseguir que el sistema haga algo que no se pueda deshacer, o que de algún modo borre información. Como en cualquier VCS, puedes perder o estropear cambios que no has confirmado todavía; pero después de confirmar una instantánea en Git, es muy difícil de perder, especialmente si envías (push) tu base de datos a otro repositorio con regularidad. -Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de fastidiar gravemente las cosas. Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver “Entre bambalinas” en el Capítulo 9. +Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de fastidiar gravemente las cosas. Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver Capítulo 9. ### Los tres estados ### From 7980d7dd46a97c9c3aff1f015c932941dcf10454 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Fri, 2 May 2014 03:41:15 +0200 Subject: [PATCH 012/291] [es] Update chapter 1: added paragraph from english version From 0cec524 "1.1 (en): Clarify the wording in the first paragraphs to be less awkward " --- es/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index c99ee0258..593d5a6d3 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -4,7 +4,7 @@ Este capítulo tratará sobre cómo empezar con Git. Partiremos explicando algun ## Acerca del control de versiones ## -¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. Para los ejemplos de este libro llevarás control de versiones de código fuente, aunque en realidad puedes hacer esto con casi cualquier tipo de archivo que encuentres en un ordenador. +¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. A pesar de que los ejemplos de este libro muestran código fuente como archivos bajo control de versiones, en realidad cualquier tipo de archivo que encuentres en un ordenador puede ponerse bajo control de versiones. Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño (algo que sin duda quieres), un sistema de control de versiones (Version Control System o VCS en inglés) es una elección muy sabia. Te permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un VCS también significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo. From bb0158b04cfb6fd7fa6b1dda5318f20ce9874c7b Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Fri, 2 May 2014 03:51:11 +0200 Subject: [PATCH 013/291] [es] Update chapter 1: change from english version From b294744 "Minor updates (Windows & typo) " --- es/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index 593d5a6d3..64bc3bbdf 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -194,7 +194,7 @@ Git trae una herramienta llamada `git config` que te permite obtener y establece * Archivo `~/.gitconfig` file: Específico a tu usuario. Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`. * Archivo config en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`. -En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`C:\Documents and Settings\$USER` para la mayoría de usuarios). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador. +En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`%USERPROFILE%` in Windows’ environment), que es `C:\Documents and Settings\$USER` para la mayoría de usuarios, pedendiendo de la versión (`$USER` es `%USERNAME%` en el entorno Windows). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador. ### Tu identidad ### From db581019330e1988f9aedc5dea8bd2bf13a314a6 Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Sun, 4 May 2014 00:36:54 +0200 Subject: [PATCH 014/291] how to robustly use `git log` and limit the commits by date/time * show that CommitDate is considered, when using `--after` and `--before` * show that `--after` means on-or-after and `--before` means on-or-before * best practices: show how to limit by absolute time (ISO format), so that the log command's results are identical for everyone around the world * format dates returned by git log according to your timezone of choice, using TZ (tested on GNU/Linux and Windows) and `--date=local` * explain how `--after=2008-06-01` default to using time when command is run; and how offsets from UTC are (in this case) not corrected for DST changes. --- en/02-git-basics/01-chapter2.markdown | 116 ++++++++++++++++++++++---- 1 file changed, 99 insertions(+), 17 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 2d8793891..6ec2e3cf4 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -652,18 +652,108 @@ The lines must be formatted as follows Option Description -(n) Show only the last n commits - --since, --after Limit the commits to those made after the specified date. - --until, --before Limit the commits to those made before the specified date. + --since, --after Limit the commits to those whose CommitDate was made on-or-after the specified date/time. + --until, --before Limit the commits to those whose CommitDate was made on-or-before the specified date/time. --author Only show commits in which the author entry matches the specified string. --committer Only show commits in which the committer entry matches the specified string. -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and were not merges, you can run something like this: - $ # get dates on-or-after "2008-10-01 00:00:00" - $ # and on-or-before "2008-11-01 00:00:00" - $ - $ git log --pretty="%h - %s" --author=gitster --after="2008-10-01 00:00:00" \ - --before="2008-11-01 00:00:00" --no-merges -- t/ +### Limiting Log Output according to Date/Time ### + +To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone, use + + $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ + --pretty=fuller + +However this command will not yield identical results, when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments, so that all your collegues around the world would get the same results as you. First determine the absolute-times using e.g. the `date` program: + + $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 00:00:00" -Is + 2014-04-29T00:00:00+0200 + + $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 23:59:59" -Is + 2014-04-29T23:59:59+0200 + + $ # for TZ values of various countries/cities + $ # see http://wiki.openwrt.org/doc/uci/system#time.zones + + $ # Alternative (simplification) under GNU/Linux -- see /usr/share/zoneinfo/ + $ TZ="Europe/Paris" date --date="2014-04-29 00:00:00" -Is + 2014-04-29T00:00:00+0200 + + $ TZ="Europe/Paris" date --date="2014-04-29 23:59:59" -Is + 2014-04-29T23:59:59+0200 + +Using the resulting absolute-times, we can now modify the above example and construct a git log command, that gives repeatable ("Paris"-based) results for everyone, irrespective of location: + + $ git log --after="2014-04-29T00:00:00+0200" \ + --before="2014-04-29T23:59:59+0200" --pretty=fuller + +`+0200` means that here Paris is 2 hours ahead of UTC: + +For example: for `2014-04-29T23:59:59+0200` the corresponding + +UTC is `2014-04-29 21:59:59`. + + +To obtain commits made at a specific instant in time, we can use e.g. + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller + + commit de7c201a10857e5d424dbd8db880a6f24ba250f9 + Author: Ramkumar Ramachandra + AuthorDate: Mon Apr 29 18:19:37 2013 +0530 + Commit: Junio C Hamano + CommitDate: Mon Apr 29 08:07:22 2013 -0700 + + git-completion.bash: lexical sorting for diff.statGraphWidth + + df44483a (diff --stat: add config option to limit graph width, + 2012-03-01) added the option diff.startGraphWidth to the list of + configuration variables in git-completion.bash, but failed to notice + that the list is sorted alphabetically. Move it to its rightful place + in the list. + + Signed-off-by: Ramkumar Ramachandra + Signed-off-by: Junio C Hamano + +The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`--date=default`), which shows timezone information of respective author and commiter. + +We can change the way that these are displayed in the resulting log list. `--date=local` displays times according to your local timezone: + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local + +To show all times according to e.g. French timezone, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Europe/Paris"`): + + $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" \ + git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local + +Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) as well as `--date=relative` (e.g. "2 hours ago"). + +When using `git log` without specifying time, + + $ git log --after=2008-06-01 --before=2008-07-01 + +the time defaults to the time at which the command is run. For example when the above command is executed at 09:00, then the result is usually equivalent to doing: + + $ git log --after="2008-06-01 09:00:00" \ + --before="2008-07-01 09:00:00" + +More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered. The time that will be considered, is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Paris at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing: + + $ git log --after="2008-06-01T09:00:00+0100" \ + --before="2008-07-01T09:00:00+0100" + +even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Paris: + + `2008-06-01T10:00:00+0200`. + +As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and committed with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: + + $ git log --pretty="%h - %s" --author=gitster --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi @@ -671,15 +761,7 @@ For example, if you want to see which commits modifying test files in the Git so 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria. - -When using `git log` without specifying time, - - git log --after=2008-10-01 --before=2008-11-01 - -then it defaults to using the time at the instant the command is executed. For example when the above command is executed at time 09:00:00, then the result is equivalent to doing: - - git log --after="2008-10-01 09:00:00" --before="2008-11-01 09:00:00" +Of the more than 36,000 commits in the Git source code history, this command shows the 6 that match those criteria. ### Using a GUI to Visualize History ### From 9de0db392918e9cc9afe2a4d301d76f9578f9b75 Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Sun, 4 May 2014 01:05:32 +0200 Subject: [PATCH 015/291] minor: fix code formatting (for pdf output) --- en/02-git-basics/01-chapter2.markdown | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 6ec2e3cf4..dc3d4ccc2 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -752,8 +752,9 @@ even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Paris: As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and committed with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: - $ git log --pretty="%h - %s" --author=gitster --after="2008-10-01T00:00:00-0400" \ - --before="2008-10-31T23:59:59-0400" --no-merges -- t/ + $ git log --pretty="%h - %s" --author=gitster \ + --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi From f987da8c61924b4f710fd9aac26619bf6b5e9d85 Mon Sep 17 00:00:00 2001 From: iosias Date: Mon, 5 May 2014 10:02:30 -0700 Subject: [PATCH 016/291] Update 01-chapter7.markdown Global variables are not necessary to demonstrate anything in this script. Tested: % cat foo.rb #!/usr/bin/env ruby refname = ARGV[0] oldrev = ARGV[1] newrev = ARGV[2] user = ENV['USER'] puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" % ./foo.rb refs/heads/what $(git rev-parse HEAD) $(git rev-parse HEAD~~) Enforcing Policies... (refs/heads/what) (27240a) (ae2ef7) --- en/07-customizing-git/01-chapter7.markdown | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index 7029378e5..b1dbaa989 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -613,14 +613,12 @@ All the server-side work will go into the update file in your hooks directory. T #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -Yes, I’m using global variables. Don’t judge me — it’s easier to demonstrate in this manner. + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### Enforcing a Specific Commit-Message Format #### From 88239bb0ddb32e60334f59b2346ca1c101e6c4fd Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Mon, 12 May 2014 00:35:11 +0200 Subject: [PATCH 017/291] [es] Update Chapter 1: word mistake --- es/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index 64bc3bbdf..e340e566b 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -194,7 +194,7 @@ Git trae una herramienta llamada `git config` que te permite obtener y establece * Archivo `~/.gitconfig` file: Específico a tu usuario. Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`. * Archivo config en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`. -En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`%USERPROFILE%` in Windows’ environment), que es `C:\Documents and Settings\$USER` para la mayoría de usuarios, pedendiendo de la versión (`$USER` es `%USERNAME%` en el entorno Windows). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador. +En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`%USERPROFILE%` in Windows’ environment), que es `C:\Documents and Settings\$USER` para la mayoría de usuarios, dependiendo de la versión (`$USER` es `%USERNAME%` en el entorno Windows). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador. ### Tu identidad ### From 305be5218cefa0d5db062de83a65107efb269dec Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 18:32:06 +0200 Subject: [PATCH 018/291] [es] Update Chapter 2 Update from commit "Added fix for git remote -v example" 7ba488683f86e8b507c0f04c36544f512bbc3447 --- es/02-git-basics/01-chapter2.markdown | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index 5d981cf99..553f46f4b 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -738,7 +738,8 @@ Para ver qué repositorios remotos tienes configurados, puedes ejecutar el coman También puedes añadir la opción `-v`, que muestra la URL asociada a cada repositorio remoto: $ git remote -v - origin git://github.com/schacon/ticgit.git + origin git://github.com/schacon/ticgit.git (fetch) + origin git://github.com/schacon/ticgit.git (push) Si tienes más de un remoto, este comando los lista todos. Por ejemplo, mi repositorio Grit tiene esta pinta: From aa3000778b3827f0222f2207cce38b3a3c7aeb88 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 19:52:51 +0200 Subject: [PATCH 019/291] [es] Update Chapter 2 from english version Update from commit "Chapter 2 improvements and corrections " cfdce8587ed1654f07665660d5347a4b6309a062 --- es/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index 553f46f4b..cbbc2d466 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -1007,7 +1007,7 @@ Puedes incluso etiquetar confirmaciones después de avanzar sobre ellas. Supón Ahora, supón que olvidaste etiquetar el proyecto en v1.2, que estaba en la confirmación "updated rakefile". Puedes hacerlo ahora. Para etiquetar esa confirmación especifica la suma de comprobación de la confirmación (o una parte de la misma) al final del comando: - $ git tag -a v1.2 9fceb02 + $ git tag -a v1.2 -m 'version 1.2' 9fceb02 Puedes ver que has etiquetado la confirmación: From 0f3652ac67c02c48bffce1ab77a65cd0fbae5957 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 20:24:42 +0200 Subject: [PATCH 020/291] [es] Update Chapter 2: new sentence from English version Updated from "Minor updates (Windows & typo)" b294744d98a6f6cdbc3508b0058f8616147c1596 --- es/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index cbbc2d466..b10c1831c 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -380,7 +380,7 @@ El comando `git rm` acepta archivos, directorios, y patrones glob. Es decir, que $ git rm log/\*.log -Fíjate en la barra hacia atrás (`\`) antes del `*`. Es necesaria debido a que Git hace su propia expansión de rutas, además de la expansión que hace tu shell. Este comando elimina todos los archivos con la extensión `.log` en el directorio `log/`. También puedes hacer algo así: +Fíjate en la barra hacia atrás (`\`) antes del `*`. Es necesaria debido a que Git hace su propia expansión de rutas, además de la expansión que hace tu shell. En la consola del sistema de Windows, esta barra debe de ser omitida. Este comando elimina todos los archivos con la extensión `.log` en el directorio `log/`. También puedes hacer algo así: $ git rm \*~ From 6e793954966d8dcc214105d57350515f20686fb4 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 21:26:27 +0200 Subject: [PATCH 021/291] [es] Update Chapter 2: new sentence from English version Updated from commit: "Mention --oneline in Table 2-2" 5502e94d3237d285eb3157cc7e4d6710d650464e --- es/02-git-basics/01-chapter2.markdown | 1 + 1 file changed, 1 insertion(+) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index b10c1831c..232d0b4e9 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -585,6 +585,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra --relative-date Muestra la fecha en formato relativo (por ejemplo, “2 weeks ago” (“hace 2 semanas”)) en lugar del formato completo. --graph Muestra un gráfico ASCII con la historia de ramificaciones y uniones. --pretty Muestra las confirmaciones usando un formato alternativo. Posibles opciones son oneline, short, full, fuller y format (mediante el cual puedes especificar tu propio formato). + --oneline Un cómodo acortamiento de la opción `--pretty=oneline --abbrev-commit`. ### Limitando la salida del histórico ### From 4b2c0b013aa544f0ecc9873798c41625b2edb54d Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 21:38:29 +0200 Subject: [PATCH 022/291] [es] Update Chapter 2 from English version Updated from commit: "Add an example on `**/` pattern to the example of .gitignore file." df7639bb6d5b6ef453de18bd43d0b7f59464d1ab --- es/02-git-basics/01-chapter2.markdown | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index 232d0b4e9..7127ba3e7 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -180,6 +180,10 @@ He aquí otro ejemplo de archivo .gitignore: build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt + # ignore all .txt files in the doc/ directory + doc/**/*.txt + +El patrón `**/` está disponible en Git desde la versión 1.8.2. ### Viendo tus cambios preparados y no preparados ### From 71cc219597a07e81ab3360944254614151c22816 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 22:21:37 +0200 Subject: [PATCH 023/291] [es] Update Chapter 2: Translation of some new English paragraphs Updated from commit: "Add --word-diff option description" 716e1926c63890027cf133492bf59c8f05e8bfa1 and from commit: "Add --word-diff option description v2" aa830655d85f8799554a8789a9607347c81e47be --- es/02-git-basics/01-chapter2.markdown | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index 7127ba3e7..12d9cc29c 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -494,6 +494,26 @@ Una de las opciones más útiles es `-p`, que muestra las diferencias introducid Esta opción muestra la misma información, pero añadiendo tras cada entrada las diferencias que le corresponden. Esto resulta muy útil para revisiones de código, o para visualizar rápidamente lo que ha pasado en las confirmaciones enviadas por un colaborador. +A veces es más fácil revisar cambios a nivel de palabra que a nivel de línea. Git dispone de la opción `--word-diff`, que se puede añadir al comando `git log -p` para obtener las diferencias por palabras en lugar de las diferencias línea por línea. Formatear las diferencias a nivel de palabra es bastante inusual cuando se aplica a código fuente, pero resulta muy práctico cuando se aplica a grandes archivos de texto, como libros o tu propia tesis. He aquí un ejemplo: + + $ git log -U1 --word-diff + commit ca82a6dff817ec66f44342007202690a93763949 + Author: Scott Chacon + Date: Mon Mar 17 21:52:11 2008 -0700 + + changed the version number + + diff --git a/Rakefile b/Rakefile + index a874b73..8f94139 100644 + --- a/Rakefile + +++ b/Rakefile + @@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s| + s.name = "simplegit" + s.version = [-"0.1.0"-]{+"0.1.1"+} + s.author = "Scott Chacon" + +Como se puede ver, no aparecen líneas añadidas o eliminadas en la salida como en las diferencias normales. Se puede ver la palabra añadida encerrada en `{+ +}` y la eliminada en `[- -]`. Puede que se quiera reducir las usuales tres líneas de contexto en las diferencias a sólo una línea puesto que el contexto es ahora de palabras, no de líneas. Se puede hacer esto con `-U1`, como hicimos en el ejemplo de arriba. + También puedes usar con `git log` una serie de opciones de resumen. Por ejemplo, si quieres ver algunas estadísticas de cada confirmación, puedes usar la opción `--stat`: $ git log --stat @@ -581,6 +601,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra Opción Descripción -p Muestra el parche introducido en cada confirmación. + --word-diff Muestra el parche en formato de una palabra. --stat Muestra estadísticas sobre los archivos modificados en cada confirmación. --shortstat Muestra solamente la línea de resumen de la opción `--stat`. --name-only Muestra la lista de archivos afectados. From 4111372d85cc0584a8b9b2768d37da6abdfaabc5 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Tue, 13 May 2014 22:42:23 +0200 Subject: [PATCH 024/291] [es] Update Chapter 2: new sentence from English version Update from commit: "Direct the reader directly to the git-completion download link" 21e84addadf2ea58eebfeb77379fc0434aa952a3 --- es/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index 12d9cc29c..bc2425c73 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -1092,9 +1092,9 @@ Antes de que terminemos este capitulo de Git básico, unos pocos trucos y consej ### Autocompletado ### -Si usas el shell Bash, Git viene con un buen script de autocompletado que puedes activar. Descarga el código fuente de Git y busca en el directorio `contrib/completion`; ahí debe haber un archivo llamado `git-completion.bash`. Copia este fichero en tu directorio `home` y añade esto a tu archivo `.bashrc`: +Si usas el shell Bash, Git viene con un buen script de autocompletado que puedes activar. Descárgalo directamente desde el código fuente de Git en `https://github.com/git/git/blob/master/contrib/completion/git-completion.bash`, copia este fichero en tu directorio `home` y añade esto a tu archivo `.bashrc`: - source ~/.git-completion.bash + source ~/git-completion.bash Si quieres que Git tenga automáticamente autocompletado para todos los usuarios, copia este script en el directorio `/opt/local/etc/bash_completion.d` en sistemas Mac, o en el directorio `/etc/bash_completion.d/` en sistemas Linux. Este es un directorio de scripts que Bash cargará automáticamente para proveer de autocompletado. From d0551ea518abe1e791ab9a34fd743a48c60eb010 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Wed, 14 May 2014 00:23:21 +0200 Subject: [PATCH 025/291] [es] Updated Chapter 2: Included not translated paragraph in a comment This English paragraph comes from commit: "As of current Git version, --all-match matches greps " 60e261895a77951a6541470c9438f32a1e5b7fd0 I have included it here to not forget that it should be translated if necesary. --- es/02-git-basics/01-chapter2.markdown | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index bc2425c73..d46c1cb7d 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -624,6 +624,13 @@ Este comando acepta muchos formatos. Puedes indicar una fecha concreta (“2008- También puedes filtrar la lista para que muestre sólo aquellas confirmaciones que cumplen ciertos criterios. La opción `--author` te permite filtrar por autor, y `--grep` te permite buscar palabras clave entre los mensajes de confirmación. (Ten en cuenta que si quieres aplicar ambas opciones simultáneamente, tienes que añadir `--all-match`, o el comando mostrará las confirmaciones que cumplan cualquiera de las dos, no necesariamente las dos a la vez.) + + La última opción verdaderamente útil para filtrar la salida de `git log` es especificar una ruta. Si especificas la ruta de un directorio o archivo, puedes limitar la salida a aquellas confirmaciones que introdujeron un cambio en dichos archivos. Ésta debe ser siempre la última opción, y suele ir precedida de dos guiones (`--`) para separar la ruta del resto de opciones. En la Tabla 2-3 se listan estas opciones, y algunas otras bastante comunes, a modo de referencia. From 77c738375f4fd7a2aea1240e6335ab144abaefba Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Thu, 15 May 2014 21:47:41 +0200 Subject: [PATCH 026/291] provide timezone-examples from different Cities * Auckland/New Zealand, Berlin, etc. -- not just Paris * minor corrections --- en/02-git-basics/01-chapter2.markdown | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index dc3d4ccc2..dd13cc7fc 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -660,12 +660,12 @@ The lines must be formatted as follows ### Limiting Log Output according to Date/Time ### -To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone, use +To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone (as set on your computer), use $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ --pretty=fuller -However this command will not yield identical results, when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments, so that all your collegues around the world would get the same results as you. First determine the absolute-times using e.g. the `date` program: +However this command will not yield identical results when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments. First determine the absolute-times using e.g. the `date` program: $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 00:00:00" -Is 2014-04-29T00:00:00+0200 @@ -695,7 +695,7 @@ For example: for `2014-04-29T23:59:59+0200` the corresponding UTC is `2014-04-29 21:59:59`. -To obtain commits made at a specific instant in time, we can use e.g. +To obtain commits made at a specific instant in time (e.g. `2013-04-29T17:07:22+0200`), we can use $ git log --after="2013-04-29T17:07:22+0200" \ --before="2013-04-29T17:07:22+0200" --pretty=fuller @@ -724,9 +724,9 @@ We can change the way that these are displayed in the resulting log list. `--dat $ git log --after="2013-04-29T17:07:22+0200" \ --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local -To show all times according to e.g. French timezone, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Europe/Paris"`): +To show all times according to the timezone of New Zealand, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Pacific/Auckland"`): - $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" \ + $ TZ="NZST-12NZDT,M9.5.0,M4.1.0/3" \ git log --after="2013-04-29T17:07:22+0200" \ --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local @@ -736,17 +736,17 @@ When using `git log` without specifying time, $ git log --after=2008-06-01 --before=2008-07-01 -the time defaults to the time at which the command is run. For example when the above command is executed at 09:00, then the result is usually equivalent to doing: +the time defaults to the time at which the command is run on your computer. For example when the above command is executed at 09:00, then the result is usually equivalent to doing: $ git log --after="2008-06-01 09:00:00" \ --before="2008-07-01 09:00:00" -More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered. The time that will be considered, is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Paris at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing: +More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered: The time that will be considered is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Berlin at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing: $ git log --after="2008-06-01T09:00:00+0100" \ --before="2008-07-01T09:00:00+0100" -even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Paris: +even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Berlin (because of Daylight Saving Time): `2008-06-01T10:00:00+0200`. From a30a7dd6b1b18dd8446a331619ee303158db068b Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Thu, 15 May 2014 22:06:53 +0200 Subject: [PATCH 027/291] minor: remove repetition ("committed") --- en/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index dd13cc7fc..6af8e59e8 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -750,7 +750,7 @@ even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Berlin `2008-06-01T10:00:00+0200`. -As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and committed with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: +As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: $ git log --pretty="%h - %s" --author=gitster \ --after="2008-10-01T00:00:00-0400" \ From de1d8de938210c39f875b30f1ca5f0d05b2f234f Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Thu, 15 May 2014 22:22:07 +0200 Subject: [PATCH 028/291] shorten explanation for `git log --after=2008-06-01` (date-only) --- en/02-git-basics/01-chapter2.markdown | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 6af8e59e8..4e68be6ed 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -736,19 +736,10 @@ When using `git log` without specifying time, $ git log --after=2008-06-01 --before=2008-07-01 -the time defaults to the time at which the command is run on your computer. For example when the above command is executed at 09:00, then the result is usually equivalent to doing: +the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC; effectively disregarding Daylight Saving Time). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing: - $ git log --after="2008-06-01 09:00:00" \ - --before="2008-07-01 09:00:00" - -More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered: The time that will be considered is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Berlin at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing: - - $ git log --after="2008-06-01T09:00:00+0100" \ - --before="2008-07-01T09:00:00+0100" - -even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Berlin (because of Daylight Saving Time): - - `2008-06-01T10:00:00+0200`. + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: From 3e67b84c15c63f02c13c94e55b1c1aebc9091972 Mon Sep 17 00:00:00 2001 From: nicesw123 Date: Thu, 15 May 2014 22:26:28 +0200 Subject: [PATCH 029/291] `git log --after=2008-06-01` keeps timezone offset from UTC equiv. to the time when it is run on your computer. Saying this is "disregarding Daylight Saving Time" is confusing, because it could lead one to mistakenly assume that git then only considers summer-time, or only winter-time. But this is not the case. Git just keeps the offset from UTC identical. --- en/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 4e68be6ed..465f3cc9a 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -736,7 +736,7 @@ When using `git log` without specifying time, $ git log --after=2008-06-01 --before=2008-07-01 -the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC; effectively disregarding Daylight Saving Time). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing: +the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing: $ git log --after="2008-06-01T09:00:00+0300" \ --before="2008-07-01T09:00:00+0300" From f5170bb2e34131c7088236066d13d1f657dfa381 Mon Sep 17 00:00:00 2001 From: Alex Moundalexis Date: Fri, 16 May 2014 12:41:42 -0400 Subject: [PATCH 030/291] Update command line output in Chapter 2 The command line output in the examples is slightly inconsistent with the latest version; git doesn't strip content from the commit message. --- en/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 8090ba342..74784dc65 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -324,7 +324,7 @@ You can see that the default commit message contains the latest output of the `g Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: $ git commit -m "Story 182: Fix benchmarks for speed" - [master 463dc4f] Fix benchmarks for speed + [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README From 4d32ade1d53c023ca645f3bf2ad42ea3bc2e5f4c Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Sun, 18 May 2014 01:51:29 +0200 Subject: [PATCH 031/291] [es] Update chapter 3: fixed markdown mistake Fixed wrong character to indicate markdown span of code: There was made with apostrophes instead of backtick quotes Signed-off-by: Carlos Arturo Guerra Parra --- es/03-git-branching/01-chapter3.markdown | 166 +++++++++++------------ 1 file changed, 83 insertions(+), 83 deletions(-) diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown index bb63d84a4..9a732fa23 100644 --- a/es/03-git-branching/01-chapter3.markdown +++ b/es/03-git-branching/01-chapter3.markdown @@ -15,7 +15,7 @@ Para ilustrar esto, vamos a suponer, por ejemplo, que tienes una carpeta con tre $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' -Cuando creas una confirmación con el comando 'git commit', Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y guarda en el repositorio Git una copia de cada uno de los archivos contenidos en ella/s. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al nodo correspondiente del árbol de proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario. +Cuando creas una confirmación con el comando `git commit`, Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y guarda en el repositorio Git una copia de cada uno de los archivos contenidos en ella/s. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al nodo correspondiente del árbol de proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario. En este momento, el repositorio de Git contendrá cinco objetos: un "blob" para cada uno de los tres archivos, un árbol con la lista de contenidos de la carpeta (más sus respectivas relaciones con los "blobs"), y una confirmación de cambios (commit) apuntando a la raiz de ese árbol y conteniendo el resto de metadatos pertinentes. Conceptualmente, el contenido del repositorio Git será algo parecido a la Figura 3-1 @@ -27,12 +27,12 @@ Si haces más cambios y vuelves a confirmar, la siguiente confirmación guardar Insert 18333fig0302.png Figura 3-2. Datos en el repositorio tras una serie de confirmaciones. -Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones. La rama por defecto de Git es la rama 'master'. Con la primera confirmación de cambios que realicemos, se creará esta rama principal 'master' apuntando a dicha confirmación. En cada confirmación de cambios que realicemos, la rama irá avanzando automáticamente. Y la rama 'master' apuntará siempre a la última confirmación realizada. +Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones. La rama por defecto de Git es la rama `master`. Con la primera confirmación de cambios que realicemos, se creará esta rama principal `master` apuntando a dicha confirmación. En cada confirmación de cambios que realicemos, la rama irá avanzando automáticamente. Y la rama `master` apuntará siempre a la última confirmación realizada. Insert 18333fig0303.png Figura 3-3. Apuntadores en el registro de confirmaciones de una rama. -¿Qué sucede cuando creas una nueva rama? Bueno....., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando 'git branch': +¿Qué sucede cuando creas una nueva rama? Bueno....., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando `git branch`: $ git branch testing @@ -41,16 +41,16 @@ Esto creará un nuevo apuntador apuntando a la misma confirmación donde estés Insert 18333fig0304.png Figura 3-4. Apuntadores de varias ramas en el registro de confirmaciones de cambio. -Y, ¿cómo sabe Git en qué rama estás en este momento? Pues...., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama 'master'. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama. +Y, ¿cómo sabe Git en qué rama estás en este momento? Pues...., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama `master`. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama. Insert 18333fig0305.png Figura 3-5. Apuntador HEAD a la rama donde estás actualmente. -Para saltar de una rama a otra, tienes que utilizar el comando 'git checkout'. Hagamos una prueba, saltando a la rama 'testing' recién creada: +Para saltar de una rama a otra, tienes que utilizar el comando `git checkout`. Hagamos una prueba, saltando a la rama `testing` recién creada: $ git checkout testing -Esto mueve el apuntador HEAD a la rama 'testing' (ver Figura 3-6). +Esto mueve el apuntador HEAD a la rama `testing` (ver Figura 3-6). Insert 18333fig0306.png Figura 3-6. Apuntador HEAD apuntando a otra rama cuando saltamos de rama. @@ -65,7 +65,7 @@ La Figura 3-7 ilustra el resultado. Insert 18333fig0307.png Figura 3-7. La rama apuntada por HEAD avanza con cada confirmación de cambios. -Observamos algo interesante: la rama 'testing' avanza, mientras que la rama 'master' permanece en la confirmación donde estaba cuando lanzaste el comando 'git checkout' para saltar. Volvamos ahora a la rama 'master': +Observamos algo interesante: la rama `testing` avanza, mientras que la rama `master` permanece en la confirmación donde estaba cuando lanzaste el comando `git checkout` para saltar. Volvamos ahora a la rama `master`: $ git checkout master @@ -74,14 +74,14 @@ La Figura 3-8 muestra el resultado. Insert 18333fig0308.png Figura 3-8. HEAD apunta a otra rama cuando hacemos un checkout. -Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama 'master', y revierte los archivos de tu directorio de trabajo; dejandolos tal y como estaban en la última instantánea confirmada en dicha rama 'master'. Esto supone que los cambios que hagas desde este momento en adelante divergerán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habias hecho temporalmente en la rama 'testing'; de tal forma que puedas avanzar en otra dirección diferente. +Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejandolos tal y como estaban en la última instantánea confirmada en dicha rama `master`. Esto supone que los cambios que hagas desde este momento en adelante divergerán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habias hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente. Haz algunos cambios más y confirmalos: $ vim test.rb $ git commit -a -m 'made other changes' -Ahora el registro de tu proyecto diverge (ver Figura 3-9). Has creado una rama y saltado a ella, has trabajado sobre ella; has vuelto a la rama original, y has trabajado también sobre ella. Los cambios realizados en ambas sesiones de trabajo están aislados en ramas independientes: puedes saltar libremente de una a otra según estimes oportuno. Y todo ello simplemente con dos comandos: 'git branch' y 'git checkout'. +Ahora el registro de tu proyecto diverge (ver Figura 3-9). Has creado una rama y saltado a ella, has trabajado sobre ella; has vuelto a la rama original, y has trabajado también sobre ella. Los cambios realizados en ambas sesiones de trabajo están aislados en ramas independientes: puedes saltar libremente de una a otra según estimes oportuno. Y todo ello simplemente con dos comandos: `git branch` y `git checkout`. Insert 18333fig0309.png Figura 3-9. Los registros de las ramas divergen. @@ -114,7 +114,7 @@ Imagina que estas trabajando en un proyecto, y tienes un par de confirmaciones ( Insert 18333fig0310.png Figura 3-10. Un registro de confirmaciones simple y corto. -Decides trabajar el problema #53, del sistema que tu compañia utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando 'git checkout' con la opción '-b': +Decides trabajar el problema #53, del sistema que tu compañia utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`: $ git checkout -b iss53 Switched to a new branch "iss53" @@ -129,24 +129,24 @@ Figura 3-11 muestra el resultado. Insert 18333fig0311.png Figura 3-11. Creación de un apuntador a la nueva rama. -Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Con ello avanzas la rama 'iss53', que es la que tienes activada (checked out) en este momento (es decir, a la que apunta HEAD; ver Figura 3-12): +Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Con ello avanzas la rama `iss53`, que es la que tienes activada (checked out) en este momento (es decir, a la que apunta HEAD; ver Figura 3-12): $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' Insert 18333fig0312.png -Figura 3-12. La rama 'iss53' ha avanzado con tu trabajo. +Figura 3-12. La rama `iss53` ha avanzado con tu trabajo. -Entonces, recibes una llamada avisandote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habias realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama 'master' y continuar trabajando a partir de ella. +Entonces, recibes una llamada avisandote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habias realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de ella. -Pero, antes de poder hacer eso, hemos de tener en cuenta que teniendo cambios aún no confirmados en la carpeta de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos. Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas. Y, para ello, tenemos algunos procedimientos (stash y commit ammend), que vamos a ver más adelante. Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama 'master' sin problemas: +Pero, antes de poder hacer eso, hemos de tener en cuenta que teniendo cambios aún no confirmados en la carpeta de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos. Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas. Y, para ello, tenemos algunos procedimientos (stash y commit ammend), que vamos a ver más adelante. Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama `master` sin problemas: $ git checkout master Switched to branch "master" Tras esto, tendrás la carpeta de trabajo exactamente igual a como estaba antes de comenzar a trabajar sobre el problema #53. Y podrás concentrarte en el nuevo problema urgente. Es importante recordar que Git revierte la carpeta de trabajo exactamente al estado en que estaba en la confirmación (commit) apuntada por la rama que activamos (checkout) en cada momento. Git añade, quita y modifica archivos automáticamente. Para asegurarte que tu copia de trabajo es exactamente tal y como era la rama en la última confirmación de cambios realizada sobre ella. -Volviendo al problema urgente. Vamos a crear una nueva rama 'hotfix', sobre la que trabajar hasta resolverlo (ver Figura 3-13): +Volviendo al problema urgente. Vamos a crear una nueva rama `hotfix`, sobre la que trabajar hasta resolverlo (ver Figura 3-13): $ git checkout -b 'hotfix' Switched to a new branch "hotfix" @@ -156,9 +156,9 @@ Volviendo al problema urgente. Vamos a crear una nueva rama 'hotfix', sobre la q 1 files changed, 0 insertions(+), 1 deletions(-) Insert 18333fig0313.png -Figura 3-13. rama 'hotfix' basada en la rama 'master' original. +Figura 3-13. rama `hotfix` basada en la rama `master` original. -Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, e incorporar los cambios a la rama 'master' para ponerlos en producción. Esto se hace con el comando 'git merge': +Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, e incorporar los cambios a la rama `master` para ponerlos en producción. Esto se hace con el comando `git merge`: $ git checkout master $ git merge hotfix @@ -169,12 +169,12 @@ Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, Merece destacar la frase "Avance rápido" ("Fast forward") que aparece en la respuesta al comando. Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente "aguas arriba" respecto de la confirmación actual. Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el registro de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningûn otro trabajo divergente a fusionar. Esto es lo que se denomina "avance rápido" ("fast forward"). -Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama 'master'. Y puedes desplegarlos (ver Figura 3-14) +Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama `master`. Y puedes desplegarlos (ver Figura 3-14) Insert 18333fig0314.png -Figura 3-14. Tras la fusión (merge), la rama 'master' apunta al mismo sitio que la rama 'hotfix'. +Figura 3-14. Tras la fusión (merge), la rama `master` apunta al mismo sitio que la rama `hotfix`. -Tras haber resuelto el problema urgente que te habia interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama 'hotfix'. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama 'master'. Esto lo puedes hacer con la opción '-d' del comando 'git branch': +Tras haber resuelto el problema urgente que te habia interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`: $ git branch -d hotfix Deleted branch hotfix (3a0874c). @@ -189,13 +189,13 @@ Y, con esto, ya estas dispuesto para regresar al trabajo sobre el problema #53 ( 1 files changed, 1 insertions(+), 0 deletions(-) Insert 18333fig0315.png -Figura 3-15. La rama 'iss53' puede avanzar independientemente. +Figura 3-15. La rama `iss53` puede avanzar independientemente. -Cabe indicar que todo el trabajo realizado en la rama 'hotfix' no está en los archivos de la rama 'iss53'. Si fuera necesario agregarlos, puedes fusionar (merge) la rama 'master' sobre la rama 'iss53' utilizando el comando 'git merge master'. O puedes esperar hasta que decidas llevar (pull) la rama 'iss53' a la rama 'master'. +Cabe indicar que todo el trabajo realizado en la rama `hotfix` no está en los archivos de la rama `iss53`. Si fuera necesario agregarlos, puedes fusionar (merge) la rama `master` sobre la rama `iss53` utilizando el comando `git merge master`. O puedes esperar hasta que decidas llevar (pull) la rama `iss53` a la rama `master`. ### Procedimientos básicos de fusión ### -Supongamos que tu trabajo con el problema #53 está ya completo y listo para fusionarlo (merge) con la rama 'master'. Para ello, de forma similar a como antes has hecho con la rama 'hotfix', vas a fusionar la rama 'iss53'. Simplemente, activando (checkout) la rama donde deseas fusionar y lanzando el comando 'git merge': +Supongamos que tu trabajo con el problema #53 está ya completo y listo para fusionarlo (merge) con la rama `master`. Para ello, de forma similar a como antes has hecho con la rama `hotfix`, vas a fusionar la rama `iss53`. Simplemente, activando (checkout) la rama donde deseas fusionar y lanzando el comando `git merge`: $ git checkout master $ git merge iss53 @@ -203,7 +203,7 @@ Supongamos que tu trabajo con el problema #53 está ya completo y listo para fus README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -Es algo diferente de la fusión realizada anteriormente con 'hotfix'. En este caso, el registro de desarrollo habia divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso. +Es algo diferente de la fusión realizada anteriormente con `hotfix`. En este caso, el registro de desarrollo habia divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso. Insert 18333fig0316.png Figura 3-16. Git identifica automáticamente el mejor ancestro común para realizar la fusión de las ramas. @@ -215,20 +215,20 @@ Merece la pena destacar el hecho de que es el propio Git quien determina automá Insert 18333fig0317.png Figura 3-17. Git crea automáticamente una nueva confirmación para la fusión. -Ahora que todo tu trabajo está ya fusionado con la rama principal, ya no tienes necesidad de la rama 'iss53'. Por lo que puedes borrarla. Y cerrar manualmente el problema en el sistema de seguimiento de problemas de tu empresa. +Ahora que todo tu trabajo está ya fusionado con la rama principal, ya no tienes necesidad de la rama `iss53`. Por lo que puedes borrarla. Y cerrar manualmente el problema en el sistema de seguimiento de problemas de tu empresa. $ git branch -d iss53 ### Principales conflictos que pueden surgir en las fusiones ### -En algunas ocasiones, los procesos de fusión no suelen ser fluidos. Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente. Por ejemplo, si en tu trabajo del problema #53 has modificado una misma porción que también ha sido modificada en el problema 'hotfix'. Puedes obtener un conflicto de fusión tal que: +En algunas ocasiones, los procesos de fusión no suelen ser fluidos. Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente. Por ejemplo, si en tu trabajo del problema #53 has modificado una misma porción que también ha sido modificada en el problema `hotfix`. Puedes obtener un conflicto de fusión tal que: $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. -Git no crea automáticamente una nueva fusión confirmada (merge commit). Sino que hace una pausa en el proceso, esperando a que tu resuelvas el conflicto. Para ver qué archivos permanecen sin fusionar en un determinado momento conflictivo de una fusión, puedes usar el comando 'git status': +Git no crea automáticamente una nueva fusión confirmada (merge commit). Sino que hace una pausa en el proceso, esperando a que tu resuelvas el conflicto. Para ver qué archivos permanecen sin fusionar en un determinado momento conflictivo de una fusión, puedes usar el comando `git status`: [master*]$ git status index.html: needs merge @@ -250,14 +250,14 @@ Todo aquello que sea conflictivo y no se haya podido resolver, se marca como "si >>>>>>> iss53:index.html -Donde nos dice que la versión en HEAD (la rama 'master', la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de '======='). Y que la versión en 'iss53' contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejandolo tal que: +Donde nos dice que la versión en HEAD (la rama `master`, la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de `=======`). Y que la versión en `iss53` contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejandolo tal que: -Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos 'git add' para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos. -Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando 'git mergetool'. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella. +Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos `git add` para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos. +Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando `git mergetool`. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella. $ git mergetool merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff @@ -268,11 +268,11 @@ Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfic {remote}: modified Hit return to start merge resolution tool (opendiff): -Si deseas usar una herramienta distinta de la escogida por defecto (en mi caso 'opendiff', porque estoy lanzando el comando en un Mac), puedes escogerla entre la lista de herramientas soportadas mostradas al principio ("merge tool candidates"). Tecleando el nombre de dicha herramienta. En el capítulo 7 se verá cómo cambiar este valor por defecto de tu entorno de trabajo. +Si deseas usar una herramienta distinta de la escogida por defecto (en mi caso `opendiff`, porque estoy lanzando el comando en un Mac), puedes escogerla entre la lista de herramientas soportadas mostradas al principio ("merge tool candidates"). Tecleando el nombre de dicha herramienta. En el capítulo 7 se verá cómo cambiar este valor por defecto de tu entorno de trabajo. Tras salir de la herramienta de fusionado, Git preguntará a ver si hemos resuelto todos los conflictos y la fusión ha sido satisfactoria. Si le indicas que así ha sido, Git marca como preparado (staged) el archivo que acabamos de modificar. -En cualquier momento, puedes lanzar el comando 'git status' para ver si ya has resuelto todos los conflictos: +En cualquier momento, puedes lanzar el comando `git status` para ver si ya has resuelto todos los conflictos: $ git status # On branch master @@ -282,7 +282,7 @@ En cualquier momento, puedes lanzar el comando 'git status' para ver si ya has r # modified: index.html # -Si todo ha ido correctamente, y ves que todos los archivos conflictivos están marcados como preparados, puedes lanzar el comando 'git commit' para terminar de confirmar la fusión. El mensaje de confirmación por defecto será algo parecido a: +Si todo ha ido correctamente, y ves que todos los archivos conflictivos están marcados como preparados, puedes lanzar el comando `git commit` para terminar de confirmar la fusión. El mensaje de confirmación por defecto será algo parecido a: Merge branch 'iss53' @@ -301,40 +301,40 @@ Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fu Ahora que ya has creado, fusionado y borrado algunas ramas, vamos a dar un vistazo a algunas herramientas de gestión muy útiles cuando comienzas a utilizar ramas profusamente. -El comando 'git branch' tiene más funciones que las de crear y borrar ramas. Si lo lanzas sin argumentos, obtienes una lista de las ramas presentes en tu proyecto: +El comando `git branch` tiene más funciones que las de crear y borrar ramas. Si lo lanzas sin argumentos, obtienes una lista de las ramas presentes en tu proyecto: $ git branch iss53 * master testing -Fijate en el carácter `*` delante de la rama 'master': nos indica la rama activa en este momento. Si hacemos una confirmación de cambios (commit), esa será la rama que avance. Para ver la última confirmación de cambios en cada rama, puedes usar el comando 'git branch -v': +Fijate en el carácter `*` delante de la rama `master`: nos indica la rama activa en este momento. Si hacemos una confirmación de cambios (commit), esa será la rama que avance. Para ver la última confirmación de cambios en cada rama, puedes usar el comando `git branch -v`: $ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes -Otra opción útil para averiguar el estado de las ramas, es filtrarlas y mostrar solo aquellas que han sido fusionadas (o que no lo han sido) con la rama actualmente activa. Para ello, Git dispone, desde la versión 1.5.6, las opciones '--merged' y '--no-merged'. Si deseas ver las ramas que han sido fusionadas en la rama activa, puedes lanzar el comando 'git branch --merged': +Otra opción útil para averiguar el estado de las ramas, es filtrarlas y mostrar solo aquellas que han sido fusionadas (o que no lo han sido) con la rama actualmente activa. Para ello, Git dispone, desde la versión 1.5.6, las opciones `--merged` y `--no-merged`. Si deseas ver las ramas que han sido fusionadas en la rama activa, puedes lanzar el comando `git branch --merged`: $ git branch --merged iss53 * master -Aparece la rama 'iss53' porque ya ha sido fusionada. Y no lleva por delante el caracter `*` porque todo su contenido ya ha sido incorporado a otras ramas. Podemos borrarla tranquilamente con 'git branch -d', sin miedo a perder nada. +Aparece la rama `iss53` porque ya ha sido fusionada. Y no lleva por delante el caracter `*` porque todo su contenido ya ha sido incorporado a otras ramas. Podemos borrarla tranquilamente con `git branch -d`, sin miedo a perder nada. -Para mostrar todas las ramas que contienen trabajos sin fusionar aún, puedes utilizar el comando 'git branch --no-merged': +Para mostrar todas las ramas que contienen trabajos sin fusionar aún, puedes utilizar el comando `git branch --no-merged`: $ git branch --no-merged testing -Esto nos muestra la otra rama en el proyecto. Debido a que contiene trabajos sin fusionar aún, al intentarla borrar con 'git branch -d', el comando nos dará un error: +Esto nos muestra la otra rama en el proyecto. Debido a que contiene trabajos sin fusionar aún, al intentarla borrar con `git branch -d`, el comando nos dará un error: $ git branch -d testing error: The branch 'testing' is not an ancestor of your current HEAD. If you are sure you want to delete it, run 'git branch -D testing'. -Si realmente deseas borrar la rama, y perder el trabajo contenido en ella, puedes forzar el borrado con la opción '-D'; tal y como lo indica el mensaje de ayuda. +Si realmente deseas borrar la rama, y perder el trabajo contenido en ella, puedes forzar el borrado con la opción `-D`; tal y como lo indica el mensaje de ayuda. ## Flujos de trabajo ramificados ## @@ -344,7 +344,7 @@ Ahora que ya has visto los procedimientos básicos de ramificación y fusión, Por la sencillez de la fusión a tres bandas de Git, el fusionar de una rama a otra multitud de veces a lo largo del tiempo es facil de hacer. Esto te posibilita tener varias ramas siempre abiertas, e irlas usando en diferentes etapas del ciclo de desarrollo; realizando frecuentes fusiones entre ellas. -Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza, manteniendo en la rama 'master' únicamente el código totalmente estable (el código que ha sido o que va a ser liberado). Teniendo otras ramas paralelas denominadas 'desarrollo' o 'siguiente', en las que trabajan y realizan pruebas. Estas ramas paralelas no suele estar siempre en un estado estable; pero cada vez que sí lo están, pueden ser fusionadas con la rama 'master'. También es habitual el incorporarle (pull) ramas puntuales (ramas temporales, como la rama 'iss53' del anterior ejemplo) cuando las completamos y estamos seguros de que no van a introducir errores. +Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza, manteniendo en la rama `master` únicamente el código totalmente estable (el código que ha sido o que va a ser liberado). Teniendo otras ramas paralelas denominadas `desarrollo` o `siguiente`, en las que trabajan y realizan pruebas. Estas ramas paralelas no suele estar siempre en un estado estable; pero cada vez que sí lo están, pueden ser fusionadas con la rama `master`. También es habitual el incorporarle (pull) ramas puntuales (ramas temporales, como la rama `iss53` del anterior ejemplo) cuando las completamos y estamos seguros de que no van a introducir errores. En realidad, en todo momento estamos hablando simplemente de apuntadores moviendose por la línea temporal de confirmaciones de cambio (commit history). Las ramas estables apuntan hacia posiciones más antiguas en el registro de confirmaciones. Mientras que las ramas avanzadas, las que van abriendo camino, apuntan hacia posiciones más recientes. @@ -356,24 +356,24 @@ Podría ser más sencillo pensar en las ramas como si fueran silos de almacenami Insert 18333fig0319.png Figura 3-19. Puede ayudar pensar en las ramas como silos de almacenamiento. -Este sistema de trabajo se puede ampliar para diversos grados de estabilidad. Algunos proyectos muy grandes suelen tener una rama denominada 'propuestas' o 'pu' (proposed updates). Donde suele estar todo aquello integrado desde otras ramas, pero que aún no está listo para ser incorporado a las ramas 'siguiente' o 'master'. La idea es mantener siempre diversas ramas en diversos grados de estabilidad; pero cuando alguna alcanza un estado más estable, la fusionamos con la rama inmediatamente superior a ella. +Este sistema de trabajo se puede ampliar para diversos grados de estabilidad. Algunos proyectos muy grandes suelen tener una rama denominada `propuestas` o `pu` (proposed updates). Donde suele estar todo aquello integrado desde otras ramas, pero que aún no está listo para ser incorporado a las ramas `siguiente` o `master`. La idea es mantener siempre diversas ramas en diversos grados de estabilidad; pero cuando alguna alcanza un estado más estable, la fusionamos con la rama inmediatamente superior a ella. Aunque no es obligatorio el trabajar con ramas de larga duración, realmente es práctico y útil. Sobre todo en proyectos largos o complejos. ### Ramas puntuales ### Las ramas puntuales, en cambio, son útiles en proyectos de cualquier tamaño. Una rama puntual es aquella de corta duración que abres para un tema o para una funcionalidad muy concretos. Es algo que nunca habrías hecho en otro sistema VCS, debido a los altos costos de crear y fusionar ramas que se suelen dar en esos sistemas. Pero en Git, por el contrario, es muy habitual el crear, trabajar con, fusionar y borrar ramas varias veces al día. -Tal y como has visto con las ramas 'iss53' y 'hotfix' que has creado en la sección anterior. Has hecho unas pocas confirmaciones de cambio en ellas, y luego las has borrado tras fusionarlas con la rama principal. Esta técnica te posibilita realizar rápidos y completos saltos de contexto. Y, debido a que el trabajo está claramente separado en silos, con todos los cambios de cada tema en su propia rama, te será mucho más sencillo revisar el código y seguir su evolución. Puedes mantener los cambios ahí durante minutos, dias o meses; y fusionarlos cuando realmente estén listos. En lugar de verte obligado a fusionarlos en el orden en que fueron creados y comenzaste a trabajar en ellos. +Tal y como has visto con las ramas `iss53` y `hotfix` que has creado en la sección anterior. Has hecho unas pocas confirmaciones de cambio en ellas, y luego las has borrado tras fusionarlas con la rama principal. Esta técnica te posibilita realizar rápidos y completos saltos de contexto. Y, debido a que el trabajo está claramente separado en silos, con todos los cambios de cada tema en su propia rama, te será mucho más sencillo revisar el código y seguir su evolución. Puedes mantener los cambios ahí durante minutos, dias o meses; y fusionarlos cuando realmente estén listos. En lugar de verte obligado a fusionarlos en el orden en que fueron creados y comenzaste a trabajar en ellos. -Por ejemplo, puedes realizar cierto trabajo en la rama 'master', ramificar para un problema concreto (rama 'iss91'), trabajar en él un rato, ramificar a una segunda rama para probar otra manera de resolverlo (rama 'iss92v2'), volver a la rama 'master' y trabajar un poco más, y, por último, ramificar temporalmente para probar algo de lo que no estás seguro (rama 'dumbidea'). El registro de confirmaciones (commit history) será algo parecido a la Figura 3-20. +Por ejemplo, puedes realizar cierto trabajo en la rama `master`, ramificar para un problema concreto (rama `iss91`), trabajar en él un rato, ramificar a una segunda rama para probar otra manera de resolverlo (rama `iss92v2`), volver a la rama `master` y trabajar un poco más, y, por último, ramificar temporalmente para probar algo de lo que no estás seguro (rama `dumbidea`). El registro de confirmaciones (commit history) será algo parecido a la Figura 3-20. Insert 18333fig0320.png Figura 3-20. El registro de confirmaciones con múltiples ramas puntuales. -En este momento, supongamos que te decides por la segunda solución al problema (rama 'iss92v2'); y que, tras mostrar la rama 'dumbidea' a tus compañeros, resulta que les parece una idea genial. Puedes descartar la rama 'iss91' (perdiendo las confirmaciones C5 y C6), y fusionar las otras dos. El registro será algo parecido a la Figura 3-21. +En este momento, supongamos que te decides por la segunda solución al problema (rama `iss92v2`); y que, tras mostrar la rama `dumbidea` a tus compañeros, resulta que les parece una idea genial. Puedes descartar la rama `iss91` (perdiendo las confirmaciones C5 y C6), y fusionar las otras dos. El registro será algo parecido a la Figura 3-21. Insert 18333fig0321.png -Figura 3-21. El registro tras fusionar 'dumbidea' e 'iss91v2'. +Figura 3-21. El registro tras fusionar `dumbidea` e `iss91v2`. Es importante recordar que, mientras estás haciendo todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositório Git. No hay nigún tipo de tráfico con ningún servidor. @@ -381,38 +381,38 @@ Es importante recordar que, mientras estás haciendo todo esto, todas las ramas Las ramas remotas son referencias al estado de ramas en tus repositorios remotos. Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos. -Suelen referenciarse como '(remoto)/(rama)'. Por ejemplo, si quieres saber cómo estaba la rama 'master' en el remoto 'origin'. Puedes revisar la rama 'origin/master'. O si estás trabajando en un problema con un compañero y este envia (push) una rama 'iss53', tu tendrás tu propia rama de trabajo local 'iss53'; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama 'origin/iss53'. +Suelen referenciarse como `(remoto)/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`. Puedes revisar la rama `origin/master`. O si estás trabajando en un problema con un compañero y este envia (push) una rama `iss53`, tu tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin/iss53`. -Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un sevidor Git en tu red, en 'git.ourcompany.com'. Si haces un clón desde ahí, Git automáticamente lo denominará 'origin', traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama 'master', denominará la copia local 'origin/master'; y será inamovible para tí. Git te proporcionará también tu propia rama 'master', apuntando al mismo lugar que la rama 'master' de 'origin'; siendo en esta última donde podrás trabajar. +Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un sevidor Git en tu red, en `git.ourcompany.com`. Si haces un clón desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master`, denominará la copia local `origin/master`; y será inamovible para tí. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; siendo en esta última donde podrás trabajar. Insert 18333fig0322.png -Figura 3-22. Un clón Git te proporciona tu propia rama 'master' y otra rama 'origin/master' apuntando a la rama 'master' original. +Figura 3-22. Un clón Git te proporciona tu propia rama `master` y otra rama `origin/master` apuntando a la rama `master` original. -Si haces algún trabajo en tu rama 'master' local, y al mismo tiempo, alguna otra persona lleva (push) su trabajo al servidor 'git.ourcompany.com', actualizando la rama 'master' de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama 'origin/master' no se moverá (ver Figura 3/23). +Si haces algún trabajo en tu rama `master` local, y al mismo tiempo, alguna otra persona lleva (push) su trabajo al servidor `git.ourcompany.com`, actualizando la rama `master` de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama `origin/master` no se moverá (ver Figura 3/23). Insert 18333fig0323.png Figura 3-23. Trabajando localmente y que otra persona esté llevando (push) algo al servidor remoto, hace que cada registro avance de forma distinta. -Para sincronizarte, puedes utilizar el comando 'git fetch origin'. Este comando localiza en qué servidor está el origen (en este caso 'git.ourcompany.com'), recupera cualquier dato presente allí que tu no tengas, y actualiza tu base de datos local, moviendo tu rama 'origin/master' para que apunte a esta nueva y más reciente posición (ver Figura 3-24). +Para sincronizarte, puedes utilizar el comando `git fetch origin`. Este comando localiza en qué servidor está el origen (en este caso `git.ourcompany.com`), recupera cualquier dato presente allí que tu no tengas, y actualiza tu base de datos local, moviendo tu rama `origin/master` para que apunte a esta nueva y más reciente posición (ver Figura 3-24). Insert 18333fig0324.png -Figura 3-24. El comando 'git fetch' actualiza tus referencias remotas. +Figura 3-24. El comando `git fetch` actualiza tus referencias remotas. -Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos. Supongamos que tienes otro servidor Git; utilizado solamente para desarrollo, por uno de tus equipos sprint. Un servidor en 'git.team1.ourcompany.com'. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando 'git remote add', tal y como vimos en el capítulo 2. Puedes denominar 'teamone' a este remoto, poniendo este nombre abreviado para la URL (ver Figura 3-25) +Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos. Supongamos que tienes otro servidor Git; utilizado solamente para desarrollo, por uno de tus equipos sprint. Un servidor en `git.team1.ourcompany.com`. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando `git remote add`, tal y como vimos en el capítulo 2. Puedes denominar `teamone` a este remoto, poniendo este nombre abreviado para la URL (ver Figura 3-25) Insert 18333fig0325.png Figura 3-25. Añadiendo otro servidor como remoto. -Ahora, puedes usar el comando 'git fetch teamone' para recuperar todo el contenido del servidor que tu no tenias. Debido a que dicho servidor es un subconjunto de de los datos del servidor 'origin' que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada 'teamone/master' para apuntar a la confirmación (commit) que 'teamone' tiene en su rama 'master'. +Ahora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del servidor que tu no tenias. Debido a que dicho servidor es un subconjunto de de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada `teamone/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`. Insert 18333fig0326.png -Figura 3-26. Obtienes una referencia local a la posición en la rama 'master' de 'teamone'. +Figura 3-26. Obtienes una referencia local a la posición en la rama `master` de `teamone`. ### Publicando ### Cuando quieres compartir una rama con el resto del mundo, has de llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes. Sino que tienes que llevar (push) expresamente, cada vez, al remoto las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir. Llevando a un remoto tan solo aquellas partes que deseas aportar a los demás. -Si tienes una rama llamada 'serverfix', con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando 'git push (remoto) (rama)': +Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando `git push (remoto) (rama)`: $ git push origin serverfix Counting objects: 20, done. @@ -422,9 +422,9 @@ Si tienes una rama llamada 'serverfix', con la que vas a trabajar en colaboraci To git@github.com:schacon/simplegit.git * [new branch] serverfix -> serverfix -Esto es un poco como un atajo. Git expande automáticamente el nombre de rama 'serverfix' a 'refs/heads/serverfix:refs/heads/serverfix', que significa: "coge mi rama local 'serverfix' y actualiza con ella la rama 'serverfix' del remoto". Volveremos más tarde sobre el tema de 'refs/heads/', viendolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer 'git push origin serverfix:serverfix', que hace lo mismo; es decir: "coge mi 'serverfix' y hazlo el 'serverfix' remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame 'serverfix' en el remoto, puedes lanzar, por ejemplo, 'git push origin serverfix:awesomebranch'; para llevar tu rama 'serverfix' local a la rama 'awesomebranch' en el proyecto remoto. +Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viendolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto. -La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de 'serverfix' en el servidor esté bajo la rama remota 'origin/serverfix': +La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de `serverfix` en el servidor esté bajo la rama remota `origin/serverfix`: $ git fetch origin remote: Counting objects: 20, done. @@ -434,21 +434,21 @@ La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán un From git@github.com:schacon/simplegit * [new branch] serverfix -> origin/serverfix -Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia editable local de las mismas. En otras palabras, en este caso, no tienes una nueva rama 'serverfix'. Sino que únicamente tienes un puntero no editable a 'origin/serverfix'. +Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia editable local de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin/serverfix`. -Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando 'git merge origin/serverfix'. Y si quieres tener tu propia rama 'serverfix', donde puedas trabajar, puedes crearla directamente basandote en rama remota: +Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix`, donde puedas trabajar, puedes crearla directamente basandote en rama remota: $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "serverfix"Switched to a new branch "serverfix" -Esto sí te da una rama local donde puedes trabajar, comenzando donde 'origin/serverfix' estaba en ese momento. +Esto sí te da una rama local donde puedes trabajar, comenzando donde `origin/serverfix` estaba en ese momento. ### Haciendo seguimiento a las ramas ### -Activando (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar "una rama de seguimiento" (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando 'git push', Git sabe automáticamente a qué servidor y a qué rama ha de llevar los contenidos. Igualmente, tecleando 'git pull' mientras estamos en una de esas ramas, recupera (fetch) todas las referencias remotas y las consolida (merge) automáticamente en la correspondiente rama remota. +Activando (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar "una rama de seguimiento" (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando `git push`, Git sabe automáticamente a qué servidor y a qué rama ha de llevar los contenidos. Igualmente, tecleando `git pull` mientras estamos en una de esas ramas, recupera (fetch) todas las referencias remotas y las consolida (merge) automáticamente en la correspondiente rama remota. -Cuando clonas un repositorio, este suele crear automáticamente una rama 'master' que hace seguimiento de 'origin/master'. Y es por eso que 'git push' y 'git pull' trabajan directamente, sin necesidad de más argumentos. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que no hagan seguimiento de ramas en 'origin' y que no sigan a la rama 'master'. El ejemplo más simple, es el que acabas de ver al lanzar el comando 'git checkout -b [rama] [nombreremoto]/[rama]'. Si tienes la versión 1.6.2 de Git, o superior, puedes utilizar también el parámetro '--track': +Cuando clonas un repositorio, este suele crear automáticamente una rama `master` que hace seguimiento de `origin/master`. Y es por eso que `git push` y `git pull` trabajan directamente, sin necesidad de más argumentos. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que no hagan seguimiento de ramas en `origin` y que no sigan a la rama `master`. El ejemplo más simple, es el que acabas de ver al lanzar el comando `git checkout -b [rama] [nombreremoto]/[rama]`. Si tienes la versión 1.6.2 de Git, o superior, puedes utilizar también el parámetro `--track`: $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. @@ -460,17 +460,17 @@ Para preparar una rama local con un nombre distinto a la del remoto, puedes util Branch sf set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "sf" -Así, tu rama local 'sf' va a llevar (push) y traer (pull) hacia o desde 'origin/serverfix'. +Así, tu rama local `sf` va a llevar (push) y traer (pull) hacia o desde `origin/serverfix`. ### Borrando ramas remotas ### -Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus colaboradores habeis completado una determinada funcionalidad y la habeis incorporado (merge) a la rama 'master' en el remoto (o donde quiera que tengais la rama de código estable). Puedes borrar la rama remota utilizando la un tanto confusa sintaxis: 'git push [nombreremoto] :[rama]'. Por ejemplo, si quieres borrar la rama 'serverfix' del servidor, puedes utilizar: +Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus colaboradores habeis completado una determinada funcionalidad y la habeis incorporado (merge) a la rama `master` en el remoto (o donde quiera que tengais la rama de código estable). Puedes borrar la rama remota utilizando la un tanto confusa sintaxis: `git push [nombreremoto] :[rama]`. Por ejemplo, si quieres borrar la rama `serverfix` del servidor, puedes utilizar: $ git push origin :serverfix To git@github.com:schacon/simplegit.git - [deleted] serverfix -Y....Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis 'git push [nombreremoto] [ramalocal]:[ramaremota]'. Si omites la parte '[ramalocal]', lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]". +Y....Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis `git push [nombreremoto] [ramalocal]:[ramaremota]`. Si omites la parte `[ramalocal]`, lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]". ## Reorganizando el trabajo realizado ## @@ -483,12 +483,12 @@ Volviendo al ejemplo anterior, en la sección sobre fusiones (ver Figura 3-27), Insert 18333fig0327.png Figura 3-27. El registro de confirmaciones inicial. -La manera más sencilla de integrar ramas, tal y como hemos visto, es el comando 'git merge'. Realiza una fusión a tres bandas entre las dos últimas instantáneas de cada rama (C3 y C4) y el ancestro común a ambas (C2); creando una nueva instantánea (snapshot) y la correspondiente confirmación (commit), según se muestra en la Figura 3-28. +La manera más sencilla de integrar ramas, tal y como hemos visto, es el comando `git merge`. Realiza una fusión a tres bandas entre las dos últimas instantáneas de cada rama (C3 y C4) y el ancestro común a ambas (C2); creando una nueva instantánea (snapshot) y la correspondiente confirmación (commit), según se muestra en la Figura 3-28. Insert 18333fig0328.png Figura 3-28. Fusionando una rama para integrar el registro de trabajos divergentes. -Aunque también hay otra forma de hacerlo: puedes coger los cambios introducidos en C3 y reaplicarlos encima de C4. Esto es lo que en Git llamamos _reorganizar_. Con el comando 'git rebase', puedes coger todos los cambios confirmados en una rama, y reaplicarlos sobre otra. +Aunque también hay otra forma de hacerlo: puedes coger los cambios introducidos en C3 y reaplicarlos encima de C4. Esto es lo que en Git llamamos _reorganizar_. Con el comando `git rebase`, puedes coger todos los cambios confirmados en una rama, y reaplicarlos sobre otra. Por ejemplo, puedes lanzar los comandos: @@ -502,29 +502,29 @@ Haciendo que Git: vaya al ancestro común de ambas ramas (donde estás actualmen Insert 18333fig0329.png Figura 3-29. Reorganizando sobre C4 los cambios introducidos en C3. -En este momento, puedes volver a la rama 'master' y hacer una fusión con avance rápido (fast-forward merge). (ver Figura 3-30) +En este momento, puedes volver a la rama `master` y hacer una fusión con avance rápido (fast-forward merge). (ver Figura 3-30) Insert 18333fig0330.png -Figura 3-30. Avance rápido de la rama 'master'. +Figura 3-30. Avance rápido de la rama `master`. Así, la instantánea apuntada por C3' aquí es exactamente la misma apuntada por C5 en el ejemplo de la fusión. No hay ninguna diferencia en el resultado final de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal: como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en paralelo. -Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama 'origin/master' cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia. +Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia. Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una regorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea. Lo único diferente es el registro. La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera. Mientras que la fusión combina entre sí los dos puntos finales de ambas ramas. ### Algunas otras reorganizaciones interesantes ### -También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual ('server') para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Despues, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama 'client'), y confirmas también esos cambios. Por último, vuelves sobre la rama 'server' y haces algunos cambios más. +También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual (`server`) para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Despues, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama `client`), y confirmas también esos cambios. Por último, vuelves sobre la rama `server` y haces algunos cambios más. Insert 18333fig0331.png Figura 3-31. Un registro con una rama puntual sobre otra rama puntual. -Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no estan en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción '--onto' del comando 'git rebase': +Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no estan en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción `--onto` del comando `git rebase`: $ git rebase --onto master server client -Esto viene a decir: "Activa la rama 'client', averigua los cambios desde el ancestro común entre las ramas 'client' y 'server', y aplicalos en la rama 'master'. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes. +Esto viene a decir: "Activa la rama `client`, averigua los cambios desde el ancestro común entre las ramas `client` y `server`, y aplicalos en la rama `master`. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes. Insert 18333fig0332.png Figura 3-32. Reorganizando una rama puntual fuera de otra rama puntual. @@ -535,23 +535,23 @@ Y, tras esto, ya puedes avanzar la rama principal (ver Figura 3-33): $ git merge client Insert 18333fig0333.png -Figura 3-33. Avance rápido de tu rama 'master', para incluir los cambios de la rama 'client'. +Figura 3-33. Avance rápido de tu rama `master`, para incluir los cambios de la rama `client`. -Ahora supongamos que decides traerlos (pull) también sobre tu rama 'server'. Puedes reorganizar (rebase) la rama 'server' sobre la rama 'master' sin necesidad siquiera de comprobarlo previamente, usando el comando 'git rebase [ramabase] [ramapuntual]'. El cual activa la rama puntual ('server' en este caso) y la aplica sobre la rama base ('master' en este caso): +Ahora supongamos que decides traerlos (pull) también sobre tu rama `server`. Puedes reorganizar (rebase) la rama `server` sobre la rama `master` sin necesidad siquiera de comprobarlo previamente, usando el comando `git rebase [ramabase] [ramapuntual]`. El cual activa la rama puntual (`server` en este caso) y la aplica sobre la rama base (`master` en este caso): $ git rebase master server -Esto vuelca el trabajo de 'server' sobre el de 'master', tal y como se muestra en la Figura 3-34. +Esto vuelca el trabajo de `server` sobre el de `master`, tal y como se muestra en la Figura 3-34. Insert 18333fig0334.png -Figura 3-34. Reorganizando la rama 'server' sobre la rama 'branch'. +Figura 3-34. Reorganizando la rama `server` sobre la rama `branch`. -Después, puedes avanzar rápidamente la rama base ('master'): +Después, puedes avanzar rápidamente la rama base (`master`): $ git checkout master $ git merge server -Y por último puedes eliminar las ramas 'client' y 'server' porque ya todo su contenido ha sido integrado y no las vas a necesitar más. Dejando tu registro tras todo este proceso tal y como se muestra en la Figura 3-35: +Y por último puedes eliminar las ramas `client` y `server` porque ya todo su contenido ha sido integrado y no las vas a necesitar más. Dejando tu registro tras todo este proceso tal y como se muestra en la Figura 3-35: $ git branch -d client $ git branch -d server @@ -567,7 +567,7 @@ Ahh...., pero la dicha de la reorganización no la alcanzamos sin sus contrapart Siguiendo esta recomendación, no tendrás problemas. Pero si no la sigues, la gente te odiará y serás despreciado por tus familiares y amigos. -Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes. Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí. Y después vas tu y las reescribes con 'git rebase' y las vuelves a enviar (push) de nuevo. Tus colaboradores tendrán que refusionar (re-merge) su trabajo y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo. +Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes. Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí. Y después vas tu y las reescribes con `git rebase` y las vuelves a enviar (push) de nuevo. Tus colaboradores tendrán que refusionar (re-merge) su trabajo y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo. Vamos a verlo con un ejemplo. Imaginate que haces un clon desde un servidor central, y luego trabajas sobre él. Tu registro de cambios puede ser algo como lo de la Figura 3-36. @@ -579,7 +579,7 @@ Ahora, otra persona trabaja también sobre ello, realiza una fusión (merge) y l Insert 18333fig0337.png Figura 3-37. Traer (fetch) algunas confirmaciones de cambio (commits) y fusionarlas (merge) sobre tu trabajo. -A continuación, la persona que habia llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un 'git push --force' para sobreescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor. +A continuación, la persona que habia llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un `git push --force` para sobreescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor. Insert 18333fig0338.png Figura 3-38. Alguien envia (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habias basado tu trabajo. @@ -589,7 +589,7 @@ En ese momento, tu te ves obligado a fusionar (merge) tu trabajo de nuevo, aunqu Insert 18333fig0339.png Figura 3-39. Vuelves a fusionar el mismo trabajo en una nueva fusión confirmada. -Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un 'git log' en un registro como este, verás dos confirmaciones con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envias (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente. +Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un `git log` en un registro como este, verás dos confirmaciones con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envias (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente. Si solo usas la reorganización como una vía para hacer limpieza y organizar confirmaciones de cambio antes de enviarlas, y si únicamente reorganizas confirmaciones que nunca han sido públicas. Entonces no tendrás problemas. Si, por el contrario, reorganizas confirmaciones que alguna vez han sido públicas y otra gente ha basado su trabajo en ellas. Entonces estarás en un aprieto. From b6a2407be6f5f665198ff030481c34573ada5b4d Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Sun, 18 May 2014 02:15:33 +0200 Subject: [PATCH 032/291] [es] Update chapter 3: fixed some mistakes * Suspension points had 4 or 5 points instead of 3. * Closing exclamation mark not opened. --- es/03-git-branching/01-chapter3.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown index 9a732fa23..2977cb2ab 100644 --- a/es/03-git-branching/01-chapter3.markdown +++ b/es/03-git-branching/01-chapter3.markdown @@ -32,7 +32,7 @@ Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirma Insert 18333fig0303.png Figura 3-3. Apuntadores en el registro de confirmaciones de una rama. -¿Qué sucede cuando creas una nueva rama? Bueno....., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando `git branch`: +¿Qué sucede cuando creas una nueva rama? Bueno..., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando `git branch`: $ git branch testing @@ -41,7 +41,7 @@ Esto creará un nuevo apuntador apuntando a la misma confirmación donde estés Insert 18333fig0304.png Figura 3-4. Apuntadores de varias ramas en el registro de confirmaciones de cambio. -Y, ¿cómo sabe Git en qué rama estás en este momento? Pues...., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama `master`. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama. +Y, ¿cómo sabe Git en qué rama estás en este momento? Pues..., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama `master`. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama. Insert 18333fig0305.png Figura 3-5. Apuntador HEAD a la rama donde estás actualmente. @@ -55,7 +55,7 @@ Esto mueve el apuntador HEAD a la rama `testing` (ver Figura 3-6). Insert 18333fig0306.png Figura 3-6. Apuntador HEAD apuntando a otra rama cuando saltamos de rama. -¿Cuál es el significado de todo esto?. Bueno.... lo veremos tras realizar otra confirmación de cambios: +¿Cuál es el significado de todo esto?. Bueno... lo veremos tras realizar otra confirmación de cambios: $ vim test.rb $ git commit -a -m 'made a change' @@ -470,7 +470,7 @@ Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus co To git@github.com:schacon/simplegit.git - [deleted] serverfix -Y....Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis `git push [nombreremoto] [ramalocal]:[ramaremota]`. Si omites la parte `[ramalocal]`, lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]". +Y... ¡Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis `git push [nombreremoto] [ramalocal]:[ramaremota]`. Si omites la parte `[ramalocal]`, lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]". ## Reorganizando el trabajo realizado ## @@ -561,7 +561,7 @@ Figura 3-35. Registro final de confirmaciones de cambio. ### Los peligros de la reorganización ### -Ahh...., pero la dicha de la reorganización no la alcanzamos sin sus contrapartidas: +Ahh..., pero la dicha de la reorganización no la alcanzamos sin sus contrapartidas: **Nunca reorganices confirmaciones de cambio (commits) que hayas enviado (push) a un repositorio público.** From 6652b8578e0baaa634e5cf7af3318a908df0bab2 Mon Sep 17 00:00:00 2001 From: Carlos Arturo Guerra Parra Date: Sun, 18 May 2014 23:16:28 +0200 Subject: [PATCH 033/291] [es] Fixed some orthography mistakes --- es/03-git-branching/01-chapter3.markdown | 58 ++++++++++++------------ 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown index 2977cb2ab..44f715729 100644 --- a/es/03-git-branching/01-chapter3.markdown +++ b/es/03-git-branching/01-chapter3.markdown @@ -74,7 +74,7 @@ La Figura 3-8 muestra el resultado. Insert 18333fig0308.png Figura 3-8. HEAD apunta a otra rama cuando hacemos un checkout. -Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejandolos tal y como estaban en la última instantánea confirmada en dicha rama `master`. Esto supone que los cambios que hagas desde este momento en adelante divergerán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habias hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente. +Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejándolos tal y como estaban en la última instantánea confirmada en dicha rama `master`. Esto supone que los cambios que hagas desde este momento en adelante divergirán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habías hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente. Haz algunos cambios más y confirmalos: @@ -88,7 +88,7 @@ Figura 3-9. Los registros de las ramas divergen. Debido a que una rama Git es realmente un simple archivo que contiene los 40 caracteres de una suma de control SHA-1, (representando la confirmación de cambios a la que apunta), no cuesta nada el crear y destruir ramas en Git. Crear una nueva rama es tan rápido y simple como escribir 41 bytes en un archivo, (40 caracteres y un retorno de carro). -Esto contrasta fuertemente con los métodos de ramificación usados por otros sistemas de control de versiones. En los que crear una nueva rama supone el copiar todos los archivos del proyecto a una nueva carpeta adiccional. Lo que puede llevar segundos o incluso minutos, dependiendo del tamaño del proyecto. Mientras que en Git el proceso es siempre instantáneo. Y, además, debido a que se almacenan tambien los nodos padre para cada confirmación, el encontrar las bases adecuadas para realizar una fusión entre ramas es un proceso automático y generalmente sencillo de realizar. Animando así a los desarrolladores a utilizar ramificaciones frecuentemente. +Esto contrasta fuertemente con los métodos de ramificación usados por otros sistemas de control de versiones. En los que crear una nueva rama supone el copiar todos los archivos del proyecto a una nueva carpeta adicional. Lo que puede llevar segundos o incluso minutos, dependiendo del tamaño del proyecto. Mientras que en Git el proceso es siempre instantáneo. Y, además, debido a que se almacenan también los nodos padre para cada confirmación, el encontrar las bases adecuadas para realizar una fusión entre ramas es un proceso automático y generalmente sencillo de realizar. Animando así a los desarrolladores a utilizar ramificaciones frecuentemente. Y vamos a ver el por qué merece la pena hacerlo así. @@ -100,11 +100,11 @@ Vamos a presentar un ejemplo simple de ramificar y de fusionar, con un flujo de 2. Creas una rama para un nuevo tema sobre el que quieres trabajar. 3. Realizas algo de trabajo en esa rama. -En este momento, recibes una llamada avisandote de un problema crítico que has de resolver. Y sigues los siguientes pasos: +En este momento, recibes una llamada avisándote de un problema crítico que has de resolver. Y sigues los siguientes pasos: 1. Vuelves a la rama de producción original. 2. Creas una nueva rama para el problema crítico y lo resuelves trabajando en ella. -3. Tras las pertinentes pruebas, fusionas (merge) esa rama y la envias (push) a la rama de producción. +3. Tras las pertinentes pruebas, fusionas (merge) esa rama y la envías (push) a la rama de producción. 4. Vuelves a la rama del tema en que andabas antes de la llamada y continuas tu trabajo. ### Procedimientos básicos de ramificación ### @@ -114,7 +114,7 @@ Imagina que estas trabajando en un proyecto, y tienes un par de confirmaciones ( Insert 18333fig0310.png Figura 3-10. Un registro de confirmaciones simple y corto. -Decides trabajar el problema #53, del sistema que tu compañia utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`: +Decides trabajar el problema #53, del sistema que tu compañía utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`: $ git checkout -b iss53 Switched to a new branch "iss53" @@ -137,7 +137,7 @@ Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Co Insert 18333fig0312.png Figura 3-12. La rama `iss53` ha avanzado con tu trabajo. -Entonces, recibes una llamada avisandote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habias realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de ella. +Entonces, recibes una llamada avisándote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habías realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de ella. Pero, antes de poder hacer eso, hemos de tener en cuenta que teniendo cambios aún no confirmados en la carpeta de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos. Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas. Y, para ello, tenemos algunos procedimientos (stash y commit ammend), que vamos a ver más adelante. Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama `master` sin problemas: @@ -167,19 +167,19 @@ Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, README | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) -Merece destacar la frase "Avance rápido" ("Fast forward") que aparece en la respuesta al comando. Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente "aguas arriba" respecto de la confirmación actual. Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el registro de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningûn otro trabajo divergente a fusionar. Esto es lo que se denomina "avance rápido" ("fast forward"). +Merece destacar la frase "Avance rápido" ("Fast forward") que aparece en la respuesta al comando. Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente "aguas arriba" respecto de la confirmación actual. Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el registro de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningún otro trabajo divergente a fusionar. Esto es lo que se denomina "avance rápido" ("fast forward"). Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama `master`. Y puedes desplegarlos (ver Figura 3-14) Insert 18333fig0314.png Figura 3-14. Tras la fusión (merge), la rama `master` apunta al mismo sitio que la rama `hotfix`. -Tras haber resuelto el problema urgente que te habia interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`: +Tras haber resuelto el problema urgente que te habií interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`: $ git branch -d hotfix Deleted branch hotfix (3a0874c). -Y, con esto, ya estas dispuesto para regresar al trabajo sobre el problema #53 (ver Figura 3-15): +Y, con esto, ya estás dispuesto para regresar al trabajo sobre el problema #53 (ver Figura 3-15): $ git checkout iss53 Switched to branch "iss53" @@ -203,14 +203,14 @@ Supongamos que tu trabajo con el problema #53 está ya completo y listo para fus README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -Es algo diferente de la fusión realizada anteriormente con `hotfix`. En este caso, el registro de desarrollo habia divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso. +Es algo diferente de la fusión realizada anteriormente con `hotfix`. En este caso, el registro de desarrollo había divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso. Insert 18333fig0316.png Figura 3-16. Git identifica automáticamente el mejor ancestro común para realizar la fusión de las ramas. En lugar de simplemente avanzar el apuntador de la rama, Git crea una nueva instantánea (snapshot) resultante de la fusión a tres bandas; y crea automáticamente una nueva confirmación de cambios (commit) que apunta a ella. Nos referimos a este proceso como "fusión confirmada". Y se diferencia en que tiene más de un padre. -Merece la pena destacar el hecho de que es el propio Git quien determina automáticamente el mejor ancestro común para realizar la fusión. Diferenciandose de otros sistemas tales como CVS o Subversion, donde es el desarrollador quien ha de imaginarse cuál puede ser dicho mejor ancestro común. Esto hace que en Git sea mucho más facil el realizar fusiones. +Merece la pena destacar el hecho de que es el propio Git quien determina automáticamente el mejor ancestro común para realizar la fusión. Diferenciandose de otros sistemas tales como CVS o Subversion, donde es el desarrollador quien ha de imaginarse cuál puede ser dicho mejor ancestro común. Esto hace que en Git sea mucho más fácil el realizar fusiones. Insert 18333fig0317.png Figura 3-17. Git crea automáticamente una nueva confirmación para la fusión. @@ -250,14 +250,14 @@ Todo aquello que sea conflictivo y no se haya podido resolver, se marca como "si >>>>>>> iss53:index.html -Donde nos dice que la versión en HEAD (la rama `master`, la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de `=======`). Y que la versión en `iss53` contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejandolo tal que: +Donde nos dice que la versión en HEAD (la rama `master`, la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de `=======`). Y que la versión en `iss53` contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejándolo tal que: Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos `git add` para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos. -Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando `git mergetool`. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella. +Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando `git mergetool`. Esto arrancará la correspondiente herramienta de visualización y te permitirá ir resolviendo conflictos con ella. $ git mergetool merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff @@ -295,7 +295,7 @@ Si todo ha ido correctamente, y ves que todos los archivos conflictivos están m # and try again. # -Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fusión, si lo consideras util para que otros entiendan esta fusión en un futuro. Se trata de indicar porqué has hecho lo que has hecho; a no ser que resulte obvio, claro está. +Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fusión, si lo consideras útil para que otros entiendan esta fusión en un futuro. Se trata de indicar porqué has hecho lo que has hecho; a no ser que resulte obvio, claro está. ## Gestión de ramificaciones ## @@ -342,7 +342,7 @@ Ahora que ya has visto los procedimientos básicos de ramificación y fusión, ### Ramas de largo recorrido ### -Por la sencillez de la fusión a tres bandas de Git, el fusionar de una rama a otra multitud de veces a lo largo del tiempo es facil de hacer. Esto te posibilita tener varias ramas siempre abiertas, e irlas usando en diferentes etapas del ciclo de desarrollo; realizando frecuentes fusiones entre ellas. +Por la sencillez de la fusión a tres bandas de Git, el fusionar de una rama a otra multitud de veces a lo largo del tiempo es fácil de hacer. Esto te posibilita tener varias ramas siempre abiertas, e irlas usando en diferentes etapas del ciclo de desarrollo; realizando frecuentes fusiones entre ellas. Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza, manteniendo en la rama `master` únicamente el código totalmente estable (el código que ha sido o que va a ser liberado). Teniendo otras ramas paralelas denominadas `desarrollo` o `siguiente`, en las que trabajan y realizan pruebas. Estas ramas paralelas no suele estar siempre en un estado estable; pero cada vez que sí lo están, pueden ser fusionadas con la rama `master`. También es habitual el incorporarle (pull) ramas puntuales (ramas temporales, como la rama `iss53` del anterior ejemplo) cuando las completamos y estamos seguros de que no van a introducir errores. @@ -375,7 +375,7 @@ En este momento, supongamos que te decides por la segunda solución al problema Insert 18333fig0321.png Figura 3-21. El registro tras fusionar `dumbidea` e `iss91v2`. -Es importante recordar que, mientras estás haciendo todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositório Git. No hay nigún tipo de tráfico con ningún servidor. +Es importante recordar que, mientras estás haciendo todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositorio Git. No hay nigún tipo de tráfico con ningún servidor. ## Ramas Remotas ## @@ -383,7 +383,7 @@ Las ramas remotas son referencias al estado de ramas en tus repositorios remotos Suelen referenciarse como `(remoto)/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`. Puedes revisar la rama `origin/master`. O si estás trabajando en un problema con un compañero y este envia (push) una rama `iss53`, tu tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin/iss53`. -Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un sevidor Git en tu red, en `git.ourcompany.com`. Si haces un clón desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master`, denominará la copia local `origin/master`; y será inamovible para tí. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; siendo en esta última donde podrás trabajar. +Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un sevidor Git en tu red, en `git.ourcompany.com`. Si haces un clón desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master`, denominará la copia local `origin/master`; y será inamovible para ti. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; siendo en esta última donde podrás trabajar. Insert 18333fig0322.png Figura 3-22. Un clón Git te proporciona tu propia rama `master` y otra rama `origin/master` apuntando a la rama `master` original. @@ -422,7 +422,7 @@ Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboraci To git@github.com:schacon/simplegit.git * [new branch] serverfix -> serverfix -Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viendolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto. +Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viéndolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto. La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de `serverfix` en el servidor esté bajo la rama remota `origin/serverfix`: @@ -436,7 +436,7 @@ La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán un Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia editable local de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin/serverfix`. -Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix`, donde puedas trabajar, puedes crearla directamente basandote en rama remota: +Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix`, donde puedas trabajar, puedes crearla directamente basaádote en rama remota: $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. @@ -509,22 +509,22 @@ Figura 3-30. Avance rápido de la rama `master`. Así, la instantánea apuntada por C3' aquí es exactamente la misma apuntada por C5 en el ejemplo de la fusión. No hay ninguna diferencia en el resultado final de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal: como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en paralelo. -Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia. +Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorganizar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia. -Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una regorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea. Lo único diferente es el registro. La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera. Mientras que la fusión combina entre sí los dos puntos finales de ambas ramas. +Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una reorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea. Lo único diferente es el registro. La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera. Mientras que la fusión combina entre sí los dos puntos finales de ambas ramas. ### Algunas otras reorganizaciones interesantes ### -También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual (`server`) para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Despues, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama `client`), y confirmas también esos cambios. Por último, vuelves sobre la rama `server` y haces algunos cambios más. +También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual (`server`) para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Después, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama `client`), y confirmas también esos cambios. Por último, vuelves sobre la rama `server` y haces algunos cambios más. Insert 18333fig0331.png Figura 3-31. Un registro con una rama puntual sobre otra rama puntual. -Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no estan en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción `--onto` del comando `git rebase`: +Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no están en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción `--onto` del comando `git rebase`: $ git rebase --onto master server client -Esto viene a decir: "Activa la rama `client`, averigua los cambios desde el ancestro común entre las ramas `client` y `server`, y aplicalos en la rama `master`. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes. +Esto viene a decir: "Activa la rama `client`, averigua los cambios desde el ancestro común entre las ramas `client` y `server`, y aplicarlos en la rama `master`. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes. Insert 18333fig0332.png Figura 3-32. Reorganizando una rama puntual fuera de otra rama puntual. @@ -569,7 +569,7 @@ Siguiendo esta recomendación, no tendrás problemas. Pero si no la sigues, la g Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes. Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí. Y después vas tu y las reescribes con `git rebase` y las vuelves a enviar (push) de nuevo. Tus colaboradores tendrán que refusionar (re-merge) su trabajo y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo. -Vamos a verlo con un ejemplo. Imaginate que haces un clon desde un servidor central, y luego trabajas sobre él. Tu registro de cambios puede ser algo como lo de la Figura 3-36. +Vamos a verlo con un ejemplo. Imagínate que haces un clon desde un servidor central, y luego trabajas sobre él. Tu registro de cambios puede ser algo como lo de la Figura 3-36. Insert 18333fig0336.png Figura 3-36. Clonar un repositorio y trabajar sobre él. @@ -579,20 +579,20 @@ Ahora, otra persona trabaja también sobre ello, realiza una fusión (merge) y l Insert 18333fig0337.png Figura 3-37. Traer (fetch) algunas confirmaciones de cambio (commits) y fusionarlas (merge) sobre tu trabajo. -A continuación, la persona que habia llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un `git push --force` para sobreescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor. +A continuación, la persona que había llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un `git push --force` para sobrescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor. Insert 18333fig0338.png -Figura 3-38. Alguien envia (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habias basado tu trabajo. +Figura 3-38. Alguien envií (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habías basado tu trabajo. En ese momento, tu te ves obligado a fusionar (merge) tu trabajo de nuevo, aunque creias que ya lo habias hecho antes. La reorganización cambia los resumenes (hash) SHA-1 de esas confirmaciones (commits), haciendo que Git se crea que son nuevas confirmaciones. Cuando realmente tu ya tenias el trabajo de C4 en tu registro. Insert 18333fig0339.png Figura 3-39. Vuelves a fusionar el mismo trabajo en una nueva fusión confirmada. -Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un `git log` en un registro como este, verás dos confirmaciones con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envias (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente. +Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un `git log` en un registro como este, verás dos confirmaciones con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envías (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente. Si solo usas la reorganización como una vía para hacer limpieza y organizar confirmaciones de cambio antes de enviarlas, y si únicamente reorganizas confirmaciones que nunca han sido públicas. Entonces no tendrás problemas. Si, por el contrario, reorganizas confirmaciones que alguna vez han sido públicas y otra gente ha basado su trabajo en ellas. Entonces estarás en un aprieto. ## Recapitulación ## -Hemos visto los procedimientos básicos de ramificación (branching) y fusión (merging) en Git. A estas alturas, te sentirás cómodo creando nuevas ramas (branch), saltando (checkout) entre ramas para trabajar y fusionando (merge) ramas entre ellas. También conocerás cómo compatir tus ramas enviandolas (push) a un servidor compartido, cómo trabajar colaborativamente en ramas compartidas, y cómo reorganizar (rebase) tus ramas antes de compartirlas. +Hemos visto los procedimientos básicos de ramificación (branching) y fusión (merging) en Git. A estas alturas, te sentirás cómodo creando nuevas ramas (branch), saltando (checkout) entre ramas para trabajar y fusionando (merge) ramas entre ellas. También conocerás cómo compartir tus ramas enviándolas (push) a un servidor compartido, cómo trabajar colaborativamente en ramas compartidas, y cómo reorganizar (rebase) tus ramas antes de compartirlas. From 0f99958673a96ff97ea9a28556c1d7d022987883 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sun, 18 May 2014 23:22:49 +0200 Subject: [PATCH 034/291] [cs] the empty cs/09-git-internals/02-translation-notes.markdown added The reason is to try overwrite incorectly rendered content. --- cs/09-git-internals/02-translation-notes.markdown | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 cs/09-git-internals/02-translation-notes.markdown diff --git a/cs/09-git-internals/02-translation-notes.markdown b/cs/09-git-internals/02-translation-notes.markdown new file mode 100644 index 000000000..e69de29bb From b8ca7b9979f981269279f04ff1201243fca74d59 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 20 May 2014 12:01:24 +0200 Subject: [PATCH 035/291] [cs] faked chapter in cs/09-git-internals/02-translation-notes.markdown --- cs/09-git-internals/02-translation-notes.markdown | 1 + 1 file changed, 1 insertion(+) diff --git a/cs/09-git-internals/02-translation-notes.markdown b/cs/09-git-internals/02-translation-notes.markdown index e69de29bb..e769bc6e0 100644 --- a/cs/09-git-internals/02-translation-notes.markdown +++ b/cs/09-git-internals/02-translation-notes.markdown @@ -0,0 +1 @@ +# .......... \ No newline at end of file From 656765a765691d837ba919bc3974529f6ee728c2 Mon Sep 17 00:00:00 2001 From: Soon Van Date: Tue, 20 May 2014 22:47:49 -0400 Subject: [PATCH 036/291] Word spacing and capitals on README [ci skip] --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 5e72d6d1f..0230cddf5 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ On MacOS you can do like this:: ## Notes on pandoc -Please use Pandoc version 1.11.1 or later as older versions(confirmed on 1.9.1.1) has a [bug](https://github.com/jgm/pandoc/issues/964) which hides a word after tilde `~`. You can do `pandoc -v` to see which version you have installed. +Please use Pandoc version 1.11.1 or later as older versions (confirmed on 1.9.1.1) has a [bug](https://github.com/jgm/pandoc/issues/964) which hides a word after tilde `~`. You can do `pandoc -v` to see which version you have installed. # Errata @@ -46,13 +46,13 @@ correction, please [open an issue](https://github.com/progit/progit/issues/new) If you wish to translate the book, your work will be put up on the git-scm.com site. Please put your translation into the appropriate subdirectory of this project, using the -[ISO 639](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) +[ISO 639](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) code and send a pull request. # Sending a pull request * Be careful to use UTF-8 encoding in your files. -* Do not mix changes to the original english with translations in a single pull request. -* If your pull request changes a translation, prefix your pull request and commits'messages with the ISO 639 code, e.g. `[de] Update chapter 2`. Please only push files where there is already some translation done. +* Do not mix changes to the original English with translations in a single pull request. +* If your pull request changes a translation, prefix your pull request and commits' messages with the ISO 639 code, e.g. `[de] Update chapter 2`. Please only push files where there is already some translation done. * Make sure the translation changes can be automatically merged. The maintainers can not make the merge manually if there are some conflicts. -* Make as sure as possible that the changes work correctly for publishing to pdf, ebooks and the git-scm.com website +* Make as sure as possible that the changes work correctly for publishing to PDF, ebooks and the git-scm.com website. From fce58269569383f95c59278c838feb8a4226c98e Mon Sep 17 00:00:00 2001 From: Yue Lin Ho Date: Fri, 23 May 2014 07:11:54 +0800 Subject: [PATCH 037/291] [zh-tw] Synchronize with En version Based on commits from 2014.04.15 to 2014.05.17: 1) 3f6c10594c51ac7b61dab0115c5f43740ef7093b 2) ceba7dfb5358143802192fd6f231db1aa06aaccb 3) 60e261895a77951a6541470c9438f32a1e5b7fd0 4) 5f72fef306296811cc8b165e312b703f6090931c 5) 9c4252b492885aabe41346148d589b480e753a60 6) 20a3f53631c8b3fb448ac7717263b62a22f4ffda 7) f987da8c61924b4f710fd9aac26619bf6b5e9d85 8) f5170bb2e34131c7088236066d13d1f657dfa381 --- zh-tw/02-git-basics/01-chapter2.markdown | 8 +++-- zh-tw/06-git-tools/01-chapter6.markdown | 36 +++++++++++++------ zh-tw/07-customizing-git/01-chapter7.markdown | 12 +++---- 3 files changed, 35 insertions(+), 21 deletions(-) diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown index 2f80c92c1..0ab5bb8e7 100644 --- a/zh-tw/02-git-basics/01-chapter2.markdown +++ b/zh-tw/02-git-basics/01-chapter2.markdown @@ -325,7 +325,7 @@ A `**/` pattern is available in Git since version 1.8.2. 另一種方式則是在commit命令後方以`-m`參數指定提交訊息，如下： $ git commit -m "Story 182: Fix benchmarks for speed" - [master 463dc4f] Fix benchmarks for speed + [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README @@ -638,7 +638,9 @@ The lines must be formatted as follows 此命令支援多種格式。 可指定特定日期（如：“2008-01-15”）或相對的日期，如：“2 years 1 day 3 minutes ago”。 -使用者也可以過濾出符合某些搜尋條件的更新。 `--author` 選項允許使用者過濾出特定作者，而 `--grep` 選項允許以關鍵字搜尋提交的訊息。（注意：若希望同時符合作者名字及字串比對，需要再加上 `--all-match`；否則預設為列出符合任一條件的更新） +使用者也可以過濾出符合某些搜尋條件的更新。 `--author` 選項允許使用者過濾出特定作者，而 `--grep` 選項允許以關鍵字搜尋提交的訊息。（注意：若同時使用作者名字及字串比對，該命令會列出同時符合二個條件的更新。） + +若希望比對多個字串，需要再加上 `--all-match`；否則只會列出符合任一條件的更新。 最後一個有用的選項是過濾路徑。 若指定目錄或檔案名稱，可僅印出更動到這些檔案的更新。 這選項永遠放在最後，而且一般來說會在前方加上 -- 以資區別。 @@ -797,7 +799,7 @@ Insert 18333fig0202.png koke git://github.com/koke/grit.git origin git@github.com:mojombo/grit.git -這意謂著我們可很容易從這些伙伴的儲存庫取得最新的更新。 要留意的是只有 origin 遠端的 URL 是 SSH。 因此它是唯一我們能上傳的遠端的儲存庫。（關於這部份將在第四章介紹） +這意謂著我可以很容易從這些伙伴的儲存庫取得最新的更新。 要留意的是只有 origin 遠端的 URL 是 SSH。 因此它是唯一我能上傳的遠端的儲存庫。（關於這部份將在第四章介紹） ### 新增遠端儲存庫 ### diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown index 392cc7b5b..42c34316e 100644 --- a/zh-tw/06-git-tools/01-chapter6.markdown +++ b/zh-tw/06-git-tools/01-chapter6.markdown @@ -82,13 +82,13 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞 你可以使用 `git reflog` 來查看引用日誌： $ git reflog - 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated - d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. - 1c002dd... HEAD@{2}: commit: added some blame and merge stuff - 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD - 95df984... HEAD@{4}: commit: # This is a combination of two commits. - 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD - 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD + 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated + d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. + 1c002dd HEAD@{2}: commit: added some blame and merge stuff + 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD + 95df984 HEAD@{4}: commit: # This is a combination of two commits. + 1c36188 HEAD@{5}: rebase -i (squash): updating HEAD + 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD 每次你的分支頂端因為某些原因被修改時，Git 就會為你將資訊保存在這個臨時歷史記錄裡面。你也可以使用這份資料來指明更早的分支。如果你想查看倉庫中 HEAD 在五次前的值，你可以使用引用日誌的輸出中的 @{n} 引用： @@ -445,8 +445,8 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log 在這個案例中，之前已經進行了兩次儲藏，所以你可以取得三個不同的儲藏。你可以重新應用你剛剛的儲藏，所採用的命令就是原本 stash 命令輸出的輔助訊息裡提示的：`git stash apply`。如果你想應用較舊的儲藏，你可以通過名字指定它，像這樣：`git stash apply stash@{2}`。如果你不指明，Git 預設使用最近的儲藏並嘗試應用它： @@ -480,8 +480,8 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) @@ -565,12 +565,19 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊 # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out 很重要的一點是你得注意這些提交的順序與你通常通過 `log` 命令看到的是相反的。如果你執行 `log`，你會看到下面這樣的結果： @@ -631,12 +638,19 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊 # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out 如果不用 ”pick” 或者 ”edit”，而是指定 ”squash”，Git 會同時應用那個變更和它之前的變更並將提交說明歸併。因此，如果你想將這三個提交合併為單一提交，你可以將腳本修改成這樣： diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown index 4c85c396e..e16573d71 100644 --- a/zh-tw/07-customizing-git/01-chapter7.markdown +++ b/zh-tw/07-customizing-git/01-chapter7.markdown @@ -609,14 +609,12 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更 #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -沒錯，我在用全域變數。別鄙視我——這樣比較利於演示過程。 + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### 強制特定的提交資訊格式 #### From 178682200b339a8802be852494c0282f5467e9d5 Mon Sep 17 00:00:00 2001 From: Xue Fuqiao Date: Tue, 27 May 2014 16:59:45 +0800 Subject: [PATCH 038/291] Markup fix. --- en/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown index 7d06fb1e8..af0ae4ad2 100644 --- a/en/05-distributed-git/01-chapter5.markdown +++ b/en/05-distributed-git/01-chapter5.markdown @@ -632,7 +632,7 @@ To apply a patch generated by `format-patch`, you use `git am`. Technically, `gi Limit log functionality to the first 20 -This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time. +This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time. However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: From 10de0a2643bba02739c4dd6a44bd3bf40223654d Mon Sep 17 00:00:00 2001 From: Xue Fuqiao Date: Tue, 27 May 2014 17:28:24 +0800 Subject: [PATCH 039/291] [zh] Sync with English version. --- zh/02-git-basics/01-chapter2.markdown | 2 +- zh/06-git-tools/01-chapter6.markdown | 22 +++++++++++----------- zh/07-customizing-git/01-chapter7.markdown | 12 +++++------- 3 files changed, 17 insertions(+), 19 deletions(-) diff --git a/zh/02-git-basics/01-chapter2.markdown b/zh/02-git-basics/01-chapter2.markdown index 2a95c60f4..e8e878d0e 100644 --- a/zh/02-git-basics/01-chapter2.markdown +++ b/zh/02-git-basics/01-chapter2.markdown @@ -323,7 +323,7 @@ A `**/` pattern is available in Git since version 1.8.2. 另外也可以用 -m 参数后跟提交说明的方式，在一行命令中提交更新： $ git commit -m "Story 182: Fix benchmarks for speed" - [master 463dc4f] Fix benchmarks for speed + [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown index 391317cfa..ac3f20ac1 100644 --- a/zh/06-git-tools/01-chapter6.markdown +++ b/zh/06-git-tools/01-chapter6.markdown @@ -82,13 +82,13 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递 你可以使用 `git reflog` 来查看引用日志： $ git reflog - 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated - d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. - 1c002dd... HEAD@{2}: commit: added some blame and merge stuff - 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD - 95df984... HEAD@{4}: commit: # This is a combination of two commits. - 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD - 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD + 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated + d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. + 1c002dd HEAD@{2}: commit: added some blame and merge stuff + 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD + 95df984 HEAD@{4}: commit: # This is a combination of two commits. + 1c36188 HEAD@{5}: rebase -i (squash): updating HEAD + 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD 每次你的分支顶端因为某些原因被修改时，Git 就会为你将信息保存在这个临时历史记录里面。你也可以使用这份数据来指明更早的分支。如果你想查看仓库中 HEAD 在五次前的值，你可以使用引用日志的输出中的 `@{n}` 引用： @@ -445,8 +445,8 @@ simplegit.rb的状态非常有意思。它显示有几行被暂存了，有几 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log 在这个案例中，之前已经进行了两次储藏，所以你可以访问到三个不同的储藏。你可以重新应用你刚刚实施的储藏，所采用的命令就是之前在原始的 stash 命令的帮助输出里提示的：`git stash apply`。如果你想应用更早的储藏，你可以通过名字指定它，像这样：`git stash apply stash@{2}`。如果你不指明，Git 默认使用最近的储藏并尝试应用它： @@ -480,8 +480,8 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 9b1a5b9aa..2b4d20121 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -612,14 +612,12 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为 #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -没错，我在用全局变量。别鄙视我——这样比较利于演示过程。 + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### 指定特殊的提交信息格式 #### From 766b4a0cb5c03d6539e955213eb57e4635a78cfa Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Sat, 31 May 2014 00:12:13 +0900 Subject: [PATCH 040/291] [ko] update translation --- ko/01-introduction/01-chapter1.markdown | 2 +- ko/02-git-basics/01-chapter2.markdown | 300 +++++++++++---------- ko/03-git-branching/01-chapter3.markdown | 92 ++++--- ko/04-git-server/01-chapter4.markdown | 50 ++-- ko/05-distributed-git/01-chapter5.markdown | 37 ++- ko/06-git-tools/01-chapter6.markdown | 40 ++- ko/07-customizing-git/01-chapter7.markdown | 12 +- 7 files changed, 298 insertions(+), 235 deletions(-) diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown index a7a24715b..131e80efb 100644 --- a/ko/01-introduction/01-chapter1.markdown +++ b/ko/01-introduction/01-chapter1.markdown @@ -163,7 +163,7 @@ Ubuntu같은 데비안류 배포판에서는 apt-get을 사용한다: Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러가 가장 쉽게 사용할 수 있다. Google Code 페이지에서 내려받는다: - http://code.google.com/p/git-osx-installer + http://sourceforge.net/projects/git-osx-installer/ Insert 18333fig0107.png 그림 1-7. OS X Git 인스톨러 diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown index 5bf08bdfa..61764f4ab 100644 --- a/ko/02-git-basics/01-chapter2.markdown +++ b/ko/02-git-basics/01-chapter2.markdown @@ -54,8 +54,8 @@ Insert 18333fig0201.png 파일의 상태를 확인하려면 보통 `git status` 명령을 사용한다. Clone한 후에 바로 이 명령을 실행하면 아래과 같은 메시지를 볼 수 있다: $ git status - # On branch master - nothing to commit (working directory clean) + On branch master + nothing to commit, working directory clean 위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해준다. Tracked나 Modified 상태인 파일이 없다는 의미다. Untracked 파일은 아직 없어서 목록에 나타나지 않는다. 그리고 현재 작업 중인 브랜치를 알려준다. 기본 브랜치가 master이기 때문에 현재 master로 나오는 것이다. 브랜치 관련 내용은 차차 알아가자. 다음 장에서 브랜치와 레퍼런스에 대해 자세히 다룬다. @@ -63,11 +63,12 @@ Insert 18333fig0201.png $ vim README $ git status - # On branch master - # Untracked files: - # (use "git add ..." to include in what will be committed) - # - # README + On branch master + Untracked files: + (use "git add ..." to include in what will be committed) + + README + nothing added to commit but untracked files present (use "git add" to track) `README` 파일은 `Untracked files` 부분에 속해 있는데 이것은 `README` 파일이 Untracked 상태라는 것을 말한다. Git은 Untracked 파일을 아직 스냅샷(커밋)에 넣어지지 않은 파일이라고 본다. 파일이 Tracked 상태가 되기 전까지는 Git은 절대 그 파일을 커밋하지 않는다. 그래서 일하면서 생성하는 바이너리 파일 같은 것을 커밋하는 실수는 하지 않게 된다. README 파일을 추가해서 직접 Tracked 상태로 만들어 보자. @@ -81,12 +82,12 @@ Insert 18333fig0201.png `git status` 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것을 확인할 수 있다: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + 'Changes to be committed' 에 들어 있는 파일은 Staged 상태라는 것을 의미한다. 커밋하면 `git add`를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다. 앞에서 `git init` 명령을 실행했을 때, 그 다음 `git add (files)` 명령을 실행했던 걸 기억할 것이다. 이것은 작업 디렉토리에 있는 파일들을 추적하기 시작하게 하였다. `git add` 명령은 파일 또는 디렉토리의 경로명을 아규먼트로 받는다; 만일 디렉토리를 아규먼트로 줄 경우, 그 디렉토리 아래에 있는 모든 파일들을 재귀적으로 추가한다. @@ -95,58 +96,59 @@ Insert 18333fig0201.png 이미 Tracked 상태인 파일을 수정하는 법을 알아보자. `benchmarks.rb`라는 파일을 수정하고 나서 `git status` 명령을 다시 실행하면 결과는 아래와 같다: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + 이 `benchmarks.rb` 파일은 `Changes not staged for commit`에 있다. 이것은 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 것이다. Staged 상태로 만들려면 `git add` 명령을 실행해야 한다. `git add`는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다. `git add`를 실행하여 benchmarks.rb 파일을 Staged 상태로 만들고 `git status` 명령으로 결과를 확인해보자: $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + 두 파일 모두 Staged 상태이므로 다음 커밋에 포함된다. 하지만, 아직 더 수정해야 한다는 것을 알게 되어 바로 커밋하지 못하는 상황이 되었다고 하자. 이 상황에서 benchmark.rb 파일을 열고 수정한다. 아마 당신은 커밋할 준비가 다 됐다고 생각할 테지만, Git은 그렇지 않다. `git status` 명령으로 파일의 상태를 다시 확인해보자: $ vim benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + + modified: benchmarks.rb + 헉! benchmarks.rb가 Staged 상태이면서 동시에 Unstaged 상태로 나온다. 어떻게 이런 일이 가능할까? `git add` 명령을 실행하면 Git은 파일을 바로 Staged 상태로 만든다. 지금 이 시점에서 커밋을 하면 `git commit` 명령을 실행하는 시점의 버전이 커밋되는 것이 아니라 마지막으로 `git add` 명령을 실행했을 때의 버전이 커밋된다. 그러니까 `git add` 명령을 실행한 후에 또 파일을 수정하면 `git add` 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 한다: $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + ### 파일 무시하기 ### @@ -192,17 +194,18 @@ Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되 README 파일을 수정해서 Staged 상태로 만들고 benchmarks.rb 파일은 그냥 수정만 해둔다. 이 상태에서 `git status` 명령을 실행하면 아래와 같은 메시지를 볼 수 있다: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + `git diff` 명령을 실행하면 수정했지만 아직 staged 상태가 아닌 파일을 비교해 볼 수 있다: @@ -247,16 +250,18 @@ benchmarks.rb 파일을 Stage한 후에 다시 수정해도 `git diff` 명령을 $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status - # On branch master - # - # Changes to be committed: - # - # modified: benchmarks.rb - # - # Changes not staged for commit: - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + `git diff` 명령으로 Unstaged 상태인 변경 부분을 확인해 볼 수 있다: @@ -305,10 +310,9 @@ Git 설정에 지정된 편집기가 실행되고, 아래와 같은 텍스트가 # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # # new file: README # modified: benchmarks.rb + # ~ ~ ~ @@ -319,8 +323,8 @@ Git 설정에 지정된 편집기가 실행되고, 아래와 같은 텍스트가 메시지를 인라인으로 첨부할 수도 있다. `commit` 명령을 실행할 때 아래와 같이 `-m` 옵션을 사용한다: $ git commit -m "Story 182: Fix benchmarks for speed" - [master]: created 463dc4f: "Fix benchmarks for speed" - 2 files changed, 3 insertions(+), 0 deletions(-) + [master 463dc4f] Story 182: Fix benchmarks for speed + 2 files changed, 3 insertions(+) create mode 100644 README `commit` 명령은 몇 가지 정보를 출력하는데 위 예제는 master 브랜치에 커밋했고 체크섬은 `463dc4f`이라고 알려준다. 그리고 수정한 파일이 몇 개이고 삭제됐거나 추가된 줄이 몇 줄인지 알려준다. @@ -332,15 +336,17 @@ Git은 Staging Area에 속한 스냅샷을 커밋한다는 것을 기억해야 Staging Area는 커밋할 파일을 정리한다는 점에서 매우 유용하지만 복잡하기만 하고 필요하지 않은 때도 있다. 아주 쉽게 Staging Area를 생략할 수 있다. `git commit` 명령을 실행할 때 `-a` 옵션을 추가하면 Git은 Tracked 상태의 파일을 자동으로 Staging Area에 넣는다. 그래서 `git add` 명령을 실행하는 수고를 덜 수 있다: $ git status - # On branch master - # - # Changes not staged for commit: - # - # modified: benchmarks.rb - # + On branch master + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + + no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks - 1 files changed, 5 insertions(+), 0 deletions(-) + 1 files changed, 5 insertions(+) 이 예제에서는 커밋하기 전에 `git add` 명령으로 benchmarks.rb 파일을 추가하지 않았다는 점을 눈여겨보자. @@ -352,26 +358,26 @@ Git에서 파일을 제거하려면 `git rm` 명령으로 Tracked 상태의 파 $ rm grit.gemspec $ git status - # On branch master - # - # Changes not staged for commit: - # (use "git add/rm ..." to update what will be committed) - # - # deleted: grit.gemspec - # + On branch master + Changes not staged for commit: + (use "git add/rm ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + deleted: grit.gemspec + + no changes added to commit (use "git add" and/or "git commit -a") 그리고 `git rm` 명령을 실행하면 삭제한 파일은 staged 상태가 된다: $ git rm grit.gemspec rm 'grit.gemspec' $ git status - # On branch master - # - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # deleted: grit.gemspec - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + deleted: grit.gemspec + 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다. 이미 파일을 수정했거나 Index에(역주, Staging Area을 Git Index라고도 부른다) 추가했다면 `-f`옵션을 주어 강제로 삭제해야 한다. 이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 한 번도 커밋한적 없는 데이터는 Git으로 복구할 수 없다. @@ -401,14 +407,12 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의 $ git mv README.txt README $ git status - # On branch master - # Your branch is ahead of 'origin/master' by 1 commit. - # - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # renamed: README.txt -> README - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + renamed: README.txt -> README + 사실 `git mv` 명령은 아래 명령어들을 수행한 것과 완전히 똑같다: @@ -525,7 +529,7 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의 changed the version number Rakefile | 2 +- - 1 files changed, 1 insertions(+), 1 deletions(-) + 1 file changed, 1 insertion(+), 1 deletion(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon @@ -534,7 +538,7 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의 removed unnecessary test code lib/simplegit.rb | 5 ----- - 1 files changed, 0 insertions(+), 5 deletions(-) + 1 file changed, 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon @@ -545,7 +549,7 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의 README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ lib/simplegit.rb | 25 +++++++++++++++++++++++++ - 3 files changed, 54 insertions(+), 0 deletions(-) + 3 files changed, 54 insertions(+) 이 결과에서 `--stat` 옵션은 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마나 많은 줄을 추가하거나 삭제했는지 보여준다. 요약정보는 가장 뒤쪽에 보여준다. @@ -633,7 +637,9 @@ The lines must be formatted as follows 이 옵션은 다양한 형식을 지원한다. `2008-01-15`같이 정확한 날짜도 사용할 수 있고 `2 years 1 day 3 minutes ago`같이 상대적인 기간을 사용할 수도 있다. -또 다른 기준도 있다. `--author` 옵션으로 저자를 지정하여 검색할 수도 있고 `--grep` 옵션으로 커밋 메시지에서 키워드를 검색할 수도 있다(author와 grep 옵션을 나눠서 지정하고 싶지 않으면 `--all-match` 옵션으로 한 번에 검색할 수 있다). +또 다른 기준도 있다. `--author` 옵션으로 저자를 지정하여 검색할 수도 있고 `--grep` 옵션으로 커밋 메시지에서 키워드를 검색할 수도 있다(author와 grep 옵션을 함께 사용하면 모두 만족하는 커밋을 찾는다). + +grep 옵션을 여러개 사용하면 그중 하나이상 만족하는 커밋을 찾는다. 모두 만족하는 커밋을 찾으려면 `--all-match` 옵션을 추가해야 한다. 마지막으로 파일 경로로 검색하는 옵션이 있는데 이것도 정말 유용하다. 디렉토리나 파일 이름을 사용하여 그 파일이 변경된 log의 결과를 검색할 수 있다. 이 옵션은 `--`와 함께 경로 이름을 사용하는데 명령어 끝 부분에 쓴다(역주, `git log -- path1 path2`). @@ -701,31 +707,32 @@ Insert 18333fig0202.png $ git add . $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + modified: benchmarks.rb + `Changes to be commited` 밑에 `git reset HEAD ...`이라는 문장을 볼 수 있다. 이 명령으로 Unstage 상태로 변경할 수 있다. benchmarks.rb 파일을 Unstage 상태로 변경해보자: $ git reset HEAD benchmarks.rb - benchmarks.rb: locally modified + Unstaged changes after reset: + M benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + 명령어가 낮설게 느껴질 수도 있지만 잘 동작한다. benchmarks.rb 파일은 Unstage 상태가 됐다. @@ -733,23 +740,23 @@ Insert 18333fig0202.png 어떻게 해야 benchmarks.rb 파일을 수정하고 나서 다시 되돌릴 수 있을까? 그러니까 최근 커밋된 버전으로(아니면 처음 Clone했을 때처럼 워킹 디렉토리에 처음 Checkout 한 그 내용으로) 되돌리는 방법이 무얼까? `git status` 명령이 친절하게 알려준다. 바로 위에 있는 예제에서 Unstaged 부분을 보자: - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # modified: benchmarks.rb - # + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + 위의 메시지는 수정한 파일을 되돌리는 방법을 꽤 정확하게 알려준다(적어도 Git 1.6.1이후 버전부터는 그렇다. 만약 예전 것을 아직 사용하고 있으면 업그레드하는 것이 좋다. 편의성이 많이 개선됐다). 알려주는 대로 한 번 해보자: $ git checkout -- benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + 정상적으로 복원된 것을 알 수 있다. 하지만 이 명령은 꽤 위험한 명령이라는 것을 알아야 한다. 수정 이전의 파일로 덮어썼기 때문에 수정했던 내용은 전부 사라진다. 수정한 내용이 진짜 마음에 들지 않을 때에만 사용하자. 정말 이렇게 삭제해야 한다면 Stash와 Branch를 사용하자. 다음 장에서 다루는 이 방법들이 훨씬 낫다. @@ -764,12 +771,12 @@ Git으로 커밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브 `git remote` 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다. 이 명령은 리모트 저장소의 단축 이름을 보여준다. 저장소를 Clone하면 origin이라는 리모트 저장소가 자동으로 등록되기 때문에 origin이라는 이름을 볼 수 있다: $ git clone git://github.com/schacon/ticgit.git - Initialized empty Git repository in /private/tmp/ticgit/.git/ - remote: Counting objects: 595, done. - remote: Compressing objects: 100% (269/269), done. - remote: Total 595 (delta 255), reused 589 (delta 253) - Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done. - Resolving deltas: 100% (255/255), done. + Cloning into 'ticgit'... + remote: Reusing existing pack: 1857, done. + remote: Total 1857 (delta 0), reused 0 (delta 0) + Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done. + Resolving deltas: 100% (772/772), done. + Checking connectivity... done. $ cd ticgit $ git remote origin @@ -942,6 +949,7 @@ Annotated 태그를 만드는 방법은 간단하다. `tag` 명령을 실행할 Date: Mon Feb 9 14:45:11 2009 -0800 my version 1.4 + commit 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon diff --git a/ko/03-git-branching/01-chapter3.markdown b/ko/03-git-branching/01-chapter3.markdown index cf5dade52..6b52978ce 100644 --- a/ko/03-git-branching/01-chapter3.markdown +++ b/ko/03-git-branching/01-chapter3.markdown @@ -104,7 +104,7 @@ Insert 18333fig0309.png 이때 중요한 문제가 생겨서 그것을 해결하는 Hotfix를 먼저 만들어야 한다. 그러면 다음과 같이 할 수 있다: -1. 새로운 이슈를 처리하기 이전의 운영(Production) 브랜치로 복원. +1. 새로운 이슈를 처리하기 이전의 운영(Production) 브랜치로 이동. 2. Hotfix 브랜치를 새로 하나 생성. 3. 수정한 Hotfix 테스트를 마치고 운영 브랜치로 Merge. 4. 다시 작업하던 브랜치로 옮겨가서 하던 일 진행. @@ -154,8 +154,8 @@ hotfix라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사 Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'fixed the broken email address' - [hotfix]: created 3a0874c: 'fixed the broken email address' - 1 files changed, 0 insertions(+), 1 deletions(-) + [hotfix 3a0874c] fixed the broken email address + 1 files changed, 1 deletion(-) Insert 18333fig0313.png 그림 3-13. master 브랜치에서 갈라져 나온 hotfix 브랜치 @@ -165,11 +165,11 @@ Insert 18333fig0313.png $ git checkout master $ git merge hotfix Updating f42c576..3a0874c - Fast forward - README | 1 - - 1 files changed, 0 insertions(+), 1 deletions(-) + Fast-forward + README | 1 - + 1 file changed, 1 deletion(-) -Merge 메시지에서 'Fast forward'가 보이는가? Merge할 브랜치가 가리키고 있던 커밋이 현 브랜치가 가리키는 것보다 '앞으로 진행한' 커밋이기 때문에 master 브랜치 포인터는 최신 커밋으로 이동한다. 이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해서 A 브랜치에서 다른 B 브랜치를 Merge할 때 B가 A 이후의 커밋을 가리키고 있으면 그저 A가 B의 커밋을 가리키게 할 뿐이다. +Merge 메시지에서 'Fast-forward'가 보이는가? Merge할 브랜치가 가리키고 있던 커밋이 현 브랜치가 가리키는 것보다 '앞으로 진행한' 커밋이기 때문에 master 브랜치 포인터는 최신 커밋으로 이동한다. 이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해서 A 브랜치에서 다른 B 브랜치를 Merge할 때 B가 A 이후의 커밋을 가리키고 있으면 그저 A가 B의 커밋을 가리키게 할 뿐이다. 이제 hotfix는 master 브랜치에 포함됐고 운영환경에 적용할 수 있다(그림 3-14). @@ -179,7 +179,7 @@ Insert 18333fig0314.png 문제를 급히 해결하고 master 브랜치에 적용하고 나면 다시 일하던 브랜치로 돌아가야 한다. 하지만, 그전에 필요없는 hotfix 브랜치를 삭제한다. `git branch` 명령에 `-d` 옵션을 주고 브랜치를 삭제한다. $ git branch -d hotfix - Deleted branch hotfix (3a0874c). + Deleted branch hotfix (was 3a0874c). 자 이제 이슈 53번을 처리하던 환경으로 되돌아가서 하던 일을 계속 하자(그림 3-15): @@ -187,8 +187,8 @@ Insert 18333fig0314.png Switched to branch 'iss53' $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' - [iss53]: created ad82d7a: 'finished the new footer [issue 53]' - 1 files changed, 1 insertions(+), 0 deletions(-) + [iss53 ad82d7a] finished the new footer [issue 53] + 1 file changed, 1 insertion(+) Insert 18333fig0315.png 그림 3-15. master와 별개로 진행하는 iss53 브랜치 @@ -201,9 +201,10 @@ Insert 18333fig0315.png $ git checkout master $ git merge iss53 - Merge made by recursive. - README | 1 + - 1 files changed, 1 insertions(+), 0 deletions(-) + Auto-merging README + Merge made by the 'recursive' strategy. + README | 1 + + 1 file changed, 1 insertion(+) hotfix를 Merge했을 때와 메시지가 다르다. 현 브랜치가 가리키는 커밋이 Merge할 브랜치의 조상이 아니므로 Git은 'Fast-forward'로 Merge하지 않는다. 이러면 Git은 각 브랜치가 가리키는 커밋 두 개와 공통 조상 하나를 사용하여 3-way Merge를 한다. 그림 3-16에 이 Merge에서 사용하는 커밋 세 개가 표시된다. @@ -232,25 +233,27 @@ iss53 브랜치를 master에 Merge하고 나면 더는 iss53 브랜치가 필요 Git은 자동으로 Merge하지 못해서 새 커밋이 생기지 않는다. 변경사항의 충돌을 개발자가 해결하지 않는 한 Merge 과정을 진행할 수 없다. Merge 충돌이 일어났을 때 Git이 어떤 파일을 Merge할 수 없었는지 살펴보려면 `git status` 명령을 이용한다: - [master*]$ git status - index.html: needs merge - # On branch master - # Changes not staged for commit: - # (use 'git add ...' to update what will be committed) - # (use 'git checkout -- ...' to discard changes in working directory) - # - # unmerged: index.html - # + $ git status + On branch master + You have unmerged paths. + (fix conflicts and run "git commit") + + Unmerged paths: + (use "git add ..." to mark resolution) + + both modified: index.html + + no changes added to commit (use "git add" and/or "git commit -a") 충돌이 일어난 파일은 unmerged 상태로 표시된다. Git은 충돌이 난 부분을 표준 형식에 따라 표시해준다. 그러면 개발자는 해당 부분을 수동으로 해결한다. 충돌 난 부분은 다음과 같이 표시된다. - <<<<<<< HEAD:index.html + <<<<<<< HEAD ======= - >>>>>>> iss53:index.html + >>>>>>> iss53 `=======` 위쪽의 내용은 HEAD 버전(merge 명령을 실행할 때 작업하던 master 브랜치)의 내용이고 아래쪽은 iss53 브랜치의 내용이다. 충돌을 해결하려면 위쪽이나 아래쪽 내용 중에서 고르거나 새로 작성하여 Merge한다. 다음은 아예 새로 작성하여 충돌을 해결하는 예제다: @@ -261,27 +264,32 @@ Git은 자동으로 Merge하지 못해서 새 커밋이 생기지 않는다. 변 충돌한 양쪽에서 조금씩 가져와서 새로 수정했다. 그리고 `<<<<<<<`, `=======`, `>>>>>>>` 가 포함된 행을 삭제하였다. 이렇게 충돌한 부분을 해결하고 `git add` 명령으로 다시 Git에 저장한다. 충돌을 쉽게 해결하기 위해 다른 Merge 도구도 이용할 수 있다. `git mergetool` 명령으로 실행한다: $ git mergetool - merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff - Merging the files: index.html + + This message is displayed because 'merge.tool' is not configured. + See 'git mergetool --tool-help' or 'git help config' for more details. + 'git mergetool' will now attempt to use one of the following tools: + opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge + Merging: + index.html Normal merge conflict for 'index.html': - {local}: modified - {remote}: modified + {local}: modified file + {remote}: modified file Hit return to start merge resolution tool (opendiff): -Mac에서는 `opendiff`가 실행된다. 기본 도구 말고 사용할 수 있는 다른 Merge 도구도 있는데, 'merge tool candidates' 부분에 보여준다. 여기에 표시된 도구 중 하나를 고를 수 있다. Merge 도구를 변경하는 방법은 *7장*에서 다룬다. +Mac에서는 `opendiff`가 실행된다. 기본 도구 말고 사용할 수 있는 다른 Merge 도구도 있는데, "... one of the following tools:" 부분에 보여준다. 여기에 표시된 도구 중 하나를 고를 수 있다. Merge 도구를 변경하는 방법은 *7장*에서 다룬다. Merge 도구를 종료하면 Git은 잘 Merge했는지 물어본다. 잘 마쳤다고 입력하면 자동으로 `git add`가 수행되고 해당 파일이 Staging Area에 저장된다. `git status` 명령으로 충돌이 해결된 상태인지 다시 한번 확인해볼 수 있다. $ git status - # On branch master - # Changes to be committed: - # (use 'git reset HEAD ...' to unstage) - # - # modified: index.html - # + On branch master + Changes to be committed: + (use 'git reset HEAD ...' to unstage) + + modified: index.html + 충돌을 해결하고 나서 해당 파일이 Staging Area에 저장됐는지 확인했으면 `git commit` 명령으로 Merge 한 것을 커밋한다. 충돌을 해결하고 Merge할 때에는 커밋 메시지가 아래와 같다. @@ -290,9 +298,9 @@ Merge 도구를 종료하면 Git은 잘 Merge했는지 물어본다. 잘 마쳤 Conflicts: index.html # - # It looks like you may be committing a MERGE. + # It looks like you may be committing a merge. # If this is not correct, please remove the file - # .git/MERGE_HEAD + # .git/MERGE_HEAD # and try again. # @@ -332,7 +340,7 @@ iss53 브랜치는 앞에서 이미 Merge했기 때문에 목록에 나타난다 위에는 없었던 다른 브랜치가 보인다. 아직 Merge하지 않은 커밋을 담고 있기 때문에 `git branch -d` 명령으로 삭제되지 않는다: $ git branch -d testing - error: The branch 'testing' is not an ancestor of your current HEAD. + error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. Merge하지 않은 브랜치를 강제로 삭제하려면 `-D` 옵션으로 삭제한다. @@ -445,7 +453,7 @@ Git은 serverfix라는 브랜치 이름을 `refs/heads/serverfix:refs/heads/serv 새로 받은 브랜치의 내용을 Merge하려면 `git merge origin/serverfix` 명령을 사용한다. Merge하지 않고 리모트 브랜치에서 시작하는 새 브랜치를 만들려면 아래와 같은 명령을 사용한다. $ git checkout -b serverfix origin/serverfix - Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. + Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' 그러면 origin/serverfix에서 시작하고 수정할 수 있는 serverfix라는 로컬 브랜치가 만들어진다. @@ -457,16 +465,16 @@ Git은 serverfix라는 브랜치 이름을 `refs/heads/serverfix:refs/heads/serv 서버로부터 저장소를 Clone해올 때도 Git은 자동으로 master 브랜치를 origin/master 브랜치의 트래킹 브랜치로 만든다. 그래서 `git push`, `git pull` 명령이 추가적인 아규먼트 없이도 동작한다. 트래킹 브랜치를 직접 만들 수 있는데 origin/master뿐만 아니라 다른 저장소의 다른 브랜치도 추적하게(Tracking) 할 수 있다. `git checkout -b [branch] [remotename]/[branch]` 명령으로 간단히 트래킹 브랜치를 만들 수 있다. Git 1.6.2 버전 이상을 사용하는 경우에는 --track 옵션도 사용할 수 있다. $ git checkout --track origin/serverfix - Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. + Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' 리모트 브랜치와 다른 이름으로 브랜치를 만들려면 로컬 브랜치의 이름을 아래와 같이 다르게 지정한다: $ git checkout -b sf origin/serverfix - Branch sf set up to track remote branch refs/remotes/origin/serverfix. + Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' -이제 sf 브랜치에서 Push나 Pull하면 자동으로 origin/serverfix에 데이터를 보내거나 가져온다. +이제 `sf` 브랜치에서 Push나 Pull하면 자동으로 `origin/serverfix`에 데이터를 보내거나 가져온다. ### 리모트 브랜치 삭제 ### diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown index 1f57aa7b7..ff28be894 100644 --- a/ko/04-git-server/01-chapter4.markdown +++ b/ko/04-git-server/01-chapter4.markdown @@ -26,7 +26,7 @@ HTTP 프로토콜을 제외한 나머지들은 모두 Git이 서버에 설치돼 $ git clone file:///opt/git/project.git -Git은 파일 경로를 직접 쓸 때와 `file://`로 시작하는 URL을 사용할 때에 약간 다르게 처리한다. 디렉토리 경로를 그대로 사용하면 Git은 필요한 파일을 직접 복사하거나 하드 링크를 사용한다. 하지만 `file://`로 시작하면 Git은 네트워크를 통해서 데이터를 전송할 때처럼 프로세스를 별도로 생성하여 처리한다. 이 프로세스로 데이터를 전송하는 것은 효율이 좀 떨어지지만 그래도 `file://`를 사용하는 이유가 있다. 보통은 다른 버전 관리 시스템들에서 임포트한 후에 이렇게 사용하는데, 외부 레퍼런스나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨두고자 할때 사용한다(*9장*에서 자세히 다룬다). 여기서는 속도가 빠른 디렉토리 경로를 사용한다. +Git은 파일 경로를 직접 쓸 때와 `file://`로 시작하는 URL을 사용할 때에 약간 다르게 처리한다. 디렉토리 경로를 사용해서 같은 파일시스템에 있는 저장소를 Clone할 때 Git은 하드링크를 만든다. 같은 파일시스템에 있는게 아니면 그냥 복사한다. 하지만 `file://`로 시작하면 Git은 네트워크를 통해서 데이터를 전송할 때처럼 프로세스를 별도로 생성하여 처리한다. 이 프로세스로 데이터를 전송하는 것은 효율이 좀 떨어지지만 그래도 `file://`를 사용하는 이유가 있다. 보통은 다른 버전 관리 시스템들에서 임포트한 후에 이렇게 사용하는데, 외부 레퍼런스나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨두고자 할때 사용한다(*9장*에서 자세히 다룬다). 여기서는 속도가 빠른 디렉토리 경로를 사용한다. 이미 있는 Git 프로젝트에서 아래와 같이 로컬 저장소를 추가한다: @@ -70,7 +70,7 @@ SSH의 단점은 익명으로 접근할 수 없다는 것이다. 심지어 읽 ### Git 프로토콜 ### -Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-daemon-export-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다. +Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다. #### 장점 #### @@ -115,7 +115,13 @@ HTTP는 매우 보편적인 프로토콜이라서 거의 모든 회사가 트래 어떤 서버를 설치하더라도 일단 저장소를 Bare 저장소로 만들어야 한다. 다시 말하지만, Bare 저장소는 워킹 디렉토리가 없는 저장소이다. `--bare` 옵션을 주고 Clone하면 새로운 Bare 저장소가 만들어진다. Bare 저장소 디렉토리는 관례에 따라. git 확장자로 끝난다: $ git clone --bare my_project my_project.git - Initialized empty Git repository in /opt/projects/my_project.git/ + Cloning into bare repository 'my_project.git'... + done. + + 이 명령이 출력하는 메시지가 조금 이상해보일 수도 있다. 사실 `git clone` 명령은 `git init`을 하고 나서 `git fetch`를 실행한다. 그런데 빈 디렉토리밖에 만들지 않는 `git init` 명령의 메시지만 보여준다. 개체 전송에 관련된 메시지는 아무것도 보여주지 않는다. 전송 메시지를 보여주지 않지만 `my_project.git` 디렉토리를 보면 Git 데이터가 들어 있다. @@ -282,6 +288,13 @@ something, something.pub이라는 형식으로 된 파일을 볼 수 있다. som $ cat .git/hooks/post-update #!/bin/sh + # + # An example hook script to prepare a packed repository for use over + # dumb transports. + # + # To enable this hook, rename this file to "post-update". + # + exec git-update-server-info SSH를 통해서 서버에 Push하면 Git은 이 명령어를 실행하여 HTTP를 통해서도 Fetch할 수 있도록 파일를 갱신한다. @@ -363,7 +376,7 @@ Gitosis는 Python이 필요하기 때문에 먼저 Python setuptools 패키지 그리고 Gitosis 프로젝트 사이트에서 Gitosis를 Clone한 후 설치한다: - $ git clone git://eagain.net/gitosis.git + $ git clone https://github.com/tv42/gitosis.git $ cd gitosis $ sudo python setup.py install @@ -397,6 +410,7 @@ Gitosis가 키들을 관리할 것이기 때문에 현재 파일은 삭제하고 $ ssh git@gitserver PTY allocation request failed on channel 0 + ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. fatal: unrecognized command 'gitosis-serve schacon@quaternion' Connection to gitserver closed. @@ -421,8 +435,8 @@ Gitosis가 키들을 관리할 것이기 때문에 현재 파일은 삭제하고 [gitosis] [group gitosis-admin] - writable = gitosis-admin members = scott + writable = gitosis-admin scott이라는 사용자는 Gitosis를 초기화할 때 사용한 공개키의 사용자이다. 이 사용자만 `gitosis-admin` 프로젝트에 접근할 수 있다. @@ -435,14 +449,14 @@ scott이라는 사용자는 Gitosis를 초기화할 때 사용한 공개키의 `gitosis-admin` 프로젝트를 수정하면 커밋하고 서버에 Push해야 수정한 설정이 적용된다: $ git commit -am 'add iphone_project and mobile group' - [master]: created 8962da8: "changed name" - 1 files changed, 4 insertions(+), 0 deletions(-) - $ git push + [master 8962da8] add iphone_project and mobile group + 1 file changed, 4 insertions(+) + $ git push origin master Counting objects: 5, done. - Compressing objects: 100% (2/2), done. - Writing objects: 100% (3/3), 272 bytes, done. - Total 3 (delta 1), reused 0 (delta 0) - To git@gitserver:/opt/git/gitosis-admin.git + Compressing objects: 100% (3/3), done. + Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:gitosis-admin.git fb27aec..8962da8 master -> master 로컬에 있는 `iphone_project` 프로젝트에 이 서버를 리모트 저장소로 추가하고 Push하면 서버에 새로운 저장소가 추가된다. 서버에 프로젝트를 새로 만들 때 이제는 수동으로 Bare 저장소를 만들 필요가 없다. 처음 Push할 때 Gitosis가 알아서 생성해 준다: @@ -451,7 +465,7 @@ scott이라는 사용자는 Gitosis를 초기화할 때 사용한 공개키의 $ git push origin master Initialized empty Git repository in /opt/git/iphone_project.git/ Counting objects: 3, done. - Writing objects: 100% (3/3), 230 bytes, done. +> Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gitserver:iphone_project.git * [new branch] master -> master @@ -467,20 +481,20 @@ Gitosis를 이용할 때에는 저장소 경로를 명시할 필요도 없고 이 세 사람을 모두 mobile 팀으로 추가하여 `iphone_project` 에 대한 읽기, 쓰기를 허용한다: [group mobile] - writable = iphone_project members = scott john josie jessica + writable = iphone_project 이 파일을 커밋하고 Push하고 나면 네 명 모두 `iphone_project`를 읽고 쓸 수 있게 된다. Gitosis의 접근제어 방법은 매우 단순하다. 만약 이 프로젝트에 대해서 John은 읽기만 가능하도록 설정하려면 아래와 같이 한다: [group mobile] - writable = iphone_project members = scott josie jessica + writable = iphone_project [group mobile_ro] - readonly = iphone_project members = john + readonly = iphone_project 이제 John은 프로젝트를 Clone하거나 Fetch할 수는 있지만, 프로젝트에 Push할 수는 없다. 다양한 사용자와 프로젝트가 있어도 필요한 만큼 그룹을 만들어 사용하면 된다. 그리고 members 항목에 사용자 대신 그룹명을 사용할 수도 있다. 그룹명 앞에 `@`를 붙이면 그 그룹의 사용자를 그대로 상속한다: @@ -488,12 +502,12 @@ Gitosis의 접근제어 방법은 매우 단순하다. 만약 이 프로젝트 members = scott josie jessica [group mobile] - writable = iphone_project members = @mobile_committers + writable = iphone_project [group mobile_2] - writable = another_iphone_project members = @mobile_committers john + writable = another_iphone_project `[gitosis]` 절에 `loglevel=DEBUG`라고 적으면 문제가 생겼을 때 해결하는데 도움이 된다. 그리고 설정이 꼬여버려서 Push할 수 없게 되면 서버에 있는 파일을 수동으로 고쳐도 된다. Gitosis는 `/home/git/.gitosis.conf` 파일의 정보를 읽기 때문에 이 파일을 고친다. `gitosis.conf`는 Push할 때 그 위치로 복사되기 때문에 수동으로 고친 파일은 `gitosis-admin` 프로젝트가 다음에 Push될 때까지 유지된다. diff --git a/ko/05-distributed-git/01-chapter5.markdown b/ko/05-distributed-git/01-chapter5.markdown index 11ec5df3c..acbe5dc68 100644 --- a/ko/05-distributed-git/01-chapter5.markdown +++ b/ko/05-distributed-git/01-chapter5.markdown @@ -169,7 +169,7 @@ John씨는 Jessica씨가 저장소로 Push했던 커밋과 를 로컬 저장소 Merge가 잘 이루어지면 John씨의 브랜치는 그림 5-5와 같은 상태가 된다. Insert 18333fig0505.png -그림 5-5. origin/master 브랜치를 Merge하고 난 후, John씨의 저장소 +그림 5-5. `origin/master` 브랜치를 Merge하고 난 후, John씨의 저장소 John씨는 Merge하고 나서 자신이 작업한 코드가 제대로 동작하는지 확인한다. 그 후에 공유하는 저장소에 Push한다: @@ -210,13 +210,13 @@ Insert 18333fig0508.png removed invalid default value -Merge할 내용을 확인한 Jessica씨는 자신이 작업한 내용과 John씨가 Push한 작업(origin/master)을 master 브랜치에 Merge하고 Push한다. 모든 내용을 합치기 전에 우선 master 브랜치를 Checkout한다: +Merge할 내용을 확인한 Jessica씨는 자신이 작업한 내용과 John씨가 Push한 작업(`origin/master`)을 `master` 브랜치에 Merge하고 Push한다. 모든 내용을 합치기 전에 우선 `master` 브랜치를 Checkout한다: $ git checkout master Switched to branch "master" Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. -origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때문에 둘 중에 무엇을 먼저 Merge하든 상관이 없다. 물론 어떤 것을 먼저 Merge하느냐에 따라 히스토리 순서는 달라지지만, 최종 결과는 똑같다. Jessica씨는 먼저 issue54 브랜치를 Merge한다: +`origin/master`, `issue54` 모두 `master`보다 Fast-forward된 브랜치이기 때문에 둘 중에 무엇을 먼저 Merge하든 상관이 없다. 물론 어떤 것을 먼저 Merge하느냐에 따라 히스토리 순서는 달라지지만, 최종 결과는 똑같다. Jessica씨는 먼저 `issue54` 브랜치를 Merge한다: $ git merge issue54 Updating fbff5bc..4af4298 @@ -225,7 +225,7 @@ origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때 lib/simplegit.rb | 6 +++++- 2 files changed, 6 insertions(+), 1 deletions(-) -보다시피 Fast-forward Merge이기 때문에 별 문제 없이 실행된다. 다음은 John씨의 커밋(origin/master)을 Merge한다: +보다시피 Fast-forward Merge이기 때문에 별 문제 없이 실행된다. 다음은 John씨의 커밋(`origin/master`)을 Merge한다: $ git merge origin/master Auto-merging lib/simplegit.rb @@ -238,7 +238,7 @@ origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때 Insert 18333fig0509.png 그림 5-9. Merge 이후 Jessica씨의 저장소 -origin/master 브랜치가 Jessica씨의 master 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John씨가 그 사이에 Push를 하지 않았다면): +`origin/master` 브랜치가 Jessica씨의 `master` 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John씨가 그 사이에 Push를 하지 않았다면): $ git push origin master ... @@ -250,7 +250,7 @@ origin/master 브랜치가 Jessica씨의 master 브랜치로 나아갈(reachable Insert 18333fig0510.png 그림 5-10. Jessica씨가 서버로 Push하고 난 후의 저장소 -여기서 살펴본 예제가 가장 간단한 상황이다. 토픽 브랜치에서 수정하고 로컬의 master 브랜치에 Merge한다. 작업한 내용을 프로젝트의 공유 저장소에 Push하고자 할 때에는 우선 origin/master 브랜치를 Fetch하고 Merge한다. 그리고 나서 Merge한 결과를 다시 서버로 Push한다. 이런 Workflow가 일반적이고 그림 5-11로 나타낼 수 있다. +여기서 살펴본 예제가 가장 간단한 상황이다. 토픽 브랜치에서 수정하고 로컬의 `master` 브랜치에 Merge한다. 작업한 내용을 프로젝트의 공유 저장소에 Push하고자 할 때에는 우선 `origin/master` 브랜치를 Fetch하고 Merge한다. 그리고 나서 Merge한 결과를 다시 서버로 Push한다. 이런 Workflow가 일반적이고 그림 5-11로 나타낼 수 있다. Insert 18333fig0511.png 그림 5-11. 여러 개발자가 Git을 사용하는 Workflow @@ -518,7 +518,7 @@ format-patch 명령을 실행하면 생성한 파일 이름을 보여준다. -M 다행히 Git에는 Patch 메일을 그대로 보낼 수 있는 도구가 있다. IMAP 프로토콜로 보낸다. 저자가 사용하는 방법으로 Gmail을 사용하여 Patch 메일을 전송하는 방법을 살펴보자. 추가로 Git 프로젝트의 `Documentation/SubmittingPatches` 문서의 마지막 부분을 살펴보면 다양한 메일 프로그램으로 메일을 보내는 방법을 설명한다. -메일을 보내려면 먼저 ~/.gitconfig 파일에서 이메일 부분 설정한다. `git config` 명령으로 추가할 수도 있고 직접 파일을 열어서 추가할 수도 있다. 아무튼, 아래와 같이 설정을 한다: +메일을 보내려면 먼저 `~/.gitconfig` 파일에서 이메일 부분 설정한다. `git config` 명령으로 추가할 수도 있고 직접 파일을 열어서 추가할 수도 있다. 아무튼, 아래와 같이 설정을 한다: [imap] folder = "[Gmail]/Drafts" @@ -528,7 +528,26 @@ format-patch 명령을 실행하면 생성한 파일 이름을 보여준다. -M port = 993 sslverify = false -IMAP 서버가 SSL을 사용하지 않으면 마지막 두 줄은 필요 없고 host에서 `imaps://` 대신 `imap://`로 한다. 이렇게 설정하면 `git send-email` 명령으로 메일을 전송할 수 있다: +IMAP 서버가 SSL을 사용하지 않으면 마지막 두 줄은 필요 없고 host에서 `imaps://` 대신 `imap://`로 한다. 이렇게 설정하면 `git imap-send` 명령으로 메일을 전송할 수 있다: + + $ cat *.patch |git imap-send + Resolving imap.gmail.com... ok + Connecting to [74.125.142.109]:993... ok + Logging in... + sending 2 messages + 100% (2/2) done + +이후 Gmail의 Draft 폴더로 가서 To 부분을 메일링리스트의 주소로 변경하고 CC 부분에 해당 메일을 참고해야 하는 관리자나 개발자의 메일 주소를 적고 실제로 전송한다. + +SMTP 서버로도 패치를 보낼 수 있다. `git config` 명령으로 설정을 하나씩 입력하거나 `~/.gitconfig` 파일의 sendmail 부분을 손으로 직접 수정한다: + + [sendemail] + smtpencryption = tls + smtpserver = smtp.gmail.com + smtpuser = user@gmail.com + smtpserverport = 587 + +이렇게 했으면 `git send-mail`로 패치를 보낸다: $ git send-email *.patch 0001-added-limit-to-log-function.patch @@ -555,8 +574,6 @@ Git으로 메일을 보내면 아래와 같은 로그 메시지가 출력된다: Result: OK -이후 Gmail의 Draft 폴더로 가서 To 부분을 메일링리스트의 주소로 변경하고 CC 부분에 해당 메일을 참고해야 하는 관리자나 개발자의 메일 주소를 적고 실제로 전송한다. - ### 요약 ### 이번 절에서는 다양한 Workflow에 따라 Git을 어떻게 사용하는 지 살펴보고 그에 필요한 도구들을 설명했다. 다음 절에서는 동전의 뒷면인 프로젝트를 운영하는 방법에 대하여 살펴본다. 즉 친절한 Dictator나 Integration-Manager가 되어 보는 것이다. diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown index af810484d..231d2dc8c 100644 --- a/ko/06-git-tools/01-chapter6.markdown +++ b/ko/06-git-tools/01-chapter6.markdown @@ -82,13 +82,13 @@ Git은 자동으로 브랜치와 HEAD가 지난 몇 달 동안에 가리켰었 `git reflog`를 실행하면 Reflog를 볼 수 있다: $ git reflog - 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated - d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. - 1c002dd... HEAD@{2}: commit: added some blame and merge stuff - 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD - 95df984... HEAD@{4}: commit: # This is a combination of two commits. - 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD - 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD + 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated + d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. + 1c002dd HEAD@{2}: commit: added some blame and merge stuff + 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD + 95df984 HEAD@{4}: commit: # This is a combination of two commits. + 1c36188 HEAD@{5}: rebase -i (squash): updating HEAD + 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD Git은 브랜치가 가리키는 것이 변경될 때마다 그 정보를 임시 영역에 저장한다. 그래서 예전에 뭘 가리켰었는지 확인할 수 있다. `@{n}` 규칙을 사용하면 아래와 같이 HEAD가 5번 전에 가리켰던 것을 알 수 있다: @@ -442,8 +442,8 @@ Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일만 저 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log Stash 두 개는 원래 있었던 것이다. 그래서 현재 총 세 개의 Stash를 사용할 수 있다. 이제 `git stash apply`를 사용하여 Stash를 적용할 수 있다. `git stash` 명령을 실행하면 이 명령에 대한 도움말을 보여주기 때문에 편리하다. 다른 Stash를 고르고 싶으면 Stash 이름을 입력해야 한다. 이름이 없으면 Git은 가장 최근의 Stash를 적용한다: @@ -477,8 +477,8 @@ Git은 Stash를 적용할 때 Staged 상태였던 파일을 자동으로 다시 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) @@ -562,12 +562,19 @@ Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해 # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out 이 커밋은 모두 `log` 명령과는 정반대의 순서로 나열된다. `log` 명령을 실행하면 아래와 같은 결과를 볼 수 있다: @@ -586,6 +593,10 @@ Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해 저장하고 편집기를 종료하면 Git은 목록에 있는 커밋 중에서 가장 오래된 커밋으로 이동하고, 아래와 같은 메시지를 보여주고, 명령 프롬프트를 보여준다: + + $ git rebase -i HEAD~3 Stopped at 7482e0d... updated the gemspec to hopefully work better You can amend the commit now, with @@ -628,12 +639,19 @@ Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해 # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out "pick"이나 "edit"말고 "squash"를 입력하면 Git은 해당 커밋과 바로 이전 커밋을 합칠 것이고 커밋 메시지도 Merge한다. 그래서 3개의 커밋을 모두 합치려면 스크립트를 아래와 같이 수정한다: diff --git a/ko/07-customizing-git/01-chapter7.markdown b/ko/07-customizing-git/01-chapter7.markdown index 8e363021f..901c2d27c 100644 --- a/ko/07-customizing-git/01-chapter7.markdown +++ b/ko/07-customizing-git/01-chapter7.markdown @@ -612,14 +612,12 @@ update 스크립트는 각 브랜치마다 한 번씩 실행된다는 것을 제 #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -쉽게 설명하기 위해 전역 변수를 사용했다. 비판하지 말기 바란다. + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### 커밋 메시지 규칙 만들기 #### From 7092f297fd9c73108d588a9bc5d1ce8a7bce000a Mon Sep 17 00:00:00 2001 From: "Larry Shatzer, Jr" Date: Fri, 30 May 2014 14:14:50 -0600 Subject: [PATCH 041/291] Markup fixes. --- en/01-introduction/01-chapter1.markdown | 8 ++++---- en/03-git-branching/01-chapter3.markdown | 4 ++-- en/05-distributed-git/01-chapter5.markdown | 2 +- en/07-customizing-git/01-chapter7.markdown | 2 +- en/08-git-and-other-scms/01-chapter8.markdown | 8 ++++---- en/09-git-internals/01-chapter9.markdown | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index e30752b7f..b82705a07 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -102,7 +102,7 @@ Now, pay attention. This is the main thing to remember about Git if you want the This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. Insert 18333fig0106.png -Figure 1-6. Working directory, staging area, and git directory. +Figure 1-6. Working directory, staging area, and Git directory. The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. @@ -116,7 +116,7 @@ The basic Git workflow goes something like this: 2. You stage the files, adding snapshots of them to your staging area. 3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. -If a particular version of a file is in the git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. +If a particular version of a file is in the Git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. ## Installing Git ## @@ -188,11 +188,11 @@ Note on Windows usage: you should use Git with the provided msysGit shell (Unix Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. -Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: +Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: * `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. * `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. -* config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +* config file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown index 0ab31e938..adf1995d1 100644 --- a/en/03-git-branching/01-chapter3.markdown +++ b/en/03-git-branching/01-chapter3.markdown @@ -41,7 +41,7 @@ This creates a new pointer at the same commit you’re currently on (see Figure Insert 18333fig0304.png Figure 3-4. Multiple branches pointing into the commit’s data history. -How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5). +How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The `git branch` command only created a new branch — it didn’t switch to that branch (see Figure 3-5). Insert 18333fig0305.png Figure 3-5. HEAD file pointing to the branch you’re on. @@ -404,7 +404,7 @@ Figure 3-23. Working locally and having someone push to your remote server makes To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24). Insert 18333fig0324.png -Figure 3-24. The git fetch command updates your remote references. +Figure 3-24. The `git fetch` command updates your remote references. To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25). diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown index af0ae4ad2..a4d821de9 100644 --- a/en/05-distributed-git/01-chapter5.markdown +++ b/en/05-distributed-git/01-chapter5.markdown @@ -611,7 +611,7 @@ If you received the patch from someone who generated it with the `git diff` or a This modifies the files in your working directory. It’s almost identical to running a `patch -p1` command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches than patch. It also handles file adds, deletes, and renames if they’re described in the `git diff` format, which `patch` won’t do. Finally, `git apply` is an "apply all or abort all" model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. `git apply` is overall much more paranoid than `patch`. It won’t create a commit for you — after running it, you must stage and commit the changes introduced manually. -You can also use git apply to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch: +You can also use `git apply` to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch: $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index b1dbaa989..e77128dd8 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -511,7 +511,7 @@ For example, say you have some test files in a `test/` subdirectory, and it does test/ export-ignore -Now, when you run git archive to create a tarball of your project, that directory won’t be included in the archive. +Now, when you run `git archive` to create a tarball of your project, that directory won’t be included in the archive. #### export-subst #### diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown index 4e6671c27..a270b14e3 100644 --- a/en/08-git-and-other-scms/01-chapter8.markdown +++ b/en/08-git-and-other-scms/01-chapter8.markdown @@ -202,7 +202,7 @@ Running `git svn rebase` every once in a while makes sure your code is always up ### Git Branching Issues ### -When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via git svn, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so git svn follows only the first parent when converting the snapshots into Subversion commits. +When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via `git svn`, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so `git svn` follows only the first parent when converting the snapshots into Subversion commits. Suppose your history looks like the following: you created an `experiment` branch, did two commits, and then merged them back into `master`. When you `dcommit`, you see output like this: @@ -231,7 +231,7 @@ When someone else clones that work, all they see is the merge commit with all th ### Subversion Branching ### -Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using git svn. +Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using `git svn`. #### Creating a New SVN Branch #### @@ -499,7 +499,7 @@ To quickly demonstrate, you’ll write a simple importer. Suppose you work in cu In order to import a Git directory, you need to review how Git stores its data. As you may remember, Git is fundamentally a linked list of commit objects that point to a snapshot of content. All you have to do is tell `fast-import` what the content snapshots are, what commit data points to them, and the order they go in. Your strategy will be to go through the snapshots one at a time and create commits with the contents of each directory, linking each commit back to the previous one. -As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you’ll need to take special care to not introduce carriage returns at the end your lines — git fast-import is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses. +As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you’ll need to take special care to not introduce carriage returns at the end your lines — `git fast-import` is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses. To begin, you’ll change into the target directory and identify every subdirectory, each of which is a snapshot that you want to import as a commit. You’ll change into each subdirectory and print the commands necessary to export it. Your basic main loop looks like this: @@ -601,7 +601,7 @@ The last thing you need to do is to return the current mark so it can be passed return mark -NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF: +NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while `git fast-import` expects only LF. To get around this problem and make `git fast-import` happy, you need to tell ruby to use LF instead of CRLF: $stdout.binmode diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown index 71d41a932..b638c04b7 100644 --- a/en/09-git-internals/01-chapter9.markdown +++ b/en/09-git-internals/01-chapter9.markdown @@ -27,7 +27,7 @@ When you run `git init` in a new or existing directory, Git creates the `.git` d objects/ refs/ -You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a .gitignore file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7. +You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a `.gitignore` file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7. This leaves four important entries: the `HEAD` and `index` files and the `objects` and `refs` directories. These are the core parts of Git. The `objects` directory stores all the content for your database, the `refs` directory stores pointers into commit objects in that data (branches), the `HEAD` file points to the branch you currently have checked out, and the `index` file is where Git stores your staging area information. You’ll now look at each of these sections in detail to see how Git operates. From fdee83e97c2dea0dc103988f1f0bb4ffeeb435bf Mon Sep 17 00:00:00 2001 From: Xue Fuqiao Date: Sun, 1 Jun 2014 11:14:00 +0800 Subject: [PATCH 042/291] [zh] Synchronize with English version. --- zh/01-introduction/01-chapter1.markdown | 4 ++-- zh/03-git-branching/01-chapter3.markdown | 2 +- zh/07-customizing-git/01-chapter7.markdown | 2 +- zh/08-git-and-other-scms/01-chapter8.markdown | 8 ++++---- zh/09-git-internals/01-chapter9.markdown | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown index cfac13adf..93ceddd73 100644 --- a/zh/01-introduction/01-chapter1.markdown +++ b/zh/01-introduction/01-chapter1.markdown @@ -188,11 +188,11 @@ Insert 18333fig0107.png 一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。 -Git 提供了一个叫做 git config 的工具（译注：实际是 `git-config` 命令，只不过可以通过 `git` 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方： +Git 提供了一个叫做 `git config` 的工具（译注：实际是 `git-config` 命令，只不过可以通过 `git` 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方： * `/etc/gitconfig` 文件：系统中对所有用户都普遍适用的配置。若使用 `git config` 时用 ` --system` 选项，读写的就是这个文件。 * `~/.gitconfig` 文件：用户目录下的配置文件只适用于该用户。若使用 `git config` 时用 ` --global` 选项，读写的就是这个文件。 -* 当前项目的 git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。 +* 当前项目的 Git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。 在 Windows 系统上，Git 会找寻用户主目录下的 `.gitconfig` 文件。主目录即 `$HOME` 变量指定的目录，一般都是 `C:\Documents and Settings\$USER`。此外，Git 还会尝试找寻 `/etc/gitconfig` 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。 diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown index 70473c28e..05bc4817f 100644 --- a/zh/03-git-branching/01-chapter3.markdown +++ b/zh/03-git-branching/01-chapter3.markdown @@ -402,7 +402,7 @@ Insert 18333fig0323.png 可以运行 `git fetch origin` 来同步远程服务器上的数据到本地。该命令首先找到 `origin` 是哪个服务器（本例为 `git.ourcompany.com`），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 `origin/master` 的指针移到它最新的位置上（见图 3-24）。 Insert 18333fig0324.png -图 3-24. git fetch 命令会更新 remote 索引。 +图 3-24. `git fetch` 命令会更新 remote 索引。 为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加为当前项目的远程分支之一。我们把它命名为 `teamone`，以便代替完整的 Git URL 以方便使用（见图 3-25）。 diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 2b4d20121..43ef5f389 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -510,7 +510,7 @@ Git属性在导出项目归档时也能发挥作用。 test/ export-ignore -现在，当运行git archive来创建项目的压缩包时，那个目录不会在归档中出现。 +现在，当运行 `git archive` 来创建项目的压缩包时，那个目录不会在归档中出现。 #### export-subst #### diff --git a/zh/08-git-and-other-scms/01-chapter8.markdown b/zh/08-git-and-other-scms/01-chapter8.markdown index 1aae0d2a3..0110dde53 100644 --- a/zh/08-git-and-other-scms/01-chapter8.markdown +++ b/zh/08-git-and-other-scms/01-chapter8.markdown @@ -202,7 +202,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令 ### Git 分支问题 ### -习惯了 Git 的工作流程以后，你可能会创建一些特性分支，完成相关的开发工作，然后合并他们。如果要用 git svn 向 Subversion 推送内容，那么最好是每次用衍合来并入一个单一分支，而不是直接合并。使用衍合的原因是 Subversion 只有一个线性的历史而不像 Git 那样处理合并，所以 Git svn 在把快照转换为 Subversion 的 commit 时只能包含第一个祖先。 +习惯了 Git 的工作流程以后，你可能会创建一些特性分支，完成相关的开发工作，然后合并他们。如果要用 `git svn` 向 Subversion 推送内容，那么最好是每次用衍合来并入一个单一分支，而不是直接合并。使用衍合的原因是 Subversion 只有一个线性的历史而不像 Git 那样处理合并，所以 `git svn` 在把快照转换为 Subversion 的 commit 时只能包含第一个祖先。 假设分支历史如下：创建一个 `experiment` 分支，进行两次提交，然后合并到 `master` 。在 `dcommit` 的时候会得到如下输出： @@ -231,7 +231,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令 ### Subversion 分支 ### -Subversion 的分支和 Git 中的不尽相同；避免过多的使用可能是最好方案。不过，用 git svn 创建和提交不同的 Subversion 分支仍是可行的。 +Subversion 的分支和 Git 中的不尽相同；避免过多的使用可能是最好方案。不过，用 `git svn` 创建和提交不同的 Subversion 分支仍是可行的。 #### 创建新的 SVN 分支 #### @@ -499,7 +499,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的 为了导入到一个 Git 目录，我们首先回顾一下 Git 储存数据的方式。你可能还记得，Git 本质上是一个 commit 对象的链表，每一个对象指向一个内容的快照。而这里需要做的工作就是告诉 `fast-import` 内容快照的位置，什么样的 commit 数据指向它们，以及它们的顺序。我们采取一次处理一个快照的策略，为每一个内容目录建立对应的 commit ，每一个 commit 与之前的建立链接。 -正如在第七章 "Git 执行策略一例" 一节中一样，我们将使用 Ruby 来编写这个脚本，因为它是我日常使用的语言而且阅读起来简单一些。你可以用任何其他熟悉的语言来重写这个例子——它仅需要把必要的信息打印到标准输出而已。同时，如果你在使用 Windows，这意味着你要特别留意不要在换行的时候引入回车符（译注：carriage returns，Windows 换行时加入的符号，通常说的 `\r` ）—— Git 的 fast-import 对仅使用换行符（LF）而非 Windows 的回车符（CRLF）要求非常严格。 +正如在第七章 "Git 执行策略一例" 一节中一样，我们将使用 Ruby 来编写这个脚本，因为它是我日常使用的语言而且阅读起来简单一些。你可以用任何其他熟悉的语言来重写这个例子——它仅需要把必要的信息打印到标准输出而已。同时，如果你在使用 Windows，这意味着你要特别留意不要在换行的时候引入回车符（译注：carriage returns，Windows 换行时加入的符号，通常说的 `\r` ）—— `git fast-import` 对仅使用换行符（LF）而非 Windows 的回车符（CRLF）要求非常严格。 首先，进入目标目录并且找到所有子目录，每一个子目录将作为一个快照被导入为一个 commit。我们将依次进入每一个子目录并打印所需的命令来导出它们。脚本的主循环大致是这样： @@ -601,7 +601,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的 return mark -注意：如果你在用 Windows，一定记得添加一项额外的步骤。前面提过，Windows 使用 CRLF 作为换行字符而 Git fast-import 只接受 LF。为了绕开这个问题来满足 git fast-import，你需要让 ruby 用 LF 取代 CRLF： +注意：如果你在用 Windows，一定记得添加一项额外的步骤。前面提过，Windows 使用 CRLF 作为换行字符而 `git fast-import` 只接受 LF。为了绕开这个问题来满足 `git fast-import`，你需要让 ruby 用 LF 取代 CRLF： $stdout.binmode diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown index d77f577bc..0c29420fc 100644 --- a/zh/09-git-internals/01-chapter9.markdown +++ b/zh/09-git-internals/01-chapter9.markdown @@ -27,7 +27,7 @@ objects/ refs/ -该目录下有可能还有其他文件，但这是一个全新的 `git init` 生成的库，所以默认情况下这些就是你能看到的结构。新版本的 Git 不再使用 `branches` 目录，`description` 文件仅供 GitWeb 程序使用，所以不用关心这些内容。`config` 文件包含了项目特有的配置选项，`info` 目录保存了一份不希望在 .gitignore 文件中管理的忽略模式 (ignored patterns) 的全局可执行文件。`hooks` 目录保存了第七章详细介绍了的客户端或服务端钩子脚本。 +该目录下有可能还有其他文件，但这是一个全新的 `git init` 生成的库，所以默认情况下这些就是你能看到的结构。新版本的 Git 不再使用 `branches` 目录，`description` 文件仅供 GitWeb 程序使用，所以不用关心这些内容。`config` 文件包含了项目特有的配置选项，`info` 目录保存了一份不希望在 `.gitignore` 文件中管理的忽略模式 (ignored patterns) 的全局可执行文件。`hooks` 目录保存了第七章详细介绍了的客户端或服务端钩子脚本。 另外还有四个重要的文件或目录：`HEAD` 及 `index` 文件，`objects` 及 `refs` 目录。这些是 Git 的核心部分。`objects` 目录存储所有数据内容，`refs` 目录存储指向数据 (分支) 的提交对象的指针，`HEAD` 文件指向当前分支，`index` 文件保存了暂存区域信息。马上你将详细了解 Git 是如何操纵这些内容的。 From adc3ae7adf55d3e51c66cf205094264e5ba82235 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 2 Jun 2014 21:52:19 +0200 Subject: [PATCH 043/291] [fr] Update chapter on diffing --- fr/07-customizing-git/01-chapter7.markdown | 48 ++++++++++++---------- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/fr/07-customizing-git/01-chapter7.markdown b/fr/07-customizing-git/01-chapter7.markdown index e7248a28a..835a4dc3c 100644 --- a/fr/07-customizing-git/01-chapter7.markdown +++ b/fr/07-customizing-git/01-chapter7.markdown @@ -385,12 +385,23 @@ Dans la branche 1.6 de Git, vous pouvez aussi utiliser une macro fournie qui sig #### Comparaison de fichiers binaires #### -Dans la branche 1.6 de Git, vous pouvez utiliser la fonctionnalité des attributs Git pour effectivement comparer les fichiers binaires. +Dans Git, vous pouvez utiliser la fonctionnalité des attributs pour comparer efficacement les fichiers binaires. Pour ce faire, indiquez à Git comment convertir vos données binaires en format texte qui peut être comparé via un diff normal. +Mais le question revient alors à savoir comment convertir les données binaires en texte. +La meilleure solution consiste à trouver un outil qui réalise pour vous la conversion des données binaires en représentation textuelle (imaginez par exemple comment convertir un fichier audio en texte). +Si c'est impossible et qur vous ne parvenez pas à obtenir une réprésentation du contenu sous forme de texte, il reste relativement facile d'obtenir une description dans un format humainement lisible de ce contenu. +Les métadonnées ne vous donneront pas une représentation complète du contenu du fichier, mais c'est en tout cas mieux que rien. + +Nous allons utiliser les deux méthodes précédentes pour obtenir des comparaisons de formats binaires largement utilisés. + +Note : il existe de nombreux types de formats binaires avec du contenu textuel pour lesquels il est difficile de trouver une convertisseur vers du texte. +Dans ces cas, il reste toujours possible d'extraire le texte au moyen du programme `strings`. +Certains de ces fichiers peuvent aussi utiliser une encodage spécifique du texte, comme UTF-16, et `strings` ne trouvera alors rien de probant. +Les résultats sont très variables. +Dans tous les cas, `strings` est disponible sur la plupart des systèmes Mac et Linux, et constitue une bonne option pour un premier essai. ##### Fichiers MS Word ##### -Comme c'est une fonctionnalité plutôt cool et peu connue, nous allons en voir quelques exemples. Premièrement, nous utiliserons cette technique pour résoudre un des problèmes les plus ennuyeux de l'humanité : gérer en contrôle de version les documents Word. Tout le monde convient que Word est l'éditeur de texte le plus horrible qui existe, mais bizarrement, tout le monde persiste à l'utiliser. Si vous voulez gérer en version des documents Word, vous pouvez les coller dans un dépôt Git et les valider de temps à autre. @@ -411,20 +422,17 @@ Ajoutez la ligne suivante dans votre fichier `.gitattributes` : Cette ligne indique à Git que tout fichier correspondant au patron (.doc) doit utiliser le filtre `word` pour visualiser le diff des modifications. Qu'est-ce que le filtre « word » ? Nous devons le définir. -Vous allez configurer Git à utiliser le programme `strings` pour convertir les documents Word en fichiers texte lisibles qu'il pourra alors comparer correctement : +Vous allez indiquer à Git d'utiliser le programme `catdoc` qui a été écrit spécifiquement pour extraire le texte d'un document MS Word. +Vous pouvez l'obtenir depuis `http://www.wagner.pp.ru/~vitus/software/catdoc`. - $ git config diff.word.textconv strings + $ git config diff.word.textconv catdoc Cette commande ajoute à votre fichier `.git/config` une section qui ressemble à ceci : [diff "word"] - textconv = strings - -Note : il existe différents types de fichiers `.doc`. -Certains utilisent un codage UTF-16 ou d'autres pages de codes plus exotiques dans lesquels `strings` ne trouvera aucune chaîne utile. -Le résultat de ce filtre pour vos fichiers dépendra de ces conditions. + textconv = catdoc -À présent, Git sait que s'il essaie de faire un diff entre deux instantanés et qu'un des fichiers finit en `.doc`, il devrait faire passer ces fichiers par le filtre `word` défini comme le programme `strings`. +À présent, Git sait que s'il essaie de faire un diff entre deux instantanés et qu'un des fichiers finit en `.doc`, il devrait faire passer ces fichiers par le filtre `word` défini comme le programme `catdoc`. Cette méthode fait effectivement des jolies versions texte de vos fichiers Word avant d'essayer de les comparer. Voici un exemple. @@ -436,18 +444,14 @@ Puis, j'ai lancé `git diff` pour visualiser ce qui a changé : index c1c8a0a..b93c9e4 100644 --- a/chapter1.doc +++ b/chapter1.doc - @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics - re going to cover how to get it and set it up for the first time if you don - t already have it on your system. - In Chapter Two we will go over basic Git usage - how to use Git for the 80% - -s going on, modify stuff and contribute changes. If the book spontaneously - +s going on, modify stuff and contribute changes. If the book spontaneously - +Let's see if this works. - -Git réussit à m'indiquer succinctement que j'ai ajouté la chaîne « *Let's see if this works* », ce qui est correct. -Ce n'est pas parfait car il y a toujours un tas de données aléatoires à la fin, mais c'est suffisant. -Si vous êtes capable d'écrire un convertisseur Word vers texte qui fonctionne suffisamment bien, cette solution peut s'avérer très efficace. -Cependant, `strings` est disponible sur la plupart des systèmes Mac et Linux et peut donc constituer un bon début pour de nombreux formats binaires. + @@ -128,7 +128,7 @@ and data size) + Since its birth in 2005, Git has evolved and matured to be easy to use + and yet retain these initial qualities. It’s incredibly fast, it’s + very efficient with large projects, and it has an incredible branching + -system for non-linear development. + +system for non-linear development (See Chapter 3). + +Git m'indique succinctement que j'ai ajouté la chaîne « (see Chapter 3) », ce qui est correct. ##### Fichiers OpenDocument texte ##### From 203fe7efccf629cc0ecaa7ace38fffa42ec9a206 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 2 Jun 2014 21:53:47 +0200 Subject: [PATCH 044/291] [fr] sync with 90c92ceb --- fr/08-git-and-other-scms/01-chapter8.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/08-git-and-other-scms/01-chapter8.markdown b/fr/08-git-and-other-scms/01-chapter8.markdown index e7e3ad7ac..f31bf8d22 100644 --- a/fr/08-git-and-other-scms/01-chapter8.markdown +++ b/fr/08-git-and-other-scms/01-chapter8.markdown @@ -456,7 +456,7 @@ Vous pouvez alors fournir ce fichier à `git svn` pour l'aider à convertir les Vous pouvez aussi indiquer à `git svn` de ne pas inclure les méta-données que Subversion importe habituellement en passant l'option `--no-metadata` à la commande `clone` ou `init`. Au final, votre commande d'import ressemble à ceci : - $ git-svn clone http://mon-projet.googlecode.com/svn/ \ + $ git svn clone http://mon-projet.googlecode.com/svn/ \ --authors-file=users.txt --no-metadata -s my_project Maintenant, l'import depuis Subversion dans le répertoire `my_project` est plus présentable. From dae161eb9b4b0f83f0c0f5f5ce9fbbf3e3e90cfd Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 2 Jun 2014 22:05:23 +0200 Subject: [PATCH 045/291] [fr] sync with 21e84add --- fr/02-git-basics/01-chapter2.markdown | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index 1ed5f012e..a52fc4c61 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -1289,8 +1289,7 @@ De nombreuses personnes utilisent parfaitement Git sans connaître aucun de ces ### Auto-Complétion ### Si vous utilisez le shell Bash, Git est livré avec un script d'auto-complétion utile. -Téléchargez le code source de Git, et jetez un œil dans le répertoire `contrib/completion`. -Il devrait y avoir un fichier nommé `git-completion.bash`. +Téléchargez le directement depuis le code source de Git à https://github.com/git/git/blob/master/contrib/git-completion.bash . Copiez ce fichier dans votre répertoire personnel et ajoutez cette ligne à votre fichier `.bashrc` : source ~/.git-completion.bash From 26630312925924dbd75e895558544935a79f6724 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 2 Jun 2014 22:11:03 +0200 Subject: [PATCH 046/291] [fr] sync with 2a0a8371 --- fr/04-git-server/01-chapter4.markdown | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown index 698952413..91238f71c 100644 --- a/fr/04-git-server/01-chapter4.markdown +++ b/fr/04-git-server/01-chapter4.markdown @@ -43,7 +43,8 @@ Ou bien cela : $ git clone file:///opt/git/projet.git Git opère légèrement différemment si vous spécifiez explicitement le protocole `file://` au début de l'URL. -Si vous spécifiez simplement le chemin, Git tente d'utiliser des liens durs ou une copie des fichiers nécessaires. +Si vous spécifiez simplement le chemin et si la destination se trouve sur le même système de fichiers, Git tente d'utiliser des liens durs pour le fichiers communs. +Si la destination se trouve sur un autre système de fichiers, Git fait une copie des fichiers nécessaires. Si vous spécifiez le protocole `file://`, Git lance un processus d'accès au travers du réseau, ce qui est généralement moins efficace. La raison d'utiliser spécifiquement le préfixe `file://` est la volonté d'obtenir une copie propre du dépôt, sans aucune référence ou aucun objet supplémentaire qui pourraient résulter d'un import depuis un autre système de gestion de version ou d'une action similaire (voir chapitre 9 pour les tâches de maintenance). Nous utiliserons les chemins normaux par la suite car c'est la méthode la plus efficace. From 7fc30646d5f26b6271b23eee5500a74602595ec1 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 2 Jun 2014 22:28:46 +0200 Subject: [PATCH 047/291] [fr] apply 15f2bf1b --- fr/05-distributed-git/01-chapter5.markdown | 28 ++++++++++++++++++---- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/fr/05-distributed-git/01-chapter5.markdown b/fr/05-distributed-git/01-chapter5.markdown index 19716edfd..72096ff41 100644 --- a/fr/05-distributed-git/01-chapter5.markdown +++ b/fr/05-distributed-git/01-chapter5.markdown @@ -678,11 +678,31 @@ Vous pouvez positionner ces valeurs séparément avec une série de commandes `g sslverify = false Si votre serveur IMAP n'utilise pas SSL, les deux dernières lignes ne sont probablement pas nécessaires et le paramètre `host` commencera par `imap://` au lieu de `imaps://`. -Quand c'est fait, vous pouvez utiliser la commande `git send-email` pour placer la série de patchs dans le répertoire *Drafts* du serveur IMAP spécifié : +Quand c'est fait, vous pouvez utiliser la commande `git imap-send` pour placer la série de patchs dans le répertoire *Drafts* du serveur IMAP spécifié : + + $ cat *.patch |git imap-send + Resolving imap.gmail.com... ok + Connecting to [74.125.142.109]:993... ok + Logging in... + sending 2 messages + 100% (2/2) done + +À présent, vous devriez pouvoir vous rendre dans le répertoire *Drafts*, changer le champ destinataire pour celui de la liste de diffusion, y ajouter optionnellement en copie le mainteneur du projet ou le responsable et l'envoyer. + +Une autre méthode consiste à envoyer vos patchs par un serveur SMTP. +Comme précédemment, vous pouvez régler chaque paramètre séparément avec une série de commandes `git config` ou vous pouvez les ajouter directement dans la section `sendemail` de votre fichier `~/.gitconfig` : + + [sendemail] + smtpencryption = tls + smtpserver = smtp.gmail.com + smtpuser = user@gmail.com + smtpserverport = 587 + +Après ceci, vous pouvez utiliser la commande `git send-email` pour envoyer vos patchs : $ git send-email *.patch - 0001-Ajout-d-une-limite-la-fonction-de-log.patch - 0002-change-la-largeur-du-log-de-25-a-30.patch + 0001-added-limit-to-log-function.patch + 0002-changed-log-output-to-30-from-25.patch Who should the emails appear to be from? [Jessica Smith ] Emails will be sent from: Jessica Smith Who should the emails be sent to? jessica@example.com @@ -707,8 +727,6 @@ Ensuite, Git crache un certain nombre d'informations qui ressemblent à ceci pou Result: OK -À présent, vous devriez pouvoir vous rendre dans le répertoire Drafts, changer le champ destinataire pour celui de la liste de diffusion, y ajouter optionnellement en copie le mainteneur du projet ou le responsable et l'envoyer. - ### Résumé ### Ce chapitre a traité quelques-unes des méthodes communes de gestion de types différents de projets Git que vous pourrez rencontrer et a introduit un certain nombre de nouveaux outils pour vous aider à gérer ces processus. From 28fdda9302fb2d1dc80211e91faea62c0dc65aa1 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 2 Jun 2014 22:34:11 +0200 Subject: [PATCH 048/291] [fr] apply bdef6f76 and 1ca5ef16 --- fr/03-git-branching/01-chapter3.markdown | 2 +- fr/05-distributed-git/01-chapter5.markdown | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fr/03-git-branching/01-chapter3.markdown b/fr/03-git-branching/01-chapter3.markdown index 6768e4a02..832292d3b 100644 --- a/fr/03-git-branching/01-chapter3.markdown +++ b/fr/03-git-branching/01-chapter3.markdown @@ -597,7 +597,7 @@ Pour créer une branche locale avec un nom différent de celui de la branche dis Branch sf set up to track remote branch refs/remotes/origin/correctionserveur. Switched to a new branch "sf" -À présent, votre branche locale sf poussera vers et tirera automatiquement depuis origin/correctionserveur. +À présent, votre branche locale `sf` poussera vers et tirera automatiquement depuis `origin/correctionserveur`. ### Effacer des branches distantes ### diff --git a/fr/05-distributed-git/01-chapter5.markdown b/fr/05-distributed-git/01-chapter5.markdown index 72096ff41..8b0ac0a35 100644 --- a/fr/05-distributed-git/01-chapter5.markdown +++ b/fr/05-distributed-git/01-chapter5.markdown @@ -255,7 +255,7 @@ John a une référence aux modifications que Jessica a poussées, mais il doit l Cette fusion se passe sans problème — l'historique de *commits* de John ressemble à présent à la figure 5-5. Insert 18333fig0505.png -Figure 5-5. Le dépôt local de John après la fusion d'origin/master. +Figure 5-5. Le dépôt local de John après la fusion d'`origin/master`. Maintenant, John peut tester son code pour s'assurer qu'il fonctionne encore correctement et peut pousser son travail nouvellement fusionné sur le serveur : From 3e72fe91a906f5a1c7ca1d50cadef6f86c617ecb Mon Sep 17 00:00:00 2001 From: lord63 Date: Tue, 3 Jun 2014 16:34:35 +0800 Subject: [PATCH 049/291] [zh] Fix a small typo in 01-chapter5 --- zh/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/05-distributed-git/01-chapter5.markdown b/zh/05-distributed-git/01-chapter5.markdown index b74cf66a9..2eaacee66 100644 --- a/zh/05-distributed-git/01-chapter5.markdown +++ b/zh/05-distributed-git/01-chapter5.markdown @@ -837,7 +837,7 @@ Insert 18333fig0527.png user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 -完成签名之后，如何分发PGP公钥（public key）是个问题。（译者注：分发公钥是为了验证标签）。还好，Git的设计者想到了解决办法：可以把key（既公钥）作为blob变量写入Git库，然后把它的内容直接写在标签里。`gpg --list-keys`命令可以显示出你所拥有的key： +完成签名之后，如何分发PGP公钥（public key）是个问题。（译者注：分发公钥是为了验证标签）。还好，Git的设计者想到了解决办法：可以把key（即公钥）作为blob变量写入Git库，然后把它的内容直接写在标签里。`gpg --list-keys`命令可以显示出你所拥有的key： $ gpg --list-keys /Users/schacon/.gnupg/pubring.gpg From 06245d5a93718e1e24db4e3a48495dc02c097b51 Mon Sep 17 00:00:00 2001 From: onovy Date: Sat, 7 Jun 2014 18:59:51 +0200 Subject: [PATCH 050/291] (working directory clean) message change. This change was introduced in git at https://github.com/git/git/commit/50bd8b7eb960ff7a646195e0751b48a0e57e03ad --- ar/02-git-basics/01-chapter2.markdown | 2 +- az/02-git-basics/01-chapter2.markdown | 2 +- az/06-git-tools/01-chapter6.markdown | 2 +- be/02-git-basics/01-chapter2.markdown | 2 +- cs/02-git-basics/01-chapter2.markdown | 2 +- cs/06-git-tools/01-chapter6.markdown | 2 +- de/06-git-tools/01-chapter6.markdown | 2 +- en/06-git-tools/01-chapter6.markdown | 2 +- eo/02-git-basics/01-chapter2.markdown | 2 +- es-ni/02-git-basics/01-chapter2.markdown | 2 +- es/02-git-basics/01-chapter2.markdown | 2 +- es/06-git-tools/01-chapter6.markdown | 2 +- es/omegat-Benzirpi.tmx | 4 ++-- fi/02-git-basics/01-chapter2.markdown | 2 +- fr/02-git-basics/01-chapter2.markdown | 2 +- fr/06-git-tools/01-chapter6.markdown | 2 +- id/02-git-basics/01-chapter2.markdown | 2 +- it/06-git-tools/01-chapter6.markdown | 2 +- ja/06-git-tools/01-chapter6.markdown | 2 +- ko/06-git-tools/01-chapter6.markdown | 2 +- mk/02-git-basics/01-chapter2.markdown | 2 +- nl/02-git-basics/01-chapter2.markdown | 2 +- nl/06-git-tools/01-chapter6.markdown | 2 +- no-nb/02-git-basics/01-chapter2.markdown | 2 +- no-nb/06-git-tools/01-chapter6.markdown | 2 +- pl/02-git-basics/02-chapter2.markdown | 2 +- pl/06-git-tools/01-chapter6.markdown | 2 +- pt-br/02-git-basics/01-chapter2.markdown | 2 +- pt-br/06-git-tools/01-chapter6.markdown | 2 +- ru/02-git-basics/01-chapter2.markdown | 2 +- ru/06-git-tools/01-chapter6.markdown | 2 +- th/02-git-basics/01-chapter2.markdown | 2 +- tr/02-git-basics/01-chapter2.markdown | 2 +- vi/02-git-basics/01-chapter2.markdown | 2 +- zh-tw/06-git-tools/01-chapter6.markdown | 2 +- zh/06-git-tools/01-chapter6.markdown | 2 +- 36 files changed, 37 insertions(+), 37 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 42771d7b9..0bea0227d 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -56,7 +56,7 @@ The main tool you use to determine which files are in which state is the git sta $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. diff --git a/az/02-git-basics/01-chapter2.markdown b/az/02-git-basics/01-chapter2.markdown index 4e177b56a..7f405674a 100644 --- a/az/02-git-basics/01-chapter2.markdown +++ b/az/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ The main tool you use to determine which files are in which state is the `git st $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown index 5ca797d32..a6f0108af 100644 --- a/az/06-git-tools/01-chapter6.markdown +++ b/az/06-git-tools/01-chapter6.markdown @@ -440,7 +440,7 @@ Your working directory is clean: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`: diff --git a/be/02-git-basics/01-chapter2.markdown b/be/02-git-basics/01-chapter2.markdown index 4767c095a..d1f61ded5 100644 --- a/be/02-git-basics/01-chapter2.markdown +++ b/be/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Insert 18333fig0201.png $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Гэта значыць, што ў вас чысты працоўны каталог, іншымі словамі - адсутнічаюць мадыфікаваныя адсочваемыя файлы. Git таксама не знайшоў якія-небудзь неадсочваемыя файлы, у зваротным выпадку яны былі б пералічаны тут. У канцы каманда паказвае вам на якой ветцы вы знаходзіцеся. This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index b8b37c4c0..cae0cc93e 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz ` $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole. diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index 17b17dcb3..8b4349abf 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -457,7 +457,7 @@ Váš pracovní adresář se vyčistil: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Nyní můžete bez obav přepnout větve a pracovat na jiném úkolu, vaše změny byly uloženy do zásobníku. Chcete-li se podívat, které soubory jste odložili, spusťte příkaz `git stash list`: diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown index d9574cfff..0a16b2f0a 100644 --- a/de/06-git-tools/01-chapter6.markdown +++ b/de/06-git-tools/01-chapter6.markdown @@ -580,7 +580,7 @@ In Deinem Arbeitsverzeichnis befinden sich jetzt keine geänderten Dateien mehr $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index f986c2e38..eaa9b42a0 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -440,7 +440,7 @@ Your working directory is clean: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`: diff --git a/eo/02-git-basics/01-chapter2.markdown b/eo/02-git-basics/01-chapter2.markdown index be6a22bcf..78f6820c2 100644 --- a/eo/02-git-basics/01-chapter2.markdown +++ b/eo/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ The main tool you use to determine which files are in which state is the `git st $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. diff --git a/es-ni/02-git-basics/01-chapter2.markdown b/es-ni/02-git-basics/01-chapter2.markdown index aac17c27c..701d8c983 100644 --- a/es-ni/02-git-basics/01-chapter2.markdown +++ b/es-ni/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ La herramienta principal que se utiliza para determinar qué archivos están en $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Esto significa que tienes una copia de trabajo limpia, en otras palabras, que no hay ningún archivo versionado que haya sido modificado. Git tampoco detectó ningún archivo sin versionar, de otra manera debería estar listado aquí. Por último, el comando indica en qué branch estás trabajando. Por ahora, siempre será master, que es el branch por defecto; no hace falta que te preocupes por saber qué significa en este punto aún. En el próximo capítulo analizaremos los branches y referencias en detalle. diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown index d46c1cb7d..d4e8d4098 100644 --- a/es/02-git-basics/01-chapter2.markdown +++ b/es/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Tu principal herramienta para determinar qué archivos están en qué estado es $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Esto significa que tienes un directorio de trabajo limpio —en otras palabras, no tienes archivos bajo seguimiento y modificados—. Git tampoco ve ningún archivo que no esté bajo seguimiento, o estaría listado ahí. Por último, el comando te dice en qué rama estás. Por ahora, esa rama siempre es "master", que es la predeterminada. No te preocupes de eso por ahora, el siguiente capítulo tratará los temas de las ramas y las referencias en detalle. diff --git a/es/06-git-tools/01-chapter6.markdown b/es/06-git-tools/01-chapter6.markdown index df5bec3cd..5ae5c5c8b 100644 --- a/es/06-git-tools/01-chapter6.markdown +++ b/es/06-git-tools/01-chapter6.markdown @@ -440,7 +440,7 @@ Con ello, se limpia el área de trabajo: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Y se permite cambiar de rama para ponerse a trabajar en cualquier otra parte. Con la tranquilidad de que los cambios a medio completar están guardados a buen recaudo en la pila de guardado rápido. Para ver el contenido de dicha pila, se emplea el comando 'git stash list': diff --git a/es/omegat-Benzirpi.tmx b/es/omegat-Benzirpi.tmx index f789972d9..971ad7931 100644 --- a/es/omegat-Benzirpi.tmx +++ b/es/omegat-Benzirpi.tmx @@ -28305,12 +28305,12 @@ Figura 5-21. $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown index f5c7f1ab0..2221d8629 100644 --- a/fi/02-git-basics/01-chapter2.markdown +++ b/fi/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Päätyökalu tiedostojesi eri tilojen selvittämiseen on `git status` -komento. $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Tämä tarkoittaa, että sinulla on puhdas työhakemisto - toisin sanoen, jäljitettyjä tiedostoja ei ole muutettu. Git ei myöskään näe yhtään jäljittämätöntä tiedostoa, muuten ne olisi listattu näkymään. Lopuksi komento kertoo sinulle missä haarassa olet. Tällä hetkellä se on aina `master`-haara, joka on oletusarvo; sinun ei tarvitse huolehtia siitä nyt. Seuraava luku käy läpi haarautumiset ja viittaukset yksityiskohtaisesti. diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index 1ed5f012e..5196cc1b0 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -81,7 +81,7 @@ Si vous lancez cette commande juste après un clonage, vous devriez voir ce qui $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Ce message signifie que votre copie de travail est propre, en d'autres mots, aucun fichier suivi n'a été modifié. Git ne voit pas non plus de fichiers non-suivis, sinon ils seraient listés ici. diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown index 042f4ed3e..81009134a 100644 --- a/fr/06-git-tools/01-chapter6.markdown +++ b/fr/06-git-tools/01-chapter6.markdown @@ -504,7 +504,7 @@ Votre répertoire de travail est propre : $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean À ce moment, vous pouvez facilement changer de branche et travailler autre part ; vos modifications sont conservées dans votre pile. Pour voir quelles remises vous avez sauvegardées, vous pouvez utiliser la commande `git stash list` : diff --git a/id/02-git-basics/01-chapter2.markdown b/id/02-git-basics/01-chapter2.markdown index dd67c0367..428e91669 100644 --- a/id/02-git-basics/01-chapter2.markdown +++ b/id/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Alat utama yang Anda gunakan untuk menentukan berkas-berkas mana yang berada dal $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Ini berarti Anda memiliki direktori kerja yang bersih-dengan kata lain, tidak ada berkas terpantau yang terubah. Git juga tidak melihat berkas-berkas yang tak terpantau, karena pasti akan dilaporkan oleh alat ini. Juga, perintah ini memberitahu Anda tentang cabang tempat Anda berada. Pada saat ini, cabang akan selalu berada di master, karena sudah menjadi default-nya; Anda tidak perlu khawatir tentang cabang dulu. Bab berikutnya akan membahas tentang percabangan dan referensi secara lebih detil. diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown index 26d1e0821..28a30020c 100644 --- a/it/06-git-tools/01-chapter6.markdown +++ b/it/06-git-tools/01-chapter6.markdown @@ -440,7 +440,7 @@ La tua cartella di lavoro ora è pulita: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean A questo punto puoi passare facilmente a un'altra diramazione e lavorare ad altro; le tue modifiche sono salvate nella tua pila di accantonamento. Per vedere cosa c'è nella tua pila usa `git stash list`: diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown index fae8cf67c..84519bda2 100644 --- a/ja/06-git-tools/01-chapter6.markdown +++ b/ja/06-git-tools/01-chapter6.markdown @@ -435,7 +435,7 @@ simplegit.rb のステータスがおもしろいことになっています。 $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean これで、簡単にブランチを切り替えて別の作業をできるようになりました。これまでの変更内容はスタックに格納されています。今までに格納した内容を見るには `git stash list` を使います。 diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown index 231d2dc8c..ae30bf7f2 100644 --- a/ko/06-git-tools/01-chapter6.markdown +++ b/ko/06-git-tools/01-chapter6.markdown @@ -436,7 +436,7 @@ Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일만 저 $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean 이제 아무 브랜치나 골라서 바꿀 수 있다. 수정하던 것은 스택에 저장했다. 아래와 같이 `git stash list`를 사용하여 저장한 Stash를 확인한다: diff --git a/mk/02-git-basics/01-chapter2.markdown b/mk/02-git-basics/01-chapter2.markdown index 22d47ac85..82152512d 100644 --- a/mk/02-git-basics/01-chapter2.markdown +++ b/mk/02-git-basics/01-chapter2.markdown @@ -54,7 +54,7 @@ Insert 18333fig0201.png Главната алатка која ја користите за да дознаете кој фајл во која фаза се наоѓа е Git статус командата. Ако ја извршите оваа комнада веднаш по клонирањето треба да забележите нешто вака: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Ова значи дека имате чист работен директориѕм, т.е. не постојат следени и променети фајлови. Git не нашол неследени фајлови, во спротивно ќе бидат прикажани овде. Како последна информација што ви ја дава оваа команда е тоа на кој бранч се наоѓате. За сега тоа секогаш е главниот бранч кој е предодреден; не треба да ве засега тоа во овој момент. Во следното поглавје ќе бидат детално разгледани бранчовите и референците. diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown index 2e2a50a51..1df052bc7 100644 --- a/nl/02-git-basics/01-chapter2.markdown +++ b/nl/02-git-basics/01-chapter2.markdown @@ -91,7 +91,7 @@ Het commando dat je voornamelijk zult gebruiken om te bepalen welk bestand zich $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Dit betekent dat je een schone werkdirectory hebt, met andere woorden er zijn geen tracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In het volgende hoofdstuk wordt gedetaileerd ingegaan op branches en referenties. diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown index 667354d80..6ff291d40 100644 --- a/nl/06-git-tools/01-chapter6.markdown +++ b/nl/06-git-tools/01-chapter6.markdown @@ -477,7 +477,7 @@ Je werkdirectory is schoon: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Nu kan je eenvoudig van branch wisselen en ergens anders aan werken, je wijzigingen zijn opgeslagen op de stapel. Om te zien welke stashes je opgeslagen hebt, kun je `git stash list` gebruiken: diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown index 7ce179f56..69de1735e 100644 --- a/no-nb/02-git-basics/01-chapter2.markdown +++ b/no-nb/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ The main tool you use to determine which files are in which state is the `git st $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown index 5ca797d32..a6f0108af 100644 --- a/no-nb/06-git-tools/01-chapter6.markdown +++ b/no-nb/06-git-tools/01-chapter6.markdown @@ -440,7 +440,7 @@ Your working directory is clean: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`: diff --git a/pl/02-git-basics/02-chapter2.markdown b/pl/02-git-basics/02-chapter2.markdown index c10ec28a2..3695a4541 100644 --- a/pl/02-git-basics/02-chapter2.markdown +++ b/pl/02-git-basics/02-chapter2.markdown @@ -55,7 +55,7 @@ Podstawowe narzędzie używane do sprawdzenia stanu plików to polecenie `git st $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Oznacza to, że posiadasz czysty katalog roboczy — innymi słowy nie zawiera on śledzonych i zmodyfikowanych plików. Git nie widzi także żadnych plików nieśledzonych, w przeciwnym wypadku wyświetliłby ich listę. W końcu polecenie pokazuje również gałąź, na której aktualnie pracujesz. Póki co, jest to zawsze master, wartość domyślna; nie martw się tym jednak teraz. Następny rozdział w szczegółach omawia gałęzie oraz odniesienia. diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown index fbba51d7a..9dd3e6e3b 100644 --- a/pl/06-git-tools/01-chapter6.markdown +++ b/pl/06-git-tools/01-chapter6.markdown @@ -602,7 +602,7 @@ Twój katalog roboczy jest teraz w stanie niezmienionym: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean W tej chwili, możesz bez problemu przejść na inną gałąź i rozpocząć pracę nad innymi zmianami; Twoje poprzednie modyfikacje zapisane są w przechowalni. Aby zobaczyć listę zapisanych zmian w przechowalni, użyj komendy `git stash list`: diff --git a/pt-br/02-git-basics/01-chapter2.markdown b/pt-br/02-git-basics/01-chapter2.markdown index a773e232c..d4b0201cb 100644 --- a/pt-br/02-git-basics/01-chapter2.markdown +++ b/pt-br/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ A principal ferramenta utilizada para determinar quais arquivos estão em quais $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Isso significa que você tem um diretório de trabalho limpo — em outras palavras, não existem arquivos monitorados e modificados. Git também não encontrou qualquer arquivo não monitorado, caso contrário eles seriam listados aqui. Por fim, o comando lhe mostra em qual branch você se encontra. Por enquanto, esse sempre é o `master`, que é o padrão; você não deve se preocupar com isso. No próximo capítulo nós vamos falar sobre branches e referências em detalhes. diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown index 4a73cba92..8b4da423a 100644 --- a/pt-br/06-git-tools/01-chapter6.markdown +++ b/pt-br/06-git-tools/01-chapter6.markdown @@ -436,7 +436,7 @@ Seu diretório de trabalho está limpo: $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Neste momento, você pode facilmente mudar de branch e trabalhar em outra coisa; suas alterações estão armazenadas na sua pilha. Para ver as stashes que você guardou, você pode usar `git stash list`: diff --git a/ru/02-git-basics/01-chapter2.markdown b/ru/02-git-basics/01-chapter2.markdown index e2fa37cf8..b033ab202 100644 --- a/ru/02-git-basics/01-chapter2.markdown +++ b/ru/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Insert 18333fig0201.png $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка `master` — это ветка по умолчанию; в этой главе это не важно. В следующей главе будет подробно рассказано про ветки и ссылки. diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown index 0299438f1..470168f78 100644 --- a/ru/06-git-tools/01-chapter6.markdown +++ b/ru/06-git-tools/01-chapter6.markdown @@ -440,7 +440,7 @@ Insert 18333fig0601.png $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean В данный момент вы легко можете переключить ветки и поработать где-то ещё; ваши изменения сохранены в стеке. Чтобы посмотреть, что у вас есть припрятанного, используйте `git stash list`: diff --git a/th/02-git-basics/01-chapter2.markdown b/th/02-git-basics/01-chapter2.markdown index d6cad5300..0e23db3e3 100644 --- a/th/02-git-basics/01-chapter2.markdown +++ b/th/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Insert 18333fig0201.png $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean ผลลัพธ์ด้านบนหมายความว่าไดเรกทอรีของคุณยังสะอาดอยู่ นั่นก็คือไม่มีการแก้ไขแฟ้มที่ถูก track และ ไม่มีแฟ้มที่อยู่ในสถานะ untracked ในไดเรกทอรี นอกจากนั้นคำสั่งนี้ยังบอกว่าคุณอยู่ใน branch ชื่อ master ซึ่งเป็น branch เริ่มต้นอยู่แล้ว เราจะลงรายละเอียดเกี่ยวกับ branch และ reference ในบทถัดไป diff --git a/tr/02-git-basics/01-chapter2.markdown b/tr/02-git-basics/01-chapter2.markdown index fd769f132..7d90fb73c 100644 --- a/tr/02-git-basics/01-chapter2.markdown +++ b/tr/02-git-basics/01-chapter2.markdown @@ -56,7 +56,7 @@ Hangi dosyanın hangi durumda olduğunu görmek için kullanılacak temel araç $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Bu çalışma klasörünüzün temiz olduğu anlamına gelir —başka bir deyişle, izlenmekte olup da değiştirilmiş herhangi bir dosya yoktur. Git'in saptadığı herhangi bir izlenmeyen dosya da yok, olsaydı burada listelenmiş olurdu. Son olarak, bu komut size hangi dal (_branch_) üzerinde olduğunuzu söylüyor. Şimdilik bu, daima varsayılan dal olan `master` olacaktır; Şu anda buna kafa yormayın. Sonraki bölüm de dallar ve referanslar konusu derinlemesine ele alınacak. diff --git a/vi/02-git-basics/01-chapter2.markdown b/vi/02-git-basics/01-chapter2.markdown index 460b5455a..9b4e38645 100644 --- a/vi/02-git-basics/01-chapter2.markdown +++ b/vi/02-git-basics/01-chapter2.markdown @@ -55,7 +55,7 @@ Công cụ chính để phát hiện trạng thái của tập tin là lệnh `g $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean Điều này có nghĩa là bạn có một thư mục làm việc "sạch" - hay nói cách khác, không có tập tin đang theo dõi nào bị thay đổi. Git cũng không phát hiện ra tập tin chưa được theo dõi nào, nếu không thì chúng đã được liệt kê ra đây. Cuối cùng, lệnh này cho bạn biết bạn đang thao tác trên "nhánh" (branch) nào. Hiện tại thì nó sẽ luôn là `master`, đó là nhánh mặc định; bạn chưa nên quan tâm đến vấn đề này bây giờ. Chương tiếp theo chúng ta sẽ bàn về các Nhánh chi tiết hơn. diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown index 42c34316e..9315aedd9 100644 --- a/zh-tw/06-git-tools/01-chapter6.markdown +++ b/zh-tw/06-git-tools/01-chapter6.markdown @@ -439,7 +439,7 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾 $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean 這時，你可以方便地切換到其他分支工作；你的變更都保存在堆疊上。要查看現有的儲藏，你可以使用 `git stash list`： diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown index ac3f20ac1..948b1ff1d 100644 --- a/zh/06-git-tools/01-chapter6.markdown +++ b/zh/06-git-tools/01-chapter6.markdown @@ -439,7 +439,7 @@ simplegit.rb的状态非常有意思。它显示有几行被暂存了，有几 $ git status # On branch master - nothing to commit (working directory clean) + nothing to commit, working directory clean 这时，你可以方便地切换到其他分支工作；你的变更都保存在栈上。要查看现有的储藏，你可以使用 `git stash list`： From 4396aa8204094e4ca72ba05e16e3cc36686745d4 Mon Sep 17 00:00:00 2001 From: FrankLo Date: Mon, 9 Jun 2014 06:27:55 +0200 Subject: [PATCH 051/291] Update 01-chapter1.markdown The sentence did not make sense, so I hopefully could write it in a more clear format. --- de/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown index ff5c6ef4c..5c60ced9d 100644 --- a/de/01-introduction/01-chapter1.markdown +++ b/de/01-introduction/01-chapter1.markdown @@ -340,7 +340,7 @@ Git umfasst das Werkzeug `git config`, das Dir erlaubt, Konfigurationswerte zu v -Auf Windows Systemen sucht Git nach der `.gitconfig` Datei im `$HOME` Verzeichnis (für die meisten Leute ist das das Verzeichnis `C:\Dokumente und Einstellungen\$USER`). Git sucht außerdem auch nach dem Verzeichnis /etc/gitconfig, aber es sucht relativ demjenigen Verzeichnis, in dem Du Git mit Hilfe des Installers installiert hast. +Auf Windows Systemen sucht Git nach der `.gitconfig` Datei im `$HOME` Verzeichnis (für die meisten Leute ist das das Verzeichnis `C:\Dokumente und Einstellungen\$USER`). Es schaut auch immer nach `/etc/gitconfig`, auch wenn dieses relativ zu dem MSys Wurzelverzeichnis ist, welches das ist, wohin Du Git bei der Installation in Windows installiert hast. ### Deine Identität ### From 9597815435afd21c146d501a32a7af280455d689 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Mon, 9 Jun 2014 17:38:09 +0200 Subject: [PATCH 052/291] fix chap 4. --- fr/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown index 91238f71c..76257d723 100644 --- a/fr/04-git-server/01-chapter4.markdown +++ b/fr/04-git-server/01-chapter4.markdown @@ -43,7 +43,7 @@ Ou bien cela : $ git clone file:///opt/git/projet.git Git opère légèrement différemment si vous spécifiez explicitement le protocole `file://` au début de l'URL. -Si vous spécifiez simplement le chemin et si la destination se trouve sur le même système de fichiers, Git tente d'utiliser des liens durs pour le fichiers communs. +Si vous spécifiez simplement le chemin et si la destination se trouve sur le même système de fichiers, Git tente d'utiliser des liens physiques pour le fichiers communs. Si la destination se trouve sur un autre système de fichiers, Git fait une copie des fichiers nécessaires. Si vous spécifiez le protocole `file://`, Git lance un processus d'accès au travers du réseau, ce qui est généralement moins efficace. La raison d'utiliser spécifiquement le préfixe `file://` est la volonté d'obtenir une copie propre du dépôt, sans aucune référence ou aucun objet supplémentaire qui pourraient résulter d'un import depuis un autre système de gestion de version ou d'une action similaire (voir chapitre 9 pour les tâches de maintenance). From 0ecb87948149ab9e8bdd4a7a5dfb2a334776733b Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 9 Jun 2014 17:49:55 +0200 Subject: [PATCH 053/291] Updating to current message. The message is no more confusing. --- en/04-git-server/01-chapter4.markdown | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown index 622648798..9d3496693 100644 --- a/en/04-git-server/01-chapter4.markdown +++ b/en/04-git-server/01-chapter4.markdown @@ -120,12 +120,7 @@ In order to clone your repository to create a new bare repository, you run the c Cloning into bare repository 'my_project.git'... done. - - -The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory. +You should now have a copy of the Git directory data in your `my_project.git` directory. This is roughly equivalent to something like From 995117cde957f1b573aeb02c282989a75c284c82 Mon Sep 17 00:00:00 2001 From: Mengz You Date: Tue, 10 Jun 2014 17:10:04 +0800 Subject: [PATCH 054/291] [zh] Simple Chinese translation Translate the rest of part in Chapter 4. --- zh/04-git-server/01-chapter4.markdown | 58 +++++++++++++-------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown index ae751aeef..ef41b90b2 100644 --- a/zh/04-git-server/01-chapter4.markdown +++ b/zh/04-git-server/01-chapter4.markdown @@ -58,7 +58,7 @@ Git 使用的传输协议中最常见的可能就是 SSH 了。这是因为大 $ git clone user@server:project.git -如果不指明用户，Git 会默认使用当前登录的用户名连接服务器。 +如果不指明用户，Git 会默认使用当前登录的用户名连接服务器。 #### 优点 #### @@ -293,7 +293,7 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者 # # To enable this hook, rename this file to "post-update". # - + exec git-update-server-info 意思是当通过 SSH 向服务器推送时，Git 将运行这个 `git-update-server-info` 命令来更新匿名 HTTP 访问获取数据时所需要的文件。 @@ -511,39 +511,39 @@ Gitosis 也具有简单的访问控制功能。如果想让 John 只有读权限 ## Gitolite ## -This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. 不能完全替代随 gitolite 自带的大量文档。 There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg]. +本节作为Gitolite的一个快速指南，指导基本的安装和设置。不能完全替代随Gitolite自带的大量文档。而且可能会随时改变本节内容，因此你也许想看看最新的[版本][gldpg]。 [gldpg]: http://sitaramc.github.com/gitolite/progit.html [gltoc]: http://sitaramc.github.com/gitolite/master-toc.html -Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to). +Gitolite是在Git之上的一个授权层，依托`sshd`或者`httpd`来进行认证。（概括：认证是确定用户是谁，授权是决定该用户是否被允许做他想做的事情）。 -Gitolite 允许你定义访问许可而不只作用于仓库，而同样于仓库中的每个branch和tag name。你可以定义确切的人 (或一组人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。 +Gitolite允许你定义访问许可而不只作用于仓库，而同样于仓库中的每个branch和tag name。你可以定义确切的人(或一组人)只能push特定的"refs"(或者branches或者tags)而不是其他人。 ### 安装 ### -安装 Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户；许多linux变种和solaris 10都已经试过了。你不需要root访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。在下面的例子里，我们会用 `git` 账户在 `gitserver`上. +安装Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户；许多linux变种和solaris 10都已经试过了。你不需要root访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。在下面的例子里，我们会用`git`账户在`gitserver`进行。 -Gitolite 是不同于 "server" 的软件 -- 通过ssh访问, 而且每个在服务器上的userid都是一个潜在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation. +Gitolite是不同于“服务”的软件 -- 其通过ssh访问, 而且每个在服务器上的userid都是一个潜在的“gitolite主机”。我们在这里描述最简单的安装方法，对于其他方法，请参考其文档。 -To begin, create a user called `git` on your server and login to this user. Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `.pub` (we'll use `scott.pub` in our examples). Then run these commands: +开始，在你的服务器上创建一个名为`git`的用户，然后以这个用户登录。从你的工作站拷贝你的SSH公钥（也就是你用`ssh-keygen`默认生成的`~/.ssh/id_dsa.pub`文件），重命名为`.pub`（我们这里使用`scott.pub`作为例子）。然后执行下面的命令： $ git clone git://github.com/sitaramc/gitolite $ gitolite/install -ln # assumes $HOME/bin exists and is in your $PATH $ gitolite setup -pk $HOME/scott.pub -That last command creates new Git repository called `gitolite-admin` on the server. +最后一个命令在服务器上创建了一个名为`gitolite-admin`的Git仓库。 -Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your Gitolite setup by making changes to this repository and pushing. +最后，回到你的工作站，执行`git clone git@gitserver:gitolite-admin`。然后你就完成了！Gitolite现在已经安装在了服务器上，在你的工作站上，你也有一个名为`gitolite-admin`的新仓库。你可用通过更改这个仓库以及推送到服务器上来管理你的Gitolite配置。 ### 定制安装 ### -默认快速安装对大多数人都管用，还有一些定制安装方法如果你用的上的话。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite. +默认快速安装对大多数人都管用，还有一些定制安装方法如果你用的上的话。一些设置可以通过编辑rc文件来简单地改变，但是如果这个不够，有关于定制Gitolite的文档供参考。 ### 配置文件和访问规则 ### -安装结束后，你切换到 `gitolite-admin` 仓库 (放在你的 HOME 目录) 然后看看都有啥： +安装结束后，你切换到`gitolite-admin`仓库（放在你的HOME目录）然后看看都有啥： $ cd ~/gitolite-admin/ $ ls @@ -561,11 +561,11 @@ Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. 注意 "scott" ( 之前用`gl-setup` 命令时候的 pubkey 名稱) 有读写权限而且在 `gitolite-admin` 仓库里有一个同名的公钥文件。 -Adding users is easy. To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation. Add, commit, and push the change, and the user has been added. +添加用户很简单。为了添加一个名为`alice`的用户，获取她的公钥，命名为`alice.pub`，然后放到在你工作站上的`gitolite-admin`克隆的`keydir`目录。添加，提交，然后推送更改。这样用户就被添加了。 -gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一些主要的。 +gitolite配置文件的语法在`conf/example.conf`里，我们只会提到一些主要的。 -你可以给用户或者仓库分组。分组名就像一些宏；定义的时候，无所谓他们是工程还是用户；区别在于你’使用‘“宏”的时候 +你可以给用户或者仓库分组。分组名就像一些宏；定义的时候，无所谓他们是工程还是用户；区别在于你*使用*“宏”的时候 @oss_repos = linux perl rakudo git gitolite @secret_repos = fenestra pear @@ -575,7 +575,7 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一 @engineers = sitaram dilbert wally alice @staff = @admins @engineers @interns -你可以控制许可在 "ref" 级别。在下面的例子里，实习生可以 push "int" branch. 工程师可以 push任何有 "eng-"开头的branch，还有refs/tags下面用 "rc"开头的后面跟数字的。而且管理员可以随便改 (包括rewind) 对任何参考名. +你可以控制许可在”ref“级别。在下面的例子里，实习生可以push ”int“分支。工程师可以push任何有"eng-"开头的branch，还有refs/tags下面用"rc"开头的后面跟数字的。而且管理员可以随便更改(包括rewind)对任何参考名。 repo @oss_repos RW int$ = @interns @@ -583,11 +583,11 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一 RW refs/tags/rc[0-9] = @engineers RW+ = @admins -在 `RW` or `RW+`之后的表达式是正则表达式 (regex) 对应着后面的push用的参考名字 (ref) 。所以我们叫它 "参考正则"（refex）！当然，一个 refex 可以比这里表现的更强大，所以如果你对perl的正则表达式不熟的话就不要改过头。 +在`RW`or`RW+`之后的表达式是正则表达式(regex)对应着后面的push用的参考名字(ref)。所以我们叫它”参考正则“（refex）！当然，一个refex可以比这里表现的更强大，所以如果你对perl的正则表达式不熟的话就不要改过头。 -同样，你可能猜到了，Gitolite 字头 `refs/heads/` 是一个便捷句法如果参考正则没有用 `refs/`开头。 +同样，你可能猜到了，Gitolite字头`refs/heads/`是一个便捷句法如果参考正则没有用`refs/`开头。 -一个这个配置文件语法的重要功能是，所有的仓库的规则不需要在同一个位置。你能报所有普通的东西放在一起，就像上面的对所有 `oss_repos` 的规则那样，然后建一个特殊的规则对后面的特殊案例，就像： +一个这个配置文件语法的重要功能是，所有的仓库的规则不需要在同一个位置。你能报所有普通的东西放在一起，就像上面的对所有`oss_repos`的规则那样，然后建一个特殊的规则对后面的特殊案例，就像： repo gitolite RW+ = sitaram @@ -598,23 +598,23 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一 在gitolite里有两级访问控制。第一是在仓库级别；如果你已经读或者写访问过了任何在仓库里的参考，那么你已经读或者写访问仓库了。 -第二级，应用只能写访问，通过在仓库里的 branch或者 tag。用户名如果尝试过访问 (`W` 或 `+`)，参考名被更新为已知。访问规则检查是否出现在配置文件里，为这个联合寻找匹配 (但是记得参考名是正则匹配的，不是字符串匹配的)。如果匹配被找到了，push就成功了。不匹配的访问会被拒绝。 +第二级，应用只能写访问，通过在仓库里的branch或者tag。用户名如果尝试过访问 (`W`或`+`)，参考名被更新为已知。访问规则检查是否出现在配置文件里，为这个联合寻找匹配 (但是记得参考名是正则匹配的，不是字符串匹配的)。如果匹配被找到了，push就成功了。不匹配的访问会被拒绝。 ### 带'拒绝'的高级访问控制 ### -目前，我们只看过了许可是 `R`, `RW`, 或者 `RW+`这样子的。但是gitolite还允许另外一种许可：`-`，代表 "拒绝"。这个给了你更多的能力，当然也有一点复杂，因为不匹配并不是唯一的拒绝访问的方法，因此规则的顺序变得无关了！ +目前，我们只看过了许可是`R`,`RW`, 或者`RW+`这样子的。但是gitolite还允许另外一种许可：`-`，代表 ”拒绝“。这个给了你更多的能力，当然也有一点复杂，因为不匹配并不是唯一的拒绝访问的方法，因此规则的顺序变得无关了！ -这么说好了，在前面的情况中，我们想要工程师可以 rewind 任意 branch 除了master和 integ。 这里是如何做到的 +这么说好了，在前面的情况中，我们想要工程师可以rewind任意branch除了master和integ。 这里是如何做到的 RW master integ = @engineers - master integ = @engineers RW+ = @engineers -你再一次简单跟随规则从上至下知道你找到一个匹配你的访问模式的，或者拒绝。非rewind push到 master或者 integ 被第一条规则允许。一个 rewind push到那些 refs不匹配第一条规则，掉到第二条，因此被拒绝。任何 push (rewind 或非rewind) 到参考或者其他 master 或者 integ不会被前两条规则匹配，即被第三条规则允许。 +你再一次简单跟随规则从上至下知道你找到一个匹配你的访问模式的，或者拒绝。非rewind push到master或者integ 被第一条规则允许。一个rewind push到那些refs不匹配第一条规则，掉到第二条，因此被拒绝。任何push(rewind或非rewind)到参考或者其他master或者integ不会被前两条规则匹配，即被第三条规则允许。 ### 通过改变文件限制 push ### -此外限制用户 push改变到哪条branch的，你也可以限制哪个文件他们可以碰的到。比如, 可能 Makefile (或者其他哪些程序) 真的不能被任何人做任何改动，因为好多东西都靠着它呢，或者如果某些改变刚好不对就会崩溃。你可以告诉 gitolite: +此外限制用户push改变到哪条branch的，你也可以限制哪个文件他们可以碰的到。比如, 可能Makefile (或者其他哪些程序) 真的不能被任何人做任何改动，因为好多东西都靠着它呢，或者如果某些改变刚好不对就会崩溃。你可以告诉 gitolite: repo foo RW = @junior_devs @senior_devs @@ -625,17 +625,17 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一 ### 个人分支 ### -Gitolite 也支持一个叫 "个人分支"的功能 (或者叫, "个人分支命名空间") 在合作环境里非常有用。 +Gitolite也支持一个叫”个人分支“的功能 (或者叫, ”个人分支命名空间“) 在合作环境里非常有用。 -在 git世界里许多代码交换通过 "pull" 请求发生。然而在合作环境里，委任制的访问是‘绝不’，一个开发者工作站不能认证，你必须push到中心服务器并且叫其他人从那里pull。 +在 git世界里许多代码交换通过”pull“请求发生。然而在合作环境里，委任制的访问是‘绝不’，一个开发者工作站不能认证，你必须push到中心服务器并且叫其他人从那里pull。 -这个通常会引起一些 branch 名称簇变成像 VCS里一样集中化，加上设置许可变成管理员的苦差事。 +这个通常会引起一些branch名称簇变成像 VCS里一样集中化，加上设置许可变成管理员的苦差事。 -Gitolite让你定义一个 "个人的" 或者 "乱七八糟的" 命名空间字首给每个开发人员 (比如，`refs/personal//*`)；看在 `doc/3-faq-tips-etc.mkd`里的 "personal branches" 一段获取细节。 +Gitolite让你定义一个”个人的“或者”乱七八糟的”命名空间字首给每个开发人员(比如，`refs/personal//*`)；看在`doc/3-faq-tips-etc.mkd`里的"personal branches"一段获取细节。 ### "通配符" 仓库 ### -Gitolite 允许你定义带通配符的仓库 (其实还是 perl正则式), 比如随便整个例子的话 `assignments/s[0-9][0-9]/a[0-9][0-9]`。 这是一个非常有用的功能，需要通过设置 `$GL_WILDREPOS = 1;` 在 rc文件中启用。允许你安排一个新许可模式 ("C") 允许用户创建仓库基于通配符，自动分配拥有权对特定用户 - 创建者，允许他交出 R和 RW许可给其他合作用户等等。这个功能在`doc/4-wildcard-repositories.mkd`文档里 +Gitolite 允许你定义带通配符的仓库(其实还是perl正则式), 比如随便整个例子的话`assignments/s[0-9][0-9]/a[0-9][0-9]`。 这是一个非常有用的功能，需要通过设置`$GL_WILDREPOS = 1;` 在 rc文件中启用。允许你安排一个新许可模式("C")允许用户创建仓库基于通配符，自动分配拥有权对特定用户 - 创建者，允许他交出 R和 RW许可给其他合作用户等等。这个功能在`doc/4-wildcard-repositories.mkd`文档里 ### 其他功能 ### From 5b3fc96703e1555189aaf3d5022e1d85dcaee31f Mon Sep 17 00:00:00 2001 From: yamel Date: Tue, 10 Jun 2014 19:27:00 +0300 Subject: [PATCH 055/291] [uk] Chapter 01, translation --- uk/01-introduction/01-chapter1.markdown | 522 ++++++++++++++++++++++++ 1 file changed, 522 insertions(+) create mode 100644 uk/01-introduction/01-chapter1.markdown diff --git a/uk/01-introduction/01-chapter1.markdown b/uk/01-introduction/01-chapter1.markdown new file mode 100644 index 000000000..dae022f01 --- /dev/null +++ b/uk/01-introduction/01-chapter1.markdown @@ -0,0 +1,522 @@ +# Введення # + + + +В цьому розділі йдеться про початок роботи з Git. + +Знайомство відбувається поступово: пояснення основних принципів роботи систем контролю версій, потім інструкція з запуску Git у вашій системі та врешті-решт опис його налаштування для початку роботи. + +Наприкінці розділу ви вже розумітимете передумови виникнення Git, причини та способи його використання саме у ваших проектах та будете готові до практичних дій у цьому напрямі. + + + +## Про контроль версій ## + + + +Що таке контроль версій і навіщо він вам? + +Контроль версій здійснює система, що записує та «запам’ятовує» усі зміни одного чи сукупності файлів, завдяки чому ви можете відновити будь-яку версію пізніше. + +Не варто надавати багато значення тому, що у прикладах цієї книги в якості файлів для контролю версій використовуються початкові коди програм. Насправді, для контролю версій можуть використовуватись будь-які файли + + + +Якщо ви графічний чи вебовий дизайнер та бажаєте зберігати кожну копію зображення чи шару, то використання системи контролю версій (СКВ) стане навпрочуд мудрим рішенням. + +СКВ дозволяє: повертати до попереднього стану будь-які файли чи увесь проект цілком; переглядати зміни зроблені протягом усього часу; бачити хто вносив правки у щось, що могло викликати проблему; хто і коли додав зауваження та багато інших рречей. + +Використання СКВ також передбачає можливість легкого відновлення файлів у разі їх втрати чи пошкодження. На додачу, все це ви отримуєте за досить невеликих витрат часу та ресурсів системи + + + +### Локальні системи контролю версій ### + + + +Багато людей здійснюють контроль версій шляхом простого копіювання файлів до іншої директорії (особливо охайні навіть іменують директорії у хронологічному порядку). Завдяки своїй простоті такий підхід дуже розповсюджений, втім він також неймовірно ненадійний. Адже дуже легко переплутати в якій саме директорії ви зараз знаходитесь і випадково перезаписати не ті файли + + + +Для вирішення цієї проблеми були створені локальні СКВ, що мали просту базу даних для зберігання усіх змін необхідних файлів. (див. Ілюстрацію 1-1). + + + +Insert 18333fig0101.png +Ілюстрація 1-1. Схема локальної системи контролю версій. + + + +Однією з найпопулярніших систем цього типу була rcs, що й досі розповсюджується разом з багатьма комп’ютерами. Навіть операційна система Mac OS X отримує команду rcs після встановлення Developer Tools (Інструменти Розробника). Робота цієї програми заснована на зберіганні сукупності патчів (так називаються відмінності між файлами) між версіями у спеціальному форматі на диску. Вона може відновити стан будь якого файлу у будь-який час шляхом застосування усіх патчів. + + + +### Централізовані системи контролю версій ### + + + +Наступною великою проблемою, з якою зіткнулись люди, стала необхідність співпраці з іншими розробниками. В результаті, справу було вирішено завдяки централізованим системам контролю версій (ЦСКВ). Такі системи, як CVS, Subversion та Perforce, складаються з одного сервера, що зберігає усі контрольовані файли, та деякої кількості клієнтів, які отримують файли з цього «центру». Протягом багатьох років це залишалось стандартом у контролі версій (див. Ілюстрацію 1-2). + + + +Insert 18333fig0102.png +Ілюстрація 1-2. Схема централізованої системи контролю версій. + + + +Така конфігурація має багато переваг, особливо у порівнянні з локальними СКВ. Наприклад, кожен може дізнатись чим займається інший учасник проекту на будь-якому етапі. У адміністраторів є чіткий контроль над тим, хто і що може робити. До того ж, значно простіше адмініструвати централізовану систему, аніж мати справу з локальними базами даних кожного клієнта. + + + +Втім, і цей підхід має деякі серйозні вади. Найбільш очевидною є безумовна залежність від одного елементу мережі, що являє собою централізований сервер. Якщо на годину вимкнути сервер, то протягом цієї години стає неможливою взаємодія між учасниками системи та збереження версійних змін до об’єктів, над якими ведеться робота. При пошкодженні жорсткого диску з центральною базою даних та відсутності її резервних копій ви втрачаєте абсолютно все — всю історію проекту, за виключенням хіба що поодиноких знімків, які клієнтам пощастило мати на локальних машинах. + +Локальні СКВ страждають від тієї ж проблеми — ризик повної втрати проекту у результаті зберігання усієї історії в одному місці. + + + +### Розподілені системи контролю версій ### + + + +Ось тут в гру вступають розподілені системи контролю версій (РСКВ). У цих системах (наприклад: Git, Mercurial, Bazaar чи Darcs) клієнти мають не лише останній знімок файлів, вони отримують повне дзеркало репозиторію. Тож, за втрати одного з серверів, за допомогою якого відбувається співпраця, будь-який з клієнтських репозиторіїв може бути скопійований назад на сервер для відновлення. Кожне стягування файлів, по суті є повною резервною копією усіх даних (див. Ілюстрацію 1-3). + + + +Insert 18333fig0103.png +Ілюстрація 1-3. Розподілена система контролю версій. + + + +Крім того, багато з цих систем чудово працюють з декількома віддаленими репозиторіями. Таким чином, у межах одного проекту ви можете співпрацювати з різними групами людей і різними шляхами одночасно. Це дозволяє налаштувати декілька типів робочих процесів, на відміну від централізованих систем. + + + +## Коротенький екскурс в історію ## + + + +Як і багато інших видатних речей, Git почався з творчого непорозуміння та гарячих протиріч. Ядро Linux це проект з відкритим програмним кодом достатньо великих розмірів. Протягом більшої частини існування ядра (1991-2002 рр.) зміни у коді передавались у вигляді патчів та архівів. У 2002 році у проекті почала використовуватись пропрієтарна РСКВ під назвою BitKeeper. + + + +У 2005 році взаємовідносини між спільнотою розробників ядра та комерційною компанією, що займалась розробкою BitKeeper, погіршились і право безкоштовного користування продуктом було скасовано. Це спонукало спільноту Linux (і особливо Лінуса Торвальдса, засновника Linux) до створення власного інструменту. У пригоді став досвід використання BitKeeper з усіма його перевагами і недоліками. Головні вимоги до нової системи були такі: + + + +* швидкість; +* простий дизайн; +* підтримка нелінійної розробки (тисячі паралельних гілок); +* повна розподільність; +* можливість ефективного управління великими проектами на зразок ядра Linux (швидкість та розмір даних). + + + +Від свого створення у 2005 Git розвивався зберігаючи простоту використання, але не втрачаючи цих початкових орієнтирів. Він неймовірно швидкий, ефективний на великих проектах і має вражаючу систему розгалужування для нелінійної розробки (див. Розділ 3). + + + +## Основи Git ## + + + +Отже, що таке Git у двох словах? + +Це дуже важливо засвоїти, оскільки, зрозумівши основи та принципи функціонування Git, ви зможете використовувати його більш ефективно і з меншими зусиллями. + +На час знайомства з Git спробуйте забути все що ви знаєте про інші СКВ. Це дозволить уникнути деяких непорозумінь. + +Git зберігає інформацію та оперує нею дещо по-іншому, ніж інші системи, навіть попри схожий користувацький інтерфейс. Розуміння цих відмінностей допоможе уникнути плутанини у подальшому. + + + +### Знімки ### + + + +Однією з головних відмінностей від інших систем (таких як Subversion та подібних їй) є те, як Git сприймає дані. + +Більшість СКВ зберігають інформацію як список файлових редагувань. Ці системи (CVS, Subversion, Perforce, Bazaar) розглядають інформацію як список файлів та їх змін, що показано на Ілюстрації 1-4. + + + +Insert 18333fig0104.png +Ілюстрація 1-4. Інші системи зберігають дані як список змін до початкової версії кожного файлу. + + +Git сприймає та зберігає інформацію по-іншому. Git розглядає свої дані ніби сукупність знімків невеликої файлової системи. Щоразу, при збереженні поточного стану проекту, Git робить знімок (копію) того, як виглядають ваші файли саме у цей момент і зберігає посилання на цей знімок. Для ефективності, якщо файл не змінився, Git не збергіє його знову, а просто робить посилання на ідентичний файл з попередньої фіксації змін. Схематичне зображення такого підходу показано нижче. + + + +Insert 18333fig0105.png +Ілюстрація 1-5. Git зберігає дані як знімки проекту за хронологією. + + + +Це дуже важлива різниця між Git та іншими СКВ. З цієї причини у Git було заново переосмислено майже кожен аспект контролю версій, що зробило його схожим на мініатюрну файлову систему з деякими неймовірно потужними вбудованими інструментами. Ми познайомимось з деякими перевагами, які ви отримаєте при сприйнятті інформації подібним чином, у третьому розділі, де йдеться про гілки. + + + +### Майже кожна операція — локальна ### + + + +Більшість операцій в Git потребують лише локальних файлів та ресурсів для здійснення операцій — немає небхідності у інформації з інших комп’ютерів вашої мережі. Якщо ви працюєте з ЦСКВ, де більшість операцій обтяжені такими мережевими запитами, то цей аспект може привести вас до думки, що боги швидкості наділили Git неземною силою. Через те, що повна історія проекту знаходиться на вашому локльному диску, більшість операцій здійснюються майже миттєво. + + + +Наприклад, для перегляду історії, Git не має потреби брати її з серверу, він просто зчитує її прямо з локальної бази даних. Це означає, що ви отримуєте історію проекту не встигнувши кліпнути оком. Якщо ви бажаєте переглянути відмінності між поточною версією файлу та його редакцією місячної давності, Git знайде копію збережену місяць тому і проведе локальний розрахунок замість того, щоб звертатись за цим до віддаленого серверу чи спочатку робити запит на отримання старішої версії файлу. + + + +Також це значить, що за відсутності мережевого з’єднання ви не будете мати особливих обмежень. Перебуваючи у літаку чи потязі можна цілком комфортно фіксувати зміни поки не відновите з’єднання з мережею для їх завантаження. Дорогою додому, не маючи змоги належним чином використовувати свій VPN-клієнт, все одно можна продовжувати роботу. В багатьох інших системах подібні дії або неможливі, або пов’язані з безліччю труднощів. Наприклад, в Perforce, без з’єднання з мережею вам не вдасться зробити багато; у Subversion та CVS ви можете редагувати файли, але не можете фіксувати внесені зміни (оскільки немає зв’язку з базою даних). На перший погляд такі речі здаються незначним, але ви будете вражені наскільки велике значення вони можуть мати. + + + +### Git виконує перевірку цілісності даних ### + + + +Будь-що у Git, перед збереженням, отримує контрольну суму, за якою потім і перевіряється. Таким чином, неможливо змінити файл чи директорію так, щоб Git про це не дізнався. Цей функціонал вбудовано у систему на найнижчих рівнях і є складовою частиною її філософії. Ви не можете втратити інформацію при передачі чи отримати пошкоджений файл без відома Git. + + + +Механізм, який використовується для цього контролю, називається хеш SHA-1. Він являє собою 40-символьну послідовність цифр та перших літер латинського алфавіту (a-f) і вираховується на основі вмісту файлу чи структури директорії. Виглядає це приблизно так: + + 24b9da6552252987aa493b52f8696cd6d3b00373 + +При роботі з Git ви постійно зустрічатимете такі хеші. Фактично, Git зберігає все не за назвою файлу, а саме за такими адресами. + + + +### Git, зазвичай, тільки додає дані ### + + + +Коли ви виконуєте певні дії в Git, при цьому, майже завжди відбувається додавання інформації до її бази даних. Дуже складно змусити систему зробити щось невиправне чи повністю видалити дані. Як і в будь-якій СКВ, ви можете втратити чи зіпсувати лише незафіксовані зміни. Але це майже неможливо, коли вже зроблено знімок, особливо, якщо ви регулярно надсилаєте свою базу до іншого репозиторію. + + + +Це робить використання Git приємним, оскільки можна експериментувати без загрози щось зіпсувати. + +Про те, як Git зберігає інформацію та як можна відновити втрачені дані, детальніше розповідається у Розділі 9. + + + +### Три стани ### + + + +А зараз, будьте уважні. Це найважливіша річ, яку потрібно запам’ятати, якщо ви хочете щоб подальше вивчення Git пройшло гладко. + +Git має три основних стани, у яких можуть перебувати ваші файли: зафіксований, змінений та доданий. + +Зафіксований — значить, дані безпечно збережено в локальній базі даних. + +Змінений означає, що у файл внесено редагування, які ще не зафіксовано у базі даних. + +Доданий стан виникає тоді, коли ви позначаєте змінений файл у поточній версії, готуючи його таким чином до фіксації. + + + +Це приводить нас до трьох головних відділів проекту під управлінням Git: директорія Git, робоча директорія та область додавання. + + + +Insert 18333fig0106.png +Ілюстрація 1-6. Робоча директорія, область додавання та директорія Git. + + + +У директорії Git система зберігає метадані та базу даних об’єктів вашого проекту. Це найважливіша частина проекту. Саме вона копіюється при клонуванні проекту з іншого комп’ютеру. + + + +Робоча директорія являє собою файли і директорії проекту у поточному стані. Ці об’єкти видобуваються з бази даних (яка, пригадаємо, зберігається у директорії Git) і розміщуються на диску для подальшого використання та редагування. + + + +Область додавання це простий файл, що зазвичай знаходиться у директорії Git і містить інформацію про об’єкти, стан яких буде враховано під час наступної фіксації змін. + + + +Найпростіший процес взаємодії з Git виглядає приблизно так: + +1. Ви редагуєте файли у своїй робочій директорії. +2. Надсилаєте файли в область додавання, шляхом створення знімків їх поточного стану. +3. Робите фіксацію, яка бере файли в області додавання і остаточно зберігає цей знімок у директорії Git. + + + +У випадку, якщо окрема версія файлу вже є у директорії Git, цей файл вважається зафіксованим. Якщо він зазнав змін і перебуває в області додавання, то він доданий. Якщо ж його стан відрізняється від того, який було зафіксовано, і файл не знаходиться в області додавання, то він називається зміненим. + +У наступному розділі ви дізнаєтесь більше про ці стани, а також про те, як використовувати їхні переваги або взагалі пропускати етап області додавання. + + + +## Встановлення Git ## + + + +Перш за все, для використання Git, ви маєте його встановити. Для цього існує декілька способів; два найбільш вживаних це встановлення з сирців та встановлення існуючого пакунку для вашої платформи. + + + +### Встановлення з джерельного коду ### + + + +Встановлення Git з джерельного коду є дуже корисним, оскільки ви отримуєте найсвіжішу версію. У кожній новій версії системи зберігається тенденція до покращення елементів користувацького інтерфейсу, тож встановлення останньої версії це найкращий шлях, якщо ви володієте навиками компіляції програм з сирців. Крім того, багато дистрибутивів Лінукс містять досить застарілі пакунки, що може слугувати одним з приводів до цього способу встановлення. + + + +Для встановлення Git вам знадобляться бібліотеки, від яких залежить система: curl, zlib, openssl, expat та libiconv. Якщо ви користуєтесь системою, в якій є утиліта yum (наприклад, Fedora) чи apt-get (будь-яка система на основі Debian — Ubuntu, Mint тощо), для встановлення цих залежностей в нагоді вам може стати одна з таких команд: + + + + $ yum install curl-devel expat-devel gettext-devel \ + openssl-devel zlib-devel + + $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ + libz-dev libssl-dev + +Після отримання необхідних компонентів, можна рухатись далі і стягнути останній знімок системи Git з офіційного сайту: + + + + http://git-scm.com/download + +Потім компіляція і встановлення: + + + + $ tar -zxf git-1.7.2.2.tar.gz + $ cd git-1.7.2.2 + $ make prefix=/usr/local all + $ sudo make prefix=/usr/local install + +Коли все вишевказане виконано, ви можете завершити процес оновленням Git його власними засобами: + + + + $ git clone git://git.kernel.org/pub/scm/git/git.git + +### Встановлення на Linux ### + + + +Якщо бажаєте встановити Git у системі Linux, можете скористатись вбудованим менеджером пакунків. Наприклад, у Fedora це робиться так: + + + + $ yum install git-core + +Якщо ж ви користувач дистрибутиву базованого на Debian чи його нащадках (як Ubuntu, Mint чи elementary), спробуйте apt-get: + + + + $ apt-get install git + +Крім того, багато сучасних дистрибутивів мають графічний інтерфейс управління програмним оточенням — це найпростіший шлях встановлення, а всі залежності підтягнуться автоматично. + +### Встановлення на Mac ### + + + +Існує два простих шляхи встановлення Git на Mac. + +Найпростішим є використання графічного інсталятору, який можна звантажити з його сторінки на сервісі Google Code: + + + + http://code.google.com/p/git-osx-installer + +Insert 18333fig0107.png +Ілюстрація 1-7. Програма встановлення Git в OS X. + + + +Іншим розповсюдженим способом є встановлення за допомогою MacPorts (`http://www.macports.org`). Якщо маєте цей пакет, встановіть Git командою: + + + + $ sudo port install git-core +svn +doc +bash_completion +gitweb + +Вам не обов’язково мати всі розширення. Але якщо коли-небудь ви будете використовувати Git з репозиторіями Subversion, вам знадобиться +svn (детальніше у Розділі 8). + + + +### Встановлення на Windows ### + + + +Встановлення Git на комп’ютері під управлінням операційної системи Windows не повинно викликати проблем. + +Одну з найпростіших процедур встановлення пропонує проект msysGit. Просто звантажте встановлювач зі сторінки на GitHub і запустіть процес встановлення: + + + + http://msysgit.github.com/ + +Після встановлення, ви отримаєте і командний рядок (що включає також SSH клієнт), і стандартний графічний інтерфейс. + + + +Примітка: ви можете використовувати Git з командним рядком msysGit, він допускає набори команд, що наводяться в цій книзі. Якщо ж, з якихось причин, вам потрібно використовувати вбудований у Windows командний рядок, то замість простих одинарних лапок потрібно використовувати подвійні (наприклад, для параметрів, що містять пробіли чи закінчуються символом "^", оскільки це символ продовження). + + + +## Початкове налаштування ## + + + +Тепер, маючи у своїй системі Git, варто зробити деякі налаштування його середовища. Це потрібно зробити лише один раз, оновлення не перезаписуватимуть їх. Втім, ви завжди можете внести зміни, повторно виконавши потрібні команди. + + + +Git містить інструмент під назвою "git config", що дозволяє переглядати та встановлювати налаштування, від яких залежить вигляд та функціонал Git. Ці налаштування можуть зберігатись у трьох різних місцях: + + + +* файл `/etc/gitconfig`: містить значення змінних усіх користувачів системи та їхніх репозиторіїв. Для звернення до цього файлу потрібно в команду `git config` передати параметр `--system`. + + + +* файл `~/.gitconfig` містить налаштування лише для вашого користувача. Працювати з цим файлом можна за допомогою опції `--global`. + + + +* конфігураційний файл у директорії Git (`.git/config`) стосується лише цього окремого репозиторію. Значення кожного наступного равня мають пріоритет перед попереднім, тож значення з `.git/config` більш важливі, ніж з `/etc/gitconfig`. + + + +У системі Windows Git шукатиме файл `.gitconfig` у директорії `$HOME` (`%USERPROFILE%` у системному середовищі), що зазвичай вказує на `C:\Documents and Settings\$USER` або `C:\Users\$USER`, в залежності від версії операційної системи. Крім того, шукатиметься також файл /etc/gitconfig, що пов’язаний з кореневою директорією MSys, яка знаходиться там, де ви вирішили встановити Git. + + + +### Особисті налаштування ### + + + +Перша річ, про яку варто подбати після встановлення Git, вказати ваше ім’я та адресу електронної пошти. Це важливо, оскільки кожна фіксація змін використовує цю інформацію і записує її у дані про знімки: + + + + $ git config --global user.name "Ivan Franko" + $ git config --global user.email ivanfranko@example.com + +Знову ж таки, за умови використання параметру `--global`, вам знадобиться виконати цю дію лише одного разу. Git постійно використовуватиме вказану інформацію для кожної з ваших дій у цій системі. Змінити введені ім’я чи адресу пошти для окремих проектів можна, знаходячись у директорії проекту, тими ж командами, але вже без використання параметру `--global`. + + + +### Редактор ### + + + +Тепер, коли особисті налаштування у порядку, ви можете вказати який текстовий редактор бажаєте використовувати у випадках, коли знадобиться вводити текстову інформацію. Типово Git використовує редактор, що є стандартним у системі (зазвичай це Vi чи Vim). Для того щоб змінити його на інший (наприклад, Emacs), потрібно виконати таку команду: + + + + $ git config --global core.editor emacs + +### Утиліта порівняння ### + + + +Іншою корисною опцією може бути використання певної утиліти порівняння, що буде використовуватись для розв’язання конфліктів при об’єднанні знімків. Припустімо, це має бути vimdiff: + + + + $ git config --global merge.tool vimdiff + +Git сприймає kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, та opendiff у якості коректних значень. Також ви можете вказати інший інструмент, про що більш детальніше розповідається у Розділі 7. + + + +### Перевірка налаштувань ### + + + +Для перегляду своїх налаштувань використовуйте команду `git config --list`: + + + + $ git config --list + user.name=Taras Shevchenko + user.email=taras@example.com + color.status=auto + color.branch=auto + color.interactive=auto + color.diff=auto + ... + + + +Деякі ключі можуть зустрічатись декілька разів. Це може статись через те, що Git шукає значення у різних місцях (наприклад, `/etc/gitconfig` та `~/.gitconfg`). В такому випадку, Git використовує останнє знайдене значення для кожного з ключів. + + + +Також, за допомогою конструкції `git config {key}` можна перевірити значення певного ключа: + + + + $ git config user.name + Taras Shevchenko + + + +## Отримання допомоги ## + + + +У випадку, якщо вам знадобиться допомога, існує три шляхи доступу до керівництва з використання для будь-якої команди Git: + + + + $ git help + $ git --help + $ man git- + +Наприклад, так ви можете переглянути допоміжну інформацію щодо використання команди config: + + + + $ git help config + +Особлива зручність цих команд у том, що вони доступні навіть без підключення до мережі. + +Якщо ж офіційного керівництва і цієї книжки буде недостатньо, і вам знадобиться персональна допомога, спробуйте під’єднатись до каналу `#git` або `#github` на IRC сервері Freenode. Там постійно перебувають сотні людей, що добре розуміються на роботі з Git і готові допомогти. + + + +## Підсумок ## + + + +Тепер ви знаєте що таке Git і в чому його відмінність від централізованих систем контролю версій, з якими ви, можливо, вже знайомі. Також ви отримали у своїй системі робочу версію Git з персональними налаштуваннями. + +Настав час дізнатись про Git більше. + + From 411ed8eafc2e3ba623416697b09afeb75ab287fe Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 9 Jun 2014 17:23:01 +0200 Subject: [PATCH 056/291] [it] Update command line output in Chapter 2 Git doesn't strip content from the commit message PR#761 --- it/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index 37e424f01..ef9a148e5 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -323,8 +323,8 @@ Come vedi, il messaggio predefinito della commit contiene l'ultimo output del co In alternativa, puoi inserire il messaggio per la tua commit alla riga di comando della `commit` specificando l'opzione -m, come segue: - $ git commit -m "Story 182: Fix benchmarks for speed" - [master 463dc4f] Fix benchmarks for speed + $ git commit -m "Storia 182: Corretti benchmarks per la velocità" + [master 463dc4f] Storia 182: Corretti benchmarks per la velocità 2 files changed, 3 insertions(+) create mode 100644 README From b002cf8fdaeff37b5b2c4f98cd24c62796771092 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 9 Jun 2014 17:34:42 +0200 Subject: [PATCH 057/291] [it] translating chapter 6 --- it/06-git-tools/01-chapter6.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown index 26d1e0821..a8a40b57f 100644 --- a/it/06-git-tools/01-chapter6.markdown +++ b/it/06-git-tools/01-chapter6.markdown @@ -525,13 +525,13 @@ Se accantoni del lavoro e lo lasci lì mentre continui a lavorare per un po' nel Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359) Questa è una bella accorciatoioa per recuperare il lavoro accantonato e lavorarci in una nuova diramazione. - -## Rewriting History ## -Many times, when working with Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others. +## Riscrivere la storia ## -In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others. +Molto spesso, lavorando con Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others. +In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others. + ### Changing the Last Commit ### Changing your last commit is probably the most common rewriting of history that you’ll do. You’ll often want to do two basic things to your last commit: change the commit message, or change the snapshot you just recorded by adding, changing and removing files. From 9b0c3e8f6aa8544fe5217f1939ac3c8058595a29 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 9 Jun 2014 17:55:37 +0200 Subject: [PATCH 058/291] [it] Add a chmod on the ~/.ssh on server As per merged PR#777 --- it/04-git-server/01-chapter4.markdown | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown index 56a46cd8c..23de5a0a5 100644 --- a/it/04-git-server/01-chapter4.markdown +++ b/it/04-git-server/01-chapter4.markdown @@ -117,9 +117,10 @@ Per inizializzare un qualsiasi server Git, devi esportare un repository esistent Per clonare il tuo repository per creare un nuovo repository di soli dati, devi avviare il comando clone con l'opzione `--bare`. Convenzionalmente, un repository di soli dati in finisce in `.git`, ad esempio: $ git clone --bare my_project my_project.git - Initialized empty Git repository in /opt/projects/my_project.git/ + Cloning into bare repository 'my_project.git'... + done. -L'output di questo comando confonde un pochino. Dato che `clone` è un `git init` quindi un `git fetch`, vediamo parte dell'output dalla parte `git init`, il quale crea una directory vuota. L'effecttivo trasferimento dell'oggetto non fornisce output, ma avviene. Ora dovresti avere una copia della directory dei dati di Git nella directory `my_project.git`. +Ora dovresti avere una copia della directory dei dati di Git nella directory `my_project.git`. La stessa cosa la si può ottenere con @@ -226,7 +227,12 @@ Devi solo aggiungerle al tuo file `authorized_keys`: $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys -Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro: +L'autenticazione tramite chiavi SSH generalmente richiede una restrizione dei diritti di accesso ai file coinvolti. Per prevenire qualsiasi problema è necessario eseguire: + + $ chmod -R go= ~/.ssh + + + Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro: $ cd /opt/git $ mkdir project.git From d52662e12dd88a1dac772738998311d2182c18ff Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 11 Jun 2014 11:45:21 +0200 Subject: [PATCH 059/291] Rewording --- en/02-git-basics/01-chapter2.markdown | 57 ++------------------------- 1 file changed, 4 insertions(+), 53 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index b8bb571f6..ad75d9c3b 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -665,37 +665,8 @@ To determine which commits in the Git source code repository (git://git.kernel.o $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ --pretty=fuller -However this command will not yield identical results when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments. First determine the absolute-times using e.g. the `date` program: - - $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 00:00:00" -Is - 2014-04-29T00:00:00+0200 - - $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 23:59:59" -Is - 2014-04-29T23:59:59+0200 - - $ # for TZ values of various countries/cities - $ # see http://wiki.openwrt.org/doc/uci/system#time.zones - - $ # Alternative (simplification) under GNU/Linux -- see /usr/share/zoneinfo/ - $ TZ="Europe/Paris" date --date="2014-04-29 00:00:00" -Is - 2014-04-29T00:00:00+0200 - - $ TZ="Europe/Paris" date --date="2014-04-29 23:59:59" -Is - 2014-04-29T23:59:59+0200 - -Using the resulting absolute-times, we can now modify the above example and construct a git log command, that gives repeatable ("Paris"-based) results for everyone, irrespective of location: - - $ git log --after="2014-04-29T00:00:00+0200" \ - --before="2014-04-29T23:59:59+0200" --pretty=fuller - -`+0200` means that here Paris is 2 hours ahead of UTC: - -For example: for `2014-04-29T23:59:59+0200` the corresponding - -UTC is `2014-04-29 21:59:59`. - - -To obtain commits made at a specific instant in time (e.g. `2013-04-29T17:07:22+0200`), we can use +As the output will be different according to the timezone where it will be run, it's recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. +To obtain commits made at a specific instant in time (e.g. 29 April 2013 at 17:07:22 CET), we can use $ git log --after="2013-04-29T17:07:22+0200" \ --before="2013-04-29T17:07:22+0200" --pretty=fuller @@ -719,29 +690,9 @@ To obtain commits made at a specific instant in time (e.g. `2013-04-29T17:07:22+ The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`--date=default`), which shows timezone information of respective author and commiter. -We can change the way that these are displayed in the resulting log list. `--date=local` displays times according to your local timezone: - - $ git log --after="2013-04-29T17:07:22+0200" \ - --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local - -To show all times according to the timezone of New Zealand, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Pacific/Auckland"`): - - $ TZ="NZST-12NZDT,M9.5.0,M4.1.0/3" \ - git log --after="2013-04-29T17:07:22+0200" \ - --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local - -Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) as well as `--date=relative` (e.g. "2 hours ago"). - -When using `git log` without specifying time, - - $ git log --after=2008-06-01 --before=2008-07-01 - -the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing: - - $ git log --after="2008-06-01T09:00:00+0300" \ - --before="2008-07-01T09:00:00+0300" +Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) `--date=local` (times according to your local timezone) as well as `--date=relative` (e.g. "2 hours ago"). -As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: +As a final example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: $ git log --pretty="%h - %s" --author=gitster \ --after="2008-10-01T00:00:00-0400" \ From 3389a244274cc9584240ba1dae733590714df584 Mon Sep 17 00:00:00 2001 From: hoeggi Date: Fri, 13 Jun 2014 11:29:37 +0200 Subject: [PATCH 060/291] Update 01-chapter3.markdown --- de/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown index 64f804ed6..e8e0f3145 100644 --- a/de/03-git-branching/01-chapter3.markdown +++ b/de/03-git-branching/01-chapter3.markdown @@ -867,7 +867,7 @@ Lass uns annehmen, Du entscheidest Dich Deinen Server-Branch ebenfalls einzupfle -Das wiederholt Deine `server`-Arbeit auf der Basis der `server`-Arbeit, wie in Abbildung 3-34 ersichtlich. +Das wiederholt Deine `server`-Arbeit auf der Basis der `master`-Arbeit, wie in Abbildung 3-34 ersichtlich. From ef5722785db3451ab43cbf862b8a602fa38715c5 Mon Sep 17 00:00:00 2001 From: lord63 Date: Sun, 15 Jun 2014 22:44:47 +0800 Subject: [PATCH 061/291] [zh] Fix typo in 01-chapter1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change 丰富的 git 知识 --> 丰富的 Git 知识 In the original en-document, it should be Git rather than git. What's more, this book often use Git rather than git when refer to Git, so I think it should be a typo. --- zh/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown index 93ceddd73..5af662642 100644 --- a/zh/01-introduction/01-chapter1.markdown +++ b/zh/01-introduction/01-chapter1.markdown @@ -252,7 +252,7 @@ Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff $ git help config 我们随时都可以浏览这些帮助信息而无需连网。 -不过，要是你觉得还不够，可以到 Freenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。 +不过，要是你觉得还不够，可以到 Freenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 Git 知识，并且乐于助人。 ## 小结 ## From 93463d3739819e23aab2b75f9fdce1ef5283e1db Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Sun, 15 Jun 2014 20:56:58 +0200 Subject: [PATCH 062/291] Improving description Describing what happens when not specifying the time of the day. --- en/02-git-basics/01-chapter2.markdown | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index ad75d9c3b..2a5dd41ab 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -666,6 +666,7 @@ To determine which commits in the Git source code repository (git://git.kernel.o --pretty=fuller As the output will be different according to the timezone where it will be run, it's recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. + To obtain commits made at a specific instant in time (e.g. 29 April 2013 at 17:07:22 CET), we can use $ git log --after="2013-04-29T17:07:22+0200" \ @@ -692,6 +693,13 @@ The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`- Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) `--date=local` (times according to your local timezone) as well as `--date=relative` (e.g. "2 hours ago"). +When using `git log` without specifying time, the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). + +For example, running a `git log` at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, makes the following two commands equivalent: + $ git log --after=2008-06-01 --before=2008-07-01 + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" + As a final example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: $ git log --pretty="%h - %s" --author=gitster \ From 0a9790cf27874895f1cfe3b31d6f3fe96cb19427 Mon Sep 17 00:00:00 2001 From: Aaron Schumacher Date: Sun, 15 Jun 2014 21:06:23 -0400 Subject: [PATCH 063/291] typo: "User who are" to "Users who are" --- en/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown index 9d3496693..a52ba5361 100644 --- a/en/04-git-server/01-chapter4.markdown +++ b/en/04-git-server/01-chapter4.markdown @@ -622,7 +622,7 @@ In addition to restricting what branches a user can push changes to, you can als - VREF/NAME/Makefile = @junior_devs -User who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details. +Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details. ### Personal Branches ### From 3d0f81fbc60f453d6eaa6177de7c4df7dacceb7f Mon Sep 17 00:00:00 2001 From: Aaron Schumacher Date: Sun, 15 Jun 2014 21:48:11 -0400 Subject: [PATCH 064/291] typo: "works as follow:" to "works as follows:" --- en/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown index a4d821de9..bb6a633e4 100644 --- a/en/05-distributed-git/01-chapter5.markdown +++ b/en/05-distributed-git/01-chapter5.markdown @@ -22,7 +22,7 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma ### Integration-Manager Workflow ### -Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2): +Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follows (see Figure 5-2): 1. The project maintainer pushes to their public repository. 2. A contributor clones that repository and makes changes. From e19f55231f7c393857c507788d6c4b1e7480a996 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 11 Jun 2014 09:37:15 +0200 Subject: [PATCH 065/291] Introducing PR#750 --- it/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index ef9a148e5..fe8ff7d70 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -652,8 +652,8 @@ The lines must be formatted as follows Opzioni Descrizione -(n) Vedi solo le ultime n commit - --since, --after Mostra solo le commit fatte dopo la data specificata. - --until, --before Mostra solo le commit fatte prima della data specificata. + --since, --after Mostra solo le commit fatte dalla data specificata. + --until, --before Mostra solo le commit fatte entro la data specificata. --author Mostra solo le commit dell'autore specificato. --committer Mostra solo le commit del committer specificato. From 80c1acec7828c8b859782c85e861fa984af45675 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 11 Jun 2014 11:50:32 +0200 Subject: [PATCH 066/291] Translating Limiting Log Output according to Date/Time --- it/02-git-basics/01-chapter2.markdown | 51 +++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 3 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index fe8ff7d70..d817acee6 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -657,10 +657,55 @@ The lines must be formatted as follows --author Mostra solo le commit dell'autore specificato. --committer Mostra solo le commit del committer specificato. -Se vuoi, per esempio, vedere quale commit della cronologia di Git modificano i test e che siano state eseguite da Junio Hamano a ottobre 2008, ma che non siano ancora stati uniti, puoi eseguire questo comando: - $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ - --before="2008-11-01" --no-merges -- t/ +### Filtrare i risultati in base a data e ora ### + + Per sapere cosa è stato committato nel repository di Git (git://git.kernel.org/pub/scm/git/git.git) il 29/04/2014 (usando come riferimento il fuso orario impostato sul tuo computer) + + $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ + --pretty=fuller + + Il risultato che si ottiene eseguendo questo comando cambia in base al fuso orario dove viene eseguito. È quindi consigliato usare un orario assoluto quando si usano le opzioni `--after` e `--before`, come per esempio l'ISO 8601 (che include anche informazioni sul furo orario), così da ottenere gli stessi risultati indipendentemente dal fuso orario. + +Per ottenere le commit eseguite in un determinato istante (per esempio il 29 Aprile 2013 alle 17:07:22 CET), possiamo eseguire: + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller + + commit de7c201a10857e5d424dbd8db880a6f24ba250f9 + Author: Ramkumar Ramachandra + AuthorDate: Mon Apr 29 18:19:37 2013 +0530 + Commit: Junio C Hamano + CommitDate: Mon Apr 29 08:07:22 2013 -0700 + + git-completion.bash: lexical sorting for diff.statGraphWidth + + df44483a (diff --stat: add config option to limit graph width, + 2012-03-01) added the option diff.startGraphWidth to the list of + configuration variables in git-completion.bash, but failed to notice + that the list is sorted alphabetically. Move it to its rightful place + in the list. + + Signed-off-by: Ramkumar Ramachandra + Signed-off-by: Junio C Hamano + +Data e ora di `AuthorDate` e `CommitDate` hanno un formato standard (`--date=default`) che mostra le informazioni sul fuso orario, rispettivamente, dell'autore e di chi ha eseguito la commit. + +Altri formati utili sono `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (i secondi passati dall'1/1/1970 UTC) `--date=local` (l'orario del tuo attuale fuso) e `--date=relative` (per esempio: "2 ore fa"). + +Usando `git log` senza specificare un orario equivale a specificare l'orario attuale del tuo computer (mantenendo la differenza con l'UTC). + +Per esempio, eseguendo `git log` alle 09:00 su un computer che sia 3 ore avanti rispetto all'UTC, rende equivalenti questi comandi: + + $ git log --after=2008-06-01 --before=2008-07-01 + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" + +Per fare un ultimo esempio, se vuoi vedere quale commit di Junio Hamano dell'ottobre del 2008 (relative al fuso di New York) che modificano i file di test nella cronologia dei sorgenti di Git che non sono ancora state unite con merge, puoi eseguire questo: + + $ git log --pretty="%h - %s" --author=gitster \ + --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi From 038f1f006eacc5098c03e3edbd16dc328706a233 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 16 Jun 2014 18:48:09 +0200 Subject: [PATCH 067/291] Adding empty row To stay consistent --- en/02-git-basics/01-chapter2.markdown | 1 + 1 file changed, 1 insertion(+) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 2a5dd41ab..452f350a2 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -696,6 +696,7 @@ Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), ` When using `git log` without specifying time, the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). For example, running a `git log` at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, makes the following two commands equivalent: + $ git log --after=2008-06-01 --before=2008-07-01 $ git log --after="2008-06-01T09:00:00+0300" \ --before="2008-07-01T09:00:00+0300" From 7e9ef78b7395f61ad2277925091b7b831b28e30b Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 16 Jun 2014 19:00:37 +0200 Subject: [PATCH 068/291] [it] Updating chapter 6 --- it/06-git-tools/01-chapter6.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown index 9c3dc0c59..7d684617d 100644 --- a/it/06-git-tools/01-chapter6.markdown +++ b/it/06-git-tools/01-chapter6.markdown @@ -248,7 +248,7 @@ Un'opzione comunemente usata in questi casi con il comando `log` è il parametro > D > C -Con questi strumenti puoi dire facilmente a Git quali commit vuoi ispezionare. +Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare. ## Assemblaggio interattivo ## From 010759cf9136844db39461f4ec314d68beefe316 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 16 Jun 2014 19:09:10 +0200 Subject: [PATCH 069/291] [it] Updating chapter 1 --- it/01-introduction/01-chapter1.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 4b5701a8a..09f2af980 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -75,25 +75,25 @@ Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer della rete. Se sei abituato ad un CVCS in cui la maggior parte delle operazioni sono soggette alle latenze di rete, questo aspetto di Git ti farà pensare che gli Dei della velocità abbiano benedetto Git con poteri soprannaturali. Poiché hai l'intera storia del progetto sul tuo disco locale, molte operazioni sembrano quasi istantanee. -Per esempio, per scorrere la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi visualizzarla — la legge direttamente dal database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere i cambiamenti introdotti tra la versione corrente di un file e la versione di un mese fa, Git può consultare il file di un mese fa e calcolare localmente le differenze, invece di richiedere di farlo ad un server remoto o di estrarre una precedente versione del file dal server remoto, per poi farlo in locale. +Per esempio, per navigare la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi mostrarla: la legge direttamente dal tuo database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere le modifiche introdotte tra la versione corrente e la versione di un mese fa di un file, Git può accedere al file com'era un mese fa e calcolare le differenze localmente, invece di dover chiedere a un server remoto di farlo o di scaricare dal server remoto una versione precedente del file, per poi farlo in locale. -Questo significa anche che sono minime le cose che non si possono fare se si è offline o non connesso alla VPN. Se sei in aereo o sul treno e vuoi fare un po' di lavoro, puoi eseguire tranquillamente il commit, anche se non sei connesso alla rete per fare l'upload. Se tornando a casa, trovi che il tuo client VPN non funziona correttamente, puoi comunque lavorare. In molti altri sistemi, fare questo è quasi impossibile o penoso. Con Perforce, per esempio, puoi fare ben poco se non sei connesso al server; e con Subversion e CVS, puoi modificare i file, ma non puoi inviare i cambiamenti al tuo database (perché il database è offline). Tutto ciò non ti può sembrare una gran cosa, tuttavia potresti rimanere di stucco dalla differenza che Git può fare. +Questo significa anche che sono pochissime le cose che non puoi fare se sei offline o non sei connesso alla VPN. Se sei in aereo o sul treno e vuoi fare un po' di lavoro, puoi committare tranquillamente in attesa di essere di nuovo connesso per fare l'upload. Se vai a casa e il tuo client VPN non funziona correttamente, puoi lavorare ugualmente. In molti altri sistemi questo è impossibile o molto penoso. Con Perforce, per esempio, puoi fare ben poco se non sei connesso al server; e con Subversion e CVS, puoi modificare i file, ma non puoi inviare le modifiche al tuo database (perché il database è offline). Tutto ciò potrebbe non sembrarti una gran cosa, ma potrebbe sorprenderti quanta differenza possa fare. ### Git Ha Integrità ### -Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di Git al più basso livello ed è intrinseco nella sua filosofia. Non puoi perdere informazioni nel transito o avere corruzioni di file senza che Git non sia in grado di accorgersene. +Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capira che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene. -Il meccanismo che Git usa per fare questo checksum, è un hash, denominato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come: +Il meccanismo che Git usa per fare questo checksum è un hash chiamato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come: 24b9da6552252987aa493b52f8696cd6d3b00373 -in Git, questi valori di hash si vedono dappertutto, perché Git li usa tantissimo. Infatti, Git immagazzina ogni cosa, nel proprio database indirizzabile, non per nome di file, ma per il valore di hash del suo contenuto. +Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa non in base al nome del file, ma nel suo database indirizzabile per l'hash del suo contenuto. ### Git Generalmente Aggiunge Solo Dati ### -Quando si fanno delle azioni in Git, quasi tutte aggiungono solo dati al database di Git. E' piuttosto difficile che si porti il sistema a fare qualcosa che non sia annullabile o a cancellare i dati in una qualche maniera. Come in altri VCS, si possono perdere o confondere le modifiche, di cui non si è ancora fatto il commit; ma dopo aver fatto il commit di uno snapshot in Git, è veramente difficile perderle, specialmente se si esegue regolarmente, il push del proprio database su di un altro repository. +Quasi tutte le azioni in Git aggiungono dati al database di Git. È piuttosto difficile fare qualcosa che non sia annullabile o che cancelli i dati in una qualche maniera. Come negli altri VCS, puoi perdere o fare confusione con le modifiche che non hai ancora committato, ma dopo aver committato uno snapshot in Git, è veramente difficile perderle, specialmente se regolarmente fai il push del tuo database su un altro repository. -Questo rende l'uso di Git un piacere perché sappiamo che possiamo sperimentare senza il pericolo di perdere seriamente le cose. Per un maggior approfondimento su come Git salva i dati e come puoi recuperare i dati che sembrano persi, vedi "Sotto il Cofano" nel Capitolo 9. +Questo rende piaceole l'uso di Git perché sappiamo che possiamo sperimentare senza il pericolo di causare danni pesanti. Per un maggior approfondimento su come Git salvi i dati e come tu possa recuperare quelli che sembrino persi, consulta il Capitolo 9. ### I Tre Stati ### From f43fe652072573f024137c7943fdb979d63d729f Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 27 May 2014 22:59:01 +0200 Subject: [PATCH 070/291] Add a chmod on the ~/.ssh on server As remarked in #709, setting up a key-based server may need to set up restricted rights. --- en/04-git-server/01-chapter4.markdown | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown index 622648798..78b6c9d84 100644 --- a/en/04-git-server/01-chapter4.markdown +++ b/en/04-git-server/01-chapter4.markdown @@ -232,7 +232,11 @@ You just append them to your `authorized_keys` file: $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys -Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory: +Key-based SSH authentication usually enforces security by requiring restricted rights on the involved files. To prevent SSH from refusing to work, type this: + + $ chmod -R go= ~/.ssh + +Now, you can set up an empty repository for your users by running `git init` with the `--bare` option, which initializes the repository without a working directory: $ cd /opt/git $ mkdir project.git From 8086a29391fd3e20daaea242e2e399d1bf5f5a2d Mon Sep 17 00:00:00 2001 From: Alex Schroeder Date: Sat, 21 Jun 2014 21:48:07 +0200 Subject: [PATCH 071/291] [de] Add missing word and comma --- de/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown index e8e0f3145..fd2081a01 100644 --- a/de/03-git-branching/01-chapter3.markdown +++ b/de/03-git-branching/01-chapter3.markdown @@ -739,7 +739,7 @@ Nun wird Dein lokaler Branch `sf` automatisch push und pull auf `origin/serverfi -Stellen wir uns Du bist fertig mit Deinem Remote-Branch – sagen wir Deine Mitarbeiter und Du, Ihr seid fertig mit einer neuen Funktion und habt sie in den entfernten `master`-Branch (oder in welchem Zweig Ihr sonst den stabilen Code ablegt) gemerged. Du kannst einen Remote-Branch mit der unlogischen Syntax `git push [remotename] :[branch]` löschen. Wenn Du Deinen `serverfix`-Branch vom Server löschen möchtest, führe folgendes aus: +Stellen wir uns vor, Du bist fertig mit Deinem Remote-Branch – sagen wir Deine Mitarbeiter und Du, Ihr seid fertig mit einer neuen Funktion und habt sie in den entfernten `master`-Branch (oder in welchem Zweig Ihr sonst den stabilen Code ablegt) gemerged. Du kannst einen Remote-Branch mit der unlogischen Syntax `git push [remotename] :[branch]` löschen. Wenn Du Deinen `serverfix`-Branch vom Server löschen möchtest, führe folgendes aus: $ git push origin :serverfix To git@github.com:schacon/simplegit.git From 30568d68d9f2491f24ecef48fbecba0040e9b0de Mon Sep 17 00:00:00 2001 From: Soon Van Date: Mon, 23 Jun 2014 23:29:31 -0400 Subject: [PATCH 072/291] Clarify usage of single quotes, not simple ' is more commonly known as a single quote. Was pointed out in #792 by @harupong --- en/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index b82705a07..fc6d9bdd5 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -182,7 +182,7 @@ Installing Git on Windows is very easy. The msysGit project has one of the easie After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. -Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. +Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of single quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. ## First-Time Git Setup ## From 27641e62039ab3ec98785dd48bdf425b08e4e75e Mon Sep 17 00:00:00 2001 From: Olivier Trichet Date: Wed, 25 Jun 2014 14:42:19 +0200 Subject: [PATCH 073/291] Synchronize command example with previous one The file "README" is created/added by previous examples of the chapter. Therefore, it's best for reader to use it as source for "git mv" --- en/02-git-basics/01-chapter2.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 452f350a2..9aa20341f 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -406,20 +406,20 @@ Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file: - $ git mv README.txt README + $ git mv README README.txt $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) - renamed: README.txt -> README + renamed: README -> README.txt However, this is equivalent to running something like this: - $ mv README.txt README - $ git rm README.txt - $ git add README + $ mv README README.txt + $ git rm README + $ git add README.txt Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. From 833a634d818bce260020928f6d56c0550de14ddf Mon Sep 17 00:00:00 2001 From: JordiPujol Date: Wed, 25 Jun 2014 11:59:31 -0500 Subject: [PATCH 074/291] Update 01-chapter1.markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit he traduit un parell de paragrafs. dema més --- ca/01-introduction/01-chapter1.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ca/01-introduction/01-chapter1.markdown b/ca/01-introduction/01-chapter1.markdown index e245b9236..1944283d7 100644 --- a/ca/01-introduction/01-chapter1.markdown +++ b/ca/01-introduction/01-chapter1.markdown @@ -4,11 +4,11 @@ Aquest capítol tracta com iniciar-se amb Git. Començarem explicant alguns conc ## Control de Versions ## -What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer. +Que es el control de version i per què t'hauria d'importar? El control de versions es un sitema que registra els canvis a un arxiu o conjunt d'arxius de manera que despres pot recuperar cualsevol de les versions. Tot i que els exemples de control de versions del llibre son codi font, potfer servir gairebe quansevol mena de arxiu per del teu ordinador. -If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead. +Si ets un disenyador gràfic o de pagines web i vols guardar cada escuna de les versions d'una imatge o disenys (que segur que vols) un sitema de control de versions (Version Control System -VCS-) sera una eina acurada. Et permetrà torna al estat anterior dels fitxers, tornar a un punt anterior de tot el projecte, comparà canvis en el proces, saber qui es el darrer a modificat coses que potser estant donant problemes, qui a introduit un tema i quant, i encara més coses. Fer servir VCS vol dir que si la pífias o pot arreglar, generalment. i tot aixo amb pocs costos. -### Local Version Control Systems ### +### Sitemas de control de versions locals ### Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. From cbcaef87564369049c33e5180963383182df7308 Mon Sep 17 00:00:00 2001 From: Severyn Kozak Date: Wed, 25 Jun 2014 22:50:43 -0400 Subject: [PATCH 075/291] Add numeric color values to 07-customizing-git. en/07-customizing-git/01-chapter7.markdown -Explain that, when colorizing `git` output, users can specify arbitrary numeric color values instead of color names. --- en/07-customizing-git/01-chapter7.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index e77128dd8..1a1b7f729 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -130,7 +130,7 @@ In addition, each of these has subsettings you can use to set specific colors fo $ git config --global color.diff.meta "blue black bold" -You can set the color to any of the following values: normal, black, red, green, yellow, blue, magenta, cyan, or white. If you want an attribute like bold in the previous example, you can choose from bold, dim, ul, blink, and reverse. +You can set the color to any of the following values: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`, or, if your terminal supports more than 16 colors, an arbitrary numeric color value (between 0 and 255 on a 256-color terminal). If you want an attribute like bold in the previous example, you can choose from `bold`, `dim`, `ul`, `blink`, and `reverse`. See the `git config` manpage for all the subsettings you can configure, if you want to do that. From dbecbe304cc01511f9e5bc7ec49d48e25f573df9 Mon Sep 17 00:00:00 2001 From: Soon Van Date: Thu, 26 Jun 2014 08:47:28 -0400 Subject: [PATCH 076/291] Smooth out intro from using too many begins --- en/01-introduction/01-chapter1.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index fc6d9bdd5..d1248fee1 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -1,6 +1,6 @@ # Getting Started # -This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so. +This chapter will be about getting started with Git. We will begin by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it set up to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all set up to do so. ## About Version Control ## @@ -178,7 +178,7 @@ You don’t have to add all the extras, but you’ll probably want to include +s Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: - http://msysgit.github.com/ + http://msysgit.github.io After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. From e77e54e0243b0f8c5faac676a5aa028d8111970e Mon Sep 17 00:00:00 2001 From: Alec Clews Date: Thu, 16 Jan 2014 19:05:07 +1100 Subject: [PATCH 077/291] Added some brief details on BFG http://rtyley.github.io/bfg-repo-cleaner/ --- en/06-git-tools/01-chapter6.markdown | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 3eef10757..099b47ea4 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -1,4 +1,4 @@ -# Git Tools # + Git Tools # By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. @@ -690,7 +690,9 @@ Once again, this changes the SHAs of all the commits in your list, so make sure ### The Nuclear Option: filter-branch ### -There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. +There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. +The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. +However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. #### Removing a File from Every Commit #### @@ -730,6 +732,21 @@ Another common case is that you forgot to run `git config` to set your name and This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address. +### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner### + +[Roberto Tyley](https://github.com/rtyley) has written a similar +tool to filter-branch call the BFG. It is more limited in what is can do, +but it does it _very_ fast. +On a large repository this can make a big difference. + +See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details. + +Tip: BFG is a standalone Java program. However if you create the following alias in your `~/.gitconfig` file you can use `git bfg ...` + + bfg = !java -jar ~/bin/bfg.jar + +(Assuming that you have copied the bfg-x.x.x.jar file to ~/bin/bfg.jar) + ## Debugging with Git ## Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. From 45f9e9860dd0ea7b7d79c73c7ab081264a485155 Mon Sep 17 00:00:00 2001 From: Alec Clews Date: Thu, 16 Jan 2014 19:25:03 +1100 Subject: [PATCH 078/291] A note about using 'git svn info' in build scripts Also fixed a small typo --- en/06-git-tools/01-chapter6.markdown | 2 +- en/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 099b47ea4..9e1d85e54 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -1,4 +1,4 @@ - Git Tools # +# Git Tools # By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown index 4e6671c27..49792b126 100644 --- a/en/08-git-and-other-scms/01-chapter8.markdown +++ b/en/08-git-and-other-scms/01-chapter8.markdown @@ -324,6 +324,17 @@ You can also get the same sort of information that `svn info` gives you by runni This is like `blame` and `log` in that it runs offline and is up to date only as of the last time you communicated with the Subversion server. +Tip: If your build scripts expect to be able to run `svn info` then providing a wrapper around git will often work. +Here is example to experiment with + + #!/usr/bin/env bash + + if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then + git svn info + else + /usr/local/bin/svn "$@" + fi + #### Ignoring What Subversion Ignores #### If you clone a Subversion repository that has `svn:ignore` properties set anywhere, you’ll likely want to set corresponding `.gitignore` files so you don’t accidentally commit files that you shouldn’t. `git svn` has two commands to help with this issue. The first is `git svn create-ignore`, which automatically creates corresponding `.gitignore` files for you so your next commit can include them. From b36c68c02674d5a24ac7560ff64e33ed4197e4f3 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Sat, 28 Jun 2014 09:40:17 +0200 Subject: [PATCH 079/291] [it] Fixing as per PR#799 --- it/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 09f2af980..868a83984 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -182,7 +182,7 @@ Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle pr Una volta installato avrai a disposizione sia la versione da riga di comando (incluso un client SSH ti servirà in seguito) sia l'interfaccia grafica (_GUI_) standard. -Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix) perché permette di usare le complesse linee di comando di questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette semplici (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché in Windows è uno dei simboli di proseguimento. +Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix) perché permette di usare le complesse linee di comando di questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette singole (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché in Windows è uno dei simboli di proseguimento. ## Prima Configurazione di Git ## From c00e5fc24a3c3ffd61a970903b78ce1f71ea27b6 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Sat, 28 Jun 2014 09:44:25 +0200 Subject: [PATCH 080/291] [it] Introducing changes as per PR#800 Riusando negli esempi il file "README" creato precedentemente --- it/02-git-basics/01-chapter2.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index d817acee6..aa304ff8e 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -406,20 +406,20 @@ Può perciò creare un po' di confusione il fatto che Git abbia un comando `mv`. e funziona. Se, infatti, lanci un comando del genere e controlli lo stato, vedrai che Git considera il file rinominato: - $ git mv README.txt README + $ git mv README README.txt $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) - renamed: README.txt -> README + renamed: README -> README.txt Ovviamente, questo è equivalente a eseguire: - $ mv README.txt README - $ git rm README.txt - $ git add README + $ mv README README.txt + $ git rm README + $ git add README.txt Git capisce che, implicitamente stai rinominando il file, così che non c'è differenza se rinominare un file in questo modo o con il comando `mv`. L'unica differenza reale è che `mv` è un solo comando invece di tre: è un questione di convenienza. La cosa più importante è che puoi usare qualsiasi strumento per rinominare un file, e gestire l'aggiunta/rimozione più tardi, prima della commit. From c73da3ca13cff8fa1edbecc3224307e22e185110 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Sat, 28 Jun 2014 09:54:25 +0200 Subject: [PATCH 081/291] [it] updating msygit URL to http://msysgit.github.io/ --- it/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 868a83984..8f716ca98 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -178,7 +178,7 @@ Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai inclu Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione più facili. Semplicemente scarica l'eseguibile dalla pagina di GitHub e lancialo: - http://msysgit.github.com/ + http://msysgit.github.io/ Una volta installato avrai a disposizione sia la versione da riga di comando (incluso un client SSH ti servirà in seguito) sia l'interfaccia grafica (_GUI_) standard. From 1354a7db41b2e3aad98190a5ffab9004395432fa Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Sun, 29 Jun 2014 19:28:00 +0200 Subject: [PATCH 082/291] [it] aggiunge l'uso dei valori numerici per i colori vedi anche PR n.872 --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 4ea91604d..a5e42995a 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -1,4 +1,4 @@ -# Customizing Git # + # Customizing Git # Finora abbiamo quindi coperto le basi di come Git funzioni e come usarlo, abbiamo introdotto un numero di strumenti che Git fornisce per aiutarti ad utilizzarlo al meglio ed in modo efficiente. In questo capitolo spiegherò alcune delle operazioni che possono essere utilizzate per personalizzare il comportamento di Git introducendo molti settaggi ed il Hooks System. Tramite questi strumenti, è semplice fare in modo che Git lavori nel modo che tu, la tua azienda, o il tuo gruppo desiderate. @@ -130,7 +130,7 @@ In aggiunta, ognuna di queste ha sottoimpostazioni che possono essere utilizzate $ git config --global color.diff.meta "blue black bold" -Il colore può essere impostato di ognuno dei seguenti valori: normal, black, red, green, yellow, blue, magenta, cyan, oppure white. Per quanto riguarda gli attributi, come bold nell'esempio precedente, puoi scegliere tra from bold, dim, ul, blink, e reverse. +Il colore può essere impostato di ognuno dei seguenti valori: `normal` (normale), `black` (nero), `red` (rosso), `green` (verde), `yellow` (giallo), `blue` (blu), `magenta`, `cyan` (ciano), `white` (bianco) oppure, se il tuo terminale supporta più di sedici colori, un valore numerico per il colore che vada da 0 a 255 (in un terminale a 256 colori). Per quanto riguarda gli attributi, come `bold` nell'esempio precedente, puoi scegliere tra from `bold` (grassetto), `dim` (ridotto), `ul` (sottolineato), `blink` (lampeggiante), e `revers` (a colori invertiti). Per queste sotto-configurazioni puoi guardare la pagina di manuale di `git config`. From 888599ff6927e874ea5b9a0e4dc257c8f11a5b99 Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 14:46:19 +0900 Subject: [PATCH 083/291] Apply 7092f29 to ja tree --- ja/01-introduction/01-chapter1.markdown | 2 +- ja/03-git-branching/01-chapter3.markdown | 4 ++-- ja/05-distributed-git/01-chapter5.markdown | 2 +- ja/07-customizing-git/01-chapter7.markdown | 2 +- ja/08-git-and-other-scms/01-chapter8.markdown | 8 ++++---- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown index 039eb307e..9dc643ca3 100644 --- a/ja/01-introduction/01-chapter1.markdown +++ b/ja/01-introduction/01-chapter1.markdown @@ -190,7 +190,7 @@ Windows利用時の注意点: この本で紹介されている複雑なコマ 今や、Gitがシステムにあります。Git環境をカスタマイズするためにしたい事が少しはあることでしょう。アップグレードの度についてまわるので、たった一度でそれらを終わらすべきでしょう。またそれらは、またコマンドを実行することによっていつでも変更することができます。 -Gitには、git configと呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。これらの変数は三つの異なる場所に格納されうります： +Gitには、`git config`と呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。これらの変数は三つの異なる場所に格納されうります： * `/etc/gitconfig` file: システム上の全てのユーザーと全てのリポジトリに対する設定値を保持します。もし`--system`オプションを`git config`に指定すると、明確にこのファイルに読み書きを行ないます。 * `~/.gitconfig` file: 特定のユーザーに対する設定値を保持します. `--global`オプションを指定することで、Gitに、明確にこのファイルに読み書きを行なわせることができます。 diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown index 6b16045b8..7d002206e 100644 --- a/ja/03-git-branching/01-chapter3.markdown +++ b/ja/03-git-branching/01-chapter3.markdown @@ -41,7 +41,7 @@ Insert 18333fig0303.png Insert 18333fig0304.png 図 3-4. 複数のブランチがコミットデータの履歴を指す例 -Git は、あなたが今どのブランチで作業しているのかをどうやって知るのでしょうか? それを保持する特別なポインタが HEAD と呼ばれるものです。これは、Subversion や CVS といった他の VCS における HEAD の概念とはかなり違うものであることに注意しましょう。Git では、HEAD はあなたが作業しているローカルブランチへのポインタとなります。今回の場合は、あなたはまだ master ブランチにいます。git branch コマンドは新たにブランチを作成するだけであり、そのブランチに切り替えるわけではありません (図 3-5 を参照ください)。 +Git は、あなたが今どのブランチで作業しているのかをどうやって知るのでしょうか? それを保持する特別なポインタが HEAD と呼ばれるものです。これは、Subversion や CVS といった他の VCS における HEAD の概念とはかなり違うものであることに注意しましょう。Git では、HEAD はあなたが作業しているローカルブランチへのポインタとなります。今回の場合は、あなたはまだ master ブランチにいます。`git branch` コマンドは新たにブランチを作成するだけであり、そのブランチに切り替えるわけではありません (図 3-5 を参照ください)。 Insert 18333fig0305.png 図 3-5. 現在作業中のブランチを指す HEAD @@ -402,7 +402,7 @@ Insert 18333fig0323.png 手元での作業を同期させるには、`git fetch origin` コマンドを実行します。このコマンドは、まず origin が指すサーバー (今回の場合は `git.ourcompany.com`) を探し、まだ手元にないデータをすべて取得し、ローカルデータベースを更新し、`origin/master` が指す先を最新の位置に変更します (図 3-24 を参照ください)。 Insert 18333fig0324.png -図 3-24. git fetch コマンドによるリモートへの参照の更新 +図 3-24. `git fetch` コマンドによるリモートへの参照の更新 複数のリモートサーバーがあった場合にリモートのブランチがどのようになるのかを知るために、もうひとつ Git サーバーがあるものと仮定しましょう。こちらのサーバーは、チームの一部のメンバーが開発目的にのみ使用しています。このサーバーは `git.team1.ourcompany.com` にあるものとしましょう。このサーバーをあなたの作業中のプロジェクトから参照できるようにするには、第 2 章で紹介した `git remote add` コマンドを使用します。このリモートに `teamone` という名前をつけ、URL ではなく短い名前で参照できるようにします (図 3-25 を参照ください)。 diff --git a/ja/05-distributed-git/01-chapter5.markdown b/ja/05-distributed-git/01-chapter5.markdown index 2b68260f7..0c44af676 100644 --- a/ja/05-distributed-git/01-chapter5.markdown +++ b/ja/05-distributed-git/01-chapter5.markdown @@ -606,7 +606,7 @@ Git はその後、各パッチについてこのようなログ情報をはき これは、作業ディレクトリ内のファイルを変更します。`patch -p1` コマンドでパッチをあてるのとほぼ同じなのですが、それ以上に「これでもか」というほどのこだわりを持ってパッチを適用するので fuzzy マッチになる可能性が少なくなります。また、`git diff` 形式ではファイルの追加・削除やファイル名の変更も扱うことができますが、`patch` コマンドにはそれはできません。そして最後に、`git apply` は「全部適用するか、あるいは一切適用しないか」というモデルを採用しています。一方 `patch` コマンドの場合は、途中までパッチがあたった中途半端な状態になって困ることがあります。`git apply` のほうが、 `patch` よりもこだわりを持った処理を行うのです。`git apply` コマンドはコミットを作成するわけではありません。実行した後で、その変更をステージしてコミットする必要があります。 -git apply を使って、そのパッチをきちんと適用できるかどうかを事前に確かめることができます。パッチをチェックするには `git apply --check` を実行します。 +`git apply` を使って、そのパッチをきちんと適用できるかどうかを事前に確かめることができます。パッチをチェックするには `git apply --check` を実行します。 $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown index 860824fbe..86ea6fca3 100644 --- a/ja/07-customizing-git/01-chapter7.markdown +++ b/ja/07-customizing-git/01-chapter7.markdown @@ -511,7 +511,7 @@ RCSスタイルの`$Date$`キーワード展開もまた別の興味深い例で test/ export-ignore -これで、プロジェクトのtarballを作成するためにgitを実行した時、アーカイブには`test/`ディレクトリが含まれないようになります。 +これで、プロジェクトのtarballを作成するために`git archive`を実行した時、アーカイブには`test/`ディレクトリが含まれないようになります。 #### export-subst #### diff --git a/ja/08-git-and-other-scms/01-chapter8.markdown b/ja/08-git-and-other-scms/01-chapter8.markdown index 7b86af20e..6f41e8a70 100644 --- a/ja/08-git-and-other-scms/01-chapter8.markdown +++ b/ja/08-git-and-other-scms/01-chapter8.markdown @@ -203,7 +203,7 @@ Git と Subversion の橋渡しをするコマンド群のベースとなるコ ### Git でのブランチに関する問題 ### -Git のワークフローに慣れてくると、トピックブランチを作ってそこで作業を行い、それをマージすることもあるでしょう。git svn を使って Subversion サーバーにプッシュする場合は、それらのブランチをまとめてプッシュするのではなく一つのブランチ上にリベースしてからプッシュしたくなるかもしれません。リベースしたほうがよい理由は、Subversion はリニアに歴史を管理していて Git のようなマージができないからです。git svn がスナップショットを Subversion のコミットに変換するときには、最初の親だけに続けます。 +Git のワークフローに慣れてくると、トピックブランチを作ってそこで作業を行い、それをマージすることもあるでしょう。`git svn` を使って Subversion サーバーにプッシュする場合は、それらのブランチをまとめてプッシュするのではなく一つのブランチ上にリベースしてからプッシュしたくなるかもしれません。リベースしたほうがよい理由は、Subversion はリニアに歴史を管理していて Git のようなマージができないからです。`git svn` がスナップショットを Subversion のコミットに変換するときには、最初の親だけに続けます。 歴史が次のような状態になっているものとしましょう。`experiment` ブランチを作ってそこで 2 回のコミットを済ませ、それを `master` にマージしたところです。ここで `dcommit` すると、出力はこのようになります。 @@ -232,7 +232,7 @@ Git のワークフローに慣れてくると、トピックブランチを作 ### Subversion のブランチ ### -Subversion のブランチは Git のブランチとは異なります。可能ならば、Subversion のブランチは使わないようにするのがベストでしょう。しかし、Subversion のブランチの作成やコミットも、git svn を使ってすることができます。 +Subversion のブランチは Git のブランチとは異なります。可能ならば、Subversion のブランチは使わないようにするのがベストでしょう。しかし、Subversion のブランチの作成やコミットも、`git svn` を使ってすることができます。 #### 新しい SVN ブランチの作成 #### @@ -501,7 +501,7 @@ Subversion や Perforce 以外のシステムを使っている場合は、そ Git のディレクトリにインポートするにはまず、これらのデータをどのように Git に格納するかをレビューしなければなりません。Git は基本的にはコミットオブジェクトのリンクリストであり、コミットオブジェクトがコンテンツのスナップショットを指しています。`fast-import` に指示しなければならないのは、コンテンツのスナップショットが何でどのコミットデータがそれを指しているのかということと、コミットデータを取り込む順番だけです。ここでは、スナップショットをひとつずつたどって各ディレクトリの中身をさすコミットオブジェクトを作り、それらを日付順にリンクさせるものとします。 -第 7 章の「Git ポリシーの実施例」同様、ここでも Ruby を使って書きます。ふだんから使いなれており、きっと他の方にも読みやすいであろうからです。このサンプルをあなたの使いなれた言語で書き換えるのも簡単でしょう。単に適切な情報を標準出力に送るだけなのだから。また、Windows を使っている場合は、行末にキャリッジリターンを含めないように注意が必要です。git fast-import が想定している行末は LF だけであり、Windows で使われている CRLF は想定していません。 +第 7 章の「Git ポリシーの実施例」同様、ここでも Ruby を使って書きます。ふだんから使いなれており、きっと他の方にも読みやすいであろうからです。このサンプルをあなたの使いなれた言語で書き換えるのも簡単でしょう。単に適切な情報を標準出力に送るだけなのだから。また、Windows を使っている場合は、行末にキャリッジリターンを含めないように注意が必要です。`git fast-import` が想定している行末は LF だけであり、Windows で使われている CRLF は想定していません。 まず最初に対象ディレクトリに移動し、コミットとしてインポートするスナップショットとしてサブディレクトリを識別します。基本的なメインループは、このようになります。 @@ -602,7 +602,7 @@ Git のディレクトリにインポートするにはまず、これらのデ return mark -注意: Windows 上で動かす場合はさらにもう一手間必要です。先述したように、Windows の改行文字は CRLF ですが git fast-import は LF にしか対応していません。この問題に対応して git fast-import をうまく動作させるには、CRLF ではなく LF を使うよう ruby に指示しなければなりません。 +注意: Windows 上で動かす場合はさらにもう一手間必要です。先述したように、Windows の改行文字は CRLF ですが `git fast-import` は LF にしか対応していません。この問題に対応して `git fast-import` をうまく動作させるには、CRLF ではなく LF を使うよう ruby に指示しなければなりません。 $stdout.binmode From 468fc7712a9667064c1c7dda5a866de3ea2cec9d Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 14:54:10 +0900 Subject: [PATCH 084/291] Apply 0ecb879 to ja tree --- ja/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown index 5aa3b77e5..af26092c6 100644 --- a/ja/04-git-server/01-chapter4.markdown +++ b/ja/04-git-server/01-chapter4.markdown @@ -118,7 +118,7 @@ Git サーバーを立ち上げるには、既存のリポジトリをエクス Cloning into bare repository 'my_project.git'... done. -このコマンドを実行したときの出力はちょっとわかりにくいかもしれません。`clone` は基本的に `git init` をしてから `git fetch` をするのと同じことなので、`git init` の部分の出力も見ることになります。そのメッセージは「空のディレクトリを作成しました」というものです。実際にどんなオブジェクトの転送が行われたのかは何も表示されませんが、きちんと転送は行われています。これで、`my_project.git` ディレクトリに Git リポジトリのデータができあがりました。 +そうすると、Git ディレクトリのデータを `my_project.git` ディレクトリにコピーできます。 これは、おおざっぱに言うと次の操作と同じようなことです。 From caa686a5648baf26a92d0e40282c4b317e94b06a Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 14:59:59 +0900 Subject: [PATCH 085/291] Apply 1786822 to ja tree --- ja/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/05-distributed-git/01-chapter5.markdown b/ja/05-distributed-git/01-chapter5.markdown index 0c44af676..5dd8964f2 100644 --- a/ja/05-distributed-git/01-chapter5.markdown +++ b/ja/05-distributed-git/01-chapter5.markdown @@ -627,7 +627,7 @@ Git はその後、各パッチについてこのようなログ情報をはき Limit log functionality to the first 20 -先ほどのセクションでごらんいただいたように、format-patch コマンドの出力結果もこれと同じ形式で始まっていますね。これは、mbox 形式のメールフォーマットとしても正しいものです。git send-email を正しく使ったパッチが送られてきた場合、受け取ったメールを mbox 形式で保存して git am コマンドでそのファイルを指定すると、すべてのパッチの適用が始まります。複数のメールをまとめてひとつの mbox に保存できるメールソフトを使っていれば、送られてきたパッチをひとつのファイルにまとめて git am で一度に適用することもできます。 +先ほどのセクションでごらんいただいたように、format-patch コマンドの出力結果もこれと同じ形式で始まっていますね。これは、mbox 形式のメールフォーマットとしても正しいものです。`git send-email` を正しく使ったパッチが送られてきた場合、受け取ったメールを mbox 形式で保存して `git am` コマンドでそのファイルを指定すると、すべてのパッチの適用が始まります。複数のメールをまとめてひとつの mbox に保存できるメールソフトを使っていれば、送られてきたパッチをひとつのファイルにまとめて `git am` で一度に適用することもできます。 しかし、`format-patch` で作ったパッチがチケットシステム (あるいはそれに類する何か) にアップロードされたような場合は、まずそのファイルをローカルに保存して、それを `git am` に渡すことになります。 From 71736c19716b13c62e1f46171bbbe2ac524ae735 Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 15:04:54 +0900 Subject: [PATCH 086/291] Apply 20a3f53 to ja tree --- ja/06-git-tools/01-chapter6.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown index 84519bda2..15e854955 100644 --- a/ja/06-git-tools/01-chapter6.markdown +++ b/ja/06-git-tools/01-chapter6.markdown @@ -476,8 +476,8 @@ apply オプションは、スタックに隠した作業を再度適用する $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) From 3e51e0c1194cd76d834736fafdb22c8d969ac20d Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 15:09:17 +0900 Subject: [PATCH 087/291] Apply 9c4252b to ja tree --- ja/06-git-tools/01-chapter6.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown index 15e854955..90a2342e9 100644 --- a/ja/06-git-tools/01-chapter6.markdown +++ b/ja/06-git-tools/01-chapter6.markdown @@ -441,8 +441,8 @@ simplegit.rb のステータスがおもしろいことになっています。 $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log この例では、以前にも二回ほど作業を隠していたようです。そこで、三種類の異なる作業にアクセスできるようになっています。先ほど隠した変更を再度適用するには、stash コマンドの出力に書かれていたように `git stash apply` コマンドを実行します。それよりもっと前に隠したものを適用したい場合は `git stash apply stash@{2}` のようにして名前を指定することもできます。名前を指定しなければ、Git は直近に隠された変更を再適用します。 From 074f6f806f0b655d4b4814a0bc29c15154505c3e Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 15:10:18 +0900 Subject: [PATCH 088/291] Apply 5f72fef to ja tree --- ja/06-git-tools/01-chapter6.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown index 90a2342e9..40379d5ee 100644 --- a/ja/06-git-tools/01-chapter6.markdown +++ b/ja/06-git-tools/01-chapter6.markdown @@ -81,13 +81,13 @@ SHA-1 の衝突を見るにはどうしたらいいのか、ひとつの例を 参照ログを見るには `git reflog` を使います。 $ git reflog - 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated - d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. - 1c002dd... HEAD@{2}: commit: added some blame and merge stuff - 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD - 95df984... HEAD@{4}: commit: # This is a combination of two commits. - 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD - 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD + 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated + d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. + 1c002dd HEAD@{2}: commit: added some blame and merge stuff + 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD + 95df984 HEAD@{4}: commit: # This is a combination of two commits. + 1c36188 HEAD@{5}: rebase -i (squash): updating HEAD + 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD 何らかの理由でブランチの先端が更新されるたびに、Git はその情報をこの一時履歴に格納します。そして、このデータを使って過去のコミットを指定することもできます。リポジトリの HEAD の五つ前の状態を知りたい場合は、先ほど見た reflog の出力のように `@{n}` 形式で参照することができます。 From 6dfa9e1ff7d35612596208429b70e505a9a5b4d5 Mon Sep 17 00:00:00 2001 From: harupong Date: Fri, 20 Jun 2014 15:16:57 +0900 Subject: [PATCH 089/291] Apply f987da8 to ja tree --- ja/07-customizing-git/01-chapter7.markdown | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown index 86ea6fca3..4050bdcf9 100644 --- a/ja/07-customizing-git/01-chapter7.markdown +++ b/ja/07-customizing-git/01-chapter7.markdown @@ -613,14 +613,12 @@ update スクリプトは `pre-receive` スクリプトと似ていますが、 #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -ああ、グローバル変数を使ってるとかいうツッコミは勘弁してください。このほうが説明が楽なので。 + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### 特定のコミットメッセージ書式の強制 #### From 5c868cd9538db8c48250fd1bb46ba45e2fcde77c Mon Sep 17 00:00:00 2001 From: harupong Date: Thu, 26 Jun 2014 15:28:43 +0900 Subject: [PATCH 090/291] Apply f5170bb to ja tree --- ja/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown index b78d99bf7..fdc4f7980 100755 --- a/ja/02-git-basics/01-chapter2.markdown +++ b/ja/02-git-basics/01-chapter2.markdown @@ -323,7 +323,7 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも あるいは、コミットメッセージをインラインで記述することもできます。その場合は、`commit` コマンドの後で `-m` フラグに続けて次のように記述します。 $ git commit -m "Story 182: Fix benchmarks for speed" - [master 463dc4f] Fix benchmarks for speed + [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README From bf8c8bb47d2fc16ac21f5562da62b02a4a2d27e5 Mon Sep 17 00:00:00 2001 From: harupong Date: Thu, 26 Jun 2014 16:27:02 +0900 Subject: [PATCH 091/291] Apply #750 #787 to ja tree Also applied 038f1f0 as it is related to those two pull requests. --- ja/02-git-basics/01-chapter2.markdown | 56 ++++++++++++++++++++++++--- 1 file changed, 50 insertions(+), 6 deletions(-) diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown index fdc4f7980..2bfd2962a 100755 --- a/ja/02-git-basics/01-chapter2.markdown +++ b/ja/02-git-basics/01-chapter2.markdown @@ -650,15 +650,59 @@ The lines must be formatted as follows オプション 説明 -(n) 直近の n 件のコミットのみを表示する - --since, --after 指定した日付以降のコミットのみに制限する - --until, --before 指定した日付以前のコミットのみに制限する + --since, --after 指定した日付/時刻以降のCommitDateのコミットのみに制限する + --until, --before 指定した日付/時刻以前のCommitDateのコミットのみに制限する --author エントリが指定した文字列にマッチするコミットのみを表示する --committer エントリが指定した文字列にマッチするコミットのみを表示する -たとえば、Git ソースツリーのテストファイルに対する変更があったコミットのうち、Junio Hamano がコミットしたもの (マージは除く) で 2008 年 10 月に行われたものを知りたければ次のように指定します。 +### 日時にもとづくログ出力の制限 ### - $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ - --before="2008-11-01" --no-merges -- t/ +Git のリポジトリ(git://git.kernel.org/pub/scm/git/git.git)からCommitDateを使ってコミットを検索してみましょう。パソコンに設定されたタイムゾーンにおける2014/04/29のコミットを検索するには、以下のコマンドを実行します。 + + $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ + --pretty=fuller + +この場合、コマンドの結果はパソコンのタイムゾーン設定ごとに異なってしまいます。それを避けるには、タイムゾーンを含むISO 8601フォーマットのような日時を `--after` や `--before` の引数に指定するといいでしょう。そうすれば、上述のケースのようにコマンド実行結果が異なる可能性がなくなります。 + +特定日時(例として、中央ヨーロッパ時間で2013/04/29 17:07:22)を指定してコミットを検索するには、以下のコマンドを使います。 + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller + + commit de7c201a10857e5d424dbd8db880a6f24ba250f9 + Author: Ramkumar Ramachandra + AuthorDate: Mon Apr 29 18:19:37 2013 +0530 + Commit: Junio C Hamano + CommitDate: Mon Apr 29 08:07:22 2013 -0700 + + git-completion.bash: lexical sorting for diff.statGraphWidth + + df44483a (diff --stat: add config option to limit graph width, + 2012-03-01) added the option diff.startGraphWidth to the list of + configuration variables in git-completion.bash, but failed to notice + that the list is sorted alphabetically. Move it to its rightful place + in the list. + + Signed-off-by: Ramkumar Ramachandra + Signed-off-by: Junio C Hamano + +これらの日時(`AuthorDate` と `CommitDate`)はGitのデフォルトフォーマット(`--date=default` オプション相当)です。作者とコミッター、それぞれのタイムゾーン情報を表示します。 + +日時フォーマットの指定は他にも `--date=iso` (ISO 8601)、`--date=rfc` (RFC 2822)、`--date=raw` (Unix時間)、`--date=local` (端末のタイムゾーン)、`--date=relative`("2 hours ago"のように相対的な指定)などがあります。 + +また、 `git log` 実行時に日時指定を省略すると、パソコンの時計をもとにコマンド実行日時を指定日時として使用します(協定標準時からの時差も同一になります)。 + +具体的には、仮にパソコンの時計が09:00を指していて、かつタイムゾーン設定が協定標準時プラス3時間の場合、以下の `git log` コマンドの日時指定は同一として扱われます。 + + $ git log --after=2008-06-01 --before=2008-07-01 + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" + +もう一つ例を挙げておきましょう。Git ソースツリーのテストファイルに対する変更があったコミットのうち、Junio Hamano がコミットしたもの (マージは除く) で 2008 年 10 月(ニューヨークのタイムゾーン)に行われたものを知りたければ次のように指定します。 + + $ git log --pretty="%h - %s" --author=gitster \ + --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi @@ -666,7 +710,7 @@ The lines must be formatted as follows 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -約 20,000 件におよぶ Git ソースコードのコミットの歴史の中で、このコマンドの条件にマッチするのは 6 件となります。 +約 36,000 件におよぶ Git ソースコードのコミットの歴史の中で、このコマンドの条件にマッチするのは 6 件となります。 ### GUI による歴史の可視化 ### From c3d1c382901a56433e3f6693345a7f0a4548278f Mon Sep 17 00:00:00 2001 From: harupong Date: Tue, 1 Jul 2014 15:26:52 +0900 Subject: [PATCH 092/291] Fix indent for pdf table output --- ja/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown index 2bfd2962a..775f52e51 100755 --- a/ja/02-git-basics/01-chapter2.markdown +++ b/ja/02-git-basics/01-chapter2.markdown @@ -650,8 +650,8 @@ The lines must be formatted as follows オプション 説明 -(n) 直近の n 件のコミットのみを表示する - --since, --after 指定した日付/時刻以降のCommitDateのコミットのみに制限する - --until, --before 指定した日付/時刻以前のCommitDateのコミットのみに制限する + --since, --after 指定した日付/時刻以降のCommitDateのコミットのみに制限する + --until, --before 指定した日付/時刻以前のCommitDateのコミットのみに制限する --author エントリが指定した文字列にマッチするコミットのみを表示する --committer エントリが指定した文字列にマッチするコミットのみを表示する From f138201bbd15091db65eb5c25797e10a9921510c Mon Sep 17 00:00:00 2001 From: cor Date: Mon, 7 Jul 2014 15:01:11 +0200 Subject: [PATCH 093/291] [NL] resynchronized with 4cefec --- nl/01-introduction/01-chapter1.markdown | 4 +- nl/02-git-basics/01-chapter2.markdown | 70 +++++++++++++++---- nl/03-git-branching/01-chapter3.markdown | 4 +- nl/04-git-server/01-chapter4.markdown | 4 +- nl/05-distributed-git/01-chapter5.markdown | 6 +- nl/06-git-tools/01-chapter6.markdown | 6 +- nl/07-customizing-git/01-chapter7.markdown | 16 ++--- nl/08-git-and-other-scms/01-chapter8.markdown | 10 +-- nl/09-git-internals/01-chapter9.markdown | 4 +- 9 files changed, 83 insertions(+), 41 deletions(-) diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown index 2a6870648..458169187 100644 --- a/nl/01-introduction/01-chapter1.markdown +++ b/nl/01-introduction/01-chapter1.markdown @@ -33,10 +33,10 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Aan de slag # -In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen bij het begin beginnen door wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt. Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan. +In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen beginnen met wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt. Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan. ## Het wat en waarom van versiebeheer ## diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown index 1df052bc7..a87e88310 100644 --- a/nl/02-git-basics/01-chapter2.markdown +++ b/nl/02-git-basics/01-chapter2.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # De basis van Git # Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen naar en pullen van repositories. @@ -358,7 +358,7 @@ Je kunt zien dat de standaard commit boodschap de laatste output van het `git st Als alternatief kun je de commit boodschap met het `commit` commando meegeven door hem achter de `-m` optie te specificeren, zoals hier: $ git commit -m "Story 182: Fix benchmarks for speed" - [master 463dc4f] Fix benchmarks for speed + [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README @@ -440,20 +440,20 @@ Het is daarom een beetje verwarrend dat Git een `mv` commando heeft. Als je een en dat werkt prima. Sterker nog, als je zoiets als dit uitvoert en naar de status kijkt, zul je zien dat Git het als een hernoemd bestand beschouwt: - $ git mv README.txt README + $ git mv README README.txt $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) - renamed: README.txt -> README + renamed: README -> README.txt Maar dat is gelijk aan het uitvoeren van het volgende: - $ mv README.txt README - $ git rm README.txt - $ git add README + $ mv README README.txt + $ git rm README + $ git add README.txt Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het `mv` commando. Het enige echte verschil is dat het `mv` commando slechts één commando is in plaats van drie. En belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen voordat je commit. @@ -682,15 +682,59 @@ The lines must be formatted as follows Optie Omschrijving -(n) Laat alleen de laatste n commits zien - --since, --after Limiteer de commits tot degenen na de gegeven datum. - --until, --before Limiteer de commits tot degenen voor de gegeven datum. + --since, --after Limiteer de commits tot degenen waarvan de CommitDate op of na de gegeven datum/tijd ligt. + --until, --before Limiteer de commits tot degenen waarvan de CommitDate op of voor de gegeven datum/tijd ligt. --author Laat alleen de commits zien waarvan de auteur bij de gegeven tekst past. --committer Laat alleen de commits zien waarvan de committer bij de gegeven tekst past. -Bijvoorbeeld, als je wilt zien welke commits test bestanden in de Git broncode geschiedenis aanpasten waarvan de committer Junio Hamano is en die in de maand oktober van 2008 gemerged zijn, kun je zoiets als dit uitvoeren: +### Log uitvoer beperken volgens datum/tijd ### + +Om te bepalen welke commits in de Git broncode repository aanwezig zijn (git://git.kernel.org/pub/scm/git/git.git) met een CommitDate van 2014-04-29 relatief aan je lokale tijdzone (zoals ingesteld op jouw computer), gebruik je + + $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ + --pretty=fuller + +Omdat de uitvoer zal verschillen met de tijdzone waar dit commando wordt gegeven, wordt het aangeraden om altijd een absolute tijd zoals volgens het ISO 8601 formaat (welke tijdzone informatie bevat) als argument bij `--after` and `--before` te gebruiken, zodat iedereen die het commando geeft dezelfde herhaalbare resultaten krijgt. + +Om de commits gemaakt op een specifiek moment in de tijd te krijgen (bijv. 29 April 2013 om 17:07:22 CET), kunnen we dit gebruiken + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller + + commit de7c201a10857e5d424dbd8db880a6f24ba250f9 + Author: Ramkumar Ramachandra + AuthorDate: Mon Apr 29 18:19:37 2013 +0530 + Commit: Junio C Hamano + CommitDate: Mon Apr 29 08:07:22 2013 -0700 + + git-completion.bash: lexical sorting for diff.statGraphWidth + + df44483a (diff --stat: add config option to limit graph width, + 2012-03-01) added the option diff.startGraphWidth to the list of + configuration variables in git-completion.bash, but failed to notice + that the list is sorted alphabetically. Move it to its rightful place + in the list. + + Signed-off-by: Ramkumar Ramachandra + Signed-off-by: Junio C Hamano + +De bovenstaande tijden (`AuthorDate`, `CommitDate`) worden getoond in het standaard formaat (`--date=default`), welke de tijdzone informatie van respectievelijk de auteur en committer weergeeft. + +Andere nuttige formaten zijn onder andere `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconden sinds de "epoch" (1970-01-01 UTC)) `--date=local` (tijden volgens jouw locale tijdzone) alsmede `--date=relative` (bijv. "2 hours ago"). + +Als het commando `git log` zonder tijdsaanduiding gebruikt wordt, wordt de tijd van je computer aangehouden op het moment dat het commando wordt uitgevoerd (met behoud van het relatieve verschil met UTC). + +Bijvoorbeeld, het uitvoeren van een `git log` commando om 09:00 op jouw computer waarbij je tijdzone op dat moment 3 uur voorloopt op UTC, maakt de uitvoer van de volgende twee commando's gelijk: + + $ git log --after=2008-06-01 --before=2008-07-01 + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" + +Als laatste voorbeeld, als je commits wilt zien die de testbestanden wijzigen in de Git sourcecode geschiedenis die door Junio Hamano gecommit waren met de CommitDate in de maand oktober 2008 (relatief tot de tijdzone van New York) en die geen merges waren, kan je bijvoorbeeld het volgende commando typen: - $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ - --before="2008-11-01" --no-merges -- t/ + $ git log --pretty="%h - %s" --author=gitster \ + --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi @@ -698,7 +742,7 @@ Bijvoorbeeld, als je wilt zien welke commits test bestanden in de Git broncode g 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -Van de bijna 20.000 commits in de Git broncode historie, laat dit commando de 6 zien die bij die criteria passen. +Van de bijna 36.000 commits in de Git broncode historie, laat dit commando de 6 zien die bij die criteria passen. ### Een grafische interface gebruiken om de historie te visualiseren ### diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown index 9032bea63..f0439bf51 100644 --- a/nl/03-git-branching/01-chapter3.markdown +++ b/nl/03-git-branching/01-chapter3.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Branchen in Git # Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd-ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staat, wat lang kan duren voor grote projecten. @@ -440,7 +440,7 @@ Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server pusht laa Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master`-verwijzing naar zijn nieuwe positie verplaatst wordt die meer up-to-date is (zie Figuur 3-24). Insert 18333fig0324.png -Figuur 3-24. Het git fetch commando vernieuwt je remote referenties. +Figuur 3-24. Het `git fetch` commando vernieuwt je remote referenties. Om het hebben van meerdere remote servers te tonen en hoe remote branches voor die remote projecten eruitzien, zullen we aannemen dat je nog een interne Git-server hebt die alleen wordt gebruikt voor ontwikkeling gedaan door een van je sprint teams. Deze server bevindt zich op `git.team1.ourcompany.com`. Je kunt het als een nieuwe remote referentie toevoegen aan het project waar je nu aan werkt door het `git remote add` commando uit te voeren, zoals we behandeld hebben in Hoofdstuk 2. Noem deze remote `teamone`, wat jouw afkorting voor die hele URL wordt (zie Figuur 3-25). diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown index 78f101c69..4ddf3e9fc 100644 --- a/nl/04-git-server/01-chapter4.markdown +++ b/nl/04-git-server/01-chapter4.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Git op de server # Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote Git repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is; het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de "Git server" noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben. @@ -156,7 +156,7 @@ Om je repository te clonen met als doel het maken van een kale repository, voer Cloning into bare repository 'my_project.git'... done. -De output van dit commando is een beetje verwarrend. Het commando `clone` is eigenlijk een `git init` en dan een `git fetch`, wat we hier zien is de output van het `git init` gedeelte wat een lege directory aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git directory data in je `my_project.git` directory moeten hebben. +Nu zou je een kopie van de Git directory data in je `my_project.git` directory moeten hebben. Dit is grofweg gelijk aan dit diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown index 9baad756a..231734e24 100644 --- a/nl/05-distributed-git/01-chapter5.markdown +++ b/nl/05-distributed-git/01-chapter5.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Gedistribueerd Git # Nu je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale workflow, zul je hier zien hoe je een paar gedistribueerde workflows kunt gebruiken die je met Git kunt bereiken. @@ -650,7 +650,7 @@ Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de `git Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer paranoïde is en minder "fuzzy matches" accepteert dan patch. Het handelt ook het toevoegen, verwijderen, en hernoemen van bestanden af als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werkdirectory in een vreemde status achterblijft. Over het algemeen is `git apply` meer paranoïde dan `patch`. Het zal geen commit voor je aanmaken: na het uitvoeren moet je de geïntroduceerde wijzigingen handmatig stagen en committen. -Je kunt ook git apply gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch: +Je kunt ook `git apply` gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch: $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 @@ -671,7 +671,7 @@ Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Limit log functionality to the first 20 -Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze één voor één toe te passen. +Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van `git send-email` en je downloadt dat in een mbox formaat, dan kan je het `git am` naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan `git am` gebruiken om ze één voor één toe te passen. Maar, als iemand een patch bestand heeft geüpload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het te applyen: diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown index 6ff291d40..d4cc79d8f 100644 --- a/nl/06-git-tools/01-chapter6.markdown +++ b/nl/06-git-tools/01-chapter6.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Git tools # Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers. @@ -518,8 +518,8 @@ De apply optie probeert alleen het gestashete werk toe te passen - je blijft op $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown index 03feaf471..b1bb95223 100644 --- a/nl/07-customizing-git/01-chapter7.markdown +++ b/nl/07-customizing-git/01-chapter7.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Git op maat maken # Tot zover heb ik de fundamentele werking van Git behandeld en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git tot je beschikking stelt om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een maat gemaakte manier te laten werken middels het introduceren van een aantal belangrijke configuratie-instellingen en het inhaak-systeem (hooks). Met deze tools is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het nodig hebben. @@ -548,7 +548,7 @@ Bijvoorbeeld, stel dat je wat testbestanden in een `test/` subdirectory hebt, en test/ export-ignore -Als je nu git archive uitvoert om een tarball van je project te maken, zal die map niet meegenomen worden in het archief. +Als je nu `git archive` uitvoert om een tarball van je project te maken, zal die map niet meegenomen worden in het archief. #### export-subst #### @@ -650,14 +650,12 @@ Al het werk aan de server kant zal in het update bestand in je hooks directory g #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -Ja, ik gebruik globale variabelen. Schiet me niet af – het is makkelijker om het op deze manier te laten zien. + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### Een specifiek commit-bericht formaat afdwingen #### diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown index 32e0b9ccd..8a17493e8 100644 --- a/nl/08-git-and-other-scms/01-chapter8.markdown +++ b/nl/08-git-and-other-scms/01-chapter8.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Git en andere systemen # Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, het bidirectionele Subversion uitwissel tool van Git. @@ -238,7 +238,7 @@ Regelmatig `git svn rebase` uitvoeren zorgt er voor dat je code altijd up to dat ### Git branch problemen ### -Als je gewend geraakt bent aan een Git workflow, zal je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan terug mergen. Als je naar een Subversion server pusht via git svn, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen te mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus git svn volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden. +Als je gewend geraakt bent aan een Git workflow, zal je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan terug mergen. Als je naar een Subversion server pusht via `git svn`, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen te mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus `git svn` volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden. Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch gemaakt, twee commits gedaan en ze dan terug in `master` gemerged. Als je dan `dcommit` zie je output zoals dit: @@ -267,7 +267,7 @@ Als iemand anders dat werk cloned, is alles wat ze zien de merge commit met al h ### Subversion branchen ### -Branchen in Subversion is niet hetzelfde als branchen in Git; het is waarschijnlijk het beste om het zoveel mogelijk te vermijden. Maar, je kunt Subversion branches maken en daarnaar committen met git svn. +Branchen in Subversion is niet hetzelfde als branchen in Git; het is waarschijnlijk het beste om het zoveel mogelijk te vermijden. Maar, je kunt Subversion branches maken en daarnaar committen met `git svn`. #### Een nieuwe SVN branch maken #### @@ -535,7 +535,7 @@ Voor een korte demonstratie ga je een eenvoudige importeerder schrijven. Stel da Om naar een Git directory te importeren, moet je nalezen hoe Git zijn data opslaat. Je kunt je misschien herinneren dat Git eigenlijk een gelinkte lijst is met commit objecten die naar een snapshot van de inhoud wijzen. Het enige dat je hoeft te doen, is `fast-import` vertellen wat de inhoud snapshots zijn, welke commit data er naar wijst en de volgorde waarin ze moeten staan. Je strategie zal bestaan uit het doorlopen van de snapshots en commits te creëren met de inhoud van iedere directory, waarbij je iedere commit terug linkt met de vorige. -Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in hetgeen waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want git fast-import is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de cariage return line feeds (CRLF) die Windows gebruikt. +Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in hetgeen waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want `git fast-import` is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de carriage return line feeds (CRLF) die Windows gebruikt. Om te beginnen ga je naar de doeldirectory en identificeert iedere subdirectory, waarvan elk een snapshot is dat je als commit wil importeren. Dan ga je in iedere subdirectory en print de noodzakelijke commando's om ze te exporteren. Je basis hoofdlus ziet er zo uit: @@ -637,7 +637,7 @@ Het laatste wat je moet doen is het huidige kenmerk teruggeven, zodat het meegeg return mark -LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is, gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en git fast-import blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken: +LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is, gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en `git fast-import` blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken: $stdout.binmode diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown index 51c798a3f..ac6228145 100644 --- a/nl/09-git-internals/01-chapter9.markdown +++ b/nl/09-git-internals/01-chapter9.markdown @@ -33,7 +33,7 @@ vertaling moeten proberen te maken. Veel succes en plezier bij het vertalen... --> - + # Het binnenwerk van Git # Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een voorafgaand hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt; hoe dan ook, hier is waar het binnenwerk en implementatie van Git behandeld gaat worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik de behandeling hiervan het laatste hoofdstuk gemaakt in het boek, zodat je kunt besluiten om het het vroeg of later in je leerproces kunt lezen. Ik laat het aan jou over om dat te beslissen. @@ -63,7 +63,7 @@ Als je `git init` uitvoert in een nieuwe of bestaande directory, zal Git de dire objects/ refs/ -Je zou hier een paar andere bestanden kunnen zien, maar dit is een verse `git init` repository - dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar die je niet wilt opnemen in een .gitignore bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, deze zijn in detail behandeld in Hoofdstuk 7. +Je zou hier een paar andere bestanden kunnen zien, maar dit is een verse `git init` repository - dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar die je niet wilt opnemen in een `.gitignore` bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, deze zijn in detail behandeld in Hoofdstuk 7. Dit laat vier belangrijke vermeldingen over: de bestanden `HEAD` en `index`, en de directories `objects` en `refs`. Dit zijn de kernbestanddelen van Git. De directory `objects` bevat alle inhoud van je databank, de directory `refs` bevat verwijzingen naar commitobjecten (branches) in die databank, het bestand `HEAD` wijst naar de branch die je op dit moment uitgecheckt hebt, en het bestand `index` is waar Git de informatie van je staging area (wachtrij) opslaat. We gaan nu gedetaileerd naar elk van deze onderdelen kijken om te laten zien hoe Git werkt. From 971cf63ed1553970685939997dd2201e6e55511e Mon Sep 17 00:00:00 2001 From: Kangyi Zhu Date: Tue, 8 Jul 2014 20:55:54 +0800 Subject: [PATCH 094/291] [zh] Fix a missing word in 01-chapter6 "All the changes from your Rack project are merged in and ready to be committed locally." The word "and" is missed in the translation. --- zh/06-git-tools/01-chapter6.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown index 948b1ff1d..b0929d272 100644 --- a/zh/06-git-tools/01-chapter6.markdown +++ b/zh/06-git-tools/01-chapter6.markdown @@ -1110,7 +1110,7 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库 Squash commit -- not updating HEAD Automatic merge went well; stopped before committing as requested -所有 Rack 项目的变更都被归并可以进行本地提交。你也可以做相反的事情——在你主分支的`rack`目录里进行变更然后归并回`rack_branch`分支，然后将它们提交给维护者或者推送到上游。 +所有 Rack 项目的变更都被归并并且可以进行本地提交。你也可以做相反的事情——在你主分支的`rack`目录里进行变更然后归并回`rack_branch`分支，然后将它们提交给维护者或者推送到上游。 为了得到`rack`子目录和你`rack_branch`分支的区别——以决定你是否需要归并它们——你不能使用一般的`diff`命令。而是对你想比较的分支运行`git diff-tree`： From d481a879e337300ec08786faf4d9c974fb25597d Mon Sep 17 00:00:00 2001 From: Soon Van Date: Wed, 9 Jul 2014 20:45:54 -0400 Subject: [PATCH 095/291] Add -L flag to cURL command to follow any redirects cURL by default will not follow redirects, leading to blank file unless the `-L` flag is included since all resources once hosted on raw.github.com are now on the raw.githubusercontent.com domain. Fixes issue mentioned at https://github.com/git/git-scm.com/issues/422 --- cs/09-git-internals/01-chapter9.markdown | 2 +- de/09-git-internals/01-chapter9.markdown | 2 +- en/09-git-internals/01-chapter9.markdown | 2 +- fr/09-git-internals/01-chapter9.markdown | 2 +- ja/09-git-internals/01-chapter9.markdown | 2 +- ko/09-git-internals/01-chapter9.markdown | 2 +- pl/09-git-internals/01-chapter9.markdown | 2 +- ru/09-git-internals/01-chapter9.markdown | 2 +- zh-tw/09-git-internals/01-chapter9.markdown | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown index 81708d2b4..83c7505fd 100644 --- a/cs/09-git-internals/01-chapter9.markdown +++ b/cs/09-git-internals/01-chapter9.markdown @@ -433,7 +433,7 @@ Vraťme se zpět do databáze objektů vašeho testovacího repozitáře Git. V Git komprimuje obsah těchto souborů metodou zlib a uložená data tak nejsou příliš velká. Všechny tyto soubory zabírají dohromady pouhých 925 bytů. Do repozitáře tak nyní přidáme větší objem dat, na němž si budeme moci ukázat jednu zajímavou funkci systému Git. Z knihovny Grit, s níž jsme pracovali před časem, přidejte soubor „repo.rb“. Je to soubor se zdrojovým kódem o velikosti asi 12 kB: - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/de/09-git-internals/01-chapter9.markdown b/de/09-git-internals/01-chapter9.markdown index 6f92c1d00..947c36bc9 100644 --- a/de/09-git-internals/01-chapter9.markdown +++ b/de/09-git-internals/01-chapter9.markdown @@ -596,7 +596,7 @@ Kommen wir noch einmal auf die Objekt-Datenbank zurück, die Du für Dein Test-R Git komprimiert die Inhalte dieser Dateien mit zlib und Du hast nicht sonderlich viele davon, sodass die Gesamtgröße der Dateien gerade mal 925 Bytes beträgt. Wir wollen ein anderes interessantes Feature von Git demonstrieren, und dazu müssen wir eine größere Datei hinzufügen, z.B. die `repo.rb` Datei aus der Grit-Bibliothek, die Du schon verwendet hast. Diese Datei ist eine etwa 12K große Quelltext-Datei: - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown index b638c04b7..354a44f16 100644 --- a/en/09-git-internals/01-chapter9.markdown +++ b/en/09-git-internals/01-chapter9.markdown @@ -433,7 +433,7 @@ Let’s go back to the objects database for your test Git repository. At this po Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. You’ll add some larger content to the repository to demonstrate an interesting feature of Git. Add the repo.rb file from the Grit library you worked with earlier — this is about a 12K source code file: - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/fr/09-git-internals/01-chapter9.markdown b/fr/09-git-internals/01-chapter9.markdown index ccf9eb886..9e881901d 100644 --- a/fr/09-git-internals/01-chapter9.markdown +++ b/fr/09-git-internals/01-chapter9.markdown @@ -544,7 +544,7 @@ Ajoutons de plus gros contenu au dépôt pour montrer une fonctionnalité intér Ajoutez le fichier `repo.rb` de la bibliothèque Grit que vous avez manipulé plus tôt. Il représente environ 12 Kio de code source : - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/ja/09-git-internals/01-chapter9.markdown b/ja/09-git-internals/01-chapter9.markdown index b3834a73a..133f5eaed 100644 --- a/ja/09-git-internals/01-chapter9.markdown +++ b/ja/09-git-internals/01-chapter9.markdown @@ -439,7 +439,7 @@ Git レポジトリ test のオブジェクトデータベースに戻りまし Git は zlib を使用してこれらのファイルのコンテンツを圧縮するため、多くを格納していません。これらすべてのファイルを集めても 925バイトにしかならないのです。Git の興味深い機能を実際に見るために、幾つか大きなコンテンツをレポジトリに追加してみましょう。前に作業したGritライブラリから `repo.rb` ファイルを追加します。これは約 12Kバイトのソースコードファイルです。 - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/ko/09-git-internals/01-chapter9.markdown b/ko/09-git-internals/01-chapter9.markdown index a30e480e8..51acb5422 100644 --- a/ko/09-git-internals/01-chapter9.markdown +++ b/ko/09-git-internals/01-chapter9.markdown @@ -432,7 +432,7 @@ Linux Kernel 저장소에도 커밋이 아닌 다른 개체를 가리키는 태 Git은 zlib으로 파일 내용을 압축하기 때문에 저장 공간이 많이 필요하지 않다. 그래서 이 데이터베이스에 저장된 파일은 겨우 925바이트밖에 되지 않는다. 크기가 큰 파일을 추가해서 이 기능의 효과를 좀 더 살펴보자. 앞 장에서 사용했던 Grit 라이브러리에 들어 있는 repo.rb 파일을 추가한다. 이 파일의 크기는 약 12K이다. - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/pl/09-git-internals/01-chapter9.markdown b/pl/09-git-internals/01-chapter9.markdown index 3bdd05268..9dafcad67 100644 --- a/pl/09-git-internals/01-chapter9.markdown +++ b/pl/09-git-internals/01-chapter9.markdown @@ -612,7 +612,7 @@ Git kompresuje zawartość tych plików za pomocą biblioteki zlib, a Ty nie mas - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/ru/09-git-internals/01-chapter9.markdown b/ru/09-git-internals/01-chapter9.markdown index 7fed573a4..7ec5b914b 100644 --- a/ru/09-git-internals/01-chapter9.markdown +++ b/ru/09-git-internals/01-chapter9.markdown @@ -433,7 +433,7 @@ Insert 18333fig0904.png Git сжал содержимое этих файлов при помощи zlib, к тому же мы не записывали много данных, поэтому все эти файлы вместе занимают всего 925 байт. Для того чтобы продемонстрировать одну интересную возможность Git'а, добавим файл побольше. Добавим файл repo.rb из библиотеки Grit, с которой мы работали ранее, он занимает примерно 12 Кбайт: - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb diff --git a/zh-tw/09-git-internals/01-chapter9.markdown b/zh-tw/09-git-internals/01-chapter9.markdown index 864290411..d7fadb1b1 100644 --- a/zh-tw/09-git-internals/01-chapter9.markdown +++ b/zh-tw/09-git-internals/01-chapter9.markdown @@ -433,7 +433,7 @@ Remote references 和分支(`refs/heads` references)的主要區別在於他們 Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，所有檔加起來總共僅用了 925 位元組。接下去你將添加一些大檔以演示 Git 的一個很有意思的功能。將你之前用到過的 Grit 庫中的 repo.rb 檔加進去 ── 這個原始程式碼檔大小約為 12K： - $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb From ceea34fc6c3fc44fceb1ba31de8f8020938af95e Mon Sep 17 00:00:00 2001 From: Yu Takasuka Date: Thu, 10 Jul 2014 22:22:43 +0800 Subject: [PATCH 096/291] [JP]Fix typo in chapter2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change to "時点" from "地点" --- ja/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown index 775f52e51..3d08a1a11 100755 --- a/ja/02-git-basics/01-chapter2.markdown +++ b/ja/02-git-basics/01-chapter2.markdown @@ -879,7 +879,7 @@ Paul の master ブランチは、ローカルでは `pb/master` としてアク ### リモートへのプッシュ ### -あなたのプロジェクトがみんなと共有できる状態に達したら、それを上流にプッシュしなければなりません。そのためのコマンドが `git push [remote-name] [branch-name]` です。master ブランチの内容を `origin` サーバー (何度も言いますが、クローンした地点でこのブランチ名とサーバー名が自動設定されます) にプッシュしたい場合は、このように実行します。 +あなたのプロジェクトがみんなと共有できる状態に達したら、それを上流にプッシュしなければなりません。そのためのコマンドが `git push [remote-name] [branch-name]` です。master ブランチの内容を `origin` サーバー (何度も言いますが、クローンした時点でこのブランチ名とサーバー名が自動設定されます) にプッシュしたい場合は、このように実行します。 $ git push origin master From 62e3eacaf7f2e442deb2166e23c15ec44b71086c Mon Sep 17 00:00:00 2001 From: Alec Clews Date: Thu, 16 Jan 2014 19:05:07 +1100 Subject: [PATCH 097/291] Added some brief details on BFG http://rtyley.github.io/bfg-repo-cleaner/ --- en/06-git-tools/01-chapter6.markdown | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 3eef10757..099b47ea4 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -1,4 +1,4 @@ -# Git Tools # + Git Tools # By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. @@ -690,7 +690,9 @@ Once again, this changes the SHAs of all the commits in your list, so make sure ### The Nuclear Option: filter-branch ### -There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. +There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. +The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. +However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. #### Removing a File from Every Commit #### @@ -730,6 +732,21 @@ Another common case is that you forgot to run `git config` to set your name and This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address. +### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner### + +[Roberto Tyley](https://github.com/rtyley) has written a similar +tool to filter-branch call the BFG. It is more limited in what is can do, +but it does it _very_ fast. +On a large repository this can make a big difference. + +See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details. + +Tip: BFG is a standalone Java program. However if you create the following alias in your `~/.gitconfig` file you can use `git bfg ...` + + bfg = !java -jar ~/bin/bfg.jar + +(Assuming that you have copied the bfg-x.x.x.jar file to ~/bin/bfg.jar) + ## Debugging with Git ## Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. From 4028d5a9568aea30599d8f0f8f4d29d23b4d44c2 Mon Sep 17 00:00:00 2001 From: Alec Clews Date: Mon, 14 Jul 2014 21:07:14 +1000 Subject: [PATCH 098/291] Added reference to BFG --- en/06-git-tools/01-chapter6.markdown | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 099b47ea4..762e1aab6 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -1,4 +1,4 @@ - Git Tools # +# Git Tools # By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. @@ -690,9 +690,7 @@ Once again, this changes the SHAs of all the commits in your list, so make sure ### The Nuclear Option: filter-branch ### -There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. -The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. -However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. +There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. #### Removing a File from Every Commit #### @@ -732,21 +730,12 @@ Another common case is that you forgot to run `git config` to set your name and This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address. -### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner### +### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner ### -[Roberto Tyley](https://github.com/rtyley) has written a similar -tool to filter-branch call the BFG. It is more limited in what is can do, -but it does it _very_ fast. -On a large repository this can make a big difference. +[Roberto Tyley](https://github.com/rtyley) has written a similar tool to filter-branch called the BFG. It is more limited in what is can do, but it is _very_ fast and on a large repository this can make a big difference. See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details. -Tip: BFG is a standalone Java program. However if you create the following alias in your `~/.gitconfig` file you can use `git bfg ...` - - bfg = !java -jar ~/bin/bfg.jar - -(Assuming that you have copied the bfg-x.x.x.jar file to ~/bin/bfg.jar) - ## Debugging with Git ## Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. From 39a1ea40cc088be3854fdf15fdd45d1ba992c2f7 Mon Sep 17 00:00:00 2001 From: Alec Clews Date: Thu, 16 Jan 2014 19:25:03 +1100 Subject: [PATCH 099/291] A note about using 'git svn info' in build scripts Also fixed a small typo --- en/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown index 4e6671c27..49792b126 100644 --- a/en/08-git-and-other-scms/01-chapter8.markdown +++ b/en/08-git-and-other-scms/01-chapter8.markdown @@ -324,6 +324,17 @@ You can also get the same sort of information that `svn info` gives you by runni This is like `blame` and `log` in that it runs offline and is up to date only as of the last time you communicated with the Subversion server. +Tip: If your build scripts expect to be able to run `svn info` then providing a wrapper around git will often work. +Here is example to experiment with + + #!/usr/bin/env bash + + if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then + git svn info + else + /usr/local/bin/svn "$@" + fi + #### Ignoring What Subversion Ignores #### If you clone a Subversion repository that has `svn:ignore` properties set anywhere, you’ll likely want to set corresponding `.gitignore` files so you don’t accidentally commit files that you shouldn’t. `git svn` has two commands to help with this issue. The first is `git svn create-ignore`, which automatically creates corresponding `.gitignore` files for you so your next commit can include them. From 4a84b8b8ae3d463d2014525a67920914bf5ea868 Mon Sep 17 00:00:00 2001 From: Kangyi Zhu Date: Mon, 14 Jul 2014 19:24:25 +0800 Subject: [PATCH 100/291] [zh] Synchronize with English version Synchronize with English version commit 9e0a6b9. Synchronize the description of new example. --- zh/07-customizing-git/01-chapter7.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 43ef5f389..33e268454 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -351,7 +351,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然 -system for non-linear development. +system for non-linear development (See Chapter 3). -Git 成功且简洁地显示出我增加的文本"Let’s see if this works"。虽然有些瑕疵，在末尾显示了一些随机的内容，但确实可以比较了。如果你能找到或自己写个Word到纯文本的转换器的话，效果可能会更好。 `strings`可以在大部分Mac和Linux系统上运行，所以它是处理二进制格式的第一选择。 +Git 成功且简洁地显示出我增加的文本"(See Chapter 3)"。工作的很完美！ ##### OpenDocument Text files ##### From 652925e2c5faffa67e3c9b1c3aa140fe0020e3a6 Mon Sep 17 00:00:00 2001 From: Kangyi Zhu Date: Mon, 14 Jul 2014 19:26:39 +0800 Subject: [PATCH 101/291] [zh] Fix typo in 01-chapter7 Fix typo. --- zh/07-customizing-git/01-chapter7.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 43ef5f389..500f4030e 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -819,7 +819,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为 ### 客户端挂钩 ### -这种手段的缺点在于用户推送内容遭到拒绝后几乎无法避免的抱怨。辛辛苦苦写成的代码在最后时刻惨遭拒绝是十分悲剧切具迷惑性的；更可怜的是他们不得不修改提交历史来解决问题，这怎么也算不上王道。 +这种手段的缺点在于用户推送内容遭到拒绝后几乎无法避免的抱怨。辛辛苦苦写成的代码在最后时刻惨遭拒绝是十分悲剧且具有迷惑性的；更可怜的是他们不得不修改提交历史来解决问题，这怎么也算不上王道。 逃离这种两难境地的法宝是给用户一些客户端的挂钩，在他们作出可能悲剧的事情的时候给以警告。然后呢，用户们就能在提交--问题变得更难修正之前解除隐患。由于挂钩本身不跟随克隆的项目副本分发，所以必须通过其他途径把这些挂钩分发到用户的 .git/hooks 目录并设为可执行文件。虽然可以在相同或单独的项目内 容里加入并分发它们，全自动的解决方案是不存在的。 From 1a5228d470049b28d9808db2418da81f61645554 Mon Sep 17 00:00:00 2001 From: Daniel Lin Date: Mon, 14 Jul 2014 22:19:55 +0800 Subject: [PATCH 102/291] Correct some typos on chapter2 --- zh-tw/02-git-basics/01-chapter2.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown index 0ab5bb8e7..f637fa8f4 100644 --- a/zh-tw/02-git-basics/01-chapter2.markdown +++ b/zh-tw/02-git-basics/01-chapter2.markdown @@ -673,7 +673,7 @@ Git 原始碼的更新歷史接近二萬筆更新，本命令顯示符合條件 ### 使用圖形界面檢視歷史 ### -若讀者較偏向使用圖形界面檢視歷史，或與會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。 +若讀者較偏向使用圖形界面檢視歷史，或許會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。 Insert 18333fig0202.png 圖2-2。 gitk檢視歷史程式。 @@ -739,7 +739,7 @@ Insert 18333fig0202.png ### 復原已被更動的檔案 ### -若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最被複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示： +若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最初複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示： Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -761,7 +761,7 @@ Insert 18333fig0202.png 在上述文字可看到該變更已被復原。 讀者應該瞭解這是危險的命令，任何對該檔案做的修改將不復存在，就好像複製別的檔案將它覆蓋。 除非很清楚真的不需要該檔案，絕不要使用此檔案。 若需要將這些修改排除，我們在下一章節會介紹備份及分支。 一般來說會比此方法來的好。 -切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被覆原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。 +切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被復原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。 ## 與遠端協同工作 ## @@ -927,7 +927,7 @@ Insert 18333fig0202.png v1.4.2.3 v1.4.2.4 -### 建立標簽 ### +### 建立標籤 ### Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。輕量級標籤就像是沒有更動的分支，實際上它僅是指到特定commit的指標。然而，含附註的標籤則是實際存在Git資料庫上的完整物件。它具備檢查碼、e-mail和日期，也包含標籤訊息，並可以被GNU Privacy Guard (GPG)簽署和驗證。一般而言，我們都建議使用含附註的標籤以便保留相關訊息；但如果只是臨時加註標籤或不需要保留其他訊息，就是使用輕量級標籤的時機。 @@ -994,9 +994,9 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。 稍後你會看到如何驗證已簽署的標籤。 -### 輕量級的標簽 ### +### 輕量級的標籤 ### -另一種則是輕量級的標簽。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。 +另一種則是輕量級的標籤。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。 $ git tag v1.4-lw $ git tag @@ -1180,4 +1180,4 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。 ## 總結 ## -至此，讀者已具備所有Git的本地端操作，包括：創建和副本儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。 +至此，讀者已具備所有Git的本地端操作，包括：創建和複製儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。 From 526c669412d42addb597f1bf0ff3084ba0fe5929 Mon Sep 17 00:00:00 2001 From: Daniel Lin Date: Mon, 14 Jul 2014 22:19:55 +0800 Subject: [PATCH 103/291] [zh-tw] Correct some typos on chapter2 --- zh-tw/02-git-basics/01-chapter2.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown index 0ab5bb8e7..f637fa8f4 100644 --- a/zh-tw/02-git-basics/01-chapter2.markdown +++ b/zh-tw/02-git-basics/01-chapter2.markdown @@ -673,7 +673,7 @@ Git 原始碼的更新歷史接近二萬筆更新，本命令顯示符合條件 ### 使用圖形界面檢視歷史 ### -若讀者較偏向使用圖形界面檢視歷史，或與會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。 +若讀者較偏向使用圖形界面檢視歷史，或許會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。 Insert 18333fig0202.png 圖2-2。 gitk檢視歷史程式。 @@ -739,7 +739,7 @@ Insert 18333fig0202.png ### 復原已被更動的檔案 ### -若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最被複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示： +若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最初複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示： Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -761,7 +761,7 @@ Insert 18333fig0202.png 在上述文字可看到該變更已被復原。 讀者應該瞭解這是危險的命令，任何對該檔案做的修改將不復存在，就好像複製別的檔案將它覆蓋。 除非很清楚真的不需要該檔案，絕不要使用此檔案。 若需要將這些修改排除，我們在下一章節會介紹備份及分支。 一般來說會比此方法來的好。 -切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被覆原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。 +切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被復原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。 ## 與遠端協同工作 ## @@ -927,7 +927,7 @@ Insert 18333fig0202.png v1.4.2.3 v1.4.2.4 -### 建立標簽 ### +### 建立標籤 ### Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。輕量級標籤就像是沒有更動的分支，實際上它僅是指到特定commit的指標。然而，含附註的標籤則是實際存在Git資料庫上的完整物件。它具備檢查碼、e-mail和日期，也包含標籤訊息，並可以被GNU Privacy Guard (GPG)簽署和驗證。一般而言，我們都建議使用含附註的標籤以便保留相關訊息；但如果只是臨時加註標籤或不需要保留其他訊息，就是使用輕量級標籤的時機。 @@ -994,9 +994,9 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。 稍後你會看到如何驗證已簽署的標籤。 -### 輕量級的標簽 ### +### 輕量級的標籤 ### -另一種則是輕量級的標簽。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。 +另一種則是輕量級的標籤。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。 $ git tag v1.4-lw $ git tag @@ -1180,4 +1180,4 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。 ## 總結 ## -至此，讀者已具備所有Git的本地端操作，包括：創建和副本儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。 +至此，讀者已具備所有Git的本地端操作，包括：創建和複製儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。 From aa1e9bc460a8c335a9add63a5e4812925f582e6b Mon Sep 17 00:00:00 2001 From: klern Date: Tue, 15 Jul 2014 15:29:40 +0800 Subject: [PATCH 104/291] Update 01-chapter5.markdown typo --- zh-tw/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh-tw/05-distributed-git/01-chapter5.markdown b/zh-tw/05-distributed-git/01-chapter5.markdown index b8dbecdd5..655b22b01 100644 --- a/zh-tw/05-distributed-git/01-chapter5.markdown +++ b/zh-tw/05-distributed-git/01-chapter5.markdown @@ -85,7 +85,7 @@ Insert 18333fig0503.png 接下來，請將每次提交限定於完成一次邏輯功能。並且可能的話，適當地分解為多次小更新，以便每次小型提交都更易於理解。請不要在週末窮追猛打一次性解決五個問題，而最後拖到週一再提交。就算是這樣也請盡可能利用暫存區域，將之前的改動分解為每次修復一個問題，再分別提交和加注說明。如果針對兩個問題改動的是同一個檔，可以試試看 `git add --patch` 的方式將部分內容置入暫存區域（我們會在第六章再詳細介紹）。無論是五次小提交還是混雜在一起的大提交，最終分支末端的專案快照應該還是一樣的，但分解開來之後，更便於其他開發者複閱。這麼做也方便自己將來取消某個特定問題的修復。我們將在第六章介紹一些重寫提交歷史，同暫存區域交互的技巧和工具，以便最終得到一個乾淨有意義，且易於理解的提交歷史。 最後需要謹記的是提交說明的撰寫。寫得好可以讓大家協作起來更輕鬆。一般來說，提交說明最好限制在一行以內，50 個字元以下，簡明扼要地描述更新內容，空開一行後，再展開詳細注解。Git 專案本身需要開發者撰寫詳盡注解，包括本次修訂的因由，以及前後不同實現之間的比較，我們也該借鑒這種做法。另外，提交說明應該用祈使現在式語態，比如，不要說成 “I added tests for” 或 “Adding tests for” 而應該用 “Add tests for”。 -下麵是來自 tpope.net 的 Tim Pope 原創的提交說明格式模版，供參考： +下面是來自 tpope.net 的 Tim Pope 原創的提交說明格式模版，供參考： 本次更新的簡要描述（50 個字元以內） From c6b3fc8240ed9de96f2135f7e2a5d882c6bc7824 Mon Sep 17 00:00:00 2001 From: Daniel Lin Date: Tue, 15 Jul 2014 15:50:07 +0800 Subject: [PATCH 105/291] [zh-tw] Correct some typos on chapter3 --- zh-tw/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown index 918a9fd6f..a4fe6b5e8 100644 --- a/zh-tw/03-git-branching/01-chapter3.markdown +++ b/zh-tw/03-git-branching/01-chapter3.markdown @@ -580,7 +580,7 @@ Insert 18333fig0335.png Insert 18333fig0336.png 圖 3-36. 克隆一個倉庫，在其基礎上工作一番。 -現在，某人在 C1 的基礎上做了些改變，併合並他自己的分支得到結果 C6，推送到中央伺服器。當你抓取併合並這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣： +現在，某人在 C1 的基礎上做了些改變，並合併他自己的分支得到結果 C6，推送到中央伺服器。當你抓取並合併這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣： Insert 18333fig0337.png 圖 3-37. 抓取他人提交，併入自己主幹。 From ccdf2802a71755f5ed60ae06620061b0e41c1322 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 15 Jul 2014 19:14:41 +0200 Subject: [PATCH 106/291] [fr] update with bdef6f76 --- fr/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index a52fc4c61..f35cc0469 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -1290,7 +1290,7 @@ De nombreuses personnes utilisent parfaitement Git sans connaître aucun de ces Si vous utilisez le shell Bash, Git est livré avec un script d'auto-complétion utile. Téléchargez le directement depuis le code source de Git à https://github.com/git/git/blob/master/contrib/git-completion.bash . -Copiez ce fichier dans votre répertoire personnel et ajoutez cette ligne à votre fichier `.bashrc` : +Copiez ce fichier dans votre répertoire personnel sous le nom `.git-completion.bash` et ajoutez cette ligne à votre fichier `.bashrc` : source ~/.git-completion.bash From 8343398db460066104f0514d76352a220e0df304 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 15 Jul 2014 21:54:24 +0200 Subject: [PATCH 107/291] [fr] sync with c418e2ea --- fr/03-git-branching/01-chapter3.markdown | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/fr/03-git-branching/01-chapter3.markdown b/fr/03-git-branching/01-chapter3.markdown index 832292d3b..2f6370579 100644 --- a/fr/03-git-branching/01-chapter3.markdown +++ b/fr/03-git-branching/01-chapter3.markdown @@ -336,15 +336,20 @@ Placer le fichier dans l'index marque le conflit comme résolu pour Git. Si vous souhaitez utiliser un outil graphique pour résoudre ces problèmes, vous pouvez lancer `git mergetool` qui démarre l'outil graphique de fusion approprié et vous permet de naviguer dans les conflits : $ git mergetool - merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff - Merging the files: index.html + + This message is displayed because 'merge.tool' is not configured. + See 'git mergetool --tool-help' or 'git help config' for more details. + 'git mergetool' will now attempt to use one of the following tools: + opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge + Merging: + index.html Normal merge conflict for 'index.html': - {local}: modified - {remote}: modified + {local}: modified file + {remote}: modified file Hit return to start merge resolution tool (opendiff): -Si vous souhaitez utiliser un outil de fusion autre que celui par défaut (Git a choisi `opendiff` pour moi dans ce cas car j'utilise la commande sous Mac), vous pouvez voir tous les outils supportés après l'indication « merge tool candidates ». +Si vous souhaitez utiliser un outil de fusion autre que celui par défaut (Git a choisi `opendiff` pour moi dans ce cas car j'utilise la commande sous Mac), vous pouvez voir tous les outils supportés après l'indication « *of the following tools:* ». Tapez le nom de l'outil que vous préfèreriez utiliser. Au chapitre 7, nous expliquerons comment changer cette valeur par défaut dans votre environnement. From 608b8b2cf1dd5903fc5159a71da0ad642302f0bd Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 15 Jul 2014 21:57:48 +0200 Subject: [PATCH 108/291] [fr] Sync with ceba7dfb --- fr/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index f35cc0469..771cd44a7 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -924,7 +924,7 @@ Par exemple, mon dépôt Grit ressemble à ceci. koke git://github.com/koke/grit.git origin git@github.com:mojombo/grit.git -Cela signifie que nous pouvons tirer très facilement des contributions depuis certains utilisateurs. +Cela signifie que je peux tirer très facilement des contributions depuis certains utilisateurs. Mais il est à noter que seul le dépôt distant `origin` utilise une URL SSH, ce qui signifie que c'est le seul sur lequel je peux pousser (nous traiterons de ceci au chapitre 4). ### Ajouter des dépôts distants ### From ac28a7e8e49923e895e380a9fec56e44ddf34211 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 15 Jul 2014 22:10:07 +0200 Subject: [PATCH 109/291] [fr] Sync with 60e26189 --- fr/02-git-basics/01-chapter2.markdown | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index 771cd44a7..29843aad8 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -738,7 +738,9 @@ Cette commande fonctionne avec de nombreux formats — vous pouvez indiquer une Vous pouvez aussi restreindre la liste aux *commits* vérifiant certains critères de recherche. L'option `--author` permet de filtrer sur un auteur spécifique, et l'option `--grep` permet de chercher des mots clés dans les messages de validation. -Notez que si vous cherchez seulement des *commits* correspondant simultanément aux deux critères, vous devez ajouter l'option `--all-match`, car par défaut ces commandes retournent les *commits* vérifiant au moins un critère lors de recherche. +Notez que si vous spécifiez à la fois `--author` et `--grep`, la commande retournera seulement des *commits* correspondant simultanément aux deux critères. + +Si vous souhaitez spécifier plusieurs options `--grep`, vous devez ajouter l'option `--all-match`, car par défaut ces commandes retournent les *commits* vérifiant au moins un critère de recherche. La dernière option vraiment utile à `git log` est la spécification d'un chemin. Si un répertoire ou un nom de fichier est spécifié, le journal est limité aux *commits* qui ont introduit des modifications aux fichiers concernés. From b6305ab38e5cfc83eca5b9a84eee85298250b87d Mon Sep 17 00:00:00 2001 From: Alec Clews Date: Wed, 16 Jul 2014 13:27:13 +1000 Subject: [PATCH 110/291] Updated after feedback on 548a15f --- en/06-git-tools/01-chapter6.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 762e1aab6..15cf7b93a 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -730,9 +730,9 @@ Another common case is that you forgot to run `git config` to set your name and This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address. -### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner ### +### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner (BFG) ### -[Roberto Tyley](https://github.com/rtyley) has written a similar tool to filter-branch called the BFG. It is more limited in what is can do, but it is _very_ fast and on a large repository this can make a big difference. +[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capaility, and you have performance issues, then you should consider using it. See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details. From a41419d570381128264b02f2cfa56f0de8630a45 Mon Sep 17 00:00:00 2001 From: Kangyi Zhu Date: Tue, 15 Jul 2014 20:08:10 +0800 Subject: [PATCH 111/291] [zh]Fix a typo in chapter 7 fix a typo --- zh/07-customizing-git/01-chapter7.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 43ef5f389..427a37ab5 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -251,7 +251,7 @@ Git预先设置了一些选项来探测和修正空白问题，其4种主要选 $ git apply --whitespace=fix -这些选项也能运用于衍合。如果提交了有空白问题的文件但还没推送到上流，你可以运行带有`--whitespace=fix`选项的`rebase`来让Git在重写补丁时自动修正它们。 +这些选项也能运用于衍合。如果提交了有空白问题的文件但还没推送到上游，你可以运行带有`--whitespace=fix`选项的`rebase`来让Git在重写补丁时自动修正它们。 ### 服务器端配置 ### From 6bd33272819cb1e2af0e94eb48102baaa302d111 Mon Sep 17 00:00:00 2001 From: Kangyi Zhu Date: Tue, 15 Jul 2014 19:47:16 +0800 Subject: [PATCH 112/291] [zh]Translate binary file type name --- zh/07-customizing-git/01-chapter7.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 986f0b379..0f7a3c68e 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -313,7 +313,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然 边注：有一些二进制文件虽然包含文字，但是却难以转换。（译注：例如 Word 文档。）在这些情况，你可以尝试使用 `strings` 工具来获取其中的文字。但如果当这些文档包含 UTF-16 编码，或者其他代码页（codepages），`strings` 也可能无补于事。`strings` 在大部分的 Mac 和 Linux 下都有安装。当遇到有二进制文件需要转换的时候，你可以试试这个工具。 -##### MS Word files ##### +##### Word文档 ##### 这个特性很酷，而且鲜为人知，因此我会结合实例来讲解。首先，要解决的是最令人头疼的问题：对Word文档进行版本控制。很多人对Word文档又恨又爱，如果想对其进行版本控制，你可以把文件加入到 Git 库中，每次修改后提交即可。但这样做没有一点实际意义，因为运行`git diff`命令后，你只能得到如下的结果： @@ -353,7 +353,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然 Git 成功且简洁地显示出我增加的文本"(See Chapter 3)"。工作的很完美！ -##### OpenDocument Text files ##### +##### OpenDocument文本文档 ##### The same approach that we used for MS Word files (`*.doc`) can be used for OpenDocument Text files (`*.odt`) created by OpenOffice.org. @@ -403,7 +403,7 @@ And make it executable Now `git diff` will be able to tell you what changed in `.odt` files. -##### Image files ##### +##### 图像文件 ##### 你还能用这个方法比较图像文件。当比较时，对JPEG文件运用一个过滤器，它能提炼出EXIF信息 — 大部分图像格式使用的元数据。如果你下载并安装了`exiftool`程序，可以用它参照元数据把图像转换成文本。比较的不同结果将会用文本向你展示： From ce39ac2e9afca4ab9a02a5e9d546d90347988c43 Mon Sep 17 00:00:00 2001 From: Kangyi Zhu Date: Wed, 16 Jul 2014 19:51:42 +0800 Subject: [PATCH 113/291] [zh]Translate a part of chapter 7 Translate OpenDocument Text files section in chapter 7 --- zh/07-customizing-git/01-chapter7.markdown | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 0f7a3c68e..f793fa52a 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -355,19 +355,19 @@ Git 成功且简洁地显示出我增加的文本"(See Chapter 3)"。工作的 ##### OpenDocument文本文档 ##### -The same approach that we used for MS Word files (`*.doc`) can be used for OpenDocument Text files (`*.odt`) created by OpenOffice.org. +我们用于处理Word文档（`*.doc`）的方法同样适用于处理OpenOffice.org创建的OpenDocument文本文档（`*.odt`）。 -Add the following line to your `.gitattributes` file: +把下面这行添加到`.gitattributes`文件： *.odt diff=odt -Now set up the `odt` diff filter in `.git/config`: +然后在`.git/config` 文件中设置`odt`过滤器： [diff "odt"] binary = true textconv = /usr/local/bin/odt-to-txt -OpenDocument files are actually zip’ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We’ll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content: +OpenDocument文档实际上是多个文件（包括一个XML文件和表格、图片等文件）的压缩包。我们需要写一个脚本来提取其中纯文本格式的内容。创建一个文件`/usr/local/bin/odt-to-txt`（你也可以放到其他目录下），写入下面内容： #! /usr/bin/env perl # Simplistic OpenDocument Text (.odt) to plain text converter. @@ -397,11 +397,11 @@ OpenDocument files are actually zip’ped directories containing multiple files s/\A\n+//; # remove leading blank lines print "\n", $_, "\n\n"; -And make it executable +然后把它设为可执行文件 chmod +x /usr/local/bin/odt-to-txt -Now `git diff` will be able to tell you what changed in `.odt` files. +现在`git diff`命令就可以显示`.odt`文件的变更了。 ##### 图像文件 ##### From 5277a400c8cf1c8a807c0810580681394b4d41f7 Mon Sep 17 00:00:00 2001 From: Daniel Lin Date: Tue, 15 Jul 2014 15:50:07 +0800 Subject: [PATCH 114/291] [zh-tw] Correct some typos on chapter3 --- zh-tw/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown index 918a9fd6f..a4fe6b5e8 100644 --- a/zh-tw/03-git-branching/01-chapter3.markdown +++ b/zh-tw/03-git-branching/01-chapter3.markdown @@ -580,7 +580,7 @@ Insert 18333fig0335.png Insert 18333fig0336.png 圖 3-36. 克隆一個倉庫，在其基礎上工作一番。 -現在，某人在 C1 的基礎上做了些改變，併合並他自己的分支得到結果 C6，推送到中央伺服器。當你抓取併合並這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣： +現在，某人在 C1 的基礎上做了些改變，並合併他自己的分支得到結果 C6，推送到中央伺服器。當你抓取並合併這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣： Insert 18333fig0337.png 圖 3-37. 抓取他人提交，併入自己主幹。 From 70fdcc7a74ce2c465cde933652e2f1c3a7c8c655 Mon Sep 17 00:00:00 2001 From: okhtayaz Date: Tue, 15 Jul 2014 17:36:48 -0700 Subject: [PATCH 115/291] [fa] Persian translation started. includes two paragraphs from chapter 1 and an inirial README file to complete as the work progresses --- fa/.gitignore | 2 + fa/01-introduction/01-chapter1.markdown | 262 ++++++++++++++++++++++++ fa/README.md | 7 + 3 files changed, 271 insertions(+) create mode 100644 fa/.gitignore create mode 100644 fa/01-introduction/01-chapter1.markdown create mode 100644 fa/README.md diff --git a/fa/.gitignore b/fa/.gitignore new file mode 100644 index 000000000..b7cd94167 --- /dev/null +++ b/fa/.gitignore @@ -0,0 +1,2 @@ +.DS_store +.idea \ No newline at end of file diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown new file mode 100644 index 000000000..11b5b2d71 --- /dev/null +++ b/fa/01-introduction/01-chapter1.markdown @@ -0,0 +1,262 @@ +# آغاز # + +این فصل در موردشروع استفاده از گیت خواهد بود. +ما ابتدا کمی پیشزمینه ابزارهای کنترل نسخه را مرور میکنیم، سپس میرسیم به قسمتی که چگونه گیت را در سیستم خود راه اندازی کنید و در نهایت چگونه آن را نصب کنید تا بتوانید با آن شروع به کار نمایید. +در انتهای این فصل شما باید فهمیده باشید که چرا گیت لازم است، چرا باید از آن استفاده کرد و آماده باشید تا شروع به استفاده از آن کنید. + +## درباره کنترل نسخه ## + +کنترل نسخه چیست، و چرا باید برای شما اهمیتی داشته باشد؟ کنترل نسخه سیستمی ست که تغییرات ایجاد شده در یک فایل یا مجموعه ای از فایلها را در طول زمان ثبت میکند تا شما بتوانید نسخه مشخصی از آنها را بعدا بازخوانی کنید. + Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control. + +If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. + +### Local Version Control Systems ### + +Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. + +To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1). + +Insert 18333fig0101.png +Figure 1-1. Local version control diagram. + +One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one revision to another in a special format on disk; it can then recreate what any file looked like at any point in time by adding up all the patches. + +### Centralized Version Control Systems ### + +The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2). + +Insert 18333fig0102.png +Figure 1-2. Centralized version control diagram. + +This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client. + +However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. + +### Distributed Version Control Systems ### + +This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3). + +Insert 18333fig0103.png +Figure 1-3. Distributed version control diagram. + +Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. + +## A Short History of Git ## + +As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. + +In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: + +* Speed +* Simple design +* Strong support for non-linear development (thousands of parallel branches) +* Fully distributed +* Able to handle large projects like the Linux kernel efficiently (speed and data size) + +Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). + +## Git Basics ## + +So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. + +### Snapshots, Not Differences ### + +The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4. + +Insert 18333fig0104.png +Figure 1-4. Other systems tend to store data as changes to a base version of each file. + +Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5. + +Insert 18333fig0105.png +Figure 1-5. Git stores data as snapshots of the project over time. + +This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3. + +### Nearly Every Operation Is Local ### + +Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. + +For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. + +This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. + +### Git Has Integrity ### + +Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it. + +The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this: + + 24b9da6552252987aa493b52f8696cd6d3b00373 + +You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents. + +### Git Generally Only Adds Data ### + +When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. + +This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9. + +### The Three States ### + +Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. + +This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. + +Insert 18333fig0106.png +Figure 1-6. Working directory, staging area, and Git directory. + +The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. + +The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. + +The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area. + +The basic Git workflow goes something like this: + +1. You modify files in your working directory. +2. You stage the files, adding snapshots of them to your staging area. +3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. + +If a particular version of a file is in the Git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. + +## Installing Git ## + +Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform. + +### Installing from Source ### + +If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet. + +To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: + + $ yum install curl-devel expat-devel gettext-devel \ + openssl-devel zlib-devel + + $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ + libz-dev libssl-dev + +When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: + + http://git-scm.com/download + +Then, compile and install: + + $ tar -zxf git-1.7.2.2.tar.gz + $ cd git-1.7.2.2 + $ make prefix=/usr/local all + $ sudo make prefix=/usr/local install + +After this is done, you can also get Git via Git itself for updates: + + $ git clone git://git.kernel.org/pub/scm/git/git.git + +### Installing on Linux ### + +If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum: + + $ yum install git-core + +Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: + + $ apt-get install git + +### Installing on Mac ### + +There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7): + + http://sourceforge.net/projects/git-osx-installer/ + +Insert 18333fig0107.png +Figure 1-7. Git OS X installer. + +The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via + + $ sudo port install git-core +svn +doc +bash_completion +gitweb + +You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). + +### Installing on Windows ### + +Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: + + http://msysgit.github.io + +After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. + +Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of single quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. + +## First-Time Git Setup ## + +Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. + +Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: + +* `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. +* `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. +* config file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. + +On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. + +### Your Identity ### + +The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: + + $ git config --global user.name "John Doe" + $ git config --global user.email johndoe@example.com + +Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project. + +### Your Editor ### + +Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following: + + $ git config --global core.editor emacs + +### Your Diff Tool ### + +Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff: + + $ git config --global merge.tool vimdiff + +Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that. + +### Checking Your Settings ### + +If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: + + $ git config --list + user.name=Scott Chacon + user.email=schacon@gmail.com + color.status=auto + color.branch=auto + color.interactive=auto + color.diff=auto + ... + +You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees. + +You can also check what Git thinks a specific key’s value is by typing `git config {key}`: + + $ git config user.name + Scott Chacon + +## Getting Help ## + +If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: + + $ git help + $ git --help + $ man git- + +For example, you can get the manpage help for the config command by running + + $ git help config + +These commands are nice because you can access them anywhere, even offline. +If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. + +## Summary ## + +You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics. diff --git a/fa/README.md b/fa/README.md new file mode 100644 index 000000000..936a0ec43 --- /dev/null +++ b/fa/README.md @@ -0,0 +1,7 @@ +# تلاش برای ترجمه فارسی # + + +## لیست افراد حاضر در این پروژه ## + +اگر شما هم بر روی این ترجمه کار میکنید یا در نظر دارید که این کار را شروع کنید لطفآ به ما اطلاع دهید تا از دوباره کاری پرهیز شود . + From 9d03a436893932f0f16e38c26351851c9ffe1e67 Mon Sep 17 00:00:00 2001 From: okhtayaz Date: Fri, 18 Jul 2014 11:16:20 -0700 Subject: [PATCH 116/291] chapter 1 progressing, chapter 3 started --- fa/01-introduction/01-chapter1.markdown | 7 +- fa/03-git-branching/01-chapter3.markdown | 608 +++++++++++++++++++++++ 2 files changed, 613 insertions(+), 2 deletions(-) create mode 100644 fa/03-git-branching/01-chapter3.markdown diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown index 11b5b2d71..0bab2f4a4 100644 --- a/fa/01-introduction/01-chapter1.markdown +++ b/fa/01-introduction/01-chapter1.markdown @@ -7,9 +7,12 @@ ## درباره کنترل نسخه ## کنترل نسخه چیست، و چرا باید برای شما اهمیتی داشته باشد؟ کنترل نسخه سیستمی ست که تغییرات ایجاد شده در یک فایل یا مجموعه ای از فایلها را در طول زمان ثبت میکند تا شما بتوانید نسخه مشخصی از آنها را بعدا بازخوانی کنید. - Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control. + هر چند مثالهای این کتاب کدهای نرم افزاری را به عنوان فایلهای تحت کنترل نسخه نشان میدهند, در واقع هر نوع فایلی بر روی رایانه میتواند تحت کنترل نسخه قرار بگیرد. -If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. + +اگر شما طراح گرافیکی یا طراح وب هستید و میخواهید که تمام نسخه های یک تصویر یا طرح را نگاه دارد (که معمولا هم همینطور است), استفاده از یک سیستم کنترل نسخه کار معقولی خواهد بود. + +A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. ### Local Version Control Systems ### diff --git a/fa/03-git-branching/01-chapter3.markdown b/fa/03-git-branching/01-chapter3.markdown new file mode 100644 index 000000000..f5e2663bd --- /dev/null +++ b/fa/03-git-branching/01-chapter3.markdown @@ -0,0 +1,608 @@ +# Git Branching # + +تقریبا تمام انواع VCS نوعی از انشعاب را پشتیبانی میکنند. + +Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. + +Some people refer to the branching model in Git as its “killer feature” , and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop. + +## What a Branch Is ## + +To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots. + +When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. + +To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files checksums each one (the SHA-1 hash we mentioned in Chapter 1), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: + + $ git add README test.rb LICENSE + $ git commit -m 'initial commit of my project' + +Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed. + +Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1. + +Insert 18333fig0301.png +Figure 3-1. Single commit repository data. + +If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3-2. + +Insert 18333fig0302.png +Figure 3-2. Git object data for multiple commits. + +A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, it moves forward automatically. + +Insert 18333fig0303.png +Figure 3-3. Branch pointing into the commit data’s history. + +What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command: + + $ git branch testing + +This creates a new pointer at the same commit you’re currently on (see Figure 3-4). + +Insert 18333fig0304.png +Figure 3-4. Multiple branches pointing into the commit’s data history. + +How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The `git branch` command only created a new branch — it didn’t switch to that branch (see Figure 3-5). + +Insert 18333fig0305.png +Figure 3-5. HEAD file pointing to the branch you’re on. + +To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch: + + $ git checkout testing + +This moves HEAD to point to the testing branch (see Figure 3-6). + +Insert 18333fig0306.png +Figure 3-6. HEAD points to another branch when you switch branches. + +What is the significance of that? Well, let’s do another commit: + + $ vim test.rb + $ git commit -a -m 'made a change' + +Figure 3-7 illustrates the result. + +Insert 18333fig0307.png +Figure 3-7. The branch that HEAD points to moves forward with each commit. + +This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch: + + $ git checkout master + +Figure 3-8 shows the result. + +Insert 18333fig0308.png +Figure 3-8. HEAD moves to another branch on a checkout. + +That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction. + +Let’s make a few changes and commit again: + + $ vim test.rb + $ git commit -a -m 'made other changes' + +Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands. + +Insert 18333fig0309.png +Figure 3-9. The branch histories have diverged. + +Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). + +This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often. + +Let’s see why you should do so. + +## Basic Branching and Merging ## + +Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps: + +1. Do work on a web site. +2. Create a branch for a new story you’re working on. +3. Do some work in that branch. + +At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: + +1. Switch back to your production branch. +2. Create a branch to add the hotfix. +3. After it’s tested, merge the hotfix branch, and push to production. +4. Switch back to your original story and continue working. + +### Basic Branching ### + +First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10). + +Insert 18333fig0310.png +Figure 3-10. A short and simple commit history. + +You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: + + $ git checkout -b iss53 + Switched to a new branch 'iss53' + +This is shorthand for: + + $ git branch iss53 + $ git checkout iss53 + +Figure 3-11 illustrates the result. + +Insert 18333fig0311.png +Figure 3-11. Creating a new branch pointer. + +You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12): + + $ vim index.html + $ git commit -a -m 'added a new footer [issue 53]' + +Insert 18333fig0312.png +Figure 3-12. The iss53 branch has moved forward with your work. + +Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch. + +However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch: + + $ git checkout master + Switched to branch 'master' + +At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. + +Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13): + + $ git checkout -b hotfix + Switched to a new branch 'hotfix' + $ vim index.html + $ git commit -a -m 'fixed the broken email address' + [hotfix 3a0874c] fixed the broken email address + 1 files changed, 1 deletion(-) + +Insert 18333fig0313.png +Figure 3-13. hotfix branch based back at your master branch point. + +You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command: + + $ git checkout master + $ git merge hotfix + Updating f42c576..3a0874c + Fast-forward + README | 1 - + 1 file changed, 1 deletion(-) + +You’ll notice the phrase "Fast-forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward". + +Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14). + +Insert 18333fig0314.png +Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge. + +After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`: + + $ git branch -d hotfix + Deleted branch hotfix (was 3a0874c). + +Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15): + + $ git checkout iss53 + Switched to branch 'iss53' + $ vim index.html + $ git commit -a -m 'finished the new footer [issue 53]' + [iss53 ad82d7a] finished the new footer [issue 53] + 1 file changed, 1 insertion(+) + +Insert 18333fig0315.png +Figure 3-15. Your iss53 branch can move forward independently. + +It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. + +### Basic Merging ### + +Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command: + + $ git checkout master + $ git merge iss53 + Auto-merging README + Merge made by the 'recursive' strategy. + README | 1 + + 1 file changed, 1 insertion(+) + +This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case. + +Insert 18333fig0316.png +Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging. + +Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent. + +It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems. + +Insert 18333fig0317.png +Figure 3-17. Git automatically creates a new commit object that contains the merged work. + +Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system: + + $ git branch -d iss53 + +### Basic Merge Conflicts ### + +Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging together, Git won’t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the `hotfix`, you’ll get a merge conflict that looks something like this: + + $ git merge iss53 + Auto-merging index.html + CONFLICT (content): Merge conflict in index.html + Automatic merge failed; fix conflicts and then commit the result. + +Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: + + $ git status + On branch master + You have unmerged paths. + (fix conflicts and run "git commit") + + Unmerged paths: + (use "git add ..." to mark resolution) + + both modified: index.html + + no changes added to commit (use "git add" and/or "git commit -a") + +Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this: + + <<<<<<< HEAD + + ======= + + >>>>>>> iss53 + +This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: + + + +This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git. +If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts: + + $ git mergetool + + This message is displayed because 'merge.tool' is not configured. + See 'git mergetool --tool-help' or 'git help config' for more details. + 'git mergetool' will now attempt to use one of the following tools: + opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge + Merging: + index.html + + Normal merge conflict for 'index.html': + {local}: modified file + {remote}: modified file + Hit return to start merge resolution tool (opendiff): + +If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment. + +After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. + +You can run `git status` again to verify that all conflicts have been resolved: + + $ git status + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: index.html + + +If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this: + + Merge branch 'iss53' + + Conflicts: + index.html + # + # It looks like you may be committing a merge. + # If this is not correct, please remove the file + # .git/MERGE_HEAD + # and try again. + # + +You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious. + +## Branch Management ## + +Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time. + +The `git branch` command does more than just create and delete branches. If you run it with no arguments, you get a simple listing of your current branches: + + $ git branch + iss53 + * master + testing + +Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out. This means that if you commit at this point, the `master` branch will be moved forward with your new work. To see the last commit on each branch, you can run `git branch -v`: + + $ git branch -v + iss53 93b412c fix javascript issue + * master 7a98805 Merge branch 'iss53' + testing 782fd34 add scott to the author list in the readmes + +Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`: + + $ git branch --merged + iss53 + * master + +Because you already merged in `iss53` earlier, you see it in your list. Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you’ve already incorporated their work into another branch, so you’re not going to lose anything. + +To see all the branches that contain work you haven’t yet merged in, you can run `git branch --no-merged`: + + $ git branch --no-merged + testing + +This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail: + + $ git branch -d testing + error: The branch 'testing' is not fully merged. + If you are sure you want to delete it, run 'git branch -D testing'. + +If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out. + +## Branching Workflows ## + +Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we’ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle. + +### Long-Running Branches ### + +Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others. + +Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs. + +In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18). + +Insert 18333fig0318.png +Figure 3-18. More stable branches are generally farther down the commit history. + +It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19). + +Insert 18333fig0319.png +Figure 3-19. It may be helpful to think of your branches as silos. + +You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them. +Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects. + +### Topic Branches ### + +Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you’ve likely never done with a VCS before because it’s generally too expensive to create and merge branches. But in Git it’s common to create, work on, merge, and delete branches several times a day. + +You saw this in the last section with the `iss53` and `hotfix` branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely — because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on. + +Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20. + +Insert 18333fig0320.png +Figure 3-20. Your commit history with multiple topic branches. + +Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21. + +Insert 18333fig0321.png +Figure 3-21. Your history after merging in dumbidea and iss91v2. + +It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening. + +## Remote Branches ## + +Remote branches are references to the state of branches on your remote repositories. They’re local branches that you can’t move; they’re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them. + +They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`. + +This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22). + +Insert 18333fig0322.png +Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch. + +If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23). + +Insert 18333fig0323.png +Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently. + +To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24). + +Insert 18333fig0324.png +Figure 3-24. The `git fetch` command updates your remote references. + +To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25). + +Insert 18333fig0325.png +Figure 3-25. Adding another server as a remote. + +Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26). + +Insert 18333fig0326.png +Figure 3-26. You get a reference to teamone’s master branch position locally. + +### Pushing ### + +When you want to share a branch with the world, you need to push it up to a remote that you have write access to. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on. + +If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. Run `git push (remote) (branch)`: + + $ git push origin serverfix + Counting objects: 20, done. + Compressing objects: 100% (14/14), done. + Writing objects: 100% (15/15), 1.74 KiB, done. + Total 15 (delta 5), reused 0 (delta 0) + To git@github.com:schacon/simplegit.git + * [new branch] serverfix -> serverfix + +This is a bit of a shortcut. Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, “Take my serverfix local branch and push it to update the remote’s serverfix branch.” We’ll go over the `refs/heads/` part in detail in Chapter 9, but you can generally leave it off. You can also do `git push origin serverfix:serverfix`, which does the same thing — it says, “Take my serverfix and make it the remote’s serverfix.” You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project. + +The next time one of your collaborators fetches from the server, they will get a reference to where the server’s version of `serverfix` is under the remote branch `origin/serverfix`: + + $ git fetch origin + remote: Counting objects: 20, done. + remote: Compressing objects: 100% (14/14), done. + remote: Total 15 (delta 5), reused 0 (delta 0) + Unpacking objects: 100% (15/15), done. + From git@github.com:schacon/simplegit + * [new branch] serverfix -> origin/serverfix + +It’s important to note that when you do a fetch that brings down new remote branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new `serverfix` branch — you only have an `origin/serverfix` pointer that you can’t modify. + +To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch: + + $ git checkout -b serverfix origin/serverfix + Branch serverfix set up to track remote branch serverfix from origin. + Switched to a new branch 'serverfix' + +This gives you a local branch that you can work on that starts where `origin/serverfix` is. + +### Tracking Branches ### + +Checking out a local branch from a remote branch automatically creates what is called a _tracking branch_. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type `git push`, Git automatically knows which server and branch to push to. Also, running `git pull` while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch. + +When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand: + + $ git checkout --track origin/serverfix + Branch serverfix set up to track remote branch serverfix from origin. + Switched to a new branch 'serverfix' + +To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name: + + $ git checkout -b sf origin/serverfix + Branch sf set up to track remote branch serverfix from origin. + Switched to a new branch 'sf' + +Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`. + +### Deleting Remote Branches ### + +Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following: + + $ git push origin :serverfix + To git@github.com:schacon/simplegit.git + - [deleted] serverfix + +Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.” + +## Rebasing ## + +In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it. + +### The Basic Rebase ### + +If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches. + +Insert 18333fig0327.png +Figure 3-27. Your initial diverged commit history. + +The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28. + +Insert 18333fig0328.png +Figure 3-28. Merging a branch to integrate the diverged work history. + +However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one. + +In this example, you’d run the following: + + $ git checkout experiment + $ git rebase master + First, rewinding head to replay your work on top of it... + Applying: added staged command + +It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process. + +Insert 18333fig0329.png +Figure 3-29. Rebasing the change introduced in C3 onto C4. + +At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30). + +Insert 18333fig0330.png +Figure 3-30. Fast-forwarding the master branch. + +Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. + +Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply. + +Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. + +### More Interesting Rebases ### + +You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits. + +Insert 18333fig0331.png +Figure 3-31. A history with a topic branch off another topic branch. + +Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`: + + $ git rebase --onto master server client + +This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool. + +Insert 18333fig0332.png +Figure 3-32. Rebasing a topic branch off another topic branch. + +Now you can fast-forward your master branch (see Figure 3-33): + + $ git checkout master + $ git merge client + +Insert 18333fig0333.png +Figure 3-33. Fast-forwarding your master branch to include the client branch changes. + +Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`): + + $ git rebase master server + +This replays your `server` work on top of your `master` work, as shown in Figure 3-34. + +Insert 18333fig0334.png +Figure 3-34. Rebasing your server branch on top of your master branch. + +Then, you can fast-forward the base branch (`master`): + + $ git checkout master + $ git merge server + +You can remove the `client` and `server` branches because all the work is integrated and you don’t need them anymore, leaving your history for this entire process looking like Figure 3-35: + + $ git branch -d client + $ git branch -d server + +Insert 18333fig0335.png +Figure 3-35. Final commit history. + +### The Perils of Rebasing ### + +Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line: + +**Do not rebase commits that you have pushed to a public repository.** + +If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family. + +When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours. + +Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36. + +Insert 18333fig0336.png +Figure 3-36. Clone a repository, and base some work on it. + +Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37. + +Insert 18333fig0337.png +Figure 3-37. Fetch more commits, and merge them into your work. + +Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits. + +Insert 18333fig0338.png +Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on. + +At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39). + +Insert 18333fig0339.png +Figure 3-39. You merge in the same work again into a new merge commit. + +You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people. + +If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble. + +## Summary ## + +We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. From 49df6b1c3757e1b03116b22d6613b5f51befb4e1 Mon Sep 17 00:00:00 2001 From: Soon Van Date: Tue, 22 Jul 2014 17:42:15 -0400 Subject: [PATCH 117/291] Update link to download P4Merge tool --- az/07-customizing-git/01-chapter7.markdown | 2 +- cs/07-customizing-git/01-chapter7.markdown | 2 +- de/07-customizing-git/01-chapter7.markdown | 2 +- en/07-customizing-git/01-chapter7.markdown | 4 ++-- es/07-customizing-git/01-chapter7.markdown | 2 +- es/omegat-Benzirpi.tmx | 4 ++-- fr/07-customizing-git/01-chapter7.markdown | 2 +- it/07-customizing-git/01-chapter7.markdown | 2 +- ja/07-customizing-git/01-chapter7.markdown | 2 +- ko/07-customizing-git/01-chapter7.markdown | 2 +- nl/07-customizing-git/01-chapter7.markdown | 2 +- no-nb/07-customizing-git/01-chapter7.markdown | 2 +- pl/07-customizing-git/01-chapter7.markdown | 2 +- pt-br/07-customizing-git/01-chapter7.markdown | 2 +- ru/07-customizing-git/01-chapter7.markdown | 2 +- zh-tw/07-customizing-git/01-chapter7.markdown | 2 +- zh/07-customizing-git/01-chapter7.markdown | 2 +- 17 files changed, 19 insertions(+), 19 deletions(-) diff --git a/az/07-customizing-git/01-chapter7.markdown b/az/07-customizing-git/01-chapter7.markdown index 41f5dd33f..c2bb85fc1 100644 --- a/az/07-customizing-git/01-chapter7.markdown +++ b/az/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ If you want to try this out, P4Merge works on all major platforms, so you should You can download P4Merge here: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided: diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown index 54d0ca3a5..5491834de 100644 --- a/cs/07-customizing-git/01-chapter7.markdown +++ b/cs/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Pokud ho chcete vyzkoušet, nemělo by vám v tom nic bránit, P4Merge funguje n P4Merge můžete stáhnout na této adrese: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Pro začátek je třeba nastavit kvůli spouštění příkazů externí skripty wrapperu. Jako cestu ke spustitelnému souboru používám cestu v systému Mac. V ostatních systémech použijte cestu k umístění, kde máte nainstalován binární soubor `p4merge`. Nastavte wrapperový skript pro slučování `extMerge`, který bude volat binární soubor všemi dostupnými parametry: diff --git a/de/07-customizing-git/01-chapter7.markdown b/de/07-customizing-git/01-chapter7.markdown index aefff281d..1d9a629d2 100644 --- a/de/07-customizing-git/01-chapter7.markdown +++ b/de/07-customizing-git/01-chapter7.markdown @@ -219,7 +219,7 @@ Da P4Merge für die üblichen Plattformen verfügbar ist, sollte es kein Problem Du kannst P4Merge hier herunterladen: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index 1a1b7f729..de99afcd7 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -4,7 +4,7 @@ So far, I’ve covered the basics of how Git works and how to use it, and I’ve ## Git Configuration ## -As you briefly saw in the Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address: +As you briefly saw in Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com @@ -142,7 +142,7 @@ If you want to try this out, P4Merge works on all major platforms, so you should You can download P4Merge here: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided: diff --git a/es/07-customizing-git/01-chapter7.markdown b/es/07-customizing-git/01-chapter7.markdown index af19b3cc6..6ac5413f4 100644 --- a/es/07-customizing-git/01-chapter7.markdown +++ b/es/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Si lo quieres probar, P4Merge funciona en todas las principales plataformas. Los P4Merge se puede descargar desde: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Para empezar, tienes que preparar los correspondientes scripts para lanzar tus comandos. En estos ejemplos, voy a utilizar caminos y nombres Mac para los ejecutables; en otros sistemas, tendrás que sustituirlos por los correspondientes donde tengas instalado 'p4merge'. El primer script a preparar es uno al que denominaremos 'extMerge', para llamar al ejecutable con los correspodientes argumentos: diff --git a/es/omegat-Benzirpi.tmx b/es/omegat-Benzirpi.tmx index 971ad7931..95f49f3b2 100644 --- a/es/omegat-Benzirpi.tmx +++ b/es/omegat-Benzirpi.tmx @@ -2369,10 +2369,10 @@ Figura 3-36. - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools diff --git a/fr/07-customizing-git/01-chapter7.markdown b/fr/07-customizing-git/01-chapter7.markdown index e7248a28a..fefd66dcc 100644 --- a/fr/07-customizing-git/01-chapter7.markdown +++ b/fr/07-customizing-git/01-chapter7.markdown @@ -177,7 +177,7 @@ Pour Windows, vous devrez changer `/usr/local/bin` en un chemin d'exécution d'u Vous pouvez télécharger P4Merge ici : - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Pour commencer, créez un script d'appel externe pour lancer vos commandes. Je vais utiliser le chemin Mac pour l'exécutable ; dans d'autres systèmes, il résidera où votre binaire `p4merge` a été installé. diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index a5e42995a..78b49f917 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Se vuoi provarlo, P4Merge funziona su tutte le maggiori piattaforme, quindi dovr Puoi scarucare P4Merge qua: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Per iniziare dovrai impostare scripts esterni di wrapping per eseguire i tuoi comandi. Utilizzerò il percorso relativo a Mac per l'eseguibile; in altri sistemi, sarà dove è posizionato il binario `p4merge`. Imposta uno script per il wrapping del merge chiamato `extMerge` che chiami il binario con tutti gli argomenti necessari: diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown index 4050bdcf9..74d0dd626 100644 --- a/ja/07-customizing-git/01-chapter7.markdown +++ b/ja/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ P4Merge はすべての主要プラットフォーム上で動作するので、 まず、P4Merge をここからダウンロードします。 - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools 最初に、コマンドを実行するための外部ラッパースクリプトを用意します。この例では、Mac 用の実行パスを使います。他のシステムで使う場合は、`p4merge` のバイナリがインストールされた場所に置き換えてください。次のようなマージ用ラッパースクリプト `extMerge` を用意しました。これは、すべての引数を受け取ってバイナリをコールします。 diff --git a/ko/07-customizing-git/01-chapter7.markdown b/ko/07-customizing-git/01-chapter7.markdown index 901c2d27c..26a6a4737 100644 --- a/ko/07-customizing-git/01-chapter7.markdown +++ b/ko/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ P4Merge는 중요 플랫폼을 모두 지원하기 때문에 웬만한 환경이 다음 페이지에서 P4Merge를 내려받는다: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools 먼저 P4Merge에 쓸 Wrapper 스크립트를 만든다. 필자는 Mac 사용자라서 Mac 경로를 사용한다. 어떤 시스템이든 `p4merge`가 설치된 경로를 사용하면 된다. extMerge라는 Merge용 Wrapper 스크립트를 만들고 이 스크립트로 넘어오는 모든 아규먼트를 p4merge 프로그램으로 넘긴다: diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown index b1bb95223..53edfbce1 100644 --- a/nl/07-customizing-git/01-chapter7.markdown +++ b/nl/07-customizing-git/01-chapter7.markdown @@ -178,7 +178,7 @@ Als je dit wilt proberen, P4Merge werkt op alle grote platformen, dus je zou het Je kunt P4Merge hier downloaden: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Om te beginnen ga je externe wrapper scripts instellen om de commando's uit te voeren. Ik zal het Mac pad gebruiken voor de applicatie; in andere systemen zal het moeten wijzen naar de plaats waar de `p4merge` binary geïnstalleerd is. Maak merge wrapper script, genaamd `extMerge`, die jouw applicatie met alle meegegeven argumenten aanroept: diff --git a/no-nb/07-customizing-git/01-chapter7.markdown b/no-nb/07-customizing-git/01-chapter7.markdown index 38f7d4562..2a800faf9 100644 --- a/no-nb/07-customizing-git/01-chapter7.markdown +++ b/no-nb/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ If you want to try this out, P4Merge works on all major platforms, so you should You can download P4Merge here: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided: diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown index be288a25a..f7346cd0d 100644 --- a/pl/07-customizing-git/01-chapter7.markdown +++ b/pl/07-customizing-git/01-chapter7.markdown @@ -218,7 +218,7 @@ Możesz pobrać P4Merge stąd: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Na początek, ustawimy zewnętrzny skrypt do uruchamiania komend. Użyję ścieżki z systemu Mac wskazującej na program; w innych systemach, będzie ona musiała wskazywać na miejsce w którym program `p4merge` został zainstalowany. Stwórz skrypt o nazwie `extMerge`, który będzie przyjmował wszystkie podane parametry i uruchamiał program: diff --git a/pt-br/07-customizing-git/01-chapter7.markdown b/pt-br/07-customizing-git/01-chapter7.markdown index c734872e3..47fc4964c 100644 --- a/pt-br/07-customizing-git/01-chapter7.markdown +++ b/pt-br/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Se você quiser experimentar, P4Merge funciona em todas as principais plataforma Você pode baixar P4Merge aqui: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Para começar, você vai configurar um script para executar seus comandos. Vou usar o caminho para o executável Mac; em outros sistemas, este será onde o seu binário do `p4merge` está instalado. Configure um script chamado `extMerge` que chama seu binário com todos os argumentos necessários: diff --git a/ru/07-customizing-git/01-chapter7.markdown b/ru/07-customizing-git/01-chapter7.markdown index 3fc54cceb..94009ba4a 100644 --- a/ru/07-customizing-git/01-chapter7.markdown +++ b/ru/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Git автоматически раскрасит большую часть св Скачать P4Merge можно здесь: - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Для начала сделаем внешние сценарии-обёртки для запуска нужных команд. Я буду использовать Mac'овский путь к исполняемым файлам; для других систем это будет тот путь, куда установлен ваш файл `p4merge`. Сделайте для слияния сценарий-обёртку с именем `extMerge`, он будет вызывать бинарник со всеми переданными аргументами: diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown index e16573d71..a5ead4413 100644 --- a/zh-tw/07-customizing-git/01-chapter7.markdown +++ b/zh-tw/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Git 會按照你的需要，自動為大部分的輸出加上顏色。你能明 你可以在這裏下載 P4Merge： - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools 首先，你要設定一個外部包裝腳本(external wrapper scripts)來執行你要的命令，我會使用 Mac 系統上的路徑來指定該腳本的位置；在其他系統上，它應該被放置在二進位檔案 `p4merge` 所在的目錄中。創建一個 merge 包裝腳本，名字叫作 `extMerge`，讓它附帶所有參數呼叫 p4merge 二進位檔案： diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 564f32c6d..f3e7082a9 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ P4Merge可以在所有主流平台上运行，现在开始大胆尝试吧。对 下载P4Merge： - http://www.perforce.com/perforce/downloads/component.html + http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools 首先把你要运行的命令放入外部包装脚本中，我会使用Mac系统上的路径来指定该脚本的位置，在其他系统上，它应该被放置在二进制文件`p4merge`所在的目录中。创建一个merge包装脚本，名字叫作`extMerge`，让它带参数调用`p4merge`二进制文件： From 375f9d876fbf8899633098985a1a190402f278ce Mon Sep 17 00:00:00 2001 From: Micah Walter Date: Fri, 25 Jul 2014 16:39:37 -0400 Subject: [PATCH 118/291] Update 01-chapter1.markdown Translation of the brief history / Traduko de la mallonga historio --- eo/01-introduction/01-chapter1.markdown | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/eo/01-introduction/01-chapter1.markdown b/eo/01-introduction/01-chapter1.markdown index d8c3313bc..2702db772 100644 --- a/eo/01-introduction/01-chapter1.markdown +++ b/eo/01-introduction/01-chapter1.markdown @@ -39,19 +39,19 @@ Figure 1-3. Distributed version control diagram. Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. -## A Short History of Git ## +## Mallonga historio de Git ## -As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. +Kiel pluraj el la bonaĵoj en la vivo, Git komenciĝis per iom da kreiga detruo kaj granda disputego. La Linux-kerno estas malfermitkoda programaro-projekto kun sufiĉe granda amplekso. Dum la plejparto de la tempo en kiu la Linux-kerno estis prizorgata (1991–2002), oni disdonis ŝanĝojn al la programaro kiel flikaĵoj kaj enarkivigitaj dosieroj. En 2002, la Linux-kerna projekto komencis uzi proprietan DVCS-sistemon nomita BitKeeper. -In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: +En 2005 rompiĝis la rilato inter la komunumo, en kiu la Linux-kerno evoluis, kaj la komerco firmao, kiu produktis BitKeeper; oni senvalidigis la senkostan statuson de la ilo. Tio instigis la komunumo, kiu sin prizorgis pri la evoluo de Linux—kaj precipe Linus Torvalds, la kreinto de Linux—krei sian propran ilon, tenante en la menso la lecionojn, kiujn ili lernis, dum ili uzis BitKeeper. Jen kelkaj el la celoj de la nova sistemo: -* Speed -* Simple design -* Strong support for non-linear development (thousands of parallel branches) -* Fully distributed -* Able to handle large projects like the Linux kernel efficiently (speed and data size) +* Rapideco +* Simpla desegno +* Bona subteno por nelinea konstruado (miloj da paralelaj branĉoj) +* Tute disa sistemo +* La ebleco rendimente trakti grandajn projektojn (kiel la Linux-kerno) koncerne al rapideco kaj datuma grandeco -Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). +Ekde ĝia naskiĝo en 2005, Git evoluis kaj prenkreskiĝis por esti facile uzebla kaj tamen reteni tiujn dekomencaj ecoj. Ĝi estas nekredeble rapida; ĝi estas tre rendimenta kun grandaj projektoj; kaj ĝi havas bonegan branĉigan sistemon por nelinea konstruado (vidu Ĉapitro 3). ## Git Basics ## From 95a5fb84c899447b6555ae197b84b5c81dedf707 Mon Sep 17 00:00:00 2001 From: mxamin Date: Sun, 27 Jul 2014 10:54:13 +0330 Subject: [PATCH 119/291] [fa] ch1 update --- fa/01-introduction/01-chapter1.markdown | 176 ++++++++++++------------ 1 file changed, 89 insertions(+), 87 deletions(-) diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown index 0bab2f4a4..44d312701 100644 --- a/fa/01-introduction/01-chapter1.markdown +++ b/fa/01-introduction/01-chapter1.markdown @@ -1,138 +1,138 @@ -# آغاز # +# سرآغاز # -این فصل در موردشروع استفاده از گیت خواهد بود. -ما ابتدا کمی پیشزمینه ابزارهای کنترل نسخه را مرور میکنیم، سپس میرسیم به قسمتی که چگونه گیت را در سیستم خود راه اندازی کنید و در نهایت چگونه آن را نصب کنید تا بتوانید با آن شروع به کار نمایید. -در انتهای این فصل شما باید فهمیده باشید که چرا گیت لازم است، چرا باید از آن استفاده کرد و آماده باشید تا شروع به استفاده از آن کنید. +در این فصل در رابطه با شروع کار با Git صحبت خواهد شد. این فصل با توضیحاتی در رابطه با تاریخچه ابزارهای کنترل ورژن شروع می شود، سپس چگونگی راه اندازی Git برروی یک سیستم خاص آموزش داده می شود و در انتها انجام تنظیمات موردنیاز برروی این نرم افزار جهت شروع به کار با آن مورد بررسی قرار می گیرد. در انتهای این فصل خواننده باید دلیل وجود و استفاده از Git را بداند و همچنین باید محیط کار را برای استفاده از آن فراهم کرده باشد. -## درباره کنترل نسخه ## +## کنترل ورژن ## -کنترل نسخه چیست، و چرا باید برای شما اهمیتی داشته باشد؟ کنترل نسخه سیستمی ست که تغییرات ایجاد شده در یک فایل یا مجموعه ای از فایلها را در طول زمان ثبت میکند تا شما بتوانید نسخه مشخصی از آنها را بعدا بازخوانی کنید. - هر چند مثالهای این کتاب کدهای نرم افزاری را به عنوان فایلهای تحت کنترل نسخه نشان میدهند, در واقع هر نوع فایلی بر روی رایانه میتواند تحت کنترل نسخه قرار بگیرد. +کنترل ورژن چیست و چه اهمیتی دارد؟ کنترل ورژن سیستمی است که تغییرات مربوط به یک یا چندین فایل را در طول زمان ذخیره می کند، تا کاربر بتواند به ورژن های قبلی مراجعت داشته باشد. در مثالهای استفاده شده در این کتاب از فایل های سورس نرم افزار جهت نمایش کنترل ورژن استفاده میشود، ولی با این وجود میتوان هر نوع فایلی را تحت کنترل ورژن قرار داد. +اگر شما یک گرافیست یا طراح وب باشید و تصمیم به نگهداری تمامی ورژنهای یک عکس یا ساختار باشید (که قطعا به همین منوال است)، استفاده از یک سیستم کنترل ورژن (VCS) راهبردی عاقلانه است. یک VCS این امکان را به شما میدهد که: فایلها را به یک وضعیت قبل برگردانید، یک پروژه را به یک وضعیت قبل برگردانید، تغییرات انجام گرفته در مرور زمان را مشاهده کنید، باعث و بانی تغییری را بیابید که منجر به ایجاد خطا یا مشکلی در سیستم شده است، چه کسی و چه زمانی مسئلهای خاص مطرح شده است و بسیاری موارد دیگر. استفاده از یک VCS حتی این امکان را به شما میدهد که اگر احیاناً خطایی مرتکب شدید یا فایلی را اشتباهاً حذف یا از دست دادید، به راحتی آن را اصلاح و بازیابی کنید. -اگر شما طراح گرافیکی یا طراح وب هستید و میخواهید که تمام نسخه های یک تصویر یا طرح را نگاه دارد (که معمولا هم همینطور است), استفاده از یک سیستم کنترل نسخه کار معقولی خواهد بود. +### سیستمهای کنترل ورژن محلی ### -A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. +روشی که اکثر کاربران جهت کنترل ورژن انتخاب میکنند شامل کپی کردن فایلها در پوشهای دیگر است (البته اگر هوشمند باشد، پوشه موردنظر را با تاریخ و زمانی مشخص نامگذاری میکنند). چنین روشی به جهت سادگی بین کاربران بسیار رایج میباشد، ولی خطاپذیری بالایی نیز دارد. در این روش امکان دارد فرد به آسانی پوشهای که در آن قرار دارد را فراموش کند و به اشتباه شروع به تغییر برروی فایلهایی کند که مدنظر او نیست. -### Local Version Control Systems ### - -Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. - -To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1). +برای مقابله با این موذل، برنامه نویسان از زمانهای بسیار قبل اقدام به توسعه VCSها زده اند که در بردارنده پایگاه داده ساده ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایلهای هدف را در قالب کنترل رویژن نگهداری می کنند (تصویر 1-1) Insert 18333fig0101.png -Figure 1-1. Local version control diagram. +تصویر 1-1. دیاگرام کنترل ورژن محلی. -One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one revision to another in a special format on disk; it can then recreate what any file looked like at any point in time by adding up all the patches. +یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار میدهد. این ابزار به زبانی ساده با حفظ مجموعه ای از پچها (که تغییرات بین فایلها میباشند) از یک رویژن به رویژنی دیگر در قالب فرمتی خاص برروی دیسک عمل میکند؛ با چنین سیستمی این ابزار قادر است با متصل کردن پچها به یکدیگر توانایی بازسازی هر فایلی را در هر نقطه ای از زمان داشته باشد. -### Centralized Version Control Systems ### +### سیستمهای کنترل ورژن مرکزی ### -The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2). +مسئله مهم دیگری که کاربران با آن مواجه میشوند، نیاز آنها به همکاری با دیگر توسعه دهندگان برروی سیستمهای دیگر است. برای حل این مسئله، سیستمهای کنترل ورژن مرکزی (CVCSs) توسعه یافتند. چنین سیستمهایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی ورژنهای فایلها و حتی کاربرانی که این فایلها را از این مکان مرکزی check out کرده اند در خود نگهداری میکند. برای سالهای زیادی، چنین روشی، روشی استاندارد برای کنترل ورژن بوده است (تصویر 1-2). Insert 18333fig0102.png -Figure 1-2. Centralized version control diagram. +تصویر 1-2. دیاگرام کنترل ورژن مرکزی. -This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client. +این ساختار مزایای بسیاری مخصوصاً نسبت به سیستمهای کنترل ورژن محلی دارد. به عنوان مثال، هر فرد در حد و اندازه مشخصی خواهد توانست بداند که دیگر افراد تا چه اندازه در پروژه شریک هستند. مدیران از این نظر که هرکس از نظر سطح دسترسی قادر به انجام چه کاری است، کنترل مناسبی دارند؛ همچنین مدیریت یک CVCS به مراتب آسانتر از تعامل با پایگاههای داده محلی موجود برروی سیستمهای کاربران است. -However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. +با این وجود، چنین ساختاری معایبی نیز دارد. واضحترین موضوع بروز کوچکترین ایراد در سرورهای مرکزی میباشد. اگر برای مدت یک ساعت این سرور متوقف و از کار بیافتد، در طی این بازه یک ساعته هیچکس نخواهد توانست تعاملی داشته باشد یا حتی تغییرات ورژن را برروی چیزی که در حال کارکردن با آن است ذخیره کند. اگر هارد دیسکی که پایگاه داده مرکزی برروی آن قرار دارد خراب شود، و پشتیبان مناسبی از آن گرفته نشده باشد، کاربر به طور کامل تاریخچه پروژه را از دست خواهد داد به جز snapshotهایی که هر کاربر احتمالاً برروی ماشین محلی خود خواهد داشت. سیستمهای VCS محلی نیز این عیب را به ارث میبرند-اگر کاربر تمامی تاریخچه پروژه را در یک مکان ذخیره کند، ریسک از دادن همه چیز به قوت خود باقی خواهد ماند. -### Distributed Version Control Systems ### +### سیستمهای کنترل ورژن پخشی ### -This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3). +اینجا است که سیستمهای کنترل ورژن پخشی (DVCSs) نمود پیدا میکنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به check out کردن آخرین snapshot فایلها اکتفا نمیکنند: آنها repository را نیز به صورت کامل کپی میکنند. بنابراین اگر هر سروری که سیستمها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی repository هر کدام از کاربران برروی سرور، عمل بازیابی انجام میگیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده ها است. Insert 18333fig0103.png -Figure 1-3. Distributed version control diagram. +تصویر 1-3. دیاگرام کنترل ورژن پخشی. -Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. +علاوه بر آن اکثر این سیستمها تعامل خوبی با داشتن remote repositoryهای متعدد جهت کار کردن با آنها دارند، در نتیجه شخص خواهد توانست با گروههای مختلفی در قالب پروژه ای یکسان به صورت همزمان تعامل داشته باشد. این قابلیت این امکان را به کاربر خواهد داد که workflowهای متنوعی همانند مدلهای سلسه مراتبی را پیاده سازی کند که انجام آن در سیستمهای متمرکز امکان پذیر نیست. -## A Short History of Git ## +## تاریخچه کوتاهی از Git ## -As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. +همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم افزاری متن باز با وسعت نسبتاً زیادی است. برای مدت زمان زیادی از عمر نگهداری هسته لینوکس (1991 - 2002) تغییرات نرم افزاری به واسطه پچ ها و فایلهای آرشیو شده انتقال پیدا میکرد. در سال 2002، پروژه هسته لینوکس اقدام به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد. -In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: +در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن به صورت رایگان عرضه میشد تغییر پیدا کرد. این اتفاق اخطاری را متوجه مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) کرد که بر اساس تجربه های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در زمینه بزنند. مواردی از اهداف سیستم جدید عبارتند از: -* Speed -* Simple design -* Strong support for non-linear development (thousands of parallel branches) -* Fully distributed -* Able to handle large projects like the Linux kernel efficiently (speed and data size) +* سرعت +* طراحی ساده +* پشتیبانی قوی از توسعه غیر خطی (هزاران branch موازی) +* کاملاً پخشی +* قابلیت کنترل بهینه پروژه های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده) -Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). +از زمان تولد Git در سال 2005، این نرم افزار از نظر استفاده آسان و حفظ اهداف اولیه ذکر شده به تکامل و بلوغ رسیده است. Git نرم افزاری سریع، بسیار بهینه در مواجه با پروژه های بزرگ و حاوی سیستم شاخه ای (branching) باورنکردنی برای توسعه غیر خطی است (فصل 3). -## Git Basics ## +## مقدمات Git ## -So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. +خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git اطلاع پیدا کند، آنگاه خواهد توانست آسانتر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce میداند تخلیه کند؛ بدین وسیله از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می شود. با وجود آن که رابط کاربری Git نسبتاً مشابه با دیگر سیستم ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم ها دارد؛ دانستن این تفاوت ها میتواند به فرد در جلوگیری از بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد. -### Snapshots, Not Differences ### +### Snapshotها، نه تفاوتها ### + +اصلی ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می شود) دیدگاهی است که Git نسبت به داده های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می کنند. این سیستم ها (CVS، Subversion، Perfoce، Bazaar و غیره) همانطور که در تصویر 1-4 نشان داده شده است، به اطلاعاتی که نگهداری میکنند به شکل مجموعه ای از فایلها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، مینگرند. -The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4. Insert 18333fig0104.png -Figure 1-4. Other systems tend to store data as changes to a base version of each file. +تصویر 1-4. دیگر سیستم ها داده ها به شکل تغییرات در ورژن پایه هر فایل ذخیره می کنند. -Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5. +Git از چنین تفکر یا روش ذخیره سازی داده ای پیروی نمی کند. در عوض دیدگاه Git نسبت به داده های خود به شکل snapshotهایی از یک سیستم فایلی کوجک است. هر زمانی که شخص commitای انجام میدهد یا وضعیت پروژه خود را در Git ذخیره می کند، در اصل تصویری از وضعیت تمامی فایل ها در لحظه موردنظر تهیه و ارجاعی به snapshot ایجاد شده ذخیره می شود. برای آنکه این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی کند - تنها ارتباطی (link) به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است. Insert 18333fig0105.png -Figure 1-5. Git stores data as snapshots of the project over time. +تصویر 1-5. Git داده ها را به شکل snapshotهایی از پروژه در مرور زمان نگهداری میکند. + +این شکل نگرش مهمترین اصل تمایز Git با دیگر VCSها است. این امر موجب می شود تا Git تجدیدنظری نسبت به تمامی ابعاد کنترل ورژن داشته باشد، که اکثریت دیگر سیستم ها از نسل های قبل از خود به ارث برده اند. این موضوع باعث شده است تا Git از یک VCS ساده، به سیستم فایلی کوچکی بدل شود که در بالادست آن ابزار قدرتمند باورنکردنی بنا شده است. در فصل 3 بعضی از مزایای چنین دیدگاهی نسبت به داده پوشش داده می شود. -This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3. +### تقریباً تمام عملیات به صورت محلی انجام می پذیرد ### -### Nearly Every Operation Is Local ### +اکثر عملیاتی که در Git انجام میپذیرد جهت اجرا تنها نیازمند فایلها و منابع محلی هستند - به طور کلی نیازمند هیچگونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده اید که در آن اکثر فعالیت ها دارای افزونگی رکود شبکه ای داشته اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می رسد که اکثر عملیات به صورت لحظه ای و بلادرنگ انجام می پذیرند. -Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. +به عنوان مثال، Git برای نمایش تاریخچه پروژه نیازی جهت مراجعه به سرور برای اخذ تاریخچه و نمایش آن ندارد - Git این عمل را با خواندن مستقیم پایگاه داده محلی انجام میدهد. این بدان معناست که شخص میتوان تاریخچه پروژه را تقریباً بلادرنگ مشاهده کند. اگر نیاز به مشاهده تغییرات بین ورژن فعلی یک فایل با ورژن یک ماه قبل از آن باشد، Git میتواند بجای آنکه از سرور درخواست این عمل را داشته باشد و یا آنکه نسخه قبلی را از سرور خارجی فراخوانی و سپس مقایسه محلی را انجام دهد، این عمل را با نگاهی به نسخه یک ماه قبل فایل و انجام محاسبات محلی تغییرات رخ داده، انجام میدهد. -For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. +همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، میتوانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه ای در کار شما حاصل نمی شود. در اکثریت دیگر سیستم ها انجام این موارد غیرممکن یا به سختی انجام می پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دستکاری فایل ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تغییرات بزرگی که میتواند به موجب آن ایجاد شود، شگفت زده شوید. -This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. +### Git صداقت دارد ### -### Git Has Integrity ### +هرچیزی که بخواهد در Git ذخیره شود، ابتدا checksum آن محاسبه میشود و سپس بوسیله همین checksum ارجاع داده میشود. چنین عملی موجب میشود که در صورت ایجاد کوچکترین تغییری در مححتویات فایل یا پوشه ای، Git از آن آگاهی پیدا کند. این دستورالعمل در Git در پایینترین سطح پیاده سازی شده است و تاییدی بر صحت فلسفه Git دارد. بدین دلیل است که اگر داده ای در حین انتقال از دست برود و یا فایلی مخدوش شود، Git به سرعت از آن اطلاع پیدا میکند. -Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it. +مکانیزمی که Git برای تولید checksum استفاده میکند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه میگردد. در ادامه یک نمونه از هش SHA-1 آورده شده است: -The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this: 24b9da6552252987aa493b52f8696cd6d3b00373 -You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents. +به علت استفاده زیاد Git از این هش، به کرات در جای جای Git مشاهده گر این هش ها خواهید بود. در واقع، Git از نام فایل برای ذخیره سازی آن استفاده نمیکند بلکه Git از هش تولید شده از محتویات فایل مربوطه برای آدرس دهی آن در پایگاه داده خود بهره میگیرد. + +### عموماً Git فقط داده اضافه میکند ### ### Git Generally Only Adds Data ### -When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. +هرگاه عملی در Git انجام میپذیرد، تقریباً در تمامی موارد Git داده ای به داده های خود در پایگاه داده اضافه می کند. انجام دادن عملی در این سیستم که برگشت پذیر نباشد یا باعث حذف داده ای از سیستم شود، بسیار سخت است. مشابه اکثر VCSها، فرد میتواند تا قبل از commit هرگونه تغییراتی را انجام دهد؛ ولی به محض commit یک snapshot در Git، امکان حذف آن بسیار سخت است، مخصوصاً اگر فرد عادتاً پایگاه داده خود را به repository دیگری push کند. + +این قابلیت باعث می شود که استفاده از Git، به عملی فرح بخش تبدیل شود زیرا فرد خواهد توانست بدون در خطر انداختن چیزی دست به هرگونه آزمایشی بزند. برای آشنایی بیشتر با چگونگی عملکرد Git در ذخیره سازی و بازیابی داده هایی که به نظر از دست رفته می باشند، میتوانید به فصل 9 مراجعه کنید. -This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9. +### سه وضعیت ### ### The Three States ### -Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. +توجه، توجه. اگر میخواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این مطلب را به خاطر بسپارید. فایلها در Git میتوانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای به موجب این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته میباشد که ورژن فعلی آن جهت snapshot بعدی جهت commit نشانه گذاری شده است. -This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. +حال میتوان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area. Insert 18333fig0106.png -Figure 1-6. Working directory, staging area, and Git directory. +تصویر 1-6. پوشه در حال کار، staging area و پوشه Git -The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. +در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره میشوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از repository کامپیوتری cloneای گرفته می شود، کپی از این پوشه ایجاد میگردد. -The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. +پوشه در حال کار، checkout منفردی از ورژنی از پروژه است. فایلهای این بخش، فایلهایی می باشند که از پایگاه داده فشرده واقع در پوشه Git بیرون کشیده شده و جهت استفاده و ایجاد تغییر بر روی دیسک قرار داده شده اند. -The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area. +staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص میکند که چه چیزهایی در commit بعدی قرار میگیرند. معمولاً از این فایل را index مینامند ولی staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است. -The basic Git workflow goes something like this: +روند کاری Git عموماً به صورت ذیل است: -1. You modify files in your working directory. -2. You stage the files, adding snapshots of them to your staging area. -3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. +1. ایجاد تغییرات روی فایلهای واقع در پوشه در حال کار. +2. stage کردن فایلها و اضافه کردن snapshotهای فایلها به staging area. +3. commit کردن، که به موجب آن وضعیت فعلی فایلها در staging area تحت یک snapshot به صورت دائمی در پوشه Git ذخیره میگردد. -If a particular version of a file is in the Git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. +اگر ورژنی از یک فایل در پوشه git قرار داشته باشد، commit شده فرض میشود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه ای که check out شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه میتوان از آنها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد. -## Installing Git ## +## نصب Git ## -Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform. +حال وقت آن است که کار با Git را شروع کنیم. اول از هر چیز میبایست Git را نصب کرد. روشهای مختلفی برای این کار وجود دارد؛ دو مورد از رایجترین این روشها نصب از طریق سورس یا نصب به واسطه پکیج های موجودی است که برای پلتفرم مورد نظر شما تهیه شده است. -### Installing from Source ### +### نصب از طریق سورس ### -If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet. +اگر امکان نصب از طریق سورس برای شما وجود دارد، این روش مناسبترین روش جهت نصب میباشد، زیرا شما بعد از نصب آخرین ورژن نرم افزار را در اختیار خواهید داشت. در هر نسخه از Git سعی شده است که تا در رابط کاربری بهبودهایی حاصل شود، بنابراین در اختیار داشتن آخرین ورژن بهترین گزینه است البته اگر با کامپایل سورس نرم افزار مشکلی نداشته باشید. همچنین معمولاً مخازن نرم افزاری اکثر توزیعهای لینوکس در بر دارنده پکیجهایی با ورژنهای قدیمی هستند؛ بنابراین در صورتی که شما توسعه دهنده ای به روز هستید یا از backportها استفاده میکنید، نصب از طریق سورس بهترین انتخاب برای شما می باشد. -To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: +برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار میکنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، میتوانید برای نصب این بسته های نیازمندی از دستورهای ذیل استفاده کنید: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel @@ -140,65 +140,67 @@ To install Git, you need to have the following libraries that Git depends on: cu $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev -When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: +حال که تمامی نیازمندیها نصب گردید، میتوان آخرین نسخه Git را از وب سایت آن دانلود کرد: http://git-scm.com/download -Then, compile and install: +و آن را کامپایل و نصب کرد: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install -After this is done, you can also get Git via Git itself for updates: +بعد از کامل شدن این مراحل میتوان از خود Git برای دریافت آپدیت های Git استفاده کرد: $ git clone git://git.kernel.org/pub/scm/git/git.git -### Installing on Linux ### +### نصب بر روی لینوکس ### -If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum: +اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، میتوانید این کار را از طریق ابزار مدیریت بسته های نرم افزاری که همراه توزیع موردنظر شما ارائه می شود انجام دهید. اگر توزیع شما Fedora است، میتوانید از yum استفاده کنید: $ yum install git-core -Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: +یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، میتوانید از apt-get استفاده کنید: $ apt-get install git -### Installing on Mac ### +### نصب بر روی Mac ### -There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7): +برای نصب بر روی Mac دو روش آسان وجود دارد. آسانترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7): - http://sourceforge.net/projects/git-osx-installer/ + http://code.google.com/p/git-osx-installer Insert 18333fig0107.png -Figure 1-7. Git OS X installer. +تصویر 1-7. نصاب Git OS X -The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via +روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPorts را نصب شده روی سیستم خود دارید، میتوانید Git را با دستور ذیل نصب کنید $ sudo port install git-core +svn +doc +bash_completion +gitweb -You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). +نیازی به افزودن تمامی اضافات نیست، ولی شاید برای استفاده از Git به همراه مخازن Subversion، احتمالاً افزودن +svn گزینه مناسبی است. + +### نصب بر روی ویندوز ### -### Installing on Windows ### +نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسانترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد: -Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: + http://msysgit.github.com/ - http://msysgit.github.io +بعد از اتمام نصب، هم نسخه خط فرمان (شامل SSH client که در ادامه مشاهده خواهد شد که ابزاری کارآمد است) و هم رابط گرافیکی استاندارد را در اختیار خواهید داشت. -After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. +نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix)، تا بتواند دستورات چند خطی پیچیده ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز / کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان میرسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است. -Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of single quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. +## تنظیمات شروع به کار Git ## ## First-Time Git Setup ## Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. -Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: +Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: * `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. * `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. -* config file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +* config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. From 8a8974877aee75884c58cdcec0aa152a151abaaa Mon Sep 17 00:00:00 2001 From: mxamin Date: Sun, 27 Jul 2014 23:41:21 +0430 Subject: [PATCH 120/291] [fa] chapter 1 update --- fa/01-introduction/01-chapter1.markdown | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown index 44d312701..f03cf8c65 100644 --- a/fa/01-introduction/01-chapter1.markdown +++ b/fa/01-introduction/01-chapter1.markdown @@ -192,26 +192,26 @@ Insert 18333fig0107.png ## تنظیمات شروع به کار Git ## -## First-Time Git Setup ## +حال که Git روی سیستم نصب شده است، نیاز به شخصی سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان قابل انجام است. -Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. +به همراه Git ابزاری ارائه شده است با نام git config که امکان خواندن و اعمال متغیرهای تنظیماتی که تمامی ابعاد ظاهری و عملیاتی Git را کنترل می‌کند فراهم می‌سازد. -Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: +* فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم و مخازن آن‌ها است. اگر به همراه `git config` از آپشن `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد. +* فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از آپشن `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد. +* فایل config موجود در پوشه git (`.git/config`) یا هر مخزنی که در حال استفاده از آن می‌باشید: مختص یک مخزن خاص است. مقادیر هر سطح باعث لغو مقادیر سطح قبلی خود می‌شود. بنابراین مقادیر `.git/config` موجب لغو مقادیر `/etc/gitconfig` خواهد شد. -* `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. -* `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. -* config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به ورژن سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد. -On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. +### شناسه کاربر ### -### Your Identity ### - -The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: +اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی کردن دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند. $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project. +مجدداْ یادآوری می‌شود که انجام این عمل در صورت استفاده از آپشن `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی داردُ، می‌تواند با اجرای همان دستورات البته بدون استفاده از آپشن `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد. + +### ویرایشگر کاربر ### ### Your Editor ### From 1781fde635bf9d6ebcde7e9c6902012de5c371bb Mon Sep 17 00:00:00 2001 From: mxamin Date: Mon, 28 Jul 2014 09:04:32 +0330 Subject: [PATCH 121/291] [fa] chapter 1 complete translation of chapter 1 completed but it needs another lookup for spelling correction and some minor modifications. --- fa/01-introduction/01-chapter1.markdown | 37 ++++++++++++------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown index f03cf8c65..09f80590b 100644 --- a/fa/01-introduction/01-chapter1.markdown +++ b/fa/01-introduction/01-chapter1.markdown @@ -202,7 +202,7 @@ Insert 18333fig0107.png در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به ورژن سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد. -### شناسه کاربر ### +### شناسه ### اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی کردن دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند. @@ -211,25 +211,23 @@ Insert 18333fig0107.png مجدداْ یادآوری می‌شود که انجام این عمل در صورت استفاده از آپشن `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی داردُ، می‌تواند با اجرای همان دستورات البته بدون استفاده از آپشن `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد. -### ویرایشگر کاربر ### +### ویرایشگر ### -### Your Editor ### - -Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following: +حال که شناسه تنظیم شد، میتوان ویرایشگر متنی پیش فرضی را معرفی کرد تا هنگامی که نیاز به نوشتن پیغامی در Git وجود دارد فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، میتوان به صورت ذیل عمل کرد: $ git config --global core.editor emacs -### Your Diff Tool ### +### ابزار Diff ### -Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff: +ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در استفاده از دستور merge استفاده میگردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت: $ git config --global merge.tool vimdiff -Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that. +Git ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff را به عنوان ابزارهایی معتبر جهت merge می شناسد. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد میتوانید به فصل 7 مراجعه کنید. -### Checking Your Settings ### +### بررسی تنظیمات ### -If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: +برای مشاهده و بررسی تنظیمات، میتوان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می دهد: $ git config --list user.name=Scott Chacon @@ -240,28 +238,29 @@ If you want to check your settings, you can use the `git config --list` command color.diff=auto ... -You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees. +احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شود، دلیل این امر آن است که Git کلید مشابهی را از فایلهای مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده باشد. در اینگونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می کند را مورد استفاده قرار میدهد. -You can also check what Git thinks a specific key’s value is by typing `git config {key}`: +همچنین برای مشاهده مقدار مورداستفاده یک کلید خاص توسط Git، میتوان از دستور `git config {key}` استفاده کرد: $ git config user.name Scott Chacon -## Getting Help ## +## دریافت راهنمایی ## -If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: +هرگاه در استفاده از Git نیازمند راهنمایی بودید، سه روش برای مشاهده صفحه راهنما (manpage) هرگونه دستوری در Git وجود دارد: $ git help $ git --help $ man git- -For example, you can get the manpage help for the config command by running +برای مثال، برای مشاهده راهنما manpage دستور config داریم $ git help config -These commands are nice because you can access them anywhere, even offline. -If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. +این دستورات از آن جهت که میتوان از هر مکانی، حتی در حالت آفلاین، به آنها دسترسی پیدا کرد ابزاری کاربردی میباشند. +اگر manpageها و این کتاب جوابگوی نیاز شما نبودند و نیاز به راهنمایی فردی پیدا کردید، میتوانید به کانالهای `#git` یا `#github` در سرور Freenode IRC (irc.freenode.net) مراجعه کنید. +معمولاً این کانالها مملؤ از افرادی با سطح دانش بالا در زمینه Git هستند که آماده راهنمایی رساندن به شما می باشند. -## Summary ## +## خلاصه ## -You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics. +با مطالعه این فصل شما باید درک اولیه ای از این که Git چیست و چه تفاوتی با دیگر CVCSهایی که احتمالاً از آن استفاده میکردید پیدا کرده باشد. همچنین شما باید نسخه آماده به کاری از Git را روی سیستم خود داشته باشید که با شناسه شخصی شما تنظیم شده است. حال زمان یادگیری اصول اولیه Git است. From 1cb178b66d7e015fdfb5df96ba3bd6ec337a9f03 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 28 Jul 2014 17:46:34 +0200 Subject: [PATCH 122/291] [it] Update URL used in cURL to fetch from Grit library Add -L flag to cURL command to follow any redirects cURL by default will not follow redirects, leading to blank file unless the `-L` flag is included since all resources once hosted on raw.github.com are now on the raw.githubusercontent.com domain. Fixes issue mentioned at https://github.com/git/git-scm.com/issues/422 See also PR #811 --- it/09-git-internals/01-chapter9.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/09-git-internals/01-chapter9.markdown b/it/09-git-internals/01-chapter9.markdown index b39dc0830..56fe57b36 100644 --- a/it/09-git-internals/01-chapter9.markdown +++ b/it/09-git-internals/01-chapter9.markdown @@ -451,7 +451,7 @@ Torniamo agli oggetti del database per il tuo repository Git di test. A questo p Git comprime il contenuto di questi file con zlib e, poiché non stai memorizzando molte cose, complessivamente tutti questi file occupano solo 925 bytes. Aggiungeremo al repository del contenuto più pesante per dimostrare un’interessante caratteristica di Git. Aggiungi il file repo.rb dalla libreria Grit che abbiamo visto prima: sono circa 12K di sorgenti: - $ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb + $ curl -L http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb $ git add repo.rb $ git commit -m ‘aggiunto repo.rb' [master 484a592] aggiunto repo.rb From 37947df9797c67b03d24d34a262a6e231b0c56e9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Barbosa?= Date: Wed, 30 Jul 2014 16:36:56 -0300 Subject: [PATCH 123/291] Phrase fix in line 35 Updated the 'or' clause for the correct in portuguese is 'ou' --- pt-br/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt-br/01-introduction/01-chapter1.markdown b/pt-br/01-introduction/01-chapter1.markdown index 3d0937919..aa852021c 100644 --- a/pt-br/01-introduction/01-chapter1.markdown +++ b/pt-br/01-introduction/01-chapter1.markdown @@ -32,7 +32,7 @@ Entretanto, esse arranjo também possui grandes desvantagens. O mais óbvio é q ### Sistemas de Controle de Versão Distribuídos ### -É aí que surgem os Sistemas de Controle de Versão Distribuídos (Distributed Version Control System ou DVCS). Em um DVCS (tais como Git, Mercurial, Bazaar or Darcs), os clientes não apenas fazem cópias das últimas versões dos arquivos: eles são cópias completas do repositório. Assim, se um servidor falha, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo. Cada checkout (resgate) é na prática um backup completo de todos os dados (veja Figura 1-3). +É aí que surgem os Sistemas de Controle de Versão Distribuídos (Distributed Version Control System ou DVCS). Em um DVCS (tais como Git, Mercurial, Bazaar ou Darcs), os clientes não apenas fazem cópias das últimas versões dos arquivos: eles são cópias completas do repositório. Assim, se um servidor falha, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo. Cada checkout (resgate) é na prática um backup completo de todos os dados (veja Figura 1-3). Insert 18333fig0103.png Figura 1-3. Diagrama de Controle de Versão Distribuído. From 7376aaff1a6e8f7de8536ca261032cc36903aab3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Thu, 31 Jul 2014 17:56:11 +0200 Subject: [PATCH 124/291] translated 3 sections --- no-nb/01-introduction/01-chapter1.markdown | 25 +++++++++++----------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 6957dc82f..6966cdf11 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -8,7 +8,7 @@ Hva er versjonskontroll, og hvorfor burde du bry deg? Versjonskontroll er et sys Er du en grafisk designer eller arbeider med webdesign og ønsker å beholde alle versjoner av et bilde eller en layout (som du sannsynligvis vil), så er det lurt å bruke et Version Control System (VCS). Et VCS gjør det mulig for deg å: tilbakestille filer til en tidligere utgave, tilbakestille hele prosjektet til en tidligere utgave, sjekke forandringer over tid, se hvem som sist forandret noe som muligens forårsaker et problem, hvem som introduserte en sak og når, osv. Å benytte seg av et VCS betyr også at dersom du roter det til eller mister filer, kan du vanligvis komme tilbake opp å kjøre raskt og enkelt. I tillegg, så får du alt dette uten at det krever noe videre av deg eller systemet ditt. -### Lokalt versjonsstyringssystem ### +### Lokalt versjonskontrollsystem ### Mange folks valgte versjonskontrollmetode innebærer å kopiere filer til en annen mappe (kanskje med datomerking hvis de er smarte). Denne tilnærmingen er vanlig, fordi den er enkel, men det kan også fort gå galt. Det er lett å glemme hvilken mappe man befinner seg i og så ved et uhell skrive til feil fil, eller kopiere over filer man ikke mente. @@ -30,28 +30,29 @@ This setup offers many advantages, especially over local VCSs. For example, ever However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. -### Distributed Version Control Systems ### +### Distribuerte versjonkontrollsystemer ### -This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3). +Her er det Distribuerte Versjonkontrollsystemer (DVCSer) komme inn. I et DVCS (slik som Git, Mercurial, Bazaar eller Darcs), så henter ikke klientene bare ut det nyeste bildet av filene: de speilere hele repositoriet. Så derfor, om en server skulle dø, og disse systemene samarbeidet via den, så kan hvilken som helst av klient repositoriene bli kopiert opp til serveren for å fikse det. Hver utsjekking er en hel backup av alle dataene (see Figure 1-3). Insert 18333fig0103.png Figure 1-3. Distributed version control diagram. -Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. +Mange av disse systemene håndterer også veldig godt det å ha flere fjerne repositorier å jobbe mot, sq du kan sammarbeide med flere forskjellige grupper folk på forskjellige måter samtidig innen for det samme prosjektet. Dette lar deg sette opp flere arbeidsmåter som ikke er mulig i sentraliserte systemer, som hierarkiske modeller. -## A Short History of Git ## +## Kort Historie om Git ## -As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. +Som mange flotte ting i livet, så begynte Git med litt kreativ ødeleggelse og voldsom uenighet. Linux kjernen er et åpenkildekode prosjekt ved en ganske vidt skop. Mesteparten av livet til Linux kjerne vedlikeholdet (1991-2002), så var endringer i programvaren sendt rundt som patcher og arkiverte filer. I 2002 begynte Linux kjerne prosjektet å bruke et proprietært DVCS system med navn BitKeeper. -In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: +I 2005 så falt forholdet mellom samholdet som utviklet Linux-kjernen og det komersielle firmaet som utviklet Bitkeeper sammen, og verktøyets gratis-bruk status ble fjernet. Dette fikk Linux utviklingssamholdet (og spesielt Linux Torvals, skaperen av Linux) til å utvikle deres eget verktøy med grunnlag i noen av tingene de lærte mens de brukte BitKeeper. Noen av målene for det nye systemet ble som følger: -* Speed -* Simple design -* Strong support for non-linear development (thousands of parallel branches) -* Fully distributed +* Fart +* Enkelt design +* Sterk støtter for ikke-lineær utvikling (tusenvis av parallelle grener) +* Helt distribuert * Able to handle large projects like the Linux kernel efficiently (speed and data size) +* I stand til å håndtere store prosjekter som Linux-kjernern effektivt (fart og datastørrelse) -Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). +Siden den ble skapt i 2005, har Git utviklet seg og modnet til å bli et enkelt å bruke men forsatt beholde disse opprinnelige kvalitetene. Den er er utrolig rask, og den er veldig effektiv med store prosjekter, og den har et utrolig avgreningsystem for ikke-lineær utvikling (See Chapter 3). ## Git Basics ## From 327906ab6ae0ecdf712cc4b377ebc544b88592e9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Thu, 31 Jul 2014 18:18:00 +0200 Subject: [PATCH 125/291] added no-nb to makeebooks script --- makeebooks | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/makeebooks b/makeebooks index 5d2f308e4..25d3310ea 100755 --- a/makeebooks +++ b/makeebooks @@ -83,6 +83,11 @@ ARGV.each do |lang| figure_title = 'Obrázek' book_title = 'Pro Git — profesionální správa verzí' comments = 'Licence: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license' + elsif lang == "no-nb" + figure_title = 'Figur' + book_title = 'Pro Git - profesjonell versjonkontroll' + comments = 'Lisens: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license' + end book_content = %(#{book_title}) From dad6608b46eacb107cb128a0ca67daf14c6d409f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Thu, 31 Jul 2014 19:33:27 +0200 Subject: [PATCH 126/291] 'no-NB' translated 2 sub-sections chapter 1 --- no-nb/01-introduction/01-chapter1.markdown | 25 +++++++++++----------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 6966cdf11..1fdb7d062 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -54,31 +54,32 @@ I 2005 så falt forholdet mellom samholdet som utviklet Linux-kjernen og det kom Siden den ble skapt i 2005, har Git utviklet seg og modnet til å bli et enkelt å bruke men forsatt beholde disse opprinnelige kvalitetene. Den er er utrolig rask, og den er veldig effektiv med store prosjekter, og den har et utrolig avgreningsystem for ikke-lineær utvikling (See Chapter 3). -## Git Basics ## +## Grunnleggende Git ## -So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. +Så, hva er Git i et nøtteskall? Dette er en veldig viktig seksjon og ta innover seg, fordi om du forstår hva Git er og det fundamentelle rundt hvordan det virker, så vil det å bruke Git effektiv, sannsynligvis bli mye enklere for deg. Etter som du lærer Git, prøv å tøm tankene for de tingene du vet om andre VCSer, som Subversion og Perforce; å gjøre det vil hjelpe deg å unngå småforvirring når du bruker verktøyet. Git lagrer og tenker på informasjon veldig annerledes disse andre systemene, selv om bruker grensesnittet er ganske likt; å forstå de forskjellene vil hjelpe deg unngå å bli forvirret mens du bruker det. -### Snapshots, Not Differences ### -The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4. +### Bilder, Ikke Forskjeller ### + +Hovedforskjellen mellom Git og andre VCS verktøy (inklusivt Subversion og dens venner) er hvordan den tenker på sin data. Konseptuelt, så lagrer de fleste andre systemer informasjon som en liste over filbaserte endringer. Disse systemene (CVS, Subversion, Perforce, Bazaar, og så vidre) tenker på informasjon som det tar vare på som et sett med filer og endringene gjort til hver fil over tid, som illustrert i Figur 1-4. Insert 18333fig0104.png -Figure 1-4. Other systems tend to store data as changes to a base version of each file. +Figure 1-4. Andre systemer pleier å lagre data som endringer til en grunnleggende versjon av hver fil. -Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5. +Git verken tenker eller lagrere dataen på denne måten. Istedet så tenker Git på dataen mer som et sett med bilder av mini filsystemer. Hver gang du commit-er, eller lagrere tilstanden for prosjektet ditt i Git, så tar den i hovedask et bilde av hvordan alle filene dine ser ut i det øyeblikket of lagrer en referanse til det bildet. For å være effektiv, hvis filer ikke har blitt endre, så lagrer ikke Git filen igjen, den bare linker til forrige indentiske fil som den allerede har lagret. Git tenker på dataen mer som Figure 1-5. Insert 18333fig0105.png -Figure 1-5. Git stores data as snapshots of the project over time. +Figure 1-5. Git lagrere data som et bilde av prosjektet over tid. -This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3. +Dette er et viktig skille mellom Git og nesten alle andre VCSer. Det gjør at Git revurderer nesten alle aspekter av versjonkontroll som de fleste andre systemer kopierte fra den forrige generasjonen. Dette gjør Git mer til et mini-filsystem som har utrolig kraftige verktøy bygd oppå seg, istedet for bare en VCS. Vi vil utforske noen av fordelene du vil få ved å tenke på dataen din på denne måten når vi dekker Git avgrening i Kapitell 3. -### Nearly Every Operation Is Local ### +### Nærmest Alle Operasjoner Er Lokale ### -Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. +De fleste operasjonene i Git trenger bare lokale filer og resurser for å operer - generelt sett så er ikke informasjon fra noen annen maskin på nettverket ditt nødvendig. Hvis du har brukt en CVCS hvor de fleste operasjoner har den type nettverk forsinkelse, så vil dette aspektet av Git få deg til å tenke at gudene for fart har velsignet Git med uparallelle krefter. Fordi du har hele historien til prosjektet rett der på den lokale disk, så virker de fleste operasjoner som om de nesten skjer med en gang. -For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. +For eksempel, for å se gjennom historien til prosjektet, så trenger ikke Git å gå til serveren for å få historien, og vise det til deg- den simpelthen leser den rett fra din likale database. Dette betyr at du ser prosjekt historien nesten med en gang. Hvis du ønsker å se endringene introdusert mellom den nåværende versjonen av filen og filen for en måned isden, så kan Git sjekke den filen fra en måned siden og gjøre en lokal forskjell kalkulasjon, istedet for å enten måtte spøre en server om å gjøre det, eller å måtte hente en eldre versjon av filen fra den serveren for å gjøre det lokalt. -This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. +Dette betyr også at det er veldig lite du ikke kan gære om du er offline eller ikke er på VPN. Du kan gå på et fly, eller et tog og så ønske å jobbe litt, og du kan gladelig comitte det fram til du kommer til en nettverkstilkobling for å laste det opp. Hvis du går hjem og ikke kan få VPN klienten til å virke skikkelig, så kan du fortsatt jobbe. I mange systemer, så er det enten umulig å gjøre, eller smertefult. I Perforce, for eksempel, så kan du ikke gjære stort når du ikke er koblet til serveren, og i Subversion og CVS, så kan du endre filer, men du kan ikke bruke commit på endringene dine til databasen (siden databasen din er offline). Dette virker kanskje ikke som noe stort, men du kan bli overrasket over hvor stor forskjell det kan utgjøre. ### Git Has Integrity ### From e11b06b2376e35ee84d78077290299a7615dc972 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Thu, 31 Jul 2014 21:19:34 +0200 Subject: [PATCH 127/291] no-NB translated 2 sections in Chapther 1 "Git has Integrity" "Git generally only add data" --- no-nb/01-introduction/01-chapter1.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 1fdb7d062..1163c12c6 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -81,21 +81,21 @@ For eksempel, for å se gjennom historien til prosjektet, så trenger ikke Git Dette betyr også at det er veldig lite du ikke kan gære om du er offline eller ikke er på VPN. Du kan gå på et fly, eller et tog og så ønske å jobbe litt, og du kan gladelig comitte det fram til du kommer til en nettverkstilkobling for å laste det opp. Hvis du går hjem og ikke kan få VPN klienten til å virke skikkelig, så kan du fortsatt jobbe. I mange systemer, så er det enten umulig å gjøre, eller smertefult. I Perforce, for eksempel, så kan du ikke gjære stort når du ikke er koblet til serveren, og i Subversion og CVS, så kan du endre filer, men du kan ikke bruke commit på endringene dine til databasen (siden databasen din er offline). Dette virker kanskje ikke som noe stort, men du kan bli overrasket over hvor stor forskjell det kan utgjøre. -### Git Has Integrity ### +### Git Har Integritet ### -Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it. +Alt i Git er sjekksummert før det er lagret, og så blir den referert til med den sjekksummen. Dette betyr at det umulig å endre innhodlet på en fil eller mappe uten at Git vet om det. Denne funksjonaliteten er bygd inn i Git på de laveste nivåene og er viktig del av dens filosofi. Du kan ikke miste informasjon når den prossesserer endringer eller ende opp med en korrupt fil uten at Git er i stand til å oppdage det. -The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this: +Mekanismen Git bruker for denne sjekksummeringen er kalt en SHA-1 hash. Dette er en 40-tegn lang tekst satt sammen av hexadecimal-tegn (0-9 og a-f) og er kalkulert baser på innholdet av en fil og mappe structuren i Git. En SHA-1 hash ser ut noe sånt som dette: 24b9da6552252987aa493b52f8696cd6d3b00373 -You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents. +Du vil se disse hash verdiene overalt i Git fordi den bruker dem så mye. Git lagrer faktisk alt, ikke med navn, men i Git databasen adresserbart med hash verdien av innholdet dens. -### Git Generally Only Adds Data ### +### Git Legger Generelt Bare Til Data ### -When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. +Når du gjør ting i Git, så vil nesten alle bare legge til data til Git databasen. Det er veldig vanskelig å få systemet til å gjøre noe som ikke kan angres, eller få det til å slette data på en eller annen måte. Som i en hver VCS, så kan du miste eller rote til endringer du ikke har commitet enda; men etter du har commited et bilde inn i Git, så er det veldig vanskelig å miste det, spesielt om du jevnlig bruker push for å sende databasen til en annen repository. -This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9. +Dette gjør det å bruke Git til en gledelig opplevelse fordi vi vet at vi kan eksperimentere uten fare for å virkelig rote til ting skikkelig. For en mer dypere innsyn i hvoradn Git lagerer data og hvordan du kan få tilbake data som virker tapt, se Kapitel 9. ### The Three States ### From fa7b20f4a00d4fd2f0f37b8b04b7a52dd0c7869b Mon Sep 17 00:00:00 2001 From: mxamin Date: Fri, 1 Aug 2014 00:08:45 +0430 Subject: [PATCH 128/291] [fa] Update Chapter 1 Some minor modification on chapter 1. Added some notes for better translation. Updated README file. --- fa/01-introduction/01-chapter1.markdown | 166 ++++++++++++------------ fa/NOTES.en-fa.md | 143 ++++++++++++++++++++ fa/README.md | 6 +- 3 files changed, 227 insertions(+), 88 deletions(-) create mode 100644 fa/NOTES.en-fa.md diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown index 09f80590b..f259f012f 100644 --- a/fa/01-introduction/01-chapter1.markdown +++ b/fa/01-introduction/01-chapter1.markdown @@ -1,138 +1,134 @@ # سرآغاز # -در این فصل در رابطه با شروع کار با Git صحبت خواهد شد. این فصل با توضیحاتی در رابطه با تاریخچه ابزارهای کنترل ورژن شروع می شود، سپس چگونگی راه اندازی Git برروی یک سیستم خاص آموزش داده می شود و در انتها انجام تنظیمات موردنیاز برروی این نرم افزار جهت شروع به کار با آن مورد بررسی قرار می گیرد. در انتهای این فصل خواننده باید دلیل وجود و استفاده از Git را بداند و همچنین باید محیط کار را برای استفاده از آن فراهم کرده باشد. +در این فصل در رابطه با شروع کار با Git صحبت خواهد شد. این فصل با توضیحاتی در رابطه با تاریخچه ابزارهای کنترل نسخه شروع می‌شود، سپس چگونگی راه اندازی Git برروی یک سیستم خاص آموزش داده خواهد شد و در انتها انجام تنظیمات موردنیاز برروی این نرم افزار جهت شروع به کار با آن مورد بررسی قرار می‌گیرد. در انتهای این فصل خواننده باید دلیل وجود و استفاده از Git را بداند و همچنین باید محیط کار را برای استفاده از آن فراهم کرده باشد. -## کنترل ورژن ## +## کنترل نسخه ## -کنترل ورژن چیست و چه اهمیتی دارد؟ کنترل ورژن سیستمی است که تغییرات مربوط به یک یا چندین فایل را در طول زمان ذخیره می کند، تا کاربر بتواند به ورژن های قبلی مراجعت داشته باشد. در مثالهای استفاده شده در این کتاب از فایل های سورس نرم افزار جهت نمایش کنترل ورژن استفاده میشود، ولی با این وجود میتوان هر نوع فایلی را تحت کنترل ورژن قرار داد. +کنترل نسخه چیست و چه اهمیتی دارد؟ کنترل نسخه سیستمی است که تغییرات مربوط به یک یا چندین فایل را در طول زمان ذخیره می‌کند، تا کاربر بتواند به نسخه‌های قبلی مراجعت داشته باشد. در مثال‌های استفاده شده در این کتاب از فایل های سورس نرم افزار جهت نمایش کنترل نسخه استفاده می‌شود، ولی با این وجود می‌توان هر نوع فایلی را تحت کنترل نسخه قرار داد. -اگر شما یک گرافیست یا طراح وب باشید و تصمیم به نگهداری تمامی ورژنهای یک عکس یا ساختار باشید (که قطعا به همین منوال است)، استفاده از یک سیستم کنترل ورژن (VCS) راهبردی عاقلانه است. یک VCS این امکان را به شما میدهد که: فایلها را به یک وضعیت قبل برگردانید، یک پروژه را به یک وضعیت قبل برگردانید، تغییرات انجام گرفته در مرور زمان را مشاهده کنید، باعث و بانی تغییری را بیابید که منجر به ایجاد خطا یا مشکلی در سیستم شده است، چه کسی و چه زمانی مسئلهای خاص مطرح شده است و بسیاری موارد دیگر. استفاده از یک VCS حتی این امکان را به شما میدهد که اگر احیاناً خطایی مرتکب شدید یا فایلی را اشتباهاً حذف یا از دست دادید، به راحتی آن را اصلاح و بازیابی کنید. +اگر شما یک گرافیست یا طراح وب باشید و تصمیم به نگهداری تمامی نسخه‌های یک عکس یا ساختار را داشته باشید (که قطعًا به همین منوال است)، استفاده از یک سیستم کنترل نسخه (VCS) راهبردی عاقلانه است. یک VCS این امکان را به شما می‌دهد تا: فایل‌ها یا پروژه‌ای را به یک وضعیت قبل برگردانید، تغییرات انجام گرفته در مرور زمان را مشاهده کنید، باعث و بانی تغییری را که منجر به ایجاد خطا یا مشکلی در سیستم شده است بیابید، چه کسی و چه زمانی موردی خاص را مطرح کرده است و بسیاری موارد دیگر. استفاده از یک VCS حتی این امکان را به شما می‌دهد که اگر احیاناً خطایی مرتکب شدید یا فایلی را اشتباهاً حذف یا از دست دادید، به راحتی آن را اصلاح و بازیابی کنید. -### سیستمهای کنترل ورژن محلی ### +### سیستمهای کنترل نسخه محلی ### -روشی که اکثر کاربران جهت کنترل ورژن انتخاب میکنند شامل کپی کردن فایلها در پوشهای دیگر است (البته اگر هوشمند باشد، پوشه موردنظر را با تاریخ و زمانی مشخص نامگذاری میکنند). چنین روشی به جهت سادگی بین کاربران بسیار رایج میباشد، ولی خطاپذیری بالایی نیز دارد. در این روش امکان دارد فرد به آسانی پوشهای که در آن قرار دارد را فراموش کند و به اشتباه شروع به تغییر برروی فایلهایی کند که مدنظر او نیست. +روشی که اکثر کاربران جهت کنترل نسخه انتخاب می‌کنند شامل کپی کردن فایل‌ها در پوشه‌های دیگر است (البته اگر هوشمندی نشان دهند، پوشه موردنظر را با تاریخ و زمان مشخصی نامگذاری می‌کنند). چنین روشی به جهت سادگی بین کاربران بسیار رایج است، ولی خطاپذیری بالایی نیز دارد. در این روش امکان دارد فرد به آسانی پوشه‌ای که در آن قرار دارد را فراموش کرده و به اشتباه دست به تغییر فایل‌هایی بزند که مدنظر او نیست. -برای مقابله با این موذل، برنامه نویسان از زمانهای بسیار قبل اقدام به توسعه VCSها زده اند که در بردارنده پایگاه داده ساده ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایلهای هدف را در قالب کنترل رویژن نگهداری می کنند (تصویر 1-1) +برای مقابله با این موذل، برنامه نویسان از زمان‌های بسیار قبل اقدام به توسعه VCSها زده‌اند که در بردارنده پایگاه داده ساده‌ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایل‌های هدف را در قالب کنترل نسخه نگهداری می‌کنند (تصویر 1-1) Insert 18333fig0101.png -تصویر 1-1. دیاگرام کنترل ورژن محلی. +تصویر 1-1. دیاگرام کنترل نسخه محلی. -یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار میدهد. این ابزار به زبانی ساده با حفظ مجموعه ای از پچها (که تغییرات بین فایلها میباشند) از یک رویژن به رویژنی دیگر در قالب فرمتی خاص برروی دیسک عمل میکند؛ با چنین سیستمی این ابزار قادر است با متصل کردن پچها به یکدیگر توانایی بازسازی هر فایلی را در هر نقطه ای از زمان داشته باشد. +یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می‌شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار می‌دهد. این ابزار به زبانی ساده با حفظ مجموعه‌ای از وصله‌ها (که تغییرات بین فایل‌ها می‌باشند) از یک نسخه به نسخه‌ای دیگر در قالب فرمتی خاص برروی دیسک عمل می‌کند؛ این ابزار با اجرای چنین سیستمی قادر است با متصل کردن وصله‌ها به یکدیگر توانایی بازسازی هر فایلی را در هر لحظه‌ای از زمان داشته باشد. -### سیستمهای کنترل ورژن مرکزی ### +### سیستمهای کنترل نسخه‌ مرکزی ### -مسئله مهم دیگری که کاربران با آن مواجه میشوند، نیاز آنها به همکاری با دیگر توسعه دهندگان برروی سیستمهای دیگر است. برای حل این مسئله، سیستمهای کنترل ورژن مرکزی (CVCSs) توسعه یافتند. چنین سیستمهایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی ورژنهای فایلها و حتی کاربرانی که این فایلها را از این مکان مرکزی check out کرده اند در خود نگهداری میکند. برای سالهای زیادی، چنین روشی، روشی استاندارد برای کنترل ورژن بوده است (تصویر 1-2). +مسئله مهم دیگری که کاربران با آن مواجه می‌شوند، نیاز آن‌ها به همکاری با دیگر توسعه‌دهندگان برروی سیستم‌های دیگر است. برای حل این مسئله، سیستم‌های کنترل نسخه مرکزی (CVCSs) توسعه یافتند. چنین سیستم‌هایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی نسخه‌های فایل‌ها و حتی کاربرانی که این فایل‌ها را از این مکان مرکزی checkout کرده‌اند در خود نگهداری می‌کند. برای سال‌های زیادی، چنین روشی، روشی استاندارد برای کنترل نسخه بوده است (تصویر 1-2). Insert 18333fig0102.png -تصویر 1-2. دیاگرام کنترل ورژن مرکزی. +تصویر 1-2. دیاگرام کنترل نسخه مرکزی. -این ساختار مزایای بسیاری مخصوصاً نسبت به سیستمهای کنترل ورژن محلی دارد. به عنوان مثال، هر فرد در حد و اندازه مشخصی خواهد توانست بداند که دیگر افراد تا چه اندازه در پروژه شریک هستند. مدیران از این نظر که هرکس از نظر سطح دسترسی قادر به انجام چه کاری است، کنترل مناسبی دارند؛ همچنین مدیریت یک CVCS به مراتب آسانتر از تعامل با پایگاههای داده محلی موجود برروی سیستمهای کاربران است. +این ساختار مزایای بسیاری مخصوصاً نسبت به سیستم‌های کنترل نسخه محلی دارد. به عنوان مثال، هر فرد در حد و اندازه مشخصی خواهد توانست بداند که دیگر افراد تا چه اندازه در پروژه شریک هستند. مدیران از این نظر که هرکس از نظر سطح دسترسی قادر به انجام چه کاری است، کنترل مناسبی دارند؛ همچنین مدیریت یک CVCS به مراتب آسانتر از تعامل با پایگاه‌های داده محلی موجود برروی سیستم‌های کاربران است. -با این وجود، چنین ساختاری معایبی نیز دارد. واضحترین موضوع بروز کوچکترین ایراد در سرورهای مرکزی میباشد. اگر برای مدت یک ساعت این سرور متوقف و از کار بیافتد، در طی این بازه یک ساعته هیچکس نخواهد توانست تعاملی داشته باشد یا حتی تغییرات ورژن را برروی چیزی که در حال کارکردن با آن است ذخیره کند. اگر هارد دیسکی که پایگاه داده مرکزی برروی آن قرار دارد خراب شود، و پشتیبان مناسبی از آن گرفته نشده باشد، کاربر به طور کامل تاریخچه پروژه را از دست خواهد داد به جز snapshotهایی که هر کاربر احتمالاً برروی ماشین محلی خود خواهد داشت. سیستمهای VCS محلی نیز این عیب را به ارث میبرند-اگر کاربر تمامی تاریخچه پروژه را در یک مکان ذخیره کند، ریسک از دادن همه چیز به قوت خود باقی خواهد ماند. +با این وجود، چنین ساختاری معایبی نیز دارد. واضح‌ترین موضوع بروز کوچکترین ایراد در سرورهای مرکزی است. اگر برای مدت یک ساعت این سرور متوقف و از کار بیفتد، در طی این بازه یک ساعته هیچکس نخواهد توانست تعاملی با سرور داشته باشد یا حتی تغییرات نسخه را برروی چیزی که در حال کارکردن با آن است ذخیره کند. اگر هارد دیسکی که پایگاه داده مرکزی برروی آن قرار دارد خراب شود، و پشتیبان مناسبی از آن گرفته نشده باشد، کاربر به طور کامل تاریخچه پروژه را از دست خواهد داد به جز تصاویر لحظه‌ای که هر کاربر احتمالاً برروی ماشین محلی خود خواهد داشت. سیستمهای VCS محلی نیز این عیب را به ارث می‌برند-اگر کاربر تمامی تاریخچه پروژه را در یک مکان ذخیره کند، ریسک از دادن همه چیز به قوت خود باقی خواهد ماند. -### سیستمهای کنترل ورژن پخشی ### +### سیستمهای کنترل نسخه پخشی ### -اینجا است که سیستمهای کنترل ورژن پخشی (DVCSs) نمود پیدا میکنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به check out کردن آخرین snapshot فایلها اکتفا نمیکنند: آنها repository را نیز به صورت کامل کپی میکنند. بنابراین اگر هر سروری که سیستمها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی repository هر کدام از کاربران برروی سرور، عمل بازیابی انجام میگیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده ها است. +اینجا است که سیستم‌های کنترل نسخه پخشی (DVCSs) نمود پیدا می‌کنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به checkout کردن آخرین تصویر لحظه‌ای فایل‌ها اکتفا نمی‌کنند: آن‌ها مخزن را نیز به‌صورت کامل کپی می‌کنند. بنابراین اگر هر سروری که سیستم‌ها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی مخرن هر کدام از کاربران برروی سرور، عمل بازیابی انجام می‌گیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده‌ها است. Insert 18333fig0103.png -تصویر 1-3. دیاگرام کنترل ورژن پخشی. +تصویر 1-3. دیاگرام کنترل نسخه پخشی. -علاوه بر آن اکثر این سیستمها تعامل خوبی با داشتن remote repositoryهای متعدد جهت کار کردن با آنها دارند، در نتیجه شخص خواهد توانست با گروههای مختلفی در قالب پروژه ای یکسان به صورت همزمان تعامل داشته باشد. این قابلیت این امکان را به کاربر خواهد داد که workflowهای متنوعی همانند مدلهای سلسه مراتبی را پیاده سازی کند که انجام آن در سیستمهای متمرکز امکان پذیر نیست. +علاوه بر آن اکثر این سیستم‌ها تعامل خوبی با داشتن مخازن خارجی متعدد جهت کار کردن با آن‌ها دارند، در نتیجه شخص خواهد توانست با گروه‌های مختلفی در قالب پروژه‌ای یکسان به‌صورت همزمان تعامل داشته باشد. این قابلیت این امکان را به کاربر خواهد داد که جریان‌های کاری متنوعی همانند مدل‌های سلسه مراتبی را پیاده سازی کند که انجام آن در سیستم‌های متمرکز امکان پذیر نیست. ## تاریخچه کوتاهی از Git ## -همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم افزاری متن باز با وسعت نسبتاً زیادی است. برای مدت زمان زیادی از عمر نگهداری هسته لینوکس (1991 - 2002) تغییرات نرم افزاری به واسطه پچ ها و فایلهای آرشیو شده انتقال پیدا میکرد. در سال 2002، پروژه هسته لینوکس اقدام به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد. +همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم‌افزاری متن باز با وسعت نسبتاً زیادی است. جهت نگهداری هسته لینوکس برای مدت زمان زیادی (1991 - 2002) تغییرات نرم‌افزاری به واسطه وصله‌ها و فایل‌های بایگانی شده انتقال پیدا می‌کرد. در سال 2002، پروژه هسته لینوکس شروع به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد. -در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن به صورت رایگان عرضه میشد تغییر پیدا کرد. این اتفاق اخطاری را متوجه مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) کرد که بر اساس تجربه های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در زمینه بزنند. مواردی از اهداف سیستم جدید عبارتند از: +در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن به صورت رایگان عرضه می‌گشت تغییر پیدا کرد. این اتفاق زنگ هشداری برای مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) بود که بر اساس تجربه‌های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در این زمینه بزنند. مواردی از اهداف سیستم جدید عبارت بودند از: * سرعت * طراحی ساده -* پشتیبانی قوی از توسعه غیر خطی (هزاران branch موازی) +* پشتیبانی قوی از توسعه غیر خطی (هزاران انشعاب موازی) * کاملاً پخشی -* قابلیت کنترل بهینه پروژه های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده) +* قابلیت کنترل بهینه پروژه‌های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده) -از زمان تولد Git در سال 2005، این نرم افزار از نظر استفاده آسان و حفظ اهداف اولیه ذکر شده به تکامل و بلوغ رسیده است. Git نرم افزاری سریع، بسیار بهینه در مواجه با پروژه های بزرگ و حاوی سیستم شاخه ای (branching) باورنکردنی برای توسعه غیر خطی است (فصل 3). +از زمان تولد Git در سال 2005، این نرم افزار از نظر استفاده آسان و حفظ اهداف اولیه ذکر شده به تکامل و بلوغ رسیده است. Git نرم افزاری سریع، بسیار بهینه در مواجه با پروژه‌های بزرگ و حاوی سیستم انشعابی باورنکردنی برای توسعه غیر خطی است (فصل 3). ## مقدمات Git ## -خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git اطلاع پیدا کند، آنگاه خواهد توانست آسانتر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce میداند تخلیه کند؛ بدین وسیله از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می شود. با وجود آن که رابط کاربری Git نسبتاً مشابه با دیگر سیستم ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم ها دارد؛ دانستن این تفاوت ها میتواند به فرد در جلوگیری از بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد. +خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git اطلاع پیدا کند، آنگاه خواهد توانست آسان‌تر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce می‌داند تخلیه کند؛ بدین سبب از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می‌شود. با وجود آن‌که رابط کاربری Git نسبتاً مشابه با دیگر سیستم‌ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم‌ها دارد؛ دانستن این تفاوت‌ها می‌تواند به فرد در جلوگیری از بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد. -### Snapshotها، نه تفاوتها ### +### تصاویر لحظه‌ای، نه تفاوتها ### -اصلی ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می شود) دیدگاهی است که Git نسبت به داده های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می کنند. این سیستم ها (CVS، Subversion، Perfoce، Bazaar و غیره) همانطور که در تصویر 1-4 نشان داده شده است، به اطلاعاتی که نگهداری میکنند به شکل مجموعه ای از فایلها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، مینگرند. +اصلی‌ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می‌شود) دیدگاهی است که Git نسبت به داده‌های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم‌ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می‌کنند. این سیستم‌ها (CVS، Subversion، Perfoce، Bazaar و غیره) همان‌طور که در تصویر 1-4 نشان داده شده است، به اطلاعاتی که نگهداری می‌کنند به شکل مجموعه‌ای از فایل‌ها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، می‌نگرند. Insert 18333fig0104.png -تصویر 1-4. دیگر سیستم ها داده ها به شکل تغییرات در ورژن پایه هر فایل ذخیره می کنند. +تصویر 1-4. دیگر سیستم‌ها داده‌ها به شکل تغییرات در نسخه پایه هر فایل ذخیره می‌کنند. -Git از چنین تفکر یا روش ذخیره سازی داده ای پیروی نمی کند. در عوض دیدگاه Git نسبت به داده های خود به شکل snapshotهایی از یک سیستم فایلی کوجک است. هر زمانی که شخص commitای انجام میدهد یا وضعیت پروژه خود را در Git ذخیره می کند، در اصل تصویری از وضعیت تمامی فایل ها در لحظه موردنظر تهیه و ارجاعی به snapshot ایجاد شده ذخیره می شود. برای آنکه این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی کند - تنها ارتباطی (link) به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است. +سGit از چنین تفکر یا روش ذخیره سازی داده‌ای پیروی نمی‌کند. در عوض دیدگاه Git نسبت به داده‌های خود به شکل تصاویر لحظه‌ای از یک سیستم فایلی کوچک است. هر زمانی که شخص commitای انجام می‌دهد یا وضعیت پروژه خود را در Git ذخیره می‌کند، در اصل تصویری از وضعیت تمامی فایل‌ها در لحظه موردنظر تهیه و ارجاعی به تصویر لحظه‌ای ایجاد شده ذخیره می شود. برای آن‌که این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی‌کند - تنها پیوندی به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است. Insert 18333fig0105.png -تصویر 1-5. Git داده ها را به شکل snapshotهایی از پروژه در مرور زمان نگهداری میکند. +تصویر 1-5. Git داده‌ها را به شکل تصاویر لحظه‌ای از پروژه در مرور زمان نگهداری می‌کند. -این شکل نگرش مهمترین اصل تمایز Git با دیگر VCSها است. این امر موجب می شود تا Git تجدیدنظری نسبت به تمامی ابعاد کنترل ورژن داشته باشد، که اکثریت دیگر سیستم ها از نسل های قبل از خود به ارث برده اند. این موضوع باعث شده است تا Git از یک VCS ساده، به سیستم فایلی کوچکی بدل شود که در بالادست آن ابزار قدرتمند باورنکردنی بنا شده است. در فصل 3 بعضی از مزایای چنین دیدگاهی نسبت به داده پوشش داده می شود. +این شکل نگرش مهمترین اصل تمایز Git با دیگر VCSها است. این امر موجب می‌شود تا Git تجدیدنظری نسبت به تمامی ابعاد کنترل نسخه داشته باشد، که اکثریت دیگر سیستم‌ها از نسل‌های قبل از خود به ارث برده‌اند. این موضوع باعث شده است تا Git از یک VCS ساده، به سیستم فایلی کوچکی بدل شود که در بالادست آن ابزار قدرتمند باورنکردنی بنا شده است. در فصل 3 بعضی از مزایای چنین دیدگاهی نسبت به داده، پوشش داده می‌شود. -### تقریباً تمام عملیات به صورت محلی انجام می پذیرد ### +### تقریباً تمام عملیات به صورت محلی انجام می‌پذیرد ### -اکثر عملیاتی که در Git انجام میپذیرد جهت اجرا تنها نیازمند فایلها و منابع محلی هستند - به طور کلی نیازمند هیچگونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده اید که در آن اکثر فعالیت ها دارای افزونگی رکود شبکه ای داشته اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می رسد که اکثر عملیات به صورت لحظه ای و بلادرنگ انجام می پذیرند. +اکثر عملیاتی که در Git انجام می‌پذیرد جهت اجرا تنها نیازمند فایل‌ها و منابع محلی هستند - به‌طور کلی نیازمند هیچ‌گونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده‌اید که در آن اکثر فعالیت‌ها دارای افزونگی رکود شبکه‌ای داشته‌اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده‌اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می‌رسد که اکثر عملیات به صورت لحظه‌ای و بلادرنگ انجام می‌پذیرند. -به عنوان مثال، Git برای نمایش تاریخچه پروژه نیازی جهت مراجعه به سرور برای اخذ تاریخچه و نمایش آن ندارد - Git این عمل را با خواندن مستقیم پایگاه داده محلی انجام میدهد. این بدان معناست که شخص میتوان تاریخچه پروژه را تقریباً بلادرنگ مشاهده کند. اگر نیاز به مشاهده تغییرات بین ورژن فعلی یک فایل با ورژن یک ماه قبل از آن باشد، Git میتواند بجای آنکه از سرور درخواست این عمل را داشته باشد و یا آنکه نسخه قبلی را از سرور خارجی فراخوانی و سپس مقایسه محلی را انجام دهد، این عمل را با نگاهی به نسخه یک ماه قبل فایل و انجام محاسبات محلی تغییرات رخ داده، انجام میدهد. +به عنوان مثال، Git برای نمایش تاریخچه پروژه نیازی جهت مراجعه به سرور برای اخذ تاریخچه و نمایش آن ندارد - Git این عمل را با خواندن مستقیم پایگاه داده محلی انجام می‌دهد. این بدان معناست که شخص می‌تواند تاریخچه پروژه را تقریباً بلادرنگ مشاهده کند. اگر نیاز به مشاهده تغییرات بین نسخه فعلی یک فایل با نسخه یک ماه قبل از آن باشد، Git می‌تواند به‌جای آن‌که از سرور درخواست این عمل را داشته باشد و یا آن‌که نسخه قبلی را از سرور خارجی فراخوانی و سپس مقایسه محلی را انجام دهد، این عمل را با نگاهی به نسخه یک ماه قبل فایل و انجام محاسبات محلی تغییرات رخ داده، انجام می‌دهد. -همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، میتوانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه ای در کار شما حاصل نمی شود. در اکثریت دیگر سیستم ها انجام این موارد غیرممکن یا به سختی انجام می پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دستکاری فایل ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تغییرات بزرگی که میتواند به موجب آن ایجاد شود، شگفت زده شوید. +همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی‌شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، می‌توانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه‌ای در کار شما حاصل نمی‌شود. در اکثریت دیگر سیستم‌ها انجام این موارد غیرممکن یا به سختی انجام می‌پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دست‌کاری فایل‌ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تفاوت‌های بزرگی که می‌تواند به موجب آن ایجاد شود، شگفت زده شوید. ### Git صداقت دارد ### -هرچیزی که بخواهد در Git ذخیره شود، ابتدا checksum آن محاسبه میشود و سپس بوسیله همین checksum ارجاع داده میشود. چنین عملی موجب میشود که در صورت ایجاد کوچکترین تغییری در مححتویات فایل یا پوشه ای، Git از آن آگاهی پیدا کند. این دستورالعمل در Git در پایینترین سطح پیاده سازی شده است و تاییدی بر صحت فلسفه Git دارد. بدین دلیل است که اگر داده ای در حین انتقال از دست برود و یا فایلی مخدوش شود، Git به سرعت از آن اطلاع پیدا میکند. +هرچیزی که بخواهد در Git ذخیره شود، ابتدا checksum آن محاسبه می‌شود و سپس به‌وسیله همین checksum ارجاع داده می‌شود. چنین عملی موجب می‌شود که در صورت ایجاد کوچکترین تغییری در محتویات فایل یا پوشه‌ای، Git از آن آگاهی پیدا کند. این دستورالعمل در Git در پایینترین سطح پیاده‌سازی شده است و تأییدی بر صحت فلسفه Git دارد. بدین دلیل است که اگر داده‌ای در حین انتقال از دست برود و یا فایلی مخدوش شود، Git به سرعت از آن اطلاع پیدا می‌کند. -مکانیزمی که Git برای تولید checksum استفاده میکند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه میگردد. در ادامه یک نمونه از هش SHA-1 آورده شده است: +مکانیزمی که Git برای تولید checksum استفاده می‌کند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه می‌گردد. در ادامه یک نمونه از هش SHA-1 آورده شده است: 24b9da6552252987aa493b52f8696cd6d3b00373 -به علت استفاده زیاد Git از این هش، به کرات در جای جای Git مشاهده گر این هش ها خواهید بود. در واقع، Git از نام فایل برای ذخیره سازی آن استفاده نمیکند بلکه Git از هش تولید شده از محتویات فایل مربوطه برای آدرس دهی آن در پایگاه داده خود بهره میگیرد. +به علت استفاده زیاد Git از این هش، به کرات در جای جای Git مشاهده‌گر این هش‌ها خواهید بود. در واقع، Git از نام فایل برای ذخیره‌سازی آن استفاده نمی‌کند بلکه Git از هش تولید شده از محتویات فایل مربوطه برای آدرس دهی آن در پایگاه داده خود بهره می‌گیرد. ### عموماً Git فقط داده اضافه میکند ### -### Git Generally Only Adds Data ### +هرگاه عملی در Git انجام می‌پذیرد، تقریباً در تمامی موارد Git داده‌ای به داده‌های خود در پایگاه داده اضافه می‌کند. انجام دادن عملی در این سیستم که برگشت‌پذیر نباشد یا باعث حذف داده ای از سیستم شود، بسیار سخت است. مشابه اکثر VCSها، فرد می‌تواند تا قبل از commit هرگونه تغییراتی را انجام دهد؛ ولی به محض commit یک تصویر لحظه‌ای در Git، امکان حذف آن بسیار سخت است، مخصوصاً اگر فرد عادتاً پایگاه داده خود را به مخزن دیگری push کند. -هرگاه عملی در Git انجام میپذیرد، تقریباً در تمامی موارد Git داده ای به داده های خود در پایگاه داده اضافه می کند. انجام دادن عملی در این سیستم که برگشت پذیر نباشد یا باعث حذف داده ای از سیستم شود، بسیار سخت است. مشابه اکثر VCSها، فرد میتواند تا قبل از commit هرگونه تغییراتی را انجام دهد؛ ولی به محض commit یک snapshot در Git، امکان حذف آن بسیار سخت است، مخصوصاً اگر فرد عادتاً پایگاه داده خود را به repository دیگری push کند. - -این قابلیت باعث می شود که استفاده از Git، به عملی فرح بخش تبدیل شود زیرا فرد خواهد توانست بدون در خطر انداختن چیزی دست به هرگونه آزمایشی بزند. برای آشنایی بیشتر با چگونگی عملکرد Git در ذخیره سازی و بازیابی داده هایی که به نظر از دست رفته می باشند، میتوانید به فصل 9 مراجعه کنید. +این قابلیت باعث می‌شود که استفاده از Git، به عملی فرح بخش تبدیل شود زیرا فرد خواهد توانست بدون در خطر انداختن چیزی دست به هرگونه آزمایشی بزند. برای آشنایی بیشتر با چگونگی ذخیره‌سازی و بازیابی داده‌ها در Git که به نظر از دست رفته می‌باشند، می‌توانید به فصل 9 مراجعه کنید. ### سه وضعیت ### -### The Three States ### - -توجه، توجه. اگر میخواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این مطلب را به خاطر بسپارید. فایلها در Git میتوانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای به موجب این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته میباشد که ورژن فعلی آن جهت snapshot بعدی جهت commit نشانه گذاری شده است. +توجه، توجه. اگر می‌خواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این بخش را به دقت مطالعه کنید. فایلها در Git می‌توانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای از این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته است که نسخه فعلی آن در تصویر لحظه‌ای بعدی جهت commit نشانه‌گذاری شده است. -حال میتوان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area. +حال می‌توان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area. Insert 18333fig0106.png تصویر 1-6. پوشه در حال کار، staging area و پوشه Git -در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره میشوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از repository کامپیوتری cloneای گرفته می شود، کپی از این پوشه ایجاد میگردد. +در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره می‌شوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از مخزن کامپیوتری cloneای گرفته می‌شود، کپی از این پوشه ایجاد می‌گردد. -پوشه در حال کار، checkout منفردی از ورژنی از پروژه است. فایلهای این بخش، فایلهایی می باشند که از پایگاه داده فشرده واقع در پوشه Git بیرون کشیده شده و جهت استفاده و ایجاد تغییر بر روی دیسک قرار داده شده اند. +پوشه در حال کار، checkout منفردی از نسخه‌ای از پروژه است. فایل‌های این بخش، فایل‌هایی می‌باشند که از پایگاه داده فشرده واقع در پوشه Git بیرون کشیده شده و جهت استفاده و ایجاد تغییر بر روی دیسک قرار داده شده‌اند. -staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص میکند که چه چیزهایی در commit بعدی قرار میگیرند. معمولاً از این فایل را index مینامند ولی staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است. +staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص می‌کند که چه چیزهایی در commit بعدی قرار می‌گیرند. معمولاً این فایل را index می‌نامند ولی عبارت staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است. روند کاری Git عموماً به صورت ذیل است: -1. ایجاد تغییرات روی فایلهای واقع در پوشه در حال کار. -2. stage کردن فایلها و اضافه کردن snapshotهای فایلها به staging area. -3. commit کردن، که به موجب آن وضعیت فعلی فایلها در staging area تحت یک snapshot به صورت دائمی در پوشه Git ذخیره میگردد. +1. ایجاد تغییرات روی فایل‌های واقع در پوشه در حال کار. +2. stage کردن فایل‌ها و اضافه کردن تصاویر لحظه‌ای فایلها به staging area. +3. commit کردن، که به موجب آن وضعیت فعلی فایل‌ها در staging area تحت یک تصویر لحظه‌ای به صورت دائمی در پوشه Git ذخیره می‌گردد. -اگر ورژنی از یک فایل در پوشه git قرار داشته باشد، commit شده فرض میشود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه ای که check out شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه میتوان از آنها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد. +اگر نسخه‌ای از یک فایل در پوشه git قرار داشته باشد، commit شده فرض می‌شود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه‌ای که checkout شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت‌ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه می‌توان از آن‌ها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد. ## نصب Git ## -حال وقت آن است که کار با Git را شروع کنیم. اول از هر چیز میبایست Git را نصب کرد. روشهای مختلفی برای این کار وجود دارد؛ دو مورد از رایجترین این روشها نصب از طریق سورس یا نصب به واسطه پکیج های موجودی است که برای پلتفرم مورد نظر شما تهیه شده است. +حال وقت آن است که کار با Git را شروع کنیم. اول از هر چیز می‌بایست Git را نصب کرد. روشهای مختلفی برای این کار وجود دارد؛ دو مورد از رایج‌ترین این روش‌ها نصب از طریق سورس یا نصب به واسطه بسته‌های موجودی است که برای پلتفرم موردنظر شما تهیه شده است. ### نصب از طریق سورس ### -اگر امکان نصب از طریق سورس برای شما وجود دارد، این روش مناسبترین روش جهت نصب میباشد، زیرا شما بعد از نصب آخرین ورژن نرم افزار را در اختیار خواهید داشت. در هر نسخه از Git سعی شده است که تا در رابط کاربری بهبودهایی حاصل شود، بنابراین در اختیار داشتن آخرین ورژن بهترین گزینه است البته اگر با کامپایل سورس نرم افزار مشکلی نداشته باشید. همچنین معمولاً مخازن نرم افزاری اکثر توزیعهای لینوکس در بر دارنده پکیجهایی با ورژنهای قدیمی هستند؛ بنابراین در صورتی که شما توسعه دهنده ای به روز هستید یا از backportها استفاده میکنید، نصب از طریق سورس بهترین انتخاب برای شما می باشد. +اگر امکان نصب از طریق سورس برای شما وجود دارد، این روش مناسب‌ترین روش جهت نصب می‌باشد، زیرا شما بعد از نصب آخرین نسخه نرم‌افزار را در اختیار خواهید داشت. در هر نسخه از Git سعی شده است که تا در رابط کاربری بهبودهایی حاصل شود، بنابراین در اختیار داشتن آخرین نسخه بهترین گزینه است البته اگر با کامپایل سورس نرم‌افزار مشکلی نداشته باشید. همچنین معمولاً مخازن نرم افزاری اکثر توزیعهای لینوکس دربردارنده بسته‌هایی با نسخه‌های قدیمی هستند؛ بنابراین در صورتی که شما توسعه دهنده‌ای به روز هستید یا از backportها استفاده می‌کنید، نصب از طریق سورس بهترین انتخاب برای شما است. -برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار میکنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، میتوانید برای نصب این بسته های نیازمندی از دستورهای ذیل استفاده کنید: +برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار می‌کنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، می‌توانید برای نصب این بسته‌های نیازمندی از دستورهای ذیل استفاده کنید: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel @@ -140,41 +136,41 @@ staging area عموماً از یک فایل ساده تشکیل شده است $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev -حال که تمامی نیازمندیها نصب گردید، میتوان آخرین نسخه Git را از وب سایت آن دانلود کرد: +حال که تمامی نیازمندی‌ها نصب گردید، می‌توان آخرین نسخه Git را از وب سایت آن دانلود کرد: http://git-scm.com/download -و آن را کامپایل و نصب کرد: +و آن را کامپایل و نصب نمود: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install -بعد از کامل شدن این مراحل میتوان از خود Git برای دریافت آپدیت های Git استفاده کرد: +بعد از کامل شدن این مراحل می‌توان از خود Git برای دریافت آپدیت‌های Git استفاده کرد: $ git clone git://git.kernel.org/pub/scm/git/git.git ### نصب بر روی لینوکس ### -اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، میتوانید این کار را از طریق ابزار مدیریت بسته های نرم افزاری که همراه توزیع موردنظر شما ارائه می شود انجام دهید. اگر توزیع شما Fedora است، میتوانید از yum استفاده کنید: +اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، می‌توانید این کار را از طریق ابزار مدیریت بسته های نرم‌افزاری که همراه توزیع موردنظر شما ارائه می‌شود انجام دهید. اگر توزیع شما Fedora است، می‌توانید از yum استفاده کنید: $ yum install git-core -یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، میتوانید از apt-get استفاده کنید: +یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، می‌توانید از apt-get استفاده کنید: $ apt-get install git -### نصب بر روی Mac ### +### نصب برروی Mac ### -برای نصب بر روی Mac دو روش آسان وجود دارد. آسانترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7): +برای نصب برروی Mac دو روش آسان وجود دارد. آسان‌ترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7): http://code.google.com/p/git-osx-installer Insert 18333fig0107.png تصویر 1-7. نصاب Git OS X -روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPorts را نصب شده روی سیستم خود دارید، میتوانید Git را با دستور ذیل نصب کنید +روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPortها را نصب شده روی سیستم خود دارید، می‌توانید Git را با دستور ذیل نصب کنید $ sudo port install git-core +svn +doc +bash_completion +gitweb @@ -182,52 +178,52 @@ Insert 18333fig0107.png ### نصب بر روی ویندوز ### -نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسانترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد: +نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسان‌ترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد: http://msysgit.github.com/ بعد از اتمام نصب، هم نسخه خط فرمان (شامل SSH client که در ادامه مشاهده خواهد شد که ابزاری کارآمد است) و هم رابط گرافیکی استاندارد را در اختیار خواهید داشت. -نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix)، تا بتواند دستورات چند خطی پیچیده ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز / کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان میرسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است. +نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix) استفاده کند، تا بتواند دستورات چند خطی پیچیده‌ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز/کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان می‌رسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است. ## تنظیمات شروع به کار Git ## -حال که Git روی سیستم نصب شده است، نیاز به شخصی سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان قابل انجام است. +حال که Git روی سیستم نصب شده است، نیاز به شخصی‌سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان وجود دارد. به همراه Git ابزاری ارائه شده است با نام git config که امکان خواندن و اعمال متغیرهای تنظیماتی که تمامی ابعاد ظاهری و عملیاتی Git را کنترل می‌کند فراهم می‌سازد. -* فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم و مخازن آن‌ها است. اگر به همراه `git config` از آپشن `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد. -* فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از آپشن `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد. +* فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم و مخازن آن‌ها است. اگر به همراه `git config` از گزینه `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد. +* فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از گزینه `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد. * فایل config موجود در پوشه git (`.git/config`) یا هر مخزنی که در حال استفاده از آن می‌باشید: مختص یک مخزن خاص است. مقادیر هر سطح باعث لغو مقادیر سطح قبلی خود می‌شود. بنابراین مقادیر `.git/config` موجب لغو مقادیر `/etc/gitconfig` خواهد شد. -در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به ورژن سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد. +در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به نسخه سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد. -### شناسه ### +### شناسه کاربر ### -اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی کردن دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند. +اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند. $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -مجدداْ یادآوری می‌شود که انجام این عمل در صورت استفاده از آپشن `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی داردُ، می‌تواند با اجرای همان دستورات البته بدون استفاده از آپشن `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد. +مجدداً یادآوری می‌شود که انجام این عمل در صورت استفاده از گزینه `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی دارد، می‌تواند با اجرای همان دستورات البته بدون استفاده از گزینه `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد. -### ویرایشگر ### +### ویرایشگر کاربر ### -حال که شناسه تنظیم شد، میتوان ویرایشگر متنی پیش فرضی را معرفی کرد تا هنگامی که نیاز به نوشتن پیغامی در Git وجود دارد فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، میتوان به صورت ذیل عمل کرد: +حال که شناسه تنظیم شد، می‌توان ویرایشگر متن پیش فرضی را معرفی کرد تا هنگامی که نیاز به درج پیغامی در Git است فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، می‌توان به صورت ذیل عمل کرد: $ git config --global core.editor emacs ### ابزار Diff ### -ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در استفاده از دستور merge استفاده میگردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت: +ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در هنگام اجرای دستور merge استفاده می‌گردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت: $ git config --global merge.tool vimdiff -Git ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff را به عنوان ابزارهایی معتبر جهت merge می شناسد. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد میتوانید به فصل 7 مراجعه کنید. +سGit از ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff جهت merge پشتیبانی می‌کند. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد می‌توانید به فصل 7 مراجعه کنید. ### بررسی تنظیمات ### -برای مشاهده و بررسی تنظیمات، میتوان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می دهد: +برای مشاهده و بررسی تنظیمات، می‌توان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می‌دهد: $ git config --list user.name=Scott Chacon @@ -238,29 +234,29 @@ Git ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdi color.diff=auto ... -احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شود، دلیل این امر آن است که Git کلید مشابهی را از فایلهای مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده باشد. در اینگونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می کند را مورد استفاده قرار میدهد. +احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شوند، دلیل این امر آن است که Git کلید مشابهی را از فایل‌های مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده است. در این‌گونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می‌کند را جهت استفاده به‌کار می‌گیرد. -همچنین برای مشاهده مقدار مورداستفاده یک کلید خاص توسط Git، میتوان از دستور `git config {key}` استفاده کرد: +همچنین برای مشاهده مقدار مورد استفاده یک کلید خاص توسط Git، می‌توان از دستور `git config {key}` استفاده کرد: $ git config user.name Scott Chacon ## دریافت راهنمایی ## -هرگاه در استفاده از Git نیازمند راهنمایی بودید، سه روش برای مشاهده صفحه راهنما (manpage) هرگونه دستوری در Git وجود دارد: +هرگاه در استفاده از Git نیازمند راهنمایی بودید، سه روش برای مشاهده صفحه راهنما هرگونه دستوری در Git وجود دارد: $ git help $ git --help $ man git- -برای مثال، برای مشاهده راهنما manpage دستور config داریم +برای مثال، برای مشاهده صفحه راهنما دستور config داریم $ git help config -این دستورات از آن جهت که میتوان از هر مکانی، حتی در حالت آفلاین، به آنها دسترسی پیدا کرد ابزاری کاربردی میباشند. -اگر manpageها و این کتاب جوابگوی نیاز شما نبودند و نیاز به راهنمایی فردی پیدا کردید، میتوانید به کانالهای `#git` یا `#github` در سرور Freenode IRC (irc.freenode.net) مراجعه کنید. -معمولاً این کانالها مملؤ از افرادی با سطح دانش بالا در زمینه Git هستند که آماده راهنمایی رساندن به شما می باشند. +این دستورات از آن جهت که می‌توان از هر مکانی، حتی در حالت آفلاین، به آن‌ها دسترسی پیدا کرد ابزاری کاربردی می‌باشند. +اگر صفحات راهنما و این کتاب جوابگوی نیاز شما نبودند و نیاز به راهنمایی فردی پیدا کردید، میتوانید به کانالهای `#git` یا `#github` در سرور Freenode IRC (irc.freenode.net) مراجعه کنید. +معمولاً این کانال‌ها مملؤ از افرادی با سطح دانش بالا در زمینه Git هستند که آماده راهنمایی رساندن به شما می‌باشند. ## خلاصه ## -با مطالعه این فصل شما باید درک اولیه ای از این که Git چیست و چه تفاوتی با دیگر CVCSهایی که احتمالاً از آن استفاده میکردید پیدا کرده باشد. همچنین شما باید نسخه آماده به کاری از Git را روی سیستم خود داشته باشید که با شناسه شخصی شما تنظیم شده است. حال زمان یادگیری اصول اولیه Git است. +با مطالعه این فصل شما باید درک اولیه‌ای از این که Git چیست و چه تفاوتی با دیگر CVCSهایی که احتمالاً از آن استفاده می‌کردید دارد پیدا کرده باشد. همچنین شما باید نسخه آماده به کاری از Git را روی سیستم خود داشته باشید که شناسه شخصی شما برروی آن تنظیم شده است. حال زمان یادگیری اصول اولیه Git است. diff --git a/fa/NOTES.en-fa.md b/fa/NOTES.en-fa.md new file mode 100644 index 000000000..aef4537e1 --- /dev/null +++ b/fa/NOTES.en-fa.md @@ -0,0 +1,143 @@ +نکاتی در رابطه با ترجمه کتاب +====================== + +همان‌طور که اطلاع دارید کلمات تخصصی اکثر رشته‌ها در زبان فارسی مورد کم لطفی واقع شده‌اند و معمولاً معادل فارسی آن‌ها به صورت رسمی و مدون تعیین نشده‌اند. باالاجبار مترجمان جهت ترجمه این لغات به رای و نظر شخصی خود رجوع می‌کنند. بدین دلیل است که ممکن است برای یک عبارت تخصصی معادل‌های گوناگونی در کتب مختلف یافت شود. + +از آن جهت که ترجمه این کتاب به صورت گروهی انجام می‌پذیرد، برای جلوگیری از سردرگمی خواننده بعد از ترجمه کامل اثر سعی شده است تا لغت‌نامه کوچکی از کلمات کلیدی که در این کتاب به‌کار رفته شده است تهیه شود تا تمامی افرادی که در این کار گروهی شرکت می‌کنند از یک الگوی یکسان در ترجمه پیروی کنند. + +لذا از تمامی افرادی که در ترجمه این کتاب شرکت می‌کنند خواهشمندیم تا از این الگو پیروی کنند و همچنین اگر خود به کلمه کلیدی جدیدی برخورد کردند که در این لیست وجود ندارد، آن را به لیست اضافه کرده و حتی اگر جایگزین مناسبتری برای کلمه خاصی در نظر داشتند با هماهنگی دیگر مترجمان آن را جایگزین کنند. + +توجه: کلماتی که جایگزین مناسبی هنوز برای آن‌ها یافت نشده است، در قسمت معادل فارسی،همان عبارت انگلیسی کلمه آورده شده است. + + +archive +------- + + بایگانی + +branch +------ + + انشعاب + +checkout +-------- + + checkout + +checksum +-------- + + checksum + +clone +----- + + clone + + +commit +------ + + commit + +customize +--------- + + شخصی‌سازی + +diff +---- + + diff + +link +---- + + پیوند + +manpage +------- + + صفحه راهنما + +merge +----- + + merge + +metadata +-------- + + metadata + +option +------ + + گزینه + +package +------- + + بسته + + +patch +----- + +وصله + +platform +-------- + + platform + +push +---- + + push + +remote repository +----------------- + + مخزن خارجی + +repository +---------- + + مخزن + +revision +-------- + + نسخه + +snapshot +-------- + + تصویر لحظه‌ای + +staging area +------------ + + staging area + +state +----- + +وضعیت + +version +------- + +نسخه + +workflow +-------- + +جریان کاری + +working directory +----------------- + +پوشه در حال کار \ No newline at end of file diff --git a/fa/README.md b/fa/README.md index 936a0ec43..95dab6b2c 100644 --- a/fa/README.md +++ b/fa/README.md @@ -1,7 +1,7 @@ # تلاش برای ترجمه فارسی # - ## لیست افراد حاضر در این پروژه ## +Oxtay +mxamin -اگر شما هم بر روی این ترجمه کار میکنید یا در نظر دارید که این کار را شروع کنید لطفآ به ما اطلاع دهید تا از دوباره کاری پرهیز شود . - +اگر شما هم برروی این ترجمه کار می‌کنید یا در نظر دارید که این کار را شروع کنید لطفآ به ما اطلاع دهید تا از دوباره کاری پرهیز شود. \ No newline at end of file From 0f0aa507274fb17ef7eb79b400fd3de848087f4c Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 1 Aug 2014 16:11:09 +0200 Subject: [PATCH 129/291] [cs] Synchronizing with [en] by structure and markup --- cs/01-introduction/01-chapter1.markdown | 6 +- cs/02-git-basics/01-chapter2.markdown | 411 +++++++++++------- cs/03-git-branching/01-chapter3.markdown | 108 ++--- cs/04-git-server/01-chapter4.markdown | 50 ++- cs/05-distributed-git/01-chapter5.markdown | 33 +- cs/06-git-tools/01-chapter6.markdown | 40 +- cs/07-customizing-git/01-chapter7.markdown | 47 +- cs/08-git-and-other-scms/01-chapter8.markdown | 2 +- 8 files changed, 421 insertions(+), 276 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 10bebf266..007fa3a9b 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -6,7 +6,7 @@ Tato kapitola vám ve stručnosti představí systém Git. Začneme od samého z Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času, a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Příklady verzovaných souborů jsou v této knize ilustrovány na zdrojovém kódu softwaru, avšak ve skutečnosti lze verzování provádět téměř se všemi typy souborů v počítači. -Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z angl. Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem. +Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z anglického Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem. ### Lokální systémy správy verzí ### @@ -178,7 +178,7 @@ Není nutné přidávat všechny doplňky, ale pokud budete někdy používat Gi Instalace systému Git v OS Windows je velice nenáročná. Postup instalace projektu msysGit patří k těm nejjednodušším. Ze stránky GitHub stáhněte instalační soubor exe a spusťte ho: - http://msysgit.github.com/ + http://msysgit.github.io Po dokončení instalace budete mít k dispozici jak verzi pro příkazový řádek (včetně SSH klienta, který se vám bude hodit později), tak standardní grafické uživatelské rozhraní. @@ -188,7 +188,7 @@ Poznámka k používání pod Windows: Git byste měli používat z dodaného sh Nyní, když máte Git nainstalovaný, můžete provést některá uživatelská nastavení systému. Nastavení stačí provést pouze jednou — zůstanou zachována i po případných aktualizacích. -Nastavení konfiguračních proměnných systému, které ovlivňují jak vzhled systému Git, tak ostatní aspekty jeho práce, umožňuje příkaz git config. Tyto proměnné mohou být uloženy na třech různých místech: +Nastavení konfiguračních proměnných systému, které ovlivňují jak vzhled systému Git, tak ostatní aspekty jeho práce, umožňuje příkaz `git config`. Tyto proměnné mohou být uloženy na třech různých místech: * Soubor `/etc/gitconfig` obsahuje údaje o všech uživatelích systému a jejich repozitářích. Pokud příkazu `git config` zadáme parametr `--system` bude číst a zapisovat jen do tohoto souboru. * Soubor `~/.gitconfig` je vázán na uživatelský účet. Čtení a zápis do tohoto souboru zajistíte zadáním parametru `--global`. diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index cae0cc93e..7720fdead 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -54,7 +54,7 @@ Obrázek 2-1. Cyklus stavů vašich souborů Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz `git status`. Spustíte-li tento příkaz bezprostředně po klonování, objeví se zhruba následující: $ git status - # On branch master + On branch master nothing to commit, working directory clean To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole. @@ -63,11 +63,12 @@ To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adr $ vim README $ git status - # On branch master - # Untracked files: - # (use "git add ..." to include in what will be committed) - # - # README + On branch master + Untracked files: + (use "git add ..." to include in what will be committed) + + README + nothing added to commit but untracked files present (use "git add" to track) Vidíte, že nový soubor `README` není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, obecně to znamená, že Git ví o souboru, který nebyl v předchozím snímku (v předchozí revizi), a nezařadí ho ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README zahrnout, a proto spusťme jeho sledování. @@ -81,12 +82,12 @@ K zahájení sledování nových souborů se používá příkaz `git add`. Chce Když nyní znovu provedete příkaz k výpisu stavů (git status), uvidíte, že je nyní soubor `README` sledován a připraven k zapsání: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + Můžeme říci, že je připraven k zapsání, protože je uveden v části „Changes to be committed“, tedy „Změny k zapsání“. Pokud v tomto okamžiku zapíšete revizi, v historickém snímku bude verze souboru z okamžiku, kdy jste spustili příkaz `git add`. Možná si vzpomínáte, že když jste před časem spustili příkaz `git init`, provedli jste potom příkaz `git add (soubory)`. Příkaz jste zadávali kvůli zahájení sledování souborů ve vašem adresáři. Příkaz `git add` je doplněn uvedením cesty buď k souboru, nebo k adresáři. Pokud se jedná o adresář, příkaz přidá rekurzivně všechny soubory v tomto adresáři. @@ -95,58 +96,60 @@ Můžeme říci, že je připraven k zapsání, protože je uveden v části „ Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem `benchmarks.rb` a poté znovu spustíte příkaz `status`, zobrazí se výpis podobného obsahu: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (Změněno, ale neaktualizováno). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání. Chcete-li ho připravit, spusťte příkaz `git add` (jedná se o univerzální příkaz – používá se k zahájení sledování nových souborů, k připravení souborů a k dalším operacím, jako např. k označení souborů, které kolidovaly při sloučení, za vyřešené). Spusťme nyní příkaz `git add` k připravení souboru `benchmarks.rb` k zapsání a následně znovu příkaz `git status`: $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete ještě před zapsáním revize provést v souboru `benchmarks.rb`. Soubor znovu otevřete a provedete změnu. Soubor je připraven k zapsání. Spusťme však ještě jednou příkaz `git status`: $ vim benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor přesně tak, jak je. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru: $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + ### Ignorované soubory ### @@ -180,6 +183,10 @@ Tady je další příklad souboru `.gitignore`: build/ # ignoruj doc/notes.txt, ale nikoli doc/server/arch.txt doc/*.txt + # ignoruj všechny .txt soubory v adresáři doc/ + doc/**/*.txt + +Část masky `**/` je v Gitu dostupná od verze 1.8.2. ### Zobrazení připravených a nepřipravených změn ### @@ -188,17 +195,18 @@ Je-li pro vaše potřeby příkaz `git status` příliš neurčitý – chcete p Řekněme, že znovu upravíte a připravíte soubor `README` a poté bez připravení upravíte soubor `benchmarks.rb`. Po spuštění příkazu `status` se zobrazí zhruba toto: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Chcete-li vidět, co jste změnili, avšak ještě nepřipravili k zapsání, zadejte příkaz `git diff` bez dalších parametrů: @@ -243,16 +251,18 @@ V dalším příkladu ukážeme situaci, kdy jste připravili soubor `benchmarks $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status - # On branch master - # - # Changes to be committed: - # - # modified: benchmarks.rb - # - # Changes not staged for commit: - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Příkaz `git diff` nyní můžete použít k zobrazení změn, které dosud nejsou připraveny: @@ -301,10 +311,9 @@ Editor zobrazí následující text (tento příklad je z editoru Vim): # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # # new file: README # modified: benchmarks.rb + # ~ ~ ~ @@ -315,8 +324,8 @@ Jak vidíte, výchozí zpráva k revizi (commit message) obsahuje zakomentovaný Zprávu k revizi můžete rovněž napsat do řádku k příkazu `commit`. Jako zprávu ji označíte tak, že před ni vložíte příznak `-m`: $ git commit -m "Story 182: Fix benchmarks for speed" - [master]: created 463dc4f: "Fix benchmarks for speed" - 2 files changed, 3 insertions(+), 0 deletions(-) + [master 463dc4f] Story 182: Fix benchmarks for speed + 2 files changed, 3 insertions(+) create mode 100644 README Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (hlavní, `master`), jaký kontrolní součet SHA-1 revize dostala (`463dc4f`), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize. @@ -328,15 +337,17 @@ Nezapomeňte, že revize zaznamená snímek projektu, jak je obsažen v oblasti Přestože může být oblast připravených změn opravdu užitečným nástrojem pro přesné vytváření revizí, je někdy při daném pracovním postupu zbytečným mezikrokem. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu `git commit` parametr `-a`, Git do revize automaticky zahrne každý soubor, který je sledován. Zcela tak odpadá potřeba zadávat příkaz `git add`: $ git status - # On branch master - # - # Changes not staged for commit: - # - # modified: benchmarks.rb - # + On branch master + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + + no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks - 1 files changed, 5 insertions(+), 0 deletions(-) + 1 files changed, 5 insertions(+) Tímto způsobem není nutné provádět před zapsáním revize příkaz `git add` pro soubor `benchmarks.rb`. @@ -348,26 +359,26 @@ Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve vý $ rm grit.gemspec $ git status - # On branch master - # - # Changes not staged for commit: - # (use "git add/rm ..." to update what will be committed) - # - # deleted: grit.gemspec - # + On branch master + Changes not staged for commit: + (use "git add/rm ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + deleted: grit.gemspec + + no changes added to commit (use "git add" and/or "git commit -a") Pokud nyní provedete příkaz `git rm`, bude k zapsání připraveno odstranění souboru: $ git rm grit.gemspec rm 'grit.gemspec' $ git status - # On branch master - # - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # deleted: grit.gemspec - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + deleted: grit.gemspec + Po příštím zapsání revize soubor zmizí a nebude sledován. Pokud už jste soubor upravili a přidali do indexu, musíte odstranění provést pomocí parametru `-f`. Jedná se o bezpečnostní funkci, jež má zabránit nechtěnému odstranění dat, která ještě nebyla nahrána do snímku, a nemohou proto být ze systému Git obnovena. @@ -395,22 +406,20 @@ Může se zdát zvláštní, že Git přesto používá příkaz `mv`. Chcete-li a vše funguje na výbornou. A skutečně, pokud takový příkaz provedete a podíváte se na stav souboru, uvidíte, že ho Git považuje za přejmenovaný (renamed): - $ git mv README.txt README + $ git mv README README.txt $ git status - # On branch master - # Your branch is ahead of 'origin/master' by 1 commit. - # - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # renamed: README.txt -> README - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + renamed: README -> README.txt + Výsledek je však stejný, jako byste provedli následující: - $ mv README.txt README - $ git rm README.txt - $ git add README + $ mv README README.txt + $ git rm README + $ git add README.txt Git implicitně zjistí, že se jedná o přejmenování, a proto nehraje roli, zda přejmenujete soubor tímto způsobem, nebo pomocí příkazu `mv`. Jediným skutečným rozdílem je, že `mv` je jediný příkaz, zatímco u druhého způsobu potřebujete příkazy tři — příkaz `mv` je pouze zjednodušením. Důležitější je, že můžete použít jakýkoli způsob přejmenování a příkaz add/rm provést později, před zapsáním revize. @@ -460,11 +469,13 @@ Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly diff index a874b73..8f94139 100644 --- a/Rakefile +++ b/Rakefile - @@ -5,7 +5,7 @@ require 'rake/gempackagetask' + @@ -5,5 +5,5 @@ require 'rake/gempackagetask' spec = Gem::Specification.new do |s| + s.name = "simplegit" - s.version = "0.1.0" + s.version = "0.1.1" s.author = "Scott Chacon" + s.email = "schacon@gee-mail.com commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon @@ -488,6 +499,27 @@ Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly diff \ No newline at end of file Tento parametr zobrazí tytéž informace, ale za každým záznamem následuje informace o rozdílech. Tato funkce je velmi užitečná při kontrole kódu nebo k rychlému zjištění, co bylo obsahem série revizí, které přidal váš spolupracovník. + +Někdy se změny kontrolují snadněji na úrovni slov než na úrovni řádků. Git nabízí parametr `--word-diff`, který můžeme přidat za příkaz `git log -p`. Místo obvyklé detekce rozdílů po řádcích získáme rozdíly po slovech. Zjišťování rozdílů po slovech je u zdrojového kódu celkem k ničemu, ale pokud porovnáváme velké textové soubory -- jako například knihy nebo vaši disertační práci --, pak se tato možnost hodí. Tady máme příklad: + + $ git log -U1 --word-diff + commit ca82a6dff817ec66f44342007202690a93763949 + Author: Scott Chacon + Date: Mon Mar 17 21:52:11 2008 -0700 + + changed the version number + + diff --git a/Rakefile b/Rakefile + index a874b73..8f94139 100644 + --- a/Rakefile + +++ b/Rakefile + @@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s| + s.name = "simplegit" + s.version = [-"0.1.0"-]{+"0.1.1"+} + s.author = "Scott Chacon" + +Jak vidíte, výstup neobsahuje žádné přidané a odstraněné řádky, jak tomu bývá u běžného zobrazení rozdílů (diff). Místo toho se změny zobrazují uvnitř textu. Přidaná slova jsou uzavřena mezi značkami `{+ +}` a odstraněná jsou uzavřena v `[- -]`. Možná byste také rádi zredukovali obvyklé třířádkové okolí změny na pouhý jeden řádek, protože chcete znát okolí slova a ne okolí řádku. Můžeme toho dosáhnout zadáním parametru `-U1`, jako ve výše uvedeném příkladu. + Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujících parametrů. Pokud například chcete zobrazit některé stručné statistiky pro každou revizi, použijte parametr `--stat`: $ git log --stat @@ -498,7 +530,7 @@ Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujíc changed the version number Rakefile | 2 +- - 1 files changed, 1 insertions(+), 1 deletions(-) + 1 file changed, 1 insertion(+), 1 deletion(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon @@ -507,7 +539,7 @@ Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujíc removed unnecessary test code lib/simplegit.rb | 5 ----- - 1 files changed, 0 insertions(+), 5 deletions(-) + 1 file changed, 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon @@ -518,7 +550,7 @@ Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujíc README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ lib/simplegit.rb | 25 +++++++++++++++++++++++++ - 3 files changed, 54 insertions(+), 0 deletions(-) + 3 files changed, 54 insertions(+) Jak vidíte, parametr `--stat` vypíše pod každým záznamem revize seznam změněných souborů, kolik souborů bylo změněno (changed) a kolik řádků bylo v těchto souborech vloženo (insertions) a smazáno (deletions). Zároveň vloží na konec výpisu shrnutí těchto informací. Další opravdu užitečnou možností je parametr `--pretty`. Tento parametr změní výstup logu na jiný než výchozí formát. K dispozici máte několik přednastavených možností. Parametr `oneline` vypíše všechny revize na jednom řádku. Tuto možnost oceníte při velkém množství revizí. Dále se nabízejí parametry `short`, `full` a `fuller` (zkrácený, plný, úplný). Zobrazují výstup přibližně ve stejném formátu, avšak s více či méně podrobnými informacemi: @@ -537,6 +569,11 @@ Nejzajímavějším parametrem je pak `format`, který umožňuje definovat vlas Tabulka 2-1 uvádí některé užitečné parametry, které format akceptuje. + + Parametr Popis výstupu %H Otisk (hash) revize %h Zkrácený otisk revize @@ -572,8 +609,14 @@ Parametry `oneline` a `format` jsou zvlášť užitečné ve spojení s další To je jen několik základních parametrů k formátování výstupu pro příkaz `git log`, celkově jich je mnohem více. Tabulka 2-2 uvádí parametry, které jsme už zmínili, a některé další běžné parametry formátování, které mohou být užitečné. Pravý sloupec popisuje, jak který parametr změní výstup `log`u. + + Parametr Popis -p Zobrazí záplatu vytvořenou s každou revizí. + --word-diff Zobrazí záplatu ve tvaru rozdílu po slovech. --stat Zobrazí statistiku pro změněné soubory v každé revizi. --shortstat Zobrazí pouze řádek změněno/vloženo/smazáno z příkazu --stat. --name-only Za informacemi o revizi zobrazí seznam změněných souborů. @@ -581,7 +624,7 @@ To je jen několik základních parametrů k formátování výstupu pro příka --abbrev-commit Zobrazí pouze prvních několik znaků kontrolního součtu SHA-1 místo všech 40. --relative-date Zobrazí datum v relativním formátu (např. "2 weeks ago", tj. před 2 týdny) místo formátu s úplným datem. --graph Zobrazí vedle výstupu logu ASCII graf k historii větve a slučování. - --pretty Zobrazí revize v alternativním formátu. Parametry příkazu jsou oneline, short, full, fuller a format (lze zadat vlastní formát). + --pretty Zobrazí revize v alternativním formátu. Parametry příkazu jsou oneline, short, full, fuller a format (ve kterém uvedete svůj vlastní formát). --oneline Užitečná zkratka pro `--pretty=oneline --abbrev-commit`. ### Omezení výstupu logu ### @@ -594,12 +637,19 @@ Velmi užitečné jsou naproti tomu časově omezující parametry, jako `--sinc Tento příkaz pracuje s velkým množstvím formátů. Můžete zadat konkrétní datum („2008-01-15“) nebo relativní datum, např. „2 years 1 day 3 minutes ago“ (před 2 roky, 1 dnem a 3 minutami). -Z výpisu rovněž můžete filtrovat pouze revize, které odpovídají určitým kritériím. Parametr `--author` umožňuje filtrovat výpisy podle konkrétního autora, pomocí parametru `--grep` můžete ve zprávách k revizím vyhledávat klíčová slova. Chcete-li hledat současný výskyt parametrů author i grep, musíte přidat výraz `--all-match`, jinak se bude hledat kterýkoli z nich. +Z výpisu rovněž můžete filtrovat pouze revize, které odpovídají určitým kritériím. Parametr `--author` umožňuje filtrovat výpisy podle konkrétního autora, pomocí parametru `--grep` můžete ve zprávách k revizím vyhledávat klíčová slova. (Všimněte si, že pokud použijete současně parametry author a grep, bude příkaz vyhledávat záznamy splňující obojí.) + +Pokud chcete zadat více parametrů grep, musíte přidat výraz `--all-match`, jinak se bude hledat kterýkoli z nich. Posledním opravdu užitečným parametrem, který lze přidat k příkazu `git log` , je zadání cesty. Jestliže zadáte název adresáře nebo souboru, výstup logu tím omezíte na revize, které provedly změnu v těchto souborech. Cesta je vždy posledním parametrem a většinou jí předcházejí dvě pomlčky (`--`) , jimiž je oddělena od ostatních parametrů. Tabulka 2-3 uvádí pro přehlednost zmíněné parametry a několik málo dalších. Tabulka 2.2 + + Parametr Popis -(n) Zobrazí pouze posledních n revizí. --since, --after Omezí výpis na revize provedené po zadaném datu. @@ -607,10 +657,55 @@ Tabulka 2-3 uvádí pro přehlednost zmíněné parametry a několik málo dalš --author Zobrazí pouze revize, v nichž autor odpovídá zadanému řetězci. --committer Zobrazí pouze revize, v nichž autor revize odpovídá zadanému řetězci. -Pokud chcete například zjistit, které revize upravující testovací soubory byly v historii zdrojového kódu Git zapsány v říjnu 2008 Juniem Hamanem a nebyly sloučením, můžete zadat následující příkaz: - $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ - --before="2008-11-01" --no-merges -- t/ +### Omezení výstupního logu na určité datum nebo čas ### + +Pokud chcete zjistit, které revize (commit) v repozitáři se zdrojovým kódem Git (git://git.kernel.org/pub/scm/git/git.git) mají datum zápisu (CommitDate) 2014-04-29 -- relativně k vašemu lokálnímu časovému pásmu (takovému, jaké je nastaveno na vašem počítači), použijte příkaz + + $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ + --pretty=fuller + +Protože se výstup bude lišit podle časového pásma v místě spuštění, doporučuje se v argumentech `--after` a `--before` vždy používat absolutní čas (například ve formátu ISO 8601, který obsahuje i informaci o časovém pásmu). Činíme tak proto, aby každý, kdo stejný příkaz spustí, obdržel stejné, opakovatelné výsledky. + +Pokud chceme získat zápisy z určitého časového okamžiku (například z 29. dubna 2013 v 17:07:22 středoevropského času), můžeme použít příkaz + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller + + commit de7c201a10857e5d424dbd8db880a6f24ba250f9 + Author: Ramkumar Ramachandra + AuthorDate: Mon Apr 29 18:19:37 2013 +0530 + Commit: Junio C Hamano + CommitDate: Mon Apr 29 08:07:22 2013 -0700 + + git-completion.bash: lexical sorting for diff.statGraphWidth + + df44483a (diff --stat: add config option to limit graph width, + 2012-03-01) added the option diff.startGraphWidth to the list of + configuration variables in git-completion.bash, but failed to notice + that the list is sorted alphabetically. Move it to its rightful place + in the list. + + Signed-off-by: Ramkumar Ramachandra + Signed-off-by: Junio C Hamano + +Výše uvedené časy (`AuthorDate`, `CommitDate`) se zobrazují v základním tvaru (`--date=default`), který zobrazuje informaci o časovém pásmu autora nebo přispěvatele. + +K dalším užitečným formátům patří `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (sekundy od počátku (epoch; 1970-01-01 UTC)), `--date=local` (časy ve vašem lokálním časovém pásmu) a také `--date=relative` (jako například "2 hours ago", tj. před dvěma hodinami). + +Pokud použijete příkaz `git log` bez určení času, uvažuje se čas odpovídající okamžiku spuštění na vašem počítači (používá stejný posun vůči UTC). + +Pokud například na vašem počítači spustíte `git log` v 09:00 a vaše časové pásmo je vůči greenwichskému času posunut o tři hodiny vpřed, pak se výsledek následujících dvou příkazů shoduje: + + $ git log --after=2008-06-01 --before=2008-07-01 + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" + +A poslední příklad. Pokud chcete zjistit, které revize upravující testovací soubory ve zdrojovém kódu Git zapsal Junio Hamano v říjnu 2008 (relativě k časové zóně New Yorku) a které přitom nebyly sloučením (merge), můžete zadat následující příkaz: + + $ git log --pretty="%h - %s" --author=gitster \ + --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi @@ -618,7 +713,7 @@ Pokud chcete například zjistit, které revize upravující testovací soubory 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -Z téměř 20 000 revizí v historii zdrojového kódu Git zobrazí tento příkaz 6 záznamů, které odpovídají zadaným kritériím. +Z více než 36 tisíc revizí v historii zdrojového kódu Git zobrazí tento příkaz 6 záznamů, které odpovídají zadaným kritériím. ### Grafické uživatelské rozhraní pro procházení historie ### @@ -657,31 +752,32 @@ Následující dvě části popisují, jak vrátit změny provedené v oblasti p $ git add . $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + modified: benchmarks.rb + Přímo pod nadpisem „Changes to be committed“ (Změny k zapsání) se říká: pro návrat z oblasti připravených změn použijte příkaz `git reset HEAD ...` Budeme se tedy řídit touto radou a vrátíme soubor `benchmarks.rb` z oblasti připravených změn: $ git reset HEAD benchmarks.rb - benchmarks.rb: locally modified + Unstaged changes after reset: + M benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Příkaz je sice trochu zvláštní, ale funguje. Soubor `benchmarks.rb` má stav „změněn“, ale už se nenachází v oblasti připravených změn. @@ -689,23 +785,23 @@ Příkaz je sice trochu zvláštní, ale funguje. Soubor `benchmarks.rb` má sta A co když zjistíte, že nechcete zachovat změny, které jste provedli v souboru `benchmarks.rb`? Jak je můžete snadno zrušit a vrátit soubor zpět do podoby při poslední revizi (nebo při prvním klonování nebo v jakémkoli okamžiku, kdy jste ho zaznamenali v pracovním adresáři)? Příkaz `git status` vám naštěstí řekne, co dělat. U posledního příkladu vypadá oblast připravených změn takto: - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # modified: benchmarks.rb - # + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Výpis vám sděluje, jak zahodit změny (discard changes), které jste provedli (přinejmenším tak činí novější verze systému Git, od verze 1.6.1; pokud máte starší verzi, doporučujeme ji aktualizovat, čímž získáte některé z těchto vylepšených funkcí). Uděláme, co nám výpis radí: $ git checkout -- benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + Jak vidíte, změny byly zahozeny. Všimněte si také, že se jedná o nebezpečný příkaz. Veškeré změny, které jste v souboru provedli, jsou ztraceny, soubor jste právě překopírovali jiným souborem. Nikdy tento příkaz nepoužívejte, pokud si nejste zcela jisti, že už daný soubor nebudete potřebovat. Pokud potřebujete pouze odstranit soubor z cesty, podívejte se na odkládání a větvení v následující kapitole. Tyto postupy většinou bývají vhodnější. @@ -721,12 +817,12 @@ Při manipulaci se vzdálenými repozitáři je nutné vědět, jak lze přidat Chcete-li zjistit, jaké vzdálené servery máte nakonfigurovány, můžete použít příkaz `git remote`. Systém vypíše zkrácené názvy všech identifikátorů vzdálených repozitářů, jež máte zadány. Pokud byl váš repozitář vytvořen klonováním, měli byste vidět přinejmenším server origin. Origin je výchozí název, který Git dává serveru, z nějž jste repozitář klonovali. $ git clone git://github.com/schacon/ticgit.git - Initialized empty Git repository in /private/tmp/ticgit/.git/ - remote: Counting objects: 595, done. - remote: Compressing objects: 100% (269/269), done. - remote: Total 595 (delta 255), reused 589 (delta 253) - Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done. - Resolving deltas: 100% (255/255), done. + Cloning into 'ticgit'... + remote: Reusing existing pack: 1857, done. + remote: Total 1857 (delta 0), reused 0 (delta 0) + Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done. + Resolving deltas: 100% (772/772), done. + Checking connectivity... done. $ cd ticgit $ git remote origin @@ -897,6 +993,7 @@ Informace značky se zobrazí spolu s revizí, kterou značka označuje, po zad Date: Mon Feb 9 14:45:11 2009 -0800 my version 1.4 + commit 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon @@ -1062,9 +1159,9 @@ Než ukončíme tuto kapitolu o základech práce se systémem Git, přidáme je ### Automatické dokončování ### -Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript automatického dokončování. Stáhněte si zdrojový kód Git a podívejte se do adresáře `contrib/completion`. Měli byste tam najít soubor s názvem `git-completion.bash`. Zkopírujte tento soubor do svého domovského adresáře a přidejte ho do souboru `.bashrc`: +Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript pro automatické dokončování. Stáhněte si zdrojový kód Git https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Nakopírujte tento soubor do vašeho domovského adresáře a do souboru `.bashrc` přidejte: - source ~/.git-completion.bash + source ~/git-completion.bash Chcete-li nastavit Git tak, aby měl automaticky dokončování pro shell Bash pro všechny uživatele, zkopírujte tento skript do adresáře `/opt/local/etc/bash_completion.d` v systémech Mac nebo do adresáře `/etc/bash_completion.d/` v systémech Linux. Toto je adresář skriptů, z nějž Bash automaticky načítá pro shellové dokončování. diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 808bcb086..c71858d38 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -41,7 +41,7 @@ Tento příkaz vytvoří nový ukazatel na stejné revizi, na níž se právě n Insert 18333fig0304.png Obrázek 3-4. Několik větví ukazujících do historie dat revizí -Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem git branch jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5). +Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem `git branch` jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5). Insert 18333fig0305.png Obrázek 3-5. Soubor HEAD ukazující na větev, na níž se nacházíte. @@ -117,7 +117,7 @@ Obrázek 3-10. Krátká a jednoduchá historie revizí Rozhodli jste se, že budete pracovat na chybě č. 53, ať už vaše společnost používá jakýkoli systém sledování chyb. Přesněji řečeno, Git není začleněn do žádného konkrétního systému sledování chyb, ale protože je chyba č. 53 významná a chcete na ní pracovat, vytvoříte si pro ni novou větev. Abyste vytvořili novou větev a rovnou na ni přepnuli, můžete spustit příkaz `git checkout` s přepínačem `-b`: $ git checkout -b iss53 - Switched to a new branch "iss53" + Switched to a new branch 'iss53' Tímto způsobem jste spojili dva příkazy: @@ -142,18 +142,18 @@ V tomto okamžiku vám zavolají, že se na webových stránkách vyskytl probl Než tak učiníte, zkontrolujte, zda nemáte v pracovním adresáři nebo v oblasti připravených změn nezapsané změny, které kolidují s větví, jejíž checkout provádíte. V takovém případě by vám Git přepnutí větví nedovolil. Při přepínání větví je ideální, pokud máte čistý pracovní stav. Existují způsoby, jak toho docílit (jmenovitě odložení a doplnění revize), těm se však budeme věnovat až později. Pro tuto chvíli jste zapsali všechny provedené změny a můžete přepnout zpět na hlavní větev. $ git checkout master - Switched to branch "master" + Switched to branch 'master' V tomto okamžiku vypadá váš pracovní adresář přesně tak, jak vypadal, než jste začali pracovat na chybě č. 53, a vy se nyní můžete soustředit na rychlou opravu. Na paměti byste však stále měli mít následující: Git vždy vrátí pracovní adresář do stejného stavu, jak vypadal snímek revize, na niž ukazuje větev, jejíž checkout nyní provádíte. Automaticky budou přidány, odstraněny a upraveny soubory tak, aby byla vaše pracovní kopie totožná se stavem větve v okamžiku, kdy jste na ni zapsali poslední revizi. Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme pracovat, dokud nebude oprava hotová (viz obrázek 3-13): $ git checkout -b hotfix - Switched to a new branch "hotfix" + Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'fixed the broken email address' - [hotfix]: created 3a0874c: "fixed the broken email address" - 1 files changed, 0 insertions(+), 1 deletions(-) + [hotfix 3a0874c] fixed the broken email address + 1 files changed, 1 deletion(-) Insert 18333fig0313.png Obrázek 3-13. Větev „hotfix“ začleněná zpět v místě hlavní větve @@ -163,9 +163,9 @@ Můžete provádět testování, ujistit se, že hotfix splňuje všechny požad $ git checkout master $ git merge hotfix Updating f42c576..3a0874c - Fast forward - README | 1 - - 1 files changed, 0 insertions(+), 1 deletions(-) + Fast-forward + README | 1 - + 1 file changed, 1 deletion(-) Při sloučení jste si možná všimli spojení „Fast forward“ (rychle vpřed). Jelikož revize, na niž ukazovala větev, do níž jste začleňovali, byla v přímé linii s revizí, na níž jste se nacházeli, Git přesunul ukazatel vpřed. Jinými slovy: pokud se pokoušíte sloučit jednu revizi s revizí druhou, k níž lze dospět následováním historie první revize, Git proces zjednoduší a přesune ukazatel vpřed, protože neexistuje žádná rozdílná práce, kterou by bylo třeba sloučit. Tomuto postupu se říká „rychle vpřed“. @@ -177,16 +177,16 @@ Obrázek 3-14. Hlavní větev ukazuje po sloučení na stejné místo jako věte Poté, co jste dokončili práci na bezodkladné opravě, můžete přepnout zpět na práci, jíž jste se věnovali před telefonátem. Nejprve však smažete větev `hotfix`, kterou teď už nebudete potřebovat – větev `master` ukazuje na totéž místo. Větev smažete přidáním parametru `-d` k příkazu `git branch`: $ git branch -d hotfix - Deleted branch hotfix (3a0874c). + Deleted branch hotfix (was 3a0874c). Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na chybě č. 53 (viz obrázek 3-15): $ git checkout iss53 - Switched to branch "iss53" + Switched to branch 'iss53' $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' - [iss53]: created ad82d7a: "finished the new footer [issue 53]" - 1 files changed, 1 insertions(+), 0 deletions(-) + [iss53 ad82d7a] finished the new footer [issue 53] + 1 file changed, 1 insertion(+) Insert 18333fig0315.png Obrázek 3-15. Větev iss53 může nezávisle postupovat vpřed. @@ -199,9 +199,10 @@ Předpokládejme, že jste dokončili práci na chybě č. 53 a nyní byste ji r $ git checkout master $ git merge iss53 - Merge made by recursive. - README | 1 + - 1 files changed, 1 insertions(+), 0 deletions(-) + Auto-merging README + Merge made by the 'recursive' strategy. + README | 1 + + 1 file changed, 1 insertion(+) Toto už se trochu liší od začlenění větve `hotfix`, které jste prováděli před chvílí. V tomto případě se historie vývoje od určitého bodu v minulosti rozbíhala. Vzhledem k tomu, že revize na větvi, na níž se nacházíte, není přímým předkem větve, kterou chcete začlenit, Git bude muset podniknout určité kroky. Git v tomto případě provádí jednoduché třícestné sloučení: vychází ze dvou snímků, na které ukazují větve, a jejich společného předka. Obrázek 3-16 označuje ony tři snímky, které Git v tomto případě použije ke sloučení. @@ -230,25 +231,27 @@ Může se stát, že sloučení neproběhne bez problémů. Pokud jste tutéž Git nepřistoupil k automatickému vytvoření nové revize sloučením. Prozatím pozastavil celý proces do doby, než konflikt vyřešíte. Chcete-li kdykoli po konfliktu zjistit, které soubory zůstaly nesloučeny, spusťte příkaz `git status`: - [master*]$ git status - index.html: needs merge - # On branch master - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # unmerged: index.html - # + $ git status + On branch master + You have unmerged paths. + (fix conflicts and run "git commit") + + Unmerged paths: + (use "git add ..." to mark resolution) + + both modified: index.html + + no changes added to commit (use "git add" and/or "git commit -a") Vše, co při sloučení kolidovalo a nebylo vyřešeno, je označeno jako „unmerged“ (nesloučeno). Git přidává ke kolidujícím souborům standardní poznámky o řešení konfliktů (conflict-resolution markers), takže je můžete ručně otevřít a konflikty vyřešit. Jedna část vašeho souboru bude vypadat zhruba takto: - <<<<<<< HEAD:index.html + <<<<<<< HEAD ======= - >>>>>>> iss53:index.html + >>>>>>> iss53 To znamená, že verze ve větvi s ukazatelem HEAD (vaše hlavní větev – v té jste se nacházeli při provádění příkazu merge) je uvedena v horní části tohoto bloku (všechno nad oddělovačem `=======`), verze obsažená ve větvi `iss53` je vše, co se nachází v dolní části. Chcete-li vzniklý konflikt vyřešit, musíte buď vybrat jednu z obou stran, nebo konflikt sloučit sami. Tento konflikt můžete vyřešit například nahrazením celého bloku tímto textem: @@ -260,12 +263,17 @@ Toto řešení obsahuje trochu z každé části a zcela jsem odstranil řádky Chcete-li k vyřešení problémů použít grafický nástroj, můžete spustit příkaz `git mergetool`, kterým otevřete příslušný vizuální nástroj pro slučování, a ten vás všemi konflikty provede: $ git mergetool - merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff - Merging the files: index.html + + This message is displayed because 'merge.tool' is not configured. + See 'git mergetool --tool-help' or 'git help config' for more details. + 'git mergetool' will now attempt to use one of the following tools: + opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge + Merging: + index.html Normal merge conflict for 'index.html': - {local}: modified - {remote}: modified + {local}: modified file + {remote}: modified file Hit return to start merge resolution tool (opendiff): Chcete-li použít jiný než výchozí nástroj pro slučování (Git mi v tomto případě vybral `opendiff`, protože jsem příkaz zadal v systému Mac), všechny podporované nástroje jsou uvedeny na začátku výstupu v části „merge tool candidates“ (možné nástroje pro slučování). Zadejte název nástroje, který chcete použít. V kapitole 7 probereme, jak lze tuto výchozí hodnotu pro vaše prostředí změnit. @@ -275,12 +283,12 @@ Až nástroj pro slučování zavřete, Git se vás zeptá, zda sloučení prob Ještě jednou můžete spustit příkaz `git status`, abyste si ověřili, že byly všechny konflikty vyřešeny: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: index.html - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: index.html + Pokud jste s výsledkem spokojeni a ujistili jste se, že všechny kolidující soubory jsou připraveny k zapsání, můžete zadat příkaz `git commit` a dokončit revizi sloučením. Zpráva revize má v takovém případě přednastavenu tuto podobu: @@ -289,9 +297,9 @@ Pokud jste s výsledkem spokojeni a ujistili jste se, že všechny kolidující Conflicts: index.html # - # It looks like you may be committing a MERGE. + # It looks like you may be committing a merge. # If this is not correct, please remove the file - # .git/MERGE_HEAD + # .git/MERGE_HEAD # and try again. # @@ -331,7 +339,7 @@ Chcete-li zobrazit větve, které obsahují dosud nezačleněnou práci, spusťt Nyní se zobrazila jiná větev. Jelikož obsahuje práci, která ještě nebyla začleněna, bude pokus o její smazání příkazem `git branch -d` neúspěšný: $ git branch -d testing - error: The branch 'testing' is not an ancestor of your current HEAD. + error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. Pokud chcete větev skutečně odstranit a zahodit práci, kterou obsahuje, můžete si to vynutit parametrem `-D` (jak napovídá užitečná zpráva pod řádkem s chybovým hlášením). @@ -344,7 +352,7 @@ Teď, když jste absolvovali základní seznámení s větvemi a jejich slučov Vzhledem k tomu, že Git používá jednoduché třícestné slučování, je velmi snadné začleňovat jednu větev do druhé i několikrát v rámci dlouhého časového intervalu. Můžete tak mít několik větví, které jsou stále otevřené a které používáte pro různé fáze vývojového cyklu. Pravidelně můžete začleňovat práci z jedné větve do ostatních. -Mnoho vývojářů systému Git používá pracovní postup, při němž je tato metoda zcela ideální. Ve větvi `master` mají pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Používá se k natahování tematických větví (těch dočasných, jako byla vaše větev `iss53`) ve chvíli, kdy je k tomu vše připraveno a nehrozí, že práce neprojde testy nebo bude způsobovat chyby. +Mnoho vývojářů systému Git používá pracovní postup, kdy mají ve větvi `master` pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Ta se pak používá se k začleňování do tematických větví (těch dočasných, jako byla vaše větev `iss53`) ve chvíli, kdy je k tomu vše připraveno a nehrozí, že práce neprojde testy nebo bude způsobovat chyby. Ve skutečnosti hovoříme o ukazatelích pohybujících se vzhůru po linii revizí, které zapisujete. Stabilní větve leží v linii historie revizí níže a nové, neověřené větve se nacházejí nad nimi (viz obrázek 3-18). @@ -381,7 +389,7 @@ Při tom všem, co nyní děláte, je důležité mít na paměti, že všechny Vzdálené větve jsou reference (tj. odkazy) na stav větví ve vašich vzdálených repozitářích. Jsou to lokální větve, které nemůžete přesouvat. Přesouvají se automaticky při síťové komunikaci. Vzdálené větve slouží jako záložky, které vám připomínají, kde byly větve ve vzdálených repozitářích, když jste se k nim naposledy připojili. -Vzdálené větve mají podobu `(vzdálený repozitář)/(větev)`. Například: Chcete-li zjistit, jak vypadala větev `master` na vašem vzdáleném serveru `origin`, když jste s ní naposledy komunikovali, budete hledat větev `origin/master`. Pokud pracujete s kolegou na stejném problému a on odešle na server větev s názvem `iss53`, může se stát, že i vy máte jednu z lokálních větví pojmenovanou jako `iss53`. Větev na serveru však ukazuje na revizi označenou jako `origin/iss53`. +Vzdálené větve mají podobu `(vzdálený repozitář)/(větev)`. Pokud například chcete zjistit, jak vypadala větev `master` na vašem vzdáleném serveru `origin`, když jste s ní naposledy komunikovali, budete hledat větev `origin/master`. Pokud pracujete s kolegou na stejném problému a on odešle na server větev s názvem `iss53`, může se stát, že i vy máte jednu z lokálních větví pojmenovanou jako `iss53`. Větev na serveru však ukazuje na revizi označenou jako `origin/iss53`. Mohlo by to být trochu matoucí, takže si uveďme příklad. Řekněme, že máte v síti server Git označený `git.ourcompany.com`. Pokud provedete klonování z tohoto serveru, Git ho automaticky pojmenuje `origin`, stáhne z něj všechna data, vytvoří ukazatel, který bude označovat jeho větev `master`, a lokálně ji pojmenuje `origin/master`. Tuto větev nemůžete přesouvat. Git vám rovněž vytvoří vaši vlastní větev `master`, která bude začínat ve stejném místě jako větev `master` serveru `origin`. Máte tak definován výchozí bod pro svoji práci (viz obrázek 3-22). @@ -396,7 +404,7 @@ Obrázek 3-23. Pokud pracujete lokálně a někdo jiný odešle svou práci na v K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je „origin“ (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24). Insert 18333fig0324.png -Obrázek 3-24. Příkaz git fetch aktualizuje vaše reference na vzdálený server. +Obrázek 3-24. Příkaz `git fetch` aktualizuje vaše reference na vzdálený server. Abychom si mohli ukázat, jak se pracuje s několika vzdálenými servery a jak vypadají vzdálené větve takových vzdálených projektů, předpokládejme, že máte ještě další interní server Git, který při vývoji používá pouze jeden z vašich sprint teamů. Tento server se nachází na `git.team1.ourcompany.com`. Můžete ho přidat jako novou vzdálenou referenci k projektu, na němž právě pracujete – spusťte příkaz `git remote add` (viz kapitola 2). Pojmenujte tento vzdálený server jako `teamone`, což bude zkrácený název pro celou URL adresu (viz obrázek 3-25). @@ -439,8 +447,8 @@ Tady je důležité upozornit, že pokud vyzvedáváte data a stáhnete s nimi i Chcete-li začlenit tato data do své aktuální pracovní větve, spusťte příkaz `git merge origin/serverfix`. Chcete-li mít vlastní větev `serverfix`, na níž budete pracovat, můžete ji ze vzdálené větve vyvázat: $ git checkout -b serverfix origin/serverfix - Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. - Switched to a new branch "serverfix" + Branch serverfix set up to track remote branch serverfix from origin. + Switched to a new branch 'serverfix' Tímto způsobem získáte lokální větev, na níž můžete pracovat a která začíná na pozici `origin/serverfix`. @@ -451,16 +459,16 @@ Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte tzv. Sl Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`: $ git checkout --track origin/serverfix - Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. - Switched to a new branch "serverfix" + Branch serverfix set up to track remote branch serverfix from origin. + Switched to a new branch 'serverfix' Chcete-li nastavit lokální větev s jiným názvem, než má vzdálená větev, můžete jednoduše použít první variantu s odlišným názvem lokální větve: $ git checkout -b sf origin/serverfix - Branch sf set up to track remote branch refs/remotes/origin/serverfix. - Switched to a new branch "sf" + Branch sf set up to track remote branch serverfix from origin. + Switched to a new branch 'sf' -Vaše lokální větev „sf“ bude nyní automaticky stahovat data ze vzdálené větve origin/serverfix a bude do ní i odesílat. +Vaše lokální větev `sf` bude nyní automaticky stahovat data ze vzdálené větve `origin/serverfix` a bude do ní i odesílat. ### Mazání vzdálených větví ### diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 890884cc4..93147edbe 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -117,9 +117,10 @@ Pro úvodní nastavení serveru Git je třeba exportovat existující repozitá Chcete-li naklonovat stávající repozitář, a vytvořit tak nový a holý, zadejte příkaz clone s parametrem `--bare`. Je zvykem, že adresáře s holým repozitářem končí na `.git`, například: $ git clone --bare my_project my_project.git - Initialized empty Git repository in /opt/projects/my_project.git/ + Cloning into bare repository 'my_project.git'... + done. -Výstup tohoto příkazu je trochu nejasný. Protože příkaz `clone` znamená v podstatě `git init` a následně `git fetch`, vidíme z části `git init`, která vytvoří prázdný adresář, nějaký výstup. Následný přenos objektu neposkytuje žádný výstup, přesto však proběhl. V adresáři `my_project.git` byste nyní měli mít kopii dat z adresáře Git. +V adresáři `my_project.git` byste nyní měli mít kopii dat z adresáře Git. Je to přibližně stejné, jako byste zadali například: @@ -283,12 +284,17 @@ Nejprve ze všeho budete muset zapnout zásuvný modul: $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update -Jestliže používáte verzi systému Git starší než 1.6, nebude příkaz `mv` nutný. Git začal pojmenovávat příklady zásuvných modulů příponou „.sample“ teprve nedávno. - Jaká je funkce zásuvného modulu `post-update`? V principu vypadá asi takto: $ cat .git/hooks/post-update #!/bin/sh + # + # An example hook script to prepare a packed repository for use over + # dumb transports. + # + # To enable this hook, rename this file to "post-update". + # + exec git-update-server-info Znamená to, že až budete odesílat data na server prostřednictvím SSH, Git spustí tento příkaz a aktualizuje soubory vyžadované pro přístup přes HTTP. @@ -404,7 +410,7 @@ Nyní máte vše hotovo. Pokud jste nastavení provedli správně, můžete vyzk $ ssh git@gitserver PTY allocation request failed on channel 0 - fatal: unrecognized command 'gitosis-serve schacon@quaternion' + ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. Connection to gitserver closed. To znamená, že vás Gitosis sice rozpoznal, ale nedovolí vám přístup, protože se nepokoušíte zadat žádný příkaz Git. Provedeme tedy skutečný příkaz systému Git a naklonujeme řídicí repozitář Gitosis: @@ -428,28 +434,28 @@ Pokud se podíváte na soubor `gitosis.conf`, měl by udávat pouze informace o [gitosis] [group gitosis-admin] - writable = gitosis-admin members = scott + writable = gitosis-admin Tato informace znamená, že uživatel 'scott' – ten, jehož veřejným klíčem jste inicializovali Gitosis – je jediným uživatelem, který má přístup k projektu `gitosis-admin`. Nyní přidáme nový projekt. Přidáte novou část s názvem `mobile`, která bude obsahovat seznam vývojářů vašeho mobilního týmu a projektů, k nimž tito vývojáři potřebují přístup. Protože je v tuto chvíli jediným uživatelem v systému 'scott', přidáte ho jako jediného člena a vytvoříte pro něj nový projekt s názvem `iphone_project`: [group mobile] - writable = iphone_project members = scott + writable = iphone_project Pokaždé, když provedete změny v projektu `gitosis-admin`, musíte tyto změny zapsat a odeslat je zpět na server, aby nabyly účinnosti: $ git commit -am 'add iphone_project and mobile group' - [master]: created 8962da8: "changed name" - 1 files changed, 4 insertions(+), 0 deletions(-) - $ git push + [master 8962da8] add iphone_project and mobile group + 1 file changed, 4 insertions(+) + $ git push origin master Counting objects: 5, done. - Compressing objects: 100% (2/2), done. - Writing objects: 100% (3/3), 272 bytes, done. - Total 3 (delta 1), reused 0 (delta 0) - To git@gitserver:/opt/git/gitosis-admin.git + Compressing objects: 100% (3/3), done. + Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:gitosis-admin.git fb27aec..8962da8 master -> master Do nového projektu `iphone_project` teď můžete odeslat svá první data: přidejte do lokální verze projektu svůj server jako vzdálený repozitář a odešlete změny. Od této chvíle už nebudete muset ručně vytvářet holé repozitáře pro nové projekty na serveru. Gitosis je vytvoří automaticky, jakmile zjistí první odeslání dat: @@ -458,7 +464,7 @@ Do nového projektu `iphone_project` teď můžete odeslat svá první data: př $ git push origin master Initialized empty Git repository in /opt/git/iphone_project.git/ Counting objects: 3, done. - Writing objects: 100% (3/3), 230 bytes, done. + Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gitserver:iphone_project.git * [new branch] master -> master @@ -474,20 +480,20 @@ Na tomto projektu chcete spolupracovat s přáteli, a proto budete muset znovu p Nyní je můžete všechny přidat do týmu 'mobile', čímž získají oprávnění pro čtení i pro zápis k `iphone_project`: [group mobile] - writable = iphone_project members = scott john josie jessica + writable = iphone_project Až tuto změnu zapíšete a odešlete, všichni čtyři uživatelé budou moci z tohoto projektu číst a zapisovat do něj. Gitosis nabízí také jednoduchou správu přístupu. Pokud chcete, aby měl John u projektu pouze oprávnění pro čtení, můžete provést následující: [group mobile] - writable = iphone_project members = scott josie jessica + writable = iphone_project [group mobile_ro] - readonly = iphone_project members = john + readonly = iphone_project John nyní může naklonovat projekt a stahovat jeho aktualizace, ale Gitosis mu neumožní, aby odesílal data zpět do projektu. Takových skupin můžete vytvořit libovolně mnoho. Každá může obsahovat různé uživatele a projekty. Jako jednoho ze členů skupiny můžete zadat také celou jinou skupinu (použijete pro ni předponu `@`). Všichni její členové se tím automaticky zdědí. @@ -495,12 +501,12 @@ John nyní může naklonovat projekt a stahovat jeho aktualizace, ale Gitosis mu members = scott josie jessica [group mobile] - writable = iphone_project members = @mobile_committers + writable = iphone_project [group mobile_2] - writable = another_iphone_project members = @mobile_committers john + writable = another_iphone_project Máte-li jakékoli problémy, může vám pomoci zadání `loglevel=DEBUG` do části `[gitosis]`. Pokud jste odesláním nesprávné konfigurace ztratili oprávnění k odesílání dat, můžete ručně opravit soubor na serveru v adresáři `/home/git/.gitosis.conf` – jedná se o soubor, z nějž Gitosis načítá data. Po odeslání dat do projektu bude soubor `gitosis.conf`, který jste právě odeslali, umístěn do tohoto adresáře. Pokud soubor ručně upravíte, zůstane v této podobě až do dalšího úspěšného odeslání do projektu `gitosis-admin`. @@ -521,11 +527,11 @@ Instalace Gitolite je velmi jednoduchá a to i když nebudete číst obsáhlou d Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý. Přístup se realizuje přes ssh, takže každá serverová userid je potenciálně „hostitelem gitolite“ (gitolite host). Teď si popíšeme nejjednodušší způsob instalace. V dokumentaci naleznete další metody. -Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný ssh klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `VaseJmeno.pub`. Potom proveďte následující příkazy: +Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný SSH klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `.pub` (v příkladech budeme používat `scott.pub`). Potom proveďte následující příkazy: $ git clone git://github.com/sitaramc/gitolite $ gitolite/install -ln - # předpokládá existenci $HOME/bin a uvedení tohoto adresáře v $PATH + # assumes $HOME/bin exists and is in your $PATH $ gitolite setup -pk $HOME/scott.pub Poslední příkaz vytvoří na serveru nový gitovský repozitář nazvaný `gitolite-admin`. diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown index e046c1f2d..89140cfe2 100644 --- a/cs/05-distributed-git/01-chapter5.markdown +++ b/cs/05-distributed-git/01-chapter5.markdown @@ -174,7 +174,7 @@ John má referenci ke změnám, které odeslala Jessica, ale než bude moci sám Sloučení probíhá hladce, Johnova historie revizí teď vypadá jako na obrázku 5-5. Insert 18333fig0505.png -Obrázek 5-5. Johnův repozitář po začlenění větve origin/master +Obrázek 5-5. Johnův repozitář po začlenění větve `origin/master` John nyní může otestovat svůj kód, aby se ujistil, že stále pracuje správně, a pak může odeslat svou novou sloučenou práci na server: @@ -215,7 +215,7 @@ Jessica považuje svou tematickou větev za dokončenou, ale chce vědět, do č removed invalid default value -Jessica nyní může začlenit tematickou větev do své hlavní větve, tamtéž začlenit i Johnovu práci (`origin/master`) do své větve `master` a vše odeslat zpět na server. Nejprve se přepne zpět na svou hlavní větev, aby do ní mohla vše integrovat: +Jessica nyní může začlenit tematickou větev do své větve `master`, začlenit (merge) i Johnovu práci (`origin/master`) do své větve `master` a vše odeslat zpět na server. Nejprve se přepne zpět na svou větev `master`, aby do ní mohla vše integrovat: $ git checkout master Switched to branch "master" @@ -255,7 +255,7 @@ Všichni vývojáři zapsali několik revizí a úspěšně začlenili práci os Insert 18333fig0510.png Obrázek 5-10. Historie Jessicy po odeslání všech změn zpět na server -Toto je jeden z nejjednodušších pracovních postupů. Po určitou dobu pracujete, obvykle na nějaké tematické větvi, a když je připravena k integraci, začleníte ji do hlavní větve. Chcete-li tuto práci sdílet, začleníte ji do své hlavní větve. Poté vyzvednete a začleníte větev `origin/master`, jestliže se změnila. Nakonec odešlete všechna data do větve `master` na serveru. Obecná posloupnost kroků je naznačena na obrázku 5-11. +Toto je jeden z nejjednodušších pracovních postupů. Po určitou dobu pracujete, obvykle na nějaké tematické větvi, a když je připravena k integraci, začleníte ji do své větve `master`. Chcete-li tuto práci sdílet, začleníte ji do své větve `master`. Poté vyzvednete (fetch) a začleníte (merge) větev `origin/master`, jestliže se změnila. Nakonec odešlete všechna data do větve `master` na serveru. Obecná posloupnost kroků je naznačena na obrázku 5-11. Insert 18333fig0511.png Obrázek 5-11. Obecná posloupnost kroků u jednoduchého pracovního postupu s více vývojáři v systému Git @@ -532,7 +532,26 @@ Nejprve je třeba nastavit sekci „imap“ v souboru `~/.gitconfig`. Každou ho sslverify = false Pokud váš server IMAP nepoužívá SSL, dva poslední řádky zřejmě nebudou vůbec třeba a hodnota hostitele bude `imap://`, a nikoli `imaps://`. -Až toto nastavení dokončíte, můžete použít příkaz `git send-email`, jímž umístíte sérii patchů do složky Koncepty (Drafts) zadaného serveru IMAP: +Až toto nastavení dokončíte, můžete použít příkaz `git imap-send`, jímž umístíte sérii záplat (patch) do složky Koncepty (Drafts) zadaného serveru IMAP: + + $ cat *.patch |git imap-send + Resolving imap.gmail.com... ok + Connecting to [74.125.142.109]:993... ok + Logging in... + sending 2 messages + 100% (2/2) done + +V tomto okamžiku byste měli být schopni přejít do složky Drafts, změnit pole To na mailing list, do kterého záplatu posíláte, případně pole CC na správce nebo na osobu zodpovědnou za tuto část, a odeslat. + +Záplaty můžete odesílat i přes SMTP server. Stejně jako v předchozím případu můžete nastavit sérií příkazů `git config` každou hodnotu zvlášť, nebo je můžete vložit ručně do sekce sendemail souboru `~/.gitconfig`: + + [sendemail] + smtpencryption = tls + smtpserver = smtp.gmail.com + smtpuser = user@gmail.com + smtpserverport = 587 + +Jakmile je to hotové, můžete záplaty odeslat příkazem `git send-email`: $ git send-email *.patch 0001-added-limit-to-log-function.patch @@ -559,8 +578,6 @@ Git poté vytvoří log s určitými informacemi, který bude pro každou zápla Result: OK -V tomto okamžiku můžete přejít do své složky Koncepty, změnit pole Komu na adresáty z poštovní konference, jimž chcete záplatu odeslat, případně přidat kopii na správce nebo osobu odpovědnou za tuto část a e-mail odeslat. - ### Shrnutí ### V této části jsme popsali několik obvyklých pracovních postupů při přispívání do velmi odlišných typů projektů Git, s nimiž se můžete setkat. Představili jsme k nim také nové nástroje, které vám mohou v těchto procesech pomoci. V další části se na projekty podíváme z té druhé strany – ukážeme, jak může vypadat jejich správa. Dozvíte se, jak být benevolentním diktátorem nebo integračním manažerem. @@ -594,7 +611,7 @@ Pokud dostanete záplatu od někoho, kdo ji vygeneroval příkazem `git diff` ne Tím změníte soubory ve svém pracovním adresáři. Je to téměř stejné, jako byste k aplikaci záplaty použili příkaz `patch -p1`. Tento postup je však přísnější a nepřijímá tolik přibližných shod jako příkaz patch. Poradí si také s přidanými, odstraněnými a přejmenovanými soubory, jsou-li popsány ve formátu `git diff`, což příkaz `patch` nedělá. A konečně příkaz `git apply` pracuje na principu „aplikuj vše, nebo zruš vše“. Buď jsou tedy aplikovány všechny soubory, nebo žádný. Naproti tomu příkaz `patch` může aplikovat soubory záplaty jen částečně a zanechat váš pracovní adresář v neurčitém stavu. Příkaz `git apply` je tedy celkově víc paranoidní než příkaz `patch`. Tímto příkazem ostatně ani nezapíšete revizi, po jeho spuštění budete muset připravit a zapsat provedené změny ručně. -Příkaz git apply můžete použít také ke kontrole, zda bude záplata aplikována čistě. V takovém případě použijte na patch příkaz `git apply --check`: +Příkaz `git apply` můžete použít také ke kontrole, zda bude záplata aplikována čistě. V takovém případě použijte na patch příkaz `git apply --check`: $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 @@ -615,7 +632,7 @@ K aplikaci patche vygenerovaného příkazem `format-patch` použijte příkaz ` Limit log functionality to the first 20 -Toto je začátek výstupu příkazu format-patch, s nímž jsme se setkali v předchozí části. Zároveň je to také platný e-mailový formát mbox. Jestliže vám přispěvatel řádně poslal záplatu e-mailem pomocí příkazu git send-email a vy záplatu stáhnete do formátu mbox, můžete na soubor mbox použít příkaz git am, který začne aplikovat všechny záplaty, které najde. Jestliže spustíte poštovního klienta, který dokáže uložit několik e-mailů ve formátu mbox, můžete do jednoho souboru uložit celou sérii záplat a příkazem git am je pak aplikovat všechny najednou. +Toto je začátek výstupu příkazu format-patch, s nímž jsme se setkali v předchozí části. Zároveň je to také platný e-mailový formát mbox. Jestliže vám přispěvatel řádně poslal záplatu e-mailem pomocí příkazu `git send-email` a vy záplatu stáhnete do formátu mbox, můžete na soubor mbox použít příkaz `git am`, který začne aplikovat všechny záplaty, které najde. Jestliže spustíte poštovního klienta, který dokáže uložit několik e-mailů ve formátu mbox, můžete do jednoho souboru uložit celou sérii záplat a příkazem `git am` je pak aplikovat všechny najednou. Pokud však někdo nahrál soubor záplaty vygenerovaný příkazem `format-patch` do tiketového nebo podobného systému, můžete soubor uložit lokálně a poté na tento uložený soubor použít příkaz `git am`. Tímto způsobem záplatu aplikujete: diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index 8b4349abf..987a56217 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -82,13 +82,13 @@ Jednou z věcí, které probíhají na pozadí systému Git, zatímco vy pracuje Svůj reflog si můžete nechat zobrazit příkazem `git reflog`: $ git reflog - 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated - d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. - 1c002dd... HEAD@{2}: commit: added some blame and merge stuff - 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD - 95df984... HEAD@{4}: commit: # This is a combination of two commits. - 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD - 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD + 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated + d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. + 1c002dd HEAD@{2}: commit: added some blame and merge stuff + 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD + 95df984 HEAD@{4}: commit: # This is a combination of two commits. + 1c36188 HEAD@{5}: rebase -i (squash): updating HEAD + 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD Pokaždé, když je z nějakého důvodu aktualizován vrchol větve, Git tuto informaci uloží v dočasné historii reflog. Pomocí těchto dat lze rovněž specifikovat starší revize. Chcete-li zobrazit pátou poslední hodnotu ukazatele HEAD svého repozitáře, použijte referenci `@{n}` z výstupu reflog: @@ -463,8 +463,8 @@ Nyní můžete bez obav přepnout větve a pracovat na jiném úkolu, vaše změ $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log V tomto případě byly už dříve provedeny dva další odklady, a máte tak k dispozici tři různé odklady. Naposledy odložené soubory můžete znovu aplikovat příkazem, který byl uveden už v nápovědě ve výstupu původního příkazu stash: `git stash apply`. Chcete-li aplikovat některý ze starších odkladů, můžete ho určit na základě jeho označení, např. `git stash apply stash@{2}`. Pokud u příkazu neoznačíte konkrétní odklad, Git se automaticky pokusí aplikovat ten nejnovější: @@ -498,8 +498,8 @@ Parametr apply se pouze pokusí aplikovat odloženou práci, ta zůstává ulož $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) @@ -583,12 +583,19 @@ Spuštěním tohoto příkazu otevřete textový editor se seznamem revizí zhru # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out Tady bychom chtěli upozornit, že revize jsou uvedeny v opačném pořadí, než jste zvyklí v případě příkazu `log`. Po spuštění příkazu `log` by se zobrazilo následující: @@ -607,6 +614,10 @@ Skript je třeba upravit tak, aby zastavil na revizi, v níž chcete provést zm Po uložení změn a zavření editoru vás Git vrátí zpět na poslední revizi v seznamu a zobrazí vám příkazový řádek s touto zprávou: + + $ git rebase -i HEAD~3 Stopped at 7482e0d... updated the gemspec to hopefully work better You can amend the commit now, with @@ -649,12 +660,19 @@ Další možností, jak lze využít interaktivního nástroje přeskládání, # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out Zadáte-li místo pick nebo edit instrukci pro komprimaci squash, Git aplikuje změnu na tomto řádku a změnu těsně před ní a zároveň sloučí dohromady obě zprávy k revizím. Chcete-li tedy vytvořit jedinou revizi z těchto tří revizí, bude skript vypadat takto: diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown index 5491834de..463bffe5f 100644 --- a/cs/07-customizing-git/01-chapter7.markdown +++ b/cs/07-customizing-git/01-chapter7.markdown @@ -130,7 +130,7 @@ Chcete-li sami nastavit jednotlivé barvy, mají všechny tyto parametry navíc $ git config --global color.diff.meta "blue black bold" -U barev lze zadávat tyto hodnoty: normal (normální), black (černá), red (červená), green (zelená), yellow (žlutá), blue (modrá), magenta (purpurová), cyan (azurová) nebo white (bílá). Pokud chcete použít atribut, jakým bylo v předchozím příkladu například tučné písmo, můžete vybírat mezi bold (tučné), dim (tlumené), ul (podtržené), blink (blikající) a reverse (obrácené). +U barev lze zadávat tyto hodnoty: `normal` (normální), `black` (černá), `red` (červená), `green` (zelená), `yellow` (žlutá), `blue` (modrá), `magenta` (purpurová), `cyan` (azurová) nebo `white` (bílá). Pokud chcete použít atribut, jakým bylo v předchozím příkladu například tučné písmo, můžete vybírat mezi `bold` (tučné), `dim` (tlumené), `ul` (podtržené), `blink` (blikající) a `reverse` (obrácené). Chcete-li použít dílčí nastavení, podrobnější informace naleznete na manuálové stránce `git config`. @@ -301,17 +301,21 @@ Chcete-li systému Git zadat, aby nakládal se všemi soubory `pbxproj` jako s b *.pbxproj -crlf -diff -Až v projektu spustíte příkaz git show nebo git diff, Git se nebude pokoušet konvertovat nebo opravovat chyby CRLF ani vypočítat ani zobrazit rozdíly v tomto souboru pomocí nástroje diff. V systému Git verze 1.6 můžete také použít existující makro s významem `-crlf -diff`: +Až v projektu spustíte příkaz `git show` nebo `git diff`, Git se nebude pokoušet konvertovat nebo opravovat chyby CRLF ani vypočítat ani zobrazit rozdíly v tomto souboru pomocí nástroje diff. Můžete také použít zabudované makro `binary` s významem `-crlf -diff`: *.pbxproj binary #### Nástroj diff pro binární soubory #### -Ve verzi 1.6 systému Git můžete použít funkci atributů Git k efektivnímu zpracování binárních souborů nástrojem diff. Systému Git přitom sdělíte, jak má konvertovat binární data do textového formátu, který lze zpracovávat běžným nástrojem diff. +V systému Git můžete zadáním vhodných parametrů efektivně porovnávat binární soubory. Dosáhnete toho tím, že systému Git sdělíte, jak má konvertovat binární data do textového formátu, který lze zpracovávat běžným algoritmem pro zjišťování rozdílů (diff). Ale otázkou je, jak byste měli konverzi *binárních* dat na text provést? Nejlepší by bylo, kdybyste našli nějaký nástroj, který vám binární tvar na textový převede. Naneštěstí existuje jen velmi málo binárních formátů, které lze převést na lidsky čitelný text. (Představte si, jak byste na text převáděli zvuková data.) Pokud takový případ nastal a nejste schopni textovou reprezentaci obsahu souboru získat, lze často poměrně snadno získat lidsky čitelný popis obsahu, metadata. Metadata vám sice neposkytnou plnou reprezentaci obsahu souboru, ale v každém případě je to lepší než nic. + +Oba popsané přístupy k získání použitelných informací o rozdílech si ukážeme na některých běžně používaných binárních formátech. + +Poznámka: Existují různé druhy binárních formátů, které obsahují text, a pro které se dají obtížně najít použitelné konvertory. V takovém případě můžete zkusit získat z vašeho souboru texty programem `strings`. Některé z těchto souborů ale mohou používat kódování UTF-16 nebo jiné kódování a `strings` v nich nic rozumného nenajde. Je to případ od případu. Nicméně program `strings` je k dispozici na většině operačních systémů Mac a Linux, takže může jít o dobrou první volbu při pokusech s celou řadou binárních souborů. #### Soubory MS Word #### -Protože se jedná o opravdu šikovnou a nepříliš známou funkci, uvedu několik příkladů. Tuto metodu budete využívat především k řešení jednoho z nejpalčivějších problémů, s nímž se lidstvo potýká: verzování dokumentů Word. Je všeobecně známo, že Word je nejpříšejnější editor na světě, přesto ho však – bůhví proč – všichni používají. Chcete-li verzovat dokumenty Word, můžete je uložit do repozitáře Git a všechny hned zapsat do revize. K čemu to však bude? Spustíte-li příkaz `git diff` normálně, zobrazí se zhruba toto: +Tuto metodu budete využívat především k řešení jednoho z nejpalčivějších problémů, s nímž se lidstvo potýká: verzování dokumentů Word. Je všeobecně známo, že Word je nejpříšernější editor na světě, přesto ho však – bůhví proč – všichni používají. Chcete-li verzovat dokumenty Word, můžete je uložit do repozitáře Git a všechny hned zapsat do revize. K čemu to však bude? Spustíte-li příkaz `git diff` normálně, zobrazí se zhruba toto: $ git diff diff --git a/chapter1.doc b/chapter1.doc @@ -322,16 +326,14 @@ Srovnávat dvě verze přímo nelze, můžete je tak nanejvýš otevřít a ruč *.doc diff=word -Systému Git tím sdělíte, že pro všechny soubory, které odpovídají této masce (.doc), by měl být při zobrazení rozdílů použít filter word. Co je to filtr „word“? To budete muset nastavit. V našem případě nastavíme Git tak, aby ke konverzi dokumentů Word do čitelných textových souborů, způsobilých ke zpracování nástrojem diff, používal program `strings`: +Systému Git tím sdělíte, že pro všechny soubory, které odpovídají této masce (.doc), by měl být při zobrazení rozdílů použít filter „word“. Co je to filtr „word“? To budete muset nastavit. V našem případě nastavíme Git tak, aby ke konverzi dokumentů Word do čitelných textových souborů, způsobilých ke zpracování nástrojem diff, používal program `catdoc`, který byl napsán přímo pro extrakci textu z binární podoby dokumentů MS Word (můžete jej získat z `http://www.wagner.pp.ru/~vitus/software/catdoc/`). Tím wordovské dokumenty převedeme na čitelné textové soubory, na které lze úspěšně aplikovat algoritmus pro zjišťování rozdílů (diff): - $ git config diff.word.textconv strings + $ git config diff.word.textconv catdoc Tento příkaz do vašeho `.git/config` přidá sekci, která vypadá následovně: [diff "word"] - textconv = strings - -Okrajová poznámka: Existují různé druhy `.doc` souborů. Některé používají kódování UTF-16 nebo jiné kódové stránky a `strings` v nich nic rozumného nenajde. Záleží na okolnostech. + textconv = catdoc Git nyní ví, že až se bude pokoušet vypočítat rozdíl mezi dvěma snímky a jeden ze souborů bude končit na `.doc`, má tyto soubory spustit přes filtr word, který je definován jako program `strings`. Než se Git pokusí porovnat soubory Word nástrojem diff, efektivně vytvoří hezké textové verze souborů. @@ -342,15 +344,14 @@ Uveďme malý příklad. Kapitolu 1 této knihy jsem vložil do systému Git, do index c1c8a0a..b93c9e4 100644 --- a/chapter1.doc +++ b/chapter1.doc - @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics - re going to cover how to get it and set it up for the first time if you don - t already have it on your system. - In Chapter Two we will go over basic Git usage - how to use Git for the 80% - -s going on, modify stuff and contribute changes. If the book spontaneously - +s going on, modify stuff and contribute changes. If the book spontaneously - +Let's see if this works. + @@ -128,7 +128,7 @@ and data size) + Since its birth in 2005, Git has evolved and matured to be easy to use + and yet retain these initial qualities. It’s incredibly fast, it’s + very efficient with large projects, and it has an incredible branching + -system for non-linear development. + +system for non-linear development (See Chapter 3). -Git mi stroze, ale pravdivě sděluje, že jsem přidal řetězec „Let’s see if this works“. Není to sice dokonalé – na konci je přidáno několik náhodných znaků – ale evidentně to funguje. Pokud se vám podaří najít či vytvořit dobře fungující převaděč dokumentů Word na prostý text, bude toto řešení bezpochyby velmi účinné. Program `strings` je však k dispozici ve většině systémů Mac i Linux, a tak možná nejprve vyzkoušejte tento program s různými binárními formáty. +Git mi stroze, ale pravdivě sděluje, že jsem přidal řetězec „(See Chapter 3)“, což je správné. Funguje to perfektně! ##### OpenDocument Text files ##### @@ -612,14 +613,12 @@ Veškerá práce na straně serveru bude uložena do souboru update v adresáři #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -Ano, je to tak, používám globální proměnné. Ale neodsuzujte mne – náš příklad díky tomu bude názornější. + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### Standardizovaná zpráva k revizi #### diff --git a/cs/08-git-and-other-scms/01-chapter8.markdown b/cs/08-git-and-other-scms/01-chapter8.markdown index b12839ae7..fc5ecc81d 100644 --- a/cs/08-git-and-other-scms/01-chapter8.markdown +++ b/cs/08-git-and-other-scms/01-chapter8.markdown @@ -369,7 +369,7 @@ Vytvoříte tím log ve formátu XML. Můžete v něm vyhledávat autory, vytvo Tento soubor můžete dát k dispozici nástroji `git svn`, aby mohl přesněji zmapovat informace o autorech. Nástroji `git svn` můžete také zadat, aby ignoroval metadata, která systém Subversion normálně importuje: zadejte parametr `--no-metadata` k příkazu `clone` nebo `init`. Váš příkaz `import` pak bude mít tuto podobu: - $ git-svn clone http://my-project.googlecode.com/svn/ \ + $ git svn clone http://my-project.googlecode.com/svn/ \ --authors-file=users.txt --no-metadata -s my_project Import ze systému Subversion v adresáři `my_project` by měl nyní vypadat o něco lépe. Revize už nebudou mít tuto podobu: From 3ac88dac986604845087d2eccc41d14ef9c2aca2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Fri, 1 Aug 2014 22:01:16 +0200 Subject: [PATCH 130/291] no-NB translation Chapter 1#The Three States --- no-nb/01-introduction/01-chapter1.markdown | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 1163c12c6..1122a47bb 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -97,28 +97,28 @@ Når du gjør ting i Git, så vil nesten alle bare legge til data til Git databa Dette gjør det å bruke Git til en gledelig opplevelse fordi vi vet at vi kan eksperimentere uten fare for å virkelig rote til ting skikkelig. For en mer dypere innsyn i hvoradn Git lagerer data og hvordan du kan få tilbake data som virker tapt, se Kapitel 9. -### The Three States ### +### De Tre Tilstandene ### -Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. +Følg med. Detter er viktigeste å huske om Git om du ønsker at resten av læringsprossessen din skal gå flytende. Git har tre hoved tilstandet som filene dine kan være i: committed, modified, og staged. Commited betyr at dataen er laget trygt i din lokale database. Mofigied betyr at du har endret på filen men ikke har committed den til databasen enda. Staged betyr at du har markert en modified fil i dens nåværende versjon til å gå inn i ditt neste commit bilde. This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. Insert 18333fig0106.png -Figure 1-6. Working directory, staging area, and git directory. +Figure 1-6. Arbeidsmappe, staging området, og git mappe. -The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. +Git mappen er der Git lagere metadata og objekt databasen for prosjektet ditt. Dette er den mest viktige delen av Git, og det er det som er kopier når du kloner et repository fra en annen maskin. -The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. +Arbeidsmappen er en enkel checkout av en versjon av prosjektet. Disse filene er dratt ut av den komprimerte databasen i Git mappen og plassert på disken slik at du kan bruke eller modifisere det. -The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area. +Staging området er en enkelt fil, generelt holdt i Git mappen din, som lagrer informasjon om hva som vil gå inn i din neste commit. Det er noen ganger referert til som indeksen, men det begynner å bli det vanlige å kalle det staging området. -The basic Git workflow goes something like this: +Den grunnleggende Git arbeidsmåten er litt som dette: -1. You modify files in your working directory. -2. You stage the files, adding snapshots of them to your staging area. -3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. +1. Du modifiserer filer i arbeidmappa. +2. Du stage-er filene, og lager bilder av den til staging området. +3. Du gjør en commit, som tar filene som de er i staging området og lagrer det bildet permanent i Git mappen din. -If a particular version of a file is in the git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. +Hvis en bestemt versjon av en fil er i git mappen, så er den ansett som comitted. Hvis den er modifisert men har blitt lagt til i staging området, så der den staged. Og hvis den var endret siden den var sjekket ut men ikke blitt staged, så er den modifisert. I Kapitel 2 så vil du lære om disse tilstande og hvordan du kan utnytte deg av dem eller hoppe over staged-delen helt. ## Installing Git ## From fd86b63d6cc990817867b50033b67b41d66c5a4b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Fri, 1 Aug 2014 22:12:25 +0200 Subject: [PATCH 131/291] no-NB translation Chapter 1#Installing Git and Install Git through souce code --- no-nb/01-introduction/01-chapter1.markdown | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 1122a47bb..9f472c44a 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -120,15 +120,15 @@ Den grunnleggende Git arbeidsmåten er litt som dette: Hvis en bestemt versjon av en fil er i git mappen, så er den ansett som comitted. Hvis den er modifisert men har blitt lagt til i staging området, så der den staged. Og hvis den var endret siden den var sjekket ut men ikke blitt staged, så er den modifisert. I Kapitel 2 så vil du lære om disse tilstande og hvordan du kan utnytte deg av dem eller hoppe over staged-delen helt. -## Installing Git ## +## Installer Git ## -Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform. +La oss gå inn for å bruke litt Git. Det første du trenger gjøre er å installere det. Du kan gjøre det på flere måter; de to vanlige er å installere det fra kildekode eller å installere en allerede eksisterende pakke for din platform. -### Installing from Source ### +### Installere fra Kildekode ### -If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet. +Hvis du kan, så er det generelt sett nyttig å installere Git fra kildekode, ettersom du vil få nyeste versjon. Hver versjon av Git pleier å inkludere nyttige grensensitt forbedringer, så å skaffe seg den nyeste versjonen er ofte den beste måten, dersom du føler deg komfortable med å kompilere programvare fra kildekode. Det er er også tilfellet at mange Linux distrobusjoner har veldig gamle pakker; så med mindre du er på en veldig up-to-date distro eller bruker backports, så er det å installere fra kildekode den beste løsningen. -To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: +For å installere git så trenger du følgene biblioteker som Git er avhengige av: curl, zlib, openssl, expat, and libiconv. For eksempel, om du er på et system som har yum (som Fedora) eller apt-get (som Debian baserte systemer), så kan du bruke en av disse kommandoene for å installere alle avhengighetene: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel @@ -136,18 +136,18 @@ To install Git, you need to have the following libraries that Git depends on: cu $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev -When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: +Når du har alle de nødvendige avhengighetene, så kan du gå å laste det nyeste bildet fra Git nettsiden: http://git-scm.com/download -Then, compile and install: +Og så, kompiler og installer: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install -After this is done, you can also get Git via Git itself for updates: +Etter alt dette er gjort, så kan du også få Git gjennom Git for oppdateringer. $ git clone git://git.kernel.org/pub/scm/git/git.git From cef6c2b8679930b20eb882231beb0123c4af13d7 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 1 Aug 2014 23:47:00 +0200 Subject: [PATCH 132/291] [cs] synchronization with latest [en] finished... - examples (code snippets) fully synchronized - text sychronization based only on structure and recognized markup - newly found (missing in cs) translated --- cs/07-customizing-git/01-chapter7.markdown | 10 +++++----- cs/08-git-and-other-scms/01-chapter8.markdown | 14 +++++++------- cs/09-git-internals/01-chapter9.markdown | 2 +- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown index 463bffe5f..0e587fe57 100644 --- a/cs/07-customizing-git/01-chapter7.markdown +++ b/cs/07-customizing-git/01-chapter7.markdown @@ -335,7 +335,7 @@ Tento příkaz do vašeho `.git/config` přidá sekci, která vypadá následovn [diff "word"] textconv = catdoc -Git nyní ví, že až se bude pokoušet vypočítat rozdíl mezi dvěma snímky a jeden ze souborů bude končit na `.doc`, má tyto soubory spustit přes filtr word, který je definován jako program `strings`. Než se Git pokusí porovnat soubory Word nástrojem diff, efektivně vytvoří hezké textové verze souborů. +Git nyní ví, že až se bude pokoušet vypočítat rozdíl mezi dvěma snímky a každý ze souborů končící na `.doc` se má prohnat přes filtr „word“, který je definován jako program `catdoc`. Než se Git pokusí zjistit ve wordovských souborech rozdíly, dojde k jejich převedení na hezké textové verze. Uveďme malý příklad. Kapitolu 1 této knihy jsem vložil do systému Git, do jednoho odstavce jsem přidal kousek textu a dokument jsem uložil. Poté jsem spustil příkaz `git diff`, abych se podíval, co se změnilo: @@ -355,7 +355,7 @@ Git mi stroze, ale pravdivě sděluje, že jsem přidal řetězec „(See Chapte ##### OpenDocument Text files ##### -Stejný postup, který jsme použili pro soubory MS Word (`*.doc`), můžeme použít i pro soubory ve formátu OpenDocument Text (`*.odt`), kter vytváří OpenOffice.org. +Stejný postup, který jsme použili pro soubory MS Word (`*.doc`), můžeme použít i pro soubory ve formátu OpenDocument Text (`*.odt`), které vytváří OpenOffice.org. Do souboru `.gitattributes` přidejte následující řádek: @@ -460,7 +460,7 @@ Obrázek 7-2. Filtr smudge spuštěný při checkoutu – git checkout Insert 18333fig0703.png Obrázek 7-3. Filtr clean spuštěný při přípravě souborů k zapsání – git add -Původní zpráva k revizi s touto funkcí uvádí jednoduchý příklad, jak můžete před zapsáním prohnat veškeré vaše céčkové zdrojové texty programem `indent`. Tuto možnost lze aplikovat nastavením atributu `filter` v souboru `.gitattributes` tak, aby přefiltroval soubory `*.c` filtrem pro úpravu odsazování: +Původní zpráva k revizi s touto funkcí uvádí jednoduchý příklad, jak můžete před zapsáním prohnat veškeré vaše céčkové zdrojové texty programem `indent`. V souboru `.gitattributes` můžeme nastavit atribut `filter` tak, aby se soubory `*.c` zpracovaly filtrem `indent`: *.c filter=indent @@ -511,7 +511,7 @@ Systému Git můžete zadat, aby při generování archivu neexportoval určité test/ export-ignore -Až nyní spustíte příkaz git archive k vytvoření tarballu projektu, nebude tento adresář součástí archivu. +Až nyní spustíte příkaz `git archive` k vytvoření tarballu projektu, nebude tento adresář součástí archivu. #### export-subst #### @@ -601,7 +601,7 @@ Zásuvný modul `post-receive` se spouští až poté, co je celý proces dokon Skript update je velice podobný skriptu `pre-receive`, avšak s tím rozdílem, že se spouští zvlášť pro každou větev, kterou chce odesílatel aktualizovat. Pokud se uživatel pokouší odeslat revize do více větví, skript `pre-receive` se spustí pouze jednou, zatímco update se spustí jednou pro každou větev, již se odesílatel pokouší aktualizovat. Tento skript nenačítá data ze standardního vstupu, místo nich používá tři jiné parametry: název reference (větve), hodnotu SHA-1, na niž reference ukazovala před odesláním, a hodnotu SHA-1, kterou se uživatel pokouší odeslat. Je-li výstup skriptu update nenulový, je zamítnuta pouze tato reference, ostatní mohou být aktualizovány. -## Příklad standardů kontrolovaných systémem Git ## +## Příklad vynucení chování systémem Git ## V této části použijeme to, co jsme se naučili o vytváření pracovního postupu v systému Git. Systém může kontrolovat formát uživatelovy zprávy k revizi, dovolit pouze aktualizace „rychle vpřed“ a umožňovat změnu obsahu konkrétních podadresářů projektu pouze vybraným uživatelům. V této části vytvoříte skripty pro klienta, které vývojářům pomohou zjistit, zda budou jejich revize odmítnuty, a skripty na server, které si specifikované požadavky přímo vynutí. diff --git a/cs/08-git-and-other-scms/01-chapter8.markdown b/cs/08-git-and-other-scms/01-chapter8.markdown index fc5ecc81d..01dc32810 100644 --- a/cs/08-git-and-other-scms/01-chapter8.markdown +++ b/cs/08-git-and-other-scms/01-chapter8.markdown @@ -87,7 +87,7 @@ V tomto okamžiku byste tedy měli mít platný repozitář Git s importovanými tags/release-2.0.2rc1 trunk -Doplňme také, že tento nástroj odlišně přiřazuje jmenný prostor vzdálených referencí. Jestliže klonujete normální repozitář Git, získáte ze vzdáleného serveru všechny větve, lokálně dostupné pod označením `origin/[větev]` – jmenný prostor se přiřazuje na základě vzdáleného serveru. `git svn` však předpokládá, že nebudete mít více vzdálených repozitářů a všechny reference uloží na místa na vzdáleném serveru bez jmenného prostoru. Pokud si přejete zobrazit všechny své reference s úplným názvem, můžete použít nízkoúrovňový příkaz `show-ref`: +Doplňme také, že tento nástroj odlišně přiřazuje jmenný prostor vzdálených referencí. Jestliže klonujete normální repozitář Git, získáte ze vzdáleného serveru všechny větve, lokálně dostupné pod označením `origin/[větev]` – jmenný prostor je dán jménem vzdáleného serveru. Příkaz `git svn` však předpokládá, že nebudete mít více vzdálených repozitářů a všechny odkazy na místa na vzdáleném serveru uloží bez použití jmenného prostoru. Pokud si přejete zobrazit všechny své reference s úplným názvem, můžete použít nízkoúrovňový příkaz `show-ref`: $ git show-ref 1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master @@ -202,7 +202,7 @@ Spustíte-li čas od času příkaz `git svn rebase`, budete mít jistotu, že p ### Problémy s větvemi systému Git ### -Pokud vám vyhovuje způsob práce v systému Git, začnete pravděpodobně vytvářet tematické větve, budete v nich vytvářet svou práci a začleňovat je. Odesíláte-li revize na server Subversion nástrojem git svn, budete možná chtít pokaždé raději přeskládat svou práci na jedinou větev, místo abyste je slučovali. Důvod, proč raději využít možnosti přeskládání, spočívá v tom, že Subversion má lineární historii a neprovádí začleňování stejně jako Git. Nástroj git svn tak při konverzi snímků na revize Subversion sleduje pouze prvního rodiče. +Jakmile pracovní postupy v systému Git zvládnete, začnete pravděpodobně vytvářet tematické větve, budete v nich pracovat a potom je budete začleňovat (merge). Pokud odesíláte revizi na server Subversion nástrojem `git svn`, budete možná místo slučování chtít svou práci pokaždé přeskládat (rebase) na jedinou větev. Důvod, proč raději využít možnosti přeskládání, spočívá v tom, že Subversion uchovává lineární historii a neprovádí začleňování stejně jako Git. Takže `git svn` při konverzi snímků na revize Subversion sleduje pouze prvního rodiče. Předpokládejme, že vaše historie vypadá následovně: vytvořili jste větev `experiment`, zapsali jste dvě revize a začlenili jste je zpět do větve `master`. Výstup příkazu `dcommit` bude nyní vypadat následovně: @@ -231,7 +231,7 @@ Pokud tuto práci naklonuje jiný uživatel, uvidí jen jednu revizi vzniklou sl ### Větve v systému Subversion ### -Princip větvení v systému Subversion se odlišuje od větvení v systému Git. Pokud se mu můžete úplně vyhnout, mohu vám to vřele doporučit. Pokud se mu vyhnout nelze, můžete i tady použít nástroj git svn, pomocí nějž lze vytvářet nové větve a zapisovat do nich revize. +Princip větvení v systému Subversion se odlišuje od větvení v systému Git. Pravděpodobně nejlepší bude, když se mu pokusíte co nejvíc vyhýbat. Nicméně příkaz `git svn` vytváření větví a zapisování revizí do systému Subversion umožňuje. #### Vytvoření nové větve SVN #### @@ -288,7 +288,7 @@ O příkazu `git svn log` byste měli vědět dvě důležité věci. Zaprvé to #### Anotace SVN #### -Tak jako příkaz `git svn log` simuluje offline příkaz `svn log`, ekvivalentem příkazu `svn annotate` je `git svn blame [SOUBOR]`. Jeho výstup vypadá takto: +Tak jako příkaz `git svn log` simuluje příkaz `svn log` (bez nutnosti připojení), ekvivalentem příkazu `svn annotate` je provedení `git svn blame [SOUBOR]`. Jeho výstup vypadá takto: $ git svn blame README.txt 2 temporal Protocol Buffers - Google's data interchange format @@ -392,7 +392,7 @@ they look like this: Nejenže teď pole Author vypadá podstatně lépe, ale navíc jste se zbavili i záznamu `git-svn-id`. -Po importu bude nutné data trochu vyčistit. Zaprvé je nutné vyčistit nejasné reference, které vytvořil příkaz `git svn`. Nejprve přesunete značky tak, aby se z nich staly skutečné značky, a ne podivné vzdálené větve. V dalším kroku přesunete zbytek větví a uděláte z nich větve lokální. +Po importu bude nutné data trochu vyčistit. Zaprvé je nutné vyčistit podivné reference, které vytvořil příkaz `git svn`. Nejprve přesuňte značky tak, aby se z nich staly skutečné značky, a ne podivné vzdálené větve. V dalším kroku přesunete zbytek větví a uděláte z nich větve lokální. Abyste značky upravili na korektní gitové značky, spusťte @@ -499,7 +499,7 @@ Jako rychlou ukázku napíšeme jednoduchý importér. Řekněme, že pracujete Chcete-li importovat adresář Git, budeme se muset podívat na to, jak Git ukládá svá data. Jak si možná vzpomínáte, říkali jsme, že Git je v podstatě seznam odkazů na objekty revizí, které ukazují na určitý snímek obsahu. Jediné, co tedy musíte udělat, je sdělit příkazu `fast-import`, co je obsahem snímků, jaká data revizí na ně ukazují a pořadí, v němž budou převzaty. Vaše strategie tedy bude spočívat v tom, že postupně projdete jednotlivé snímky a vytvoříte revize s obsahem každého adresáře, přičemž každá revize bude odkazovat na revizi předchozí. -Stejně jako v části „Příklad systémem Git kontrolovaných standardů“ v kapitole 7 použijeme i tentokrát Ruby, s nímž většinou pracuji a který je srozumitelný. Tento příklad můžete ale beze všeho napsat v čemkoli, co vám vyhovuje. Jedinou podmínkou je, aby byly potřebné informace zapsány do výstupu stdout. +Stejně jako v podkapitole „Příklad vynucení chování systémem Git“ v kapitole 7 použijeme i tentokrát Ruby, s nímž většinou pracuji a který je srozumitelný. Tento příklad můžete ale beze všeho napsat v čemkoli, co vám vyhovuje. Jedinou podmínkou je, aby byly potřebné informace zapsány na standardní výstup (stdout). A to v případě používání Windows znamená, že budete muset věnovat zvláštní pozornost tomu, abyste na koncích řádků nevkládali znaky CR (carriage return). Příkaz `git fast-import` je v tomto směru velmi vybíravý a chce jen znaky LF (line feed) a nikoliv kombinaci CRLF, kterou používají Windows. Na začátku přejdete do cílového adresáře a identifikujete všechny podadresáře, z nichž bude každý představovat jeden snímek, který chcete importovat jako revizi. Přejdete do každého podadresáře a zadáte příkazy potřebné k jeho exportu. Základní smyčka bude mít tuto podobu: @@ -601,7 +601,7 @@ Poslední věcí, kterou musíte udělat, je vrátit aktuální označovač, aby return mark -Poznámka: Pokud používáte Windows, budete muset provést jeden krok navíc. Jak už jsem se zmínil, Windows používají nahrazují znak konce řádku posloupností CRLF, zatímco git fast-import očekává pouze LF. Abychom tento problém obešli a aby si git fast-import nestěžoval, musíte ruby říct, aby místo LF používal CRLF: +Poznámka: Pokud používáte Windows, budete muset provést jeden krok navíc. Jak už jsem se zmínil, Windows nahrazují znak konce řádku posloupností CRLF, zatímco `git fast-import` očekává pouze LF. Abychom tento problém obešli a přitom učinili příkaz `git fast-import` šťastným, musíte ruby říct, aby místo LF používal CRLF: $stdout.binmode diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown index 83c7505fd..3fe65175e 100644 --- a/cs/09-git-internals/01-chapter9.markdown +++ b/cs/09-git-internals/01-chapter9.markdown @@ -27,7 +27,7 @@ Spustíte-li v novém nebo existujícím adresáři příkaz `git init`, Git vyt objects/ refs/ -Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, o tyto dvě položky se tedy nemusíte starat. Soubor `config` obsahuje jednotlivá nastavení pro konfiguraci vašeho projektu a v adresáři `info` je uchováván globální soubor .gitignore s maskami ignorovaných souborů a adresářů, které si nepřejete sledovat. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 6. +Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, takže o tyto dvě položky se nemusíte starat. Soubor `config` obsahuje konfigurační nastavení vašeho projektu a v adresáři `info` je uložen globální soubor `exclude` s maskami ignorovaných souborů a adresářů, které nechcete explicitně ignorovat prostřednictvím souboru `.gitignore`. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 7. Zbývají čtyři důležité položky: soubory `HEAD` a `index` a adresáře `objects` a `refs`. To jsou ústřední součásti adresáře Git. V adresáři `objects` je uložen celý obsah vaší databáze, v adresáři `refs` jsou uloženy ukazatele na objekty revizí v datech (větve). Soubor `HEAD` ukazuje na větev, na níž se právě nacházíte, a soubor `index` je pro systém Git úložištěm informací o oblasti připravených změn. Na každou z těchto částí se teď podíváme podrobněji, abyste pochopili, jak Git pracuje. From cd82197d67d500e0edf2dd7aba05f3deb929f03f Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sat, 2 Aug 2014 20:06:57 +0200 Subject: [PATCH 133/291] [cs] ch.1 -- translation revision/comparison with new [en] finished --- cs/01-introduction/01-chapter1.markdown | 34 ++++++++++++------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 007fa3a9b..88b767131 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -190,38 +190,38 @@ Nyní, když máte Git nainstalovaný, můžete provést některá uživatelská Nastavení konfiguračních proměnných systému, které ovlivňují jak vzhled systému Git, tak ostatní aspekty jeho práce, umožňuje příkaz `git config`. Tyto proměnné mohou být uloženy na třech různých místech: -* Soubor `/etc/gitconfig` obsahuje údaje o všech uživatelích systému a jejich repozitářích. Pokud příkazu `git config` zadáme parametr `--system` bude číst a zapisovat jen do tohoto souboru. +* Soubor `/etc/gitconfig` obsahuje údaje pro všechny uživatele systému a pro všechny jejich repozitáře. Pokud příkazu `git config` zadáme parametr `--system` bude číst a zapisovat jen do tohoto souboru. * Soubor `~/.gitconfig` je vázán na uživatelský účet. Čtení a zápis do tohoto souboru zajistíte zadáním parametru `--global`. -* Konfigurační soubor v adresáři Git (tedy `.git/config`) jakéhokoliv užívaného repozitáře přísluší tomuto konkrétnímu repozitáři. Každá úroveň je nadřazená hodnotám úrovně předchozí, takže hodnoty v `.git/config` přebíjejí hodnotami v `/etc/gitconfig`. +* Konfigurační soubor v adresáři Git (tedy `.git/config`) jakéhokoliv užívaného repozitáře přísluší tomuto konkrétnímu repozitáři. Každá úroveň je nadřazená hodnotám úrovně předchozí, takže hodnoty v `.git/config` převládnou nad hodnotami v `/etc/gitconfig`. -Ve Windows používá Git soubor `.gitconfig`, který je umístěný v adresáři `$HOME` (v prostředí Windows je to `%USERPROFILE%`), což je u většiny uživatelů `C:\Documents and Settings\$USER` nebo `C:\Users\$USER` (kde `$USER` se v prostředí Windows označuje `%USERNAME%`). I ve Windows se hledá soubor `/etc/gitconfig`, který je ale umístěn relativně v kořeni Msys, tedy vůči místu, do kterého jste se po spuštění instalačního programu rozhodli Git nainstalovat. +Ve Windows Git hledá soubor `.gitconfig` v adresáři `$HOME` (v proměnných prostředí Windows je to `%USERPROFILE%`), což je u většiny uživatelů `C:\Documents and Settings\$USER` nebo `C:\Users\$USER` (`$USER` se ve Windows zapisuje odkazem na proměnnou prostředí `%USERNAME%`). I ve Windows se hledá soubor `/etc/gitconfig`, který je ale umístěn relativně v kořeni MSys, tedy vůči místu, do kterého jste se po spuštění instalačního programu rozhodli Git nainstalovat. -### Totožnost uživatele ### +### Vaše totožnost ### -První věcí, kterou byste měli po nainstalování systému Git udělat, je nastavení uživatelského jména (user name) a e-mailové adresy. Tyto údaje se totiž později využívají při všech revizích v systému Git a jsou nezměnitelnou složkou každé revize, kterou zapíšete: +První věcí, kterou byste měli po nainstalování systému Git udělat, je nastavení vašeho uživatelského jména (user name) a e-mailové adresy. Je to důležité, protože tuto informaci Git používá pro každý zápis revize a uvedené údaje stanou trvalou složkou záznamů o revizi, které budou putovat po okolí: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -Použijete-li parametr `--global`, pak také toto nastavení stačí provést pouze jednou. Git bude používat tyto údaje pro všechny operace, které v systému uděláte. Pokud chcete pro konkrétní projekty změnit uživatelské jméno nebo e-mailovou adresu, můžete příkaz spustit bez parametru `--global`. V takovém případě je nutné, abyste se nacházeli v adresáři daného projektu. +Použijete-li parametr `--global`, pak také toto nastavení stačí provést pouze jednou. Git bude používat tyto údaje pro všechny operace, které v systému uděláte. Pokud chcete pro konkrétní projekt uživatelské jméno nebo e-mailovou adresu změnit (přebít), můžete příkaz spustit bez parametru `--global`. V takovém případě je nutné, abyste se nacházeli v adresáři daného projektu. -### Nastavení editoru ### +### Váš editor ### -Nyní, když jste zadali své osobní údaje, můžete nastavit výchozí textový editor, který bude Git využívat pro psaní zpráv. Pokud toto nastavení nezměníte, bude Git používat výchozí editor vašeho systému, jímž je většinou Vi nebo Vim. Chcete-li používat jiný textový editor (např. Emacs), můžete použít následující příkaz: +Nyní, když jste zadali své osobní údaje, můžete nastavit výchozí textový editor, který se použije, když po vás Git bude chtít napsat nějakou zprávu. Pokud toto nastavení nezměníte, bude Git používat výchozí editor vašeho systému, jímž je většinou Vi nebo Vim. Chcete-li používat jiný textový editor, například Emacs, můžete použít následující příkaz: $ git config --global core.editor emacs -### Nastavení nástroje diff ### +### Váš nástroj diff ### -Další proměnnou, jejíž nastavení můžete považovat za užitečné, je výchozí nástroj diff, jenž bude Git používat k řešení konfliktů při slučování. Řekněme, že jste se rozhodli používat vimdiff: +Další užitečnou volbou, jejíž nastavení můžete chtít upravit, je výchozí nástroj pro zjišťování rozdílů (diff), který Git používá k řešení konfliktů při slučování (merge). Řekněme, že jste se rozhodli používat vimdiff: $ git config --global merge.tool vimdiff Jako platné nástroje slučování Git akceptuje: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge a opendiff. Nastavit můžete ale i jiné uživatelské nástroje — více informací o této možnosti naleznete v kapitole 7. -### Kontrola provedeného nastavení ### +### Kontrola va3eho nastavení ### -Chcete-li zkontrolovat provedené nastavení, použijte příkaz `git config --list`. Git vypíše všechna aktuálně dostupná nastavení: +Chcete-li zkontrolovat vaše nastavení, použijte příkaz `git config --list`. Git vypíše všechna aktuálně dostupná nastavení: $ git config --list user.name=Scott Chacon @@ -232,14 +232,14 @@ Chcete-li zkontrolovat provedené nastavení, použijte příkaz `git config --l color.diff=auto ... -Některé klíče se mohou objevit vícekrát, protože Git načítá stejný klíč z různých souborů (např. `/etc/gitconfig` a `~/.gitconfig`). V takovém případě použije Git poslední hodnotu pro každý unikátní klíč, který vidí. +Některé klíče se mohou objevit vícekrát, protože Git načítá stejný klíč z různých souborů (například `/etc/gitconfig` a `~/.gitconfig`). V takovém případě použije Git poslední hodnotu pro každý unikátní klíč, který vidí. -Můžete také zkontrolovat, jakou hodnotu Git uchovává pro konkrétní položku. Zadejte příkaz `git config {key}`: +Můžete také zkontrolovat, jakou hodnotu Git uchovává pro konkrétní klíč zadáním `git config {klíč}`: $ git config user.name Scott Chacon -## Kde hledat pomoc ## +## Získání nápovědy ## Budete-li někdy při používání systému Git potřebovat pomoc, existují tři způsoby, jak vyvolat nápovědu z manuálové stránky (manpage) pro jakýkoli z příkazů systému Git: @@ -247,12 +247,12 @@ Budete-li někdy při používání systému Git potřebovat pomoc, existují t $ git --help $ man git- -Například manpage nápovědu pro příkaz config vyvoláte zadáním: +Například manpage nápovědu pro příkaz `config` vyvoláte zadáním: $ git help config Tyto příkazy jsou užitečné, neboť je můžete spustit kdykoli, dokonce i offline. -Pokud nenajdete pomoc na manuálové stránce ani v této knize a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou. +Pokud nestačí ani manuálová stránka ani tato kniha a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou. ## Shrnutí ## From a0bdb27526da078c50edcfaf37ccb341f3a5b4e9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Sat, 2 Aug 2014 22:39:04 +0200 Subject: [PATCH 134/291] no-NB translation Chapter 1 installation done. --- no-nb/01-introduction/01-chapter1.markdown | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 9f472c44a..9c73eab43 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -151,40 +151,40 @@ Etter alt dette er gjort, så kan du også få Git gjennom Git for oppdateringer $ git clone git://git.kernel.org/pub/scm/git/git.git -### Installing on Linux ### +### Installer på Linux ### -If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum: +Hvis du vil installere Git på Linux via en binær installasjonspakke, så kan du generelt få gjort det gjennom det vanlige pakkebehandlerverktøyet som kommer med distroen din. Hiv du er på Fedora, så kan du bruke yum: $ yum install git-core -Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: +Eller om du bruker en Debian-basert distro som Ubuntu, prøv apt-get: $ apt-get install git -### Installing on Mac ### +### Installer på Mac ### -There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7): +Det er to enkle måter å installere Git på en Mac. Den enkleste er å bruke den grafiske Git installasjonspakken, som du kan laste ned fra SourceForge siden (se Figur 1-7): http://sourceforge.net/projects/git-osx-installer/ Insert 18333fig0107.png -Figure 1-7. Git OS X installer. +Figure 1-7. Git OS X innstallasjon. -The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via +Den andre vanlige måten å gjære det på er å installere Git via MacPorts ('http://macports.org'). Hvis du har MacPorts installert, installer Git med $ sudo port install git-core +svn +doc +bash_completion +gitweb -You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). +Du trenger ikke alt det ekstra, men du vil sannynligvis ønske å inkludere +svn sånn i fall du trenger å bruke git med Subversion repositorier (se Kapitel 8). -### Installing on Windows ### +### Installer på Windows ### -Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: +Å installere Git på Windows er veldig enkelt. msysGit prosjektet har en av de enkleste installasjonprossedyrene. Bare last ned installasjons exe filen fra GitHub siden, og kjær den: http://msysgit.github.com/ -After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. +Etter den er installert, så har du både en kommandolinje versjon (inkludert en SSH klient som vil bli nyttig senere) og det standard grafiske brukgergrensesnittet. -Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. +Merknad om Windows bruk: du burde bruke Git med msysGit shellet (Unix stil) som kommer med, det lar deg bruke de komplekse linjene med kommandoer gitt i denne boken. Om du av en eller annen grunn skulle trenge å bruke Windows sitt eget shell/kommandolinje konsoll, så må du bruker dobbelt annførsel tegn istedet for enkelt annførselstegn (for parametere med mellomrom i seg) og du må bruke annførseltegn på parametere som slutter med ^ om de er på slutten av linjen, siden det er et forsettelsesymbol i Windows. ## First-Time Git Setup ## From 414039a62d8d5f98e1aa066e7e4fa79d847b368b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Sat, 2 Aug 2014 22:53:27 +0200 Subject: [PATCH 135/291] no-NB translation Chapter 1 First time setup --- no-nb/01-introduction/01-chapter1.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index 9c73eab43..cdaefb9d0 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -186,17 +186,17 @@ Etter den er installert, så har du både en kommandolinje versjon (inkludert en Merknad om Windows bruk: du burde bruke Git med msysGit shellet (Unix stil) som kommer med, det lar deg bruke de komplekse linjene med kommandoer gitt i denne boken. Om du av en eller annen grunn skulle trenge å bruke Windows sitt eget shell/kommandolinje konsoll, så må du bruker dobbelt annførsel tegn istedet for enkelt annførselstegn (for parametere med mellomrom i seg) og du må bruke annførseltegn på parametere som slutter med ^ om de er på slutten av linjen, siden det er et forsettelsesymbol i Windows. -## First-Time Git Setup ## +## Git Oppsett For Førstegangsbruk ## -Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. +Nå som du har Git på systemet ditt, så vil du ønske å gjøre noen få endringer for Git miljøet ditt. Du burder bare trenge å gjøre disse tingene en gang; for de blir værende med deg mellom oppgraderinger. Du kan også endre dem når som helst ved å gå gjennom kommandoene igjen. -Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: +Git kommer med et verktøy kalt git config som lar deg hente og sette instillingvariabler som kontrollerer alle aspektene av hvoran Git ser ut og virker. Disse varaiblene kan bli lagret i tre forskjellige steder: -* `/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. -* `~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. -* config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. +* `/etc/gitconfig` filen: Inneholder verdier for alle brukerene på systemet og alle repositoriene deres. Hvis du sender valget `--system` til `git config`, så vil det lese og skrives i denne filen. +* `~/.gitconfig` filen: Spesifikk for brukeren. Du kan får Git til å lese og skrive til denne filen ved å sende `--global` valget. +* config filen i git mappen (altså `.git/config`) av hvilken som helst repository du bruker for øyeblikket: Brukes for det enkelte repositoriet. Hver nivå overstyrer verdiene fra forrige nivå, så verdiene i `.git/config` trumfer de som er i `/etc/gitconfig`. -On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. +På Windows systemer så ser Git etter `.gitconfig`filen i `$HOME` mappen (`%USERPROFILE%` for Windows), som er `C:\Documents and Settings\$USER` eller `C:\Users\$User` for de fleste, avhengig av versjon (`$USER` er `%USERNAME%` i Windows). Det ser forsatt etter /etc/gitconfig/, selv om det er relativt til MSys root, som er hvor du la inn Git for Windows systemet når du installerte det. ### Your Identity ### From 951934924227d527f0d112a4d1ffc60bc6d6b75f Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sun, 3 Aug 2014 01:07:35 +0200 Subject: [PATCH 136/291] [cs] typo in chapter 1 --- cs/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 88b767131..3e34d6e33 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -219,7 +219,7 @@ Další užitečnou volbou, jejíž nastavení můžete chtít upravit, je vých Jako platné nástroje slučování Git akceptuje: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge a opendiff. Nastavit můžete ale i jiné uživatelské nástroje — více informací o této možnosti naleznete v kapitole 7. -### Kontrola va3eho nastavení ### +### Kontrola vašeho nastavení ### Chcete-li zkontrolovat vaše nastavení, použijte příkaz `git config --list`. Git vypíše všechna aktuálně dostupná nastavení: From 858c3d39fc92cd7336f2201a8a123b18480d8a03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Barbosa?= Date: Sun, 3 Aug 2014 02:55:48 -0300 Subject: [PATCH 137/291] [pt-br] Update chapter 3 git-branching In line 53 'testing' is the name of branch --- pt-br/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pt-br/03-git-branching/01-chapter3.markdown b/pt-br/03-git-branching/01-chapter3.markdown index 1b41b516a..21bf4b417 100644 --- a/pt-br/03-git-branching/01-chapter3.markdown +++ b/pt-br/03-git-branching/01-chapter3.markdown @@ -50,7 +50,7 @@ Para mudar para um branch existente, você executa o comando `git checkout`. Vam $ git checkout testing -Isto move o HEAD para apontar para o branch de testes (ver Figura 3-6). +Isto move o HEAD para apontar para o branch testing (ver Figura 3-6). Insert 18333fig0306.png Figura 3-6. O HEAD aponta para outro branch quando você troca de branches. From 37fd1be85e3b8181747413051c4d9ca7e200e24e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Sun, 3 Aug 2014 14:38:06 +0200 Subject: [PATCH 138/291] no-NB translation Chapter 1 everything after Setup --- no-nb/01-introduction/01-chapter1.markdown | 38 +++++++++++----------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index cdaefb9d0..ffa721142 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -198,32 +198,32 @@ Git kommer med et verktøy kalt git config som lar deg hente og sette instilling På Windows systemer så ser Git etter `.gitconfig`filen i `$HOME` mappen (`%USERPROFILE%` for Windows), som er `C:\Documents and Settings\$USER` eller `C:\Users\$User` for de fleste, avhengig av versjon (`$USER` er `%USERNAME%` i Windows). Det ser forsatt etter /etc/gitconfig/, selv om det er relativt til MSys root, som er hvor du la inn Git for Windows systemet når du installerte det. -### Your Identity ### +### Din Identitet ### -The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: +Det første du burde gjøre når du installerer Git er å sette brukernavnet og email-addressen din. Dette er viktig fordig alle Git commiter bruker denne informasjonen, og det er uforanderlig integrert inn i commitene du sender rundt. $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project. +Igjen, så trenger du bare å gjøre dette en gang om du bruker `--global` valget, siden Git alltid bruker den informasjonen for alt du gjør på det systemet. Hvis du ønsker å overstyre dette med ett annet navn eller email-adresse for bestemte prosjekter, så kan du kjøre kommandoen uten `--global` valget når du er i det prosjektet. -### Your Editor ### +### Din Editor ### -Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following: +Nå som din identiter er satt opp, så kan du konfigurere den forhåndsvalgte tekst editoren som vil bli brukt når Git trenger at du skriver en beskjed. Forhåndsvalget satt i Git bruker systemets forhåndsvalgte editor, som generelt sett er Vi eller Vim. Hvis du ønsker å bruke en annen tekst editor, som Emacs, så kan du gjøre følgende: $ git config --global core.editor emacs -### Your Diff Tool ### +### Ditt Diff Verktøy ### -Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff: +Et annet nyttig valg du kanskje vil endre på er forhåndsvalgt diff verktøy for å bruke til å håndtere merge konflikter. Så si du ønsker å bruke vimdiff: $ git config --global merge.tool vimdiff -Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that. +Git godtar kdiff3, tkdiff, meld, xxdif, emerge, vimdiff, gvimdiff, ecmerge, and opendiff som godkjente merge verktøy. Du kan også sette opp et eget verktøy; se Kapitel 7 for mer informasjon om hvordan gjøre det. -### Checking Your Settings ### +### Sjekke Innstillingene Dine ### -If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: +Hvis du ænsker å sjekke innstillingene dine, så kan du bruke `git config --list` kommandoen for å liste alle innstillingene Git kan finne akkurat da: $ git config --list user.name=Scott Chacon @@ -234,28 +234,28 @@ If you want to check your settings, you can use the `git config --list` command color.diff=auto ... -You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees. +Du kan se nøkler mer enn en gang, siden Git leser den samme nøkkelen fra forskjellige filer (`/etc/gitconfig` og `~/.gitconfig`, for eksempel). I såfall, så bruker Git den siste verdien for hver unike nøkkel den ser. -You can also check what Git thinks a specific key’s value is by typing `git config {key}`: +Du kan også sjekke hva Git tror en spesifikk nøkkels verdi er ved å skrive `git config {nøkkel}`: $ git config user.name Scott Chacon -## Getting Help ## +## Skaffe Seg Hjelp ## -If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: +Hvis du noen gang trenger hjelp mens du bruker Git, så er det tre måter å få manual sidens (manpage) hjelp for en hvilken som helst Git kommando: $ git help $ git --help $ man git- -For example, you can get the manpage help for the config command by running +For eksempel, du kan få manpage hjelp ved for config kommandoen ved å bruke $ git help config -These commands are nice because you can access them anywhere, even offline. -If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. +Disse kommandoene er fine fordi du kan få tilgang til dem over alt, tilogmed offline. +Hvis manpagene og denne boken ikke er nok, og du trenger hjelp fra folk, så kan du prøve `#git` eller `#github` kanalene på Freenode IRC Server (irc.freenode.net). Disse kanalene er til vanlig fylt med hundrevis av folk som alle kan veldig mye om Git og er ofte villige til å hjelpe. -## Summary ## +## Sammendrag ## -You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics. +Du burde ha grunnleggende forståelse for hva Git er og hvordan det skiller seg fra CVCSene du kan ha brukt. Du burde også nå ha en funksjonell versjon av Git på ditt system som er satt opp med din personlige identitet. Det er nå på tide å lære litt grunnleggende Git. From 1cc57ebcf8aaba0d2fc30d43057188835d0378de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Sun, 3 Aug 2014 14:50:13 +0200 Subject: [PATCH 139/291] no-NB translation Chapter 1 translated. --- no-nb/01-introduction/01-chapter1.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown index ffa721142..158c7678c 100644 --- a/no-nb/01-introduction/01-chapter1.markdown +++ b/no-nb/01-introduction/01-chapter1.markdown @@ -19,16 +19,16 @@ Figure 1-1. Lokalt versjonskontrolldiagram. Et av de mer populære VCS-verktøyene var et system kalt rcs, som fremdeles distribueres med mange datamaskiner i dag. Selv det populære Mac OS X-operativsystemet inkluderer rcs-kommandoen når en installerer utviklerverktøyene. Dette verktøyet virker, enkelt fortalt, ved å beholde et sett av patcher (dvs, forskjellen mellom filene) fra en revisjon til en annen, i et spesielt format på disken; det kan så gjenskape hvordan enhver fil så ut på et hvilket som helst tidspunkt, ved å legge sammen alle patchene. -### Centralized Version Control Systems ### +### Sentraliserte Versjonkontrol Systemer ### -The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2). +Det neste store problemet folk møter er at de trenger å sammarbeide med utviklere på andre systemer. For å håndere det problemet så var Sentraliserte Versjonkontrol Systmer (CVCSer) utviklet. Disse systemene, som CVS, Subversion, og Perforce, har en ekelt server som inneholder alle versjonerte filer, og tallvis med klienter som sjekker ut filene fra det sentrale stedet. I mange år så har det vært standard for versjonkontrol (Se Figur 1-2). Insert 18333fig0102.png -Figure 1-2. Centralized version control diagram. +Figure 1-2. Sentralisert versjonkontroll diagram. -This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client. +Dette oppsettet tilbyr mange fordeler, spesielt over lokal VCS. For eksempel, alle vet til en viss grad hva alle andre i prosjektet gjør. Administratorer har god kontroll over hvem som kan gjøre hva; og det er langt enklere å administrere en CVCS enn det er å jobbe med lokale databaser på alle klienter. -However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. +Dette oppsettet har også noen seriøse ulemper. Det mest opplagte er det enkelte punktet for feiling som den sentraliserte serven representere. Hvis den serveren er nede i en time, så kan ingen samarbeide i det hele tatt, eller lagre versjon endringer for noe som helst de jobber på i løpet av den timen. Hvis harddisken den sentraliserte databasen er på blir korrupt, og skikkelige backuper ikke har blir lagt, så vil du miste alt- hele historien til prosjektet med untak i hvilket nå enn enkle bildet folk har akkurat da på deres lokale maskiner. Lokale VCS systmer lider fra det samme problemet, når du har hele historien til prosjeket på ett sted, så risikerer du å miste alt. ### Distribuerte versjonkontrollsystemer ### From 739323d072d4785be6721b7c81a1063631779c19 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Sun, 3 Aug 2014 22:44:20 +0200 Subject: [PATCH 140/291] no-NB trans Chapter 2 Git Basic --- no-nb/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown index 69de1735e..b8642eb2e 100644 --- a/no-nb/02-git-basics/01-chapter2.markdown +++ b/no-nb/02-git-basics/01-chapter2.markdown @@ -1,6 +1,6 @@ -# Git Basics # +# Grunnleggende Git # -If you can read only one chapter to get going with Git, this is it. This chapter covers every basic command you need to do the vast majority of the things you’ll eventually spend your time doing with Git. By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. We’ll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. +Om du bare kan lese et kapitel for å komme i gang med Git, så er dette det kapitelet. Dette kapitellet dekker hver grunnlegende kommando du trenger for å gjøre største delen av ting du etterhvert vil bruke tiden din på å gjøre i Git. Ved slutten av dette kapitelet, så burde du være istand til å konfigurere og initiere et repository, begynne og stoppe overvåking av filer, og stage og commite endringer. Vi vil også vise deg hvordan sette opp Git til å ignorere visse filer og filmønstre, hvordan angre på feil fort og enkelt, hvordan se gjennom historien for prosjektet ditt og se på endringer mellom commiter, og hvordan pushe(dytte) endringer til eller pulle(dra) endringer fra en fjern repository. ## Getting a Git Repository ## From 15f5ed0e7e1f57060be54e9d44aa6e0f9948de2b Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Mon, 4 Aug 2014 07:59:02 +0200 Subject: [PATCH 141/291] [it] reviewed chapter 1 Rewording for better understanding --- it/04-git-server/01-chapter4.markdown | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown index 23de5a0a5..4ec820877 100644 --- a/it/04-git-server/01-chapter4.markdown +++ b/it/04-git-server/01-chapter4.markdown @@ -231,15 +231,14 @@ L'autenticazione tramite chiavi SSH generalmente richiede una restrizione dei di $ chmod -R go= ~/.ssh - - Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro: +Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro: $ cd /opt/git $ mkdir project.git $ cd project.git $ git --bare init -Poi, John, Josie o Jessica possono inviare la prima versione del loro progetto nel repository aggiungendolo come ramo remoto ed inviandolo su di un ramo. Nota che qualcuno deve accedere via shell alla macchina e creare un repository base ogni volta che si vuole aggiungere un progetto. Usiamo il nome `gitserver` per il server dove hai impostato il tuo utente 'git' ed il repository. Se lo stai usando nella rete interna e hai impostato un DNS con il punto `gitserver` per puntare a questo server, allora puoi usare il comando: +E John, Josie o Jessica possono inviare la prima versione del loro progetto nel repository aggiungendolo come ramo remoto ed inviandolo su di un ramo. Fai attenzione che ogni volta che vuoi aggiungere un progetto, qualcuno deve accedere via shell alla macchina e creare un repository base. Usiamo il nome `gitserver` per il server dove hai impostato il tuo utente 'git' ed il repository. Se lo stai usando nella rete interna e hai impostato un DNS con il punto `gitserver` per puntare a questo server, allora puoi usare il comando: # sul computer di Johns $ cd myproject From 127cfe7d73c540bfc2a76c642736fe54a950d8fc Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Mon, 4 Aug 2014 16:44:00 +0200 Subject: [PATCH 142/291] [cs] Chapter 2 manually revised up to 2.3 including --- cs/02-git-basics/01-chapter2.markdown | 84 +++++++++++++-------------- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index 7720fdead..9ea03b7ef 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -1,10 +1,10 @@ # Základy práce se systémem Git # -Pokud jste ochotni přečíst si o systému Git jen jednu kapitolu, měla by to být právě tahle. Tato kapitola popíše všechny základní příkazy, jejichž prováděním strávíte drtivou většinu času při práci se systémem Git. Po přečtení kapitoly byste měli být schopni nakonfigurovat a inicializovat repozitář, spustit a ukončit sledování souborů, připravovat soubory a zapisovat revize. Ukážeme také, jak nastavit Git, aby ignoroval určité soubory a masky souborů, jak rychle a jednoduše vrátit nežádoucí změny, jak procházet historii projektu a zobrazit změny mezi jednotlivými revizemi a jak posílat soubory do vzdálených repozitářů a stahovat z nich. +Pokud jste ochotni přečíst si o systému Git jen jednu kapitolu, měla by to být právě tahle. Tato kapitola popíše všechny základní příkazy, jejichž prováděním strávíte při práci se systémem Git drtivou většinu času. Po přečtení kapitoly byste měli být schopni nakonfigurovat a inicializovat repozitář, spustit a ukončit sledování souborů, připravovat soubory a zapisovat revize. Ukážeme si také, jak nastavit Git, aby ignoroval určité soubory a masky souborů, jak rychle a jednoduše vrátit nežádoucí změny, jak procházet historii projektu a zobrazit změny mezi jednotlivými revizemi a jak posílat soubory do vzdálených repozitářů a naopak z nich soubory zase stahovat. ## Získání repozitáře Git ## -Projekt v systému Git lze získat dvěma základními způsoby. První vezme existující projekt nebo adresář a importuje ho do systému Git. Druhý naklonuje existující repozitář Git z jiného serveru. +Projekt v systému Git lze získat dvěma základními způsoby. První způsob spočívá v tom, že vezmeme existující projekt nebo adresář a importujeme ho do systému Git. Druhý způsob spočívá v naklonování již existujícího repozitáře Git z jiného serveru. ### Inicializace repozitáře v existujícím adresáři ### @@ -12,9 +12,9 @@ Chcete-li zahájit sledování existujícího projektu v systému Git, přejdět $ git init -Příkaz vytvoří nový podadresář s názvem `.git`, který bude obsahovat všechny soubory nezbytné pro repozitář, tzv. kostru repozitáře Git. V tomto okamžiku ještě není nic z vašeho projektu sledováno. (Více informací o tom, jaké soubory obsahuje právě vytvořený adresář `.git`, naleznete v kapitole 9.) +Příkaz vytvoří nový podadresář s názvem `.git`, který bude obsahovat všechny soubory nezbytné pro repozitář, tzv. kostru repozitáře Git. V tomto okamžiku se z vašeho projektu ještě nic nesleduje. (Více informací o tom, jaké soubory obsahuje právě vytvořený adresář `.git`, naleznete v *kapitole 9*.) -Chcete-li spustit verzování existujících souborů (na rozdíl od prázdného adresáře), měli byste pravděpodobně zahájit sledování (tracking) těchto souborů a provést první revizi (commit). Můžete tak učinit pomocí několika příkazů `git add`, jimiž určíte soubory, které chcete sledovat, a provedete revizi: +Chcete-li spustit verzování existujících souborů (a ne jen prázdného adresáře), měli byste pravděpodobně zahájit sledování (tracking) těchto souborů a provést první revizi (commit). Můžete tak učinit pomocí několika příkazů `git add`, jimiž určíte soubory, které chcete sledovat, a provedete revizi: $ git add *.c $ git add README @@ -24,27 +24,27 @@ K tomu, co přesně tyto příkazy provedou, se dostaneme za okamžik. V této c ### Klonování existujícího repozitáře ### -Chcete-li vytvořit kopii existujícího repozitáře Git (například u projektu, do nějž chcete začít přispívat), pak příkazem, který hledáte, je `git clone`. Pokud jste zvyklí pracovat s jinými systémy VCS, např. se systémem Subversion, jistě jste si všimli, že příkaz zní `clone`, a nikoli `checkout`. Souvisí to s jedním podstatným rozdílem: Git stáhne kopii téměř všech dat na serveru. Po spuštění příkazu `git clone` budou k historii projektu staženy všechny verze všech souborů. Pokud by někdy poté došlo k poruše disku serveru, lze použít libovolný z těchto klonů na kterémkoli klientovi a obnovit pomocí něj server zpět do stavu, v němž byl v okamžiku klonování (může dojít ke ztrátě některých zásuvných modulů na straně serveru apod., ale všechna verzovaná dat budou obnovena – další podrobnosti v kapitole 4). +Chcete-li vytvořit kopii existujícího repozitáře Git (například u projektu, do nějž chcete začít přispívat), pak příkazem, který hledáte, je `git clone`. Pokud jste zvyklí pracovat s jinými systémy pro správu verzí, jako je například Subversion, jistě jste si všimli, že příkaz zní `clone`, a nikoli `checkout`. Souvisí to s jedním podstatným rozdílem: Git získá kopii téměř všech dat na serveru. Po spuštění příkazu `git clone` budou k historii projektu staženy všechny verze všech souborů. Pokud by někdy poté došlo k poruše disku serveru, lze použít libovolný z těchto klonů na kterémkoli klientovi a obnovit pomocí něj server zpět do stavu, v němž byl v okamžiku klonování (může dojít ke ztrátě některých zásuvných modulů na straně serveru a podobných věcí, ale všechna verzovaná data budou obnovena. Další podrobnosti naleznete v *kapitole 4*). Repozitář naklonujete příkazem `git clone [url]`. Pokud například chcete naklonovat knihovnu Ruby Git nazvanou Grit, můžete to provést následovně: $ git clone git://github.com/schacon/grit.git -Tímto příkazem vytvoříte adresář s názvem `grit`, inicializujete v něm adresář `.git`, stáhnete všechna data pro tento repozitář a systém rovněž stáhne pracovní kopii nejnovější verze. Přejdete-li do nového adresáře `grit`, uvidíte v něm soubory projektu připravené ke zpracování nebo jinému použití. Pokud chcete naklonovat repozitář do adresáře pojmenovaného jinak než grit, můžete název zadat jako další parametr na příkazovém řádku: +Tímto příkazem se vytvoří adresář s názvem `grit`, inicializuje se v něm adresář `.git`, stáhnou se všechna data pro tento repozitář a vytvoří se pracovní kopie nejnovější verze. Přejdete-li do nového adresáře `grit`, uvidíte v něm soubory projektu připravené ke zpracování nebo jinému použití. Pokud chcete naklonovat repozitář do adresáře pojmenovaného jinak než grit, můžete název zadat jako další parametr na příkazovém řádku: $ git clone git://github.com/schacon/grit.git mygrit -Tento příkaz učiní totéž co příkaz předchozí, jen cílový adresář se bude jmenovat `mygrit`. +Tento příkaz učiní totéž co příkaz předchozí, ale cílový adresář se bude jmenovat `mygrit`. -Git nabízí celou řadu různých přenosových protokolů. Předchozí příklad využívá protokol `git://`, můžete se ale setkat také s protokolem `http(s)://` nebo `user@server:/path.git`, který používá přenosový protokol SSH. V kapitole 4 budou představeny všechny dostupné parametry pro nastavení serveru pro přístup do repozitáře Git, včetně jejich předností a nevýhod. +Git nabízí celou řadu různých přenosových protokolů. Předchozí příklad využívá protokol `git://`, můžete se ale setkat také s protokolem `http(s)://` nebo `user@server:/path.git`, který používá přenosový protokol SSH. V *kapitole 4* budou představeny všechny dostupné možnosti, které mohou být pro přístup do repozitáře Git na serveru nastaveny, včetně jejich předností a nevýhod. ## Nahrávání změn do repozitáře ## -Nyní máte vytvořen repozitář Git a checkout nebo pracovní kopii souborů k projektu. Řekněme, že potřebujete udělat pár změn a zapsat snímky těchto změn do svého repozitáře pokaždé, kdy se projekt dostane do stavu, v němž ho chcete nahrát. +Nyní máte vytvořen opravdový gitový repozitář a pracovní kopii souborů k projektu (checkout). Řekněme, že potřebujete udělat pár změn a zapsat snímky těchto změn do svého repozitáře pokaždé, kdy se projekt dostane do stavu, který chcete zaznamenat. -Nezapomeňte, že každý soubor ve vašem pracovním adresáři může být ve dvou různých stavech: sledován a nesledován. Za sledované jsou označovány soubory, které byly součástí posledního snímku. Mohou být ve stavu změněno (modified), nezměněno (unmodified) nebo připraveno k zapsání (staged). Nesledované soubory jsou všechny ostatní, tedy veškeré soubory ve vašem pracovním adresáři, které nebyly obsaženy ve vašem posledním snímku a nejsou v oblasti připravených změn. Po úvodním klonování repozitáře budou všechny vaše soubory sledované a nezměněné, protože jste právě provedli jejich checkout a dosud jste neudělali žádné změny. +Nezapomeňte, že každý soubor ve vašem pracovním adresáři může být ve dvou různých stavech: *sledován* (tracked) a *nesledován* (untracked). Za *sledované* jsou označovány soubory, které byly součástí posledního snímku. Mohou být ve stavu *změněn* (modified), *nezměněn* (unmodified) nebo *připraven k zapsání* (staged). *Nesledované* soubory jsou všechny ostatní, tedy veškeré soubory ve vašem pracovním adresáři, které nebyly obsaženy ve vašem posledním snímku a nejsou v oblasti připravených změn. Po úvodním klonování repozitáře budou všechny vaše soubory sledované a nezměněné, protože jste právě provedli jejich checkout a dosud jste neudělali žádné změny. -Jakmile začnete soubory upravovat, Git je bude považovat za „změněné“, protože jste v nich od poslední revize provedli změny. Poté všechny tyto změněné soubory připravíte k zapsání a následně všechny připravené změny zapíšete. Cyklus může začít od začátku. Pracovní cyklus je znázorněn na obrázku 2-1. +Jakmile začnete soubory upravovat, Git je bude považovat za změněné, protože jste v nich od poslední revize provedli změny. Poté všechny tyto změněné soubory *připravíte k zapsání* (stage) a následně všechny připravené změny zapíšete (commit). A celý cyklus se opakuje. Pracovní cyklus je znázorněn na obrázku 2-1. Insert 18333fig0201.png Obrázek 2-1. Cyklus stavů vašich souborů @@ -57,9 +57,9 @@ Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz ` On branch master nothing to commit, working directory clean -To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole. +To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy, žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole. -Řekněme, že nyní přidáte do projektu nový soubor, například soubor `README`. Pokud soubor neexistoval dříve a vy spustíte příkaz `git status`, bude nesledovaný soubor uveden takto: +Řekněme, že nyní přidáte do projektu nový soubor, například soubor `README`. Pokud soubor dříve neexistoval a vy spustíte příkaz `git status`, bude nesledovaný soubor uveden takto: $ vim README $ git status @@ -91,9 +91,9 @@ Když nyní znovu provedete příkaz k výpisu stavů (git status), uvidíte, ž Můžeme říci, že je připraven k zapsání, protože je uveden v části „Changes to be committed“, tedy „Změny k zapsání“. Pokud v tomto okamžiku zapíšete revizi, v historickém snímku bude verze souboru z okamžiku, kdy jste spustili příkaz `git add`. Možná si vzpomínáte, že když jste před časem spustili příkaz `git init`, provedli jste potom příkaz `git add (soubory)`. Příkaz jste zadávali kvůli zahájení sledování souborů ve vašem adresáři. Příkaz `git add` je doplněn uvedením cesty buď k souboru, nebo k adresáři. Pokud se jedná o adresář, příkaz přidá rekurzivně všechny soubory v tomto adresáři. -### Připravení změněných souborů ### +### Příprava změněných souborů k zapsání ### -Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem `benchmarks.rb` a poté znovu spustíte příkaz `status`, zobrazí se výpis podobného obsahu: +Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem `benchmarks.rb` a poté znovu spustíte příkaz `status`, zobrazí se něco takového: $ git status On branch master @@ -109,7 +109,7 @@ Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už modified: benchmarks.rb -Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (Změněno, ale neaktualizováno). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání. Chcete-li ho připravit, spusťte příkaz `git add` (jedná se o univerzální příkaz – používá se k zahájení sledování nových souborů, k připravení souborů a k dalším operacím, jako např. k označení souborů, které kolidovaly při sloučení, za vyřešené). Spusťme nyní příkaz `git add` k připravení souboru `benchmarks.rb` k zapsání a následně znovu příkaz `git status`: +Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (změněny nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). Chcete-li ho připravit k zapsání, spusťte příkaz `git add` (jedná se o víceúčelový příkaz – používá se k zahájení sledování nových souborů i k dalším operacím, jako je například označení vyřešených případů kolize souborů při slučování). Spusťme nyní příkaz `git add`, abychom soubor `benchmarks.rb` připravili k zapsání, a potom znovu zadejme příkaz `git status`: $ git add benchmarks.rb $ git status @@ -121,7 +121,7 @@ Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ ( modified: benchmarks.rb -Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete ještě před zapsáním revize provést v souboru `benchmarks.rb`. Soubor znovu otevřete a provedete změnu. Soubor je připraven k zapsání. Spusťme však ještě jednou příkaz `git status`: +Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete ještě před zapsáním revize provést v souboru `benchmarks.rb`. Soubor znovu otevřete, provedete změnu a chcete jej zapsat. Spusťme však ještě jednou příkaz `git status`: $ vim benchmarks.rb $ git status @@ -139,7 +139,7 @@ Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští re modified: benchmarks.rb -Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor přesně tak, jak je. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru: +Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor k zapsání ve přesně tak, jak vypadá v daném okamžiku. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal, když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru: $ git add benchmarks.rb $ git status @@ -153,18 +153,18 @@ Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno ### Ignorované soubory ### -Často se ve vašem adresáři vyskytne skupina souborů, u nichž nebudete chtít, aby je Git automaticky přidával nebo aby je vůbec uváděl jako nesledované. Jedná se většinou o automaticky vygenerované soubory, jako soubory log nebo soubory vytvořené sestavovacím systémem. V takovém případě můžete vytvořit soubor `.gitignore`, který specifikuje ignorované soubory. Tady je malý příklad souboru `.gitignore`: +Ve vašem adresáři se často vyskytne skupina souborů, u nichž nebudete chtít, aby je Git automaticky přidával nebo aby je vůbec uváděl jako nesledované. Jedná se většinou o automaticky vygenerované soubory, jako soubory log nebo soubory vytvořené při překladu. V takových případech můžete vytvořit soubor `.gitignore` se seznamem masek pro ignorované soubory. Tady je malý příklad souboru `.gitignore`: $ cat .gitignore *.[oa] *~ -První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – objektové a archivní soubory, které mohou být výsledkem vytváření kódu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), již mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci apod. Nastavit soubor `.gitignore`, ještě než se pustíte do práce, bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte. +První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – *objekty* a *archivní* soubory, které mohou být výsledkem překladu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci a podobné. Vytvoření a naplnění souboru `.gitignore` ještě dříve než se pustíte do práce, bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte. -Toto jsou pravidla pro masky, které můžete použít v souboru `.gitignore`: +Pravidla pro masky, které můžete použít v souboru `.gitignore`, jsou následující: * Prázdné řádky nebo řádky začínající znakem `#` budou ignorovány. -* Standardní masku souborů. +* Standardní masky souborů. * Chcete-li označit adresář, můžete masku zakončit lomítkem (`/`). * Pokud řádek začíná vykřičníkem (`!`), maska na něm je negována. @@ -190,7 +190,7 @@ Tady je další příklad souboru `.gitignore`: ### Zobrazení připravených a nepřipravených změn ### -Je-li pro vaše potřeby příkaz `git status` příliš neurčitý – chcete přesně vědět, co jste změnili, nejen které soubory – můžete použít příkaz `git diff`. Podrobněji se budeme příkazu `git diff` věnovat později. Vy ho však nejspíš budete nejčastěji využívat k zodpovězení těchto dvou otázek: Co jste změnili, ale ještě nepřipravili k zapsání? A co jste připravili a nyní může být zapsáno? Zatímco příkaz `git status` vám tyto otázky zodpoví velmi obecně, příkaz `git diff` přesně zobrazí přidané a odstraněné řádky – tedy samotná záplata. +Je-li pro vaše potřeby příkaz `git status` příliš neurčitý – chcete přesně vědět, co jste změnili, nejen které soubory – můžete použít příkaz `git diff`. Podrobněji se budeme příkazu `git diff` věnovat později. Vy ho však nejspíš budete nejčastěji využívat k zodpovězení těchto dvou otázek: Co jste změnili, ale ještě nepřipravili k zapsání? A co jste připravili a nyní může být zapsáno? Zatímco příkaz `git status` vám tyto otázky zodpoví velmi obecně, příkaz `git diff` přesně zobrazí přidané a odstraněné řádky – tedy samotnou záplatu. Řekněme, že znovu upravíte a připravíte soubor `README` a poté bez připravení upravíte soubor `benchmarks.rb`. Po spuštění příkazu `status` se zobrazí zhruba toto: @@ -229,7 +229,7 @@ Chcete-li vidět, co jste změnili, avšak ještě nepřipravili k zapsání, za Tento příkaz srovná obsah vašeho pracovního adresáře a oblasti připravených změn. Výsledek vám ukáže provedené změny, které jste dosud nepřipravili k zapsání. -Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte příkaz `git diff --cached`. (Ve verzích Git 1.6.1 a novějších můžete použít také příkaz `git diff --staged`, který se možná snáze pamatuje.) Tento příkaz srovná připravené změny s poslední revizí: +Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte příkaz `git diff --cached`. (Ve verzích Git 1.6.1 a novějších můžete použít také příkaz `git diff --staged`, který se možná snáze pamatuje.) Tento příkaz srovná připravené změny (staged changes) s poslední revizí: $ git diff --cached diff --git a/README b/README @@ -244,7 +244,7 @@ Chcete-li vidět, co jste připravili a co bude součástí příští revize, p + +Grit is a Ruby library for extracting information from a Git repository -K tomu je třeba poznamenat, že příkaz `git diff` sám o sobě nezobrazí všechny změny provedené od poslední revize, ale jen změny, které zatím nejsou připraveny. To může být občas matoucí, protože pokud jste připravili všechny provedené změny, výstup příkazu `git diff` bude prázdný. +K tomu je třeba poznamenat, že příkaz `git diff` sám o sobě nezobrazí všechny změny provedené od poslední revize, ale jen změny, které zatím nejsou připraveny. To může být občas matoucí, protože pokud jste připravili všechny provedené změny, bude výstup příkazu `git diff` prázdný. V dalším příkladu ukážeme situaci, kdy jste připravili soubor `benchmarks.rb` a poté ho znovu upravili. Příkaz `git diff` můžete nyní použít k zobrazení změn v souboru, které byly připraveny, a změn, které nejsou připraveny: @@ -298,12 +298,12 @@ A příkaz `git diff --cached` ukáže změny, které už připraveny jsou: ### Zapisování změn ### -Nyní, když jste seznam připravených změn nastavili podle svých představ, můžete začít zapisovat změny. Nezapomeňte, že všechno, co dosud nebylo připraveno k zapsání – všechny soubory, které jste vytvořili nebo změnili a na které jste po úpravách nepoužili příkaz `git add` – nebudou do revize zahrnuty. Zůstanou na vašem disku ve stavu „změněno“. -Když jsme v našem případě naposledy spustili příkaz `git status`, viděli jste, že všechny soubory byly připraveny k zapsání. Nyní může proběhnout samotné zapsání změn. Nejjednodušším způsobem zapsání je zadat příkaz `git commit`: +Nyní, když jste seznam připravených změn nastavili podle svých představ, můžete začít zapisovat změny. Nezapomeňte, že všechno, co dosud nebylo připraveno k zapsání – všechny soubory, které jste vytvořili nebo změnili a na které jste po úpravách nepoužili příkaz `git add` –, nebudou do revize zahrnuty. Zůstanou na vašem disku jako změněné soubory. +Když jste v našem případě naposledy spustili příkaz `git status`, viděli jste, že všechny soubory byly připraveny k zapsání. Takže jste připraveni k samotnému zapsání změn. Nejjednodušší způsob zapsání změn spočívá v použití příkazu `git commit`: $ git commit -Po zadání příkazu se otevře zvolený editor. (Ten je nastaven proměnnou prostředí `$EDITOR` vašeho shellu. Většinou se bude jednat o editor vim nebo emacs, ale pomocí příkazu `git config --global core.editor` můžete nastavit i jakýkoli jiný – viz kapitola 1.) +Po zadání příkazu se otevře vámi zvolený editor. (Ten je nastaven proměnnou prostředí `$EDITOR` vašeho shellu. Většinou se bude jednat o editor vim nebo emacs, ale pomocí příkazu `git config --global core.editor` můžete nastavit i jakýkoli jiný – viz *kapitola 1*.) Editor zobrazí následující text (tento příklad je z editoru Vim): @@ -319,7 +319,7 @@ Editor zobrazí následující text (tento příklad je z editoru Vim): ~ ".git/COMMIT_EDITMSG" 10L, 283C -Jak vidíte, výchozí zpráva k revizi (commit message) obsahuje zakomentovaný aktuální výstup příkazu `git status` a nahoře jeden prázdný řádek. Tyto komentáře můžete odstranit a napsat vlastní zprávu k revizi, nebo je můžete v souboru ponechat, abyste si lépe vzpomněli, co bylo obsahem dané revize. (Chcete-li zařadit ještě podrobnější informace o tom, co jste měnili, můžete k příkazu `git commit` přidat parametr `-v`. V editoru se pak zobrazí také výstup „diff“ ke konkrétním změnám a vy přesně uvidíte, co bylo změněno.) Jakmile editor zavřete, Git vytvoří revizi se zprávou, kterou jste napsali (s odstraněnými komentáři a rozdíly). +Jak vidíte, výchozí zpráva k revizi (commit message) obsahuje zakomentovaný aktuální výstup příkazu `git status` a nahoře jeden prázdný řádek. Tyto komentáře můžete odstranit a napsat vlastní zprávu k revizi, nebo je můžete v souboru ponechat, abyste si lépe vzpomněli, co bylo obsahem dané revize. (Chcete-li zařadit ještě podrobnější informace o tom, co jste měnili, můžete k příkazu `git commit` přidat parametr `-v`. V editoru se pak zobrazí také výstup rozdílů (diff) ke konkrétním změnám a vy přesně uvidíte, co bylo změněno.) Jakmile editor zavřete, Git vytvoří revizi se zprávou, kterou jste napsali (s odstraněnými komentáři a rozdíly). Zprávu k revizi můžete rovněž napsat do řádku k příkazu `commit`. Jako zprávu ji označíte tak, že před ni vložíte příznak `-m`: @@ -328,13 +328,13 @@ Zprávu k revizi můžete rovněž napsat do řádku k příkazu `commit`. Jako 2 files changed, 3 insertions(+) create mode 100644 README -Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (hlavní, `master`), jaký kontrolní součet SHA-1 revize dostala (`463dc4f`), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize. +Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (`master`), jaký je kontrolní součet SHA-1 revize (`463dc4f`), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize. -Nezapomeňte, že revize zaznamená snímek projektu, jak je obsažen v oblasti připravených změn. Vše, co jste nepřipravili k zapsání, zůstane ve stavu „změněno“ na vašem disku. Chcete-li i tyto soubory přidat do své historie, zapište další revizi. Pokaždé, když zapíšete revizi, nahrajete snímek svého projektu, k němuž se můžete později vrátit nebo ho můžete použít k srovnání. +Nezapomeňte, že revize zaznamená snímek projektu, jak je obsažen v oblasti připravených změn. Vše, co jste nepřipravili k zapsání, zůstane ve stavu změněno na vašem disku. Chcete-li i tyto soubory přidat do své historie, zapište další revizi. Pokaždé, když zapíšete revizi, nahrajete snímek svého projektu, k němuž se můžete později vrátit nebo ho můžete použít k srovnání. ### Přeskočení oblasti připravených změn ### -Přestože může být oblast připravených změn opravdu užitečným nástrojem pro přesné vytváření revizí, je někdy při daném pracovním postupu zbytečným mezikrokem. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu `git commit` parametr `-a`, Git do revize automaticky zahrne každý soubor, který je sledován. Zcela tak odpadá potřeba zadávat příkaz `git add`: +Přestože může být oblast připravených změn opravdu užitečným nástrojem pro přesné vytváření revizí, je někdy při daném pracovním postupu zbytečným mezikrokem. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu `git commit` parametr `-a`, Git do revize automaticky zahrne každý soubor, který je sledován. Odpadá potřeba zadávat příkaz `git add`: $ git status On branch master @@ -349,13 +349,13 @@ Přestože může být oblast připravených změn opravdu užitečným nástroj [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+) -Tímto způsobem není nutné provádět před zapsáním revize příkaz `git add` pro soubor `benchmarks.rb`. +Povšimněte si, že kvůli souboru `benchmarks.rb` v tomto případě nemusíte před zapsáním revize provádět příkaz `git add`. ### Odstraňování souborů ### Chcete-li odstranit soubor ze systému Git, musíte ho odstranit ze sledovaných souborů (přesněji řečeno odstranit z oblasti připravených změn) a zapsat revizi. Odstranění provedete příkazem `git rm`, který odstraní soubor zároveň z vašeho pracovního adresáře, a proto ho už příště neuvidíte mezi nesledovanými soubory. -Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve výpisu `git status` v části „Changes not staged for commit“ (tedy nepřipraveno): +Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve výpisu `git status` v části „Changes not staged for commit“ (tedy *nepřipraveno*): $ rm grit.gemspec $ git status @@ -380,7 +380,7 @@ Pokud nyní provedete příkaz `git rm`, bude k zapsání připraveno odstraněn deleted: grit.gemspec -Po příštím zapsání revize soubor zmizí a nebude sledován. Pokud už jste soubor upravili a přidali do indexu, musíte odstranění provést pomocí parametru `-f`. Jedná se o bezpečnostní funkci, jež má zabránit nechtěnému odstranění dat, která ještě nebyla nahrána do snímku, a nemohou proto být ze systému Git obnovena. +Po příštím zapsání revize soubor zmizí a přestane být sledován. Pokud už jste soubor upravili a přidali do indexu, musíte odstranění provést pomocí parametru `-f`. Jedná se o bezpečnostní funkci, jež má zabránit nechtěnému odstranění dat, která ještě nebyla nahrána do snímku, a nemohou proto být ze systému Git obnovena. Další užitečnou možností, která se vám může hodit, je zachování souboru v pracovním stromě a odstranění z oblasti připravených změn. Soubor tak ponecháte na svém pevném disku, ale ukončíte jeho sledování systémem Git. To může být užitečné zejména v situaci, kdy něco zapomenete přidat do souboru `.gitignore`, a omylem to tak zahrnete do revize, např. velký log soubor nebo pár zkompilovaných souborů s příponou `.a`. V takovém případě použijte parametr `--cached`: @@ -398,7 +398,7 @@ Tento příkaz odstraní všechny soubory, které končí vlnovkou (`~`). ### Přesouvání souborů ### -Na rozdíl od ostatních systémů VCS nesleduje Git explicitně přesouvání souborů. Pokud přejmenujete v systému Git soubor, neuloží se žádná metadata s informací, že jste soubor přejmenovali. Git však používá jinou fintu, aby zjistil, že byl soubor přejmenován. Na ni se podíváme později. +Na rozdíl od ostatních systémů pro správu verzí nesleduje Git explicitně přesouvání souborů. Pokud soubor v systému Git přejmenujete, neuloží se žádná metadata s informací, že jste soubor přejmenovali. Git však používá jinou fintu, aby zjistil, že byl soubor přejmenován. Na ni se podíváme později. Může se zdát zvláštní, že Git přesto používá příkaz `mv`. Chcete-li v systému Git přejmenovat soubor, můžete spustit třeba příkaz @@ -431,7 +431,7 @@ Následující příklady ukazují velmi jednoduchý projekt pojmenovaný `simpl git clone git://github.com/schacon/simplegit-progit.git -Po zadání příkazu `git log` v tomto projektu byste měli dostat výstup, který vypadá zhruba následovně: +Po zadání příkazu `git log` v tomto projektu byste měli dostat výstup, který vypadá zhruba takto: $ git log commit ca82a6dff817ec66f44342007202690a93763949 @@ -452,11 +452,11 @@ Po zadání příkazu `git log` v tomto projektu byste měli dostat výstup, kte first commit -Ve výchozím nastavení a bez dalších parametrů vypíše příkaz `git log` revize provedené v daném repozitáři v obráceném chronologickém pořadí. Nejnovější revize tak budou uvedeny nahoře. Jak vidíte, tento příkaz vypíše všechny revize s jejich kontrolním součtem SHA-1, jménem a e-mailem autora, datem zápisu a zprávou k revizi. +Ve výchozím nastavení a bez dalších parametrů vypíše příkaz `git log` revize provedené v daném repozitáři v obráceném chronologickém pořadí. Nejnovější revize tak budou uvedeny nahoře. Jak vidíte, tento příkaz vypíše všechny revize s jejich kontrolním součtem SHA-1, jménem a e-mailem autora, datem zápisu a zprávou o revizi. -K příkazu `git log` je k dispozici velké množství nejrůznějších parametrů, díky nimž můžete najít přesně to, co hledáte. Vyjmenujme některé z nejčastěji používaných parametrů. +K příkazu `git log` je k dispozici velké množství nejrůznějších parametrů, díky nimž můžete zobrazit přesně to, co potřebujete. Ukážeme si některé z nejpoužívanějších možností. -Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly diff provedené v každé revizi. Můžete také použít parametr `-2`, který omezí výpis pouze na dva poslední záznamy: +Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly (diff) provedené v každé revizi. Můžete také použít parametr `-2`, který omezí výpis pouze na dva poslední záznamy: $ git log -p -2 commit ca82a6dff817ec66f44342007202690a93763949 @@ -591,7 +591,7 @@ Tabulka 2-1 uvádí některé užitečné parametry, které format akceptuje. %cr Datum autora revize, relativní %s Předmět -Možná se ptáte, jaký je rozdíl mezi autorem a autorem revize. Autor je osoba, která práci původně napsala, zatímco autor revize je osoba, která práci zapsala do repozitáře. Pokud tedy pošlete záplatu k projektu a některý z ústředních členů (core members) ji použije, do výpisu se dostanete oba – vy jako autor a core member jako autor revize. K tomuto rozlišení se blíže dostaneme v kapitole 5. +Možná se ptáte, jaký je rozdíl mezi *autorem* a *autorem revize*. *Autor* (author) je osoba, která práci původně napsala, zatímco *autor revize* (committer) je osoba, která práci zapsala do repozitáře. Pokud tedy pošlete záplatu k projektu a některý z ústředních členů (core members) ji použije, do výpisu se dostanete oba – vy jako autor a core member jako autor revize. K tomuto rozlišení se blíže dostaneme v *kapitole 5*. Parametry `oneline` a `format` jsou zvlášť užitečné ve spojení s další možností `log`u – parametrem `--graph`. Tento parametr vloží pěkný malý ASCII graf, znázorňující historii vaší větve a slučování, kterou si ukážeme na naší kopii repozitáře projektu Grit: @@ -695,7 +695,7 @@ K dalším užitečným formátům patří `--date=iso` (ISO 8601), `--date=rfc` Pokud použijete příkaz `git log` bez určení času, uvažuje se čas odpovídající okamžiku spuštění na vašem počítači (používá stejný posun vůči UTC). -Pokud například na vašem počítači spustíte `git log` v 09:00 a vaše časové pásmo je vůči greenwichskému času posunut o tři hodiny vpřed, pak se výsledek následujících dvou příkazů shoduje: +Pokud například na vašem počítači spustíte `git log` v 09:00 a vaše časové pásmo je vůči greenwichskému času posunuto o tři hodiny vpřed, pak se výsledek následujících dvou příkazů shoduje: $ git log --after=2008-06-01 --before=2008-07-01 $ git log --after="2008-06-01T09:00:00+0300" \ From 9efccf9f2876ee04e88515b8fb24e27e44c8f733 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Mon, 4 Aug 2014 19:27:01 +0200 Subject: [PATCH 143/291] no-NB trans Chapter 2 Getting repository + 1 sub --- no-nb/02-git-basics/01-chapter2.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown index b8642eb2e..bb023a44f 100644 --- a/no-nb/02-git-basics/01-chapter2.markdown +++ b/no-nb/02-git-basics/01-chapter2.markdown @@ -2,25 +2,25 @@ Om du bare kan lese et kapitel for å komme i gang med Git, så er dette det kapitelet. Dette kapitellet dekker hver grunnlegende kommando du trenger for å gjøre største delen av ting du etterhvert vil bruke tiden din på å gjøre i Git. Ved slutten av dette kapitelet, så burde du være istand til å konfigurere og initiere et repository, begynne og stoppe overvåking av filer, og stage og commite endringer. Vi vil også vise deg hvordan sette opp Git til å ignorere visse filer og filmønstre, hvordan angre på feil fort og enkelt, hvordan se gjennom historien for prosjektet ditt og se på endringer mellom commiter, og hvordan pushe(dytte) endringer til eller pulle(dra) endringer fra en fjern repository. -## Getting a Git Repository ## +## Skaffe seg et Git Repository ## -You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server. +Du kan skaffe deg et Git prosjekt ved å bruke to hovedframganger. Den første tar et eksisterende prosjekt eller mappe og importerer det inn i Git. Den andre kloner et eksisterende Git repository fra en annen server. -### Initializing a Repository in an Existing Directory ### +### Initere et Repository i en Eksisterende Mappe ### -If you’re starting to track an existing project in Git, you need to go to the project’s directory and type +Om du begynner å spore et eksisterende prosjekt i Git, så trenger du å gå inn i projektets mappe og skrive $ git init -This creates a new subdirectory named `.git` that contains all of your necessary repository files — a Git repository skeleton. At this point, nothing in your project is tracked yet. (See *Chapter 9* for more information about exactly what files are contained in the `.git` directory you just created.) +Dette lager en ny undermappe kalt `.git` som inneholder alle dine nødvendige repository filer – et Git repository skjellet. På dette tidspunktet, så er ingenting i prosjektet ditt overvåket enda. (See *Kapitel 9* for mer informasjon om nøyaktig hvile filer som finnes i `.git`mappen du akkurat lagde.) -If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a commit: +Om du ønsker å starte versjonkontroll på eksisterende filer (imotsetning til en tom mappe), så burde du sannsynligvis begynne å overvåke de filene og gjøre en første commit. Du kan gjøre det med noen få `git add` kommandoer som spesifiserer filene du ønsker å overvåke, fulgt med en commit: $ git add *.c $ git add README $ git commit -m 'initial project version' -We’ll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit. +Vi vil gæ over hva disse kommandoene gjør straks. Nå har du et Git repository med overvåkedne filer og en første kommit. ### Cloning an Existing Repository ### From ca3f3de73aa1303ba9f1afb1197e2cc6d8b2654e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Mon, 4 Aug 2014 23:34:17 +0200 Subject: [PATCH 144/291] no-NB updated the non-translated text to newer rev --- no-nb/02-git-basics/01-chapter2.markdown | 445 +++++++++++------- no-nb/03-git-branching/01-chapter3.markdown | 200 ++++---- no-nb/04-git-server/01-chapter4.markdown | 221 ++++----- no-nb/05-distributed-git/01-chapter5.markdown | 47 +- no-nb/06-git-tools/01-chapter6.markdown | 84 ++-- no-nb/07-customizing-git/01-chapter7.markdown | 129 +++-- .../01-chapter8.markdown | 53 +-- no-nb/09-git-internals/01-chapter9.markdown | 84 ++-- 8 files changed, 690 insertions(+), 573 deletions(-) diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown index bb023a44f..04d6eb7a3 100644 --- a/no-nb/02-git-basics/01-chapter2.markdown +++ b/no-nb/02-git-basics/01-chapter2.markdown @@ -54,39 +54,40 @@ Figure 2-1. The lifecycle of the status of your files. The main tool you use to determine which files are in which state is the `git status` command. If you run this command directly after a clone, you should see something like this: $ git status - # On branch master + On branch master nothing to commit, working directory clean -This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. +This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. -Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so: +Let’s say you add a new file to your project, a simple `README` file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so: $ vim README $ git status - # On branch master - # Untracked files: - # (use "git add ..." to include in what will be committed) - # - # README + On branch master + Untracked files: + (use "git add ..." to include in what will be committed) + + README + nothing added to commit but untracked files present (use "git add" to track) -You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file. +You can see that your new `README` file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file. ### Tracking New Files ### -In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this: +In order to begin tracking a new file, you use the command `git add`. To begin tracking the `README` file, you can run this: $ git add README -If you run your status command again, you can see that your README file is now tracked and staged: +If you run your status command again, you can see that your `README` file is now tracked and staged: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. You may recall that when you ran `git init` earlier, you then ran `git add (files)` — that was to begin tracking files in your directory. The `git add` command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively. @@ -95,58 +96,60 @@ You can tell that it’s staged because it’s under the “Changes to be commit Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + The `benchmarks.rb` file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the `benchmarks.rb` file, and then run `git status` again: $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in `benchmarks.rb` before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time: $ vim benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + What the heck? Now `benchmarks.rb` is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the `git add` command. If you commit now, the version of `benchmarks.rb` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + modified: benchmarks.rb + ### Ignoring Files ### @@ -180,6 +183,10 @@ Here is another example `.gitignore` file: build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt + # ignore all .txt files in the doc/ directory + doc/**/*.txt + +A `**/` pattern is available in Git since version 1.8.2. ### Viewing Your Staged and Unstaged Changes ### @@ -188,17 +195,18 @@ If the `git status` command is too vague for you — you want to know exactly wh Let’s say you edit and stage the `README` file again and then edit the `benchmarks.rb` file without staging it. If you run your `status` command, you once again see something like this: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: README - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: README + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + To see what you’ve changed but not yet staged, type `git diff` with no other arguments: @@ -243,16 +251,18 @@ For another example, if you stage the `benchmarks.rb` file and then edit it, you $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status - # On branch master - # - # Changes to be committed: - # - # modified: benchmarks.rb - # - # Changes not staged for commit: - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Now you can use `git diff` to see what is still unstaged @@ -301,10 +311,9 @@ The editor displays the following text (this example is a Vim screen): # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # # new file: README # modified: benchmarks.rb + # ~ ~ ~ @@ -315,8 +324,8 @@ You can see that the default commit message contains the latest output of the `g Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: $ git commit -m "Story 182: Fix benchmarks for speed" - [master]: created 463dc4f: "Fix benchmarks for speed" - 2 files changed, 3 insertions(+), 0 deletions(-) + [master 463dc4f] Story 182: Fix benchmarks for speed + 2 files changed, 3 insertions(+) create mode 100644 README Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. @@ -328,15 +337,17 @@ Remember that the commit records the snapshot you set up in your staging area. A Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: $ git status - # On branch master - # - # Changes not staged for commit: - # - # modified: benchmarks.rb - # + On branch master + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + + no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks - 1 files changed, 5 insertions(+), 0 deletions(-) + 1 files changed, 5 insertions(+) Notice how you don’t have to run `git add` on the `benchmarks.rb` file in this case before you commit. @@ -348,30 +359,30 @@ If you simply remove the file from your working directory, it shows up under the $ rm grit.gemspec $ git status - # On branch master - # - # Changes not staged for commit: - # (use "git add/rm ..." to update what will be committed) - # - # deleted: grit.gemspec - # + On branch master + Changes not staged for commit: + (use "git add/rm ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + deleted: grit.gemspec + + no changes added to commit (use "git add" and/or "git commit -a") Then, if you run `git rm`, it stages the file’s removal: $ git rm grit.gemspec rm 'grit.gemspec' $ git status - # On branch master - # - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # deleted: grit.gemspec - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + deleted: grit.gemspec + The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option: +Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option: $ git rm --cached readme.txt @@ -379,7 +390,7 @@ You can pass files, directories, and file-glob patterns to the `git rm` command. $ git rm log/\*.log -Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this: +Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. On Windows with the system console, the backslash must be omitted. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this: $ git rm \*~ @@ -395,22 +406,20 @@ Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file: - $ git mv README.txt README + $ git mv README README.txt $ git status - # On branch master - # Your branch is ahead of 'origin/master' by 1 commit. - # - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # renamed: README.txt -> README - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + renamed: README -> README.txt + However, this is equivalent to running something like this: - $ mv README.txt README - $ git rm README.txt - $ git add README + $ mv README README.txt + $ git rm README + $ git add README.txt Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. @@ -460,11 +469,13 @@ One of the more helpful options is `-p`, which shows the diff introduced in each index a874b73..8f94139 100644 --- a/Rakefile +++ b/Rakefile - @@ -5,7 +5,7 @@ require 'rake/gempackagetask' + @@ -5,5 +5,5 @@ require 'rake/gempackagetask' spec = Gem::Specification.new do |s| + s.name = "simplegit" - s.version = "0.1.0" + s.version = "0.1.1" s.author = "Scott Chacon" + s.email = "schacon@gee-mail.com commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon @@ -488,6 +499,27 @@ One of the more helpful options is `-p`, which shows the diff introduced in each \ No newline at end of file This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. + +Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example: + + $ git log -U1 --word-diff + commit ca82a6dff817ec66f44342007202690a93763949 + Author: Scott Chacon + Date: Mon Mar 17 21:52:11 2008 -0700 + + changed the version number + + diff --git a/Rakefile b/Rakefile + index a874b73..8f94139 100644 + --- a/Rakefile + +++ b/Rakefile + @@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s| + s.name = "simplegit" + s.version = [-"0.1.0"-]{+"0.1.1"+} + s.author = "Scott Chacon" + +As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above. + You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: $ git log --stat @@ -498,7 +530,7 @@ You can also use a series of summarizing options with `git log`. For example, if changed the version number Rakefile | 2 +- - 1 files changed, 1 insertions(+), 1 deletions(-) + 1 file changed, 1 insertion(+), 1 deletion(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon @@ -507,7 +539,7 @@ You can also use a series of summarizing options with `git log`. For example, if removed unnecessary test code lib/simplegit.rb | 5 ----- - 1 files changed, 0 insertions(+), 5 deletions(-) + 1 file changed, 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon @@ -518,7 +550,7 @@ You can also use a series of summarizing options with `git log`. For example, if README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ lib/simplegit.rb | 25 +++++++++++++++++++++++++ - 3 files changed, 54 insertions(+), 0 deletions(-) + 3 files changed, 54 insertions(+) As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end. Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: @@ -537,6 +569,11 @@ The most interesting option is `format`, which allows you to specify your own lo Table 2-1 lists some of the more useful options that format takes. + + Option Description of Output %H Commit hash %h Abbreviated commit hash @@ -546,7 +583,7 @@ Table 2-1 lists some of the more useful options that format takes. %p Abbreviated parent hashes %an Author name %ae Author e-mail - %ad Author date (format respects the –date= option) + %ad Author date (format respects the --date= option) %ar Author date, relative %cn Committer name %ce Committer email @@ -556,7 +593,7 @@ Table 2-1 lists some of the more useful options that format takes. You may be wondering what the difference is between _author_ and _committer_. The _author_ is the person who originally wrote the patch, whereas the _committer_ is the person who last applied the patch. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in *Chapter 5*. -The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository: +The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see in our copy of the Grit project repository: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap @@ -570,10 +607,16 @@ The `oneline` and `format` options are particularly useful with another `log` op * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local -Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command. +Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the `log` command. + + Option Description -p Show the patch introduced with each commit. + --word-diff Show the patch in a word diff format. --stat Show statistics for files modified in each commit. --shortstat Display only the changed/insertions/deletions line from the --stat command. --name-only Show the list of files modified after the commit information. @@ -582,10 +625,11 @@ Those are only some simple output-formatting options to `git log` — there are --relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format. --graph Display an ASCII graph of the branch and merge history beside the log output. --pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). + --oneline A convenience option short for `--pretty=oneline --abbrev-commit`. ### Limiting Log Output ### -In addition to output-formatting options, `git log` takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which show only the last two commits. In fact, you can do `-`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +In addition to output-formatting options, `git log` takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which shows only the last two commits. In fact, you can do `-`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks: @@ -593,23 +637,75 @@ However, the time-limiting options such as `--since` and `--until` are very usef This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”. -You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) +You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you specify both author and grep options, the command will match commits with both.) + +If you want to specify multiple grep options, you have to add `--all-match` or the command will match commits with either. The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. In Table 2-3 we’ll list these and a few other common options for your reference. + + Option Description -(n) Show only the last n commits - --since, --after Limit the commits to those made after the specified date. - --until, --before Limit the commits to those made before the specified date. + --since, --after Limit the commits to those whose CommitDate was made on-or-after the specified date/time. + --until, --before Limit the commits to those whose CommitDate was made on-or-before the specified date/time. --author Only show commits in which the author entry matches the specified string. --committer Only show commits in which the committer entry matches the specified string. -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this: - $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ - --before="2008-11-01" --no-merges -- t/ +### Limiting Log Output according to Date/Time ### + +To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone (as set on your computer), use + + $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \ + --pretty=fuller + +As the output will be different according to the timezone where it will be run, it's recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. + +To obtain commits made at a specific instant in time (e.g. 29 April 2013 at 17:07:22 CET), we can use + + $ git log --after="2013-04-29T17:07:22+0200" \ + --before="2013-04-29T17:07:22+0200" --pretty=fuller + + commit de7c201a10857e5d424dbd8db880a6f24ba250f9 + Author: Ramkumar Ramachandra + AuthorDate: Mon Apr 29 18:19:37 2013 +0530 + Commit: Junio C Hamano + CommitDate: Mon Apr 29 08:07:22 2013 -0700 + + git-completion.bash: lexical sorting for diff.statGraphWidth + + df44483a (diff --stat: add config option to limit graph width, + 2012-03-01) added the option diff.startGraphWidth to the list of + configuration variables in git-completion.bash, but failed to notice + that the list is sorted alphabetically. Move it to its rightful place + in the list. + + Signed-off-by: Ramkumar Ramachandra + Signed-off-by: Junio C Hamano + +The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`--date=default`), which shows timezone information of respective author and commiter. + +Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) `--date=local` (times according to your local timezone) as well as `--date=relative` (e.g. "2 hours ago"). + +When using `git log` without specifying time, the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). + +For example, running a `git log` at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, makes the following two commands equivalent: + + $ git log --after=2008-06-01 --before=2008-07-01 + $ git log --after="2008-06-01T09:00:00+0300" \ + --before="2008-07-01T09:00:00+0300" + +As a final example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this: + + $ git log --pretty="%h - %s" --author=gitster \ + --after="2008-10-01T00:00:00-0400" \ + --before="2008-10-31T23:59:59-0400" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi @@ -617,7 +713,7 @@ For example, if you want to see which commits modifying test files in the Git so 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria. +Of the more than 36,000 commits in the Git source code history, this command shows the 6 that match those criteria. ### Using a GUI to Visualize History ### @@ -656,31 +752,32 @@ The next two sections demonstrate how to wrangle your staging area and working d $ git add . $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + modified: benchmarks.rb + Right below the “Changes to be committed” text, it says "use `git reset HEAD ...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file: $ git reset HEAD benchmarks.rb - benchmarks.rb: locally modified + Unstaged changes after reset: + M benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged. @@ -688,23 +785,23 @@ The command is a bit strange, but it works. The `benchmarks.rb` file is modified What if you realize that you don’t want to keep your changes to the `benchmarks.rb` file? How can you easily unmodify it — revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, `git status` tells you how to do that, too. In the last example output, the unstaged area looks like this: - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # modified: benchmarks.rb - # + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do this — if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says: $ git checkout -- benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: README.txt - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: README.txt + You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go. @@ -720,12 +817,12 @@ Managing remote repositories includes knowing how to add remote repositories, re To see which remote servers you have configured, you can run the `git remote` command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see *origin* — that is the default name Git gives to the server you cloned from: $ git clone git://github.com/schacon/ticgit.git - Initialized empty Git repository in /private/tmp/ticgit/.git/ - remote: Counting objects: 595, done. - remote: Compressing objects: 100% (269/269), done. - remote: Total 595 (delta 255), reused 589 (delta 253) - Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done. - Resolving deltas: 100% (255/255), done. + Cloning into 'ticgit'... + remote: Reusing existing pack: 1857, done. + remote: Total 1857 (delta 0), reused 0 (delta 0) + Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done. + Resolving deltas: 100% (772/772), done. + Checking connectivity... done. $ cd ticgit $ git remote origin @@ -733,7 +830,8 @@ To see which remote servers you have configured, you can run the `git remote` co You can also specify `-v`, which shows you the URL that Git has stored for the shortname to be expanded to: $ git remote -v - origin git://github.com/schacon/ticgit.git + origin git://github.com/schacon/ticgit.git (fetch) + origin git://github.com/schacon/ticgit.git (push) If you have more than one remote, the command lists them all. For example, my Grit repository looks something like this. @@ -745,7 +843,7 @@ If you have more than one remote, the command lists them all. For example, my Gr koke git://github.com/koke/grit.git origin git@github.com:mojombo/grit.git -This means we can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it’s the only one I can push to (we’ll cover why this is in *Chapter 4*). +This means I can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it’s the only one I can push to (we’ll cover why this is in *Chapter 4*). ### Adding Remote Repositories ### @@ -758,7 +856,7 @@ I’ve mentioned and given some demonstrations of adding remote repositories in origin git://github.com/schacon/ticgit.git pb git://github.com/paulboone/ticgit.git -Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run git fetch pb: +Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run `git fetch pb`: $ git fetch pb remote: Counting objects: 58, done. @@ -895,6 +993,7 @@ You can see the tag data along with the commit that was tagged by using the `git Date: Mon Feb 9 14:45:11 2009 -0800 my version 1.4 + commit 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon @@ -1001,7 +1100,7 @@ You can also tag commits after you’ve moved past them. Suppose your commit his Now, suppose you forgot to tag the project at `v1.2`, which was at the "updated rakefile" commit. You can add it after the fact. To tag that commit, you specify the commit checksum (or part of it) at the end of the command: - $ git tag -a v1.2 9fceb02 + $ git tag -a v1.2 -m 'version 1.2' 9fceb02 You can see that you’ve tagged the commit: @@ -1060,9 +1159,9 @@ Before we finish this chapter on basic Git, a few little tips and tricks may mak ### Auto-Completion ### -If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download the Git source code, and look in the `contrib/completion` directory; there should be a file called `git-completion.bash`. Copy this file to your home directory, and add this to your `.bashrc` file: +If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download it directly from the Git source code at https://github.com/git/git/blob/master/contrib/completion/git-completion.bash . Copy this file to your home directory, and add this to your `.bashrc` file: - source ~/.git-completion.bash + source ~/git-completion.bash If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the `/opt/local/etc/bash_completion.d` directory on Mac systems or to the `/etc/bash_completion.d/` directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions. diff --git a/no-nb/03-git-branching/01-chapter3.markdown b/no-nb/03-git-branching/01-chapter3.markdown index de57576f7..adf1995d1 100644 --- a/no-nb/03-git-branching/01-chapter3.markdown +++ b/no-nb/03-git-branching/01-chapter3.markdown @@ -15,21 +15,21 @@ To visualize this, let’s assume that you have a directory containing three fil $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' -When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed. +Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed. Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1. -Insert 18333fig0301.png +Insert 18333fig0301.png Figure 3-1. Single commit repository data. If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3-2. -Insert 18333fig0302.png +Insert 18333fig0302.png Figure 3-2. Git object data for multiple commits. -A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically. +A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, it moves forward automatically. -Insert 18333fig0303.png +Insert 18333fig0303.png Figure 3-3. Branch pointing into the commit data’s history. What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command: @@ -38,12 +38,12 @@ What happens if you create a new branch? Well, doing so creates a new pointer fo This creates a new pointer at the same commit you’re currently on (see Figure 3-4). -Insert 18333fig0304.png +Insert 18333fig0304.png Figure 3-4. Multiple branches pointing into the commit’s data history. -How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5). +How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The `git branch` command only created a new branch — it didn’t switch to that branch (see Figure 3-5). -Insert 18333fig0305.png +Insert 18333fig0305.png Figure 3-5. HEAD file pointing to the branch you’re on. To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch: @@ -62,19 +62,19 @@ What is the significance of that? Well, let’s do another commit: Figure 3-7 illustrates the result. -Insert 18333fig0307.png +Insert 18333fig0307.png Figure 3-7. The branch that HEAD points to moves forward with each commit. -This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the master branch: +This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch: $ git checkout master Figure 3-8 shows the result. -Insert 18333fig0308.png +Insert 18333fig0308.png Figure 3-8. HEAD moves to another branch on a checkout. -That command did two things. It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction. +That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction. Let’s make a few changes and commit again: @@ -83,7 +83,7 @@ Let’s make a few changes and commit again: Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands. -Insert 18333fig0309.png +Insert 18333fig0309.png Figure 3-9. The branch histories have diverged. Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). @@ -102,7 +102,7 @@ Let’s go through a simple example of branching and merging with a workflow tha At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: -1. Revert back to your production branch. +1. Switch back to your production branch. 2. Create a branch to add the hotfix. 3. After it’s tested, merge the hotfix branch, and push to production. 4. Switch back to your original story and continue working. @@ -111,13 +111,13 @@ At this stage, you’ll receive a call that another issue is critical and you ne First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10). -Insert 18333fig0310.png +Insert 18333fig0310.png Figure 3-10. A short and simple commit history. You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: $ git checkout -b iss53 - Switched to a new branch "iss53" + Switched to a new branch 'iss53' This is shorthand for: @@ -126,7 +126,7 @@ This is shorthand for: Figure 3-11 illustrates the result. -Insert 18333fig0311.png +Insert 18333fig0311.png Figure 3-11. Creating a new branch pointer. You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12): @@ -134,7 +134,7 @@ You work on your web site and do some commits. Doing so moves the `iss53` branch $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' -Insert 18333fig0312.png +Insert 18333fig0312.png Figure 3-12. The iss53 branch has moved forward with your work. Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch. @@ -142,20 +142,20 @@ Now you get the call that there is an issue with the web site, and you need to f However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch: $ git checkout master - Switched to branch "master" + Switched to branch 'master' At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13): - $ git checkout -b 'hotfix' - Switched to a new branch "hotfix" + $ git checkout -b hotfix + Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'fixed the broken email address' - [hotfix]: created 3a0874c: "fixed the broken email address" - 1 files changed, 0 insertions(+), 1 deletions(-) + [hotfix 3a0874c] fixed the broken email address + 1 files changed, 1 deletion(-) -Insert 18333fig0313.png +Insert 18333fig0313.png Figure 3-13. hotfix branch based back at your master branch point. You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command: @@ -163,32 +163,32 @@ You can run your tests, make sure the hotfix is what you want, and merge it back $ git checkout master $ git merge hotfix Updating f42c576..3a0874c - Fast forward - README | 1 - - 1 files changed, 0 insertions(+), 1 deletions(-) + Fast-forward + README | 1 - + 1 file changed, 1 deletion(-) -You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward". +You’ll notice the phrase "Fast-forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward". Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14). -Insert 18333fig0314.png +Insert 18333fig0314.png Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge. After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`: $ git branch -d hotfix - Deleted branch hotfix (3a0874c). + Deleted branch hotfix (was 3a0874c). Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15): $ git checkout iss53 - Switched to branch "iss53" + Switched to branch 'iss53' $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' - [iss53]: created ad82d7a: "finished the new footer [issue 53]" - 1 files changed, 1 insertions(+), 0 deletions(-) + [iss53 ad82d7a] finished the new footer [issue 53] + 1 file changed, 1 insertion(+) -Insert 18333fig0315.png +Insert 18333fig0315.png Figure 3-15. Your iss53 branch can move forward independently. It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. @@ -199,20 +199,21 @@ Suppose you’ve decided that your issue #53 work is complete and ready to be me $ git checkout master $ git merge iss53 - Merge made by recursive. - README | 1 + - 1 files changed, 1 insertions(+), 0 deletions(-) + Auto-merging README + Merge made by the 'recursive' strategy. + README | 1 + + 1 file changed, 1 insertion(+) This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case. -Insert 18333fig0316.png +Insert 18333fig0316.png Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging. Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent. It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems. -Insert 18333fig0317.png +Insert 18333fig0317.png Figure 3-17. Git automatically creates a new commit object that contains the merged work. Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system: @@ -230,25 +231,27 @@ Occasionally, this process doesn’t go smoothly. If you changed the same part o Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: - [master*]$ git status - index.html: needs merge - # On branch master - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # (use "git checkout -- ..." to discard changes in working directory) - # - # unmerged: index.html - # + $ git status + On branch master + You have unmerged paths. + (fix conflicts and run "git commit") + + Unmerged paths: + (use "git add ..." to mark resolution) + + both modified: index.html + + no changes added to commit (use "git add" and/or "git commit -a") Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this: - <<<<<<< HEAD:index.html + <<<<<<< HEAD ======= - >>>>>>> iss53:index.html + >>>>>>> iss53 This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: @@ -260,27 +263,32 @@ This resolution has a little of each section, and I’ve fully removed the `<<<< If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts: $ git mergetool - merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff - Merging the files: index.html + + This message is displayed because 'merge.tool' is not configured. + See 'git mergetool --tool-help' or 'git help config' for more details. + 'git mergetool' will now attempt to use one of the following tools: + opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge + Merging: + index.html Normal merge conflict for 'index.html': - {local}: modified - {remote}: modified + {local}: modified file + {remote}: modified file Hit return to start merge resolution tool (opendiff): -If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment. +If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment. After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run `git status` again to verify that all conflicts have been resolved: $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # modified: index.html - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + modified: index.html + If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this: @@ -289,9 +297,9 @@ If you’re happy with that, and you verify that everything that had conflicts h Conflicts: index.html # - # It looks like you may be committing a MERGE. + # It looks like you may be committing a merge. # If this is not correct, please remove the file - # .git/MERGE_HEAD + # .git/MERGE_HEAD # and try again. # @@ -315,7 +323,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes -Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`: +Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`: $ git branch --merged iss53 @@ -331,7 +339,7 @@ To see all the branches that contain work you haven’t yet merged in, you can r This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail: $ git branch -d testing - error: The branch 'testing' is not an ancestor of your current HEAD. + error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out. @@ -348,12 +356,12 @@ Many Git developers have a workflow that embraces this approach, such as having In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18). -Insert 18333fig0318.png +Insert 18333fig0318.png Figure 3-18. More stable branches are generally farther down the commit history. It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19). -Insert 18333fig0319.png +Insert 18333fig0319.png Figure 3-19. It may be helpful to think of your branches as silos. You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them. @@ -367,12 +375,12 @@ You saw this in the last section with the `iss53` and `hotfix` branches you crea Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20. -Insert 18333fig0320.png +Insert 18333fig0320.png Figure 3-20. Your commit history with multiple topic branches. Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21. -Insert 18333fig0321.png +Insert 18333fig0321.png Figure 3-21. Your history after merging in dumbidea and iss91v2. It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening. @@ -385,27 +393,27 @@ They take the form `(remote)/(branch)`. For instance, if you wanted to see what This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22). -Insert 18333fig0322.png +Insert 18333fig0322.png Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch. If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23). -Insert 18333fig0323.png +Insert 18333fig0323.png Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently. To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24). -Insert 18333fig0324.png -Figure 3-24. The git fetch command updates your remote references. +Insert 18333fig0324.png +Figure 3-24. The `git fetch` command updates your remote references. To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25). -Insert 18333fig0325.png +Insert 18333fig0325.png Figure 3-25. Adding another server as a remote. -Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server is a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26). +Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26). -Insert 18333fig0326.png +Insert 18333fig0326.png Figure 3-26. You get a reference to teamone’s master branch position locally. ### Pushing ### @@ -439,8 +447,8 @@ It’s important to note that when you do a fetch that brings down new remote br To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch: $ git checkout -b serverfix origin/serverfix - Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. - Switched to a new branch "serverfix" + Branch serverfix set up to track remote branch serverfix from origin. + Switched to a new branch 'serverfix' This gives you a local branch that you can work on that starts where `origin/serverfix` is. @@ -451,16 +459,16 @@ Checking out a local branch from a remote branch automatically creates what is c When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand: $ git checkout --track origin/serverfix - Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. - Switched to a new branch "serverfix" + Branch serverfix set up to track remote branch serverfix from origin. + Switched to a new branch 'serverfix' To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name: $ git checkout -b sf origin/serverfix - Branch sf set up to track remote branch refs/remotes/origin/serverfix. - Switched to a new branch "sf" + Branch sf set up to track remote branch serverfix from origin. + Switched to a new branch 'sf' -Now, your local branch sf will automatically push to and pull from origin/serverfix. +Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`. ### Deleting Remote Branches ### @@ -480,12 +488,12 @@ In Git, there are two main ways to integrate changes from one branch into anothe If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches. -Insert 18333fig0327.png +Insert 18333fig0327.png Figure 3-27. Your initial diverged commit history. The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28. -Insert 18333fig0328.png +Insert 18333fig0328.png Figure 3-28. Merging a branch to integrate the diverged work history. However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one. @@ -499,12 +507,12 @@ In this example, you’d run the following: It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process. -Insert 18333fig0329.png +Insert 18333fig0329.png Figure 3-29. Rebasing the change introduced in C3 onto C4. At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30). -Insert 18333fig0330.png +Insert 18333fig0330.png Figure 3-30. Fast-forwarding the master branch. Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. @@ -517,7 +525,7 @@ Note that the snapshot pointed to by the final commit you end up with, whether i You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits. -Insert 18333fig0331.png +Insert 18333fig0331.png Figure 3-31. A history with a topic branch off another topic branch. Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`: @@ -526,7 +534,7 @@ Suppose you decide that you want to merge your client-side changes into your mai This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool. -Insert 18333fig0332.png +Insert 18333fig0332.png Figure 3-32. Rebasing a topic branch off another topic branch. Now you can fast-forward your master branch (see Figure 3-33): @@ -534,7 +542,7 @@ Now you can fast-forward your master branch (see Figure 3-33): $ git checkout master $ git merge client -Insert 18333fig0333.png +Insert 18333fig0333.png Figure 3-33. Fast-forwarding your master branch to include the client branch changes. Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`): @@ -543,7 +551,7 @@ Let’s say you decide to pull in your server branch as well. You can rebase the This replays your `server` work on top of your `master` work, as shown in Figure 3-34. -Insert 18333fig0334.png +Insert 18333fig0334.png Figure 3-34. Rebasing your server branch on top of your master branch. Then, you can fast-forward the base branch (`master`): @@ -556,7 +564,7 @@ You can remove the `client` and `server` branches because all the work is integr $ git branch -d client $ git branch -d server -Insert 18333fig0335.png +Insert 18333fig0335.png Figure 3-35. Final commit history. ### The Perils of Rebasing ### @@ -571,22 +579,22 @@ When you rebase stuff, you’re abandoning existing commits and creating new one Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36. -Insert 18333fig0336.png +Insert 18333fig0336.png Figure 3-36. Clone a repository, and base some work on it. Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37. -Insert 18333fig0337.png +Insert 18333fig0337.png Figure 3-37. Fetch more commits, and merge them into your work. Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits. -Insert 18333fig0338.png +Insert 18333fig0338.png Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on. At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39). -Insert 18333fig0339.png +Insert 18333fig0339.png Figure 3-39. You merge in the same work again into a new merge commit. You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people. diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown index 4c9639ff6..a52ba5361 100644 --- a/no-nb/04-git-server/01-chapter4.markdown +++ b/no-nb/04-git-server/01-chapter4.markdown @@ -26,7 +26,7 @@ Or you can do this: $ git clone file:///opt/git/project.git -Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster. +Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, and the source and the destination are on the same filesystem, Git tries to hardlink the objects it needs. If they are not on the same filesystem, it will copy the objects it needs using the system's standard copying functionality. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster. To add a local repository to an existing Git project, you can run something like this: @@ -55,7 +55,7 @@ To clone a Git repository over SSH, you can specify ssh:// URL like this: $ git clone ssh://user@server/project.git Or you can use the shorter scp-like syntax for SSH protocol: - + $ git clone user@server:project.git You can also not specify a user, and Git assumes the user you’re currently logged in as. @@ -117,9 +117,10 @@ In order to initially set up any Git server, you have to export an existing repo In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option. By convention, bare repository directories end in `.git`, like so: $ git clone --bare my_project my_project.git - Initialized empty Git repository in /opt/projects/my_project.git/ + Cloning into bare repository 'my_project.git'... + done. -The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory. +You should now have a copy of the Git directory data in your `my_project.git` directory. This is roughly equivalent to something like @@ -177,11 +178,11 @@ First, you should check to make sure you don’t already have a key. By default, You’re looking for a pair of files named something and something.pub, where the something is usually `id_dsa` or `id_rsa`. The `.pub` file is your public key, and the other file is your private key. If you don’t have these files (or you don’t even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows: - $ ssh-keygen + $ ssh-keygen Generating public/private rsa key pair. - Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): - Enter passphrase (empty for no passphrase): - Enter same passphrase again: + Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): + Enter passphrase (empty for no passphrase): + Enter same passphrase again: Your identification has been saved in /Users/schacon/.ssh/id_rsa. Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. The key fingerprint is: @@ -191,7 +192,7 @@ First it confirms where you want to save the key (`.ssh/id_rsa`), and then it as Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). All they have to do is copy the contents of the `.pub` file and e-mail it. The public keys look something like this: - $ cat ~/.ssh/id_rsa.pub + $ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA @@ -246,6 +247,7 @@ Then, John, Josie, or Jessica can push the first version of their project into t At this point, the others can clone it down and push changes back up just as easily: $ git clone git@gitserver:/opt/git/project.git + $ cd project $ vim README $ git commit -am 'fix for the README file' $ git push origin master @@ -282,12 +284,17 @@ First you need to enable the hook: $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update -If you’re using a version of Git earlier than 1.6, the `mv` command isn’t necessary — Git started naming the hooks examples with the .sample postfix only recently. - What does this `post-update` hook do? It looks basically like this: - $ cat .git/hooks/post-update + $ cat .git/hooks/post-update #!/bin/sh + # + # An example hook script to prepare a packed repository for use over + # dumb transports. + # + # To enable this hook, rename this file to "post-update". + # + exec git-update-server-info This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching. @@ -317,7 +324,7 @@ This way, you can set up HTTP-based read access to any of your projects for a fa Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1). -Insert 18333fig0401.png +Insert 18333fig0401.png Figure 4-1. The GitWeb web-based user interface. If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option. @@ -335,7 +342,7 @@ If you want to run the web interface on a server all the time for your team or f $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/ $ make GITWEB_PROJECTROOT="/opt/git" \ - prefix=/usr gitweb/gitweb.cgi + prefix=/usr gitweb $ sudo cp -Rf gitweb /var/www/ Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: @@ -403,7 +410,7 @@ You’re ready to roll. If you’re set up correctly, you can try to SSH into yo $ ssh git@gitserver PTY allocation request failed on channel 0 - fatal: unrecognized command 'gitosis-serve schacon@quaternion' + ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. Connection to gitserver closed. That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository: @@ -423,32 +430,32 @@ The `gitosis.conf` file is the control file you use to specify users, repositori If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned: - $ cat gitosis.conf + $ cat gitosis.conf [gitosis] [group gitosis-admin] - writable = gitosis-admin members = scott + writable = gitosis-admin It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project. Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on: [group mobile] - writable = iphone_project members = scott + writable = iphone_project Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect: $ git commit -am 'add iphone_project and mobile group' - [master]: created 8962da8: "changed name" - 1 files changed, 4 insertions(+), 0 deletions(-) - $ git push + [master 8962da8] add iphone_project and mobile group + 1 file changed, 4 insertions(+) + $ git push origin master Counting objects: 5, done. - Compressing objects: 100% (2/2), done. - Writing objects: 100% (3/3), 272 bytes, done. - Total 3 (delta 1), reused 0 (delta 0) - To git@gitserver:/opt/git/gitosis-admin.git + Compressing objects: 100% (3/3), done. + Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:gitosis-admin.git fb27aec..8962da8 master -> master You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push: @@ -457,7 +464,7 @@ You can make your first push to the new `iphone_project` project by adding your $ git push origin master Initialized empty Git repository in /opt/git/iphone_project.git/ Counting objects: 3, done. - Writing objects: 100% (3/3), 230 bytes, done. + Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gitserver:iphone_project.git * [new branch] master -> master @@ -473,20 +480,20 @@ You want to work on this project with your friends, so you’ll have to re-add t Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`: [group mobile] - writable = iphone_project members = scott john josie jessica + writable = iphone_project After you commit and push that change, all four users will be able to read from and write to that project. Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead: [group mobile] - writable = iphone_project members = scott josie jessica + writable = iphone_project [group mobile_ro] - readonly = iphone_project members = john + readonly = iphone_project Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically: @@ -494,102 +501,78 @@ Now John can clone the project and get updates, but Gitosis won’t allow him to members = scott josie jessica [group mobile] - writable = iphone_project members = @mobile_committers + writable = iphone_project [group mobile_2] - writable = another_iphone_project members = @mobile_committers john + writable = another_iphone_project If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project. ## Gitolite ## -Note: the latest copy of this section of the ProGit book is always available within the [gitolite documentation][gldpg]. The author would also like to humbly state that, while this section is accurate, and *can* (and often *has*) been used to install gitolite without reading any other documentation, it is of necessity not complete, and cannot completely replace the enormous amount of documentation that gitolite comes with. +This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with. There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg]. -[gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd +[gldpg]: http://sitaramc.github.com/gitolite/progit.html +[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html -Git has started to become very popular in corporate environments, which tend to have some additional requirements in terms of access control. Gitolite was originally created to help with those requirements, but it turns out that it's equally useful in the open source world: the Fedora Project controls access to their package management repositories (over 10,000 of them!) using gitolite, and this is probably the largest gitolite installation anywhere too. +Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to). Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others. ### Installing ### -Installing Gitolite is very easy, even if you don't read the extensive documentation that comes with it. You need an account on a Unix server of some kind; various Linux flavours, and Solaris 10, have been tested. You do not need root access, assuming git, perl, and an openssh compatible ssh server are already installed. In the examples below, we will use the `gitolite` account on a host called `gitserver`. - -Gitolite is somewhat unusual as far as "server" software goes -- access is via ssh, and so every userid on the server is a potential "gitolite host". As a result, there is a notion of "installing" the software itself, and then "setting up" a user as a "gitolite host". - -Gitolite has 4 methods of installation. People using Fedora or Debian systems can obtain an RPM or a DEB and install that. People with root access can install it manually. In these two methods, any user on the system can then become a "gitolite host". - -People without root access can install it within their own userids. And finally, gitolite can be installed by running a script *on the workstation*, from a bash shell. (Even the bash that comes with msysgit will do, in case you're wondering.) - -We will describe this last method in this article; for the other methods please see the documentation. - -You start by obtaining public key based access to your server, so that you can log in from your workstation to the server without getting a password prompt. The following method works on Linux; for other workstation OSs you may have to do this manually. We assume you already had a key pair generated using `ssh-keygen`. - - $ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver +Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind. You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed. In the examples below, we will use the `git` account on a host called `gitserver`. -This will ask you for the password to the gitolite account, and then set up public key access. This is **essential** for the install script, so check to make sure you can run a command without getting a password prompt: +Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation. - $ ssh gitolite@gitserver pwd - /home/gitolite - -Next, you clone Gitolite from the project's main site and run the "easy install" script (the third argument is your name as you would like it to appear in the resulting gitolite-admin repository): +To begin, create a user called `git` on your server and login to this user. Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `.pub` (we'll use `scott.pub` in our examples). Then run these commands: $ git clone git://github.com/sitaramc/gitolite - $ cd gitolite/src - $ ./gl-easy-install -q gitolite gitserver sitaram - -And you're done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in the home directory of your workstation. You administer your gitolite setup by making changes to this repository and pushing. - -That last command does produce a fair amount of output, which might be interesting to read. Also, the first time you run this, a new keypair is created; you will have to choose a passphrase or hit enter for none. Why a second keypair is needed, and how it is used, is explained in the "ssh troubleshooting" document that comes with Gitolite. (Hey the documentation has to be good for *something*!) - -Repos named `gitolite-admin` and `testing` are created on the server by default. If you wish to clone either of these locally (from an account that has SSH console access to the gitolite account via *authorized_keys*), type: + $ gitolite/install -ln + # assumes $HOME/bin exists and is in your $PATH + $ gitolite setup -pk $HOME/scott.pub - $ git clone gitolite:gitolite-admin - $ git clone gitolite:testing - -To clone these same repos from any other account: - - $ git clone gitolite@servername:gitolite-admin - $ git clone gitolite@servername:testing +That last command creates new Git repository called `gitolite-admin` on the server. +Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your Gitolite setup by making changes to this repository and pushing. ### Customising the Install ### -While the default, quick, install works for most people, there are some ways to customise the install if you need to. If you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step. The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses. This "rc" file is liberally commented so you should be able to make any changes you need quite easily, save it, and continue. This file also contains various settings that you can change to enable or disable some of gitolite's advanced features. +While the default, quick, install works for most people, there are some ways to customise the install if you need to. Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite. ### Config File and Access Control Rules ### -Once the install is done, you switch to the `gitolite-admin` repository (placed in your HOME directory) and poke around to see what you got: +Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got: $ cd ~/gitolite-admin/ $ ls conf/ keydir/ $ find conf keydir -type f conf/gitolite.conf - keydir/sitaram.pub + keydir/scott.pub $ cat conf/gitolite.conf - #gitolite conf - # please see conf/example.conf for details on syntax and features repo gitolite-admin - RW+ = sitaram + RW+ = scott repo testing RW+ = @all -Notice that "sitaram" (the last argument in the `gl-easy-install` command you gave earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name. +Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name. -The config file syntax for gitolite is liberally documented in `conf/example.conf`, so we'll only mention some highlights here. +Adding users is easy. To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation. Add, commit, and push the change, and the user has been added. -You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn't even matter whether they are projects or users; that distinction is only made when you *use* the "macro". +The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here. + +You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro". @oss_repos = linux perl rakudo git gitolite @secret_repos = fenestra pear - @admins = scott # Adams, not Chacon, sorry :) - @interns = ashok # get the spelling right, Scott! + @admins = scott + @interns = ashok @engineers = sitaram dilbert wally alice @staff = @admins @engineers @interns @@ -601,74 +584,70 @@ You can control permissions at the "ref" level. In the following example, inter RW refs/tags/rc[0-9] = @engineers RW+ = @admins -The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against. So we call it a "refex"! Of course, a refex can be far more powerful than shown here, so don't overdo it if you're not comfortable with perl regexes. +The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against. So we call it a "refex"! Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes. Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`. -An important feature of the config file's syntax is that all the rules for a repository need not be in one place. You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so: +An important feature of the config file’s syntax is that all the rules for a repository need not be in one place. You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so: repo gitolite RW+ = sitaram That rule will just get added to the ruleset for the `gitolite` repository. -At this point you might be wondering how the access control rules are actually applied, so let's go over that briefly. +At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly. -There are two levels of access control in gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. +There are two levels of access control in Gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. This is the only access control that Gitosis had. The second level, applicable only to "write" access, is by branch or tag within a repository. The username, the access being attempted (`W` or `+`), and the refname being updated are known. The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched). If a match is found, the push succeeds. A fallthrough results in access being denied. ### Advanced Access Control with "deny" rules ### -So far, we've only seen permissions to be one of `R`, `RW`, or `RW+`. However, gitolite allows another permission: `-`, standing for "deny". This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*! +So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`. However, Gitolite allows another permission: `-`, standing for "deny". This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*! -Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ. Here's how to do that: +Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ. Here’s how to do that: RW master integ = @engineers - master integ = @engineers RW+ = @engineers -Again, you simply follow the rules top down until you hit a match for your access mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied. Any push (rewind or non-rewind) to refs other than master or integ won't match the first two rules anyway, and the third rule allows it. +Again, you simply follow the rules top down until you hit a match for your access mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied. Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it. ### Restricting pushes by files changed ### -In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell gitolite: +In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell Gitolite: repo foo - RW = @junior_devs @senior_devs + RW = @junior_devs @senior_devs - RW NAME/ = @senior_devs - - NAME/Makefile = @junior_devs - RW NAME/ = @junior_devs + - VREF/NAME/Makefile = @junior_devs -This powerful feature is documented in `conf/example.conf`. +Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details. ### Personal Branches ### Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment. -A lot of code exchange in the git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there. +A lot of code exchange in the Git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there. This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin. -Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal//*`); see the "personal branches" section in `doc/3-faq-tips-etc.mkd` for details. +Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal//*`); please see the documentation for details. ### "Wildcard" repositories ### -Gitolite allows you to specify repositories with wildcards (actually perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. This is a *very* powerful feature, which has to be enabled by setting `$GL_WILDREPOS = 1;` in the rc file. It allows you to assign a new permission mode ("C") which allows users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out R and RW permissions to other users to collaborate, etc. This feature is documented in `doc/4-wildcard-repositories.mkd`. +Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc. Again, please see the documentation for details. ### Other Features ### -We'll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the "faqs, tips, etc" and other documents. +We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation. -**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away "master", the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed. +**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed. -**Git outside normal PATH**: One extremely useful convenience feature in gitolite is support for git installed outside the normal `$PATH` (this is more common than you think; some corporate environments or even some hosting providers refuse to install things system-wide and you end up putting them in your own directories). Normally, you are forced to make the *client-side* git aware of this non-standard location of the git binaries in some way. With gitolite, just choose a verbose install and set `$GIT_PATH` in the "rc" files. No client-side changes are required after that :-) +**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here’s an example: -**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here's an example: + hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4 - hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4 - the gitolite config gives you the following access: R anu-wsd R entrans R W git-notes @@ -677,9 +656,7 @@ We'll round off this discussion with a sampling of other features, all of which, R indic_web_input R shreelipi_converter -**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently. This reduces the load on the main admin, and makes him less of a bottleneck. This feature has its own documentation file in the `doc/` directory. - -**Gitweb support**: Gitolite supports gitweb in several ways. You can specify which repos are visible via gitweb. You can set the "owner" and "description" for gitweb from the gitolite config file. Gitweb has a mechanism for you to implement access control based on HTTP authentication, so you can make it use the "compiled" config file that gitolite produces, which means the same access control rules (for read access) apply for gitweb and gitolite. +**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently. This reduces the load on the main admin, and makes him less of a bottleneck. **Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down. @@ -718,7 +695,7 @@ When you restart your machine, your Git daemon will start automatically and resp On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow. -Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for your iphone project, you add this to the end of the `gitosis.conf` file: +Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file: [repo iphone_project] daemon = yes @@ -739,13 +716,13 @@ Gitosis can also control which projects GitWeb shows. First, you need to add som $export_ok = "git-daemon-export-ok"; @git_base_url_list = ('git://gitserver'); -You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the iphone project to show up on GitWeb, you make the `repo` setting look like this: +You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this: [repo iphone_project] daemon = yes gitweb = yes -Now, if you commit and push the project, GitWeb will automatically start showing your iphone project. +Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`. ## Hosted Git ## @@ -755,7 +732,7 @@ These days, you have a huge number of hosting options to choose from, each with https://git.wiki.kernel.org/index.php/GitHosting -Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved. +Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved. GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book. @@ -767,39 +744,39 @@ GitHub is also a commercial company that charges for accounts that maintain priv ### Setting Up a User Account ### -The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page. +The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. Insert 18333fig0402.png Figure 4-2. The GitHub plan page. Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3). -Insert 18333fig0403.png +Insert 18333fig0403.png Figure 4-3. The GitHub user signup form. If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems. Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4). -Insert 18333fig0404.png +Insert 18333fig0404.png Figure 4-4. The GitHub user dashboard. -Next you can create a new repository. +Next you can create a new repository. ### Creating a New Repository ### Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5). -Insert 18333fig0405.png +Insert 18333fig0405.png Figure 4-5. Creating a new repository on GitHub. All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6). -Insert 18333fig0406.png +Insert 18333fig0406.png Figure 4-6. GitHub project header information. Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7). -Insert 18333fig0407.png +Insert 18333fig0407.png Figure 4-7. Instructions for a new repository. These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use @@ -815,7 +792,7 @@ When you have a Git repository locally, add GitHub as a remote and push up your Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8). -Insert 18333fig0408.png +Insert 18333fig0408.png Figure 4-8. Project header with a public URL and a private URL. The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you. @@ -826,7 +803,7 @@ The Your Clone URL is a read/write SSH-based URL that you can read or write over If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9). -Insert 18333fig0409.png +Insert 18333fig0409.png Figure 4-9. Subversion importing interface. If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports. @@ -837,17 +814,17 @@ Let’s add the rest of the team. If John, Josie, and Jessica all sign up for ac Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10). -Insert 18333fig0410.png +Insert 18333fig0410.png Figure 4-10. GitHub administration page. To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11). -Insert 18333fig0411.png +Insert 18333fig0411.png Figure 4-11. Adding a collaborator to your project. When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12). -Insert 18333fig0412.png +Insert 18333fig0412.png Figure 4-12. A list of collaborators on your project. If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project. @@ -856,7 +833,7 @@ If you need to revoke access to individuals, you can click the "revoke" link, an After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13. -Insert 18333fig0413.png +Insert 18333fig0413.png Figure 4-13. A GitHub main project page. When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information. @@ -869,12 +846,12 @@ This way, projects don’t have to worry about adding users as collaborators to To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14). -Insert 18333fig0414.png +Insert 18333fig0414.png Figure 4-14. Get a writable copy of any repository by clicking the "fork" button. After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15). -Insert 18333fig0415.png +Insert 18333fig0415.png Figure 4-15. Your fork of a project. ### GitHub Summary ### diff --git a/no-nb/05-distributed-git/01-chapter5.markdown b/no-nb/05-distributed-git/01-chapter5.markdown index e72635415..bb6a633e4 100644 --- a/no-nb/05-distributed-git/01-chapter5.markdown +++ b/no-nb/05-distributed-git/01-chapter5.markdown @@ -22,7 +22,7 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma ### Integration-Manager Workflow ### -Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2): +Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follows (see Figure 5-2): 1. The project maintainer pushes to their public repository. 2. A contributor clones that repository and makes changes. @@ -48,7 +48,7 @@ This is a variant of a multiple-repository workflow. It’s generally used by hu Insert 18333fig0503.png Figure 5-3. Benevolent dictator workflow. -This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, because as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them. +This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them. These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. Now that you can (I hope) determine which workflow combination may work for you, I’ll cover some more specific examples of how to accomplish the main roles that make up the different flows. @@ -174,7 +174,7 @@ John has a reference to the changes Jessica pushed up, but he has to merge them The merge goes smoothly — John’s commit history now looks like Figure 5-5. Insert 18333fig0505.png -Figure 5-5. John’s repository after merging origin/master. +Figure 5-5. John’s repository after merging `origin/master`. Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server: @@ -215,7 +215,7 @@ Jessica thinks her topic branch is ready, but she wants to know what she has to removed invalid default value -Now, Jessica can merge her topic work into her master branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her master branch to integrate all this work: +Now, Jessica can merge her topic work into her `master` branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her `master` branch to integrate all this work: $ git checkout master Switched to branch "master" @@ -230,7 +230,7 @@ She can merge either `origin/master` or `issue54` first — they’re both upstr lib/simplegit.rb | 6 +++++- 2 files changed, 6 insertions(+), 1 deletions(-) -No problems occur; as you can see it, was a simple fast-forward. Now Jessica merges in John’s work (`origin/master`): +No problems occur; as you can see, it was a simple fast-forward. Now Jessica merges in John’s work (`origin/master`): $ git merge origin/master Auto-merging lib/simplegit.rb @@ -255,7 +255,7 @@ Each developer has committed a few times and merged each other’s work successf Insert 18333fig0510.png Figure 5-10. Jessica’s history after pushing all changes back to the server. -That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it’s ready to be integrated. When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11. +That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your `master` branch when it’s ready to be integrated. When you want to share that work, you merge it into your own `master` branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11. Insert 18333fig0511.png Figure 5-11. General sequence of events for a simple multiple-developer Git workflow. @@ -359,12 +359,12 @@ Finally, she merges John’s work into her own `featureA` branch: Jessica wants to tweak something, so she commits again and then pushes this back up to the server: $ git commit -am 'small tweak' - [featureA ed774b3] small tweak + [featureA 774b3ed] small tweak 1 files changed, 1 insertions(+), 1 deletions(-) $ git push origin featureA ... To jessica@githost:simplegit.git - 3300904..ed774b3 featureA -> featureA + 3300904..774b3ed featureA -> featureA Jessica’s commit history now looks something like Figure 5-13. @@ -481,7 +481,7 @@ The workflow is similar to the previous use case — you create topic branches f $ (work) $ git commit -Now you have two commits that you want to send to the mailing list. You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly, as you’ll see more of in the next section when you apply these commits: +Now you have two commits that you want to send to the mailing list. You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly, as you’ll see more of in the next section when you apply these patches: $ git format-patch -M origin/master 0001-add-limit-to-log-function.patch @@ -532,7 +532,26 @@ First, you need to set up the imap section in your `~/.gitconfig` file. You can sslverify = false If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`. -When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server: +When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server: + + $ cat *.patch |git imap-send + Resolving imap.gmail.com... ok + Connecting to [74.125.142.109]:993... ok + Logging in... + sending 2 messages + 100% (2/2) done + +At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off. + +You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file: + + [sendemail] + smtpencryption = tls + smtpserver = smtp.gmail.com + smtpuser = user@gmail.com + smtpserverport = 587 + +After this is done, you can use `git send-email` to send your patches: $ git send-email *.patch 0001-added-limit-to-log-function.patch @@ -559,8 +578,6 @@ Then, Git spits out a bunch of log information looking something like this for e Result: OK -At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off. - ### Summary ### This section has covered a number of common workflows for dealing with several very different types of Git projects you’re likely to encounter and introduced a couple of new tools to help you manage this process. Next, you’ll see how to work the other side of the coin: maintaining a Git project. You’ll learn how to be a benevolent dictator or integration manager. @@ -576,7 +593,7 @@ As you’ll remember, you can create the branch based off your master branch lik $ git branch sc/ruby_client master -Or, if you want to also switch to it immediately, you can use the `checkout -b` option: +Or, if you want to also switch to it immediately, you can use the `checkout -b` command: $ git checkout -b sc/ruby_client master @@ -594,7 +611,7 @@ If you received the patch from someone who generated it with the `git diff` or a This modifies the files in your working directory. It’s almost identical to running a `patch -p1` command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches than patch. It also handles file adds, deletes, and renames if they’re described in the `git diff` format, which `patch` won’t do. Finally, `git apply` is an "apply all or abort all" model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. `git apply` is overall much more paranoid than `patch`. It won’t create a commit for you — after running it, you must stage and commit the changes introduced manually. -You can also use git apply to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch: +You can also use `git apply` to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch: $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 @@ -615,7 +632,7 @@ To apply a patch generated by `format-patch`, you use `git am`. Technically, `gi Limit log functionality to the first 20 -This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time. +This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time. However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown index a6f0108af..eaa9b42a0 100644 --- a/no-nb/06-git-tools/01-chapter6.markdown +++ b/no-nb/06-git-tools/01-chapter6.markdown @@ -57,7 +57,7 @@ Generally, eight to ten characters are more than enough to be unique within a pr A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value. What then? -If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object. +If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object. However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth. @@ -82,13 +82,13 @@ One of the things Git does in the background while you’re working away is keep You can see your reflog by using `git reflog`: $ git reflog - 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated - d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. - 1c002dd... HEAD@{2}: commit: added some blame and merge stuff - 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD - 95df984... HEAD@{4}: commit: # This is a combination of two commits. - 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD - 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD + 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated + d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive. + 1c002dd HEAD@{2}: commit: added some blame and merge stuff + 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD + 95df984 HEAD@{4}: commit: # This is a combination of two commits. + 1c36188 HEAD@{5}: rebase -i (squash): updating HEAD + 7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. And you can specify older commits with this data, as well. If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{n}` reference that you see in the reflog output: @@ -105,7 +105,7 @@ To see reflog information formatted like the `git log` output, you can run `git $ git log -g master commit 734713bc047d87bf7eac9674765ae793478c50d3 Reflog: master@{0} (Scott Chacon ) - Reflog message: commit: fixed refs handling, added gc auto, updated + Reflog message: commit: fixed refs handling, added gc auto, updated Author: Scott Chacon Date: Fri Jan 2 18:32:33 2009 -0800 @@ -119,7 +119,7 @@ To see reflog information formatted like the `git log` output, you can run `git Merge commit 'phedders/rdocs' -It’s important to note that the reflog information is strictly local — it’s a log of what you’ve done in your repository. The references won’t be the same on someone else’s copy of the repository; and right after you initially clone a repository, you'll have an empty reflog, as no activity has occurred yet in your repository. Running `git show HEAD@{2.months.ago}` will work only if you cloned the project at least two months ago — if you cloned it five minutes ago, you’ll get no results. +It’s important to note that the reflog information is strictly local — it’s a log of what you’ve done in your repository. The references won’t be the same on someone else’s copy of the repository; and right after you initially clone a repository, you’ll have an empty reflog, as no activity has occurred yet in your repository. Running `git show HEAD@{2.months.ago}` will work only if you cloned the project at least two months ago — if you cloned it five minutes ago, you’ll get no results. ### Ancestry References ### @@ -129,10 +129,10 @@ Suppose you look at the history of your project: $ git log --pretty=format:'%h %s' --graph * 734713b fixed refs handling, added gc auto, updated tests * d921970 Merge commit 'phedders/rdocs' - |\ + |\ | * 35cfb2b Some rdoc changes * | 1c002dd added some blame and merge stuff - |/ + |/ * 1c36188 ignore *.gem * 9b29157 add open3_detach to gemspec file list @@ -190,7 +190,7 @@ Now that you can specify individual commits, let’s see how to specify ranges o The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another. For example, say you have a commit history that looks like Figure 6-1. -Insert 18333fig0601.png +Insert 18333fig0601.png Figure 6-1. Example history for range selection. You want to see what is in your experiment branch that hasn’t yet been merged into your master branch. You can ask Git to show you a log of just those commits with `master..experiment` — that means "all commits reachable by experiment that aren’t reachable by master." For the sake of brevity and clarity in these examples, I’ll use the letters of the commit objects from the diagram in place of the actual log output in the order that they would display: @@ -248,7 +248,7 @@ A common switch to use with the `log` command in this case is `--left-right`, wh > D > C -With these tools, you can much more easily let Git know what commit or commits you want to inspect. +With these tools, you can much more easily let Git know what commit or commits you want to inspect. ## Interactive Staging ## @@ -264,9 +264,9 @@ If you run `git add` with the `-i` or `--interactive` option, Git goes into an i *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help - What now> + What now> -You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right. +You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right. After this comes a Commands section. Here you can do a number of things, including staging files, unstaging files, staging parts of files, adding untracked files, and seeing diffs of what has been staged. @@ -292,7 +292,7 @@ To stage the TODO and index.html files, you can type the numbers: The `*` next to each file means the file is selected to be staged. If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you: - Update>> + Update>> updated 2 paths *** Commands *** @@ -374,7 +374,7 @@ It’s also possible for Git to stage certain parts of files and not the rest. F end def blame(path) - Stage this hunk [y,n,a,d,/,j,J,g,e,?]? + Stage this hunk [y,n,a,d,/,j,J,g,e,?]? You have a lot of options at this point. Typing `?` shows a list of what you can do: @@ -403,7 +403,7 @@ Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging The status of the simplegit.rb file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. You’ve partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files. -Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line. +Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line. ## Stashing ## @@ -446,8 +446,8 @@ At this point, you can easily switch branches and do work elsewhere; your change $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. If you don’t specify a stash, Git assumes the most recent stash and tries to apply it: @@ -481,8 +481,8 @@ The apply option only tries to apply the stashed work — you continue to have i $ git stash list stash@{0}: WIP on master: 049d078 added the index file - stash@{1}: WIP on master: c264051... Revert "added file_size" - stash@{2}: WIP on master: 21d80a5... added number to log + stash@{1}: WIP on master: c264051 Revert "added file_size" + stash@{2}: WIP on master: 21d80a5 added number to log $ git stash drop stash@{0} Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43) @@ -498,7 +498,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash: $ git stash show -p | git apply -R -You may want to create an alias and effectively add a `stash-unapply` command to your git. For example: +You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' $ git stash @@ -566,12 +566,19 @@ Running this command gives you a list of commits in your text editor that looks # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this: @@ -590,6 +597,10 @@ You need to edit the script so that it stops at the commit you want to edit. To When you save and exit the editor, Git rewinds you back to the last commit in that list and drops you on the command line with the following message: + + $ git rebase -i HEAD~3 Stopped at 7482e0d... updated the gemspec to hopefully work better You can amend the commit now, with @@ -632,12 +643,19 @@ It’s also possible to take a series of commits and squash them down into a sin # # Commands: # p, pick = use commit + # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit + # f, fixup = like "squash", but discard this commit's log message + # x, exec = run command (the rest of the line) using shell + # + # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. + # # However, if you remove everything, the rebase will be aborted. # + # Note that empty commits are commented out If, instead of "pick" or "edit", you specify "squash", Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this: @@ -669,7 +687,7 @@ Splitting a commit undoes a commit and then partially stages and commits as many edit 310154e updated README formatting and added blame pick a5f4a0d added cat-file -Then, when the script drops you to the command line, you reset that commit, take the changes that have been reset, and create multiple commits out of them. When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can stage and commit files until you have several commits, and run `git rebase --continue` when you’re done: +When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can take the changes that have been reset, and create multiple commits out of them. Simply stage and commit files until you have several commits, and run `git rebase --continue` when you’re done: $ git reset HEAD^ $ git add README @@ -700,7 +718,7 @@ This occurs fairly commonly. Someone accidentally commits a huge binary file wit Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21) Ref 'refs/heads/master' was rewritten -The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results. In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter "find * -type f -name '*~' -delete" HEAD`. +The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results. In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter "rm -f *~" HEAD`. You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `--all` to the command. @@ -712,7 +730,7 @@ Suppose you’ve done an import from another source control system and have subd Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12) Ref 'refs/heads/master' was rewritten -Now your new project root is what was in the `trunk` subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory. +Now your new project root is what was in the `trunk` subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory. #### Changing E-Mail Addresses Globally #### @@ -738,7 +756,7 @@ Git also provides a couple of tools to help you debug issues in your projects. B If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. It shows you what commit was the last to modify each line of any file. So, if you see that a method in your code is buggy, you can annotate the file with `git blame` to see when each line of the method was last edited and by whom. This example uses the `-L` option to limit the output to lines 12 through 22: - $ git blame -L 12,22 simplegit.rb + $ git blame -L 12,22 simplegit.rb ^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 12) def show(tree = 'master') ^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 13) command("git show #{tree}") ^4832fe2 (Scott Chacon 2008-03-15 10:31:28 -0700 14) end @@ -746,7 +764,7 @@ If you track down a bug in your code and want to know when it was introduced and 9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 16) def log(tree = 'master') 79eaf55d (Scott Chacon 2008-04-06 10:15:08 -0700 17) command("git log #{tree}") 9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 18) end - 9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 19) + 9f6560e4 (Scott Chacon 2008-03-17 21:52:20 -0700 19) 42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20) def blame(path) 42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21) command("git blame #{path}") 42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22) end @@ -755,8 +773,8 @@ Notice that the first field is the partial SHA-1 of the commit that last modifie Another cool thing about Git is that it doesn’t track file renames explicitly. It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. Recently, I was refactoring a file named `GITServerHandler.m` into multiple files, one of which was `GITPackUpload.m`. By blaming `GITPackUpload.m` with the `-C` option, I could see where sections of the code originally came from: - $ git blame -C -L 141,153 GITPackUpload.m - f344f58d GITServerHandler.m (Scott 2009-01-04 141) + $ git blame -C -L 141,153 GITPackUpload.m + f344f58d GITServerHandler.m (Scott 2009-01-04 141) f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC f344f58d GITServerHandler.m (Scott 2009-01-04 143) { 70befddd GITServerHandler.m (Scott 2009-03-22 144) //NSLog(@"GATHER COMMI @@ -853,7 +871,7 @@ Now you have the Rack project under a subdirectory named `rack` within your proj First you notice the `.gitmodules` file. This is a configuration file that stores the mapping between the project’s URL and the local subdirectory you’ve pulled it into: - $ cat .gitmodules + $ cat .gitmodules [submodule "rack"] path = rack url = git://github.com/chneukirchen/rack.git @@ -993,7 +1011,7 @@ Then, you e-mail that guy and yell at him. Sometimes, developers want to get a combination of a large project’s subdirectories, depending on what team they’re on. This is common if you’re coming from CVS or Subversion, where you’ve defined a module or collection of subdirectories, and you want to keep this type of workflow. -A good way to do this in Git is to make each of the subfolders a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects. +A good way to do this in Git is to make each of the subdirectories a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects. ### Issues with Submodules ### diff --git a/no-nb/07-customizing-git/01-chapter7.markdown b/no-nb/07-customizing-git/01-chapter7.markdown index 2a800faf9..de99afcd7 100644 --- a/no-nb/07-customizing-git/01-chapter7.markdown +++ b/no-nb/07-customizing-git/01-chapter7.markdown @@ -4,16 +4,16 @@ So far, I’ve covered the basics of how Git works and how to use it, and I’ve ## Git Configuration ## -As you briefly saw in the Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address: +As you briefly saw in Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com Now you’ll learn a few of the more interesting options that you can set in this manner to customize your Git usage. -You saw some simple Git configuration details in the first chapter, but I’ll go over them again quickly here. Git uses a series of configuration files to determine non-default behavior that you may want. The first place Git looks for these values is in an `/etc/gitconfig` file, which contains values for every user on the system and all of their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically. +You saw some simple Git configuration details in the first chapter, but I’ll go over them again quickly here. Git uses a series of configuration files to determine non-default behavior that you may want. The first place Git looks for these values is in an `/etc/gitconfig` file, which contains values for every user on the system and all of their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically. -The next place Git looks is the `~/.gitconfig` file, which is specific to each user. You can make Git read and write to this file by passing the `--global` option. +The next place Git looks is the `~/.gitconfig` file, which is specific to each user. You can make Git read and write to this file by passing the `--global` option. Finally, Git looks for configuration values in the config file in the Git directory (`.git/config`) of whatever repository you’re currently using. These values are specific to that single repository. Each level overwrites values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`, for instance. You can also set these values by manually editing the file and inserting the correct syntax, but it’s generally easier to run the `git config` command. @@ -75,7 +75,7 @@ The core.pager setting determines what pager is used when Git pages output such $ git config --global core.pager '' -If you run that, Git will page the entire output of all commands, no matter how long they are. +If you run that, Git will page the entire output of all commands, no matter how long it is. #### user.signingkey #### @@ -93,7 +93,7 @@ You can put patterns in your project’s `.gitignore` file to have Git not see t #### help.autocorrect #### -This option is available only in Git 1.6.1 and later. If you mistype a command in Git 1.6, it shows you something like this: +This option is available only in Git 1.6.1 and later. If you mistype a command in Git, it shows you something like this: $ git com git: 'com' is not a git-command. See 'git --help'. @@ -113,13 +113,13 @@ Git automatically colors most of its output if you ask it to. You can get very s $ git config --global color.ui true -When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command. This setting was added in Git version 1.5.5; if you have an older version, you’ll have to specify all the color settings individually. +When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command. You’ll rarely want `color.ui = always`. In most scenarios, if you want color codes in your redirected output, you can instead pass a `--color` flag to the Git command to force it to use color codes. The `color.ui = true` setting is almost always what you’ll want to use. #### `color.*` #### -If you want to be more specific about which commands are colored and how, or you have an older version, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`: +If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`: color.branch color.diff @@ -128,9 +128,9 @@ If you want to be more specific about which commands are colored and how, or you In addition, each of these has subsettings you can use to set specific colors for parts of the output, if you want to override each color. For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run - $ git config --global color.diff.meta “blue black bold” + $ git config --global color.diff.meta "blue black bold" -You can set the color to any of the following values: normal, black, red, green, yellow, blue, magenta, cyan, or white. If you want an attribute like bold in the previous example, you can choose from bold, dim, ul, blink, and reverse. +You can set the color to any of the following values: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`, or, if your terminal supports more than 16 colors, an arbitrary numeric color value (between 0 and 255 on a 256-color terminal). If you want an attribute like bold in the previous example, you can choose from `bold`, `dim`, `ul`, `blink`, and `reverse`. See the `git config` manpage for all the subsettings you can configure, if you want to do that. @@ -156,13 +156,13 @@ The diff wrapper checks to make sure seven arguments are provided and passes two Because you only want the `old-file` and `new-file` arguments, you use the wrapper script to pass the ones you need. - $ cat /usr/local/bin/extDiff + $ cat /usr/local/bin/extDiff #!/bin/sh [ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5" You also need to make sure these tools are executable: - $ sudo chmod +x /usr/local/bin/extMerge + $ sudo chmod +x /usr/local/bin/extMerge $ sudo chmod +x /usr/local/bin/extDiff Now you can set up your config file to use your custom merge resolution and diff tools. This takes a number of custom settings: `merge.tool` to tell Git what strategy to use, `mergetool.*.cmd` to specify how to run the command, `mergetool.trustExitCode` to tell Git if the exit code of that program indicates a successful merge resolution or not, and `diff.external` to tell Git what command to run for diffs. So, you can either run four config commands @@ -184,12 +184,12 @@ or you can edit your `~/.gitconfig` file to add these lines: external = extDiff After all this is set, if you run diff commands such as this: - + $ git diff 32d1776b1^ 32d1776b1 Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like Figure 7-1. -Insert 18333fig0701.png +Insert 18333fig0701.png Figure 7-1. P4Merge. If you try to merge two branches and subsequently have merge conflicts, you can run the command `git mergetool`; it starts P4Merge to let you resolve the conflicts through that GUI tool. @@ -197,7 +197,7 @@ If you try to merge two branches and subsequently have merge conflicts, you can The nice thing about this wrapper setup is that you can change your diff and merge tools easily. For example, to change your `extDiff` and `extMerge` tools to run the KDiff3 tool instead, all you have to do is edit your `extMerge` file: $ cat /usr/local/bin/extMerge - #!/bin/sh + #!/bin/sh /Applications/kdiff3.app/Contents/MacOS/kdiff3 $* Now, Git will use the KDiff3 tool for diff viewing and merge conflict resolution. @@ -214,7 +214,7 @@ Formatting and whitespace issues are some of the more frustrating and subtle pro #### core.autocrlf #### -If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work. +If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work. Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the `core.autocrlf` setting. If you’re on a Windows machine, set it to `true` — this converts LF endings into CRLF when you check out code: @@ -251,7 +251,7 @@ Or you can have Git try to automatically fix the issue before applying the patch $ git apply --whitespace=fix -These options apply to the git rebase option as well. If you’ve committed whitespace issues but haven’t yet pushed upstream, you can run a `rebase` with the `--whitespace=fix` option to have Git automatically fix whitespace issues as it’s rewriting the patches. +These options apply to the `git rebase` command as well. If you’ve committed whitespace issues but haven’t yet pushed upstream, you can run a `rebase` with the `--whitespace=fix` option to have Git automatically fix whitespace issues as it’s rewriting the patches. ### Server Configuration ### @@ -301,19 +301,23 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line *.pbxproj -crlf -diff -Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run git show or git diff on your project. In the 1.6 series of Git, you can also use a macro that is provided that means `-crlf -diff`: +Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run `git show` or `git diff` on your project. You can also use a built-in macro `binary` that means `-crlf -diff`: *.pbxproj binary #### Diffing Binary Files #### -In the 1.6 series of Git, you can use the Git attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff. +In Git, you can use the attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff. But the question is how do you convert *binary* data to a text? The best solution is to find some tool that does conversion for your binary format to a text representation. Unfortunately, very few binary formats can be represented as human readable text (imagine trying to convert audio data to a text). If this is the case and you failed to get a text presentation of your file's contents, it's often relatively easy to get a human readable description of that content, or metadata. Metadata won't give you a full representation of your file's content, but in any case it's better than nothing. + +We'll make use of the both described approaches to get usable diffs for some widely used binary formats. + +Side note: There are different kinds of binary formats with a text content, which are hard to find usable converter for. In such a case you could try to extract a text from your file with the `strings` program. Some of these files may use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats. ##### MS Word files ##### -Because this is a pretty cool and not widely known feature, I’ll go over a few examples. First, you’ll use this technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this: +First, you’ll use the described technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this: - $ git diff + $ git diff diff --git a/chapter1.doc b/chapter1.doc index 88839c4..4afcb7c 100644 Binary files a/chapter1.doc and b/chapter1.doc differ @@ -322,18 +326,16 @@ You can’t directly compare two versions unless you check them out and scan the *.doc diff=word -This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `strings` program to convert Word documents into readable text files, which it will then diff properly: +This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `catdoc` program, which was written specifically for extracting text from a binary MS Word documents (you can get it from `http://www.wagner.pp.ru/~vitus/software/catdoc/`), to convert Word documents into readable text files, which it will then diff properly: - $ git config diff.word.textconv strings + $ git config diff.word.textconv catdoc This command adds a section to your `.git/config` that looks like this: [diff "word"] - textconv = strings - -Side note: There are different kinds of `.doc` files. Some use an UTF-16 encoding or other "codepages" and `strings` won't find anything useful in there. Your mileage may vary. + textconv = catdoc -Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `strings` program. This effectively makes nice text-based versions of your Word files before attempting to diff them. +Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `catdoc` program. This effectively makes nice text-based versions of your Word files before attempting to diff them. Here’s an example. I put Chapter 1 of this book into Git, added some text to a paragraph, and saved the document. Then, I ran `git diff` to see what changed: @@ -342,15 +344,14 @@ Here’s an example. I put Chapter 1 of this book into Git, added some text to a index c1c8a0a..b93c9e4 100644 --- a/chapter1.doc +++ b/chapter1.doc - @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics - re going to cover how to get it and set it up for the first time if you don - t already have it on your system. - In Chapter Two we will go over basic Git usage - how to use Git for the 80% - -s going on, modify stuff and contribute changes. If the book spontaneously - +s going on, modify stuff and contribute changes. If the book spontaneously - +Let's see if this works. + @@ -128,7 +128,7 @@ and data size) + Since its birth in 2005, Git has evolved and matured to be easy to use + and yet retain these initial qualities. It’s incredibly fast, it’s + very efficient with large projects, and it has an incredible branching + -system for non-linear development. + +system for non-linear development (See Chapter 3). -Git successfully and succinctly tells me that I added the string "Let’s see if this works", which is correct. It’s not perfect — it adds a bunch of random stuff at the end — but it certainly works. If you can find or write a Word-to-plain-text converter that works well enough, that solution will likely be incredibly effective. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats. +Git successfully and succinctly tells me that I added the string "(See Chapter 3)", which is correct. Works perfectly! ##### OpenDocument Text files ##### @@ -366,18 +367,18 @@ Now set up the `odt` diff filter in `.git/config`: binary = true textconv = /usr/local/bin/odt-to-txt -OpenDocument files are actually zip'ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We'll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content: +OpenDocument files are actually zip’ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We’ll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content: #! /usr/bin/env perl # Simplistic OpenDocument Text (.odt) to plain text converter. # Author: Philipp Kempgen - + if (! defined($ARGV[0])) { print STDERR "No filename given!\n"; print STDERR "Usage: $0 filename\n"; exit 1; } - + my $content = ''; open my $fh, '-|', 'unzip', '-qq', '-p', $ARGV[0], 'content.xml' or die $!; { @@ -405,7 +406,7 @@ Now `git diff` will be able to tell you what changed in `.odt` files. ##### Image files ##### -Another interesting problem you can solve this way involves diffing image files. One way to do this is to run JPEG files through a filter that extracts their EXIF information — metadata that is recorded with most image formats. If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened: +Another interesting problem you can solve this way involves diffing image files. One way to do this is to run PNG files through a filter that extracts their EXIF information — metadata that is recorded with most image formats. If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened: $ echo '*.png diff=exif' >> .gitattributes $ git config diff.exif.textconv exiftool @@ -419,7 +420,7 @@ If you replace an image in your project and run `git diff`, you see something li @@ -1,12 +1,12 @@ ExifTool Version Number : 7.74 -File Size : 70 kB - -File Modification Date/Time : 2009:04:21 07:02:45-07:00 + -File Modification Date/Time : 2009:04:17 10:12:35-07:00 +File Size : 94 kB +File Modification Date/Time : 2009:04:21 07:02:43-07:00 File Type : PNG @@ -444,26 +445,26 @@ First, you can inject the SHA-1 checksum of a blob into an `$Id$` field in the f The next time you check out this file, Git injects the SHA of the blob: - $ rm text.txt - $ git checkout -- text.txt - $ cat test.txt + $ rm test.txt + $ git checkout -- test.txt + $ cat test.txt $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $ However, that result is of limited use. If you’ve used keyword substitution in CVS or Subversion, you can include a datestamp — the SHA isn’t all that helpful, because it’s fairly random and you can’t tell if one SHA is older or newer than another. It turns out that you can write your own filters for doing substitutions in files on commit/checkout. These are the "clean" and "smudge" filters. In the `.gitattributes` file, you can set a filter for particular paths and then set up scripts that will process files just before they’re checked out ("smudge", see Figure 7-2) and just before they’re committed ("clean", see Figure 7-3). These filters can be set to do all sorts of fun things. -Insert 18333fig0702.png +Insert 18333fig0702.png Figure 7-2. The “smudge” filter is run on checkout. -Insert 18333fig0703.png +Insert 18333fig0703.png Figure 7-3. The “clean” filter is run when files are staged. The original commit message for this functionality gives a simple example of running all your C source code through the `indent` program before committing. You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the "indent" filter: *.c filter=indent -Then, tell Git what the "indent"" filter does on smudge and clean: +Then, tell Git what the "indent" filter does on smudge and clean: $ git config --global filter.indent.clean indent $ git config --global filter.indent.smudge cat @@ -510,7 +511,7 @@ For example, say you have some test files in a `test/` subdirectory, and it does test/ export-ignore -Now, when you run git archive to create a tarball of your project, that directory won’t be included in the archive. +Now, when you run `git archive` to create a tarball of your project, that directory won’t be included in the archive. #### export-subst #### @@ -548,7 +549,7 @@ Like many other Version Control Systems, Git has a way to fire off custom script ### Installing a Hook ### -The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. For post-1.6 versions of Git, these example hook files end with .sample; you’ll need to rename them. For pre-1.6 versions of Git, the example files are named properly but are not executable. +The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. These example hook files end with .sample; you’ll need to rename them. To enable a hook script, put a file in the `hooks` subdirectory of your Git directory that is named appropriately and is executable. From that point forward, it should be called. I’ll cover most of the major hook filenames here. @@ -612,14 +613,12 @@ All the server-side work will go into the update file in your hooks directory. T #!/usr/bin/env ruby - $refname = ARGV[0] - $oldrev = ARGV[1] - $newrev = ARGV[2] - $user = ENV['USER'] - - puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})" + refname = ARGV[0] + oldrev = ARGV[1] + newrev = ARGV[2] + user = ENV['USER'] -Yes, I’m using global variables. Don’t judge me — it’s easier to demonstrate in this manner. + puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})" #### Enforcing a Specific Commit-Message Format #### @@ -736,7 +735,7 @@ If you use the ACL structure returned from the `get_acl_access_data` method and access[$user].each do |access_path| if !access_path || # user has access to everything (path.index(access_path) == 0) # access to this path - has_file_access = true + has_file_access = true end end if !has_file_access @@ -744,22 +743,22 @@ If you use the ACL structure returned from the `get_acl_access_data` method and exit 1 end end - end + end end check_directory_perms -Most of that should be easy to follow. You get a list of new commits being pushed to your server with `git rev-list`. Then, for each of those, you find which files are modified and make sure the user who’s pushing has access to all the paths being modified. One Rubyism that may not be clear is `path.index(access_path) == 0`, which is true if path begins with `access_path` — this ensures that `access_path` is not just in one of the allowed paths, but an allowed path begins with each accessed path. +Most of that should be easy to follow. You get a list of new commits being pushed to your server with `git rev-list`. Then, for each of those, you find which files are modified and make sure the user who’s pushing has access to all the paths being modified. One Rubyism that may not be clear is `path.index(access_path) == 0`, which is true if path begins with `access_path` — this ensures that `access_path` is not just in one of the allowed paths, but an allowed path begins with each accessed path. Now your users can’t push any commits with badly formed messages or with modified files outside of their designated paths. #### Enforcing Fast-Forward-Only Pushes #### -The only thing left is to enforce fast-forward-only pushes. In Git versions 1.6 or newer, you can set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will work in older versions of Git, and you can modify it to do so only for certain users or whatever else you come up with later. +The only thing left is to enforce fast-forward-only pushes. To do so, you can simply set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will also work, and you can modify it to do so only for certain users or whatever else you come up with later. The logic for checking this is to see if any commits are reachable from the older revision that aren’t reachable from the newer one. If there are none, then it was a fast-forward push; otherwise, you deny it: - # enforces fast-forward only pushes + # enforces fast-forward only pushes def check_fast_forward missed_refs = `git rev-list #{$newrev}..#{$oldrev}` missed_ref_count = missed_refs.split("\n").size @@ -771,7 +770,7 @@ The logic for checking this is to see if any commits are reachable from the olde check_fast_forward -Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the file into which you should have put all this code, and then try to push a non-fast-forwarded reference, you get something like this: +Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the file into which you should have put all this code, and then try to push a non-fast-forward reference, you’ll get something like this: $ git push -f origin master Counting objects: 5, done. @@ -779,9 +778,9 @@ Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the fil Writing objects: 100% (3/3), 323 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. - Enforcing Policies... + Enforcing Policies... (refs/heads/master) (8338c5) (c5b616) - [POLICY] Cannot push a non-fast-forward reference + [POLICY] Cannot push a non fast-forward reference error: hooks/update exited with error code 1 error: hook declined to update refs/heads/master To git@gitserver:project.git @@ -790,8 +789,8 @@ Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the fil There are a couple of interesting things here. First, you see this where the hook starts running. - Enforcing Policies... - (refs/heads/master) (fb8c72) (c56860) + Enforcing Policies... + (refs/heads/master) (8338c5) (c5b616) Notice that you printed that out to stdout at the very beginning of your update script. It’s important to note that anything your script prints to stdout will be transferred to the client. @@ -917,7 +916,7 @@ Here is an example pre-rebase script that checks for that. It gets a list of all target_shas.each do |sha| remote_refs.each do |remote_ref| shas_pushed = `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}` - if shas_pushed.split(“\n”).include?(sha) + if shas_pushed.split("\n").include?(sha) puts "[POLICY] Commit #{sha} has already been pushed to #{remote_ref}" exit 1 end diff --git a/no-nb/08-git-and-other-scms/01-chapter8.markdown b/no-nb/08-git-and-other-scms/01-chapter8.markdown index 2465ffaa5..a270b14e3 100644 --- a/no-nb/08-git-and-other-scms/01-chapter8.markdown +++ b/no-nb/08-git-and-other-scms/01-chapter8.markdown @@ -2,7 +2,7 @@ The world isn’t perfect. Usually, you can’t immediately switch every project you come in contact with to Git. Sometimes you’re stuck on a project using another VCS, and many times that system is Subversion. You’ll spend the first part of this chapter learning about `git svn`, the bidirectional Subversion gateway tool in Git. -At some point, you may want to convert your existing project to Git. The second part of this chapter covers how to migrate your project into Git: first from Subversion, then from Perforce, and finally via a custom import script for a nonstandard importing case. +At some point, you may want to convert your existing project to Git. The second part of this chapter covers how to migrate your project into Git: first from Subversion, then from Perforce, and finally via a custom import script for a nonstandard importing case. ## Git and Subversion ## @@ -20,7 +20,7 @@ Don’t rewrite your history and try to push again, and don’t push to a parall ### Setting Up ### -To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on Google code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. +To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on Google code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. To follow along, you first need to create a new local Subversion repository: @@ -29,14 +29,14 @@ To follow along, you first need to create a new local Subversion repository: Then, enable all users to change revprops — the easy way is to add a pre-revprop-change script that always exits 0: - $ cat /tmp/test-svn/hooks/pre-revprop-change + $ cat /tmp/test-svn/hooks/pre-revprop-change #!/bin/sh exit 0; $ chmod +x /tmp/test-svn/hooks/pre-revprop-change You can now sync this project to your local machine by calling `svnsync init` with the to and from repositories. - $ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ + $ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ This sets up the properties to run the sync. You can then clone the code by running @@ -106,7 +106,7 @@ A normal Git repository looks more like this: 0a30dd3b0c795b80212ae723640d4e5d48cabdff refs/remotes/origin/master 25812380387fdd55f916652be4881c6f11600d6f refs/remotes/origin/testing -You have two remote servers: one named `gitserver` with a `master` branch; and another named `origin` with two branches, `master` and `testing`. +You have two remote servers: one named `gitserver` with a `master` branch; and another named `origin` with two branches, `master` and `testing`. Notice how in the example of remote references imported from `git svn`, tags are added as remote branches, not as real Git tags. Your Subversion import looks like it has a remote named tags with branches under it. @@ -202,7 +202,7 @@ Running `git svn rebase` every once in a while makes sure your code is always up ### Git Branching Issues ### -When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via git svn, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so git svn follows only the first parent when converting the snapshots into Subversion commits. +When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via `git svn`, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so `git svn` follows only the first parent when converting the snapshots into Subversion commits. Suppose your history looks like the following: you created an `experiment` branch, did two commits, and then merged them back into `master`. When you `dcommit`, you see output like this: @@ -231,7 +231,7 @@ When someone else clones that work, all they see is the merge commit with all th ### Subversion Branching ### -Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using git svn. +Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using `git svn`. #### Creating a New SVN Branch #### @@ -250,7 +250,7 @@ This does the equivalent of the `svn copy trunk branches/opera` command in Subve ### Switching Active Branches ### -Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history — you should have only one, and it should be the last one with a `git-svn-id` in your current branch history. +Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history — you should have only one, and it should be the last one with a `git-svn-id` in your current branch history. If you want to work on more than one branch simultaneously, you can set up local branches to `dcommit` to specific Subversion branches by starting them at the imported Subversion commit for that branch. If you want an `opera` branch that you can work on separately, you can run @@ -281,7 +281,7 @@ If you’re used to Subversion and want to see your history in SVN output style, ------------------------------------------------------------------------ r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines - + updated the changelog You should know two important things about `git svn log`. First, it works offline, unlike the real `svn log` command, which asks the Subversion server for the data. Second, it only shows you commits that have been committed up to the Subversion server. Local Git commits that you haven’t dcommited don’t show up; neither do commits that people have made to the Subversion server in the meantime. It’s more like the last known state of the commits on the Subversion server. @@ -290,19 +290,19 @@ You should know two important things about `git svn log`. First, it works offlin Much as the `git svn log` command simulates the `svn log` command offline, you can get the equivalent of `svn annotate` by running `git svn blame [FILE]`. The output looks like this: - $ git svn blame README.txt + $ git svn blame README.txt 2 temporal Protocol Buffers - Google's data interchange format 2 temporal Copyright 2008 Google Inc. 2 temporal http://code.google.com/apis/protocolbuffers/ - 2 temporal + 2 temporal 22 temporal C++ Installation - Unix 22 temporal ======================= - 2 temporal + 2 temporal 79 schacon Committing in git-svn. - 78 schacon + 78 schacon 2 temporal To build and install the C++ Protocol Buffer runtime and the Protocol 2 temporal Buffer compiler (protoc) execute the following: - 2 temporal + 2 temporal Again, it doesn’t show commits that you did locally in Git or that have been pushed to Subversion in the meantime. @@ -369,7 +369,7 @@ That gives you the log output in XML format — you can look for the authors, cr You can provide this file to `git svn` to help it map the author data more accurately. You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command. This makes your `import` command look like this: - $ git-svn clone http://my-project.googlecode.com/svn/ \ + $ git svn clone http://my-project.googlecode.com/svn/ \ --authors-file=users.txt --no-metadata -s my_project Now you should have a nicer Subversion import in your `my_project` directory. Instead of commits that look like this @@ -396,15 +396,13 @@ You need to do a bit of `post-import` cleanup. For one thing, you should clean u To move the tags to be proper Git tags, run - $ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/ - $ rm -Rf .git/refs/remotes/tags + $ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done This takes the references that were remote branches that started with `tag/` and makes them real (lightweight) tags. Next, move the rest of the references under `refs/remotes` to be local branches: - $ cp -Rf .git/refs/remotes/* .git/refs/heads/ - $ rm -Rf .git/refs/remotes + $ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done Now all the old branches are real Git branches and all the old tags are real Git tags. The last thing to do is add your new Git server as a remote and push to it. Here is an example of adding your server as a remote: @@ -413,12 +411,13 @@ Now all the old branches are real Git branches and all the old tags are real Git Because you want all your branches and tags to go up, you can now run this: $ git push origin --all + $ git push origin --tags All your branches and tags should be on your new Git server in a nice, clean import. ### Perforce ### -The next system you’ll look at importing from is Perforce. A Perforce importer is also distributed with Git, but only in the `contrib` section of the source code — it isn’t available by default like `git svn`. To run it, you must get the Git source code, which you can download from git.kernel.org: +The next system you’ll look at importing from is Perforce. A Perforce importer is also distributed with Git. If you have a version of Git earlier than 1.7.11, then the importer is only available in the `contrib` section of the source code. In that case you must get the Git source code, which you can download from git.kernel.org: $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/contrib/fast-import @@ -500,7 +499,7 @@ To quickly demonstrate, you’ll write a simple importer. Suppose you work in cu In order to import a Git directory, you need to review how Git stores its data. As you may remember, Git is fundamentally a linked list of commit objects that point to a snapshot of content. All you have to do is tell `fast-import` what the content snapshots are, what commit data points to them, and the order they go in. Your strategy will be to go through the snapshots one at a time and create commits with the contents of each directory, linking each commit back to the previous one. -As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you'll need to take special care to not introduce carriage returns at the end your lines — git fast-import is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses. +As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you’ll need to take special care to not introduce carriage returns at the end your lines — `git fast-import` is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses. To begin, you’ll change into the target directory and identify every subdirectory, each of which is a snapshot that you want to import as a commit. You’ll change into each subdirectory and print the commands necessary to export it. Your basic main loop looks like this: @@ -512,7 +511,7 @@ To begin, you’ll change into the target directory and identify every subdirect next if File.file?(dir) # move into the target directory - Dir.chdir(dir) do + Dir.chdir(dir) do last_mark = print_export(dir, last_mark) end end @@ -561,7 +560,7 @@ Now you’re ready to begin printing out the commit data for your importer. The export_data('imported from ' + dir) puts 'from :' + last_mark if last_mark -You hardcode the time zone (-0700) because doing so is easy. If you’re importing from another system, you must specify the time zone as an offset. +You hardcode the time zone (-0700) because doing so is easy. If you’re importing from another system, you must specify the time zone as an offset. The commit message must be expressed in a special format: data (size)\n(contents) @@ -596,19 +595,19 @@ Here, 644 is the mode (if you have executable files, you need to detect and spec export_data(content) end -You reuse the `export_data` method you defined earlier, because it’s the same as the way you specified your commit message data. +You reuse the `export_data` method you defined earlier, because it’s the same as the way you specified your commit message data. The last thing you need to do is to return the current mark so it can be passed to the next iteration: return mark -NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF: +NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while `git fast-import` expects only LF. To get around this problem and make `git fast-import` happy, you need to tell ruby to use LF instead of CRLF: $stdout.binmode That’s it. If you run this script, you’ll get content that looks something like this: - $ ruby import.rb /opt/import_from + $ ruby import.rb /opt/import_from commit refs/heads/master mark :1 committer Scott Chacon 1230883200 -0700 @@ -631,7 +630,7 @@ That’s it. If you run this script, you’ll get content that looks something l new version one (...) -To run the importer, pipe this output through `git fast-import` while in the Git directory you want to import into. You can create a new directory and then run `git init` in it for a starting point, and then run your script: +To run the importer, pipe this output through `git fast-import` while in the Git repository you want to import into. You can create a new directory and then run `git init` in it for a starting point, and then run your script: $ git init Initialized empty Git repository in /opt/import_to/.git/ diff --git a/no-nb/09-git-internals/01-chapter9.markdown b/no-nb/09-git-internals/01-chapter9.markdown index a04fee487..354a44f16 100644 --- a/no-nb/09-git-internals/01-chapter9.markdown +++ b/no-nb/09-git-internals/01-chapter9.markdown @@ -16,7 +16,7 @@ The book’s first eight chapters deal almost exclusively with porcelain command When you run `git init` in a new or existing directory, Git creates the `.git` directory, which is where almost everything that Git stores and manipulates is located. If you want to back up or clone your repository, copying this single directory elsewhere gives you nearly everything you need. This entire chapter basically deals with the stuff in this directory. Here’s what it looks like: - $ ls + $ ls HEAD branches/ config @@ -27,7 +27,7 @@ When you run `git init` in a new or existing directory, Git creates the `.git` d objects/ refs/ -You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a .gitignore file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7. +You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a `.gitignore` file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7. This leaves four important entries: the `HEAD` and `index` files and the `objects` and `refs` directories. These are the core parts of Git. The `objects` directory stores all the content for your database, the `refs` directory stores pointers into commit objects in that data (branches), the `HEAD` file points to the branch you currently have checked out, and the `index` file is where Git stores your staging area information. You’ll now look at each of these sections in detail to see how Git operates. @@ -54,7 +54,7 @@ Git has initialized the `objects` directory and created `pack` and `info` subdir The `-w` tells `hash-object` to store the object; otherwise, the command simply tells you what the key would be. `--stdin` tells the command to read the content from stdin; if you don’t specify this, `hash-object` expects the path to a file. The output from the command is a 40-character checksum hash. This is the SHA-1 hash — a checksum of the content you’re storing plus a header, which you’ll learn about in a bit. Now you can see how Git has stored your data: - $ find .git/objects -type f + $ find .git/objects -type f .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 You can see a file in the `objects` directory. This is how Git stores the content initially — as a single file per piece of content, named with the SHA-1 checksum of the content and its header. The subdirectory is named with the first 2 characters of the SHA, and the filename is the remaining 38 characters. @@ -67,32 +67,32 @@ You can pull the content back out of Git with the `cat-file` command. This comma Now, you can add content to Git and pull it back out again. You can also do this with content in files. For example, you can do some simple version control on a file. First, create a new file and save its contents in your database: $ echo 'version 1' > test.txt - $ git hash-object -w test.txt + $ git hash-object -w test.txt 83baae61804e65cc73a7201a7252750c76066a30 Then, write some new content to the file, and save it again: $ echo 'version 2' > test.txt - $ git hash-object -w test.txt + $ git hash-object -w test.txt 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a Your database contains the two new versions of the file as well as the first content you stored there: - $ find .git/objects -type f + $ find .git/objects -type f .git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a .git/objects/83/baae61804e65cc73a7201a7252750c76066a30 .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 Now you can revert the file back to the first version - $ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt - $ cat test.txt + $ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt + $ cat test.txt version 1 or the second version: - $ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt - $ cat test.txt + $ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt + $ cat test.txt version 2 But remembering the SHA-1 key for each version of your file isn’t practical; plus, you aren’t storing the filename in your system — just the content. This object type is called a blob. You can have Git tell you the object type of any object in Git, given its SHA-1 key, with `cat-file -t`: @@ -116,10 +116,10 @@ The `master^{tree}` syntax specifies the tree object that is pointed to by the l Conceptually, the data that Git is storing is something like Figure 9-1. -Insert 18333fig0901.png +Insert 18333fig0901.png Figure 9-1. Simple version of the Git data model. -You can create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a tree object from it. So, to create a tree object, you first have to set up an index by staging some files. To create an index with a single entry — the first version of your text.txt file — you can use the plumbing command `update-index`. You use this command to artificially add the earlier version of the test.txt file to a new staging area. You must pass it the `--add` option because the file doesn’t yet exist in your staging area (you don’t even have a staging area set up yet) and `--cacheinfo` because the file you’re adding isn’t in your directory but is in your database. Then, you specify the mode, SHA-1, and filename: +You can create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a tree object from it. So, to create a tree object, you first have to set up an index by staging some files. To create an index with a single entry — the first version of your test.txt file — you can use the plumbing command `update-index`. You use this command to artificially add the earlier version of the test.txt file to a new staging area. You must pass it the `--add` option because the file doesn’t yet exist in your staging area (you don’t even have a staging area set up yet) and `--cacheinfo` because the file you’re adding isn’t in your directory but is in your database. Then, you specify the mode, SHA-1, and filename: $ git update-index --add --cacheinfo 100644 \ 83baae61804e65cc73a7201a7252750c76066a30 test.txt @@ -141,8 +141,8 @@ You can also verify that this is a tree object: You’ll now create a new tree with the second version of test.txt and a new file as well: $ echo 'new file' > new.txt - $ git update-index test.txt - $ git update-index --add new.txt + $ git update-index test.txt + $ git update-index --add new.txt Your staging area now has the new version of test.txt as well as the new file new.txt. Write out that tree (recording the state of the staging area or index to a tree object) and see what it looks like: @@ -164,7 +164,7 @@ Notice that this tree has both file entries and also that the test.txt SHA is th If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the test.txt file. You can think of the data that Git contains for these structures as being like Figure 9-2. -Insert 18333fig0902.png +Insert 18333fig0902.png Figure 9-2. The content structure of your current Git data. ### Commit Objects ### @@ -241,7 +241,7 @@ Amazing. You’ve just done the low-level operations to build up a Git history w If you follow all the internal pointers, you get an object graph something like Figure 9-3. -Insert 18333fig0903.png +Insert 18333fig0903.png Figure 9-3. All the objects in your Git directory. ### Object Storage ### @@ -326,7 +326,7 @@ Your branch will contain only work from that commit down: Now, your Git database conceptually looks something like Figure 9-4. -Insert 18333fig0904.png +Insert 18333fig0904.png Figure 9-4. Git directory objects with branch head references included. When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create. @@ -335,12 +335,12 @@ When you run commands like `git branch (branchname)`, Git basically runs that `u The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this: - $ cat .git/HEAD + $ cat .git/HEAD ref: refs/heads/master If you run `git checkout test`, Git updates the file to look like this: - $ cat .git/HEAD + $ cat .git/HEAD ref: refs/heads/test When you run `git commit`, it creates the commit object, specifying the parent of that commit object to be whatever SHA-1 value the reference in HEAD points to. @@ -353,7 +353,7 @@ You can also manually edit this file, but again a safer command exists to do so: You can also set the value of HEAD: $ git symbolic-ref HEAD refs/heads/test - $ cat .git/HEAD + $ cat .git/HEAD ref: refs/heads/test You can’t set a symbolic reference outside of the refs style: @@ -375,7 +375,7 @@ That is all a lightweight tag is — a branch that never moves. An annotated tag Here’s the object SHA-1 value it created: - $ cat .git/refs/tags/v1.1 + $ cat .git/refs/tags/v1.1 9585191f37f7b0fb9444f35a9bf50de191beadc2 Now, run the `cat-file` command on that SHA-1 value: @@ -409,7 +409,7 @@ The third type of reference that you’ll see is a remote reference. If you add Then, you can see what the `master` branch on the `origin` remote was the last time you communicated with the server, by checking the `refs/remotes/origin/master` file: - $ cat .git/refs/remotes/origin/master + $ cat .git/refs/remotes/origin/master ca82a6dff817ec66f44342007202690a93763949 Remote references differ from branches (`refs/heads` references) mainly in that they can’t be checked out. Git moves them around as bookmarks to the last known state of where those branches were on those servers. @@ -433,8 +433,8 @@ Let’s go back to the objects database for your test Git repository. At this po Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. You’ll add some larger content to the repository to demonstrate an interesting feature of Git. Add the repo.rb file from the Grit library you worked with earlier — this is about a 12K source code file: - $ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb - $ git add repo.rb + $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb + $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb 3 files changed, 459 insertions(+), 2 deletions(-) @@ -449,14 +449,14 @@ If you look at the resulting tree, you can see the SHA-1 value your repo.rb file 100644 blob 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e repo.rb 100644 blob e3f094f522629ae358806b17daf78246c27c007b test.txt -You can then use `git cat-file` to see how big that object is: +You can then check how big is that object on your disk: - $ git cat-file -s 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e - 12898 + $ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e + 4102 .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e Now, modify that file a little, and see what happens: - $ echo '# testing' >> repo.rb + $ echo '# testing' >> repo.rb $ git commit -am 'modified repo a bit' [master ab1afef] modified repo a bit 1 files changed, 1 insertions(+), 0 deletions(-) @@ -470,10 +470,10 @@ Check the tree created by that commit, and you see something interesting: The blob is now a different blob, which means that although you added only a single line to the end of a 400-line file, Git stored that new content as a completely new object: - $ git cat-file -s 05408d195263d853f09dca71d55116663690c27c - 12908 + $ du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c + 4109 .git/objects/05/408d195263d853f09dca71d55116663690c27c -You have two nearly identical 12K objects on your disk. Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? +You have two nearly identical 4K objects on your disk. Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? It turns out that it can. The initial format in which Git saves objects on disk is called a loose object format. However, occasionally Git packs up several of these objects into a single binary file called a packfile in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the `git gc` command manually, or if you push to a remote server. To see what happens, you can manually ask Git to pack up the objects by calling the `git gc` command: @@ -495,7 +495,7 @@ If you look in your objects directory, you’ll find that most of your objects a The objects that remain are the blobs that aren’t pointed to by any commit — in this case, the "what is up, doc?" example and the "test content" example blobs you created earlier. Because you never added them to any commits, they’re considered dangling and aren’t packed up in your new packfile. -The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 12K in size, the new packfile is only 6K. You’ve halved your disk usage by packing your objects. +The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 8K in size, the new packfile is only 4K. You’ve halved your disk usage by packing your objects. How does Git do this? When Git packs objects, it looks for files that are named and sized similarly, and stores just the deltas from one version of the file to the next. You can look into the packfile and see what Git did to save space. The `git verify-pack` plumbing command allows you to see what was packed up: @@ -510,9 +510,9 @@ How does Git do this? When Git packs objects, it looks for files that are named 484a59275031909e19aadb7c92262719cfcdf19a commit 226 153 169 83baae61804e65cc73a7201a7252750c76066a30 blob 10 19 5362 9585191f37f7b0fb9444f35a9bf50de191beadc2 tag 136 127 5476 - 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e blob 7 18 5193 1 - 05408d195263d853f09dca71d55116663690c27c \ - ab1afef80fac8e34258ff41fc1b867c702daa24b commit 232 157 12 + 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e blob 7 18 5193 1 \ + 05408d195263d853f09dca71d55116663690c27c + ab1afef80fac8e34258ff41fc1b867c702daa24b commit 232 157 12 cac0cab538b970a37ea1e769cbbde608743bc96d commit 226 154 473 d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree 36 46 5316 e3f094f522629ae358806b17daf78246c27c007b blob 1486 734 4352 @@ -522,7 +522,7 @@ How does Git do this? When Git packs objects, it looks for files that are named chain length = 1: 1 object pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack: ok -Here, the `9bc1d` blob, which if you remember was the first version of your repo.rb file, is referencing the `05408` blob, which was the second version of the file. The third column in the output is the size of the object in the pack, so you can see that `05408` takes up 12K of the file but that `9bc1d` only takes up 7 bytes. What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file. +Here, the `9bc1d` blob, which if you remember was the first version of your repo.rb file, is referencing the `05408` blob, which was the second version of the file. The third column in the output is the size of the object’s content, so you can see that the content of `05408` takes up 12K, but that of `9bc1d` only takes up 7 bytes. What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file. The really nice thing about this is that it can be repacked at any time. Git will occasionally repack your database automatically, always trying to save more space. You can also manually repack at any time by running `git gc` by hand. @@ -610,7 +610,7 @@ You can also use the refspec to delete references from the remote server by runn $ git push origin :topic -Because the refspec is `:`, by leaving off the `` part, this basically says to make the topic branch on the remote nothing, which deletes it. +Because the refspec is `:`, by leaving off the `` part, this basically says to make the topic branch on the remote nothing, which deletes it. ## Transfer Protocols ## @@ -632,7 +632,7 @@ Now you have a list of the remote references and SHAs. Next, you look for what t => GET HEAD ref: refs/heads/master -You need to check out the `master` branch when you’ve completed the process. +You need to check out the `master` branch when you’ve completed the process. At this point, you’re ready to start the walking process. Because your starting point is the `ca82a6` commit object you saw in the `info/refs` file, you start by fetching that: => GET objects/ca/82a6dff817ec66f44342007202690a93763949 @@ -783,8 +783,8 @@ The other thing `gc` will do is pack up your references into a single file. Supp If you run `git gc`, you’ll no longer have these files in the `refs` directory. Git will move them for the sake of efficiency into a file named `.git/packed-refs` that looks like this: - $ cat .git/packed-refs - # pack-refs with: peeled + $ cat .git/packed-refs + # pack-refs with: peeled cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0 @@ -854,7 +854,7 @@ It looks like the bottom commit is the one you lost, so you can recover it by cr cac0cab538b970a37ea1e769cbbde608743bc96d second commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit -Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again. +Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again. Next, suppose your loss was for some reason not in the reflog — you can simulate that by removing `recover-branch` and deleting the reflog. Now the first two commits aren’t reachable by anything: $ git branch -D recover-branch @@ -889,7 +889,7 @@ To demonstrate, you’ll add a large file into your test repository, remove it i Oops — you didn’t want to add a huge tarball to your project. Better get rid of it: - $ git rm git.tbz2 + $ git rm git.tbz2 rm 'git.tbz2' $ git commit -m 'oops - removed large tarball' [master da3f30d] oops - removed large tarball From 79a83b05651140ea563c36f176c24615b99b4be3 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 5 Aug 2014 12:55:17 +0200 Subject: [PATCH 145/291] [cs] translation revision of Chapter 2 --- cs/02-git-basics/01-chapter2.markdown | 66 +++++++++++++-------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index 9ea03b7ef..f0932e788 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -726,11 +726,11 @@ V horní polovině okna vidíte historii revizí, doplněnou názorným hierarch ## Rušení změn ## -Kdykoli si můžete přát zrušit nějakou provedenou změnu. Podívejme se proto, jaké základní nástroje se nám tu nabízejí. Ale buďte opatrní! Ne všechny zrušené změny se dají vrátit. Je to jedna z mála oblastí v systému Git, kdy při neuváženém postupu riskujete, že přijdete o část své práce. +Kdykoli se může stát, že byste nějakou úpravu chtěli vrátit do původního stavu.. Podívejme se proto, jaké základní nástroje se nám tu nabízejí. Ale buďte opatrní! Ne všechny zrušené změny se dají vrátit. Je to jedna z mála oblastí v systému Git, kdy při neuváženém postupu riskujete, že přijdete o část své práce. ### Změna poslední revize ### -Jedním z nejčastějších rušení úprav je situace, kdy zapíšete revizi příliš brzy a ještě jste např. zapomněli přidat některé soubory nebo byste rádi změnili zprávu k revizi. Chcete-li opravit poslední revizi, můžete spustit příkaz commit s parametrem `--amend`: +Jedním z nejčastějších důvodů pro rušení úprav je situace, kdy zapíšete revizi příliš brzy a ještě jste například zapomněli přidat některé soubory, nebo byste rádi změnili zprávu k revizi. Chcete-li opravit poslední revizi, můžete spustit příkaz commit s parametrem `--amend`: $ git commit --amend @@ -744,11 +744,11 @@ Pokud například zapíšete revizi a potom si uvědomíte, že jste zapomněli $ git add forgotten_file $ git commit --amend -Tyto tři příkazy vytvoří jedinou revizi – třetí příkaz nahradí výsledky prvního. +Provedení uvedených tří příkazů zůstane jediná revize – druhý příkaz `commit` nahradí výsledky prvního. -### Návrat souboru z oblasti připravených změn ### +### Odstranění souboru z oblasti připravených změn ### -Následující dvě části popisují, jak vrátit změny provedené v oblasti připravených změn a v pracovním adresáři. Je příjemné, že příkaz, jímž se zjišťuje stav těchto dvou oblastí, zároveň připomíná, jak v nich zrušit nežádoucí změny. Řekněme například, že jste změnili dva soubory a chcete je zapsat jako dvě oddělené změny, jenže omylem jste zadali příkaz `git add *` a oba soubory jste tím připravili k zapsání. Jak lze tyto dva soubory vrátit z oblasti připravených změn? Připomene vám to příkaz `git status`: +Následující dvě části popisují, jak se poprat s oblastí připravených změn a se změnami v pracovním adresáři. Je příjemné, že příkaz, jímž se zjišťuje stav těchto dvou oblastí, zároveň připomíná, jak v nich nežádoucí změny zrušit. Řekněme například, že jste změnili dva soubory a chcete je zapsat jako dvě oddělené změny. Jenže omylem jste zadali příkaz `git add *` a oba soubory jste tím připravili k zapsání. Jak lze tyto dva soubory vrátit z oblasti připravených změn? Připomene vám to příkaz `git status`: $ git add . $ git status @@ -803,18 +803,18 @@ Výpis vám sděluje, jak zahodit změny (discard changes), které jste provedli modified: README.txt -Jak vidíte, změny byly zahozeny. Všimněte si také, že se jedná o nebezpečný příkaz. Veškeré změny, které jste v souboru provedli, jsou ztraceny, soubor jste právě překopírovali jiným souborem. Nikdy tento příkaz nepoužívejte, pokud si nejste zcela jisti, že už daný soubor nebudete potřebovat. Pokud potřebujete pouze odstranit soubor z cesty, podívejte se na odkládání a větvení v následující kapitole. Tyto postupy většinou bývají vhodnější. +Jak vidíte, změny byly zahozeny. Všimněte si také, že se jedná o nebezpečný příkaz. Veškeré změny, které jste v souboru provedli, jsou ztraceny, soubor jste právě překopírovali jiným souborem. Nikdy tento příkaz nepoužívejte, pokud si nejste zcela jisti, že už daný soubor nebudete potřebovat. Pokud potřebujete pouze odstranit soubor z cesty, podívejte se na odkládání (stashing) a větvení v následující kapitole. Tyto postupy většinou bývají vhodnější. -Vše, co je zapsáno v systému Git, lze téměř vždy obnovit. Obnovit lze dokonce i revize na odstraněných větvích nebo revize, které byly přepsány revizí `--amend` (o obnovování dat viz kapitola 9). Pokud však dojde ke ztrátě dat, která dosud nebyla součástí žádné revize, bude tato ztráta patrně nevratná. +Zapamatujte si, že vše, co je zapsáno v systému Git, lze téměř vždy obnovit. Obnovit lze dokonce i revize na odstraněných větvích nebo revize, které byly přepsány revizí `--amend` (o obnovování dat viz *kapitola 9*). Pokud však dojde ke ztrátě dat, která dosud nebyla součástí žádné revize, bude tato ztráta patrně nevratná. ## Práce se vzdálenými repozitáři ## -Abyste mohli spolupracovat na projektech v systému Git, je třeba vědět, jak manipulovat se vzdálenými repozitáři (remote repositories). Vzdálené repozitáře jsou verze vašeho projektu umístěné na internetu nebo kdekoli v síti. Vzdálených repozitářů můžete mít hned několik, každý pro vás přitom bude buď pouze ke čtení (read-only) nebo ke čtení a zápisu (read write). Spolupráce s ostatními uživateli zahrnuje také manipulaci s těmito vzdálenými repozitáři. Chcete-li svou práci sdílet, je nutné ji posílat do repozitářů a také ji z nich stahovat. -Při manipulaci se vzdálenými repozitáři je nutné vědět, jak lze přidat vzdálený repozitář, jak odstranit repozitář, který už není platný, jak spravovat různé vzdálené větve, jak je definovat jako sledované či nesledované apod. V této části se zaměříme právě na správu vzdálených repozitářů. +Abyste mohli spolupracovat na projektech v systému Git, je třeba vědět, jak manipulovat se vzdálenými repozitáři (remote repositories). Vzdálené repozitáře jsou verze vašeho projektu umístěné na Internetu nebo kdekoli v síti. Vzdálených repozitářů můžete mít hned několik, každý pro vás přitom bude buď pouze ke čtení (read-only) nebo ke čtení a zápisu (read write). Spolupráce s ostatními uživateli zahrnuje také správu těchto vzdálených repozitářů. Při sdílení práce musíte do těchto repozitářů data odesílat (push) a zase je z nich stahovat (pull). +Při správě vzdálených repozitářů musíte vědět, jak lze přidat vzdálený repozitář, jak odstranit vzdálený repozitář, který už není platný, jak spravovat různé vzdálené větve, jak je definovat jako sledované či nesledované a další věci. V této části se zaměříme právě na správu vzdálených repozitářů. ### Zobrazení vzdálených serverů ### -Chcete-li zjistit, jaké vzdálené servery máte nakonfigurovány, můžete použít příkaz `git remote`. Systém vypíše zkrácené názvy všech identifikátorů vzdálených repozitářů, jež máte zadány. Pokud byl váš repozitář vytvořen klonováním, měli byste vidět přinejmenším server origin. Origin je výchozí název, který Git dává serveru, z nějž jste repozitář klonovali. +Chcete-li zjistit, jaké vzdálené servery máte nakonfigurovány, můžete použít příkaz `git remote`. Systém vypíše krátké názvy, přes které se se vzdálenými repozitáři manipuluje, a které jste dříve určili. Pokud byl váš repozitář vytvořen klonováním, měli byste vidět přinejmenším server *origin*. Jde o výchozí název, který Git dává serveru, z nějž jste repozitář klonovali. $ git clone git://github.com/schacon/ticgit.git Cloning into 'ticgit'... @@ -833,7 +833,7 @@ Můžete rovněž zadat parametr `-v`, jenž zobrazí adresu URL, kterou má Git origin git://github.com/schacon/ticgit.git (fetch) origin git://github.com/schacon/ticgit.git (push) -Pokud máte více než jeden vzdálený repozitář, příkaz je vypíše všechny. Například můj repozitář Grit vypadá takto: +Pokud používáte více než jeden vzdálený repozitář, příkaz je vypíše všechny. Například můj repozitář Grit vypadá takto: $ cd grit $ git remote -v @@ -843,11 +843,11 @@ Pokud máte více než jeden vzdálený repozitář, příkaz je vypíše všech koke git://github.com/koke/grit.git origin git@github.com:mojombo/grit.git -To znamená, že můžeme velmi snadno stáhnout příspěvky od kteréhokoli z těchto uživatelů. Nezapomeňte však, že pouze vzdálený server origin je SSH URL, a je tedy jediným repozitářem, kam lze posílat soubory (důvod objasníme v kapitole 4). +To znamená, že mohu velmi snadno stáhnout příspěvky od kteréhokoli z těchto uživatelů. Ale všimněte si, že pouze vzdálený server origin je SSH URL, a je tedy jediným repozitářem, kam lze soubory odesílat (push; důvod objasníme v *kapitole 4*). ### Přidávání vzdálených repozitářů ### -V předchozích částech už jsem se letmo dotkl přidávání vzdálených repozitářů. V této části se dostávám k tomu, jak přesně při přidávání postupovat. Chcete-li přidat nový vzdálený repozitář Git ve formě zkráceného názvu, na nějž lze snadno odkazovat, spusťte příkaz `git remote add [zkrácený název] [url]`: +V předchozích částech už jsem se letmo dotkl přidávání vzdálených repozitářů. V této části se dostávám k tomu, jak přesně při přidávání postupovat. Chcete-li přidat nový vzdálený repozitář Git a zadat zkrácený název, přes který se můžete snadno odkazovat, spusťte příkaz `git remote add [zkrácený název] [url]`: $ git remote origin @@ -867,7 +867,7 @@ V předchozích částech už jsem se letmo dotkl přidávání vzdálených rep * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit -Paulova hlavní větev (master branch) je lokálně dostupná jako `pb/master`. Můžete ji začlenit do některé ze svých větví nebo tu můžete provést checkout lokální větve, jestliže si ji chcete prohlédnout. +Paulova hlavní větev (master branch) je teď lokálně dostupná jako `pb/master`. Můžete ji začlenit (merge) do některé ze svých větví, nebo ji můžete zpřístupnit jako lokální větev (check out), jestliže si ji chcete prohlédnout. ### Vyzvedávání a stahování ze vzdálených repozitářů ### @@ -875,19 +875,19 @@ Jak jste právě viděli, data ze vzdálených projektů můžete získat pomoc $ git fetch [název vzdáleného repozitáře] -Příkaz zamíří do vzdáleného projektu a stáhne z něj všechna data, která ještě nevlastníte. Poté byste měli mít reference na všechny větve tohoto vzdáleného projektu. Nyní je můžete kdykoli slučovat nebo prohlížet. (Podrobněji se budeme větvím a jejich použití věnovat v kapitole 3.) +Příkaz zamíří do vzdáleného projektu a stáhne z něj všechna data, která ještě nemáte u sebe. Poté byste měli mít k dispozici odkazy na všechny větve tohoto vzdáleného projektu. Od toho okamžiku je můžete kdykoli slučovat nebo prohlížet. (Podrobněji se budeme větvím a jejich použití věnovat v *kapitole 3*.) -Pokud jste naklonovali repozitář, příkaz automaticky přiřadí tento vzdálený repozitář pod název „origin“. Příkaz `git fetch origin` tak vyzvedne veškerou novou práci, která byla na server poslána (push) od okamžiku, kdy jste odsud klonovali (popř. odsud naposledy vyzvedávali práci). Měli bychom zmínit, že příkaz `fetch` stáhne data do vašeho lokálního repozitáře, v žádném případě ale data automaticky nesloučí s vaší prací ani jinak nezmění nic z toho, na čem právě pracujete. Data ručně sloučíte se svou prací, až to uznáte za vhodné. +Pokud jste naklonovali repozitář, příkaz automaticky přidá tento vzdálený repozitář pod názvem *origin*. Takže příkaz `git fetch origin` vyzvedne veškerou novou práci, která byla na uvedený server poslána (push) od okamžiku, kdy jste odtud klonovali (nebo kdy jste odtud naposledy vyzvedávali práci). Měli bychom zmínit, že příkaz `fetch` stáhne data do vašeho lokálního repozitáře. V žádném případě ale data automaticky nesloučí s vaší prací ani jinak nezmění nic z toho, na čem právě pracujete. Sloučení s vaší prací musíte udělat ručně, až to uznáte za vhodné. -Pokud máte větev nastavenou ke sledování vzdálené větve (více informací naleznete v následující části a v kapitole 3), můžete použít příkaz `git pull`, který automaticky vyzvedne a poté začlení vzdálenou větev do vaší aktuální větve. Tento postup pro vás může být snazší a pohodlnější. Standardně přitom příkaz `git clone` automaticky nastaví vaši lokální hlavní větev, aby sledovala vzdálenou hlavní větev na serveru, z nějž jste klonovali (za předpokladu, že má vzdálený server hlavní větev). Příkaz `git pull` většinou vyzvedne data ze serveru, z nějž jste původně klonovali, a automaticky se pokusí začlenit je do kódu, na němž právě pracujete. +Pokud máte větev nastavenou ke sledování vzdálené větve (více informací naleznete v následující části a v *kapitole 3*), můžete použít příkaz `git pull`, který automaticky vyzvedne (fetch) a poté začlení (merge) vzdálenou větev do vaší aktuální větve. Tento postup pro vás může být snazší a pohodlnější. Standardně přitom příkaz `git clone` automaticky nastaví vaši lokální hlavní větev, aby sledovala vzdálenou hlavní větev na serveru, z kterého jste klonovali (za předpokladu, že má vzdálený server hlavní větev). Příkaz `git pull` většinou vyzvedne data ze serveru, z něhož jste původně klonovali, a automaticky se pokusí začlenit je do kódu, na němž právě pracujete. -### Posílání do vzdálených repozitářů ### +### Odesílání do vzdálených repozitářů ### -Pokud se váš projekt nachází ve fázi, kdy ho chcete sdílet s ostatními, můžete ho odeslat (push) na vzdálený server. Příkaz pro tuto akci je jednoduchý: `git push [název vzdáleného repozitáře] [název větve]`. Pokud chcete poslat svou hlavní větev na server `origin` (i tady platí, že proces klonování vám nastaví názvy `master` i `origin` automaticky), můžete k odeslání své práce na server použít tento příkaz: +Pokud se váš projekt nachází ve stavu, kdy ho chcete sdílet s ostatními, můžete ho odeslat (push) na vzdálený server. Příkaz pro tuto akci je jednoduchý: `git push [název vzdáleného repozitáře] [název větve]`. Pokud chcete poslat svou hlavní větev na server `origin` (i tady platí, že proces klonování vám nastaví názvy `master` i `origin` automaticky), můžete k odeslání své práce na server použít tento příkaz: $ git push origin master -Tento příkaz bude funkční, pouze pokud jste klonovali ze serveru, k němuž máte oprávnění pro zápis, a pokud sem od vašeho klonování nikdo neposílal svou práci. Pokud spolu s vámi provádí současně klonování ještě někdo další a ten poté svou práci odešle na server, vaše později odesílaná práce bude oprávněně odmítnuta. Nejprve musíte stáhnout práci ostatních a začlenit ji do své, teprve potom vám server umožní odeslání. Více informací o odesílání na vzdálené servery najdete v kapitole 3. +Tento příkaz bude funkční, pouze pokud jste klonovali ze serveru, k němuž máte oprávnění pro zápis, a pokud sem od vašeho klonování nikdo neposílal svou práci. Pokud spolu s vámi provádí současně klonování ještě někdo další a ten poté svou práci odešle na server, vaše později odesílaná práce bude oprávněně odmítnuta. Nejprve musíte stáhnout práci ostatních a začlenit ji do své, teprve potom vám server umožní odeslání. Více informací o odesílání na vzdálené servery najdete v *kapitole 3*. ### Prohlížení vzdálených repozitářů ### @@ -902,9 +902,9 @@ Jestliže chcete získat více informací o konkrétním vzdáleném repozitář master ticgit -Bude obsahovat adresu URL vzdáleného repozitáře a informace ke sledování větví. Příkaz vám mimo jiné sděluje, že pokud se nacházíte na hlavní větvi (branch master) a spustíte příkaz `git pull`, automaticky začlení (merge) práci do hlavní větve na vzdáleném serveru, jakmile vyzvedne všechny vzdálené reference. Součástí výpisu jsou také všechny vzdálené reference, které příkaz stáhl. +Bude obsahovat adresu URL vzdáleného repozitáře a informace ke sledování větví. Příkaz vám mimo jiné sděluje, že pokud se nacházíte na hlavní větvi (branch `master`) a spustíte příkaz `git pull`, pak se po vyzvednutí všech vzdálených referencí (fetch) práce z hlavní větve na vzdáleném serveru automaticky začlení (merge). Součástí výpisu jsou také všechny vzdálené reference, které příkaz stáhl. -Toto je jednoduchý příklad, s nímž se můžete setkat. Pokud však Git používáte na pokročilé bázi, příkaz `git remote show` vám patrně zobrazí podstatně více informací: +S uvedeným jednoduchým případem se pravděpodobně setkáte. Pokud však Git používáte na intenzivněji, může vám příkaz `git remote show` zobrazit mnohem více informací: $ git remote show origin * remote origin @@ -928,11 +928,11 @@ Toto je jednoduchý příklad, s nímž se můžete setkat. Pokud však Git pou Local branch pushed with 'git push' master:master -Tento příkaz vám ukáže, která větev bude automaticky odeslána, pokud spustíte příkaz `git push` na určitých větvích. Příkaz vám také oznámí, které vzdálené větve na serveru ještě nemáte, které vzdálené větve máte, jež už byly ze serveru odstraněny, a několik větví, které budou automaticky sloučeny, jestliže spustíte příkaz `git pull`. +Tento příkaz ukazuje, která větev bude automaticky odeslána, pokud spustíte příkaz `git push` na určitých větvích. Příkaz vám také oznámí, které vzdálené větve na serveru ještě nemáte, které vzdálené větve máte, ale ze serveru už byly odstraněny, a několik větví, které budou automaticky sloučeny, jestliže spustíte příkaz `git pull`. -### Přesouvání a přejmenovávání vzdálených repozitářů ### +### Odstraňování a přejmenovávání vzdálených repozitářů ### -Chcete-li přejmenovat vzdálený repozitář, můžete v novějších verzích systému Git spustit příkaz `git remote rename`. Příkazem lze změnit zkrácený název vzdáleného repozitáře. Pokud například chcete přejmenovat repozitář z `pb` na `paul`, můžete tak učinit pomocí příkazu `git remote rename`: +Chcete-li změnit zkrácené jméno vzdáleného repozitáře, můžete v novějších verzích systému Git spustit příkaz `git remote rename`. Pokud například chcete přejmenovat repozitář z `pb` na `paul`, můžete tak učinit příkazem `git remote rename`: $ git remote rename pb paul $ git remote @@ -941,7 +941,7 @@ Chcete-li přejmenovat vzdálený repozitář, můžete v novějších verzích Za zmínku stojí, že tímto příkazem změníte zároveň i názvy vzdálených větví. Z původní reference `pb/master` se tak nyní stává `paul/master`. -Chcete-li, ať už z jakéhokoli důvodu, odstranit referenci (např. jste přesunuli server nebo už nepoužíváte dané zrcadlo, popř. přispěvatel přestal přispívat), můžete využít příkaz `git remote rm`: +Chcete-li, ať už z jakéhokoli důvodu, odstranit referenci (přesunuli jste například server nebo už nepoužíváte dané zrcadlo, nebo třeba přispěvatel přestal přispívat), můžete využít příkaz `git remote rm`: $ git remote rm paul $ git remote @@ -949,7 +949,7 @@ Chcete-li, ať už z jakéhokoli důvodu, odstranit referenci (např. jste přes ## Značky ## -Stejně jako většina systémů VCS nabízí i Git možnost označovat v historii určitá místa, jež považujete za důležitá. Tato funkce se nejčastěji používá k označení jednotlivých vydání (např. `v1.0`). V této části vysvětlíme, jak pořídíte výpis všech dostupných značek, jak lze vytvářet značky nové a jaké typy značek se vám nabízejí. +Stejně jako většina systémů VCS nabízí i Git možnost označovat v historii určitá místa, jež považujete za důležitá. Tato funkce se nejčastěji používá k označení jednotlivých vydání (například `v1.0`). V této části vysvětlíme, jak pořídíte výpis všech dostupných značek, jak lze vytvářet značky nové a jaké typy značek se vám nabízejí. ### Výpis značek ### @@ -1127,7 +1127,7 @@ Můžete se podívat, že jste revizi označil: ### Sdílení značek ### -Příkaz `git push` nepřenáší značky na vzdálené servery automaticky. Pokud jste vytvořili značku, budete ji muset na sdílený server poslat ručně. Tento proces je stejný jako sdílení vzdálených větví. Spusťte příkaz `git push origin [název značky]`. +Příkaz `git push` nepřenáší značky na vzdálené servery automaticky. Pokud jste vytvořili značku, budete ji muset na sdílený server poslat explicitně. Tento proces je stejný jako sdílení vzdálených větví. Spusťte příkaz `git push origin [název značky]`. $ git push origin v1.5 Counting objects: 50, done. @@ -1155,17 +1155,17 @@ Pokud nyní někdo bude klonovat nebo stahovat z vašeho repozitáře, stáhne r ## Tipy a triky ## -Než ukončíme tuto kapitolu o základech práce se systémem Git, přidáme ještě pár tipů a triků, které vám mohou usnadnit či zpříjemnit práci. Mnoho uživatelů pracuje se systémem Git, aniž by tyto triky znali a používali. V dalších částech knihy se už o nich nebudeme zmiňovat ani nebudeme předpokládat, že je používáte. Přesto pro vás mohou být užitečné. +Než ukončíme tuto kapitolu věnovanou základům práce se systémem Git, přidáme ještě pár tipů a triků, které vám mohou usnadnit či zpříjemnit práci. Mnoho uživatelů pracuje se systémem Git, aniž by tyto triky znali a používali. V dalších částech knihy se už o nich nebudeme zmiňovat ani nebudeme předpokládat, že je používáte. Přesto pro vás mohou být užitečné. ### Automatické dokončování ### -Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript pro automatické dokončování. Stáhněte si zdrojový kód Git https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Nakopírujte tento soubor do vašeho domovského adresáře a do souboru `.bashrc` přidejte: +Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript pro automatické dokončování. Stáhněte si jej ze zdrojových textů systému Git z https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Soubor nakopírujte tento do vašeho domovského adresáře a do souboru `.bashrc` přidejte: source ~/git-completion.bash -Chcete-li nastavit Git tak, aby měl automaticky dokončování pro shell Bash pro všechny uživatele, zkopírujte tento skript do adresáře `/opt/local/etc/bash_completion.d` v systémech Mac nebo do adresáře `/etc/bash_completion.d/` v systémech Linux. Toto je adresář skriptů, z nějž Bash automaticky načítá pro shellové dokončování. +Chcete-li nastavit Git tak, aby měl automaticky dokončování pro shell Bash pro všechny uživatele, zkopírujte u systému Mac tento skript do adresáře `/opt/local/etc/bash_completion.d`, nebo u systémů Linux do adresáře `/etc/bash_completion.d/`. Jde o adresář skriptů, ze kterého si Bash automaticky načítá podporu pro shellové dokončování. -Pokud používáte Git Bash v systému Windows (Git Bash je výchozím programem při instalaci systému Git v OS Windows pomocí msysGit), mělo by být automatické dokončování přednastaveno. +Pokud používáte Git Bash v systému Windows (Git Bash je pro instalaci msysGit pod Windows výchozím programem), mělo by být automatické dokončování přednastaveno. Při zadávání příkazu Git stiskněte klávesu Tab a měla by se objevit nabídka, z níž můžete zvolit příslušné dokončení: @@ -1174,7 +1174,7 @@ Při zadávání příkazu Git stiskněte klávesu Tab a měla by se objevit nab Pokud zadáte – stejně jako v našem příkladu nahoře – `git co` a dvakrát stisknete klávesu Tab, systém vám navrhne „commit“ a „config“. Doplníte-li ještě `m`, skript automaticky dokončí příkaz na `git commit`. -Automatické dokončování pravděpodobně více využijete v případě parametrů. Pokud například zadáváte příkaz `git log` a nemůžete si vzpomenout na některý z parametrů, můžete zadat jeho začátek a stisknout klávesu Tab, aby vám systém navrhl možná dokončení. +Automatické dokončování pravděpodobně více využijete v případě parametrů. Pokud například zadáváte příkaz `git log` a nemůžete si vzpomenout na některý z parametrů, můžete zadat jeho začátek, stisknout klávesu Tab a podívat se, co by to mohlo přesně být: $ git log --s --shortstat --since= --src-prefix= --stat --summary From 296367f8a8c8e1725a3b717e58899e7d9ca3551e Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 5 Aug 2014 16:30:09 +0200 Subject: [PATCH 146/291] [cs] fixing the markup; minor translation enhancements --- cs/03-git-branching/01-chapter3.markdown | 6 +++--- cs/04-git-server/01-chapter4.markdown | 20 ++++++++++---------- cs/05-distributed-git/01-chapter5.markdown | 2 +- cs/06-git-tools/01-chapter6.markdown | 4 ++-- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index c71858d38..9c4935cd7 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -454,7 +454,7 @@ Tímto způsobem získáte lokální větev, na níž můžete pracovat a která ### Sledující větve ### -Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte tzv. Sledující větev (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na Sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení. +Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte takzvanou *sledující větev* (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na Sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení. Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`: @@ -496,7 +496,7 @@ Víme, že nejjednodušším způsobem, jak integrovat větve, je příkaz `merg Insert 18333fig0328.png Obrázek 3-28. Integrace rozdělené historie sloučením větví -Existuje však ještě jiný způsob. Můžete vzít záplatu se změnou, kterou jste provedli revizí C3, a aplikovat ji na vrcholu revize C4. V systému Git se tato metoda nazývá přeskládání (rebasing). Příkazem `rebase` vezmete všechny změny, které byly zapsány na jedné větvi, a necháte je znovu provést na jiné větvi. +Existuje však ještě jiný způsob. Můžete vzít záplatu se změnou, kterou jste provedli revizí C3, a aplikovat ji na vrcholu revize C4. V systému Git se tato metoda nazývá *přeskládání* (rebasing). Příkazem `rebase` vezmete všechny změny, které byly zapsány na jedné větvi, a necháte je znovu provést na jiné větvi. V našem případě tedy provedete následující: @@ -571,7 +571,7 @@ Obrázek 3-35. Konečná historie revizí Přeskládání sice nabízí určité výhody, má však také svá úskalí. Ta se dají shrnout do jedné věty: -Neprovádějte přeskládání u revizí, které jste odeslali do veřejného repozitáře. +**Neprovádějte přeskládání u revizí, které jste odeslali do veřejného repozitáře.** Budete-li se touto zásadou řídit, nemusíte se přeskládání obávat. V opačném případě vás čeká opovržení ostatních, rodina a přátelé vás zapřou. diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 93147edbe..5e4d1a27c 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -6,7 +6,7 @@ Spuštění serveru Git je jednoduché. Nejprve určíte, jakými protokoly má Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o různých vstupech a výstupech při práci v prostředí s distribuovanou správou zdrojového kódu. -Vzdálený repozitář je obvykle holý repozitář, tj. repozitář Git bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc. +Vzdálený repozitář je obvykle *holý repozitář* (bare repository), tj. repozitář Git bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc. ## Protokoly ## @@ -16,7 +16,7 @@ Neměli bychom zamlčet ani to, že s výjimkou protokolu HTTP všechny vyžaduj ### Protokol Local ### -Nejzákladnější variantou je protokol Local, v němž je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k vašim sdíleným souborům, např. přes připojení systému NFS, nebo – v méně pravděpodobném případě – se všichni přihlašují na jednom počítači. Tato druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou v takovém případě umístěny v jednom počítači, čímž se zvyšuje riziko nevratné ztráty dat. +Nejzákladnější variantou je *lokální protokol* (Local protocol), v němž je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k vašim sdíleným souborům, např. přes připojení systému NFS, nebo – v méně pravděpodobném případě – se všichni přihlašují na jednom počítači. Tato druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou v takovém případě umístěny v jednom počítači, čímž se zvyšuje riziko nevratné ztráty dat. Máte-li připojený sdílený systém souborů, můžete klonovat, odesílat a stahovat z lokálního souborového repozitáře (local file-based repository). Chcete-li takový repozitář naklonovat nebo přidat jako vzdálený repozitář do existujícího projektu, použijte jako URL cestu k repozitáři. K naklonování lokálního repozitáře můžete použít příkaz například v tomto tvaru: @@ -109,7 +109,7 @@ Z dalších výhod protokolu HTTP bychom mohli jmenovat i jeho značné rozší #### Nevýhody #### -Nevýhodou obsluhy repozitáře přes protokol HTTP je poměrně nízká výkonnost pro klienta. Klonovat nebo vyzvedávat data z repozitáře trvá v případě protokolu HTTP obecně mnohem déle a vyžádá si většinou podstatně větší režii síťových operací a objem přenášených dat, než je tomu u ostatních síťových protokolů. Protože protokol není natolik inteligentní, aby přenášel pouze data, která potřebujete – v těchto transakcích se na straně serveru nesetkáte s dynamickou činností – je protokol HTTP často nazýván „dumb protocol“ (hloupý protokol). Více informací o rozdílech ve výkonnosti mezi protokolem HTTP a ostatními protokoly najdete v kapitole 9. +Nevýhodou obsluhy repozitáře přes protokol HTTP je poměrně nízká výkonnost pro klienta. Klonovat nebo vyzvedávat data z repozitáře trvá v případě protokolu HTTP obecně mnohem déle a vyžádá si většinou podstatně větší režii síťových operací a objem přenášených dat, než je tomu u ostatních síťových protokolů. Protože protokol není natolik inteligentní, aby přenášel pouze data, která potřebujete – v těchto transakcích se na straně serveru nesetkáte s dynamickou činností – je protokol HTTP často nazýván *dumb protocol* (hloupý protokol). Více informací o rozdílech ve výkonnosti mezi protokolem HTTP a ostatními protokoly najdete v kapitole 9. ## Jak umístit Git na server ## @@ -148,7 +148,7 @@ Vidíte, jak je jednoduché vzít repozitář Git, vytvořit jeho holou verzi a A to je skutečně vše, co je třeba ke spuštění serveru Git, k němuž bude mít přístup více lidí – na server stačí přidat SSH účty a umístit holý repozitář někam, kam budou mít všichni uživatelé oprávnění ke čtení i zápisu. Vše je připraveno, nic dalšího se od vás nevyžaduje. -V dalších částech se podíváme na některé pokročilé možnosti nastavení. Dozvíte se v nich, jak se vyhnout nutnosti vytvářet uživatelské účty pro všechny uživatele, jak k repozitářům přiřadit veřejné oprávnění pro čtení, jak nastavit webová rozhraní nebo k čemu se používá nástroj Gitosis. To však nemění nic na tom, že ke spolupráci se skupinou lidí na soukromém projektu vystačíte s jedním SSH serverem a holým repozitářem. +V dalších částech se podíváme na některé pokročilé možnosti nastavení. Dozvíte se v nich, jak se vyhnout nutnosti vytvářet uživatelské účty pro všechny uživatele, jak k repozitářům přiřadit veřejné oprávnění pro čtení, jak nastavit webová rozhraní nebo k čemu se používá nástroj Gitosis. To však nemění nic na tom, že ke spolupráci se skupinou lidí na soukromém projektu *vystačíte* s jedním SSH serverem a holým repozitářem. ### Nastavení pro malou skupinu ### @@ -566,7 +566,7 @@ Přidávání dalších uživatelů je snadné. Pokud chceme přidat uživatele Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde uvedu jen pár zajímavých věcí. -Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skupin jsou podobná jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl to je až v momentu, kdy „makro“ použijete. +Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skupin jsou podobná jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl to je až v momentu, kdy „makro“ *použijete*. @oss_repos = linux perl rakudo git gitolite @secret_repos = fenestra pear @@ -597,21 +597,21 @@ Toto pravidlo se pak přidá do skupiny pravidel `gitolite` repozitáře. Teď by vás mohlo zajímat, jak jsou vlastně pravidla pro přístup aplikována, pojďme se na to tedy krátce podívat. -V gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) k jakékoliv referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis. +V gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) *k jakékoliv* referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis. Druhá úroveň je pouze pro práva pro „zápis“ a je podle větve nebo značky v repozitáři. Uživatelské jméno uživatele snažícího se o přístup (`W` nebo `+`) a jméno reference, kterou uživatel chce aktualizovat, jsou dané. Pravidla pro přístup jsou procházena postupně v pořadí, tak jak jsou uvedena v konfiguračním souboru a hledají se záznamy odpovídající této kombinaci uživatelského jména a reference (nezapomeňte ale, že refname se porovnává jako regulární výraz nikoliv jako pouhý řetězec). Jestliže je nalezen odpovídající záznam, odesílání je povoleno. Pokud není nalezeno nic, je přístup zamítnut. -### Rozšířená kontrola přístupu ve větvi „rebel“ ### +### Rozšířené řízení přístupu pravidly typu „odmítnutí“ ### -Jak můžete vidět výše, práva musí být jedno z nastavení `R`, `RW` nebo `RW+`. Dříve zmíněná větev „rebel“ přidává ještě jedno další právo: `-`, znamenající „odmítnutí“. To dává mnohem více možností za cenu zvýšení složitosti, protože nyní už není nenalezení odpovídajícího záznamu při procházení pravidel jedinou možností, jak může být přístup zamítnut. Takže nyní už na pořadí pravidel záleží! +Prozatím jsme si ukázali jen oprávnění nastavená na jednu z hodnot `R`, `RW` nebo `RW+`. Ale Gitolite dovoluje nastavení dalšího oprávnění: `-` s významem „odmítnutí“. To vám dává mnohem více možností, ale za cenu zvýšení složitosti. Popadnutí sítem pravidel už totiž není *jedinou* možností vedoucí k zamítnutí přístupu. *Nyní už záleží na pořadí pravidel!* -Řekněme, že ve výše uvedené situaci budeme chtít, aby skupina engineers mohla vracet změny v jakékoliv větvi s výjimkou větvě „hlavní“ a větve „integ“. To se nedá nastavit pomocí normální syntaxe, ale s pomocí větve „rebel“ podle následujícího postupu: +Řekněme, že ve výše uvedené situaci budeme chtít, aby skupina engineers mohla vracet změny v jakékoliv větvi *s výjimkou* větví `master` a `integ`. Udělá se to následovně: RW master integ = @engineers - master integ = @engineers RW+ = @engineers -Pravidla se znovu budou procházet postupně až do momentu, kdy bude nalezeno odpovídají pravidlo nebo bude přístup zamítnut. Odeslání do hlavní větve nebo větve „integ“, která nevracejí zpět změny, jsou povolena prvním pravidlem. Odeslání, která vracejí změny do těchto větví, neodpovídají prvnímu pravidlu. Porovnají se tedy s druhým pravidlem a na jeho základě budou zamítnuty. Odeslání (bez ohledu na to zda se jedná o vracení změn nebo ne) do jiných referencí než hlavní a „integ“ nebudou odpovídat ani prvnímu ani druhému pravidlu a budou tedy díky třetímu pravidlu povolena. +Pravidla se budou opět procházet shora dolů až do momentu, kdy narazíte na shodu s vaším režimem přístupu nebo na pravidlo typu odmítnutí (deny). Odeslání do větve `master` nebo `integ`, která nevracejí zpět změny (non-rewind push), jsou povolena prvním pravidlem. Odeslání, která vracejí změny (rewind push) do těchto větví, neodpovídají prvnímu pravidlu. Porovnají se tedy s druhým pravidlem a na jeho základě budou zamítnuty. Jakékoliv odeslání (bez ohledu na to zda se jedná o vracení změn nebo ne) do jiných referencí než `master` nebo `integ` nebudou odpovídat ani prvnímu ani druhému pravidlu, a proto bude díky třetímu pravidlu povoleno. ### Omezení odesílání změn vázané na soubory ### diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown index 89140cfe2..f5848226b 100644 --- a/cs/05-distributed-git/01-chapter5.markdown +++ b/cs/05-distributed-git/01-chapter5.markdown @@ -328,7 +328,7 @@ Tady nastává určitý problém. Musí odeslat práci začleněnou ve své vět To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee -Říká se tomu refspec. Více o vzorcích refspec systému Git a různých možnostech, k nimž je lze využít, najdete v kapitole 9. +Říká se tomu *refspec*. Více o vzorcích refspec systému Git a různých možnostech, k nimž je lze využít, najdete v kapitole 9. Poté pošle John Jessice e-mail, že odeslal několik změn do větve `featureA`, a poprosí ji, aby je ověřila. Jessica spustí příkaz `git fetch`, jímž tyto změny stáhne. diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index 987a56217..068bba4c9 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -1095,9 +1095,9 @@ Až poté přepnete zpět, bude adresář `rack` prázdný. Buď můžete spusti ## Začlenění podstromu ## -Nyní, když jsme poznali obtíže spojené se systémem submodulů, podívejme se na jedno alternativní řešení tohoto problému. Git se vždy při slučování nejprve podívá, co a kam začleňuje, a podle toho zvolí vhodnou strategii začlenění. Pokud slučujete dvě větve, používá Git rekurzivní strategii. Pokud slučujete více než dvě větve, zvolí Git tzv. strategii chobotnice (octopus strategy). Git vybírá tyto strategie automaticky. Rekurzivní strategie zvládá složité třícestné slučování (např. s více než jedním společným předkem), ale nedokáže sloučit více než dvě větve. Chobotnicové sloučení dokáže naproti tomu sloučit několik větví, ale je opatrnější při předcházení složitým konfliktům. Proto je ostatně nastaveno jako výchozí strategie při slučování více než dvou větví. +Nyní, když jsme poznali obtíže spojené se systémem submodulů, podívejme se na jedno alternativní řešení tohoto problému. Git se vždy při slučování nejprve podívá, co a kam začleňuje, a podle toho zvolí vhodnou strategii začlenění. Pokud slučujete dvě větve, používá Git *rekurzivní* strategii. Pokud slučujete více než dvě větve, zvolí Git tzv. strategii *chobotnice* (octopus strategy). Git vybírá tyto strategie automaticky. Rekurzivní strategie zvládá složité třícestné slučování (např. s více než jedním společným předkem), ale nedokáže sloučit více než dvě větve. Chobotnicové sloučení dokáže naproti tomu sloučit několik větví, ale je opatrnější při předcházení složitým konfliktům. Proto je ostatně nastaveno jako výchozí strategie při slučování více než dvou větví. -Existují však ještě další strategie. Jednou z nich je tzv. začlenění podstromu (subtree merge), které lze použít jako řešení problémů se subprojektem. Ukažme si, jak se dá začlenit stejný adresář rack jako v předchozí části, tentokrát však s využitím strategie začlenění podstromu. +Existují však ještě další strategie. Jednou z nich je tzv. začlenění *podstromu* (subtree merge), které lze použít jako řešení problémů se subprojektem. Ukažme si, jak se dá začlenit stejný adresář rack jako v předchozí části, tentokrát však s využitím strategie začlenění podstromu. Začlenění podstromu spočívá v tom, že máte dva projekty a jeden z projektů se promítá do podadresáře druhého projektu a naopak. Pokud určíte strategii začlenění podstromu, je Git natolik inteligentní, aby zjistil, že je jeden podstromem druhého, a provedl sloučení odpovídajícím způsobem – počíná si opravdu sofistikovaně. From 9cd87e79edfac532e75c4f273a28a2133644a442 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= Date: Tue, 5 Aug 2014 22:14:40 +0200 Subject: [PATCH 147/291] no-NB translate Ch. 2#Clone an Existing Repository --- no-nb/02-git-basics/01-chapter2.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown index 04d6eb7a3..795cc3dbc 100644 --- a/no-nb/02-git-basics/01-chapter2.markdown +++ b/no-nb/02-git-basics/01-chapter2.markdown @@ -20,23 +20,23 @@ Om du ønsker å starte versjonkontroll på eksisterende filer (imotsetning til $ git add README $ git commit -m 'initial project version' -Vi vil gæ over hva disse kommandoene gjør straks. Nå har du et Git repository med overvåkedne filer og en første kommit. +Vi vil gå over hva disse kommandoene gjør straks. Nå har du et Git repository med overvåkedne filer og en første kommit. -### Cloning an Existing Repository ### +### Klone et Eksistrende Repository ### -If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is `git clone`. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is `clone` and not `checkout`. This is an important distinction — Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run `git clone`. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there — see *Chapter 4* for more details). +Hvis du ænsker å hente en kopi av et eksisterende Git repository, for eksempel, et prosjekt du gjerne vil bidra til, så er kommandoen du trenger `git clone`. Hvis du er kjent med andre VCS systemer som Subversion, så vil du legge merke til at kommandoen er `clone`ikke `checkout`. Dette er en viktig forskjell. Git mottar en kopi av nesten all data som serveren har. Hver version av en hver fil i løpet av prosjektet historie vil bli dratt ned når du kjører `git clone`. Om server disken blir korrupt, så kan du bruke hvilken som helst av klonene på en hvilken som helst klient for å sette til tilstanden den var i når den var klonet (du mister kanskje noen hook-er og slikt på server siden , men all den versjonerte dataen ville vært der. Se *Kapitel 4* for mer detaljer). -You clone a repository with `git clone [url]`. For example, if you want to clone the Ruby Git library called Grit, you can do so like this: +Du kloner et repository med `git clone [url]`. For eksempel, hvis du ænsker å klone Ruby Git biblioteket kalt Grit, så kan du gjøre det slik: $ git clone git://github.com/schacon/grit.git -That creates a directory named `grit`, initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new `grit` directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option: +Det lager en mappe kalt `grit`, initierer en `.git` mappe inni den, og drar ned all dataen fra det repositoriet, og sjekker ut en funksjonell kopi av den nyeste versjonen. Hvis du går inn i den nye `grit`mappen, så vil du se prosjekt filer inni den, klar til å bli bearbeidet eller brukt. Om du ønsker å klone repositoriet inn i en annen mappe kalt noe annet enn grit, så kan du spesifisere det som det neste kommandolinje valget. $ git clone git://github.com/schacon/grit.git mygrit -That command does the same thing as the previous one, but the target directory is called `mygrit`. +Den kommandoen gjør det samme som den forrige, bare at målmappen blir kalt `mygrit`. -Git has a number of different transfer protocols you can use. The previous example uses the `git://` protocol, but you may also see `http(s)://` or `user@server:/path.git`, which uses the SSH transfer protocol. *Chapter 4* will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +Git har tallvis av forskjellige overgangprotokoller du kan bruke. Det forrige eksemplet bruker `git://`-protokollen , men du ser kanskje også `http(s)://` eller `user@server:/path.gti`, som bruker SSH overganprotokollen. *Kapitel 4* vil introdusere alle de tilgjenglige valgene serveren kan sette opp for å gi tilgang til ditt Git repository og fordelen og ulempen med hver av dem. ## Recording Changes to the Repository ## From d68619c89852bddd90ca0f0bdb368fffb7959c15 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 5 Aug 2014 22:34:41 +0200 Subject: [PATCH 148/291] [cs] revision of Chapter 3 finished --- cs/03-git-branching/01-chapter3.markdown | 50 ++++++++++++------------ 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 9c4935cd7..5d486f281 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -1,23 +1,23 @@ # Větve v systému Git # -Téměř každý systém VCS podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste tuto hlavní linii zanášeli. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho. +Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho. -Někteří lidé mluví o modelu větvení v systému Git jako o jeho exkluzivní funkci. Není sporu o tom, že je Git díky tomuto modelu v komunitě VCS poměrně jedinečný. V čem je jeho větvení ojedinělé? Větvení je v systému Git neuvěřitelně lehké a operace s ním související probíhají téměř okamžitě. Stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů VCS Git podporuje způsob práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. +Někteří lidé mluví o modelu větvení v systému Git jako o jeho „vražedné vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. ## Co je to větev ## Abychom skutečně pochopili, jak funguje v systému Git větvení, budeme se muset vrátit o krok zpět a podívat se, jak Git ukládá data. Jak si možná vzpomínáte z kapitoly 1, Git neukládá data jako sérii změn nebo rozdílů, ale jako sérii snímků. -Zapíšete-li v systému Git revizi, Git uloží objekt revize, obsahující ukazatel na snímek obsahu, který jste určili k zapsání, metadata o autorovi a zprávě a nula nebo více ukazatelů na revizi nebo revize, které byly přímými rodiči této revize – žádné rodiče nemá první revize, jednoho rodiče má běžná revize a několik rodičů mají revize, které vznikly sloučením ze dvou či více větví. +Zapíšete-li v systému Git revizi, Git uloží objekt revize, obsahující ukazatel na snímek obsahu, který jste určili k zapsání, metadata o autorovi a zprávě a nula nebo více ukazatelů na revizi nebo revize, které byly přímými rodiči této revize: žádné rodiče nemá první revize, jednoho rodiče má běžná revize a několik rodičů mají revize, které vznikly sloučením ze dvou či více větví. -Pro ilustraci předpokládejme, že máte adresář se třemi soubory, které připravíte k zapsání a následně zapíšete. S připravením souborů k zapsání proběhne u každého z nich kontrolní součet (o otisku SHA-1 jsme se zmínili v kapitole 1), daná verze souborů se uloží v repozitáři Git (Git na ně odkazuje jako na bloby) a přidá jejich kontrolní součet do oblasti připravených změn: +Pro ilustraci předpokládejme, že máte adresář se třemi soubory, které připravíte k zapsání a následně zapíšete. Při přípravě souborů k zapsání je pro každý z nich vypočítán kontrolní součet (o otisku SHA-1 jsme se zmínili v kapitole 1), daná verze souborů se uloží v repozitáři Git (Git na ně odkazuje jako na bloby) a přidá jejich kontrolní součet do oblasti připravených změn: $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' Vytvoříte-li revizi příkazem `git commit`, provede Git kontrolní součet každého adresáře (v tomto případě pouze kořenového adresáře projektu) a uloží tyto objekty stromu v repozitáři Git. Poté vytvoří objekt revize s metadaty a ukazatelem na kořenový strom projektu, aby mohl v případě potřeby tento snímek obnovit. -Váš repozitář Git nyní obsahuje pět objektů: jeden blob pro obsah každého ze tří vašich souborů, jeden strom, který zaznamenává obsah adresáře a udává, které názvy souborů jsou uloženy jako který blob, a jednu revizi s ukazatelem na kořenový strom a se všemi metadaty revize. Data ve vašem repozitáři Git se dají schematicky znázornit jako na obrázku 3-1. +Váš gitovský repozitář nyní obsahuje pět objektů: jeden blob pro obsah každého ze tří vašich souborů, jeden strom, který zaznamenává obsah adresáře a udává, které názvy souborů jsou uloženy jako který blob, a jeden objekt revize s ukazatelem na kořenový strom a se všemi metadaty revize. Data ve vašem repozitáři Git se dají schematicky znázornit jako na obrázku 3-1. Insert 18333fig0301.png Obrázek 3-1. Repozitář s daty jedné revize @@ -41,7 +41,7 @@ Tento příkaz vytvoří nový ukazatel na stejné revizi, na níž se právě n Insert 18333fig0304.png Obrázek 3-4. Několik větví ukazujících do historie dat revizí -Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem `git branch` jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5). +Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech pro správu verzí, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem `git branch` jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5). Insert 18333fig0305.png Obrázek 3-5. Soubor HEAD ukazující na větev, na níž se nacházíte. @@ -86,11 +86,11 @@ Nyní se historie vašeho projektu rozdělila (viz obrázek 3-9). Vytvořili jst Insert 18333fig0309.png Obrázek 3-9. Historie větví se rozdělila. -Vzhledem k tomu, že větev v systému Git tvoří jeden jednoduchý soubor, obsahující 40 znaků kontrolního součtu SHA-1 revize, na niž ukazuje, je snadné větve vytvářet i odstraňovat. Vytvořit novou větev je právě tak snadné a rychlé jako zapsat 41 bytů do souboru (40 znaků a jeden nový řádek). +Vzhledem k tomu, že větev v systému Git tvoří jeden jednoduchý soubor, obsahující 40 znaků kontrolního součtu SHA-1 revize, na niž ukazuje, je snadné větve vytvářet i odstraňovat. Vytvořit novou větev je právě tak snadné a rychlé jako zapsat 41 bytů do souboru (40 znaků a jeden znak pro nový řádek). Tato metoda se výrazně liší od způsobu, jakým probíhá větvení v ostatních nástrojích VCS, kde je nutné zkopírovat všechny soubory projektu do jiného adresáře. To může zabrat – podle velikosti projektu – několik sekund i minut, zatímco v systému Git probíhá tento proces vždy okamžitě. A protože při zapisování revize zaznamenáváme její rodiče, probíhá vyhledávání příslušné základny pro sloučení automaticky a je většinou velmi snadné. Tyto funkce slouží k tomu, aby se vývojáři nebáli vytvářet a používat nové větve. -Podívejme se, jaké výhody jim z toho plynou. +Podívejme se, proč byste to měli dělat také tak. ## Základy větvení a slučování ## @@ -100,7 +100,7 @@ Vytvořme si jednoduchý příklad větvení a slučování s pracovním postupe 2. Vytvoříte větev pro novou část stránek, v níž budete pracovat. 3. Vytvoříte práci v této větvi. -V tomto okamžiku vám zavolají, že se vyskytla jiná kritická chyba, která vyžaduje hotfix. Uděláte následující: +V tomto okamžiku vám zavolají, že se vyskytla jiná kritická chyba, která vyžaduje rychlou opravu (hotfix). Uděláte následující: 1. Vrátíte se zpět na produkční větev. 2. Vytvoříte větev pro přidání hotfixu. @@ -129,7 +129,7 @@ Obrázek 3-11 ukazuje výsledek. Insert 18333fig0311.png Obrázek 3-11. Vytvoření nového ukazatele na větev -Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že jste na ni přepnuli a ukazuje na ni soubor HEAD – viz obrázek 3-12): +Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že na ni přepnuli ukazuje HEAD – viz obrázek 3-12): $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' @@ -139,12 +139,12 @@ Obrázek 3-12. Větev iss53 se s vaší prací posouvá vpřed. V tomto okamžiku vám zavolají, že se na webových stránkách vyskytl problém, který musíte okamžitě vyřešit. Jelikož pracujete v systému Git, nemusíte svou opravu vytvářet uprostřed změn, které jste provedli v části `iss53`, ani nemusíte dělat zbytečnou práci, abyste všechny tyto změny vrátili, než budete moci začít pracovat na opravě produkční verze stránek. Jediné, co teď musíte udělat, je přepnout zpět na hlavní větev. -Než tak učiníte, zkontrolujte, zda nemáte v pracovním adresáři nebo v oblasti připravených změn nezapsané změny, které kolidují s větví, jejíž checkout provádíte. V takovém případě by vám Git přepnutí větví nedovolil. Při přepínání větví je ideální, pokud máte čistý pracovní stav. Existují způsoby, jak toho docílit (jmenovitě odložení a doplnění revize), těm se však budeme věnovat až později. Pro tuto chvíli jste zapsali všechny provedené změny a můžete přepnout zpět na hlavní větev. +Než tak učiníte, zkontrolujte, zda nemáte v pracovním adresáři nebo v oblasti připravených změn nezapsané změny, které kolidují s větví, jejíž checkout provádíte. V takovém případě by vám Git přepnutí větví nedovolil. Při přepínání větví je ideální, pokud máte čistý pracovní stav. Existují způsoby, jak to obejít (jmenovitě odložení (stashing) a doplnění revize (commit amending)), těm se však budeme věnovat až později. Pro tuto chvíli jste zapsali všechny provedené změny a můžete přepnout zpět na hlavní větev. $ git checkout master Switched to branch 'master' -V tomto okamžiku vypadá váš pracovní adresář přesně tak, jak vypadal, než jste začali pracovat na chybě č. 53, a vy se nyní můžete soustředit na rychlou opravu. Na paměti byste však stále měli mít následující: Git vždy vrátí pracovní adresář do stejného stavu, jak vypadal snímek revize, na niž ukazuje větev, jejíž checkout nyní provádíte. Automaticky budou přidány, odstraněny a upraveny soubory tak, aby byla vaše pracovní kopie totožná se stavem větve v okamžiku, kdy jste na ni zapsali poslední revizi. +V tomto okamžiku vypadá váš pracovní adresář přesně tak, jak vypadal, než jste začali pracovat na chybě č. 53, a vy se nyní můžete soustředit na rychlou opravu. Tento důležitý bod si zapamatujte: Git vždy vrátí pracovní adresář do stejného stavu, jak vypadal snímek revize, na niž ukazuje větev, jejíž checkout nyní provádíte. Automaticky budou přidány, odstraněny a upraveny soubory tak, aby byla vaše pracovní kopie totožná se stavem větve v okamžiku, kdy jste na ni zapsali poslední revizi. Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme pracovat, dokud nebude oprava hotová (viz obrázek 3-13): @@ -158,7 +158,7 @@ Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme p Insert 18333fig0313.png Obrázek 3-13. Větev „hotfix“ začleněná zpět v místě hlavní větve -Můžete provádět testování, ujistit se, že hotfix splňuje všechny požadavky, a pak můžete větev začlenit (merge) zpět do hlavní větve, aby byla připravena do produkce. Učiníte tak příkazem `git merge`: +Můžete spustit testy, abyste se ujistili, že hotfix splňuje všechny požadavky, a pak můžete větev začlenit (merge) zpět do hlavní větve, aby byla připravena do produkce. Učiníte tak příkazem `git merge`: $ git checkout master $ git merge hotfix @@ -191,7 +191,7 @@ Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na c Insert 18333fig0315.png Obrázek 3-15. Větev iss53 může nezávisle postupovat vpřed. -Za zmínku stojí, že práce, kterou jste udělali ve větvi `hotfix`, není obsažena v souborech ve větvi `iss53`. Pokud potřebujete tyto změny do větve natáhnout, můžete začlenit větev `master` do větve `iss53` – použijte příkaz `git merge master`. Druhou možností je s integrací změn vyčkat a provést ji až ve chvíli, kdy budete chtít větev `iss53` natáhnout zpět do větve `master`. +Za zmínku stojí, že práce, kterou jste udělali ve větvi `hotfix`, není obsažena v souborech ve větvi `iss53`. Pokud potřebujete tyto změny do větve vtáhnout, můžete začlenit větev `master` do větve `iss53` provedením příkazu `git merge master`. Druhou možností je s integrací změn vyčkat a provést ji až ve chvíli, kdy budete chtít větev `iss53` vtáhnout zpět do větve `master`. ### Základní slučování ### @@ -211,7 +211,7 @@ Obrázek 3-16. Git automaticky identifikuje nejvhodnějšího společného před Git tentokrát neposune ukazatel větve vpřed, ale vytvoří nový snímek jako výsledek tohoto třícestného sloučení a automaticky vytvoří novou revizi, která bude na snímek ukazovat (viz obrázek 3-17). Takové revizi se říká revize sloučením (merge commit) a její zvláštností je to, že má více než jednoho rodiče. -Na tomto místě bych chtěl zopakovat, že Git určuje nejvhodnějšího společného předka, který bude použit jako základna pro sloučení, automaticky. Liší se tím od systému CVS i Subversion (před verzí 1.5), kde musí vývojář při slučování najít nejvhodnější základnu pro sloučení sám. Slučování větví je tak v systému Git o poznání jednodušší než v těchto ostatních systémech. +Na tomto místě bych chtěl zopakovat, že Git určuje nejvhodnějšího společného předka, který bude použit jako základna pro sloučení, automaticky. Liší se tím od systému CVS i Subversion (před verzí 1.5), kde musí vývojář při slučování najít nejvhodnější základnu pro sloučení sám. Slučování větví je proto v systému Git o poznání jednodušší než v ostatních systémech. Insert 18333fig0317.png Obrázek 3-17. Git automaticky vytvoří nový objekt revize, který obsahuje sloučenou práci. @@ -243,7 +243,7 @@ Git nepřistoupil k automatickému vytvoření nové revize sloučením. Prozat no changes added to commit (use "git add" and/or "git commit -a") -Vše, co při sloučení kolidovalo a nebylo vyřešeno, je označeno jako „unmerged“ (nesloučeno). Git přidává ke kolidujícím souborům standardní poznámky o řešení konfliktů (conflict-resolution markers), takže je můžete ručně otevřít a konflikty vyřešit. Jedna část vašeho souboru bude vypadat zhruba takto: +Vše, co při sloučení kolidovalo a nebylo vyřešeno, je označeno jako „unmerged“ (nesloučeno). Git přidává ke kolidujícím souborům standardní značky pro označení konfliktů (conflict-resolution markers), takže soubor můžete ručně otevřít a konflikty vyřešit. Jedna část vašeho souboru bude vypadat zhruba takto: <<<<<<< HEAD @@ -352,7 +352,7 @@ Teď, když jste absolvovali základní seznámení s větvemi a jejich slučov Vzhledem k tomu, že Git používá jednoduché třícestné slučování, je velmi snadné začleňovat jednu větev do druhé i několikrát v rámci dlouhého časového intervalu. Můžete tak mít několik větví, které jsou stále otevřené a které používáte pro různé fáze vývojového cyklu. Pravidelně můžete začleňovat práci z jedné větve do ostatních. -Mnoho vývojářů systému Git používá pracovní postup, kdy mají ve větvi `master` pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Ta se pak používá se k začleňování do tematických větví (těch dočasných, jako byla vaše větev `iss53`) ve chvíli, kdy je k tomu vše připraveno a nehrozí, že práce neprojde testy nebo bude způsobovat chyby. +Mnoho vývojářů systému Git používá pracovní postup, kdy mají ve větvi `master` pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Do ní se vtahují tématické větve (ty dočasné, jako byla vaše větev `iss53`) ve chvíli, kdy jsou připravené a je jisté, že projdou všemi testy a nezavlečou chyby. Ve skutečnosti hovoříme o ukazatelích pohybujících se vzhůru po linii revizí, které zapisujete. Stabilní větve leží v linii historie revizí níže a nové, neověřené větve se nacházejí nad nimi (viz obrázek 3-18). @@ -369,11 +369,11 @@ Není nutné používat při práci několik dlouhých větví, ale často to m ### Tematické větve ### -Naproti tomu tematické větve se vám budou hodit v projektech jakékoli velikosti. Tematická větev (topic branch) je krátkodobá větev, kterou vytvoříte a používáte pro jediný konkrétní účel nebo práci. Je to záležitost, do které byste se ve VCS asi raději nikdy nepustili, protože vytvářet a slučovat větve je v něm opravdu složité. V systému Git naopak není výjimkou vytvářet, používat, slučovat a mazat větve i několikrát denně. +Naproti tomu tematické větve se vám budou hodit v projektech jakékoli velikosti. Tematická větev (topic branch) je krátkodobá větev, kterou vytvoříte a používáte pro jediný konkrétní účel nebo práci. Je to záležitost, do které byste se v jiném systému pro správu verzí asi raději nikdy nepustili, protože vytvářet a slučovat větve je v něm opravdu složité. V systému Git naopak není výjimkou vytvářet, používat, slučovat a mazat větve i několikrát denně. -Viděli jste to v předchozí části, kdy jste si vytvořili větve `iss53` a `hotfix`. Provedli jste v nich pár revizí a smazali jste je hned po začlenění změn do hlavní větve. Tato technika umožňuje rychlé a kompletní kontextové přepínání. Protože je vaše práce rozdělena do zásobníků, kde všechny změny v jedné větvi souvisí s jedním tématem, je při kontrole kódu snazší dohledat, čeho se změny týkaly apod. Změny tu můžete uchovávat několik minut, dní i měsíců a začlenit je přesně ve vhodnou chvíli. Na pořadí, v jakém byly větve vytvořeny nebo vyvíjeny, nezáleží. +Viděli jste to v předchozí části, kdy jste si vytvořili větve `iss53` a `hotfix`. Provedli jste v nich pár revizí a smazali jste je hned po začlenění změn do hlavní větve. Tato technika umožňuje rychlé a snadné kontextové přepínání. Protože je vaše práce rozdělena do zásobníků, kde všechny změny v jedné větvi souvisí s jedním tématem, je při kontrole kódu snazší dohledat, čeho se změny týkaly apod. Změny tu můžete uchovávat několik minut, dní i měsíců a začlenit je přesně ve vhodnou chvíli. Na pořadí, v jakém byly větve vytvořeny nebo vyvíjeny, nezáleží. -Uvažujme nyní následující situaci: pracujete na projektu v hlavní větvi (`master`), odbočíte z ní k vyřešení jednoho problému (`iss91`), chvíli na něm pracujete, ale vytvoříte ještě další větev, abyste zkusili jiné řešení stejné chyby (`iss91v2`). Pak se vrátíte zpět na hlavní větev, kde pokračujete v práci, než dostanete nápad, který by se možná mohl osvědčit, a tak pro něj vytvoříte další větev (`dumbidea`). Historie revizí bude vypadat zhruba jako na obrázku 3-20. +Uvažujme nyní následující situaci: pracujete na projektu v hlavní větvi (`master`), odvětvíme se z ní k vyřešení jednoho problému (`iss91`), chvíli na něm pracujete, ale vytvoříte ještě další větev, abyste zkusili jiné řešení stejné chyby (`iss91v2`). Pak se vrátíte zpět do hlavní větve, kde pokračujete v práci, a pak dostanete nápad, který by se možná mohl osvědčit, a tak pro něj vytvoříte další větev (`dumbidea`). Historie revizí bude vypadat zhruba jako na obrázku 3-20. Insert 18333fig0320.png Obrázek 3-20. Historie revizí s několika tematickými větvemi @@ -401,7 +401,7 @@ Pokud nyní budete pracovat na své lokální hlavní větvi a někdo z kolegů Insert 18333fig0323.png Obrázek 3-23. Pokud pracujete lokálně a někdo jiný odešle svou práci na vzdálený server, obě historie se rozejdou. -K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je „origin“ (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24). +K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je `origin` (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24). Insert 18333fig0324.png Obrázek 3-24. Příkaz `git fetch` aktualizuje vaše reference na vzdálený server. @@ -454,9 +454,9 @@ Tímto způsobem získáte lokální větev, na níž můžete pracovat a která ### Sledující větve ### -Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte takzvanou *sledující větev* (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na Sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení. +Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte takzvanou *sledující větev* (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení. -Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`: +Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují samy od sebe i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`: $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. @@ -545,7 +545,7 @@ Nyní můžete posunout hlavní větev „rychle vpřed“ (viz obrázek 3-33): Insert 18333fig0333.png Obrázek 3-33. Posun hlavní větve rychle vpřed na konec změn přeskládaných z větve client -Řekněme, že se později rozhodnete natáhnout i větev server. Větev server můžete přeskládat na hlavní větev příkazem `git rebase [základna] [tematická větev]`. Příkaz provede checkout tematické větve (v tomto případě větve `server`) a přeskládá její změny na základnu (angl. base branch, v tomto případě `master`): +Řekněme, že se později rozhodnete vtáhnout i větev server. Větev server můžete přeskládat na hlavní větev příkazem `git rebase [základna] [tematická větev]`. Příkaz provede checkout tematické větve (v tomto případě větve `server`) a přeskládá její změny na základnu (angl. base branch, v tomto případě `master`): $ git rebase master server @@ -573,7 +573,7 @@ Přeskládání sice nabízí určité výhody, má však také svá úskalí. T **Neprovádějte přeskládání u revizí, které jste odeslali do veřejného repozitáře.** -Budete-li se touto zásadou řídit, nemusíte se přeskládání obávat. V opačném případě vás čeká opovržení ostatních, rodina a přátelé vás zapřou. +Budete-li se touto zásadou řídit, nemusíte se přeskládání obávat. V opačném případě vás čeká nenávist ostatních a rodina a přátelé vás zavrhnou. Při přeskládání dat zahodíte existující revize a vytvoříte nové, které jsou jim podobné, ale přesto jiné. Pokud odešlete svou práci, ostatní si ji stáhnou a založí na nich svou práci. A vy potom tyto revize přepíšete příkazem `git rebase` a znovu je odešlete, vaši spolupracovníci do ní budou muset znovu začlenit svou práci a ve všem nastane chaos, až se pokusíte natáhnout jejich práci zpět do své. From a4fa9be029aef760495b1374b7be16951645fe73 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Wed, 6 Aug 2014 08:11:16 +0200 Subject: [PATCH 149/291] [cs] minor formulation correction in chapter 2 --- cs/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index f0932e788..bb25003fd 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -139,7 +139,7 @@ Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští re modified: benchmarks.rb -Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor k zapsání ve přesně tak, jak vypadá v daném okamžiku. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal, když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru: +Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor k zapsání přesně ve tvaru, v jakém se nachází v daném okamžiku. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal, když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru: $ git add benchmarks.rb $ git status From bf1ea661c94855b55f5a9144ca209fe3eecc4d51 Mon Sep 17 00:00:00 2001 From: annoab Date: Sat, 30 Nov 2013 23:09:31 +0100 Subject: [PATCH 150/291] Update 01-chapter1.markdown Few mispelled word --- fr/01-introduction/01-chapter1.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown index 2fda80793..8a0868fcc 100644 --- a/fr/01-introduction/01-chapter1.markdown +++ b/fr/01-introduction/01-chapter1.markdown @@ -291,10 +291,10 @@ Ces variables peuvent être stockées dans trois endroits différents : Si vous passez l'option `--system` à `git config`, il lit et écrit ce fichier spécifiquement. * Fichier `~/.gitconfig` : Spécifique à votre utilisateur. Vous pouvez forcer Git à lire et écrire ce fichier en passant l'option `--global`. -* Fichier `config` dans le répertoire Git (c'est à dire `.git/config`) du dépôt en cours d'utilisation : spécifique au seul dépôt en cours. +* Fichier `config` dans le répertoire Git (c'est-à-dire `.git/config`) du dépôt en cours d'utilisation : spécifique au seul dépôt en cours. Chaque niveau surcharge le niveau précédent, donc les valeurs dans `.git/config` surchargent celles de `/etc/gitconfig`. -Sur les systèmes Windows, Git recherche le fichier `.gitconfig` dans le répertoire `$HOME` (`%USERPROFILE%` dans l'environement natif de Windows) qui est `C:\Documents and Settings\$USER` ou `C:\Users\$USER` la plupart du temps, selon la version (`$USER` devient `%USERNAME%` dans l'environement de Windows). +Sur les systèmes Windows, Git recherche le fichier `.gitconfig` dans le répertoire `$HOME` (`%USERPROFILE%` dans l’environnement natif de Windows) qui est `C:\Documents and Settings\$USER` ou `C:\Users\$USER` la plupart du temps, selon la version (`$USER` devient `%USERNAME%` dans l’environnement de Windows). Il recherche tout de même `/etc/gitconfig`, bien qu'il soit relatif à la racine MSys, qui se trouve où vous aurez décidé d'installer Git sur votre système Windows. ### Votre identité ### From 8dda255d5c80d2d6d4e47ae53aceb10f491d5a03 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 6 Aug 2014 22:36:27 +0200 Subject: [PATCH 151/291] Reviewing chapter name --- it/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown index 4ec820877..55d98c233 100644 --- a/it/04-git-server/01-chapter4.markdown +++ b/it/04-git-server/01-chapter4.markdown @@ -111,7 +111,7 @@ Un'altra cosa carina è che l'HTTP è un protocollo comunissimo che i firewall d L'altra faccia della medaglia nel fornire il tuo repository via HTTP è che è relativamente inefficiente per il client. In genere porta via molto tempo per clonare o scaricare dal repository, e si ha spesso un sovraccarico della rete tramite il trasferimento di volumi via HTTP rispetto ad altri protocolli di rete. Non essendo abbastanza intelligente da trasferire solo i dati di cui hai bisogno — non c'è un lavoro dinamico dalla parte del server in questa transazione — il protocollo HTTP viene spesso definito un protocollo _stupido_. Per maggiori informazioni sulle differenze nell'efficienza tra il protocollo HTTP e gli altri, vedi il Capitolo 9. -## Ottenere Git su di un Server ## +## Mettere Git su di un server ## Per inizializzare un qualsiasi server Git, devi esportare un repository esistente in un nuovo repository di soli dati — cioè un repository che non contiene la directory di lavoro. Questo è generalmente molto semplice da fare. Per clonare il tuo repository per creare un nuovo repository di soli dati, devi avviare il comando clone con l'opzione `--bare`. Convenzionalmente, un repository di soli dati in finisce in `.git`, ad esempio: From ff3b6ff0aa032f7d1542a9c9b542fc11697a534a Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 6 Aug 2014 22:39:08 +0200 Subject: [PATCH 152/291] Rewording sentence --- it/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown index 55d98c233..431538b69 100644 --- a/it/04-git-server/01-chapter4.markdown +++ b/it/04-git-server/01-chapter4.markdown @@ -231,7 +231,7 @@ L'autenticazione tramite chiavi SSH generalmente richiede una restrizione dei di $ chmod -R go= ~/.ssh -Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro: +Ora, puoi configurargli un repository vuoto eseguendo `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro: $ cd /opt/git $ mkdir project.git From bbcc26cd7942d6c45487dc2ffda0af280d9ccb14 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 6 Aug 2014 22:44:25 +0200 Subject: [PATCH 153/291] Updating chapter6 with changes from PR#805 --- it/06-git-tools/01-chapter6.markdown | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown index 7d684617d..e358907eb 100644 --- a/it/06-git-tools/01-chapter6.markdown +++ b/it/06-git-tools/01-chapter6.markdown @@ -708,7 +708,7 @@ Once again, this changes the SHAs of all the commits in your list, so make sure ### The Nuclear Option: filter-branch ### -There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. +There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. #### Removing a File from Every Commit #### @@ -748,6 +748,12 @@ Another common case is that you forgot to run `git config` to set your name and This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address. +### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner (BFG) ### + +[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capaility, and you have performance issues, then you should consider using it. + +See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details. + ## Debugging with Git ## Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong. From 3ca4fdc628b553edab2ff5d3ebca6f26aaa5d97c Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 6 Aug 2014 22:44:39 +0200 Subject: [PATCH 154/291] Translating changes from PR#805 --- it/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/it/08-git-and-other-scms/01-chapter8.markdown b/it/08-git-and-other-scms/01-chapter8.markdown index 7eb703c2c..2e460254b 100644 --- a/it/08-git-and-other-scms/01-chapter8.markdown +++ b/it/08-git-and-other-scms/01-chapter8.markdown @@ -328,6 +328,17 @@ Puoi ottenere le infommazioni disponibili con `svn info` eseguendo `git svn info Come per `blame` e `log`, le informazioni vengono ricercate offline e sono aggiornate all'ultima volta che si è comunicato con il server Subversion. +Suggerimento: Se il tuo script di compilazione deve poter eseguire `svn info` è meglio porre un wrapper attorno a git. +Qui c'è un esempio per i tuoi esperimenti: + + #!/usr/bin/env bash + + if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then + git svn info + else + /usr/local/bin/svn "$@" + fi + #### Ignorare ciò che Subversion ignora #### Se cloni un repository Subversion che abbia definito delle proprietà `svn:ignore`, vorrai avere un file `.gitignore` con le stesse proprietà per evitare di committare qualcosa che non dovresti. `git svn` ha due comandi per aiutarti a risolvere questo problema. Il primo, `git svn create-ignore`, crea automaticamente i file `.gitignore`, in modo che la committ successiva li includa. From b324e3078ca212973fea2e9e11ae03fd75cf0c5e Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Wed, 6 Aug 2014 22:46:41 +0200 Subject: [PATCH 155/291] Translating changes from PR#751 --- it/07-customizing-git/01-chapter7.markdown | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 78b49f917..c65d63bbf 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -534,6 +534,10 @@ Questo è utile se un ramo nel progetto presenta divergenze o è specializzato, database.xml merge=ours +Definisci quindi una strategia di merge fittizia chiamata `ours`: + + git config --global merge.ours.driver true + Nel caso si voglia fare un merge nell'altro ramo, invece di avere conflitti di merge con il file database.xml, si noterà qualcosa di simile a: $ git merge topic From d91bd055343ffec3882c4f988545bc37e2b230b0 Mon Sep 17 00:00:00 2001 From: Ming-Yang Kao Date: Thu, 7 Aug 2014 16:50:15 +0800 Subject: [PATCH 156/291] Correct chapter 2 typo --- zh-tw/02-git-basics/01-chapter2.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown index f637fa8f4..7ffc67937 100644 --- a/zh-tw/02-git-basics/01-chapter2.markdown +++ b/zh-tw/02-git-basics/01-chapter2.markdown @@ -30,7 +30,7 @@ $ git clone git://github.com/schacon/grit.git -接下來會有個名為`grit`的目錄被建立，並在其下初始化名為`.git`的目錄。 拉下所有存在該儲存庫的所有資料，並取出最新版本為工作複本。 若讀者進入新建立的 `grit` 目錄，會看到專案的檔案都在這兒，且可使用。 若讀者想畏複製儲存庫到grit以外其它名字的目錄，只需要在下一個參數指定即可： +接下來會有個名為`grit`的目錄被建立，並在其下初始化名為`.git`的目錄。 拉下所有存在該儲存庫的所有資料，並取出最新版本為工作複本。 若讀者進入新建立的 `grit` 目錄，會看到專案的檔案都在這兒，且可使用。 若讀者想要複製儲存庫到grit以外其它名字的目錄，只需要在下一個參數指定即可： $ git clone git://github.com/schacon/grit.git mygrit @@ -299,7 +299,7 @@ A `**/` pattern is available in Git since version 1.8.2. ### 提交修改 ### -現在讀者的暫存區域已被更新為讀者想畏的，可開始提交變更的部份。 要記得任何尚未被暫存的新建檔案或已被修改但尚未使用git add暫存的檔案將不會被記錄在本次的提交中。 它們仍會以被修改的檔案的身份存在磁碟中。 +現在讀者的暫存區域已被更新為讀者想要的，可開始提交變更的部份。 要記得任何尚未被暫存的新建檔案或已被修改但尚未使用git add暫存的檔案將不會被記錄在本次的提交中。 它們仍會以被修改的檔案的身份存在磁碟中。 在這情況下，最後一次執行`git status`，讀者會看到所有已被暫存的檔案，讀者也準備好要提交修改。 最簡單的提交是執行`git commit`： $ git commit @@ -391,7 +391,7 @@ A `**/` pattern is available in Git since version 1.8.2. $ git rm log/\*.log -注意倒斜線（`\`）前方的星號（`*`）。 這是必須的，因為Git會在shell以上執行檔案的擴展。 此命令移除log目錄下所有檔名以`.log`結尾的檔案。 讀者也可以執行類似下列命令： +注意星號（`*`）前方的倒斜線（`\`）。 這是必須的，因為Git會在shell以上執行檔案的擴展。 此命令移除log目錄下所有檔名以`.log`結尾的檔案。 讀者也可以執行類似下列命令： $ git rm \*~ @@ -519,7 +519,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還 s.version = [-"0.1.0"-]{+"0.1.1"+} s.author = "Scott Chacon" -如你所見，輸出範例中沒有列出新增與刪除的行，變動的地方用內嵌的方式顯示，你可以看到新增的字被包括在 `{+ +}` 內，而刪除的則包括在 `{- -}` 內，如果你想再減少顯示的資訊，將上述的三行再減少到只顯示變動的那行。你可以用 `-U1` 選項，就像上述的範例中那樣。 +如你所見，輸出範例中沒有列出新增與刪除的行，變動的地方用內嵌的方式顯示，你可以看到新增的字被包括在 `{+ +}` 內，而刪除的則包括在 `[- -]` 內，如果你想再減少顯示的資訊，將上述的三行再減少到只顯示變動的那行。你可以用 `-U1` 選項，就像上述的範例中那樣。 另外也可以使用`git log`提供的一系統摘要選項。 例如：若想檢視每個更新的簡略統計資訊，可使用 `--stat` 選項： From 6f07d8c0637386c56325adb64852f5399cc9ed9f Mon Sep 17 00:00:00 2001 From: msxiyev Date: Thu, 7 Aug 2014 18:34:45 +0300 Subject: [PATCH 157/291] updated 01-chapter1.markdown {1 & 2 paragraphs} --- az/01-introduction/01-chapter1.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/az/01-introduction/01-chapter1.markdown b/az/01-introduction/01-chapter1.markdown index baa828d98..30e626bdd 100644 --- a/az/01-introduction/01-chapter1.markdown +++ b/az/01-introduction/01-chapter1.markdown @@ -1,12 +1,12 @@ # Başlanğıc # -Bu bölmə size git haqqında başlıca məlumatları çattırmağı hədəfləyir. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so. +Bu bölmə size git haqqında başlıca məlumatları çattırmağı hədəfləyir. İşə başlamazdan əvvəl version nəzarət vasitəsinin bəzi fon məlumatlarını açıqlayaraq başlayacağıq, daha sonra Git quraşdırılmanının necə ediləcəyini, ən son olaraq da vasitənin konfiqurasiya və istifadəsini açıqlayacağıq. Bu hissənin sonunda Git'in varlıq səbəbini və niyə onu istifadə etməniz lazım olduğunu anlayacaq, Git'i istifadə etmeye başlamaq üçün quraşdırma bitirmiş olacaqsınız. -## About Version Control ## +## Versiya Nəzarət Haqqında ## -What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control. +Versiya nəzarəti nədir və nə işə yarayar? Versiya nəzarəti, Bir ya da daha çox fayl üzərində edilən dəyişiklikləri yazan və daha sonra müəyyən bir distributivə geri dönə bilmənizi təmin edən bir sistemdir. Bu kitabdakı nümunələrdə proqram qaynaq kod fayllarının versiya idarəsini edəcəksiniz, nə var ki, əslində versiyası idarəsini demək olar ki hər növdən fayl üçün istifadə edə bilərsiniz. -If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. +Bir grafik və ya web dizayn tək və bir vizual və ya dizaynın dəyişik versiyalarını qorumaq istəyirsinizsə (ki ehtimalla bunu etmək istəyərsiniz), bir Versiya Kontrol Sistemi (VKS) istifadə etməniz çox ağıllıca olacaq. VKS, faylların və ya bütün layihənin keçmişdəki müəyyən bir versiyaya daxil olmağa, zaman içində edilən dəyişiklikləri müqayisə etməyinizi, problemə səbəb olan şeydə ən son kimin dəyişiklik etdiyini, müəyyən bir səhvi kimin, nə vaxt sistemə daxil etdiyini və daha başqa bir çox şeyi görə bilməyinizi təmin edər. Digər tərəfdən, VKS istifadə etmək, bir səhv etdikdə və ya bəzi faylları səhvən sildiyiniz də vəziyyəti asanlıqla kompensasiya etmənizə köməkçi olar. Üstəlik, bütün bunlar sizə əhəmiyyətli bir əlavə yük də gətirməz. ### Local Version Control Systems ### From b9aba77271c076d8164d636fea369b8d2304de1c Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 16:52:37 +0200 Subject: [PATCH 158/291] Translating titles --- it/07-customizing-git/01-chapter7.markdown | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index c65d63bbf..558645d79 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -526,7 +526,7 @@ All'esecuzione di `git archive`, il contenuto del file quando qualcuno aprirà l $ cat LAST_COMMIT Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$ -### Merge Strategies ### +### Strategie di merge ### È possibile inoltre utilizzare attributi Git per comunicare a Git di utilizzare differenti strategie di merge per files specifici nel progetto. Un opzione molto utile è comunicare a Git di non provare ad eseguire merge di files specifici quando sussistono conflitti, ma, invece, di la propria parte di merge sopra quella di qualcun altro. @@ -556,11 +556,11 @@ Gli hooks sono salvati nella sottodirectory `hooks` all'interno della directory Per abilitare uno script hook, bisogna inserire il file nella sottodirectory `hooks` della directory Git, il file dovrà essere nominato in modo appropriato ed eseguibile. Da questo punto in poi dovrebbe essere chiamato. Vedremo ora i principali nomi di hook. -### Hooks Lato Client ### +### Hook sul client ### Esistono molti hooks lato client. In questa sezione li divideremo in committing-workflow hooks, e-mail-workflow scripts, ed i restanti client-side scripts. -#### Committing-Workflow Hooks #### +#### Hook per le commit #### I primi quattro hooks sono correlati con il processo di commit. L'hook `pre-commit` è eseguito per primo, prima che venga richiesto l'inserimento del messaggio di commit. È usato per controllare lo snapshot di cui si vuole eseguire il commit, per vedere se ci si è dimenticati di qualcosa, per assicurarsi che i test funzionino, o per esaminare qualsiasi cosa si voglia nel codice. Se il valore di uscita di questo hook è un non-zero il commit viene annullato, in alternativa può essere bypassato tramite il comando `git commit --no-veriy`. È possibile eseguire operazioni come controllare lo stile del codice (eseguendo lint o qualcosa di simile), cercare whitespace alla fine (l'hook di default fa esattamente questo), cercare documentazione appropriata su nuovi metodi. @@ -572,7 +572,7 @@ Al termine dell'intero processo di commit, viene eseguito l'hook `post-commit`. Gli script client-side per il committing-workflow possono essere utilizzati in ogni flusso di lavoro. Sono spesso utilizzati per rafforzare alcune norme, è comunque importante notare che questi scripts non sono trasferiti durante un clone. È possibile rafforzare le norme lato server per rifiutare push di commits che non siano conformi a qualche norma, ma è responsabilità dello sviluppatore utilizzare questi script lato client. Quindi, questi sono scripts che aiutano gli sviluppatori, devono essere impostati e mantenuti da loro, possono essere modificati o sovrascritti da loro in ogni momento. -#### E-mail Workflow Hooks #### +#### Hook per le e-mail #### È possibile impostare tre hooks lato client per un flusso di lavoro basato sulle e-mail. Sono tutti invocati dal comando `git am`, quindi se non si utilizza il detto comando, questa sezione può essere tranquillamente saltata. Se si prendono patches via e-mail preparate tramite `git format-patch`, allora alcuni di questi hooks potrebbero risultare utili. @@ -582,7 +582,7 @@ Il prossimo hook che viene eseguito è `pre-applypatch`. Non riceve argomenti e L'ultimo hook che viene eseguito è `post-applypatch`. È possibile utilizzarlo per notificare ad un gruppo o all'autore della patch che è stato eseguito il pull nel quale si è lavorato. È possibile fermare il patching tramite questo script. -#### Altri Client Hooks #### +#### Altri hook sul client #### L'hook `pre-rebase` viene eseguito prima di un rebase e può fermare il processo ritornando un non-zero. È possibile utilizzare questo hook per negare il rebasing di qualsiasi commit di cui sia stato già effettuato un push. Lo script `pre-rebase` di esempio esegue quanto detto, in alternativa assume che next sia il nome del branch che si vuole pubblicare. Dovresti cambiarlo nel branch stabile. @@ -591,7 +591,7 @@ Dopo aver eseguito con successp `git checkout`, viene eseguito l'hook `post-chec Infine, l'hook `post-merge` viene eseguito dopo un comando `merge` terminato con successo. È possibile utilizzarlo per ripristinare informazioni dell'albero che Git non riesce a tracciare (come informazioni di permessi). Questo hook può allo stesso modo validare la presenza di files esterni al controllo di Git che potresti voler copiare all'interno quando l'albero di lavoro cambia. -### Hooks Lato Server ### +### Hook sul server ### In aggiunta agli hooks lato client, è possibile utilizzare un paio di hooks lato server come amministrazione di sistema per rafforzare praticamente ogni tipo di norma per il progetto. Questi scripts vengono eseguiti prima e dopo i push verso il server. I pre hooks possono ritornare non-zero in ogni momento per rifiutare il push inviando un messaggio di errore al client; è possibile configurare una politica di push che sia complessa quanto si desidera. From c3fc6451ce72344bb31507d35d366ab421b23d6d Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 16:55:57 +0200 Subject: [PATCH 159/291] Translating chapter #7 --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 558645d79..32662445b 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -1,6 +1,6 @@ - # Customizing Git # +# Personalizzare Git # -Finora abbiamo quindi coperto le basi di come Git funzioni e come usarlo, abbiamo introdotto un numero di strumenti che Git fornisce per aiutarti ad utilizzarlo al meglio ed in modo efficiente. In questo capitolo spiegherò alcune delle operazioni che possono essere utilizzate per personalizzare il comportamento di Git introducendo molti settaggi ed il Hooks System. Tramite questi strumenti, è semplice fare in modo che Git lavori nel modo che tu, la tua azienda, o il tuo gruppo desiderate. +Finora abbiamo viso le basi di come Git e come usarlo, abbiamo introdotto alcuni strumenti forniti da Git per aiutarti a usarlo al meglio ed efficientemente. In questo capitolo vedremo alcune operazioni che possono essere utilizzate per personalizzare il comportamento di Git, introducendo molte impostazione e il sistema degli `hook`. Tramite questi strumenti sarà semplice fare in modo che Git lavori come tu, la tua azienda, o il tuo gruppo desideriate. ## Configurazione di Git ## From 9858222d083a803f993fb79a192b8d34e7180e6d Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:09:46 +0200 Subject: [PATCH 160/291] Fixing translation for "Git Configuration" --- it/07-customizing-git/01-chapter7.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 32662445b..b834aa454 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -4,18 +4,18 @@ Finora abbiamo viso le basi di come Git e come usarlo, abbiamo introdotto alcuni ## Configurazione di Git ## -Come hai visto brevemente nel capitolo 1, si possono specificare delle impostazioni per Git tramite il comando `git config`. Una delle prime cose che hai fatto è stato impostare il tuo nome ed il tuo indirizzo e-mail: +Come abbiamo visto brevemente nel capitolo 1, è possibile configurare Git con il comando `git config`. Una delle prime cose che abbiamo fatto è stato definire il nostro nome e il nostro indirizzo e-mail: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com -Ora imparerai alcune delle opzioni più interessanti che si possono impostare in questa maniera per personalizzare l'utilizzo di Git. +Ora vedremo alcune delle opzioni più interessanti che puoi configurare allo stesso modo, per personalizzare il modo in cui usi Git. -Hai visto alcuni semplici dettagli di configurazione nel primo capitolo, ora li esamineremo ancora velocemente. Git utilizza una serie di files di configurazione per determinare comportamenti non standard che potresti desiderare. In primo luogo Git cercherà questi valori nel file `/etc/gitconfig`, il quale contiene valori per ogni utente e repository di sua proprietà presenti sul sitema. Se si passa l'opzione `--system` a `git config`, il programma leggerà e scriverà in modo specifico su questo file. +Nel primo capitolo hai visto alcuni dettagli per delle configurazioni semplici, ora li rivedremo velocemente. Git usa più file di configurazione per decidere cosa fare in situazioni non standard. Il primo di questi, dove Git cercherà, è `/etc/gitconfig`, che contiene la configurazione per tutti gli utenti del sistema e dei loro repository. Git legge e scrive su questo file quando usi l'opzione `--system` con `git config`. -Successivamente Git controlla il file `~/.gitconfig`, che è specifico per ogni utente. Puoi fare in modo che Git legga e scriva su questo file utilizzando l'opzione `--global`. +Il file successivo dove Git va a cercare è `~/.gitconfig`, che è specifico per ogni utente. Puoi fare in modo che Git legga e scriva su questo file con l'opzione `--global`. -Infine, Git controlla i valori di configurazione nel file di configurazione presente nella directory Git (`.git/config`) di qualsiasi repository che stai utilizzando. Questi valori sono specifici del singolo repository. Ongi livello sovrascrive i valori del livello precedente, per esempio i valori in `.git/config` battono quelli in `/etc/gitconfig`. Si può inoltre impostare questi valori modificando manualmente il file ed inserendo la corretta sintassi, tuttavia solitamente è più semplice eseguire il comando `git config`. +Infine Git controlla le impostazioni nel file di configurazione presente nella directory Git (`.git/config`) di qualsiasi repository che tu stia utilizzando. Queste impostazioni sono specifiche di quel singolo repository. Ogni livello sovrascrive i valori del livello precedente, quindi i valori in `.git/config` battono quelli in `/etc/gitconfig`. Puoi configurare queste impostazioni anche editando manualmente il file, usando la sintassi corretta, ma solitamente è più semplice eseguire il comando `git config`. ### Configurazione Base del Client ### From d446e333acda216cae0613195383dc4902873324 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:13:51 +0200 Subject: [PATCH 161/291] Updating "Basic Client Configuration" --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index b834aa454..e85dc11de 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -17,9 +17,9 @@ Il file successivo dove Git va a cercare è `~/.gitconfig`, che è specifico per Infine Git controlla le impostazioni nel file di configurazione presente nella directory Git (`.git/config`) di qualsiasi repository che tu stia utilizzando. Queste impostazioni sono specifiche di quel singolo repository. Ogni livello sovrascrive i valori del livello precedente, quindi i valori in `.git/config` battono quelli in `/etc/gitconfig`. Puoi configurare queste impostazioni anche editando manualmente il file, usando la sintassi corretta, ma solitamente è più semplice eseguire il comando `git config`. -### Configurazione Base del Client ### +### Configurazione minima del client ### -Le opzioni di configurazione riconosciute da Git si suddividono in due categorie: client-side e server-side. La maggioranza delle opzioni sono client-side—impostando le tue personali preferenze. Sono comunque disponibili molte opzioni, ne copriremo solo alcune che sono solitamente utilizzate o possono personalizzare il tuo ambiente di lavoro in modo significativo. Molte opzioni sono utili solo in casi limite che non esamineremo in questa sede. Nel caso tu voglia vedere una lista di tutte le opzioni che la tua versione di Git riconosce puoi eseguire il comando +Le opzioni di configurazione riconosciute da Git si suddividono in due categorie: `client-side` e `server-side`. La maggioranza delle opzioni sono client-side perché definiscono le tue preferenze personali. Sebbene siano disponibili moltissime opzioni, vedremo solo le poche che sono utilizzate spesso o che possono influenzare significativamente il tuo ambiente di lavoro. Molte opzioni sono utili solo in casi estremi che quindi non esamineremo in questa sede. Se vuoi vedere l'elenco di tutte le opzioni disponibili in Git, puoi eseguire il comando $ git config --help From 21c6b25f3c44cc933c209ab4eb34f1f6c0f9b210 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:16:30 +0200 Subject: [PATCH 162/291] Updating "core.editor" --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index e85dc11de..f8f244185 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -27,11 +27,11 @@ La pagina del manuale per `git config` elenca tutte le opzioni disponibili aggiu #### core.editor #### -Di default, Git utilizza qualsiasi programma che tu abbia impostato come text editor, in alternativa sceglie l'editor Vi per creare e modificare commit tag e messaggi. Per cambiare l'impostazione standard, puoi utilizzare l'impostazione `core.editor`: +Di default, Git utilizza qualsiasi programma tu abbia impostato come text editor o, in mancanza, sceglie l'editor Vi per creare e modificare i messaggi delle commit e dei tag. Per cambiare l'impostazione standard, puoi configurare il `core.editor`: $ git config --global core.editor emacs -Ora, non importa quale sia la variabile shell per l'editor, Git utilizzerà Emacs per modificare i messaggi. +Facendo così non importa quale sia l'editor predefinito configurato per la tua shell, Git lancerà sempre Emacs per modificare i messaggi. #### commit.template #### From 43533f1b29f0d2a8e1b4d5678652ff8fb43a5c4a Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:24:33 +0200 Subject: [PATCH 163/291] Updating "commit.template" --- it/07-customizing-git/01-chapter7.markdown | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index f8f244185..e6d0d2345 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -35,24 +35,24 @@ Facendo così non importa quale sia l'editor predefinito configurato per la tua #### commit.template #### -Se impostato verso il percorso di un file, Git utilizzerà questo file come messaggio di default per i tuoi commit. Ad esempio, supponiamo che tu abbia creato un file di template in `$HOME/.gitmessage.txt` in questo modo: +Se come valore per questo parametro definisci il percorso di un file, Git utilizzerà quel file come modello per i tuoi messaggio quando committi. Supponiamo per esempio che tu abbia creato il seguente modello in `$HOME/.gitmessage.txt`: - subject line + oggetto - what happened + cos'è successo: giustifica la tua commit [ticket: X] -Per comunicare a Git di utilizzare come messaggio di default il messaggio che compare nell'editor quando viene eseguito `git commit`, imposta il valore `commit.template` in questo modo: +Per comunicare a Git di usare sempre questo messaggio nel tuo editor quando esegui `git commit`, configura `commit.template` in questo modo: $ git config --global commit.template $HOME/.gitmessage.txt $ git commit -Il tuo editor si aprirà quindi in un modo simile a questo per la tua variabile metasintattica del messaggio di commit, ad ogni tuo commit: +Quando committi, il tuo editor si aprirà con un contenuto simile al seguente, perché tu scriva il tuo messaggio: - subject line + oggetto - what happened + cos'è successo: giustifica la tua commit [ticket: X] # Please enter the commit message for your changes. Lines starting @@ -67,7 +67,7 @@ Il tuo editor si aprirà quindi in un modo simile a questo per la tua variabile ~ ".git/COMMIT_EDITMSG" 14L, 297C -Nel caso tu abbia una norma per il messaggio di commit, allora inserire un template per quella norma sul tuo sistema e configurare Git per utilizzarla di default può aiutare ad aumentare le possibilità che quella norma venga seguita regolarmente. +Nel caso tu abbia una sintassi standard da seguire per i messaggi di commit, configurare Git perché usi un modello può aumentare le possibilità che quello standard venga rispettato. #### core.pager #### From 01455c4aea87e3a9142eae1c1a767c13b6d8b510 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:28:05 +0200 Subject: [PATCH 164/291] Updating "core.pager" --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index e6d0d2345..93dff862d 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -71,11 +71,11 @@ Nel caso tu abbia una sintassi standard da seguire per i messaggi di commit, con #### core.pager #### -L'impostazione core.pager determina quale pager venga utilizzato quando Git pagina l'output come `log` e `diff`. Puoi impostarlo a `more` o al tuo pager preferito (di default è `less`), in alternativa puoi disattivarlo impostandolo ad una stringa vuota: +L'impostazione core.pager determina quale applicazione debba essere usata da Git quando pagina output lunghi come `log` e `diff`. Puoi impostarlo a `more` o alla tua applicazione preferita (predefinito è `less`), o puoi anche disattivarlo impostandolo a una stringa vuota: $ git config --global core.pager '' -Nel caso tu lo esegua, Git paginerà l'output di ogni comando, non importa quanto esso sia lungo. +Se eseguissi questo comando, Git paginerà l'intero output di qualsiasi comando, non importa quanto esso sia lungo. #### user.signingkey #### From 5cfd28996aac9a05ffbbf0ab5c75abdf64c0557b Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:29:57 +0200 Subject: [PATCH 165/291] Updating "user.signingkey" --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 93dff862d..2e9d86514 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -79,11 +79,11 @@ Se eseguissi questo comando, Git paginerà l'intero output di qualsiasi comando, #### user.signingkey #### -Nel caso tu voglia firmare i tags (come discusso nel Capitolo 2), impostare la tua chiave GPG nelle impostazioni rende le cose più semplici. Imposta l'ID della tua chiave in questo modo: +Nel caso utilizzi tag firmati (come descritto nel capitolo 2), definire la tua chiave GPG nelle impostazioni rende le cose più semplici. Imposta l'ID della tua chiave in questo modo: $ git config --global user.signingkey -Ora, puoi firmare i tags senza dover specificare la tua chiave ogni volta con il comando `git tag`: +Ora, puoi firmare i tags, senza dover specificare ogni volta la tua chiave, con il comando `git tag`: $ git tag -s From 163ed76670e6e3d209fc92423c2bc9dd946c036f Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:33:36 +0200 Subject: [PATCH 166/291] Updating "user.signingkey" --- it/07-customizing-git/01-chapter7.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 2e9d86514..665590518 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -89,7 +89,7 @@ Ora, puoi firmare i tags, senza dover specificare ogni volta la tua chiave, con #### core.excludesfile #### -Puoi inserire patterns nel file `.gitignore` del tuo progetto per fare in modo che Git non li veda come untracked files o provi a farne uno stage all'esecuzione del comando `git add` su di loro, come visto nel Capitolo 2. Comunque, se vuoi che un altro file all'esterno del tuo progetto gestisca questi valori o abbia valori extra, puoi informare Git della posizione del file tramite il parametro `core.excludesfile`. Impostalo semplicemente sul percorso del file che ha un contenuto simile a quello che avrebbe un file `.gitignore`. +Puoi inserire dei modelli nel file `.gitignore` del tuo progetto per fare in modo che Git non li veda come file non tracciati o provi a metterli nell'area di stage quando esegui `git add`, come visto nel capitolo 2. Se però vuoi che un altro file, all'esterno del tuo progetto, gestisca queste esclusioni o vuoi definire valori addizionali, puoi dire a Git dove si trovi quel file con `core.excludesfile`. Ti basta specificare il percorso del file che abbia un contenuto simile a quello che avrebbe il `.gitignore`. #### help.autocorrect #### From a2c680a2bbe1a3fd7253c17d3ed42e70052c50b9 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 7 Aug 2014 17:35:39 +0200 Subject: [PATCH 167/291] Updating "help.autocorrect" --- it/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown index 665590518..584005247 100644 --- a/it/07-customizing-git/01-chapter7.markdown +++ b/it/07-customizing-git/01-chapter7.markdown @@ -93,7 +93,7 @@ Puoi inserire dei modelli nel file `.gitignore` del tuo progetto per fare in mod #### help.autocorrect #### -Questa opzione è disponibile solo in Git 1.6.1 e successivi. Se digiti in modo errato un comando in Git 1.6, ti mostrerà qualcosa del genere: +Questa opzione è disponibile solo da Git 1.6.1 in poi. Se digiti male un comando in Git, otterrai qualcosa del genere: $ git com git: 'com' is not a git-command. See 'git --help'. @@ -101,7 +101,7 @@ Questa opzione è disponibile solo in Git 1.6.1 e successivi. Se digiti in modo Did you mean this? commit -Se imposti `help.autocorrect` a 1, Git automaticamente eseguirà il comando nel caso in cui corrisponda ad un solo match. +Se imposti `help.autocorrect` a 1, Git eseguirà automaticamente il comando nel caso esista un'unica corrispondenza. ### Colors in Git ### From de5632929eaecff64f5cf9a38b75570978bf3250 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 8 Aug 2014 00:35:26 +0200 Subject: [PATCH 168/291] [cs] fixed translation in ch. 3, reflecting new things in ch. 4 --- cs/03-git-branching/01-chapter3.markdown | 2 +- cs/04-git-server/01-chapter4.markdown | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 5d486f281..2c0701fef 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -2,7 +2,7 @@ Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho. -Někteří lidé mluví o modelu větvení v systému Git jako o jeho „vražedné vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. +Někteří lidé mluví o modelu větvení v systému Git jako o jeho „omračující vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. ## Co je to větev ## diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 5e4d1a27c..d3b0c44b7 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -227,6 +227,10 @@ Vy nyní klíče vložíte do souboru `authorized_keys`: $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys +Autentizace vůči SSH, která je založená na klíči, obvykle vynucuje zvýšenou bezpečnost tím, že pro zúčastněné soubory vyžaduje omezená oprávnění. Aby SSH neodmítl pracovat, napište následující: + + $ chmod -R go= ~/.ssh + Nyní pro ně můžete nastavit prázdný repozitář. Spusťte příkaz `git init` s parametrem `--bare`, který inicializuje repozitář bez pracovního adresáře: $ cd /opt/git From 9579cf8722b0d6449c75644b2cfddf1962307fad Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Fri, 8 Aug 2014 16:20:12 +0900 Subject: [PATCH 169/291] [ko] rename README to README.md --- ko/{README => README.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ko/{README => README.md} (100%) diff --git a/ko/README b/ko/README.md similarity index 100% rename from ko/README rename to ko/README.md From b371a70485c7a1eae2a3485aeebc3ad5bc34e92b Mon Sep 17 00:00:00 2001 From: msxiyev Date: Fri, 8 Aug 2014 13:44:45 +0300 Subject: [PATCH 170/291] =?UTF-8?q?3=20abzas=20terc=C3=BCmesi=20edildi=20{?= =?UTF-8?q?LVNS,=20MVNS,=20PVNS=20}=20:pencil2:?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- az/01-introduction/01-chapter1.markdown | 30 ++++++++++++------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/az/01-introduction/01-chapter1.markdown b/az/01-introduction/01-chapter1.markdown index 30e626bdd..d2cea2626 100644 --- a/az/01-introduction/01-chapter1.markdown +++ b/az/01-introduction/01-chapter1.markdown @@ -6,38 +6,38 @@ Bu bölmə size git haqqında başlıca məlumatları çattırmağı hədəfləy Versiya nəzarəti nədir və nə işə yarayar? Versiya nəzarəti, Bir ya da daha çox fayl üzərində edilən dəyişiklikləri yazan və daha sonra müəyyən bir distributivə geri dönə bilmənizi təmin edən bir sistemdir. Bu kitabdakı nümunələrdə proqram qaynaq kod fayllarının versiya idarəsini edəcəksiniz, nə var ki, əslində versiyası idarəsini demək olar ki hər növdən fayl üçün istifadə edə bilərsiniz. -Bir grafik və ya web dizayn tək və bir vizual və ya dizaynın dəyişik versiyalarını qorumaq istəyirsinizsə (ki ehtimalla bunu etmək istəyərsiniz), bir Versiya Kontrol Sistemi (VKS) istifadə etməniz çox ağıllıca olacaq. VKS, faylların və ya bütün layihənin keçmişdəki müəyyən bir versiyaya daxil olmağa, zaman içində edilən dəyişiklikləri müqayisə etməyinizi, problemə səbəb olan şeydə ən son kimin dəyişiklik etdiyini, müəyyən bir səhvi kimin, nə vaxt sistemə daxil etdiyini və daha başqa bir çox şeyi görə bilməyinizi təmin edər. Digər tərəfdən, VKS istifadə etmək, bir səhv etdikdə və ya bəzi faylları səhvən sildiyiniz də vəziyyəti asanlıqla kompensasiya etmənizə köməkçi olar. Üstəlik, bütün bunlar sizə əhəmiyyətli bir əlavə yük də gətirməz. +Bir grafik və ya web dizayn tək və bir vizual və ya dizaynın dəyişik versiyalarını qorumaq istəyirsinizsə (ki ehtimalla bunu etmək istəyərsiniz), bir Versiya Nəzarət Sistemi (VNS) istifadə etməniz çox ağıllıca olacaq. VNS, faylların və ya bütün layihənin keçmişdəki müəyyən bir versiyaya daxil olmağa, zaman içində edilən dəyişiklikləri müqayisə etməyinizi, problemə səbəb olan şeydə ən son kimin dəyişiklik etdiyini, müəyyən bir səhvi kimin, nə vaxt sistemə daxil etdiyini və daha başqa bir çox şeyi görə bilməyinizi təmin edər. Digər tərəfdən, VNS istifadə etmək, bir səhv etdikdə və ya bəzi faylları səhvən sildiyiniz də vəziyyəti asanlıqla kompensasiya etmənizə köməkçi olar. Üstəlik, bütün bunlar sizə əhəmiyyətli bir əlavə yük də gətirməz. -### Local Version Control Systems ### +### Lokal Sürüm Nəzarət Sistemləri ### -Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. +Əksəriyyəti faylları bir qovluğa (ağılları başlarındaysa tarix və zaman məlumatını də daxil olmaqla bir qovluğa) kopiyalayaraq versiyas nəzarətini etməyi seçər. Bu yanaşma çox məşhurdur, çünki çox asandır; amma eyni zamanda səhvlərə də ala bildiyinə açıqdır. Hansı qovluqda olduğunuzu unudub səhv fayla yaza ya da istəmədiyiniz faylların üstünə kopiyalama edə bilərsiniz. -To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1). +Bu problemlə baş edə bilmək üçün, proqramçılar uzun zaman əvvəl, fayllardakı bütün dəyişiklikləri versiya nəzarətinə alan sadə bir veri bazasına sahib olan lokal VNS'leri inkişaf etdirdilər (bax Göstərici 1-1). Insert 18333fig0101.png -Figure 1-1. Local version control diagram. +Göstərici 1-1. Lokal Sürüm Nəzarət diaqramı. -One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches. +Ən məşhur VNS vasitələrindən biri, bu gün hələ çox kompüterə yüklenmiş olaraq yayılan, RCS adında bir sistem idi. Məşhur Mac OS X əməliyyat sistemi belə, Developer Tools'u yüklediğinizde, RCS əmrini qurmaqdadır. Bu vasitə, iki versiyası arasındakı yamaqları (yəni, fayllar arasındakı fərqləri) xüsusi bir şəkildə diskə yazar; daha sonra, bu yamaqları bir-birinə əlavə, bir faylın müəyyən bir distributivdəki görünüşünü yenidən meydana gətirər. -### Centralized Version Control Systems ### +### Mərkəzi Versiya Nəzarət Sistemləri ### -The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2). +İnsanların qarşılaşdığı ikinci böyük problem, başqa sistemlərdəki proqramçılar ilə birlikdə iş ehtiyacından irəli gəlir. Bu problemlə başa çıxa bilmək üçün, Mərkəzi Versiya Nəzarət Sistemləri (MVNS) inkişaf etdirilmişdir. Bu sistemlər, məsələn CVS, Subversion və Perforce, versiyası idarəsinə alınan bütün faylları tutan bir server və bu serverdən faylları seçərək alan (check out) alıcını meydana gələr. Bu üsul, illərcə, versiyası idarəsində standart üsul olaraq qəbul gördü (bax Göstərici 1-2). Insert 18333fig0102.png -Figure 1-2. Centralized version control diagram. +Göstərici 1-2. Mərkəzi Versiya Nəzarət diaqramı. -This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client. +Bu üsulun, xüsusilə lokal VNS lere görə, çox sayda üstünlüyü vardır. Məsələn, bir projedeki hər kəs, digərlərinin nə etdiyindən müəyyən ölçüdə xəbərdardır. Sistem idarəçiləri kimin hansı səlahiyyətlərə sahib olacağını olduqca detallı şəkildə təşkil; üstəlik bir MVNS'yi idarə, hər alıcını ayrı-ayrı heyəti olan yerli bazalarını idarə görə çox daha asandır. -However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. +Nə var ki, bu üsulun də ciddi bəzi çətinlikləri vardır. Ən aşkar çətinlik, mərkəzi serverin işləməməsi vəziyyətində ortaya çıxacaq qırılma nöqtəsi problemidir. Server bir saatlığına çökəcək olsa, o bir saat boyunca istifadəçilərin işlərini sistemə köçürmələri ya da çalışdıqları şeylərin sürümlenmiş surətlərini saxlamaq mümkün olmayacaq. Mərkəzi bazanın sabit diski pozulacaq olsa, ehtiyyat da olması lazım olduğu kimi edilməmişsə, əlinizdəki hər şeyi -projenin, istifadəçilərin kompüterlərində qalan lokal yaddaş kopiyaları (snapshot) xaricindəki bütün tarihçesini- itirərsiniz. Yerli VNS'ler də bu problemdən çəkir -projenin bütün tarixçəsini tək bir yerdə tutduğunuz müddətcə hər şeyi itirmə riskiniz var. -### Distributed Version Control Systems ### +### Paylanmış Versiya Nəzarət Sistemləri ### -This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3). +Bu nöqtədə Paylanmış Versiya Nəzarət Sistemləri (PVNS) dövrəyə girər. Bir PVNS'de (Git, Mercurial, Bazaar ya da Darcs nümunələrində olduğu kimi), müştərilər (istifadəçilər) faylların yalnız ən son yaddaş surətlərini almaqla qalmazlar: proqram hovuzunu (repository) tamamilə yansılalar (kopyalarlar).Beləcə, serverlərdən biri çöksə, və o server üzərindən ortaq iş icra edən sistemlər varsa, alıcını birinin proqram hovuzu serverə geri yüklənərək sistem qurtarıla bilər. Hər seçmə (checkout) əməliyyatı əsasında bütün məlumatın yedeklenmesiyle nəticələnər(bax Göstərici 1-3). Insert 18333fig0103.png -Figure 1-3. Distributed version control diagram. +Göstərici 1-3. Paylanmış Versiya Nəzarət diaqramı. -Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. +Dahası, bu sistemlerden çoğu birden çok uzak uçbirimdeki yazılım havuzuyla rahatlıkla çalışır, böylece, aynı proje için aynı anda farklı insan topluluklarıyla farklı biçimlerde ortak çalışmalar yürütebilirsiniz. Bu, birden çok iş akışı ile çalışabilmenizi sağlar, ki bu merkezi sistemlerde (hiyerarşik modeller gibi) mümkün değildir. ## A Short History of Git ## From bf1d1b7637e9136abdfc3d39a350f98b5ce93db4 Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Fri, 8 Aug 2014 16:31:15 +0900 Subject: [PATCH 171/291] [ko] update README It was a tad outdated. --- ko/README.md | 83 +++++++++++++++++++++++++++++----------------------- 1 file changed, 46 insertions(+), 37 deletions(-) diff --git a/ko/README.md b/ko/README.md index 2d1c723c0..747df1892 100644 --- a/ko/README.md +++ b/ko/README.md @@ -1,56 +1,65 @@ -Pro Git 책의 내용 -===================== +This is a translation of the original [README.md](../README.md) in English with +some additional information about the Korean translation. -이 저장소는 Pro Git의 source code이고 라이센스는 Creative Commons Attribution-Non Commercial-Share Alike 3.0를 따릅니다. 필자는 여러분이 즐겁게 git을 배웠으면 좋겠습니다. 만약 Amazon에서 책을 구입해주신다면 저와 Apress는 깊은 감사를 드릴 것입니다: +# Pro Git -http://tinyurl.com/amazonprogit +이곳에 담긴 내용물은 「Pro Git」 한국어판의 소스 코드로, 원본은 영어판 「Pro Git」입니다. 원작과 +본 번역물은 [크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 3.0 (CC BY-NC-SA +3.0)](https://creativecommons.org/licenses/by-nc-sa/3.0/) 조건에 따라 이용할 수 +있습니다. -Ebook 만드는 법 -===================== +이 책을 통해 Git을 즐겁게 배우시길 바랍니다. [출판된 책을 Amazon에서 구입](http://tinyurl.com/amazonprogit)하시면 +원저자인 Scott Chacon과 Apress 출판사에게 큰 도움이 됩니다. +[git-scm.com](http://git-scm.com/book/)에서 영어, 한국어 및 10여개의 다른 언어로 온라인에서 +읽을 수도 있습니다. -페도라에서는 다음과 같이 하면 됩니다: +# 전자책 만들기 - $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug - $ gem install rdiscount - $ FORMAT=epub ./makeebooks ko # FORMAT이 없으면 mobi파일이 생성됩니다. +페도라(16 이상)에서는 아래와 같이 할 수 있습니다. -Mac에서는 먼저 Calibre를 내려받아 설치하고 `ebook-convert` 명령을 실행경로에 넣어 줘야 합니다. 예를 들어 `~/bin/`을 실행경로로 사용하고 있다면 다음과 같이합니다: + $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug rubygem-rdiscount + $ ./makeebooks en # mobi 파일 생성 - $ ln -s /Applications/calibre.app/Contents/MacOS/ebook-convert ~/bin/ebook-convert +맥에서는 아래의 설명을 따르세요. -그리고 gem을 설치하고 만들면 됩니다: +1. ruby와 rubygems을 설치 +2. 터미널에서 `gem install rdiscount` 실행 +3. 맥용 Calibre를 다운로드 및 명령줄 도구 설치. PDF를 만들려면 다음 소프트웨어도 설치해야 합니다: + * pandoc: http://johnmacfarlane.net/pandoc/installing.html + * xelatex: http://tug.org/mactex/ +4. 터미널에서 `./makeebooks ko` 실행 (mobi 파일 생성) - $ sudo gem install rdiscount ruby-debug - $ ./makeebooks en # will produce a mobi +역주: 모든 명령어는 프로젝트의 루트 디렉토리에서 실행되어야 합니다. -Pdf 만드는 법 -===================== +# 정오표 -Mac에서는 먼저 Pandoc과 MacTex 패키지를 설치합니다. pdf를 빌드하려면 xetex가 필요한데 MacTex가 가장 쉽습니다. MacTex(2011 패키지 1.8G)는 용량이 크지만 전부 설치합니다. +이 책에서 잘못된 점이나 수정되어야 하는 부분을 발견한 경우, GitHub 저장소에 [이슈를 +등록](https://github.com/progit/progit/issues/new)해주세요. -그리고 makepdf명령으로 만들 수 있습니다: +# 번역 - $ ./makepdfs ko +이 책을 새로운 언어로 번역하고 싶다면 [ISO 639](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) +코드에 맞는 이름으로 프로젝트의 루트 디렉토리에 새 디렉토리를 만든 뒤 pull request를 보내주세요. +번역된 책은 git-scm.com 웹사이트에 게시되어 누구나 볼 수 있게 됩니다. -오류 -===================== +# pull request 보내기 -틀린 부분이나 개선해야 할 부분이 있으면 주저 말고 저에게 메일을 보내주세요. -(schacon at gmail dot com) +* 모든 파일은 UTF-8 인코딩을 사용해야 합니다. +* 영어 원본과 번역본의 변경 사항은 각각 다른 pull request로 보내주세요. +* 번역본을 수정할 때는 commit 메시지와 pull request의 제목을 해당 언어의 ISO 639 코드로 + 시작해주세요. 예를 들어 한국어판의 내용을 수정했을 경우 `[ko] improve wording`처럼 제목을 + 달면 됩니다. +* 변경 사항이 conflict 없이 자동으로 merge될 수 있어야 합니다. +* PDF 만들기, 전자책 만들기, git-scm.com 웹사이트 등이 잘 작동하는지 꼭 확인해주세요. -번역 -===================== +# 한국어판 출판 및 역자 정보 -이 책을 번역해서 알려주시면 제가 progit.org에 번역본을 올릴 것입니다. 적당히(이탈리아어로 번역한다면 `it`라는 디렉토리를 만든다) 하위 디렉토리를 만들고 번역을 완성하고 나서 필자에게 pull 요청을 해주세요. +인사이트를 통해서 [Pro Git +한국어판](http://www.insightbook.co.kr/books/programming-insight/프로-git)이 +2013년 4월 19일에 출판되었습니다. 출판된 책을 구입하시면 도서출판 인사이트와 역자들에게 도움이 됩니다. -역자 정보 -===================== +## 역자 소개 -번역, 박창우(Changwoo Park), pismute at gmail dot com, https://github.com/pismute -번역, 이성환(Sean Lee), lethee at gmail dot comt, https://github.com/lethee -번역, 최용재(Yongjae choi), lnyarl at gmail dot comt, https://github.com/lnyarl - -종이책 -===================== - -[인사이트](http://www.insightbook.co.kr/)를 통해서 Pro Git 한글 번역판이 종이로도 출간됐습니다. 인사이트와 역자에게 도움을 주시기 바람니다. +* [박창우(Changwoo Park)](https://github.com/pismute), pismute at gmail dot com +* [이성환(Sean Lee)](https://github.com/lethee), lethee at gmail dot com +* [최용재(Yongjae choi)](https://github.com/lnyarl), lnyarl at gmail dot com From c575051c70c07f4d2efec0a915467896f560af61 Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Fri, 8 Aug 2014 20:15:31 +0900 Subject: [PATCH 172/291] [ko] update chapter 1 This commit improves the Korean translation of the first two paragraphs in Chapter 1. It makes the sentences sound more natural and removes the wrong clause in the first paragragh which says there will be an explanation in this chapter for how to set up a Git server, which is not true. --- ko/01-introduction/01-chapter1.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown index 8a015f6ca..436f67173 100644 --- a/ko/01-introduction/01-chapter1.markdown +++ b/ko/01-introduction/01-chapter1.markdown @@ -1,10 +1,10 @@ # 시작하기 # -이 장에서 설명하는 것은 Git을 처음 접하는 사람에게 필요한 내용이다. 먼저 버전 관리 도구에 대한 이해와 Git을 설치하는 방법을 설명하고 마지막으로 Git 서버를 설정하고 사용하는 방법을 설명한다. 이 장을 다 읽고 나면 Git 탄생 배경, Git을 사용하는 이유, Git을 설정하고 사용하는 방법을 터득하게 될 것이다. +이 장에서는 Git을 처음 접하는 사람에게 필요한 내용을 다룬다. 버전 관리 도구에 대한 전반적인 사항부터 시작해서 Git의 특징, Git을 설치하는 방법, 마지막으로 Git을 설정하는 법을 설명할 것이다. 이 장을 다 읽고 나면 Git의 탄생 배경과 Git을 사용하는 이유를 이해하고, Git을 사용하기 위한 준비가 다 되어있을 것이다. ## 버전 관리란? ## -버전 관리는 무엇이고 우리는 왜 이것을 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 이 책에서는 버전 관리하는 예제로 소스 코드만 보여주지만, 실제로 거의 모든 컴퓨터 파일의 버전을 관리할 수 있다. +버전 관리란 무엇이며, 이것을 왜 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 이 책에서는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만, 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다. 그래픽 디자이너나 웹 디자이너도 버전 관리 시스템(VCS - Version Control System)을 사용할 수 있다. VCS로 이미지나 레이아웃의 버전(변경 이력 혹은 수정 내용)을 관리하는 것은 매우 현명하다. VCS를 사용하면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다. VCS를 사용하면 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다. 이런 모든 장점을 큰 노력 없이 이용할 수 있다. From d09d45b390013b5f492a1230069616eaed1436ca Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 8 Aug 2014 14:03:42 +0200 Subject: [PATCH 173/291] [cs] synchronizing with the new additions to [en] --- cs/03-git-branching/01-chapter3.markdown | 2 +- cs/06-git-tools/01-chapter6.markdown | 6 ++++++ cs/07-customizing-git/01-chapter7.markdown | 6 +++++- cs/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++ 4 files changed, 23 insertions(+), 2 deletions(-) diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 2c0701fef..2b46fc54b 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -2,7 +2,7 @@ Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho. -Někteří lidé mluví o modelu větvení v systému Git jako o jeho „omračující vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. +Někteří lidé mluví o modelu větvení v systému Git jako o převratné vlastnosti („killer feature“). Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. ## Co je to větev ## diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index 068bba4c9..768f9c2f9 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -765,6 +765,12 @@ Dalším častým případem bývá, že uživatel zapomene spustit příkaz `gi Příkaz projde a přepíše všechny revize tak, aby obsahovaly novou adresu. Protože revize obsahují hodnoty SHA-1 svých rodičů, změní tento příkaz SHA všech revizí ve vaší historii, ne pouze těch, které mají odpovídající e-mailovou adresu. +### Velmi rychlá a nebezpečná zbraň: Big Friendly Giant Repo Cleaner (BFG) ### + +[Roberto Tyley](https://github.com/rtyley) vytvořil nástroj, který se funkčností podobá `filter-branch` a nazval jej BFG. (Celý název lze doslova přeložit jako Velký, přátelský, obří čistič repozitáře --- představte si pod tím, co chcete.) BFG neumí tolik věcí jako `filter-branch`, ale je *velmi* rychlý. Pro velké repozitáře to může být zásadní rozdíl. Pokud lze vámi zamýšlenou změnu pomocí BFG provést a pokud máte problémy s výkonností prostředí, pak byste o použití tohoto nástroje měli uvažovat. + +Podrobnosti naleznete na stránkách [BFG](http://rtyley.github.io/bfg-repo-cleaner/). + ## Ladění v systému Git ## Git také nabízí několik nástrojů, které vám pomohou ladit problémy v projektech. Protože je Git navržen tak, aby pracoval téměř s jakýmkoli typem projektu, jsou tyto nástroje velmi univerzální. Často vám mohou pomoci odhalit vzniklou chybu nebo problém. diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown index 0e587fe57..e910b46f3 100644 --- a/cs/07-customizing-git/01-chapter7.markdown +++ b/cs/07-customizing-git/01-chapter7.markdown @@ -531,10 +531,14 @@ Spustíte-li příkaz `git archive`, bude po otevření soubor archivu vypadat o Atributy Git lze použít také k nastavení různých strategií slučování pro různé soubory v projektu. Velmi užitečnou možností je například nastavení, aby se Git nepokoušel sloučit konkrétní soubory, pokud u nich dojde ke konfliktu, a raději použil vaši verzi souboru než jinou. -Tuto možnost využijete, pokud se rozdělila nebo specializovala některá z větví vašeho projektu, avšak vy z ní budete chtít začlenit změny zpět a ignorovat přitom určité soubory. Řekněme, že máte soubor s nastavením databáze database.xml, který se ve dvou větvích liší, a vy sem chcete začlenit jinou svoji větev, aniž byste tento soubor změnili. V tom případě můžete nastavit tento atribut: +Tuto možnost využijete, pokud se rozdělila nebo specializovala některá z větví vašeho projektu, avšak vy z ní budete chtít začlenit změny zpět a ignorovat přitom určité soubory. Řekněme, že máte soubor s nastavením databáze nazvaný database.xml, který se ve dvou větvích liší, a vy sem chcete začlenit jinou svoji větev, aniž byste tento soubor změnili. V tom případě můžete nastavit tento atribut: database.xml merge=ours +A potom nadefinujete prázdnou slučovací strategii `ours` příkazem: + + git config --global merge.ours.driver true + Pokud začleníte druhou větev, místo řešení konfliktů u souboru database.xml se zobrazí následující: $ git merge topic diff --git a/cs/08-git-and-other-scms/01-chapter8.markdown b/cs/08-git-and-other-scms/01-chapter8.markdown index 01dc32810..303db4d2f 100644 --- a/cs/08-git-and-other-scms/01-chapter8.markdown +++ b/cs/08-git-and-other-scms/01-chapter8.markdown @@ -324,6 +324,17 @@ Stejné informace, jaké poskytuje příkaz `svn info`, získáte příkazem `gi Stejně jako v případě příkazů `blame` a `log` pracuje i tento příkaz offline a zobrazuje stav v okamžiku, kdy jste naposledy komunikovali se serverem Subversion. +Tip: Pokud vaše skripty pro sestavení projektu chtějí spouštět `svn info`, pak si často můžete vystačit s obálkou příkazu git. +Můžete vyzkoušet + + #!/usr/bin/env bash + + if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then + git svn info + else + /usr/local/bin/svn "$@" + fi + #### Ignorování souborů, které ignoruje Subversion #### Jestliže naklonujete repozitář Subversion s nastavenými vlastnostmi `svn:ignore`, pravděpodobně budete chtít nastavit také odpovídající soubory `.gitignore`, abyste omylem nezapsali nežádoucí soubory. Nástroj `git svn` vám k řešení tohoto problému nabízí dva příkazy. Tím prvním je `git svn create-ignore`, jenž automaticky vytvoří odpovídající soubory `.gitignore`, podle nichž se bude řídit už vaše příští revize. From b7774688c84e2d9d5f5a13cf93e2b0b2ac78964f Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Sat, 9 Aug 2014 01:21:08 +0900 Subject: [PATCH 174/291] [ko] add a translation guide --- ko/translation_guide.txt | 65 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 ko/translation_guide.txt diff --git a/ko/translation_guide.txt b/ko/translation_guide.txt new file mode 100644 index 000000000..fb39b71bf --- /dev/null +++ b/ko/translation_guide.txt @@ -0,0 +1,65 @@ +이 문서는 번역에 기여하는 사람들이 기준으로 삼을 수 있는 원칙들을 제시함으로써 일관성과 높은 품질의 +번역을 달성하기 위해 작성되었습니다. + + +1. 기본 원칙 + +아래는 「C++ 프로그래밍 언어(특별판)」(비야네 스트롭스트룹 지음, 곽용재 옮김)의 번역 원칙 및 용어 +대역(21쪽)에 있는 내용으로, 어느 기술 서적의 번역에도 적용되는 내용이라고 생각하여 옮깁니다. + + 1.1 문장 + + * 모든 문장은 모호성과 오독률을 최소화하는 데 가장 큰 무게를 둔다. + * 원전의 권위는 무시하지 않되, 그 뜻을 충분히 해석한 후 우리말의 리듬을 살려 가장 편하게 읽을 수 + 있는 문장을 사용한다. + + 1.2 대역 용어 + + * 원문 용어의 대역어는 우리나라 개발업계에서 쓰이는 용어 중 가장 보편적이고 순화된 용어를 + 사옹하며, 그러한 용어가 없을 경우에는 충분한 검토를 거쳐 새로 만든다. + * 대역 용어의 선택 및 사용에 있어서는 자연스러움과 보수적인 입장 사이를 최대한 조율하여, 의미 + 전달에 어려움이 없도록 한다. + + 1.3 기타 + + * 편집 형태는 원서와 동일하게 하되 그 안에서 최대한의 가독률을 추구한다. + * 용어 대역표의 경우, 원어-우리말 대치와 우리말-원어 대치를 함께 두어 찾아보기에 편리하도록 + 하였다. + + +2. 편집 지침 + +고유명사는 대소문자를 바꾸지 않고 그대로 표기하되, 원문이 틀렸을 경우 옳은 표기로 씁니다(예: rcs -> +RCS). "옳은 표기"의 기준은 위키백과의 표제어로 하고, 없을 경우 구글 검색 결과에서 결과가 많은 쪽을 +따릅니다. + +파일명, 명령어(`git add` 등) 등은 그대로 씁니다. 원문과 마찬가지로 반드시 ``로 감싸야 합니다. + +용어 대역표에 있는 용어가 맨 처음 나타날 경우, 독자의 이해를 위해 필요한 경우 한국어 용어로 쓴 뒤 괄호 +안에 원문 용어를 넣을 수 있습니다. 이때 원문 용어는 원래 쓰는 방법에 대문자가 들어가 있는 것이 아닌 한 +모두 소문자로 씁니다. + + 잘못된 예: 마지막 스냅샷을 가져오는 대신 저장소(Repository)를 통째로 복제한다. + 옳은 예: 마지막 스냅샷을 가져오는 대신 저장소(repository)를 통째로 복제한다. + +같은 용어가 두 번 이상 나타날 경우 약어를 쓸 수 있습니다(예: VCS). + +한국어 문장에서는 괄호 앞뒤에 띄어쓰기를 하지 않습니다. + +구어체는 지양해주세요(예: 거다 -> 것이다). + + +3. 용어 대역표 + +이 표는 현재 미완성입니다. 작업을 진행하면서 채워주세요. + +centralized 중앙집중식 +checkout 가져오다, 체크아웃(하다) +hierarchical model 계층 모델 +history 역사, 이력 +local 로컬 +repository 저장소 +remote 원격(의), 원격 저장소 +version control 버전 관리, 버전(을) 관리하다 +Version Control System 버전 관리 시스템 +workflow 작업 방식 From e8a47b3f9ae3306b4d186b182fa95d8feebab1d9 Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Sat, 9 Aug 2014 01:56:34 +0900 Subject: [PATCH 175/291] [ko] update chapter 1 Improve the overall translation quality by conveying the meaning of the original text more accurately, avoiding colloquial expressions, using a more consistent writing style, etc. --- ko/01-introduction/01-chapter1.markdown | 26 ++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown index 436f67173..aa89d1a43 100644 --- a/ko/01-introduction/01-chapter1.markdown +++ b/ko/01-introduction/01-chapter1.markdown @@ -1,43 +1,43 @@ # 시작하기 # -이 장에서는 Git을 처음 접하는 사람에게 필요한 내용을 다룬다. 버전 관리 도구에 대한 전반적인 사항부터 시작해서 Git의 특징, Git을 설치하는 방법, 마지막으로 Git을 설정하는 법을 설명할 것이다. 이 장을 다 읽고 나면 Git의 탄생 배경과 Git을 사용하는 이유를 이해하고, Git을 사용하기 위한 준비가 다 되어있을 것이다. +이 장에서는 Git을 처음 접하는 사람에게 필요한 내용을 다룬다. 버전 관리 도구에 대한 약간의 배경지식, Git의 특징, Git을 설치하는 법 그리고 Git을 시작하기에 앞서 필요한 설정을 하는 방법을 설명한다. 이 장을 다 읽고 나면 Git의 탄생 배경과 Git이 사용되는 이유를 이해하고, Git을 시작하기 위한 준비가 되어있을 것이다. ## 버전 관리란? ## -버전 관리란 무엇이며, 이것을 왜 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 이 책에서는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만, 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다. +버전 관리란 무엇이며, 왜 이것을 알아야 할까? 버전 관리 시스템은 파일의 변화를 시간에 따라 기록하여 과거 특정 시점의 버전을 다시 불러올 수 있는 시스템이다. 이 책에는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다. -그래픽 디자이너나 웹 디자이너도 버전 관리 시스템(VCS - Version Control System)을 사용할 수 있다. VCS로 이미지나 레이아웃의 버전(변경 이력 혹은 수정 내용)을 관리하는 것은 매우 현명하다. VCS를 사용하면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다. VCS를 사용하면 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다. 이런 모든 장점을 큰 노력 없이 이용할 수 있다. +이미지나 레이아웃을 수정할 때마다 각각의 형태를 모두 보존하고 싶은 그래픽 디자이너나 웹 디자이너라면 버전 관리 시스템(Version Control System; VCS)을 사용하는 것이 현명할 수 있다. VCS를 사용하면 개별 파일 혹은 프로젝트 전체를 이전 상태로 되돌리거나 시간에 따른 변경 사항을 검토할 수 있으며, 문제가 되는 부분을 누가 마지막으로 수정했는지, 누가 언제 이슈를 만들어냈는지 등을 알 수 있다. 또한 파일을 잃어버리거나 무언가 잘못되어도 대개 쉽게 복구할 수 있다. 그리고 이 모든 장점을 누리는 데는 큰 노력이 들지 않는다. ### 로컬 버전 관리 시스템 ### -많은 사람은 버전을 관리하기 위해 디렉토리로 파일을 복사하는 방법을 쓴다(똑똑한 사람이라면 디렉토리 이름에 시간을 넣을 거다). 이 방법은 간단하므로 자주 사용한다. 그렇지만, 정말 뭔가가 잘못되기 쉽다. 작업하던 디렉토리를 지워버리거나, 실수로 파일을 잘못 고칠 수도 있고, 잘못 복사할 수도 있다. +대부분의 사람들이 버전 관리를 위해 쓰는 방법은 파일을 다른 디렉토리에 복사하는 것이다(똑똑한 사람이라면 디렉토리 이름에 시간을 넣을 것이다). 이 방법은 간단하고 자주 사용되는 방법이지만 실수가 발생하기 쉽다. 어느 디렉토리에서 작업하고 있었는지 잊어버리고 엉뚱한 파일을 덮어쓰거나 의도하지 않았던 위치로 복사할 수도 있다. -이런 이유로 프로그래머들은 오래전에 로컬 VCS라는 걸 만들었다. 이 VCS는 아주 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리했다. +이 문제를 해결하기 위해 오래전에 프로그래머들은 간단한 데이터베이스에 파일의 변경 사항을 기록하는 로컬 버전 관리 시스템을 만들었다(그림 1-1 참조). Insert 18333fig0101.png 그림 1-1. 로컬 버전 관리 다이어그램 -많이 쓰는 VCS 도구 중에 rcs라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사가 사용하고 있다. Mac OS X 운영체제에서도 개발 도구를 설치하면 RCS가 함께 설치된다. RCS는 기본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. 이 Patch Set은 특별한 형식의 파일로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다. +유명했던 VCS 도구들 중 현재에도 널리 쓰이는 것으로 RCS라 불리는 시스템이 있다. 그 예로 Mac OS X 운영체제에서는 개발 도구를 설치하면 RCS가 딸려온다. RCS의 기본적인 동작 방식은 각 리비전들 간의 패치 세트(patch set)라고 하는 데이터의 차이점들을 특별한 형식의 파일에 저장, 특정 시점의 파일 내용을 보고 싶을 때 해당 시점까지의 패치들을 모두 더하여 파일을 만들어내는 것이다. ### 중앙집중식 버전 관리 시스템 ### -프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제를 해결하기 위해 CVCS(중앙집중식 VCS)가 개발됐다. CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)한다. 수년 동안 이러한 시스템들이 많은 사랑을 받았다. +또 다른 문제는 시스템 외부에 있는 개발자들과 함께 작업하는 것이다. 중앙집중식 버전 관리 시스템(Centralized Version Control System; CVCS)은 이 문제를 해결하기 위해 개발됐다. CVS, Subversion, Perforce와 같은 시스템들이 여기에 속한다. CVCS에서는 버전 관리되는 모든 파일을 저장하는 하나의 서버와, 이 중앙 서버에서 파일들을 가져오는(checkout) 다수의 클라이언트가 존재한다. 오랫동안 사용된 이 방식은 지금까지도 버전 관리의 대표적인 방식이다(그림 1-2 참조). Insert 18333fig0102.png -그림 1-2. 중앙집중식 버전 관리(CVCS) 다이어그램 +그림 1-2. 중앙집중식 버전 관리 다이어그램 -CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한 사람이면 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다. +CVCS는 로컬 VCS에 비해 장점이 많다. 누구나 다른 사람들이 무엇을 하고 있는지 알 수 있고, 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. CVCS를 관리하는 것은 수많은 클라이언트의 로컬 데이터베이스를 관리하는 것보다 훨씬 쉽다. -그러나 CVCS 환경은 몇 가지 치명적인 결점이 있다. 가장 대표적인 것이 중앙 서버에 발생한 문제다. 만약 서버가 한 시간 동안 다운되면 그동안 아무도 다른 사람과 협업할 수 없고 사람들이 하는 일을 백업할 방법도 없다. 그리고 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다. 물론 사람마다 하나씩 가진 스냅샷은 괜찮다. 로컬 VCS 시스템도 이와 비슷한 결점이 있고 이런 문제가 발생하면 모든 것을 잃는다. +그러나 CVCS는 심각한 단점이 있다. 중앙 서버가 잘못되면 모든 것이 잘못된다는 점이다. 서버가 다운될 경우 서버가 다시 복구될 때까지 다른 사람과의 협업도, 진행 중이던 작업을 버전 관리하는 것도 불가능해진다. 중앙 데이터베이스가 저장된 하드디스크에 오류가 발생하고 백업도 없다면, 사람들이 각자 자신의 컴퓨터에 가지고 있던 스냅샷 외에는 그동안 쌓인 프로젝트의 이력을 모두 잃게 된다. 로컬 VCS 시스템도 같은 문제가 있다. 프로젝트의 모든 이력이 한곳에만 있을 경우 이것은 피할 수 없는 문제다. ### 분산 버전 관리 시스템 ### -DVCS(분산 버전 관리 시스템)을 설명할 차례다. Git, Mecurial, Bazaar, Darcs 같은 DVCS에서는 클라이언트가 파일의 마지막 스냅샷을 Checkout하지 않는다. 그냥 저장소를 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. 모든 Checkout은 모든 데이터를 가진 진정한 백업이다. +분산 버전 관리 시스템(Distributed Version Control System; DVCS)은 앞서 말한 문제를 해결하기 위해 개발되었다. Git, Mecurial, Bazaar, Darcs 등 DVCS에서는 클라이언트가 파일들의 마지막 스냅샷을 가져오는 대신 저장소(repository)를 통째로 복제한다. 따라서 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구된다. 체크아웃(checkout)을 할 때마다 전체 백업이 일어나는 셈이다(그림 1-3 참조). Insert 18333fig0103.png -그림 1-3. 분산 버전 관리 시스템(DVCS) 다이어그램 +그림 1-3. 분산 버전 관리 시스템 다이어그램 -게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 몇 가지 워크플로우를 사용할 수 있다. +게다가 대부분의 DVCS에서는 다수의 원격 저장소(remote repository)를 갖는 것이 가능하기 때문에 동시에 여러 그룹과 여러 방법으로 함께 작업할 수 있다. 이로 인해 계층 모델(hierarchical model) 등 중앙집중 시스템에서는 할 수 없는 다양한 작업 방식(workflow)들을 사용해볼 수 있다. ## 짧게 보는 Git의 역사 ## From 21d12234bac54cf05b7644b5deddba4e85b6f70f Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Sat, 9 Aug 2014 15:33:13 +0900 Subject: [PATCH 176/291] [ko] update README Add notes on pandoc --- ko/README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/ko/README.md b/ko/README.md index 747df1892..785666934 100644 --- a/ko/README.md +++ b/ko/README.md @@ -29,7 +29,17 @@ some additional information about the Korean translation. * xelatex: http://tug.org/mactex/ 4. 터미널에서 `./makeebooks ko` 실행 (mobi 파일 생성) -역주: 모든 명령어는 프로젝트의 루트 디렉토리에서 실행되어야 합니다. +## Pandoc 관련 노트 + +Pandoc 버전 1.9.1.1에서 확인된 [버그](https://github.com/jgm/pandoc/issues/964)로 인해 +~표 이후의 글자가 사라지는 현상이 있습니다. 버전 1.11.1 이상을 사용해주세요. `pandoc -v` 명령으로 +현재 버전을 알 수 있습니다. + +## 역주 + +* 모든 명령어는 프로젝트의 루트 디렉토리에서 실행되어야 합니다. +* 한국어판 PDF를 만들려면 [나눔바른고딕](http://hangeul.naver.com), + [나눔코딕코딩](http://dev.naver.com/projects/nanumfont/download) 글꼴이 필요합니다. # 정오표 From c0d036bec7eb88e0f9e011ee1be2461ee29488e1 Mon Sep 17 00:00:00 2001 From: Choongmin Lee Date: Sat, 9 Aug 2014 15:49:03 +0900 Subject: [PATCH 177/291] [ko] update translation of thanks --- ko/README.md | 8 ++++---- latex/config.yml | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/ko/README.md b/ko/README.md index 785666934..2e87baf4c 100644 --- a/ko/README.md +++ b/ko/README.md @@ -8,7 +8,7 @@ some additional information about the Korean translation. 3.0)](https://creativecommons.org/licenses/by-nc-sa/3.0/) 조건에 따라 이용할 수 있습니다. -이 책을 통해 Git을 즐겁게 배우시길 바랍니다. [출판된 책을 Amazon에서 구입](http://tinyurl.com/amazonprogit)하시면 +이 책을 통해 Git을 즐겁게 배울 수 있기를 바랍니다. [출판된 책을 Amazon에서 구입](http://tinyurl.com/amazonprogit)하시면 원저자인 Scott Chacon과 Apress 출판사에게 큰 도움이 됩니다. [git-scm.com](http://git-scm.com/book/)에서 영어, 한국어 및 10여개의 다른 언어로 온라인에서 읽을 수도 있습니다. @@ -64,9 +64,9 @@ Pandoc 버전 1.9.1.1에서 확인된 [버그](https://github.com/jgm/pandoc/iss # 한국어판 출판 및 역자 정보 -인사이트를 통해서 [Pro Git -한국어판](http://www.insightbook.co.kr/books/programming-insight/프로-git)이 -2013년 4월 19일에 출판되었습니다. 출판된 책을 구입하시면 도서출판 인사이트와 역자들에게 도움이 됩니다. +도서출판 인사이트를 통해서 +[한국어판](http://www.insightbook.co.kr/books/programming-insight/프로-git)이 +2013년 4월 19일에 출판되었습니다. 출판된 책을 구입하시면 인사이트와 역자들에게 도움이 됩니다. ## 역자 소개 diff --git a/latex/config.yml b/latex/config.yml index 33d11a1e7..c3baf1e90 100644 --- a/latex/config.yml +++ b/latex/config.yml @@ -127,7 +127,7 @@ ko: con: "목차" fig: "그림" tab: "표" - thanks: "지금 보시는 문서는 Pro Git 책에 대한 PDF 파일입니다. 본 문서는 Creative Commons 저작자표시-비영리조건-동일조건변경허락 3.0(Creative Commons Attribution-Non Commercial-Share Alike 3.0) 라이센스를 따릅니다. 여러분이 Git을 이해하는데 도움이 되기를 희망합니다. 종이로 출판된 책을 Amazon 웹사이트 \\url{http://tinyurl.com/amazonprogit} 에서 구입하여 저를 비롯한 Apress에도 도움을 주시기를 기대하겠습니다.\\newline한국어 번역판도 인사이트를 통해 종이로 출판됐습니다. 한국어 번역에 대한 자세한 정보는 \\url{https://github.com/progit/progit/tree/master/ko}에서 확인 바람니다." + thanks: "지금 보시는 문서는 책 「Pro Git」의 PDF 파일입니다. 본 문서는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 3.0 (Creative Commons Attribution-Non Commercial-Share Alike 3.0) 조건에 따라 이용할 수 있습니다. 이 책을 통해 Git을 즐겁게 배울 수 있기를 바랍니다. 출판된 책을 Amazon 웹사이트\\url{http://tinyurl.com/amazonprogit}에서 구입하시면 원저자인 Scott Chacon과 Apress 출판사에게 큰 도움이 됩니다.\\newline도서출판 인사이트를 통해서 한국어판이 2013년 4월 19일에 출판되었습니다. 한국어 번역에 대한 자세한 정보는 \\url{https://github.com/progit/progit/tree/master/ko}에서 확인해 주세요." be: prechap: "Глава " presect: "Раздзел " From 2f1eed8665a8dbb57d714c441dbd9268255a423b Mon Sep 17 00:00:00 2001 From: Ryuichi Okumura Date: Sun, 10 Aug 2014 21:26:54 +0900 Subject: [PATCH 178/291] Install git instead of git-core with yum The repository of yum seems that may be installed git instead of git-core as same as the Debian based distributions. --- en/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index d1248fee1..d859765ac 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -153,7 +153,7 @@ After this is done, you can also get Git via Git itself for updates: If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum: - $ yum install git-core + $ yum install git Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: From d1ec03e1b44a11fc21092e59ca53c938eaad41e0 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Sun, 10 Aug 2014 21:55:52 +0200 Subject: [PATCH 179/291] [cs] Chapter 1: Improve wording --- cs/01-introduction/01-chapter1.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 3e34d6e33..670b411ee 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -32,7 +32,7 @@ Avšak i tato koncepce má závažné nedostatky. Tímto nejkřiklavějším je ### Distribuované systémy správy verzí ### -V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verzí (DVCS z angl. Distributed Version Control System). V systémech DVCS (např. Git, Mercurial, Bazaar nebo Darcs) uživatelé pouze nestahují nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale uchovávají kompletní kopii repozitáře (repository). Pokud v takové situaci dojde ke kolapsu serveru, lze jej obnovit zkopírováním repozitáře od libovolného uživatele. Každá lokální kopie (checkout) je plnohodnotnou zálohou všech dat (viz obrázek 1-3). +V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verzí (DVCS z angl. Distributed Version Control System). V systémech DVCS (např. Git, Mercurial, Bazaar nebo Darcs) uživatelé nestahují pouze nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale uchovávají kompletní kopii repozitáře (repository). Pokud v takové situaci dojde ke kolapsu serveru, lze jej obnovit zkopírováním repozitáře od libovolného uživatele. Každá lokální kopie (checkout) je plnohodnotnou zálohou všech dat (viz obrázek 1-3). Insert 18333fig0103.png Obrázek 1-3. Diagram distribuované správy verzí @@ -69,7 +69,7 @@ Git zpracovává data jinak. Chápe je spíše jako sadu snímků (snapshots) vl Insert 18333fig0105.png Obrázek 1-5. Git ukládá data jako snímky projektu proměnlivé v čase. -Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git se podobá malému systému souborů (spíše než obyčejnému VCS) s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3. +Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git se podobá malému systému souborů (spíše než obyčejnému VCS) s řadou skutečně výkonných nástrojů, jež jsou na něm postavené. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3. ### Téměř každá operace je lokální ### From d687d7e50b4206f1135591cbe5ac1d0dcca93556 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Sun, 10 Aug 2014 22:15:43 +0200 Subject: [PATCH 180/291] [cs] Chapter 1 - Note that discussions on the IRC channel are in English --- cs/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 670b411ee..ee3a7e6d4 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -252,7 +252,7 @@ Například manpage nápovědu pro příkaz `config` vyvoláte zadáním: $ git help config Tyto příkazy jsou užitečné, neboť je můžete spustit kdykoli, dokonce i offline. -Pokud nestačí ani manuálová stránka ani tato kniha a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou. +Pokud nestačí ani manuálová stránka ani tato kniha a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou. (Nutno ovšem podotknout, že se na těchto kanálech mluví anglicky – pozn. překl.) ## Shrnutí ## From 8a2868cdaaace2e6a5ba7823c51d8ac0e4b8ffb2 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Sun, 10 Aug 2014 22:40:47 +0200 Subject: [PATCH 181/291] [cs] Chapter 2 - wording improvements, typo fixes --- cs/02-git-basics/01-chapter2.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index bb25003fd..f90025885 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -71,7 +71,7 @@ To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adr nothing added to commit but untracked files present (use "git add" to track) -Vidíte, že nový soubor `README` není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, obecně to znamená, že Git ví o souboru, který nebyl v předchozím snímku (v předchozí revizi), a nezařadí ho ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README zahrnout, a proto spusťme jeho sledování. +Vidíte, že nový soubor `README` není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, obecně to znamená, že Git ví o souboru, který nebyl v předchozím snímku (v předchozí revizi), a nezařadí ho ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README zahrnout, a proto ho začněme sledovat. ### Sledování nových souborů ### @@ -109,7 +109,7 @@ Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už modified: benchmarks.rb -Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (změněny nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). Chcete-li ho připravit k zapsání, spusťte příkaz `git add` (jedná se o víceúčelový příkaz – používá se k zahájení sledování nových souborů i k dalším operacím, jako je například označení vyřešených případů kolize souborů při slučování). Spusťme nyní příkaz `git add`, abychom soubor `benchmarks.rb` připravili k zapsání, a potom znovu zadejme příkaz `git status`: +Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (změny, které nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). Chcete-li ho připravit k zapsání, spusťte příkaz `git add` (jedná se o víceúčelový příkaz – používá se k zahájení sledování nových souborů i k dalším operacím, jako je například označení vyřešených případů kolize souborů při slučování). Spusťme nyní příkaz `git add`, abychom soubor `benchmarks.rb` připravili k zapsání, a potom znovu zadejme příkaz `git status`: $ git add benchmarks.rb $ git status @@ -159,7 +159,7 @@ Ve vašem adresáři se často vyskytne skupina souborů, u nichž nebudete cht *.[oa] *~ -První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – *objekty* a *archivní* soubory, které mohou být výsledkem překladu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci a podobné. Vytvoření a naplnění souboru `.gitignore` ještě dříve než se pustíte do práce, bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte. +První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – *objekty* a *archivní* soubory, které mohou být výsledkem překladu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci a podobné. Vytvoření a naplnění souboru `.gitignore` ještě dříve než se pustíte do práce bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte. Pravidla pro masky, které můžete použít v souboru `.gitignore`, jsou následující: @@ -579,8 +579,8 @@ Tabulka 2-1 uvádí některé užitečné parametry, které format akceptuje. %h Zkrácený otisk revize %T Otisk stromu %t Zkrácený otisk stromu - %P Nadřazené otisky - %p Zkrácené nadřazené otisky + %P Otisky rodičovských revizí + %p Zkrácené otisky rodičovských revizí %an Jméno autora %ae E-mail autora %ad Datum autora (formát je možné nastavit parametrem --date) From be9fa675bad4e16d1f506fd0d181e3eca10d7f62 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Sun, 10 Aug 2014 22:41:30 +0200 Subject: [PATCH 182/291] [cs] Chapter 2 - Give the English equivalent for "glob patterns" --- cs/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index f90025885..c301bbb54 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -164,7 +164,7 @@ První řádek říká systému Git, že má ignorovat všechny soubory končíc Pravidla pro masky, které můžete použít v souboru `.gitignore`, jsou následující: * Prázdné řádky nebo řádky začínající znakem `#` budou ignorovány. -* Standardní masky souborů. +* Standardní masky souborů (glob patterns). * Chcete-li označit adresář, můžete masku zakončit lomítkem (`/`). * Pokud řádek začíná vykřičníkem (`!`), maska na něm je negována. From e2b9d99e752653fa19b57124aa72dc7728bc89c7 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Tue, 12 Aug 2014 16:59:07 +0200 Subject: [PATCH 183/291] [it] updating chapter 1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Così suona meglio --- it/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 8f716ca98..58e00a284 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -155,7 +155,7 @@ Se vuoi installare Git su Linux, tramite una installazione da binario, generalme $ yum install git-core -O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get: +O, se usi una distribuzione basata su Debian (come Ubuntu) prova apt-get: $ apt-get install git From 6737149397f57726b37b5881b504ad62885a74e6 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Tue, 12 Aug 2014 16:48:14 +0200 Subject: [PATCH 184/291] Updating yum package name for git Currently seems the repository of yum has a git package instead of git-core. Now it's the same as for Debian based distributions. See also PR #851 --- it/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 8f716ca98..f8e5a3ccd 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -153,7 +153,7 @@ Dopo aver fatto questo, puoi scaricare gli aggiornamenti di Git con lo stesso Gi Se vuoi installare Git su Linux, tramite una installazione da binario, generalmente puoi farlo con lo strumento base di amministrazione dei pacchetti della tua distribuzione. Se usi Fedora, puoi usare yum: - $ yum install git-core + $ yum install git O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get: From f6bc9c5b64b23202dfaa865572177f6b8f44aa1d Mon Sep 17 00:00:00 2001 From: Peter Vojtek Date: Tue, 12 Aug 2014 18:52:32 +0200 Subject: [PATCH 185/291] change past tense to present in commit msgs in chapter 3.2 (Branching) --- en/03-git-branching/01-chapter3.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown index adf1995d1..3d63b2577 100644 --- a/en/03-git-branching/01-chapter3.markdown +++ b/en/03-git-branching/01-chapter3.markdown @@ -132,7 +132,7 @@ Figure 3-11. Creating a new branch pointer. You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12): $ vim index.html - $ git commit -a -m 'added a new footer [issue 53]' + $ git commit -a -m 'add a new footer [issue 53]' Insert 18333fig0312.png Figure 3-12. The iss53 branch has moved forward with your work. @@ -151,8 +151,8 @@ Next, you have a hotfix to make. Let’s create a hotfix branch on which to work $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html - $ git commit -a -m 'fixed the broken email address' - [hotfix 3a0874c] fixed the broken email address + $ git commit -a -m 'fix the broken email address' + [hotfix 3a0874c] fix the broken email address 1 files changed, 1 deletion(-) Insert 18333fig0313.png @@ -184,8 +184,8 @@ Now you can switch back to your work-in-progress branch on issue #53 and continu $ git checkout iss53 Switched to branch 'iss53' $ vim index.html - $ git commit -a -m 'finished the new footer [issue 53]' - [iss53 ad82d7a] finished the new footer [issue 53] + $ git commit -a -m 'finish the new footer [issue 53]' + [iss53 ad82d7a] finish the new footer [issue 53] 1 file changed, 1 insertion(+) Insert 18333fig0315.png From 421b64f2ac3b608c5bcc7b322aeaff47a7675692 Mon Sep 17 00:00:00 2001 From: Ryuichi Okumura Date: Sat, 16 Aug 2014 10:23:03 +0900 Subject: [PATCH 186/291] [ja] Update chapter 1 This change is follow up of #851. --- ja/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown index 9dc643ca3..8f779f48d 100644 --- a/ja/01-introduction/01-chapter1.markdown +++ b/ja/01-introduction/01-chapter1.markdown @@ -155,7 +155,7 @@ Gitをインストールするためには、Gitが依存するライブラリ バイナリのインストーラーを通じてLinux上にGitをインストールしたいのであれば、大抵はディストリビューションに付属する基本的なパッケージ・マネジメント・ツールを使って、それを行なう事ができます。もしFedoraを使っているのであれば、yumを使う事が出来ます： - $ yum install git-core + $ yum install git もしくは、もしUbuntuのようなDebianベースのディストリュビューションを使っているのであれば、apt-getをやってみましょう： From e70bff13af562b256dc1617ef7540daffc44f9ff Mon Sep 17 00:00:00 2001 From: Hans Ginzel Date: Mon, 18 Aug 2014 12:21:44 +0200 Subject: [PATCH 187/291] Update 01-chapter9.markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Oprava nechcete ignorovat → chcete ignorovat (soubory z .gitignore). --- cs/09-git-internals/01-chapter9.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown index 3fe65175e..33ac85619 100644 --- a/cs/09-git-internals/01-chapter9.markdown +++ b/cs/09-git-internals/01-chapter9.markdown @@ -27,7 +27,7 @@ Spustíte-li v novém nebo existujícím adresáři příkaz `git init`, Git vyt objects/ refs/ -Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, takže o tyto dvě položky se nemusíte starat. Soubor `config` obsahuje konfigurační nastavení vašeho projektu a v adresáři `info` je uložen globální soubor `exclude` s maskami ignorovaných souborů a adresářů, které nechcete explicitně ignorovat prostřednictvím souboru `.gitignore`. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 7. +Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, takže o tyto dvě položky se nemusíte starat. Soubor `config` obsahuje konfigurační nastavení vašeho projektu a v adresáři `info` je uložen globální soubor `exclude` s maskami ignorovaných souborů a adresářů, které chcete explicitně ignorovat prostřednictvím souboru `.gitignore`. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 7. Zbývají čtyři důležité položky: soubory `HEAD` a `index` a adresáře `objects` a `refs`. To jsou ústřední součásti adresáře Git. V adresáři `objects` je uložen celý obsah vaší databáze, v adresáři `refs` jsou uloženy ukazatele na objekty revizí v datech (větve). Soubor `HEAD` ukazuje na větev, na níž se právě nacházíte, a soubor `index` je pro systém Git úložištěm informací o oblasti připravených změn. Na každou z těchto částí se teď podíváme podrobněji, abyste pochopili, jak Git pracuje. From 88811569e6ebd10dce719cc25afbfdc4755e15da Mon Sep 17 00:00:00 2001 From: hsy Date: Tue, 19 Aug 2014 15:10:19 +0800 Subject: [PATCH 188/291] [zh] Update chapter 3, fixed one spelling --- zh/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown index 05bc4817f..56cb8b96b 100644 --- a/zh/03-git-branching/01-chapter3.markdown +++ b/zh/03-git-branching/01-chapter3.markdown @@ -394,7 +394,7 @@ Insert 18333fig0321.png Insert 18333fig0322.png 图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 `origin` 上的 `master` 分支。 -如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。 +如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而与此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。 Insert 18333fig0323.png 图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。 From 8cd54f51023f465e4d4c6547a6d61651b57f1806 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 19 Aug 2014 16:03:29 +0200 Subject: [PATCH 189/291] [cs] fix after merging with newer [en] --- cs/01-introduction/01-chapter1.markdown | 2 +- cs/03-git-branching/01-chapter3.markdown | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index ee3a7e6d4..35e688ebe 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -153,7 +153,7 @@ Po dokončení instalace můžete rovněž vyhledat aktualizace systému Git pro Chcete-li nainstalovat Git v Linuxu pomocí binárního instalátoru, většinou tak můžete učinit pomocí základního nástroje pro správu balíčků, který je součástí vaší distribuce. Ve Fedoře můžete použít nástroj yum: - $ yum install git-core + $ yum install git V distribuci založené na Debianu (jako je například Ubuntu) zkuste použít program apt-get: diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 2b46fc54b..37a3352c1 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -132,7 +132,7 @@ Obrázek 3-11. Vytvoření nového ukazatele na větev Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že na ni přepnuli ukazuje HEAD – viz obrázek 3-12): $ vim index.html - $ git commit -a -m 'added a new footer [issue 53]' + $ git commit -a -m 'add a new footer [issue 53]' Insert 18333fig0312.png Obrázek 3-12. Větev iss53 se s vaší prací posouvá vpřed. @@ -151,8 +151,8 @@ Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme p $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html - $ git commit -a -m 'fixed the broken email address' - [hotfix 3a0874c] fixed the broken email address + $ git commit -a -m 'fix the broken email address' + [hotfix 3a0874c] fix the broken email address 1 files changed, 1 deletion(-) Insert 18333fig0313.png @@ -184,8 +184,8 @@ Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na c $ git checkout iss53 Switched to branch 'iss53' $ vim index.html - $ git commit -a -m 'finished the new footer [issue 53]' - [iss53 ad82d7a] finished the new footer [issue 53] + $ git commit -a -m 'finish the new footer [issue 53]' + [iss53 ad82d7a] finish the new footer [issue 53] 1 file changed, 1 insertion(+) Insert 18333fig0315.png From 2a55c7db6bb7ef82720b84ee2a351027637d8e6f Mon Sep 17 00:00:00 2001 From: Soon Van Date: Tue, 19 Aug 2014 11:18:44 -0400 Subject: [PATCH 190/291] Update link and name to Plans and pricing page --- az/04-git-server/01-chapter4.markdown | 2 +- cs/04-git-server/01-chapter4.markdown | 2 +- de/04-git-server/01-chapter4.markdown | 4 ++-- en/04-git-server/01-chapter4.markdown | 4 ++-- es/04-git-server/01-chapter4.markdown | 2 +- fr/04-git-server/01-chapter4.markdown | 2 +- it/04-git-server/01-chapter4.markdown | 2 +- ja/04-git-server/01-chapter4.markdown | 2 +- ko/04-git-server/01-chapter4.markdown | 2 +- nl/04-git-server/01-chapter4.markdown | 2 +- no-nb/04-git-server/01-chapter4.markdown | 2 +- pl/04-git-server/01-chapter4.markdown | 2 +- pt-br/04-git-server/01-chapter4.markdown | 2 +- ru/04-git-server/01-chapter4.markdown | 2 +- zh-tw/04-git-server/01-chapter4.markdown | 2 +- zh/04-git-server/01-chapter4.markdown | 2 +- 16 files changed, 18 insertions(+), 18 deletions(-) diff --git a/az/04-git-server/01-chapter4.markdown b/az/04-git-server/01-chapter4.markdown index 1e4df37b1..c51b6a74d 100644 --- a/az/04-git-server/01-chapter4.markdown +++ b/az/04-git-server/01-chapter4.markdown @@ -738,7 +738,7 @@ GitHub is also a commercial company that charges for accounts that maintain priv ### Setting Up a User Account ### -The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page. +The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page. Insert 18333fig0402.png Figure 4-2. The GitHub plan page. diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 5e4d1a27c..46ac01d16 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -744,7 +744,7 @@ GitHub je zároveň komerční společnost, jejíž finanční příjmy plynou z ### Založení uživatelského účtu ### -První věcí, kterou budete muset udělat, je vytvoření bezplatného uživatelské účtu. Jestliže na stránce „Pricing and Signup“ (`http://github.com/plans`) kliknete u bezplatného účtu (Free) na tlačítko „Sign Up“ (viz obrázek 4-2), přejdete na registrační stránku. +První věcí, kterou budete muset udělat, je vytvoření bezplatného uživatelské účtu. Jestliže na stránce „Pricing and Signup“ (`https://github.com/pricing`) kliknete u bezplatného účtu (Free) na tlačítko „Sign Up“ (viz obrázek 4-2), přejdete na registrační stránku. Insert 18333fig0402.png Obrázek 4-2. Výběr typu účtu na serveru GitHub diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown index 16f912007..e0f25980c 100644 --- a/de/04-git-server/01-chapter4.markdown +++ b/de/04-git-server/01-chapter4.markdown @@ -1121,9 +1121,9 @@ Wenn ein Anwender ein geschützes, nicht öffentliches Repository auf GitHub ver ## Einrichten eines Benutzeraccounts ### - + -Um loslegen zu können, musst Du Dir einen Benutzeraccount erstellen. Gib dazu die Adresse `http://github.com/plans` in Deinem Browser ein und wähle den Button „Sign Up“ unter dem „Free account“-Bereich aus (siehe Abbildung 4-2). Danach wirst Du auf die Anmeldeseite weitergeleitet. +Um loslegen zu können, musst Du Dir einen Benutzeraccount erstellen. Gib dazu die Adresse `https://github.com/pricing` in Deinem Browser ein und wähle den Button „Sign Up“ unter dem „Free account“-Bereich aus (siehe Abbildung 4-2). Danach wirst Du auf die Anmeldeseite weitergeleitet. diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown index 8ff5fa1a0..88bfff101 100644 --- a/en/04-git-server/01-chapter4.markdown +++ b/en/04-git-server/01-chapter4.markdown @@ -742,13 +742,13 @@ GitHub is by far the largest open source Git hosting site and it’s also one of ### GitHub ### -GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project. +GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user-centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project. GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done. ### Setting Up a User Account ### -The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. +The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. Insert 18333fig0402.png Figure 4-2. The GitHub plan page. diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown index 81597c804..b9fde505d 100755 --- a/es/04-git-server/01-chapter4.markdown +++ b/es/04-git-server/01-chapter4.markdown @@ -584,7 +584,7 @@ GitHub es también una compañia comercial, que cobra por las cuentas que tienen ### Configurando una cuenta de usuario ### -El primer paso es dar de alta una cuenta gratuita. Si visitas la página de Precios e Inicio de Sesión, en 'http://github.com/plans', y clicas sobre el botón "Registro" ("Sign Up") de las cuentas gratuitas, verás una página de registro: +El primer paso es dar de alta una cuenta gratuita. Si visitas la página de Precios e Inicio de Sesión, en 'https://github.com/pricing', y clicas sobre el botón "Registro" ("Sign Up") de las cuentas gratuitas, verás una página de registro: Insert 18333fig0402.png Figura 4-2. La página de planes GitHub. diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown index 76257d723..5d68cb7bb 100644 --- a/fr/04-git-server/01-chapter4.markdown +++ b/fr/04-git-server/01-chapter4.markdown @@ -983,7 +983,7 @@ Nous allons détailler comment faire. ### Création d'un compte utilisateur ### La première chose à faire, c'est de créer un compte utilisateur gratuit. -Visitez la page « Plans & Pricing » (plans et prix) à `http://github.com/plans` et cliquez sur le bouton « Create a free account » (créer un compte gratuit) de la zone « Free for open source » (gratuit pour l'open source) (voir figure 4-2) qui vous amène à la page d'enregistrement. +Visitez la page « Plans and pricing » (plans et prix) à `https://github.com/pricing` et cliquez sur le bouton « Create a free account » (créer un compte gratuit) de la zone « Free for open source » (gratuit pour l'open source) (voir figure 4-2) qui vous amène à la page d'enregistrement. Insert 18333fig0402.png Figure 4-2. La page des différents plans de GitHub. diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown index 431538b69..388095f08 100644 --- a/it/04-git-server/01-chapter4.markdown +++ b/it/04-git-server/01-chapter4.markdown @@ -741,7 +741,7 @@ GitHub è inoltre una organizzazione commerciale che addebita gli account che ma ### Configurare un Account Utente ### -La prima cosa di cui hai bisogno è configurare un account utente gratuito. Se visiti la pagina "Pricing and Signup" all'inidirizzo `http://github.com/plans` e fai click sul pulsante "Sign Up" per un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione. +La prima cosa di cui hai bisogno è configurare un account utente gratuito. Se visiti la pagina "Plans and pricing" all'inidirizzo `http://https://github.com/pricing` e fai click sul pulsante "Sign Up" per un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione. Insert 18333fig0402.png Figura 4-2. La pagina dei piani di GitHub. diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown index af26092c6..3beeeedbe 100644 --- a/ja/04-git-server/01-chapter4.markdown +++ b/ja/04-git-server/01-chapter4.markdown @@ -741,7 +741,7 @@ GitHub は営利企業なので、非公開のリポジトリについては料 ### ユーザーアカウントの作成 ### -まずはフリー版のユーザーアカウントを作成しましょう。Pricing and Signup のページ `http://github.com/plans` で、フリーアカウントの "Sign Up" ボタンを押すと (図 4-2 を参照ください)、新規登録ページに移動します。 +まずはフリー版のユーザーアカウントを作成しましょう。Plans and pricing のページ `https://github.com/pricing` で、フリーアカウントの "Sign Up" ボタンを押すと (図 4-2 を参照ください)、新規登録ページに移動します。 Insert 18333fig0402.png 図 4-2. GitHub のプラン説明ページ diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown index ff28be894..b093a204d 100644 --- a/ko/04-git-server/01-chapter4.markdown +++ b/ko/04-git-server/01-chapter4.markdown @@ -745,7 +745,7 @@ GitHub은 이윤을 목적으로 하는 회사이기 때문에 비공개 저장 ### 계정 설정하기 ### -먼저 무료 계정을 하나 만든다. 가격 정책에 대해 알려주며 가입을 시작할 수 있는 `http://github.com/plans`에 방문하여 "Sign up" 버튼을 클릭한다. 그러면 가입 페이지로 이동한다. +먼저 무료 계정을 하나 만든다. 가격 정책에 대해 알려주며 가입을 시작할 수 있는 `https://github.com/pricing`에 방문하여 "Sign up" 버튼을 클릭한다. 그러면 가입 페이지로 이동한다. Insert 18333fig0402.png 그림 4-2. GitHub 가격 정책 페이지 diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown index 4ddf3e9fc..1068d2e82 100644 --- a/nl/04-git-server/01-chapter4.markdown +++ b/nl/04-git-server/01-chapter4.markdown @@ -779,7 +779,7 @@ GitHub is ook een commercieel bedrijf dat geld vraagt voor accounts die privé r ### Een gebruikersaccount instellen ### -Het eerste dat je moet doen is een gratis gebruikers account aanvragen. Als je de Pricing and Signup pagina op `http://github.com/plans` bezoekt en de "Sign Up" knop aanklikt op het Free account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht. +Het eerste dat je moet doen is een gratis gebruikers account aanvragen. Als je de "Plans and pricing" pagina op `https://github.com/pricing` bezoekt en de "Sign Up" knop aanklikt op het Free account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht. Insert 18333fig0402.png Figuur 4-2. De GitHub plan pagina. diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown index a52ba5361..2bf5855cc 100644 --- a/no-nb/04-git-server/01-chapter4.markdown +++ b/no-nb/04-git-server/01-chapter4.markdown @@ -744,7 +744,7 @@ GitHub is also a commercial company that charges for accounts that maintain priv ### Setting Up a User Account ### -The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. +The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. Insert 18333fig0402.png Figure 4-2. The GitHub plan page. diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown index 90b545c36..23fb04850 100644 --- a/pl/04-git-server/01-chapter4.markdown +++ b/pl/04-git-server/01-chapter4.markdown @@ -774,7 +774,7 @@ GitHub jest również spółką handlową, która pobiera opłaty za utrzymanie ### Konfigurowanie konta użytkownika ### -Pierwszą rzeczą jaką musisz zrobić jest założenie darmowego konta użytkownika. W tym celu wchodzisz na stronę rejestracji `http://github.com/plans` i klikasz przycisk "Zarejestruj się" na darmowe konto (patrz rysunek 4-2) i jesteś już przeniesiony na stronę rejestracji. +Pierwszą rzeczą jaką musisz zrobić jest założenie darmowego konta użytkownika. W tym celu wchodzisz na stronę rejestracji `https://github.com/pricing` i klikasz przycisk "Zarejestruj się" na darmowe konto (patrz rysunek 4-2) i jesteś już przeniesiony na stronę rejestracji. Insert 18333fig0402.png Figure 4-2. Strona rejestracji GitHub. diff --git a/pt-br/04-git-server/01-chapter4.markdown b/pt-br/04-git-server/01-chapter4.markdown index c97feb3ae..7b633ec58 100644 --- a/pt-br/04-git-server/01-chapter4.markdown +++ b/pt-br/04-git-server/01-chapter4.markdown @@ -766,7 +766,7 @@ GitHub também é uma empresa comercial que cobra para contas que mantêm reposi ### Criando uma Conta de Usuário ### -A primeira coisa que você precisa fazer é criar uma conta de usuário gratuita. Se você visitar a página de Preços e Inscrição em `http://github.com/plans` e clicar no botão "Sign Up" na conta gratuita (ver figura 4-2), você é levado à página de inscrição. +A primeira coisa que você precisa fazer é criar uma conta de usuário gratuita. Se você visitar a página de Preços e Inscrição em `https://github.com/pricing` e clicar no botão "Sign Up" na conta gratuita (ver figura 4-2), você é levado à página de inscrição. Insert 18333fig0402.png Figure 4-2. A página de planos do GitHub. diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown index 92d11d939..30927a9a7 100644 --- a/ru/04-git-server/01-chapter4.markdown +++ b/ru/04-git-server/01-chapter4.markdown @@ -731,7 +731,7 @@ GitHub — это коммерческая компания, которая вз ### Настройка учётной записи ### -Первое, что вам нужно сделать, это настроить учётную запись. Если вы посетите страницу Plans & Pricing по адресу `http://github.com/plans` и нажмёте на кнопку "Create a free account" (см. рисунок 4-2), вы попадёте на страницу регистрации. +Первое, что вам нужно сделать, это настроить учётную запись. Если вы посетите страницу "Plans and pricing" по адресу `https://github.com/pricing` и нажмёте на кнопку "Create a free account" (см. рисунок 4-2), вы попадёте на страницу регистрации. Insert 18333fig0402.png Рисунок 4-2. Страница тарифных планов на GitHub'е. diff --git a/zh-tw/04-git-server/01-chapter4.markdown b/zh-tw/04-git-server/01-chapter4.markdown index cfd2f2e3f..b9aa91489 100644 --- a/zh-tw/04-git-server/01-chapter4.markdown +++ b/zh-tw/04-git-server/01-chapter4.markdown @@ -743,7 +743,7 @@ GitHub 同時也是一個向使用私有倉庫的用戶收取費用的商業公 ### 建立新帳戶 ### -首先註冊一個免費帳戶。訪問 Pricing and Signup 頁面 `http://github.com/plans` 並點擊 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。 +首先註冊一個免費帳戶。訪問 "Plans and pricing" 頁面 `https://github.com/pricing` 並點擊 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。 Insert 18333fig0402.png 圖 4-2. GitHub 服務簡介頁面 diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown index ef41b90b2..a2cd86672 100644 --- a/zh/04-git-server/01-chapter4.markdown +++ b/zh/04-git-server/01-chapter4.markdown @@ -743,7 +743,7 @@ GitHub 同时也是一个向使用私有仓库的用户收取费用的商业公 ### 建立新账户 ### -首先注册一个免费账户。访问 Pricing and Signup 页面 `http://github.com/plans` 并点击 Free acount 里的 Sign Up 按钮（见图 4-2），进入注册页面。 +首先注册一个免费账户。访问 "Plans and pricing" 页面 `https://github.com/pricing` 并点击 Free acount 里的 Sign Up 按钮（见图 4-2），进入注册页面。 Insert 18333fig0402.png 图 4-2. GitHub 服务简介页面 From c9c079fc5cd96c1846b2d8fbc098a30d3bca3c7c Mon Sep 17 00:00:00 2001 From: Kieran Spear Date: Fri, 22 Aug 2014 16:17:14 +1000 Subject: [PATCH 191/291] Fix BFG capability --- en/06-git-tools/01-chapter6.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 16179c5aa..18044f27e 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -750,7 +750,7 @@ This goes through and rewrites every commit to have your new address. Because co ### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner (BFG) ### -[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capaility, and you have performance issues, then you should consider using it. +[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capability, and you have performance issues, then you should consider using it. See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details. From d11be6feb16db1269ed29b8663ac6c01088547a9 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 22 Aug 2014 12:53:48 +0200 Subject: [PATCH 192/291] [cs] "killer feature" translation (left out) --- cs/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 37a3352c1..95f3afe98 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -2,7 +2,7 @@ Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho. -Někteří lidé mluví o modelu větvení v systému Git jako o převratné vlastnosti („killer feature“). Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. +Někteří lidé mluví o modelu větvení v systému Git jako o převratné vlastnosti. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj. ## Co je to větev ## From 1361b5850a8b8e2f29f05763102d99d559bfd8a3 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 22 Aug 2014 15:39:25 +0200 Subject: [PATCH 193/291] [cs] ch1 typo, ch4 wording --- cs/01-introduction/01-chapter1.markdown | 2 +- cs/04-git-server/01-chapter4.markdown | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 35e688ebe..33aa76d00 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -41,7 +41,7 @@ Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika ## Stručná historie systému Git ## -Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software celkém velkého rozsahu, s otevřeným kódem. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem BitKeeper. +Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software celkem velkého rozsahu, s otevřeným kódem. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem BitKeeper. V roce 2005 se zhoršily vztahy mezi komunitou, která vyvíjela jádro Linuxu, a komerční společností, která vyvinula BitKeeper, a společnost přestala tento systém poskytovat zdarma. To přimělo komunitu vývojářů Linuxu (a zejména Linuse Torvaldse, tvůrce Linuxu), aby vyvinula vlastní nástroj, založený na poznatcích, které nasbírala při užívání systému BitKeeper. Mezi požadované vlastnosti systému patřily zejména: diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index d3b0c44b7..18566f64a 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -1,20 +1,20 @@ # Git na serveru # -V této chvíli byste už měli zvládat většinu každodenních úkonů, pro něž se vyplatí Git používat. Abyste však mohli v systému Git spolupracovat s ostatními, budete potřebovat vzdálený repozitář Git. Technicky vzato sice můžete odesílat a stahovat změny z repozitářů jednotlivých spolupracovníků, tento postup ale nedoporučujeme, protože se může při troše neopatrnosti velmi snadno stát, že zapomenete, kdo na čem pracuje. Navíc chcete, aby měli vaši spolupracovníci do repozitáře přístup, i když je váš počítač offline – na společný repozitář bývá často lepší spolehnutí. Jako nejlepší metodu spolupráce s ostatními proto můžeme doporučit nastavení „neutrálního“ repozitáře, do nějž budete mít všichni přístup, budete do něj moci odesílat data a budete z něj moci stahovat. Tomuto repozitáři budeme říkat „server Git“. Jak ale zjistíte, nebývá hostování repozitáře Git nijak zvlášť náročné na zdroje, a tak nejspíš nebudete potřebovat celý server. +V této chvíli byste už měli zvládat většinu každodenních úkonů, pro něž se vyplatí Git používat. Abyste však mohli v systému Git spolupracovat s ostatními, budete potřebovat vzdálený repozitář Git. Technicky vzato sice můžete odesílat a stahovat změny z repozitářů jednotlivých spolupracovníků, tento postup ale nedoporučujeme, protože se může při troše neopatrnosti velmi snadno stát, že zapomenete, kdo na čem pracuje. Navíc chcete, aby měli vaši spolupracovníci do repozitáře přístup, i když je váš počítač vypnutý nebo odpojený – na společný repozitář bývá často lepší spolehnutí. Jako nejlepší metodu spolupráce s ostatními proto můžeme doporučit nastavení „neutrálního“ repozitáře, do nějž budete mít všichni přístup, budete do něj moci odesílat data a budete z něj moci stahovat. Tomuto repozitáři budeme říkat „gitový server“. Jak ale zjistíte, nebývá hostování gitového repozitáře nijak zvlášť náročné na zdroje, a tak nejspíš nebudete potřebovat celý server. -Spuštění serveru Git je jednoduché. Nejprve určíte, jakými protokoly má váš server komunikovat. První část této kapitoly se bude věnovat možným protokolům, jejich přednostem a nevýhodám. V dalších částech popíšeme některá typická nastavení pro použití těchto protokolů, a jak s nimi uvést server do provozu. Nakonec se podíváme na několik možností hostování pro případ, že nebudete mít chuť podstupovat martyrium s nastavováním a správou vlastního serveru a nevadí vám umístit svůj kód na cizí server. +Zprovoznění gitového serveru je jednoduché. Nejprve určíte, jakými protokoly má váš server komunikovat. První část této kapitoly se bude věnovat možným protokolům, jejich přednostem a nevýhodám. V dalších částech popíšeme některá typická nastavení pro použití těchto protokolů, a jak s nimi uvést server do provozu. Nakonec se podíváme na několik možností hostování pro případ, že nebudete mít chuť podstupovat martyrium s nastavováním a správou vlastního serveru a nevadí vám umístit svůj kód na cizí server. -Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o různých vstupech a výstupech při práci v prostředí s distribuovanou správou zdrojového kódu. +Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o detailech a záludnostech při práci v prostředí s distribuovanou správou zdrojového kódu. -Vzdálený repozitář je obvykle *holý repozitář* (bare repository), tj. repozitář Git bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc. +Vzdálený repozitář je obvykle *holý repozitář* (bare repository), tj. gitový repozitář bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc. ## Protokoly ## Git může k přenosu dat používat jeden ze čtyř hlavních síťových protokolů: Local, Secure Shell (SSH), Git nebo HTTP. V této části se podíváme na to, co jsou jednotlivé protokoly zač a za jakých okolností je (ne)vhodné je použít. -Neměli bychom zamlčet ani to, že s výjimkou protokolu HTTP všechny vyžadují, aby byl na serveru nainstalován a spuštěn systém Git. +Neměli bychom zamlčet ani to, že s výjimkou protokolu HTTP všechny vyžadují, aby byl na serveru nainstalován a zprovozněn systém Git. -### Protokol Local ### +### Lokální protokol ### Nejzákladnější variantou je *lokální protokol* (Local protocol), v němž je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k vašim sdíleným souborům, např. přes připojení systému NFS, nebo – v méně pravděpodobném případě – se všichni přihlašují na jednom počítači. Tato druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou v takovém případě umístěny v jednom počítači, čímž se zvyšuje riziko nevratné ztráty dat. From fb71aa4628cfed003914298d167a50657a0b20ea Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sat, 23 Aug 2014 16:08:19 +0200 Subject: [PATCH 194/291] [cs] part of ch.4 revised --- cs/04-git-server/01-chapter4.markdown | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 18566f64a..dbe0741b6 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -26,7 +26,7 @@ Nebo můžete provést následující: $ git clone file:///opt/git/project.git -Pokud na začátek URL explicitně zadáte výraz `file://`, pracuje Git trochu jinak. Pokud pouze zadáte cestu, Git se pokusí použít hardlinky nebo rovnou zkopírovat soubory, které potřebuje. Pokud zadáte výraz `file://`, Git spustí procesy, jež běžně používá k přenosu dat prostřednictvím sítě. Síť je většinou výrazně méně výkonnou metodou přenosu dat. Hlavním důvodem, proč zadat předponu `file://` je to, že tak získáte čistou kopii repozitáře bez nepotřebných referencí a objektů, např. po importu z jiného verzovacího systému a podobně (úkony správy jsou popsány v kapitole 9). My budeme používat normální cestu, neboť tato metoda je téměř vždy rychlejší. +Pokud na začátek URL explicitně zadáte výraz `file://`, pracuje Git trochu jinak. Pokud pouze zadáte cestu a zdroj i cíl se nacházejí ve stejném systému souborů, pokusí se Git použít hardlinky na potřebné objekty. Pokud se nenacházejí ve stejném systému souborů, dojde k okopírování potřebných objektů pomocí standardních prostředků systému pro kopírování. Pokud zadáte výraz `file://`, Git spustí procesy, jež běžně používá k přenosu dat prostřednictvím sítě. Síť je většinou výrazně méně výkonnou metodou přenosu dat. Hlavním důvodem, proč zadat předponu `file://` je to, že tak získáte čistou kopii repozitáře bez nepotřebných referencí a objektů, například po importu z jiného verzovacího systému a podobně (úkony správy jsou popsány v kapitole 9). My budeme používat normální cestu, neboť tato metoda je téměř vždy rychlejší. K přidání lokálního repozitáře do existujícího projektu Git můžete použít příkaz například v tomto tvaru: @@ -44,17 +44,17 @@ Jedná se také o výbornou možnost, jak rychle získat práci z pracovního re Nevýhodou této metody je, že nastavit a získat sdílený přístup z více umístění je většinou těžší než obyčejný síťový přístup. Budete-li chtít pracovat doma a odeslat data z notebooku, budete muset připojit vzdálený disk, což může být ve srovnání s přístupem prostřednictvím sítě složité a pomalé. -Zapomenout bychom neměli ani na to, že používáte-li sdílené připojení určitého druhu, nemusí být tato možnost vždy nutně nejrychlejší. Lokální repozitář je rychlý pouze v případě, že máte rychlý přístup k datům. Repozitář na NFS je často pomalejší než repozitář nad SSH na tomtéž serveru, který ve všech systémech umožňuje spustit Git z lokálních disků. +Zapomenout bychom neměli ani na to, že používáte-li sdílené připojení určitého druhu, nemusí být tato možnost vždy nutně nejrychlejší. Lokální repozitář je rychlý pouze v případě, že máte rychlý přístup k datům. Repozitář na NFS je často pomalejší než stejný repozitář nad SSH na tomtéž serveru, který ve všech systémech umožňuje spustit Git z lokálních disků. ### Protokol SSH ### -Patrně nejčastějším přenosovým protokolem pro systém Git je SSH. Je to z toho důvodu, že SSH přístup k serverům je na většině míst už nastaven, a pokud ne, není ho těžké nastavit. SSH je navíc jediným síťovým protokolem, z nějž lze snadno číst a do nějž lze snadno zapisovat. Oba zbývající síťové protokoly (HTTP i Git) jsou většinou určeny pouze ke čtení, a proto i když je máte k dispozici, budete potřebovat SSH protokol pro příkazy k zápisu. SSH je také síťovým protokolem s ověřováním, a protože je hojně rozšířen, je jeho nastavení a používání většinou snadné. +Patrně nejčastějším přenosovým protokolem pro systém Git je SSH. Je to z toho důvodu, že SSH přístup k serverům je na většině míst už nastaven, a pokud ne, není ho těžké nastavit. SSH je navíc jediným síťovým protokolem, z nějž lze snadno číst a do nějž lze snadno zapisovat. Oba zbývající síťové protokoly (HTTP i Git) jsou většinou určeny pouze ke čtení, a proto i když je dáváte k dispozici ostatním, pro sebe budete potřebovat SSH protokol pro příkazy zápisu. SSH je také síťovým protokolem s autentizací, a protože je hojně rozšířen, je jeho nastavení a používání většinou snadné. -Chcete-li naklonovat repozitář Git pomocí protokolu SSH, zadejte „ssh:// URL“, například: +Chcete-li naklonovat repozitář Git pomocí protokolu SSH, zadejte `ssh://` URL, například: $ git clone ssh://user@server/project.git -Protokol ostatně ani nemusíte zadávat – pokud žádný výslovně neurčíte, Git použije SSH jako výchozí možnost: +Nebo můžete pro SSH protokol použít kratší zápis jako u scp: $ git clone user@server:project.git @@ -62,24 +62,24 @@ Stejně tak nemusíte zadávat ani uživatele, Git automaticky použije uživate #### Výhody #### -Používání protokolu SSH přináší mnoho výhod. Především byste ho měli používat vždy, když chcete v síti ověřovat oprávnění k zápisu do repozitáře. Zadruhé: protokol SSH má snadné nastavení – SSH démoni jsou zcela běžní, správci sítě si s nimi většinou vědí rady a mnoho distribucí OS je má ve výchozí instalaci nebo má nástroje, aby s nimi mohly pracovat. Z dalších výhod bychom měli zmínit také to, že přístup přes protokol SSH je bezpečný, veškerý přenos dat je šifrovaný a ověřený. A stejně jako protokoly Git a Local je i protokol SSH výkonný. Data jsou před přenosem upravena do co nejkompaktnější podoby. +Používání protokolu SSH přináší mnoho výhod. Především byste ho měli používat vždy, když chcete v síti používat autentizovaný zápis do repozitáře. Zadruhé: protokol SSH se snadno nastavuje – SSH démoni jsou zcela běžní, správci sítě si s nimi většinou vědí rady a mnoho distribucí OS je má ve výchozí instalaci nebo poskytuje nástroje pro jejich správu. Z dalších výhod bychom měli zmínit také to, že přístup přes protokol SSH je bezpečný, veškerý přenos dat je šifrovaný a autentizovaný. A stejně jako protokoly Git a Local je i protokol SSH výkonný, protože data jsou před přenosem upravena do co nejkompaktnější podoby. #### Nevýhody #### -Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitáře. Chce-li někdo získat přístup do vašeho repozitáře, byť třeba jen ke čtení, musí mít přístup k vašemu počítači přes SSH. Proto se protokol SSH nehodí pro projekty s otevřeným zdrojovým kódem. Pokud repozitář používáte jen v rámci firemní sítě, bude pro vás protokol SSH zřejmě naprosto ideální. Pokud chcete povolit anonymní přístup pro čtení k vašim projektům, budete muset nastavit protokol SSH k odesílání svých dat, ale přidat jiný protokol, pomocí nějž budou ostatní tato data stahovat. +Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitáře. Chce-li někdo získat přístup do vašeho repozitáře, byť třeba jen ke čtení, musí mít přístup k vašemu počítači přes SSH. Proto se protokol SSH nehodí pro projekty s otevřeným zdrojovým kódem. Pokud repozitář používáte jen v rámci firemní sítě, bude pro vás protokol SSH zřejmě naprosto ideální. Pokud chcete povolit anonymní přístup pro čtení k vašim projektům, budete muset nastavit protokol SSH k odesílání svých dat, ale musíte přidat i jiný protokol, který budou ostatní používat pro stahování. ### Protokol Git ### -Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakéhokoli ověřování. Chcete-li, aby byl repozitář obsluhován protokolem Git, musíte vytvořit soubor `git-daemon-export-ok` – démon nebude repozitář obsluhovat, dokud v něm tento soubor nebude. Žádné jiné zabezpečení k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze aktivovat, ale vzhledem k tomu, že protokol neumožňuje ověřování, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Tato možnost se však téměř nepoužívá. +Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakékoliv autentizace. Chcete-li, aby byl repozitář zpřístupněn protokolem Git, musíte vytvořit soubor `git-daemon-export-ok`. Bez tohoto souboru nebude repozitář démonem zpřístupněn. Žádné jiné zabezpečení ale k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze zapnout, ale vzhledem k tomu, že protokol neumožňuje autentizaci, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Je jasné, že to většinou nechcete. #### Výhody #### -Protokol Git je ze všech dostupných protokolů nejrychlejší. Potřebujete-li, aby protokol obsluhoval frekventovaný provoz u veřejného projektu nebo velmi velký projekt, u nějž není třeba ověřování identity uživatele ohledně oprávnění pro čtení, bude k obsluze nejvhodnější pravděpodobně právě démon Git. Používá stejný mechanismus přenosu dat jako protokol SSH, na rozdíl od něj ale není zpomalován šifrováním a ověřováním. +Protokol Git je ze všech dostupných protokolů nejrychlejší. Potřebujete-li, aby protokol obsluhoval frekventovaný provoz u veřejného projektu nebo velmi velký projekt, u nějž není třeba ověřování identity uživatele ohledně oprávnění pro čtení, bude k obsluze nejvhodnější pravděpodobně právě démon Git. Používá stejný mechanismus přenosu dat jako protokol SSH, na rozdíl od něj ale není zpomalován šifrováním a ověřováním identity (autentizací). #### Nevýhody #### -Nevýhodou protokolu Git je, že neprovádí ověřování. Většinou není žádoucí, aby protokol Git tvořil jediný přístup k vašemu projektu. Protokol Git většinou využijete v kombinaci s přístupem přes SSH. Protokol SSH bude nastaven pro několik málo vývojářů s oprávněním k zápisu (odesílání dat) a všichni ostatní budou používat `git://` pro přístup pouze ke čtení. -Pravděpodobně se také jedná o protokol s nejobtížnějším nastavením. Vyžaduje spuštění vlastního démona – na jeho nastavení se podíváme v části „Gitosis“ této kapitoly – a dále konfiguraci `xinetd` nebo podobnou, která také není právě jednoduchá. Vyžaduje rovněž povolení přístupu k portu 9418 skrz firewall. Tento port nepatří mezi standardní porty, které by firemní firewally vždy povolovaly. Velkými podnikovými firewally je tento málo rozšířený port většinou blokován. +Nevýhodou protokolu Git je, že neprovádí autentizaci. Většinou není žádoucí, aby protokol Git tvořil jediný přístup k vašemu projektu. Protokol Git většinou využijete v kombinaci s přístupem přes SSH. Protokol SSH bude nastaven pro několik málo vývojářů s oprávněním k zápisu (odesílání dat) a všichni ostatní budou používat `git://` pro přístup pouze ke čtení. +Pravděpodobně se také jedná o protokol s nejobtížnějším nastavením. Vyžaduje spuštění vlastního démona – na jeho nastavení se podíváme v části „Gitosis“ této kapitoly – a dále konfiguraci `xinetd` nebo podobnou, což není zrovna procházka růžovou zahradou. Vyžaduje rovněž povolení přístupu k portu 9418 skrz firewall. Tento port nepatří mezi standardní porty, které by firemní firewally vždy povolovaly. Velkými podnikovými firewally je tento málo rozšířený port většinou blokován. ### Protokol HTTP/S ### From 60fab8d0b43eade28fa49348a5c0485d3826090f Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sat, 23 Aug 2014 21:36:43 +0200 Subject: [PATCH 195/291] [cs] revision of a part of the chapter 4 --- cs/04-git-server/01-chapter4.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index dbe0741b6..2c80ca9f0 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -91,11 +91,11 @@ Na konec jsme si nechali protokol HTTP. Co je na protokolu HTTP nebo HTTPS sympa $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update -A to je vše. Zásuvný modul `post-update`, který je standardně součástí systému Git, spustí příkaz `git update-server-info`, který zajistí správné vyzvedávání a klonování dat přes protokol HTTP. Tento příkaz se spustí, když do tohoto repozitáře odesíláte data přes protokol SSH. Ostatní mohou klonovat třeba takto: +A to je vše. Zásuvný modul `post-update`, který je standardně součástí systému Git, spustí příslušný příkaz (`git update-server-info`), který zajistí správné vyzvedávání a klonování dat přes protokol HTTP. Tento příkaz se spustí, když do tohoto repozitáře odesíláte data přes protokol SSH. Poté mohou ostatní klonovat třeba takto: $ git clone http://example.com/gitproject.git -V tomto konkrétním případě používáme cestu `/var/www/htdocs`, která je obvyklá u nastavení Apache, ale použít lze v podstatě jakýkoli webový server – stačí uložit holý repozitář do daného umístění. Data repozitáře Git jsou obsluhována jako obyčejné statické soubory (podrobnosti naleznete v kapitole 9). +V tomto konkrétním případě používáme cestu `/var/www/htdocs`, která je obvyklá u nastavení Apache, ale použít lze v podstatě jakýkoli statický webový server – stačí uložit holý repozitář do dané cesty. Data repozitáře Git jsou obsluhována jako obyčejné statické soubory (podrobnosti o přesném způsobu obsluhy naleznete v kapitole 9). Odesílat data do repozitáře Git je možné také přes protokol HTTP, avšak tento způsob není příliš rozšířený a vyžaduje nastavení komplexních požadavků protokolu WebDAV. Protože se tato možnost využívá zřídka, nebudeme se jí v této knize věnovat. Pokud vás zajímá používání protokolů HTTP k odesílání dat, více se o přípravě repozitáře k tomuto účelu dočtete na adrese: `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` (anglicky). Příjemným faktem na odesílání dat přes protokol HTTP je, že můžete použít jakýkoli server WebDAV i bez speciálních funkcí systému Git. Tuto možnost tak můžete využít, pokud váš poskytovatel webhostingu podporuje WebDAV pro zápis aktualizací na vaše webové stránky. @@ -103,7 +103,7 @@ Odesílat data do repozitáře Git je možné také přes protokol HTTP, avšak Pro používání protokolu HTTP mluví zejména jeho snadné nastavení. Vystačíte s několika málo příkazy, ale získáte jednoduchý způsob, jak nastavit oprávnění pro čtení repozitáře Git pro okolní svět. Celý postup nezabere víc než pár minut. Protokol HTTP navíc jen minimálně omezuje zdroje serveru. Vzhledem k tomu, že k obsluze všech dat používá většinou statický HTTP server, obslouží běžný server Apache průměrně několik tisíc souborů za sekundu. Ani malý server proto není snadné přetížit. -Své repozitáře můžete prostřednictvím protokolu HTTPS poskytovat pouze ke čtení a šifrovat přenos dat. Nebo můžete zajít ještě dál a vyžadovat, aby klienti používali konkrétní podepsané SSL certifikáty. Je pravda, že v takovém případě by už bylo jednodušší použít veřejné SSH klíče, ale ve vašem konkrétním případě může být použití podepsaných SSL certifikátů nebo jiné ověření identity na základě protokolu HTTP lepší metodou, jak zajistit přístup přes HTTPS pouze ke čtení. +Své repozitáře můžete zpřístupnit ke čtení prostřednictvím protokolu HTTPS, což znamená, že se přenášený obsah šifruje. Nebo můžete zajít ještě dál a vyžadovat, aby klienti používali konkrétní podepsané SSL certifikáty. Je pravda, že v takovém případě by už bylo jednodušší použít veřejné SSH klíče, ale ve vašem konkrétním případě může být použití podepsaných SSL certifikátů nebo jiné ověření identity na základě protokolu HTTP lepší metodou, jak zajistit přístup přes HTTPS pouze ke čtení. Z dalších výhod protokolu HTTP bychom mohli jmenovat i jeho značné rozšíření, díky čemuž jsou firemní firewally často nastaveny tak, že umožňují provoz přes standardní port protokolu HTTP. @@ -114,7 +114,7 @@ Nevýhodou obsluhy repozitáře přes protokol HTTP je poměrně nízká výkonn ## Jak umístit Git na server ## Pro úvodní nastavení serveru Git je třeba exportovat existující repozitář do nového, holého repozitáře (bare repository), tj. do repozitáře, který neobsahuje pracovní adresář. S tím obvykle nebývá problém. -Chcete-li naklonovat stávající repozitář, a vytvořit tak nový a holý, zadejte příkaz clone s parametrem `--bare`. Je zvykem, že adresáře s holým repozitářem končí na `.git`, například: +Chcete-li naklonovat stávající repozitář, a vytvořit tak nový a holý, zadejte příkaz pro klonování s parametrem `--bare`. Je zvykem, že adresáře s holým repozitářem končí na `.git`, například: $ git clone --bare my_project my_project.git Cloning into bare repository 'my_project.git'... From 22d9440fbde8c3c2717160c4675fca5ab1bb8480 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Sun, 24 Aug 2014 12:23:45 +0200 Subject: [PATCH 196/291] [cs] ch. 4 partly revised --- cs/04-git-server/01-chapter4.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 2c80ca9f0..325d6d84c 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -204,7 +204,7 @@ Budete-li potřebovat podrobnější návod k vytvoření SSH klíče v různýc ## Nastavení serveru ## -Podívejme se nyní na nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele. +Podívejme se nyní na nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření identity uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele. $ sudo adduser git $ su git @@ -221,7 +221,7 @@ V dalším kroku musíte vložit veřejné SSH klíče od svých vývojářů do O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair -Vy nyní klíče vložíte do souboru `authorized_keys`: +Vy nyní klíče přidáte do souboru `authorized_keys`: $ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys @@ -278,7 +278,7 @@ Uživatel 'git' nyní může používat SSH připojení k odesílání a stahov ## Veřejný přístup ## -A co když chcete u svého projektu nastavit anonymní oprávnění pro čtení? Nehostujete třeba interní soukromý projekt, ale „open source“ projekt. Nebo možná máte několik serverů průběžné integrace, které se neustále mění a vy nechcete stále generovat SSH klíče, rádi byste vždy přidali jen obyčejné anonymní oprávnění pro čtení. +A co když chcete u svého projektu nastavit anonymní oprávnění pro čtení? Nehostujete třeba interní soukromý projekt, ale „open source“ projekt. Nebo možná máte několik serverů průběžné integrace, které se neustále mění a vy nechcete stále generovat SSH klíče. Rádi byste vždy přidali jen obyčejné anonymní oprávnění pro čtení. Patrně nejjednodušším způsobem pro menší týmy je spustit statický webový server s kořenovým adresářem dokumentů, v němž budou uloženy vaše Git repozitáře, a zapnout zásuvný modul `post-update`, o kterém jsme se zmínili už v první části této kapitoly. Můžeme pokračovat v našem předchozím příkladu. Řekněme, že máte repozitáře uloženy v adresáři `/opt/git` a na vašem počítači je spuštěn server Apache. Opět, můžete použít jakýkoli webový server. Pro názornost ale ukážeme některá základní nastavení serveru Apache, abyste získali představu, co vás může čekat. From cd59265c596d7e45e1bca1a3d7a0fe35c17d41b7 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Mon, 25 Aug 2014 15:05:34 +0200 Subject: [PATCH 197/291] [cs] 09-git-internals/02-translation-notes.markdown removed --- cs/09-git-internals/02-translation-notes.markdown | 1 - 1 file changed, 1 deletion(-) delete mode 100644 cs/09-git-internals/02-translation-notes.markdown diff --git a/cs/09-git-internals/02-translation-notes.markdown b/cs/09-git-internals/02-translation-notes.markdown deleted file mode 100644 index e769bc6e0..000000000 --- a/cs/09-git-internals/02-translation-notes.markdown +++ /dev/null @@ -1 +0,0 @@ -# .......... \ No newline at end of file From d340c350114b9d77e2f4e39b5e6a27f90bb55dbf Mon Sep 17 00:00:00 2001 From: sampablokuper Date: Tue, 26 Aug 2014 22:45:33 +0100 Subject: [PATCH 198/291] Install git instead of git-core with MacPorts `sudo port install git +svn +doc +bash_completion +gitweb` succeeds, whereas `sudo port install git-core +svn +doc +bash_completion +gitweb` fails with output that includes the following helpful messages: Error: git-core has been made obsolete by the port git. Please install git instead. Error: org.macports.configure for port git-core returned: obsolete port Please see the log file for port git-core for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_git-core/git-core/main.log Error: Processing of port git-core failed --- en/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index d859765ac..9079a47b5 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -170,7 +170,7 @@ Figure 1-7. Git OS X installer. The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via - $ sudo port install git-core +svn +doc +bash_completion +gitweb + $ sudo port install git +svn +doc +bash_completion +gitweb You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). From ee4586a072772a16faeba18bbea431ffc3da402a Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Wed, 27 Aug 2014 09:53:55 +0200 Subject: [PATCH 199/291] [fr] newer code snippets --- fr/02-git-basics/01-chapter2.markdown | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index 07245f842..dc7277735 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -80,7 +80,7 @@ L'outil principal pour déterminer quels fichiers sont dans quel état est la co Si vous lancez cette commande juste après un clonage, vous devriez voir ce qui suit : $ git status - # On branch master + On branch master nothing to commit, working directory clean Ce message signifie que votre copie de travail est propre, en d'autres mots, aucun fichier suivi n'a été modifié. @@ -94,11 +94,12 @@ Si ce fichier n'existait pas auparavant, et que vous lancez la commande `git sta $ vim LISEZMOI $ git status - # On branch master - # Untracked files: - # (use "git add ..." to include in what will be committed) - # - # LISEZMOI + On branch master + Untracked files: + (use "git add ..." to include in what will be committed) + + LISEZMOI + nothing added to commit but untracked files present (use "git add" to track) Vous pouvez constater que votre nouveau fichier `LISEZMOI` n'est pas en suivi de version, car il apparaît dans la section « Untracked files » de l'état de la copie de travail. From d880ffab2851adb6dc719f95224b44f15b4415d3 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Wed, 27 Aug 2014 10:15:39 +0200 Subject: [PATCH 200/291] [fr] newer snippets in ch.1 and some in ch.2 --- fr/01-introduction/01-chapter1.markdown | 4 +- fr/02-git-basics/01-chapter2.markdown | 111 ++++++++++++------------ 2 files changed, 59 insertions(+), 56 deletions(-) diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown index 8a0868fcc..9985aa6f0 100644 --- a/fr/01-introduction/01-chapter1.markdown +++ b/fr/01-introduction/01-chapter1.markdown @@ -239,7 +239,7 @@ Après ceci, vous pouvez obtenir Git par Git lui-même pour les mises à jour : Si vous souhaitez installer Git sur Linux via un installateur d'application, vous pouvez généralement le faire via le système de gestion de paquets de base fourni avec votre distribution. Si vous êtes sur Fedora, vous pouvez utiliser yum : - $ yum install git-core + $ yum install git Si vous êtes sur un système basé sur Debian, tel qu'Ubuntu, essayez apt-get : @@ -268,7 +268,7 @@ Installer Git sur Windows est très facile. Le projet msysGit fournit une des procédures d'installation les plus simples. Téléchargez simplement le fichier exe d'installateur depuis la page GitHub, et lancez-le : - http://msysgit.github.com/ + http://msysgit.github.io Après son installation, vous avez à la fois la version en ligne de commande (avec un client SSH utile pour la suite) et l'interface graphique standard. diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown index dc7277735..c7742c88d 100644 --- a/fr/02-git-basics/01-chapter2.markdown +++ b/fr/02-git-basics/01-chapter2.markdown @@ -117,12 +117,12 @@ Pour commencer à suivre le fichier `LISEZMOI`, vous pouvez entrer ceci : Si vous lancez à nouveau la commande `git status`, vous pouvez constater que votre fichier `LISEZMOI` est maintenant suivi et indexé : $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: LISEZMOI - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: LISEZMOI + Vous pouvez affirmer qu'il est indexé car il apparaît dans la section « Changes to be committed » (Modifications à valider). Si vous enregistrez à ce moment, la version du fichier à l'instant où vous lancez `git add` est celle qui appartiendra à l'instantané. @@ -135,17 +135,18 @@ Maintenant, modifions un fichier qui est déjà sous suivi de version. Si vous modifiez le fichier sous suivi de version appelé `benchmarks.rb` et que vous lancez à nouveau votre commande `git status`, vous verrez ceci : $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: LISEZMOI - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: LISEZMOI + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Le fichier `benchmarks.rb` apparaît sous la section nommée « Changes not staged for commit » ce qui signifie que le fichier sous suivi de version a été modifié dans la copie de travail mais n'est pas encore indexé. Pour l'indexer, il faut lancer la commande `git add` (qui est une commande multi-usage — elle peut être utilisée pour placer un fichier sous suivi de version, pour indexer un fichier ou pour d'autres actions telles que marquer comme résolus des conflits de fusion de fichiers). @@ -153,13 +154,13 @@ Lançons maintenant `git add` pour indexer le fichier `benchmarks.rb`, et relan $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: LISEZMOI - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: LISEZMOI + modified: benchmarks.rb + À présent, les deux fichiers sont indexés et feront partie de la prochaine validation. Mais supposons que vous souhaitiez apporter encore une petite modification au fichier `benchmarks.rb` avant de réellement valider la nouvelle version. @@ -168,18 +169,19 @@ Néanmoins, vous lancez `git status` une dernière fois : $ vim benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: LISEZMOI - # modified: benchmarks.rb - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: LISEZMOI + modified: benchmarks.rb + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Que s'est-il donc passé ? À présent, `benchmarks.rb` apparaît à la fois comme indexé et non indexé. En fait, Git indexe un fichier dans son état au moment où la commande `git add` est lancée. @@ -188,13 +190,13 @@ Si le fichier est modifié après un `git add`, il faut relancer `git add` pour $ git add benchmarks.rb $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: LISEZMOI - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: LISEZMOI + modified: benchmarks.rb + ### Ignorer des fichiers ### @@ -249,17 +251,18 @@ Supposons que vous éditez et indexez le fichier `LISEZMOI` et que vous éditez Si vous lancez la commande `git status`, vous verrez ceci : $ git status - # On branch master - # Changes to be committed: - # (use "git reset HEAD ..." to unstage) - # - # new file: LISEZMOI - # - # Changes not staged for commit: - # (use "git add ..." to update what will be committed) - # - # modified: benchmarks.rb - # + On branch master + Changes to be committed: + (use "git reset HEAD ..." to unstage) + + new file: LISEZMOI + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: benchmarks.rb + Pour visualiser ce qui a été modifié mais pas encore indexé, tapez `git diff` sans autre argument : From 281cdffb19186b511af0611ac7fbf614f947b11f Mon Sep 17 00:00:00 2001 From: Hosein Date: Wed, 27 Aug 2014 16:05:22 +0430 Subject: [PATCH 201/291] Signed-off-by: Hosein --- fa/04-git-server/01-chapter4.markdown | 872 ++++++++++++++++++++++++++ 1 file changed, 872 insertions(+) create mode 100644 fa/04-git-server/01-chapter4.markdown diff --git a/fa/04-git-server/01-chapter4.markdown b/fa/04-git-server/01-chapter4.markdown new file mode 100644 index 000000000..538ff671d --- /dev/null +++ b/fa/04-git-server/01-chapter4.markdown @@ -0,0 +1,872 @@ +#Git روی سرور# + در این نقطه، شما باید توانایی انجام کارهای روزانه ای را که قصد دارید با Git انجام دهید، داشته باشید. بااین وجود، برای همکاری با دیگران در Git ، به یک مخزن خارجی Git نیاز دارید. + +At this point, you should be able to do most of the day-to-day tasks for which you’ll be using Git. However, in order to do any collaboration in Git, you’ll need to have a remote Git repository. Although you can technically push changes to and pull changes from individuals’ repositories, doing so is discouraged because you can fairly easily confuse what they’re working on if you’re not careful. Furthermore, you want your collaborators to be able to access the repository even if your computer is offline — having a more reliable common repository is often useful. Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. We’ll refer to this repository as a "Git server"; but you’ll notice that it generally takes a tiny amount of resources to host a Git repository, so you’ll rarely need to use an entire server for it. + +Running a Git server is simple. First, you choose which protocols you want your server to communicate with. The first section of this chapter will cover the available protocols and the pros and cons of each. The next sections will explain some typical setups using those protocols and how to get your server running with them. Last, we’ll go over a few hosted options, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server. + +If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment. + +A remote repository is generally a _bare repository_ — a Git repository that has no working directory. Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it’s just the Git data. In the simplest terms, a bare repository is the contents of your project’s `.git` directory and nothing else. + +## The Protocols ## + +Git can use four major network protocols to transfer data: Local, Secure Shell (SSH), Git, and HTTP. Here we’ll discuss what they are and in what basic circumstances you would want (or not want) to use them. + +It’s important to note that with the exception of the HTTP protocols, all of these require Git to be installed and working on the server. + +### Local Protocol ### + +The most basic is the _Local protocol_, in which the remote repository is in another directory on disk. This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. The latter wouldn’t be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely. + +If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. To clone a repository like this or to add one as a remote to an existing project, use the path to the repository as the URL. For example, to clone a local repository, you can run something like this: + + $ git clone /opt/git/project.git + +Or you can do this: + + $ git clone file:///opt/git/project.git + +Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, and the source and the destination are on the same filesystem, Git tries to hardlink the objects it needs. If they are not on the same filesystem, it will copy the objects it needs using the system's standard copying functionality. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster. + +To add a local repository to an existing Git project, you can run something like this: + + $ git remote add local_proj /opt/git/project.git + +Then, you can push to and pull from that remote as though you were doing so over a network. + +#### The Pros #### + +The pros of file-based repositories are that they’re simple and they use existing file permissions and network access. If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. We’ll discuss how to export a bare repository copy for this purpose in the next section, “Getting Git on a Server.” + +This is also a nice option for quickly grabbing work from someone else’s working repository. If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you pulling down. + +#### The Cons #### + +The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. If you want to push from your laptop when you’re at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access. + +It’s also important to mention that this isn’t necessarily the fastest option if you’re using a shared mount of some kind. A local repository is fast only if you have fast access to the data. A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system. + +### The SSH Protocol ### + +Probably the most common transport protocol for Git is SSH. This is because SSH access to servers is already set up in most places — and if it isn’t, it’s easy to do. SSH is also the only network-based protocol that you can easily read from and write to. The other two network protocols (HTTP and Git) are generally read-only, so even if you have them available for the unwashed masses, you still need SSH for your own write commands. SSH is also an authenticated network protocol; and because it’s ubiquitous, it’s generally easy to set up and use. + +To clone a Git repository over SSH, you can specify ssh:// URL like this: + + $ git clone ssh://user@server/project.git + +Or you can use the shorter scp-like syntax for SSH protocol: + + $ git clone user@server:project.git + +You can also not specify a user, and Git assumes the user you’re currently logged in as. + +#### The Pros #### + +The pros of using SSH are many. First, you basically have to use it if you want authenticated write access to your repository over a network. Second, SSH is relatively easy to set up — SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. Next, access over SSH is secure — all data transfer is encrypted and authenticated. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. + +#### The Cons #### + +The negative aspect of SSH is that you can’t serve anonymous access of your repository over it. People must have access to your machine over SSH to access it, even in a read-only capacity, which doesn’t make SSH access conducive to open source projects. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. If you want to allow anonymous read-only access to your projects, you’ll have to set up SSH for you to push over but something else for others to pull over. + +### The Git Protocol ### + +Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare. + +#### The Pros #### + +The Git protocol is the fastest transfer protocol available. If you’re serving a lot of traffic for a public project or serving a very large project that doesn’t require user authentication for read access, it’s likely that you’ll want to set up a Git daemon to serve your project. It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. + +#### The Cons #### + +The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project. Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use `git://` for read-only access. +It’s also probably the most difficult protocol to set up. It must run its own daemon, which is custom — we’ll look at setting one up in the “Gitosis” section of this chapter — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked. + +### The HTTP/S Protocol ### + +Last we have the HTTP protocol. The beauty of the HTTP or HTTPS protocol is the simplicity of setting it up. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (See Chapter 7 for details on Git hooks). At that point, anyone who can access the web server under which you put the repository can also clone your repository. To allow read access to your repository over HTTP, do something like this: + + $ cd /var/www/htdocs/ + $ git clone --bare /path/to/git_project gitproject.git + $ cd gitproject.git + $ mv hooks/post-update.sample hooks/post-update + $ chmod a+x hooks/post-update + +That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. This command is run when you push to this repository over SSH; then, other people can clone via something like + + $ git clone http://example.com/gitproject.git + +In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. The Git data is served as basic static files (see Chapter 9 for details about exactly how it’s served). + +It’s possible to make Git push over HTTP as well, although that technique isn’t as widely used and requires you to set up complex WebDAV requirements. Because it’s rarely used, we won’t cover it in this book. If you’re interested in using the HTTP-push protocols, you can read about preparing a repository for this purpose at `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt`. One nice thing about making Git push over HTTP is that you can use any WebDAV server, without specific Git features; so, you can use this functionality if your web-hosting provider supports WebDAV for writing updates to your web site. + +#### The Pros #### + +The upside of using the HTTP protocol is that it’s easy to set up. Running the handful of required commands gives you a simple way to give the world read access to your Git repository. It takes only a few minutes to do. The HTTP protocol also isn’t very resource intensive on your server. Because it generally uses a static HTTP server to serve all the data, a normal Apache server can serve thousands of files per second on average — it’s difficult to overload even a small server. + +You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS. + +Another nice thing is that HTTP is such a commonly used protocol that corporate firewalls are often set up to allow traffic through this port. + +#### The Cons #### + +The downside of serving your repository over HTTP is that it’s relatively inefficient for the client. It generally takes a lot longer to clone or fetch from the repository, and you often have a lot more network overhead and transfer volume over HTTP than with any of the other network protocols. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. For more information about the differences in efficiency between the HTTP protocol and the other protocols, see Chapter 9. + +## Getting Git on a Server ## + +In order to initially set up any Git server, you have to export an existing repository into a new bare repository — a repository that doesn’t contain a working directory. This is generally straightforward to do. +In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option. By convention, bare repository directories end in `.git`, like so: + + $ git clone --bare my_project my_project.git + Cloning into bare repository 'my_project.git'... + done. + +You should now have a copy of the Git directory data in your `my_project.git` directory. + +This is roughly equivalent to something like + + $ cp -Rf my_project/.git my_project.git + +There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing. It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone. + +### Putting the Bare Repository on a Server ### + +Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. Let’s say you’ve set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/opt/git` directory. You can set up your new repository by copying your bare repository over: + + $ scp -r my_project.git user@git.example.com:/opt/git + +At this point, other users who have SSH access to the same server which has read-access to the `/opt/git` directory can clone your repository by running + + $ git clone user@git.example.com:/opt/git/my_project.git + +If a user SSHs into a server and has write access to the `/opt/git/my_project.git` directory, they will also automatically have push access. Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option. + + $ ssh user@git.example.com + $ cd /opt/git/my_project.git + $ git init --bare --shared + +You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. Now you’re ready to collaborate on the same project. + +It’s important to note that this is literally all you need to do to run a useful Git server to which several people have access — just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You’re ready to go — nothing else needed. + +In the next few sections, you’ll see how to expand to more sophisticated setups. This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs, using the Gitosis tool, and more. However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository. + +### Small Setups ### + +If you’re a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you. One of the most complicated aspects of setting up a Git server is user management. If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit difficult to arrange. + +#### SSH Access #### + +If you already have a server to which all your developers have SSH access, it’s generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section). If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs. + +If you want to place your repositories on a server that doesn’t have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them. We assume that if you have a server with which to do this, you already have an SSH server installed, and that’s how you’re accessing the server. + +There are a few ways you can give access to everyone on your team. The first is to set up accounts for everybody, which is straightforward but can be cumbersome. You may not want to run `adduser` and set temporary passwords for every user. + +A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. At that point, everyone will be able to access that machine via the 'git' user. This doesn’t affect the commit data in any way — the SSH user you connect as doesn’t affect the commits you’ve recorded. + +Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up. As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work. + +## Generating Your SSH Public Key ## + +That being said, many Git servers authenticate using SSH public keys. In order to provide a public key, each user in your system must generate one if they don’t already have one. This process is similar across all operating systems. +First, you should check to make sure you don’t already have a key. By default, a user’s SSH keys are stored in that user’s `~/.ssh` directory. You can easily check to see if you have a key already by going to that directory and listing the contents: + + $ cd ~/.ssh + $ ls + authorized_keys2 id_dsa known_hosts + config id_dsa.pub + +You’re looking for a pair of files named something and something.pub, where the something is usually `id_dsa` or `id_rsa`. The `.pub` file is your public key, and the other file is your private key. If you don’t have these files (or you don’t even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows: + + $ ssh-keygen + Generating public/private rsa key pair. + Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): + Enter passphrase (empty for no passphrase): + Enter same passphrase again: + Your identification has been saved in /Users/schacon/.ssh/id_rsa. + Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. + The key fingerprint is: + 43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local + +First it confirms where you want to save the key (`.ssh/id_rsa`), and then it asks twice for a passphrase, which you can leave empty if you don’t want to type a password when you use the key. + +Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). All they have to do is copy the contents of the `.pub` file and e-mail it. The public keys look something like this: + + $ cat ~/.ssh/id_rsa.pub + ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU + GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 + Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA + t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En + mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx + NrRFi9wrf+M7Q== schacon@agadorlaptop.local + +For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at `http://github.com/guides/providing-your-ssh-key`. + +## Setting Up the Server ## + +Let’s walk through setting up SSH access on the server side. In this example, you’ll use the `authorized_keys` method for authenticating your users. We also assume you’re running a standard Linux distribution like Ubuntu. First, you create a 'git' user and a `.ssh` directory for that user. + + $ sudo adduser git + $ su git + $ cd + $ mkdir .ssh + +Next, you need to add some developer SSH public keys to the `authorized_keys` file for that user. Let’s assume you’ve received a few keys by e-mail and saved them to temporary files. Again, the public keys look something like this: + + $ cat /tmp/id_rsa.john.pub + ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L + ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k + Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez + Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv + O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq + dAv8JggJICUvax2T9va5 gsg-keypair + +You just append them to your `authorized_keys` file: + + $ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys + $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys + $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys + +Key-based SSH authentication usually enforces security by requiring restricted rights on the involved files. To prevent SSH from refusing to work, type this: + + $ chmod -R go= ~/.ssh + +Now, you can set up an empty repository for your users by running `git init` with the `--bare` option, which initializes the repository without a working directory: + + $ cd /opt/git + $ mkdir project.git + $ cd project.git + $ git --bare init + +Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let’s use `gitserver` as the hostname of the server on which you’ve set up your 'git' user and repository. If you’re running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is: + + # on Johns computer + $ cd myproject + $ git init + $ git add . + $ git commit -m 'initial commit' + $ git remote add origin git@gitserver:/opt/git/project.git + $ git push origin master + +At this point, the others can clone it down and push changes back up just as easily: + + $ git clone git@gitserver:/opt/git/project.git + $ cd project + $ vim README + $ git commit -am 'fix for the README file' + $ git push origin master + +With this method, you can quickly get a read/write Git server up and running for a handful of developers. + +As an extra precaution, you can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. If you set this as your 'git' user’s login shell, then the 'git' user can’t have normal shell access to your server. To use this, specify `git-shell` instead of bash or csh for your user’s login shell. To do so, you’ll likely have to edit your `/etc/passwd` file: + + $ sudo vim /etc/passwd + +At the bottom, you should find a line that looks something like this: + + git:x:1000:1000::/home/git:/bin/sh + +Change `/bin/sh` to `/usr/bin/git-shell` (or run `which git-shell` to see where it’s installed). The line should look something like this: + + git:x:1000:1000::/home/git:/usr/bin/git-shell + +Now, the 'git' user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this: + + $ ssh git@gitserver + fatal: What do you think I am? A shell? + Connection to gitserver closed. + +## Public Access ## + +What if you want anonymous read access to your project? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don’t want to have to generate SSH keys all the time — you just want to add simple anonymous read access. + +Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that `post-update` hook we mentioned in the first section of this chapter. Let’s work from the previous example. Say you have your repositories in the `/opt/git` directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we’ll demonstrate some basic Apache configurations that should give you an idea of what you might need. + +First you need to enable the hook: + + $ cd project.git + $ mv hooks/post-update.sample hooks/post-update + $ chmod a+x hooks/post-update + +What does this `post-update` hook do? It looks basically like this: + + $ cat .git/hooks/post-update + #!/bin/sh + # + # An example hook script to prepare a packed repository for use over + # dumb transports. + # + # To enable this hook, rename this file to "post-update". + # + + exec git-update-server-info + +This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching. + +Next, you need to add a VirtualHost entry to your Apache configuration with the document root as the root directory of your Git projects. Here, we’re assuming that you have wildcard DNS set up to send `*.gitserver` to whatever box you’re using to run all this: + + + ServerName git.gitserver + DocumentRoot /opt/git + + Order allow, deny + allow from all + + + +You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: + + $ chgrp -R www-data /opt/git + +When you restart Apache, you should be able to clone your repositories under that directory by specifying the URL for your project: + + $ git clone http://git.gitserver/project.git + +This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we’ll cover this option in the next section, if you prefer that route. + +## GitWeb ## + +Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1). + +Insert 18333fig0401.png +Figure 4-1. The GitWeb web-based user interface. + +If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option. + + $ git instaweb --httpd=webrick + [2009-02-21 10:02:21] INFO WEBrick 1.3.1 + [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] + +That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It’s pretty easy on your part. When you’re done and want to shut down the server, you can run the same command with the `--stop` option: + + $ git instaweb --httpd=webrick --stop + +If you want to run the web interface on a server all the time for your team or for an open source project you’re hosting, you’ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. We’ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: + + $ git clone git://git.kernel.org/pub/scm/git/git.git + $ cd git/ + $ make GITWEB_PROJECTROOT="/opt/git" \ + prefix=/usr gitweb + $ sudo cp -Rf gitweb /var/www/ + +Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: + + + ServerName gitserver + DocumentRoot /var/www/gitweb + + Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch + AllowOverride All + order allow,deny + Allow from all + AddHandler cgi-script cgi + DirectoryIndex gitweb.cgi + + + +Again, GitWeb can be served with any CGI capable web server; if you prefer to use something else, it shouldn’t be difficult to set up. At this point, you should be able to visit `http://gitserver/` to view your repositories online, and you can use `http://git.gitserver` to clone and fetch your repositories over HTTP. + +## Gitosis ## + +Keeping all users’ public keys in the `authorized_keys` file for access works well only for a while. When you have hundreds of users, it’s much more of a pain to manage that process. You have to shell onto the server each time, and there is no access control — everyone in the file has read and write access to every project. + +At this point, you may want to turn to a widely used software project called Gitosis. Gitosis is basically a set of scripts that help you manage the `authorized_keys` file as well as implement some simple access controls. The really interesting part is that the UI for this tool for adding people and determining access isn’t a web interface but a special Git repository. You set up the information in that project; and when you push it, Gitosis reconfigures the server based on that, which is cool. + +Installing Gitosis isn’t the simplest task ever, but it’s not too difficult. It’s easiest to use a Linux server for it — these examples use a stock Ubuntu 8.10 server. + +Gitosis requires some Python tools, so first you have to install the Python setuptools package, which Ubuntu provides as python-setuptools: + + $ apt-get install python-setuptools + +Next, you clone and install Gitosis from the project’s main site: + + $ git clone https://github.com/tv42/gitosis.git + $ cd gitosis + $ sudo python setup.py install + +That installs a couple of executables that Gitosis will use. Next, Gitosis wants to put its repositories under `/home/git`, which is fine. But you have already set up your repositories in `/opt/git`, so instead of reconfiguring everything, you create a symlink: + + $ ln -s /opt/git /home/git/repositories + +Gitosis is going to manage your keys for you, so you need to remove the current file, re-add the keys later, and let Gitosis control the `authorized_keys` file automatically. For now, move the `authorized_keys` file out of the way: + + $ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak + +Next you need to turn your shell back on for the 'git' user, if you changed it to the `git-shell` command. People still won’t be able to log in, but Gitosis will control that for you. So, let’s change this line in your `/etc/passwd` file + + git:x:1000:1000::/home/git:/usr/bin/git-shell + +back to this: + + git:x:1000:1000::/home/git:/bin/sh + +Now it’s time to initialize Gitosis. You do this by running the `gitosis-init` command with your personal public key. If your public key isn’t on the server, you’ll have to copy it there: + + $ sudo -H -u git gitosis-init < /tmp/id_dsa.pub + Initialized empty Git repository in /opt/git/gitosis-admin.git/ + Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ + +This lets the user with that key modify the main Git repository that controls the Gitosis setup. Next, you have to manually set the execute bit on the `post-update` script for your new control repository. + + $ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update + +You’re ready to roll. If you’re set up correctly, you can try to SSH into your server as the user for which you added the public key to initialize Gitosis. You should see something like this: + + $ ssh git@gitserver + PTY allocation request failed on channel 0 + ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. + Connection to gitserver closed. + +That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository: + + # on your local computer + $ git clone git@gitserver:gitosis-admin.git + +Now you have a directory named `gitosis-admin`, which has two major parts: + + $ cd gitosis-admin + $ find . + ./gitosis.conf + ./keydir + ./keydir/scott.pub + +The `gitosis.conf` file is the control file you use to specify users, repositories, and permissions. The `keydir` directory is where you store the public keys of all the users who have any sort of access to your repositories — one file per user. The name of the file in `keydir` (in the previous example, `scott.pub`) will be different for you — Gitosis takes that name from the description at the end of the public key that was imported with the `gitosis-init` script. + +If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned: + + $ cat gitosis.conf + [gitosis] + + [group gitosis-admin] + members = scott + writable = gitosis-admin + +It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project. + +Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on: + + [group mobile] + members = scott + writable = iphone_project + +Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect: + + $ git commit -am 'add iphone_project and mobile group' + [master 8962da8] add iphone_project and mobile group + 1 file changed, 4 insertions(+) + $ git push origin master + Counting objects: 5, done. + Compressing objects: 100% (3/3), done. + Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:gitosis-admin.git + fb27aec..8962da8 master -> master + +You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push: + + $ git remote add origin git@gitserver:iphone_project.git + $ git push origin master + Initialized empty Git repository in /opt/git/iphone_project.git/ + Counting objects: 3, done. + Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:iphone_project.git + * [new branch] master -> master + +Notice that you don’t need to specify the path (in fact, doing so won’t work), just a colon and then the name of the project — Gitosis finds it for you. + +You want to work on this project with your friends, so you’ll have to re-add their public keys. But instead of appending them manually to the `~/.ssh/authorized_keys` file on your server, you’ll add them, one key per file, into the `keydir` directory. How you name the keys determines how you refer to the users in the `gitosis.conf` file. Let’s re-add the public keys for John, Josie, and Jessica: + + $ cp /tmp/id_rsa.john.pub keydir/john.pub + $ cp /tmp/id_rsa.josie.pub keydir/josie.pub + $ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub + +Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`: + + [group mobile] + members = scott john josie jessica + writable = iphone_project + +After you commit and push that change, all four users will be able to read from and write to that project. + +Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead: + + [group mobile] + members = scott josie jessica + writable = iphone_project + + [group mobile_ro] + members = john + readonly = iphone_project + +Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically: + + [group mobile_committers] + members = scott josie jessica + + [group mobile] + members = @mobile_committers + writable = iphone_project + + [group mobile_2] + members = @mobile_committers john + writable = another_iphone_project + +If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project. + +## Gitolite ## + +This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with. There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg]. + +[gldpg]: http://sitaramc.github.com/gitolite/progit.html +[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html + +Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to). + +Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others. + +### Installing ### + +Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind. You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed. In the examples below, we will use the `git` account on a host called `gitserver`. + +Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation. + +To begin, create a user called `git` on your server and login to this user. Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `.pub` (we'll use `scott.pub` in our examples). Then run these commands: + + $ git clone git://github.com/sitaramc/gitolite + $ gitolite/install -ln + # assumes $HOME/bin exists and is in your $PATH + $ gitolite setup -pk $HOME/scott.pub + +That last command creates new Git repository called `gitolite-admin` on the server. + +Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your Gitolite setup by making changes to this repository and pushing. + +### Customising the Install ### + +While the default, quick, install works for most people, there are some ways to customise the install if you need to. Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite. + +### Config File and Access Control Rules ### + +Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got: + + $ cd ~/gitolite-admin/ + $ ls + conf/ keydir/ + $ find conf keydir -type f + conf/gitolite.conf + keydir/scott.pub + $ cat conf/gitolite.conf + + repo gitolite-admin + RW+ = scott + + repo testing + RW+ = @all + +Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name. + +Adding users is easy. To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation. Add, commit, and push the change, and the user has been added. + +The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here. + +You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro". + + @oss_repos = linux perl rakudo git gitolite + @secret_repos = fenestra pear + + @admins = scott + @interns = ashok + @engineers = sitaram dilbert wally alice + @staff = @admins @engineers @interns + +You can control permissions at the "ref" level. In the following example, interns can only push the "int" branch. Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit. And the admins can do anything (including rewind) to any ref. + + repo @oss_repos + RW int$ = @interns + RW eng- = @engineers + RW refs/tags/rc[0-9] = @engineers + RW+ = @admins + +The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against. So we call it a "refex"! Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes. + +Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`. + +An important feature of the config file’s syntax is that all the rules for a repository need not be in one place. You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so: + + repo gitolite + RW+ = sitaram + +That rule will just get added to the ruleset for the `gitolite` repository. + +At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly. + +There are two levels of access control in Gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. This is the only access control that Gitosis had. + +The second level, applicable only to "write" access, is by branch or tag within a repository. The username, the access being attempted (`W` or `+`), and the refname being updated are known. The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched). If a match is found, the push succeeds. A fallthrough results in access being denied. + +### Advanced Access Control with "deny" rules ### + +So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`. However, Gitolite allows another permission: `-`, standing for "deny". This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*! + +Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ. Here’s how to do that: + + RW master integ = @engineers + - master integ = @engineers + RW+ = @engineers + +Again, you simply follow the rules top down until you hit a match for your access mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied. Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it. + +### Restricting pushes by files changed ### + +In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell Gitolite: + + repo foo + RW = @junior_devs @senior_devs + + - VREF/NAME/Makefile = @junior_devs + +Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details. + +### Personal Branches ### + +Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment. + +A lot of code exchange in the Git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there. + +This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin. + +Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal//*`); please see the documentation for details. + +### "Wildcard" repositories ### + +Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc. Again, please see the documentation for details. + +### Other Features ### + +We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation. + +**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed. + +**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here’s an example: + + hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4 + + R anu-wsd + R entrans + R W git-notes + R W gitolite + R W gitolite-admin + R indic_web_input + R shreelipi_converter + +**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently. This reduces the load on the main admin, and makes him less of a bottleneck. + +**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down. + +## Git Daemon ## + +For public, unauthenticated read access to your projects, you’ll want to move past the HTTP protocol and start using the Git protocol. The main reason is speed. The Git protocol is far more efficient and thus faster than the HTTP protocol, so using it will save your users time. + +Again, this is for unauthenticated read-only access. If you’re running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. If the server you’re running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don’t want to have to add an SSH key for each. + +In any case, the Git protocol is relatively easy to set up. Basically, you need to run this command in a daemonized manner: + + git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ + +`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on. + +You can daemonize this process a number of ways, depending on the operating system you’re running. On an Ubuntu machine, you use an Upstart script. So, in the following file + + /etc/event.d/local-git-daemon + +you put this script: + + start on startup + stop on shutdown + exec /usr/bin/git daemon \ + --user=git --group=git \ + --reuseaddr \ + --base-path=/opt/git/ \ + /opt/git/ + respawn + +For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories — you can easily do this by creating a new user 'git-ro' and running the daemon as them. For the sake of simplicity we’ll simply run it as the same 'git' user that Gitosis is running as. + +When you restart your machine, your Git daemon will start automatically and respawn if it goes down. To get it running without having to reboot, you can run this: + + initctl start local-git-daemon + +On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow. + +Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file: + + [repo iphone_project] + daemon = yes + +When that is committed and pushed up, your running daemon should start serving requests for the project to anyone who has access to port 9418 on your server. + +If you decide not to use Gitosis, but you want to set up a Git daemon, you’ll have to run this on each project you want the Git daemon to serve: + + $ cd /path/to/project.git + $ touch git-daemon-export-ok + +The presence of that file tells Git that it’s OK to serve this project without authentication. + +Gitosis can also control which projects GitWeb shows. First, you need to add something like the following to the `/etc/gitweb.conf` file: + + $projects_list = "/home/git/gitosis/projects.list"; + $projectroot = "/home/git/repositories"; + $export_ok = "git-daemon-export-ok"; + @git_base_url_list = ('git://gitserver'); + +You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this: + + [repo iphone_project] + daemon = yes + gitweb = yes + +Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`. + +## Hosted Git ## + +If you don’t want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code — it’s generally easier for the open source community to find and help you with. + +These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. To see an up-to-date list, check out the following page: + + https://git.wiki.kernel.org/index.php/GitHosting + +Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved. + +GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book. + +### GitHub ### + +GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user-centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project. + +GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done. + +### Setting Up a User Account ### + +The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. + +Insert 18333fig0402.png +Figure 4-2. The GitHub plan page. + +Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3). + +Insert 18333fig0403.png +Figure 4-3. The GitHub user signup form. + +If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems. +Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4). + +Insert 18333fig0404.png +Figure 4-4. The GitHub user dashboard. + +Next you can create a new repository. + +### Creating a New Repository ### + +Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5). + +Insert 18333fig0405.png +Figure 4-5. Creating a new repository on GitHub. + +All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6). + +Insert 18333fig0406.png +Figure 4-6. GitHub project header information. + +Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7). + +Insert 18333fig0407.png +Figure 4-7. Instructions for a new repository. + +These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use + + $ git init + $ git add . + $ git commit -m 'initial commit' + +When you have a Git repository locally, add GitHub as a remote and push up your master branch: + + $ git remote add origin git@github.com:testinguser/iphone_project.git + $ git push origin master + +Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8). + +Insert 18333fig0408.png +Figure 4-8. Project header with a public URL and a private URL. + +The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you. + +The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one. + +### Importing from Subversion ### + +If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9). + +Insert 18333fig0409.png +Figure 4-9. Subversion importing interface. + +If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports. + +### Adding Collaborators ### + +Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work. + +Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10). + +Insert 18333fig0410.png +Figure 4-10. GitHub administration page. + +To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11). + +Insert 18333fig0411.png +Figure 4-11. Adding a collaborator to your project. + +When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12). + +Insert 18333fig0412.png +Figure 4-12. A list of collaborators on your project. + +If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project. + +### Your Project ### + +After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13. + +Insert 18333fig0413.png +Figure 4-13. A GitHub main project page. + +When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information. + +### Forking Projects ### + +If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it. + +This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work. + +To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14). + +Insert 18333fig0414.png +Figure 4-14. Get a writable copy of any repository by clicking the "fork" button. + +After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15). + +Insert 18333fig0415.png +Figure 4-15. Your fork of a project. + +### GitHub Summary ### + +That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly. + +## Summary ## + +You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. + +Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that. + +It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. From e6294b6cfe8dca83b242519705ba7100616e834b Mon Sep 17 00:00:00 2001 From: Karol Jung Date: Wed, 27 Aug 2014 18:39:04 +0200 Subject: [PATCH 202/291] Translation of descriptions under illustrations. --- pl/01-introduction/01-chapter1.markdown | 14 ++-- pl/02-git-basics/02-chapter2.markdown | 2 +- pl/03-git-branching/01-chapter3.markdown | 84 +++++++++++----------- pl/04-git-server/01-chapter4.markdown | 30 ++++---- pl/05-distributed-git/01-chapter5.markdown | 54 +++++++------- pl/06-git-tools/01-chapter6.markdown | 2 +- pl/07-customizing-git/01-chapter7.markdown | 6 +- pl/09-git-internals/01-chapter9.markdown | 8 +-- 8 files changed, 100 insertions(+), 100 deletions(-) diff --git a/pl/01-introduction/01-chapter1.markdown b/pl/01-introduction/01-chapter1.markdown index 5ef367d64..8b6d4a909 100644 --- a/pl/01-introduction/01-chapter1.markdown +++ b/pl/01-introduction/01-chapter1.markdown @@ -15,7 +15,7 @@ Dla wielu ludzi preferowaną metodą kontroli wersji jest kopiowanie plików do Aby poradzić sobie z takimi problemami, programiści już dość dawno temu stworzyli lokalne systemy kontroli wersji, które składały się z prostej bazy danych w której przechowywane były wszystkie zmiany dokonane na śledzonych plikach (por. Rysunek 1-1). Insert 18333fig0101.png -Figure 1-1. Diagram lokalnego systemu kontroli wersji. +Rysunek 1-1. Diagram lokalnego systemu kontroli wersji. Jednym z najbardziej popularnych narzędzi VCS był system rcs, który wciąż jest obecny na wielu dzisiejszych komputerach. Nawet w popularnym systemie operacyjnym Mac OS X rcs jest dostępny po zainstalowaniu Narzędzi Programistycznych (Developer Tools). Program ten działa zapisując, w specjalnym formacie na dysku, dane różnicowe (to jest zawierające jedynie różnice pomiędzy plikami) z każdej dokonanej modyfikacji. Używając tych danych jest w stanie przywołać stan pliku z dowolnego momentu. @@ -24,7 +24,7 @@ Jednym z najbardziej popularnych narzędzi VCS był system rcs, który wciąż j Kolejnym poważnym problemem z którym można się spotkać jest potrzeba współpracy w rozwoju projektu z odrębnych systemów. Aby poradzić sobie z tym problemem stworzono scentralizowane systemy kontroli wersji (CVCS - Centralized Version Control System). Systemy takie jak CVS, Subversion czy Perforce składają się z jednego serwera, który zawiera wszystkie pliki poddane kontroli wersji, oraz klientów którzy mogą się z nim łączyć i uzyskać dostęp do najnowszych wersji plików. Przez wiele lat był to standardowy model kontroli wersji (por. Rysunek 1-2). Insert 18333fig0102.png -Figure 1-2. Diagram scentralizowanego systemu kontroli wersji. +Rysunek 1-2. Diagram scentralizowanego systemu kontroli wersji. Taki schemat posiada wiele zalet, szczególnie w porównaniu z VCS. Dla przykładu każdy może się zorientować co robią inni uczestnicy projektu. Administratorzy mają dokładną kontrolę nad uprawnieniami poszczególnych użytkowników. Co więcej systemy CVCS są także dużo łatwiejsze w zarządzaniu niż lokalne bazy danych u każdego z klientów. @@ -35,7 +35,7 @@ Niemniej systemy te mają także poważne wady. Najbardziej oczywistą jest prob W ten sposób dochodzimy do rozproszonych systemów kontroli wersji (DVCS - Distributed Version Control System). W systemach DVCS (takich jak Git, Mercurial, Bazaar lub Darcs) klienci nie dostają dostępu jedynie do najnowszych wersji plików ale w pełni kopiują całe repozytorium. Gdy jeden z serwerów, używanych przez te systemy do współpracy, ulegnie awarii, repozytorium każdego klienta może zostać po prostu skopiowane na ten serwer w celu przywrócenia go do pracy (por. Rysunek 1-3). Insert 18333fig0103.png -Figure 1-3. Diagram rozproszonego systemu kontroli wersji. +Rysunek 1-3. Diagram rozproszonego systemu kontroli wersji. Co więcej, wiele z tych systemów dość dobrze radzi sobie z kilkoma zdalnymi repozytoriami, więc możliwa jest jednoczesna współpraca z różnymi grupami ludzi nad tym samym projektem. Daje to swobodę wykorzystania różnych schematów pracy, nawet takich które nie są możliwe w scentralizowanych systemach, na przykład modeli hierarchicznych. @@ -62,12 +62,12 @@ Czym jest w skrócie Git? To jest bardzo istotna sekcja tej książki, ponieważ Podstawową różnicą pomiędzy Git a każdym innym systemem VCS (włączając w to Subversion) jest podejście Git do przechowywanych danych. Większość pozostałych systemów przechowuje informacje jako listę zmian na plikach. Systemy te (CVS, Subversion, Perforce, Bazaar i inne) traktują przechowywane informacje jako zbiór plików i zmian dokonanych na każdym z nich w okresie czasu. Obrazuje to Rysunek 1-4. Insert 18333fig0104.png -Figure 1-4. Inne system przechowują dane w postaci zmian do podstawowej wersji każdego z plików. +Rysunek 1-4. Inne system przechowują dane w postaci zmian do podstawowej wersji każdego z plików. Git podchodzi do przechowywania danych w odmienny sposób. Traktuje on dane podobnie jak zestaw migawek (ang. snapshots) małego systemu plików. Za każdym razem jak tworzysz commit lub zapisujesz stan projektu, Git tworzy obraz przedstawiający to jak wyglądają wszystkie pliki w danym momencie i przechowuje referencję do tej migawki. W celu uzyskania dobrej wydajności, jeśli dany plik nie został zmieniony, Git nie zapisuje ponownie tego pliku, a tylko referencję do jego poprzedniej, identycznej wersji, która jest już zapisana. Git myśli o danych w sposób podobny do przedstawionego na Rysunku 1-5. Insert 18333fig0105.png -Figure 1-5. Git przechowuje dane jako migawki projektu w okresie czasu. +Rysunek 1-5. Git przechowuje dane jako migawki projektu w okresie czasu. To jest istotna różnica pomiędzy Git i prawie wszystkimi innymi systemami VCS. Jej konsekwencją jest to, że Git rewiduje prawie wszystkie aspekty kontroli wersji, które pozostałe systemy po prostu kopiowały z poprzednich generacji. Powoduje także, że Git jest bardziej podobny do mini systemu plików ze zbudowanymi na nim potężnymi narzędziami, niż do zwykłego systemu VCS. Odkryjemy niektóre z zalet które zyskuje się poprzez myślenie o danych w ten sposób, gdy w trzecim rozdziale będziemy omawiać tworzenie gałęzi w Git. @@ -102,7 +102,7 @@ Teraz uwaga. To jedna z najważniejszych spraw do zapamiętania jeśli chodzi o Z powyższego wynikają trzy główne sekcje projektu Git: katalog Git, katalog roboczy i przechowalnia (ang. staging area). Insert 18333fig0106.png -Figure 1-6. Katalog roboczy, przechowalnia, katalog git. +Rysunek 1-6. Katalog roboczy, przechowalnia, katalog git. Katalog Git jest miejscem, w którym Git przechowuje własne metadane oraz obiektową bazę danych Twojego projektu. To najważniejsza część Git i to właśnie ten katalog jest kopiowany podczas klonowania repozytorium z innego komputera. @@ -166,7 +166,7 @@ Istnieją dwa proste sposoby instalacji Git na komputerze Mac. Najprostszym z ni http://sourceforge.net/projects/git-osx-installer/ Insert 18333fig0107.png -Figure 1-7. Instalator Git dla OS X. +Rysunek 1-7. Instalator Git dla OS X. Innym prostym sposobem jest instalacja Git z wykorzystaniem MacPorts (`http://www.macports.org`). Jeśli masz zainstalowane MacPorts, zainstaluj Git za pomocą diff --git a/pl/02-git-basics/02-chapter2.markdown b/pl/02-git-basics/02-chapter2.markdown index 3695a4541..ce2501c0b 100644 --- a/pl/02-git-basics/02-chapter2.markdown +++ b/pl/02-git-basics/02-chapter2.markdown @@ -47,7 +47,7 @@ Pamiętaj, że każdy plik w twoim katalogu roboczym może być w jednym z dwóc Kiedy zmieniasz pliki, Git rozpoznaje je jako zmodyfikowane, ponieważ różnią się od ostatniej zatwierdzonej zmiany. Zmodyfikowane pliki umieszczasz w poczekalni, a następnie zatwierdzasz oczekujące tam zmiany i tak powtarza się cały cykl. Przedstawia go Diagram 2-1. Insert 18333fig0201.png -Figure 2-1. Cykl życia stanu twoich plików. +Rysunek 2-1. Cykl życia stanu twoich plików. ### Sprawdzanie stanu twoich plików ### diff --git a/pl/03-git-branching/01-chapter3.markdown b/pl/03-git-branching/01-chapter3.markdown index db73ebf01..3cba76b94 100644 --- a/pl/03-git-branching/01-chapter3.markdown +++ b/pl/03-git-branching/01-chapter3.markdown @@ -20,17 +20,17 @@ Kiedy zatwierdzasz zmiany przez uruchomienie polecenia `git commit`, Git liczy s Teraz repozytorium Gita zawiera już 5 obiektów: jeden blob dla zawartości każdego z trzech plików, jedno drzewo opisujące zawartość katalogu i określające, które pliki przechowywane są w których blobach, oraz jeden zestaw zmian ze wskaźnikiem na owo drzewo i wszystkimi metadanymi. Jeśli chodzi o ideę, dane w repozytorium Gita wyglądają jak na Rysunku 3-1. Insert 18333fig0301.png -Figure 3-1. Dane repozytorium z jedną zatwierdzoną zmianą. +Rysunek 3-1. Dane repozytorium z jedną zatwierdzoną zmianą. Jeśli dokonasz zmian i je również zatwierdzisz, kolejne zatwierdzenie zachowa wskaźnik do zestawu zmian, który został utworzony bezpośrednio przed właśnie dodawanym. Po dwóch kolejnych zatwierdzeniach, Twoja historia może wyglądać podobnie do przedstawionej na Rysunku 3-2: Insert 18333fig0302.png -Figure 3-2. Dane Gita dla wielu zestawów zmian. +Rysunek 3-2. Dane Gita dla wielu zestawów zmian. Gałąź w Gicie jest po prostu lekkim, przesuwalnym wskaźnikiem na któryś z owych zestawów zmian. Domyślna nazwa gałęzi Gita to master. Kiedy zatwierdzasz pierwsze zmiany, otrzymujesz gałąź master, która wskazuje na ostatni zatwierdzony przez Ciebie zestaw. Z każdym zatwierdzeniem automatycznie przesuwa się ona do przodu. Insert 18333fig0303.png -Figure 3-3. Gałąź wskazująca na dane zestawu zmian w historii. +Rysunek 3-3. Gałąź wskazująca na dane zestawu zmian w historii. Co się stanie, jeśli utworzysz nową gałąź? Cóż, utworzony zostanie nowy wskaźnik, który następnie będziesz mógł przesuwać. Powiedzmy, że tworzysz nową gałąź o nazwie testing. Zrobisz to za pomocą polecenia `git branch`: @@ -39,12 +39,12 @@ Co się stanie, jeśli utworzysz nową gałąź? Cóż, utworzony zostanie nowy Polecenie to tworzy nowy wskaźnik na ten sam zestaw zmian, w którym aktualnie się znajdujesz (zobacz Rysunek 3-4). Insert 18333fig0304.png -Figure 3-4. Wiele gałęzi wskazujących na dane zestawów zmian w historii. +Rysunek 3-4. Wiele gałęzi wskazujących na dane zestawów zmian w historii. Skąd Git wie, na której gałęzi się aktualnie znajdujesz? Utrzymuje on specjalny wskaźnik o nazwie HEAD. Istotnym jest, że bardzo różni się on od koncepcji HEADa znanej z innych systemów kontroli wersji, do jakich mogłeś się już przyzwyczaić, na przykład Subversion czy CVS. W Gicie jest to wskaźnik na lokalną gałąź, na której właśnie się znajdujesz. W tym wypadku, wciąż jesteś na gałęzi master. Polecenie `git branch` utworzyło jedynie nową gałąź, ale nie przełączyło cię na nią (porównaj z Rysunkiem 3-5). Insert 18333fig0305.png -Figure 3-5. HEAD wskazuje na gałąź, na której się znajdujesz. +Rysunek 3-5. HEAD wskazuje na gałąź, na której się znajdujesz. Aby przełączyć się na istniejącą gałąź, używasz polecenia `git checkout`. Przełączmy się zatem do nowo utworzonej gałęzi testing: @@ -53,26 +53,26 @@ Aby przełączyć się na istniejącą gałąź, używasz polecenia `git checkou HEAD zostaje zmieniony tak, by wskazywać na gałąź testing (zobacz Rysunek 3-6). Insert 18333fig0306.png -Figure 3-6. Po przełączaniu gałęzi, HEAD wskazuje inną gałąź. +Rysunek 3-6. Po przełączaniu gałęzi, HEAD wskazuje inną gałąź. Jakie ma to znaczenie? Zatwierdźmy nowe zmiany: $ vim test.rb $ git commit -a -m 'zmiana' -Figure 3-7 ilustruje wynik operacji. +Rysunek 3-7 ilustruje wynik operacji. Insert 18333fig0307.png -Figure 3-7. Gałąź wskazywana przez HEAD przesuwa się naprzód po każdym zatwierdzeniu zmian. +Rysunek 3-7. Gałąź wskazywana przez HEAD przesuwa się naprzód po każdym zatwierdzeniu zmian. To interesujące, bo teraz Twoja gałąź testing przesunęła się do przodu, jednak gałąź master ciągle wskazuje ten sam zestaw zmian, co w momencie użycia `git checkout` do zmiany aktywnej gałęzi. Przełączmy się zatem z powrotem na gałąź master: $ git checkout master -Figure 3-8 pokazuje wynik. +Rysunek 3-8 pokazuje wynik. Insert 18333fig0308.png -Figure 3-8. Po wykonaniu `checkout`, HEAD przesuwa się na inną gałąź. +Rysunek 3-8. Po wykonaniu `checkout`, HEAD przesuwa się na inną gałąź. Polecenie dokonało dwóch rzeczy. Przesunęło wskaźnik HEAD z powrotem na gałąź master i przywróciło pliki w katalogu roboczym do stanu z migawki, na którą wskazuje master. Oznacza to również, że zmiany, które od tej pory wprowadzisz, będą rozwidlały się od starszej wersji projektu. W gruncie rzeczy cofa to tymczasowo pracę, jaką wykonałeś na gałęzi testing, byś mógł z dalszymi zmianami pójść w innym kierunku. @@ -84,7 +84,7 @@ Wykonajmy teraz kilka zmian i zatwierdźmy je: Teraz historia Twojego projektu została rozszczepiona (porównaj Rysunek 3-9). Stworzyłeś i przełączyłeś się na gałąź, wykonałeś na niej pracę, a następnie powróciłeś na gałąź główną i wykonałeś inną pracę. Oba zestawy zmian są od siebie odizolowane w odrębnych gałęziach: możesz przełączać się pomiędzy nimi oraz scalić je razem, kiedy będziesz na to gotowy. A wszystko to wykonałeś za pomocą dwóch prostych poleceń `branch` i `checkout`. Insert 18333fig0309.png -Figure 3-9. Rozwidlona historia gałęzi. +Rysunek 3-9. Rozwidlona historia gałęzi. Ponieważ gałęzie w Gicie są tak naprawdę prostymi plikami, zawierającymi 40 znaków sumy kontrolnej SHA-1 zestawu zmian, na który wskazują, są one bardzo tanie w tworzeniu i usuwaniu. Stworzenie nowej gałęzi zajmuje dokładnie tyle czasu, co zapisanie 41 bajtów w pliku (40 znaków + znak nowej linii). @@ -112,7 +112,7 @@ Na tym etapie otrzymasz telefon, że inny problem jest obecnie priorytetem i pot Na początek załóżmy, że pracujesz nad swoim projektem i masz już zatwierdzonych kilka zestawów zmian (patrz Rysunek 3-10). Insert 18333fig0310.png -Figure 3-10. Krótka i prosta historia zmian. +Rysunek 3-10. Krótka i prosta historia zmian. Zdecydowałeś się zająć problemem #53 z systemu śledzenia zgłoszeń, którego używa Twoja firma, czymkolwiek by on nie był. Dla ścisłości, Git nie jest powiązany z żadnym konkretnym systemem tego typu; tym niemniej ponieważ problem #53 to dość konkretny temat, utworzysz nową gałąź by się nim zająć. Aby utworzyć gałąź i jednocześnie się na nią przełączyć, możesz wykonać polecenie `git checkout` z przełącznikiem `-b`: @@ -124,10 +124,10 @@ Jest to krótsza wersja: $ git branch iss53 $ git checkout iss53 -Figure 3-11 pokazuje wynik. +Rysunek 3-11 pokazuje wynik. Insert 18333fig0311.png -Figure 3-11. Tworzenie wskaźnika nowej gałęzi. +Rysunek 3-11. Tworzenie wskaźnika nowej gałęzi. Pracujesz nad swoim serwisem WWW i zatwierdzasz kolejne zmiany. Każdorazowo naprzód przesuwa się także gałąź `iss53`, ponieważ jest aktywna (to znaczy, że wskazuje na nią wskaźnik HEAD; patrz Rysunek 2-12): @@ -135,7 +135,7 @@ Pracujesz nad swoim serwisem WWW i zatwierdzasz kolejne zmiany. Każdorazowo nap $ git commit -a -m 'nowa stopka [#53]' Insert 18333fig0312.png -Figure 3-12. Gałąź iss53 przesunęła się do przodu wraz z postępami w Twojej pracy. +Rysunek 3-12. Gałąź iss53 przesunęła się do przodu wraz z postępami w Twojej pracy. Teraz właśnie otrzymujesz telefon, że na stronie wykryto błąd i musisz go natychmiast poprawić. Z Gitem nie musisz wprowadzać poprawki razem ze zmianami wykonanymi w ramach pracy nad `iss35`. Co więcej, nie będzie cię również kosztować wiele wysiłku przywrócenie katalogu roboczego do stanu sprzed tych zmian, tak, by nanieść poprawki na kod, który używany jest na serwerze produkcyjnym. Wszystko, co musisz teraz zrobić, to przełączyć się z powrotem na gałąź master. @@ -156,7 +156,7 @@ Masz jednak teraz do wykonania ważną poprawkę. Stwórzmy zatem gałąź, na k 1 files changed, 0 insertions(+), 1 deletions(-) Insert 18333fig0313.png -Figure 3-13. Gałąź hotfix bazująca na gałęzi master. +Rysunek 3-13. Gałąź hotfix bazująca na gałęzi master. Możesz uruchomić swoje testy, upewnić się, że poprawka w gałęzi hotfix jest tym, czego potrzebujesz i scalić ją na powrót z gałęzią master, by następnie przenieść zmiany na serwer produkcyjny. Robi się to poleceniem `git merge`: @@ -172,7 +172,7 @@ Rezultat polecenia scalenia zawiera frazę „Fast forward”. Ponieważ zestaw Twoja zmiana jest teraz częścią migawki zestawu zmian wskazywanego przez gałąź `master` i możesz zaktualizować kod na serwerze produkcyjnym (zobacz Rysunek 3-14). Insert 18333fig0314.png -Figure 3-14. Po scaleniu Twoja gałąź master wskazuje to samo miejsce, co gałąź hotfix. +Rysunek 3-14. Po scaleniu Twoja gałąź master wskazuje to samo miejsce, co gałąź hotfix. Po tym, jak Twoje niezwykle istotne poprawki trafią na serwer, jesteś gotowy powrócić do uprzednio przerwanej pracy. Najpierw jednak usuniesz gałąź hotfix, gdyż nie jest już ci potrzebna — gałąź `master` wskazuje to samo miejsce. Możesz ją usunąć używając opcji `-d` polecenia `git branch`: @@ -189,7 +189,7 @@ Teraz możesz przełączyć się z powrotem do gałęzi z rozpoczętą wcześnie 1 files changed, 1 insertions(+), 0 deletions(-) Insert 18333fig0315.png -Figure 3-15. Twoja gałąź iss53 może przesuwać się do przodu niezależnie. +Rysunek 3-15. Twoja gałąź iss53 może przesuwać się do przodu niezależnie. Warto tu zauważyć, że praca, jaką wykonałeś na gałęzi `hotfix` nie jest uwzględniona w plikach w gałęzi `iss53`. Jeśli jej potrzebujesz, możesz scalić zmiany z gałęzi `master` do gałęzi `iss53`, uruchamiając `git merge master`, możesz też zaczekać z integracją zmian na moment, kiedy zdecydujesz się przenieść zmiany z gałęzi `iss53` z powrotem do gałęzi `master`. @@ -206,14 +206,14 @@ Załóżmy, że zdecydowałeś, że praca nad problemem #53 dobiegła końca i j Wygląda to odrobinę inaczej, niż w przypadku wcześniejszego scalenia gałęzi `hotfix`. W tym wypadku Twoja historia rozwoju została rozszczepiona na wcześniejszym etapie. Ponieważ zestaw zmian z gałęzi, na której obecnie jesteś, nie jest bezpośrednim potomkiem gałęzi, którą scalasz, Git musi w końcu popracować. W tym przypadku Git przeprowadza scalenie trójstronne (ang. three-way merge), używając dwóch migawek wskazywanych przez końcówki gałęzi oraz ich wspólnego przodka. Rysunek 3-16 pokazuje trzy migawki, których w tym przypadku Git używa do scalania. Insert 18333fig0316.png -Figure 3-16. Git automatycznie odnajduje najlepszego wspólnego przodka, który będzie punktem wyjściowym do scalenia gałęzi. +Rysunek 3-16. Git automatycznie odnajduje najlepszego wspólnego przodka, który będzie punktem wyjściowym do scalenia gałęzi. Zamiast zwykłego przeniesienia wskaźnika gałęzi do przodu, Git tworzy nową migawkę, która jest wynikiem wspomnianego scalenia trójstronnego i automatycznie tworzy nowy zestaw zmian, wskazujący na ową migawkę (patrz Rysunek 3-17). Określane jest to mianem zmiany scalającej (ang. merge commit), która jest o tyle wyjątkowa, że posiada więcej niż jednego rodzica. Warto zaznaczyć, że Git sam określa najlepszego wspólnego przodka do wykorzystania jako punkt wyjściowy scalenia; różni się to od zachowania CVS czy Subversion (przed wersją 1.5), gdzie osoba scalająca zmiany musi punkt wyjściowy scalania znaleźć samodzielnie. Czyni to scalanie w Gicie znacznie łatwiejszym, niż w przypadku tamtych systemów. Insert 18333fig0317.png -Figure 3-17. Git automatycznie tworzy nowy zestaw zmian zawierający scaloną pracę. +Rysunek 3-17. Git automatycznie tworzy nowy zestaw zmian zawierający scaloną pracę. Teraz, kiedy Twoja praca jest już scalona, nie potrzebujesz dłużej gałęzi `iss53`. Możesz ją usunąć, a następnie ręcznie zamknąć zgłoszenie w swoim systemie śledzenia zadań: @@ -349,12 +349,12 @@ Wielu programistów pracuje z Gitem wykorzystując to podejście, trzymając w g W rzeczywistości mówimy o wskaźnikach przesuwających się w przód po zatwierdzanych przez Ciebie zestawach zmian. Stabilne gałęzie znajdują się wcześniej w historii, a gałęzie robocze na jej końcu (patrz Rysunek 3-18). Insert 18333fig0318.png -Figure 3-18. Stabilniejsze gałęzie z reguły znajdują się wcześniej w historii zmian. +Rysunek 3-18. Stabilniejsze gałęzie z reguły znajdują się wcześniej w historii zmian. Ogólnie łatwiej jest myśleć o nich jak o silosach na zmiany, gdzie grupy zmian są promowane do stabilniejszych silosów, kiedy już zostaną przetestowane (Rysunek 3-19). Insert 18333fig0319.png -Figure 3-19. Może być ci łatwiej myśleć o swoich gałęziach jak o silosach. +Rysunek 3-19. Może być ci łatwiej myśleć o swoich gałęziach jak o silosach. Możesz powielić ten schemat na kilka poziomów stabilności. Niektóre większe projekty posiadają dodatkowo gałąź `proposed` albo `pu` („proposed updates” — proponowane zmiany), scalającą gałęzie, które nie są jeszcze gotowe trafić do gałęzi `next` czy `master`. Zamysł jest taki, że twoje gałęzie reprezentują różne poziomy stabilności; kiedy osiągają wyższy stopień stabilności, są scalane do gałęzi powyżej. Podobnie jak poprzednio, posiadanie takich długodystansowych gałęzi nie jest konieczne, ale często bardzo pomocne, zwłaszcza jeśli pracujesz przy dużych, złożonych projektach. @@ -368,12 +368,12 @@ Widziałeś to w poprzedniej sekcji, kiedy pracowaliśmy z gałęziami `iss53` i Rozważ przykład wykonywania pewnego zadania (na gałęzi głównej), stworzenia gałęzi w celu rozwiązania konkretnego problemu (`iss91`), pracy na niej przez chwilę, stworzenia drugiej gałęzi w celu wypróbowania innego sposobu rozwiązania tego samego problemu (`iss91v2`), powrotu do gałęzi głównej i pracy z nią przez kolejną chwilę, a następnie stworzenia tam kolejnej gałęzi do sprawdzenia pomysłu, co do którego nie jesteś pewny, czy ma on sens (gałąź `dumbidea`). Twoja historia rewizji będzie wygląda mniej więcej tak: Insert 18333fig0320.png -Figure 3-20. Twoja historia rewizji zawierająca kilka gałęzi tematycznych. +Rysunek 3-20. Twoja historia rewizji zawierająca kilka gałęzi tematycznych. Teraz, powiedzmy, że decydujesz się, że najbardziej podoba ci się drugie rozwiązanie Twojego problemu (`iss91v2`); zdecydowałeś się także pokazać gałąź `dumbidea` swoim współpracownikom i okazało się, że pomysł jest genialny. Możesz wyrzucić oryginalne rozwiązanie problemu znajdujące się w gałęzi `iss91` (tracąc rewizje C5 i C6) i scalić dwie pozostałe gałęzie. Twoja historia będzie wyglądać tak, jak na Rysunku 3-21. Insert 18333fig0321.png -Figure 3-21. Historia zmian po scaleniu gałęzi dumbidea i iss91v2. +Rysunek 3-21. Historia zmian po scaleniu gałęzi dumbidea i iss91v2. Ważne jest, żeby robiąc to wszystko pamiętać, że są to zupełnie lokalne gałęzie. Tworząc nowe gałęzie i scalając je później, robisz to wyłącznie w ramach własnego repozytorium - bez jakiejkolwiek komunikacji z serwerem. @@ -386,27 +386,27 @@ Ich nazwy przybierają następującą formę: `(nazwa zdalnego repozytorium)/(na Może być to nieco mylące, więc przyjrzyjmy się dokładniej przykładowi. Powiedzmy, że w swojej sieci masz serwer Git pod adresem `git.ourcompany.com`. Po sklonowaniu z niego repozytorium, Git automatycznie nazwie je jako `origin`, pobierze wszystkie dane, stworzy wskaźnik do miejsca gdzie znajduje się gałąź `master` i nazwie ją lokalnie `origin/master`; nie będziesz mógł jej przesuwać. Git da ci także do pracy Twoją własną gałąź `master` zaczynającą się w tym samym miejscu, co zdalna (zobacz Rysunek 3-22). Insert 18333fig0322.png -Figure 3-22. Po sklonowaniu otrzymasz własną gałąź główną oraz zdalną origin/master wskazującą na gałąź w zdalnym repozytorium. +Rysunek 3-22. Po sklonowaniu otrzymasz własną gałąź główną oraz zdalną origin/master wskazującą na gałąź w zdalnym repozytorium. Jeśli wykonasz jakąś pracę na gałęzi głównej, a w międzyczasie ktoś inny wypchnie zmiany na `git.ourcompany.com` i zaktualizuje jego gałąź główną, wówczas wasze historie przesuną się do przodu w różny sposób. Co więcej, dopóki nie skontaktujesz się z serwerem zdalnym, Twój wskaźnik `origin/master` nie przesunie się (Rysunek 3-23). Insert 18333fig0323.png -Figure 3-23. Kiedy pracujesz lokalnie, wypchnięcie przez kogoś zmian na serwer powoduje, że obie historie zaczynają przesuwać się do przodu w odmienny sposób. +Rysunek 3-23. Kiedy pracujesz lokalnie, wypchnięcie przez kogoś zmian na serwer powoduje, że obie historie zaczynają przesuwać się do przodu w odmienny sposób. Aby zsynchronizować zmiany uruchom polecenie `git fetch origin`. Polecenie to zajrzy na serwer, na który wskazuje nazwa origin (w tym wypadku `git.ourcompany.com`), pobierze z niego wszystkie dane, których jeszcze nie masz u siebie, i zaktualizuje Twoją lokalną bazę danych przesuwając jednocześnie wskaźnik `origin/master` do nowej, aktualniejszej pozycji (zobacz Rysunek 3-24). Insert 18333fig0324.png -Figure 3-24. Polecenie git fetch aktualizuje zdalne referencje. +Rysunek 3-24. Polecenie git fetch aktualizuje zdalne referencje. Aby zaprezentować fakt posiadania kilku zdalnych serwerów oraz stan ich zdalnych gałęzi, załóżmy, że posiadasz jeszcze jeden firmowy serwer Git, który jest używany wyłącznie przez jeden z twoich zespołów sprintowych. Jest to serwer dostępny pod adresem `git.team1.ourcompany.com`. Możesz go dodać do projektu, nad którym pracujesz, jako nowy zdalny odnośnik uruchamiając polecenie `git remote add` tak, jak pokazaliśmy to w rozdziale 2. Nazwij go `teamone`, dzięki czemu później będziesz używał tej nazwy zamiast pełnego adresu URL (rysunek 3-25). Insert 18333fig0325.png -Figure 3-25. Dodanie kolejnego zdalnego serwera. +Rysunek 3-25. Dodanie kolejnego zdalnego serwera. Możesz teraz uruchomić polecenie `git fetch teamone` aby pobrać wszystko, co znajduje się na serwerze, a czego jeszcze nie posiadasz lokalnie. Ponieważ serwer ten zawiera podzbiór danych które zawiera serwer `origin`, Git nie pobiera niczego ale tworzy zdalną gałąź `teamone/master` wskazującą na rewizję dostępną w repozytorium `teamone` i jej gałęzi `master` (rysunek 3-26). Insert 18333fig0326.png -Figure 3-26. Dostajesz lokalny odnośnik do gałęzi master w repozytorium teamone. +Rysunek 3-26. Dostajesz lokalny odnośnik do gałęzi master w repozytorium teamone. ### Wypychanie zmian ### @@ -481,12 +481,12 @@ W Git istnieją dwa podstawowe sposoby integrowania zmian z jednej gałęzi do d Jeśli cofniesz się do poprzedniego przykładu z sekcji Scalanie (patrz Rysunek 3-27), zobaczysz, że rozszczepiłeś swoją pracę i wykonywałeś zmiany w dwóch różnych gałęziach. Insert 18333fig0327.png -Figure 3-27. Początkowa historia po rozszczepieniu. +Rysunek 3-27. Początkowa historia po rozszczepieniu. Najprostszym sposobem, aby zintegrować gałęzie - jak już napisaliśmy - jest polecenie `merge`. Przeprowadza ono trójstronne scalanie pomiędzy dwoma ostatnimi migawkami gałęzi (C3 i C4) oraz ich ostatnim wspólnym przodkiem (C2), tworząc nową migawkę (oraz rewizję), tak jak widać to na rysunku 3-28. Insert 18333fig0328.png -Figure 3-28. Scalanie gałęzi integrujące rozszczepioną historię zmian. +Rysunek 3-28. Scalanie gałęzi integrujące rozszczepioną historię zmian. Jednakże istnieje inny sposób: możesz stworzyć łatkę ze zmianami wprowadzonymi w C3 i zaaplikować ją na rewizję C4. W Gicie nazywa się to zmianą bazy (ang. rebase). Dzięki poleceniu `rebase` możesz wziąć wszystkie zmiany, które zostały zatwierdzone w jednej gałęzi i zaaplikować je w innej. @@ -500,12 +500,12 @@ W tym wypadku, mógłbyś uruchomić następujące polecenie: Polecenie to działa przesuwając się do ostatniego wspólnego przodka obu gałęzi (tej w której się znajdujesz oraz tej *do* której robisz zmianę bazy), pobierając różnice opisujące kolejne zmiany (ang. diffs) wprowadzane przez kolejne rewizje w gałęzi w której się znajdujesz, zapisując je w tymczasowych plikach, następnie resetuje bieżącą gałąź do tej samej rewizji *do* której wykonujesz operację zmiany bazy, po czym aplikuje po kolei zapisane zmiany. Ilustruje to rysunek 3-29. Insert 18333fig0329.png -Figure 3-29. Zmiana bazy dla zmian wprowadzonych w C3 do C4. +Rysunek 3-29. Zmiana bazy dla zmian wprowadzonych w C3 do C4. W tym momencie możesz wrócić do gałęzi `master` i scalić zmiany wykonując proste przesunięcie wskaźnika (co przesunie wskaźnik master na koniec) (rysunek 3-30). Insert 18333fig0330.png -Figure 3-30. Przesunięcie gałęzi master po operacji zmiany bazy. +Rysunek 3-30. Przesunięcie gałęzi master po operacji zmiany bazy. Teraz migawka wskazywana przez C3' jest dokładnie taka sama jak ta, na którą wskazuje C5 w przykładzie ze scalaniem. Nie ma różnicy w produkcie końcowym integracji. Zmiana bazy tworzy jednak czystszą historię. Jeśli przejrzysz historię gałęzi po operacji `rebase`, wygląda ona na liniową: wygląda jakby cała praca była wykonywana stopniowo, nawet jeśli oryginalnie odbywała się równolegle. @@ -518,7 +518,7 @@ Zauważ, że migawka wskazywana przez wynikową rewizję bez względu na to, czy Poleceniem `rebase` możesz także zastosować zmiany na innej gałęzi niż ta, której zmieniasz bazę. Dla przykładu - weź historię taką jak na rysunku 3-31. Utworzyłeś gałąź tematyczną (`server`), żeby dodać nowe funkcje do kodu serwerowego, po czym utworzyłeś rewizję. Następnie utworzyłeś gałąź, żeby wykonać zmiany w kliencie (`client`) i kilkukrotnie zatwierdziłeś zmiany. W końcu wróciłeś do gałęzi `server` i wykonałeś kilka kolejnych rewizji. Insert 18333fig0331.png -Figure 3-31. Historia z gałęzią tematyczną utworzoną na podstawie innej gałęzi tematycznej. +Rysunek 3-31. Historia z gałęzią tematyczną utworzoną na podstawie innej gałęzi tematycznej. Załóżmy, że zdecydowałeś się scalić zmiany w kliencie do kodu głównego, ale chcesz się jeszcze wstrzymać ze zmianami po stronie serwera, dopóki nie zostaną one dokładniej przetestowane. Możesz wziąć zmiany w kodzie klienta, których nie ma w kodzie serwera (C8 i C9) i zastosować je na gałęzi głównej używając opcji `--onto` polecenia `git rebase`: @@ -527,7 +527,7 @@ Załóżmy, że zdecydowałeś się scalić zmiany w kliencie do kodu głównego Oznacza to mniej więcej "Przełącz się do gałęzi klienta, określ zmiany wprowadzone od wspólnego przodka gałęzi `client` i `server`, a następnie nanieś te zmiany na gałąź główną `master`. Jest to nieco skomplikowane, ale wynik (pokazany na rysunku 3-32) całkiem niezły. Insert 18333fig0332.png -Figure 3-32. Zmiana bazy gałęzi tematycznej odbitej z innej gałęzi tematycznej. +Rysunek 3-32. Zmiana bazy gałęzi tematycznej odbitej z innej gałęzi tematycznej. Teraz możesz zwyczajnie przesunąć wskaźnik gałęzi głównej do przodu (rysunek 3-33): @@ -535,7 +535,7 @@ Teraz możesz zwyczajnie przesunąć wskaźnik gałęzi głównej do przodu (rys $ git merge client Insert 18333fig0333.png -Figure 3-33. Przesunięcie do przodu gałęzi master w celu uwzględnienia zmian z gałęzi klienta. +Rysunek 3-33. Przesunięcie do przodu gałęzi master w celu uwzględnienia zmian z gałęzi klienta. Powiedzmy, że zdecydujesz się pobrać i scalić zmiany z gałęzi `server`. Możesz zmienić bazę gałęzi `server` na wskazywaną przez `master` bez konieczności przełączania się do gałęzi `server` używając `git rebase [gałąź bazowa] [gałąź tematyczna]` - w ten sposób zmiany z gałęzi `server` zostaną zaaplikowane do gałęzi bazowej `master`: @@ -544,7 +544,7 @@ Powiedzmy, że zdecydujesz się pobrać i scalić zmiany z gałęzi `server`. Mo Polecenie odtwarza zmiany z gałęzi `server` na gałęzi `master` tak, jak pokazuje to rysunek 3-34. Insert 18333fig0334.png -Figure 3-34. Zmiana bazy gałęzi `serwer` na koniec gałęzi głównej. +Rysunek 3-34. Zmiana bazy gałęzi `serwer` na koniec gałęzi głównej. Następnie możesz przesunąć gałąź bazową (`master`): @@ -557,7 +557,7 @@ Możesz teraz usunąć gałęzie `client` i `server`, ponieważ cała praca jest $ git branch -d server Insert 18333fig0335.png -Figure 3-35. Ostateczna historia rewizji. +Rysunek 3-35. Ostateczna historia rewizji. ### Zagrożenia operacji zmiany bazy ### @@ -572,22 +572,22 @@ Stosując operację zmiany bazy porzucasz istniejące rewizje i tworzysz nowe, k Spójrzmy na przykład obrazujący, jak operacja zmiany bazy może spowodować problemy. Załóżmy, że sklonujesz repozytorium z centralnego serwera, a następnie wykonasz bazując na tym nowe zmiany. Twoja historia rewizji wygląda tak jak na rysunku 3-36. Insert 18333fig0336.png -Figure 3-36. Sklonowane repozytorium i dokonane zmiany. +Rysunek 3-36. Sklonowane repozytorium i dokonane zmiany. Teraz ktoś inny wykonuje inną pracę, która obejmuje scalenie, i wypycha ją na centralny serwer. Pobierasz zmiany, scalasz nową, zdalną gałąź z własną pracą, w wyniku czego historia wygląda mniej więcej tak, jak na rysunku 3-37. Insert 18333fig0337.png -Figure 3-37. Pobranie kolejnych rewizji i scalenie ich z własnymi zmianami. +Rysunek 3-37. Pobranie kolejnych rewizji i scalenie ich z własnymi zmianami. Następnie osoba, która wypchnęła scalone zmiany, rozmyśliła się i zdecydowała zamiast scalenia zmienić bazę swoich zmian; wykonuje `git push --force`, żeby zastąpić historię na serwerze. Następnie ty pobierasz dane z serwera ściągając nowe rewizje. Insert 18333fig0338.png -Figure 3-38. Ktoś wypycha rewizje po operacji zmiany bazy porzucając rewizje, na których ty oparłeś swoje zmiany. +Rysunek 3-38. Ktoś wypycha rewizje po operacji zmiany bazy porzucając rewizje, na których ty oparłeś swoje zmiany. W tym momencie musisz raz jeszcze scalać tę pracę mimo tego, że już to wcześniej raz zrobiłeś. Operacja zmiany bazy zmienia sumy kontrolne SHA-1 tych rewizji, więc dla Gita wyglądają one jak zupełnie nowe, choć w rzeczywistości masz już zmiany wprowadzone w C4 w swojej historii (rysunek 3-39). Insert 18333fig0339.png -Figure 3-39. Scalasz tą samą pracę raz jeszcze tworząc nową rewizję scalającą. +Rysunek 3-39. Scalasz tą samą pracę raz jeszcze tworząc nową rewizję scalającą. Musisz scalić swoją pracę w pewnym momencie po to, żeby dotrzymywać kroku innym programistom. Kiedy już to zrobisz, Twoja historia zmian będzie zawierać zarówno rewizje C4 jak i C4', które mają różne sumy SHA-1, ale zawierają te same zmiany i mają ten sam komentarz. Jeśli uruchomisz `git log` dla takiej historii, zobaczysz dwie rewizje mające tego samego autora, datę oraz komentarz, co będzie mylące. Co więcej, jeśli wypchniesz tę historię z powrotem na serwer, raz jeszcze wprowadzisz wszystkie rewizje powstałe w wyniku operacji zmiany bazy na serwer centralny, co może dalej mylić i denerwować ludzi. diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown index 23fb04850..28e41f0fe 100644 --- a/pl/04-git-server/01-chapter4.markdown +++ b/pl/04-git-server/01-chapter4.markdown @@ -318,7 +318,7 @@ W ten sposób możesz ustawić oparty na HTTP dostęp odczytu do swoich projekt Teraz, gdy już podstawy odczytu i zapisu są dostępne tylko dla Twojego projektu, możesz założyć prostą internetową wizualizacje. Do tego celu Git wyposażony jest w skrypt CGI o nazwie GitWeb. Jak widać GitWeb stosowany jest w miejscach takich jak:`http://git.kernel.org` (patrz rys. 4-1). Insert 18333fig0401.png -Figure 4-1.GitWeb internetowy interfejs użytkownika. +Rysunek 4-1.GitWeb internetowy interfejs użytkownika. Jeśli chcesz zobaczyć jak GitWeb będzie wyglądał dla Twojego projektu, Git posiada polecenie do uruchamiania tymczasowej instancji, pod warunkiem, że posiadasz lekki serwer taki jak `lighttpd` lub `webrick`. Na komputerach z zainstalowanym linuxem `lighttpd` jest bardzo często instalowany więc należy go uruchomić wpisując `git instaweb` w katalogu projektu. Jeśli używasz komputera Mac, Leopard jest automatycznie instalowany z Ruby więc `webrick` może być najlepszym rozwiązaniem. Aby rozpocząć `instaweb` bez tymczasowej instancji, należy uruchomić go z opcją `--httpd`. @@ -777,18 +777,18 @@ GitHub jest również spółką handlową, która pobiera opłaty za utrzymanie Pierwszą rzeczą jaką musisz zrobić jest założenie darmowego konta użytkownika. W tym celu wchodzisz na stronę rejestracji `https://github.com/pricing` i klikasz przycisk "Zarejestruj się" na darmowe konto (patrz rysunek 4-2) i jesteś już przeniesiony na stronę rejestracji. Insert 18333fig0402.png -Figure 4-2. Strona rejestracji GitHub. +Rysunek 4-2. Strona rejestracji GitHub. Tutaj musisz wybrać nazwę użytkownika, taką która nie istnieje jeszcze w systemie, podać adres e-mail, który będzie powiązany z kontem i podać hasło Rysunek 4-3). Insert 18333fig0403.png -Figure 4-3. Rejestracja użytkownika GitHub. +Rysunek 4-3. Rejestracja użytkownika GitHub. Jeśli jest to możliwe to jest to dobry moment aby dodać swój publiczny klucz SSH. W rozdziale "Simple Setups" wyjaśniliśmy już jak wygenerować nowy klucz. Skopiuj zawartość klucza i wklej go w polu "SSH Public Key". Kliknięcie "explain ssh keys" przeniesie Cię do szczegółowych informacji jak zrobić to na poszczególnych systemach operacyjnych. Kliknięcie "I agree, sign me up" powoduje przeniesienie do nowego panelu użytkownika (patrz rysunek 4-4). Insert 18333fig0404.png -Figure 4-4. Panel użytkownika GitHub. +Rysunek 4-4. Panel użytkownika GitHub. Następnie możesz utworzyć nowe repozytorium. @@ -797,17 +797,17 @@ Następnie możesz utworzyć nowe repozytorium. Zacznij klikając na link "create a new one" obok Twoich repozytoriów na panelu użytkownika. Jesteś na stronie do tworzenia nowego repozytorium (patrz rysunek 4-5). Insert 18333fig0405.png -Figure 4-5. Tworzenie nowego repozytorium na GitHubie. +Rysunek 4-5. Tworzenie nowego repozytorium na GitHubie. Wszystko co tak naprawdę musisz zrobić to podać nazwę projektu. Możesz też podać dodatkowy opis. Kiedy to zrobisz klikasz przycisk "Create Repository". Masz już nowe repozytorium na GitHubie (patrz rysunek 4-6). Insert 18333fig0406.png -Figure 4-6. Główne informacje o projekcie. +Rysunek 4-6. Główne informacje o projekcie. Ponieważ nie masz tam jeszcze kodu, GitHub pokaże instrukcje jak stworzyć zupełnie nowy projekt. Wciśnij istniejący już projekt, lub zaimportuj projekt z publicznego repozytorium Subversion (patrz rysunek 4-7). Insert 18333fig0407.png -Figure 4-7. Instrukcja tworzenia nowego repozytorium. +Rysunek 4-7. Instrukcja tworzenia nowego repozytorium. Instrukcje te są podobne do tego co już przeszedłeś. Aby zainicjować projekt, jeśli nie jest jeszcze projektem gita, możesz użyć: @@ -823,7 +823,7 @@ Kiedy masz już lokalne repozytorium Gita, dodaj GitHub jako zdalne repozytorium Teraz Twój projekt jest już utrzymywany na GitHubie. Możesz każdemu udostępnić swój projekt wysyłając adres URL. W naszym przypadku jest to `http://github.com/testinguser/iphone_project`. Możesz także zobaczyć na nagłówku każdego z projektów, że masz dwa adresy URL (patrz rysunek 4-8). Insert 18333fig0408.png -Figure 4-8. Nagłówek projektu z prywatnym i publicznym adresem URL. +Rysunek 4-8. Nagłówek projektu z prywatnym i publicznym adresem URL. Publiczny adres URL służy tylko do pobierania repozytorium projektu. Zachęcamy do umieszczania go na stronach WWW. @@ -834,7 +834,7 @@ Prywatny adres URL służy do pobierania i wysyłania repozytorium na serwer. Ko Jeśli masz już projekt publiczny Subversion, który chcesz zaimportować do Gita, GitHub często może zrobić to dla Ciebie. Na dole strony instrukcji jest link służący do importu Subversion. Po kliknięciu na niego pojawi się formularz z informacjami o imporcie projektu i pole gdzie można wkleić adres swojego publicznego projektu Subversion (patrz rysunek 4-9). Insert 18333fig0409.png -Figure 4-9. Interfejs importowanie Subversion. +Rysunek 4-9. Interfejs importowanie Subversion. Jeśli Twój projekt jest bardzo duży, niestandardowy lub prywatny to proces ten najprawdopodobniej nie zadziała. W rozdziale 7 dowiesz się jak ręcznie przeprowadzić bardziej skomplikowany import. @@ -845,17 +845,17 @@ Dodajmy więc resztę naszej drużyny. Jeśli John, Josie i Jessica zapiszą si Naciśnij przycisk "edit" na nagłówku projektu lub w zakładce Admina na górze projektu aby uzyskać dostęp do strony Admina projektu GitHub (zobacz Rysunek 4-10). Insert 18333fig0410.png -Figure 4-10. Strona administratora GitHub. +Rysunek 4-10. Strona administratora GitHub. Aby dać dostęp do projektu kolejnej osobie, naciśnij link “Add another collaborator”. Pojawia się nowe pole tekstowe gdzie można wpisać nazwę użytkownika. Jak już wpiszesz nazwę użytkownika, wyskakujące okienko podpowie Ci pasujących do nazwy użytkowników. Kiedy znajdziesz prawidłowego użytkownika, naciśnij przycisk "Add" aby dodać użytkownika do współpracowników w Twoim projekcie (zobacz Rysunek 4-11). Insert 18333fig0411.png -Figure 4-11. Dodawanie współpracowników do Twojego projektu. +Rysunek 4-11. Dodawanie współpracowników do Twojego projektu. Kiedy skończysz dodawanie współpracowników, powinieneś zobaczyć ich listę w okienku "Repository Collaborators" (zobacz Rysunek 4-12). Insert 18333fig0412.png -Figure 4-12. Lista współpracowników w Twoim projekcie. +Rysunek 4-12. Lista współpracowników w Twoim projekcie. Jeśli musisz zablokować dostęp poszczególnym osobom, możesz kliknąć link "revoke", w ten sposób usuniesz możliwość użycia komendy "push". Dla przyszłych projektów, możesz skopiować grupę współpracowników kopiując ich dane dostępowe w istniejącym projekcie. @@ -864,7 +864,7 @@ Jeśli musisz zablokować dostęp poszczególnym osobom, możesz kliknąć link Po tym jak wyślesz swój projekt lub zaimportujesz z Subversion, będziesz miał stronę główną projektu wyglądającą jak na Rysunku 4-13. Insert 18333fig0413.png -Figure 4-13. Strona główna projektu GitHub. +Rysunek 4-13. Strona główna projektu GitHub. Kiedy ludzie będą odwiedzali Twój projekt, zobaczą tę stronę. Zawiera ona kilka kart. Karta zatwierdzeń pokazuje zatwierdzenia w odwrotnej kolejności, tak samo jak w przypadku polecenia `git log`. Karta połączeń pokazuje wszystkich którzy zrobili rozwidlenie Twojego projektu i uzupełniają go. Karta ściągnięć pozwala ci załadować pliki binarne do projektu oraz linki do paczek z kodami i spakowane wersje wszystkich zaznaczonych punktów w projekcie. Karta Wiki pozwala na dodawanie dokumentacji oraz informacji do projektu. Karta Grafów pokazuje w graficzny sposób statystyki użytkowania projektu. Głowna karta z plikami źródłowymi, które lądują w projekcie pokazuje listę katalogów w projekcie i automatycznie renderuje plik README poniżej jeśli taki znajduje się w głównym katalogu projektu. Ta karta pokazuje również okno z zatwierdzeniami. @@ -877,12 +877,12 @@ W tego typu projektach nie musimy martwić się o dodawanie współpracowników Aby rozwidlić projekt, odwiedź stronę projektu (w tym przykładzie, mojombo/chronic) i naciśnij przycisk "fork" w nagłówku (zobacz Rysunek 4-14). Insert 18333fig0414.png -Figure 4-14. Pozyskanie zapisywalnej wersji projektu poprzez użycie "fork". +Rysunek 4-14. Pozyskanie zapisywalnej wersji projektu poprzez użycie "fork". Po kilku sekundach zostaniesz przeniesiony na swoją stronę projektu, która zawiera informacje, że dany projekt został rozwidlony (zobacz Rysunek 4-15). Insert 18333fig0415.png -Figure 4-15. Twoje rozwidlenie projektu. +Rysunek 4-15. Twoje rozwidlenie projektu. ### Podsumowanie GitHub ### diff --git a/pl/05-distributed-git/01-chapter5.markdown b/pl/05-distributed-git/01-chapter5.markdown index fd5408ae4..92eb3984f 100644 --- a/pl/05-distributed-git/01-chapter5.markdown +++ b/pl/05-distributed-git/01-chapter5.markdown @@ -19,7 +19,7 @@ W scentralizowanych systemach, zazwyczaj jest stosowany model centralnego przep Insert 18333fig0501.png -Figure 5-1. Scentralizowany przepływ pracy. +Rysunek 5-1. Scentralizowany przepływ pracy. Oznacza to tyle, że w sytuacji w której dwóch niezależnych programistów korzystających z tego centralnego repozytorium będzie próbowało wgrać swoje zmiany, tylko pierwszemu z nich uda się tego dokonać bezproblemowo. Drugi przed wgraniem, będzie musiał najpierw pobrać i zintegrować zmiany wprowadzone przez pierwszego programistę, a dopiero później ponowić próbę wysłania swoich na serwer. Taki rodzaj współpracy sprawdza się doskonale w Gitcie, tak samo jak funkcjonuje on w Subversion (lub każdym innym CVCS). @@ -52,7 +52,7 @@ Ponieważ Git powala na posiadanie wielu zdalnych repozytoriów, możliwy jest s --> Insert 18333fig0502.png -Figure 5-2. Przepływ pracy z osobą integrującą zmiany. +Rysunek 5-2. Przepływ pracy z osobą integrującą zmiany. To jest bardzo popularne podejście podczas współpracy przy pomocy stron takich jak GitHub, gdzie bardzo łatwo można stworzyć kopię repozytorium i wgrywać zmiany do niego aby każdy mógł je zobaczyć. jedną z głównych zalet takiego podejścia jest to, że możesz kontynuować pracę, a opiekun może pobrać Twoje zmiany w dowolnym czasie. Programiści nie muszą czekać na opiekuna, aż ten włączy ich zmiany, każdy z nich może pracować oddzielnie. @@ -78,7 +78,7 @@ To jest wariant przepływu z wieloma repozytoriami. Zazwyczaj jest on używany w --> Insert 18333fig0503.png -Figure 5-3. Przepływ pracy z miłościwym dyktatorem. +Rysunek 5-3. Przepływ pracy z miłościwym dyktatorem. Ten rodzaj współpracy nie jest częsty w użyciu, ale może być użyteczny w bardzo dużych projektach, lub bardzo rozbudowanych strukturach zespołów w których lider zespołu może delegować większość pracy do innych i zbierać duże zestawy zmian przed integracją. @@ -237,7 +237,7 @@ W tym momencie lokalne repozytorium Johna wygląda podobnie do tego z rys. 5-4. Insert 18333fig0504.png -Figure 5-4. Lokalne repozytorium Johna. +Rysunek 5-4. Lokalne repozytorium Johna. John ma już odniesienie do zmian które wypchnęła Jessica, ale musi je lokalnie połączyć ze swoimi zmianami, zanim będzie w stanie wypchnąć je: @@ -253,7 +253,7 @@ John ma już odniesienie do zmian które wypchnęła Jessica, ale musi je lokaln Insert 18333fig0505.png -Figure 5-5. Repozytorium Johna po połączeniu z origin/master. +Rysunek 5-5. Repozytorium Johna po połączeniu z origin/master. Teraz, John może przetestować swój kod aby upewnić się że nadal działa poprawnie, oraz następnie wypchnąć swoje zmiany na serwer: @@ -269,7 +269,7 @@ Ostatecznie, historia zmian u Johna wygląda tak jak na rys. 5-6. Insert 18333fig0506.png -Figure 5-6. Historia zmian Johna po wypchnięciu ich na serwer "origin". +Rysunek 5-6. Historia zmian Johna po wypchnięciu ich na serwer "origin". @@ -278,7 +278,7 @@ W tym samym czasie, Jessica pracowała na swojej tematycznej gałęzi. Stworzył Insert 18333fig0507.png -Figure 5-7. Początkowa historia zmian u Jessici. +Rysunek 5-7. Początkowa historia zmian u Jessici. Jessica chce zsynchronizować się ze zmianami Johna, więc pobiera ("fetch"): @@ -295,7 +295,7 @@ Ta komenda pobiera zmiany Johna, które wprowadził w międzyczasie. Historia zm Insert 18333fig0508.png -Figure 5-8. Historia zmian u Jessici po pobraniu zmian Johna. +Rysunek 5-8. Historia zmian u Jessici po pobraniu zmian Johna. @@ -344,7 +344,7 @@ Wszystko połączyło się bez problemów, więc historia zmian u Jessici wyglą Insert 18333fig0509.png -Figure 5-9. Historia zmian u Jessici po włączeniu zmian Johna. +Rysunek 5-9. Historia zmian u Jessici po włączeniu zmian Johna. @@ -362,7 +362,7 @@ Każdy programista wprowadził zmiany kilkukrotnie, oraz połączył zmiany drug Insert 18333fig0510.png -Figure 5-10. Historia zmian u Jessici po wypchnięciu zmian na serwer. +Rysunek 5-10. Historia zmian u Jessici po wypchnięciu zmian na serwer. @@ -371,7 +371,7 @@ To jest jeden z najprostszych przepływów pracy. Pracujesz przez chwilę, gener Insert 18333fig0511.png -Figure 5-11. Sekwencja zdarzeń dla prostego przepływu zmian między programistami. +Rysunek 5-11. Sekwencja zdarzeń dla prostego przepływu zmian między programistami. @@ -433,7 +433,7 @@ Repozytorium Jessici wygląda tak jak na rys. 5-12. Insert 18333fig0512.png -Figure 5-12. Początkowa historia zmian u Jessici. +Rysunek 5-12. Początkowa historia zmian u Jessici. @@ -519,7 +519,7 @@ Historia zmian u Jessici wygląda teraz tak jak na rys. 5-13. Insert 18333fig0513.png -Figure 5-13. Historia zmian Jessici po wprowadzeniu zmian w gałęzi. +Rysunek 5-13. Historia zmian Jessici po wprowadzeniu zmian w gałęzi. @@ -528,7 +528,7 @@ Jessica, Josie i John powiadamiają osoby zajmujące się integracją, że gał Insert 18333fig0514.png -Figure 5-14. Historia zmian u Jessici po włączeniu jej obu gałęzi. +Rysunek 5-14. Historia zmian u Jessici po włączeniu jej obu gałęzi. @@ -537,7 +537,7 @@ Duża ilość grup przechodzi na Gita ze względu na możliwość jednoczesnej w Insert 18333fig0515.png -Figure 5-15. Przebieg zdarzeń w takim przepływie. +Rysunek 5-15. Przebieg zdarzeń w takim przepływie. @@ -620,7 +620,7 @@ Teraz, każdy z zestawów zmian przechowywany jest w formie silosu - podobnego d Insert 18333fig0516.png -Figure 5-16. Początkowa historia ze zmianami featureB. +Rysunek 5-16. Początkowa historia ze zmianami featureB. @@ -637,7 +637,7 @@ To przepisuje twoją historię, która wygląda teraz tak jak na rys. 5-17. Insert 18333fig0517.png -Figure 5-17. Historia zmian po pracach na featureA. +Rysunek 5-17. Historia zmian po pracach na featureA. @@ -665,7 +665,7 @@ Teraz możesz wysłać do opiekuna wiadomość, że wprowadziłeś wszystkie wym Insert 18333fig0518.png -Figure 5-18. Historia zmian po zmianach w featureBv2. +Rysunek 5-18. Historia zmian po zmianach w featureBv2. @@ -1060,12 +1060,12 @@ Jednym z prostszych przepływów pracy jest scalenie zmian z twoją gałęzią ` Insert 18333fig0519.png -Figure 5-19. Historia zmian z kilkoma gałęziami tematycznymi. +Rysunek 5-19. Historia zmian z kilkoma gałęziami tematycznymi. Insert 18333fig0520.png -Figure 5-20. Po scaleniu gałęzi. +Rysunek 5-20. Po scaleniu gałęzi. @@ -1078,17 +1078,17 @@ Jeżeli masz większą ilość deweloperów lub większy projekt, będziesz chci Insert 18333fig0521.png -Figure 5-21. Przed scaleniem gałęzi tematycznej. +Rysunek 5-21. Przed scaleniem gałęzi tematycznej. Insert 18333fig0522.png -Figure 5-22. Po scaleniu gałęzi tematycznej. +Rysunek 5-22. Po scaleniu gałęzi tematycznej. Insert 18333fig0523.png -Figure 5-23. Po utworzeniu kolejnej wersji. +Rysunek 5-23. Po utworzeniu kolejnej wersji. @@ -1105,7 +1105,7 @@ Projekt Gita ma cztery długodystansowe gałęzie: `master`, `next`, `pu` (propo Insert 18333fig0524.png -Figure 5-24. Zarządzanie złożoną serią równoczesnych zmian w gałęziach tematycznych. +Rysunek 5-24. Zarządzanie złożoną serią równoczesnych zmian w gałęziach tematycznych. @@ -1114,7 +1114,7 @@ Jeżeli funkcjonalność potrzebuje jeszcze kolejnych zmian, są one włączane Insert 18333fig0525.png -Figure 5-25. Włączanie gałęzi tematycznych do gałęzi długodystansowych. +Rysunek 5-25. Włączanie gałęzi tematycznych do gałęzi długodystansowych. @@ -1133,7 +1133,7 @@ Drugim sposobem na przeniesienie zmian z jednej gałęzi do drugiej jest zrobien Insert 18333fig0526.png -Figure 5-26. Przykładowa historia przez wybiórczym zaciąganiem zmian. +Rysunek 5-26. Przykładowa historia przez wybiórczym zaciąganiem zmian. @@ -1151,7 +1151,7 @@ To pobierze tylko zmiany z commita `e43a6`, ale otrzyma nową sumę SHA-1, ze wz Insert 18333fig0527.png -Figure 5-27. Historia po wybiórczym zaciągnięciu zmiany z gałęzi tematycznej. +Rysunek 5-27. Historia po wybiórczym zaciągnięciu zmiany z gałęzi tematycznej. diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown index 9dd3e6e3b..2bb6cb043 100644 --- a/pl/06-git-tools/01-chapter6.markdown +++ b/pl/06-git-tools/01-chapter6.markdown @@ -269,7 +269,7 @@ Najczęściej używaną składnią wskazywania zakresu zmian jest podwójna krop Insert 18333fig0601.png -Figure 6-1. Przykładowa historia dla wskazania zakresu zmian. +Rysunek 6-1. Przykładowa historia dla wskazania zakresu zmian. diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown index f7346cd0d..12865f217 100644 --- a/pl/07-customizing-git/01-chapter7.markdown +++ b/pl/07-customizing-git/01-chapter7.markdown @@ -285,7 +285,7 @@ Zamiast wyniku pokazanego w wierszu poleceń, Git uruchomi P4Merge, pokazując w Insert 18333fig0701.png -Figure 7-1. P4Merge. +Rysunek 7-1. P4Merge. Jeżeli spróbujesz wykonać łączenie (ang. merge) na dwóch gałęziach, które zakończy się konfliktem, możesz uruchomić komendę `git mergetool`; zostanie uruchomiony skrypt P4Merge, pozwalający na rozwiązanie konfliktów poprzez interfejs graficzny GUI. @@ -574,10 +574,10 @@ However, that result is of limited use. If you’ve used keyword substitution in It turns out that you can write your own filters for doing substitutions in files on commit/checkout. These are the "clean" and "smudge" filters. In the `.gitattributes` file, you can set a filter for particular paths and then set up scripts that will process files just before they’re checked out ("smudge", see Figure 7-2) and just before they’re committed ("clean", see Figure 7-3). These filters can be set to do all sorts of fun things. Insert 18333fig0702.png -Figure 7-2. The “smudge” filter is run on checkout. +Rysunek 7-2. The “smudge” filter is run on checkout. Insert 18333fig0703.png -Figure 7-3. The “clean” filter is run when files are staged. +Rysunek 7-3. The “clean” filter is run when files are staged. The original commit message for this functionality gives a simple example of running all your C source code through the `indent` program before committing. You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the "indent" filter: diff --git a/pl/09-git-internals/01-chapter9.markdown b/pl/09-git-internals/01-chapter9.markdown index 9dafcad67..1b8b04533 100644 --- a/pl/09-git-internals/01-chapter9.markdown +++ b/pl/09-git-internals/01-chapter9.markdown @@ -173,7 +173,7 @@ W ogólnym zarysie, dane które Git przechowuje wyglądają podobnie do tych pok Insert 18333fig0901.png -Figure 9-1. Prosty przykład modelu danych w Git. +Rysunek 9-1. Prosty przykład modelu danych w Git. @@ -240,7 +240,7 @@ Jeżeli odtworzyłeś katalog roboczy z drzewa które właśnie zapisałeś, otr Insert 18333fig0902.png -Figure 9-2. Zawartość struktury obecnych danych Git. +Rysunek 9-2. Zawartość struktury obecnych danych Git. @@ -337,7 +337,7 @@ Jeżeli prześledzisz wszystkie wskaźniki, dostaniesz widok obiektów podobny d Insert 18333fig0903.png -Figure 9-3. Wszystkie obiekty w Twoim repozytorium Gita. +Rysunek 9-3. Wszystkie obiekty w Twoim repozytorium Gita. @@ -456,7 +456,7 @@ W tej chwili, Twoja baza w Git wygląda podobnie do tej z rysunka 9-4. Insert 18333fig0904.png -Figure 9-4. Obiekty w katalogach Git z uwzględnieniem referencji do gałęzi. +Rysunek 9-4. Obiekty w katalogach Git z uwzględnieniem referencji do gałęzi. From 8df927becc61ef4eb87715184bee0241c006bd78 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Wed, 27 Aug 2014 23:01:13 +0200 Subject: [PATCH 203/291] [cs] revision of the part of ch. 4 --- cs/04-git-server/01-chapter4.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 10929a1fc..48228acbe 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -158,9 +158,9 @@ Pokud provádíte nastavení jen pro malý okruh lidí nebo jen zkoušíte Git v Jestliže už máte server, k němuž mají všichni vaši vývojáři SSH přístup, bude většinou nejjednodušší nastavit první repozitář tam, protože celé nastavení už tím máte v podstatě hotové (jak jsme ukázali v předchozí části). Pokud chcete pro své repozitáře nastavit komplexnější správu oprávnění, můžete je opatřit běžnými oprávněními k systému souborů, které vám nabízí operační systém daného serveru. -Pokud chcete své repozitáře umístit na server, jenž nemá účty pro všechny členy vašeho týmu, kteří by měli mít oprávnění k zápisu, musíte pro ně nastavit SSH přístup. Předpokládáme, že pokud máte server, na němž to lze provést, máte už nainstalován server SSH. Tímto způsobem získáte přístup na server. +Pokud chcete své repozitáře umístit na server, jenž nemá účty pro všechny členy vašeho týmu, kteří by měli mít oprávnění k zápisu, musíte pro ně nastavit SSH přístup. Předpokládáme, že pokud máte server, na němž to lze provést, máte už nainstalován server SSH a jeho prostřednictvím k serveru přistupujete. -Existuje několik způsobů, jak umožnit přístup všem členům vašeho týmu. Prvním způsobem je nastavit účty pro všechny, což není složité, ale může být poněkud zdlouhavé. Možná nebudete mít chuť spouštět příkaz `adduser` (přidat uživatele) a nastavovat dočasná hesla pro každého uživatele zvlášť. +Existuje několik způsobů, jak umožnit přístup všem členům vašeho týmu. Prvním způsobem je nastavit účty pro všechny, což je sice přímočaré, ale může to být poněkud zdlouhavé. Možná nebudete mít chuť spouštět příkaz `adduser` (přidat uživatele) a nastavovat pro každého uživatele dočasná hesla. Druhým způsobem je vytvořit na počítači jediného uživatele 'git', požádat všechny uživatele, kteří mají mít oprávnění k zápisu, aby vám poslali veřejný SSH klíč, a přidat tento klíč do souboru `~/.ssh/authorized_keys` vašeho nového uživatele 'git'. Nyní budou mít všichni přístup k tomuto počítači prostřednictvím uživatele 'git'. Tento postup nemá žádný vliv na data vašich revizí – SSH uživatel, jehož účtem se přihlašujete, neovlivní revize, které jste nahráli. @@ -168,7 +168,7 @@ Dalším možným způsobem je nechat ověřovat SSH přístupy LDAP serveru neb ## Vygenerování veřejného SSH klíče ## -Mnoho serverů Git provádí ověřování pomocí veřejných SSH klíčů. Aby vám mohli všichni uživatelé ve vašem systému poskytnout veřejný klíč, musí si ho nechat vygenerovat (pokud klíč ještě nemají). Tento proces se napříč operačními systémy téměř neliší. +Mnoho serverů Git provádí ověřování totožnosti pomocí veřejných SSH klíčů. Aby vám mohli všichni uživatelé ve vašem systému poskytnout veřejný klíč, musí si ho každý z nich nechat vygenerovat (pokud klíč ještě nemá). Tento proces se napříč operačními systémy téměř neliší. Nejprve byste se měli ujistit, že ještě žádný klíč nemáte. Uživatelské SSH klíče jsou standardně uloženy v adresáři `~/.ssh` daného uživatele. Nejsnazší způsob kontroly, zda už klíč vlastníte, je přejít do tohoto adresáře a zjistit jeho obsah: $ cd ~/.ssh @@ -188,7 +188,7 @@ Zobrazí se několik souborů s názvem `xxx` a `xxx.pub`, kde `xxx` je většin The key fingerprint is: 43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local -Program nejprve potvrdí, kam chcete klíč uložit (`.ssh/id_rsa`), a poté se dvakrát zeptá na přístupové heslo. Pokud nechcete při používání klíče zadávat heslo, nemusíte ho nyní vyplňovat. +Program nejprve potvrdí, kam chcete klíč uložit (`.ssh/id_rsa`), a poté se dvakrát zeptá na přístupové heslo. Pokud nechcete při používání klíče zadávat heslo, můžete ho nyní nechat prázdné. Každý uživatel, který si tímto způsobem nechá vygenerovat veřejný klíč, ho nyní pošle vám nebo jinému správci serveru Git (za předpokladu, že používáte nastavení SSH serveru vyžadující veřejné klíče). Stačí přitom zkopírovat obsah souboru `.pub` a odeslat ho e-mailem. Veřejné klíče mají zhruba tuto podobu: @@ -204,7 +204,7 @@ Budete-li potřebovat podrobnější návod k vytvoření SSH klíče v různýc ## Nastavení serveru ## -Podívejme se nyní na nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření identity uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele. +Projděme si nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření identity uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele. $ sudo adduser git $ su git @@ -238,7 +238,7 @@ Nyní pro ně můžete nastavit prázdný repozitář. Spusťte příkaz `git in $ cd project.git $ git --bare init -John, Josie a Jessica pak mohou do tohoto repozitáře odeslat první verzi svého projektu: přidají si ho jako vzdálený repozitář a odešlou do něj svou větev. Nezapomeňte, že pokaždé, když chcete přidat projekt, se musí k počítači někdo přihlásit a vytvořit holý repozitář. Pro server, na kterém jste nastavili uživatele 'git' a repozitář, můžeme použít název hostitele `gitserver`. Pokud server provozujete interně a nastavíte DNS pro `gitserver` tak, aby ukazovalo na tento server, můžete používat i takovéto příkazy: +John, Josie a Jessica pak mohou do tohoto repozitáře odeslat první verzi svého projektu: přidají si ho jako vzdálený repozitář a odešlou do něj svou větev. Nezapomeňte, že pokaždé, když chcete vytvořit projekt, musí se k počítači někdo přihlásit a vytvořit holý repozitář. Pro server, na kterém jste nastavili uživatele 'git' a repozitář, můžeme použít název hostitele `gitserver`. Pokud server provozujete interně a nastavíte DNS pro `gitserver` tak, aby ukazovalo na tento server, můžete používat i takovéto příkazy: # on Johns computer $ cd myproject @@ -258,7 +258,7 @@ Ostatní nyní mohou velmi snadno repozitář naklonovat i do něj odesílat zm Tímto způsobem lze rychle vytvořit a spustit server Git ke čtení i zápisu pro menší počet vývojářů. -Pro větší bezpečnost máte možnost využít nástroj `git-shell`, který je distribuován se systémem Git. Pomocí něj lze snadno nastavit, aby uživatel 'git' prováděl pouze operace systému Git. Pokud ho nastavíte jako přihlašovací shell uživatele 'git', pak nebude mít uživatel 'git' normální shellový přístup k vašemu serveru. Chcete-li nástroj použít, zadejte pro přihlašovací shell vašeho uživatele `git-shell` místo bash nebo csh. V takovém případě pravděpodobně budete muset upravit soubor `/etc/passwd`: +Pro větší bezpečnost máte možnost využít nástroj `git-shell`, který je distribuován se systémem Git. Pomocí něj lze uživatele 'git' snadno omezit tak, aby mohl prováděl pouze operace systému Git. Pokud ho nastavíte jako přihlašovací shell uživatele 'git', pak nebude mít uživatel 'git' normální shellový přístup k vašemu serveru. Chcete-li nástroj použít, zadejte pro přihlašovací shell vašeho uživatele `git-shell` místo bash nebo csh. V takovém případě pravděpodobně budete muset upravit soubor `/etc/passwd`: $ sudo vim /etc/passwd From 083cfaab89828d5fcb3fa1561fcd0f115627eb96 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 28 Aug 2014 14:16:55 +0200 Subject: [PATCH 204/291] Updating macports git package name git-core has been made obsolete by the port git --- it/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 695b407af..4a9dfc8d2 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -170,7 +170,7 @@ Figura 1-7. Installer di Git per OS X. L'altro metodo è installare Git con MacPorts (`http://www.macports.org`). Se hai MacPorts installato puoi farlo con: - $ sudo port install git-core +svn +doc +bash_completion +gitweb + $ sudo port install git +svn +doc +bash_completion +gitweb Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8). From f8dac602fb74d95e0f258acacc91270be82d6b94 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 28 Aug 2014 14:23:25 +0200 Subject: [PATCH 205/291] [it] reviewing translation for chapter4 --- it/04-git-server/01-chapter4.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown index 388095f08..514cd51f0 100644 --- a/it/04-git-server/01-chapter4.markdown +++ b/it/04-git-server/01-chapter4.markdown @@ -739,19 +739,19 @@ GitHub è leggermente differente nello spazio dei nomi che usa per i progetti ri GitHub è inoltre una organizzazione commerciale che addebita gli account che mantengono repository privati, ma chiunque può avere un account libero per ospitare qualsiasi progetto open source come preferisce. Vedremo velocemente come ottenere ciò. -### Configurare un Account Utente ### +### Configurare un account ### -La prima cosa di cui hai bisogno è configurare un account utente gratuito. Se visiti la pagina "Plans and pricing" all'inidirizzo `http://https://github.com/pricing` e fai click sul pulsante "Sign Up" per un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione. +La prima cosa di cui hai bisogno di un account gratuito. Vai alla pagina "Plans and pricing", che trovi all'inidirizzo `http://https://github.com/pricing`, e clicca sul pulsante "Sign Up" per creare un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione. Insert 18333fig0402.png Figura 4-2. La pagina dei piani di GitHub. -Qui devi scegliere un nome utente che non è già stato scelto nel sistema ed inserire un indirizzo e-mail che verrà associato all'account e una password (vedi Figura 4-3). +Qui devi scegliere un nome utente che non sia già stato scelto da qualcun altro, indicare un indirizzo e-mail che verrà associato all'account e una password (vedi Figura 4-3). Insert 18333fig0403.png Figura 4-3. Il form di iscrizione di GitHub. -Se ne hai una, è buona cosa aggiungere la propria chiave pubblica SSH. Abbiamo già visto come generare una nuova chiave, nella sezione "Piccole Configurazioni". Prendi il contenuto della chiave pubblica della tua coppia di chiavi, ed incollala nel box SSH Public Key. Facendo click sul link "explain ssh keys" otterrai le istruzioni dettagliate su come fare questa cosa sui maggiori sistemi operativi. +Se già ne hai una, è buona cosa aggiungere la propria chiave pubblica SSH. Abbiamo già visto come generare una nuova chiave, nella sezione "Piccole Configurazioni". Prendi il contenuto della chiave pubblica della tua coppia di chiavi, ed incollala nel box SSH Public Key. Facendo click sul link "explain ssh keys" otterrai le istruzioni dettagliate su come fare questa cosa sui maggiori sistemi operativi. Cliccare il pulsante "I agree, sign me up" ti porta al tuo nuovo pannello utente (vedi Figura 4-4). Insert 18333fig0404.png From 9bd72636f2bfe006a57a44cf3f3a7012203f2888 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 28 Aug 2014 14:44:52 +0200 Subject: [PATCH 206/291] [it] improving translation --- it/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 695b407af..e46791bb5 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -161,7 +161,7 @@ O, se usi una distribuzione basata su Debian (come Ubuntu) prova apt-get: ### Installazione su Mac ### -Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di SourceForge (vedi Figura 1-7): +Ci sono due metodi per installare facilmente Git su Mac. Il più semplice è usare l'installazione l'installer grafico di Git, che puoi scaricare da SourceForge (vedi Figura 1-7): http://sourceforge.net/projects/git-osx-installer/ From f004712b5c07a26b884f8a89d4f6b02353b1e4f7 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Thu, 28 Aug 2014 15:41:43 +0200 Subject: [PATCH 207/291] [cs] revision of chapter 4 finished --- cs/04-git-server/01-chapter4.markdown | 80 +++++++++++++-------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index 48228acbe..3dd7abd9b 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -326,7 +326,7 @@ Tímto způsobem můžete během pár minut nastavit oprávnění pro čtení za ## GitWeb ## -Nyní, když máte ke svému projektu nastavena základní oprávnění pro čtení/zápis a pouze pro čtení, možná budete chtít nastavit jednoduchou online vizualizaci. Git vám nabízí CGI skript s názvem GitWeb, který slouží k tomuto účelu. Jak GitWeb funguje, na to se můžete podívat např. na stránkách `http://git.kernel.org` (viz obrázek 4-1). +Nyní, když máte ke svému projektu nastavena základní oprávnění pro čtení/zápis a pouze pro čtení, možná budete chtít nastavit jednoduchou online vizualizaci. Git vám nabízí CGI skript s názvem GitWeb, který se k tomuto účelu běžně používá. V činnosti můžete GitWeb pozorovat například na stránkách `http://git.kernel.org` (viz obrázek 4-1). Insert 18333fig0401.png Obrázek 4-1. Online uživatelské rozhraní GitWeb @@ -364,7 +364,7 @@ Všimněte si, že musíte příkazu pomocí proměnné `GITWEB_PROJECTROOT` sd -Také GitWeb může být obsluhován jakýmkoli webovým serverem umožňujícím CGI. Chcete-li používat jakýkoli jiný server, nemělo by být nastavení obtížné. V tomto okamžiku byste měli být schopni prohlížet své repozitáře online na adrese `http://gitserver/` a používat `http://git.gitserver` ke klonování a vyzvedávání repozitářů prostřednictvím protokolu HTTP. +Znovu připomeňme, že GitWeb může být obsluhován jakýmkoli webovým serverem podporujícím CGI. Chcete-li používat jakýkoli jiný server, nemělo by být nastavení obtížné. V tomto okamžiku byste měli být schopni prohlížet své repozitáře online na adrese `http://gitserver/` a používat `http://git.gitserver` ke klonování a vyzvedávání repozitářů prostřednictvím protokolu HTTP. ## Gitosis ## @@ -374,7 +374,7 @@ Proto možná rádi přejdete na rozšířený softwarový projekt „Gitosis“ Instalace nástroje Gitosis sice nepatří mezi nejsnazší, ale není ani příliš složitá. Nejjednodušší je k ní použít linuxový server – tyto příklady používají běžný Ubuntu server 8.10. -Gitosis vyžaduje některé nástroje v jazyce Python, a proto první, co musíte udělat, je nainstalovat balíček nástrojů nastavení Python, který je v Ubuntu dostupný jako python-setuptools: +Gitosis vyžaduje některé nástroje v jazyce Python, a proto první, co musíte udělat, je nainstalovat pythonovský balíček setuptools, který je v Ubuntu dostupný jako python-setuptools: $ apt-get install python-setuptools @@ -392,7 +392,7 @@ Gitosis teď bude spravovat klíče za vás. Proto je třeba, abyste odstranili $ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak -Dále musíte znovu zapnout shell na uživatele 'git', jestliže jste ho změnili na příkaz `git-shell`. Uživatelé se stále ještě nebudou moci přihlásit, ale Gitosis za vás bude provádět správu. V souboru `/etc/passwd` tak nyní změníme řádek: +Dále musíte znovu zapnout shell na uživatele 'git', jestliže jste ho změnili na příkaz `git-shell`. Uživatelé se stále ještě nebudou moci přihlásit, ale Gitosis za vás bude provádět správu. Takže v souboru `/etc/passwd` změňte následující řádek git:x:1000:1000::/home/git:/usr/bin/git-shell @@ -400,17 +400,17 @@ zpět na git:x:1000:1000::/home/git:/bin/sh -V tomto okamžiku můžeme inicializovat nástroj Gitosis. Učiníte tak spuštěním příkazu `gitosis-init` se svým osobním veřejným klíčem. Není-li váš veřejný klíč na serveru, bude ho tam nutné zkopírovat: +V tomto okamžiku můžeme inicializovat nástroj Gitosis. Učiníte tak spuštěním příkazu `gitosis-init` se svým osobním veřejným klíčem. Není-li váš veřejný klíč na serveru, musíte ho tam nakopírovat: $ sudo -H -u git gitosis-init < /tmp/id_dsa.pub Initialized empty Git repository in /opt/git/gitosis-admin.git/ Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ -Uživatel s tímto klíčem poté bude moci měnit hlavní repozitář Git, který kontroluje nastavení nástroje Gitosis. Dále je třeba ručně nastavit právo spuštění na skriptu `post-update` pro nový řídicí repozitář. +Uživatel s tímto klíčem poté bude moci měnit hlavní repozitář Git, kterým se ovládá nastavení nástroje Gitosis. Dále je třeba ručně nastavit právo spuštění na skriptu `post-update` pro nový řídicí repozitář. $ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update -Nyní máte vše hotovo. Pokud jste nastavení provedli správně, můžete vyzkoušet SSH přístup na server jako uživatel, pro kterého jste přidali veřejný klíč při inicializaci nástroje Gitosis. Mělo by se zobrazit asi následující: +Teď to můžete rozjet. Pokud jste nastavení provedli správně, můžete vyzkoušet SSH přístup na server jako uživatel, pro kterého jste přidali veřejný klíč při inicializaci nástroje Gitosis. Mělo by se zobrazit asi následující: $ ssh git@gitserver PTY allocation request failed on channel 0 @@ -516,20 +516,20 @@ Máte-li jakékoli problémy, může vám pomoci zadání `loglevel=DEBUG` do č ## Gitolite ## -Git se stal hodně populárním v korporátním prostředí, které obvykle mívá další doplňující požadavky na kontrolu přístupu. Nástroj Gitolite byl vytvořen právě na řešení těchto požadavků. +Tato podkapitola slouží k rychlému seznámení s Gitolite a uvádí základní pokyny pro instalaci a nastavení. Nemůže ale nahradit ohromný objem [dokumentace][gltoc], která se s Gitolite dodává. Tato podkapitola se může občas změnit, takže se možná chcete podívat na její [poslední verzi][gldpg]. [gldpg]: http://sitaramc.github.com/gitolite/progit.html [gltoc]: http://sitaramc.github.com/gitolite/master-toc.html Gitolite je autorizační vrstva nad gitem, která při autentizaci spoléhá na `sshd` nebo `httpd`. (Připomeňme si: autentizace spočívá v rozpoznání uživatele, autorizací rozumíme rozhodování, zda má povolení k provádění toho, co se provést pokouší.) -Gitolite umožňuje nastavit přístupová práva nejen na repozitáře (podobně jako Gitosis), ale také na větve a značky v každém repozitáři. To znamená, že lze nastavit, aby určití lidé mohli odesílat jen do určité reference (větve nebo značky) a do jiné ne. +Gitolite umožňuje nastavit přístupová práva nejen na repozitáře (podobně jako Gitosis), ale také na větve a značky v každém repozitáři. To znamená, že lze nastavit, aby určití lidé mohli odesílat jen do určité větve (nebo určité značky; obecně „refs“), ale do jiné ne. ### Instalace ### -Instalace Gitolite je velmi jednoduchá a to i když nebudete číst obsáhlou dokumentaci, která je k dispozici. Budete potřebovat účet na nějakém unixovém serveru (bylo testováno na různých distribucích Linuxu a na Solarisu 10), kde musí být nainstalovány git, Perl a SSH server kompatibilní s OpenSSH. V příkladech uvedených níže budeme používat účet `git` na serveru `gitserver`. +Instalace Gitolite je velmi jednoduchá a to i když si nepřečtete obsáhlou dokumentaci, která je k dispozici. Budete potřebovat účet na nějakém unixovém serveru. Pokud už jsou nainstalovány nástroje Git, Perl a SSH server kompatibilní s OpenSSH, nebudete potřebovat ani přístup root. V příkladech uvedených níže budeme používat účet `git` na serveru `gitserver`. -Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý. Přístup se realizuje přes ssh, takže každá serverová userid je potenciálně „hostitelem gitolite“ (gitolite host). Teď si popíšeme nejjednodušší způsob instalace. V dokumentaci naleznete další metody. +Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý. Přístup se realizuje přes SSH, takže každá serverová userid je potenciálně „hostitelem gitolite“ (gitolite host). Teď si popíšeme nejjednodušší způsob instalace. V dokumentaci naleznete další metody. Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný SSH klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `.pub` (v příkladech budeme používat `scott.pub`). Potom proveďte následující příkazy: @@ -548,7 +548,7 @@ Základní rychlá metoda instalace bude většině lidí vyhovovoat. V případ ### Konfigurační soubor a pravidla přístupu ### -Přepněte se do repozitáře `gitolite-admin` (je umístěn ve vašem domácím adresáři), jakmile je instalace dokončena, a podívejte se co tam je: +Jakmile je instalace dokončena, přepněte se do repozitáře `gitolite-admin`, který jste naklonovali na váš počítač, a podívejte se co tam je: $ cd ~/gitolite-admin/ $ ls @@ -568,9 +568,9 @@ Všimněte si, že „scott“ (jméno veřejného klíče v dříve použitém Přidávání dalších uživatelů je snadné. Pokud chceme přidat uživatele „alice“, získáme její veřejný klíč, pojmenujeme jej `alice.pub` a umístíme jej do adresáře `keydir`. Je součástí klonu repozitáře `gitolite-admin`, který jsme právě vytvořili na pracovní stanici. Přidáme, potvrdíme a odešleme změny (add, commit, push). Tím jsme dosáhli přidání uživatele. -Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde uvedu jen pár zajímavých věcí. +Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde zdůrazníme jen pár věcí. -Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skupin jsou podobná jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl to je až v momentu, kdy „makro“ *použijete*. +Pro usnadnění můžete uživatele i repozitáře sdružovat do skupin. Jména skupin se chovají jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl se pozná až v momentu, kdy „makro“ *použijete*. @oss_repos = linux perl rakudo git gitolite @secret_repos = fenestra pear @@ -588,7 +588,7 @@ Můžete nastavovat přístupová práva na úrovni referencí. Skupina interns RW refs/tags/rc[0-9] = @engineers RW+ = @admins -Výraz za `RW` nebo `RW+` je regulární výraz (regex), se kterým se porovnává jméno odesílané reference. Nazvěme jej tedy „refex“! Refex může mít samozřejmě mnohem více použití než je tady ukázáno, takže si dejte pozor ať to nepřeženete, zvláště pokud se necítíte experty na regulární výrazy. +Výraz za `RW` nebo `RW+` je regulární výraz (regex), se kterým se porovnává jméno odesílané reference (ref). Nazvěme jej tedy „refex“! Refex může mít samozřejmě mnohem více použití než je tady ukázáno, takže si dejte pozor ať to nepřeženete, zvláště pokud nejste kovaní v perlovských regulárních výrazech. Gitolite přidává prefix `refs/heads/` jako usnadnění syntaxe, pokud refex nezačíná na `refs/`, jak jste mohli odhadnout z příkladu. @@ -597,17 +597,17 @@ Důležitou vlastností syntaxe konfiguračního souboru je to, že všechna pra repo gitolite RW+ = sitaram -Toto pravidlo se pak přidá do skupiny pravidel `gitolite` repozitáře. +Toto pravidlo se pak přidá do skupiny pravidel repozitáře `gitolite`. Teď by vás mohlo zajímat, jak jsou vlastně pravidla pro přístup aplikována, pojďme se na to tedy krátce podívat. -V gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) *k jakékoliv* referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis. +V Gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) *k jakékoliv* referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis. -Druhá úroveň je pouze pro práva pro „zápis“ a je podle větve nebo značky v repozitáři. Uživatelské jméno uživatele snažícího se o přístup (`W` nebo `+`) a jméno reference, kterou uživatel chce aktualizovat, jsou dané. Pravidla pro přístup jsou procházena postupně v pořadí, tak jak jsou uvedena v konfiguračním souboru a hledají se záznamy odpovídající této kombinaci uživatelského jména a reference (nezapomeňte ale, že refname se porovnává jako regulární výraz nikoliv jako pouhý řetězec). Jestliže je nalezen odpovídající záznam, odesílání je povoleno. Pokud není nalezeno nic, je přístup zamítnut. +Druhá úroveň se dá použít jen pro práva pro „zápis“ a vázána na větve nebo značky v repozitáři. Uživatelské jméno uživatele snažícího se o přístup (`W` nebo `+`) a jméno reference, kterou uživatel chce aktualizovat, jsou dané. Pravidla pro přístup jsou procházena postupně v pořadí, tak jak jsou uvedena v konfiguračním souboru a hledají se záznamy odpovídající této kombinaci uživatelského jména a reference (nezapomeňte ale, že refname se porovnává jako regulární výraz nikoliv jako pouhý řetězec). Jestliže je nalezen odpovídající záznam, odesílání je povoleno. Pokud není nalezeno nic, je přístup zamítnut. ### Rozšířené řízení přístupu pravidly typu „odmítnutí“ ### -Prozatím jsme si ukázali jen oprávnění nastavená na jednu z hodnot `R`, `RW` nebo `RW+`. Ale Gitolite dovoluje nastavení dalšího oprávnění: `-` s významem „odmítnutí“. To vám dává mnohem více možností, ale za cenu zvýšení složitosti. Popadnutí sítem pravidel už totiž není *jedinou* možností vedoucí k zamítnutí přístupu. *Nyní už záleží na pořadí pravidel!* +Prozatím jsme si ukázali jen oprávnění nastavená na jednu z hodnot `R`, `RW` nebo `RW+`. Ale Gitolite dovoluje nastavení dalšího oprávnění: `-` s významem „odmítnutí“. To vám dává mnohem více možností, ale za cenu zvýšení složitosti. Popadnutí sítem pravidel už totiž není *jedinou* možností vedoucí k zamítnutí přístupu. *Záleží na pořadí pravidel!* Řekněme, že ve výše uvedené situaci budeme chtít, aby skupina engineers mohla vracet změny v jakékoliv větvi *s výjimkou* větví `master` a `integ`. Udělá se to následovně: @@ -619,28 +619,28 @@ Pravidla se budou opět procházet shora dolů až do momentu, kdy narazíte na ### Omezení odesílání změn vázané na soubory ### -K omezení odesílání do určitých větví a určitými uživateli můžete přidat také omezení určující, které soubory mohou uživatelé měnit. Například soubor Makefile (a možná některé programy) by asi neměl kdokoliv měnit, protože je na něm závislá řada dalších věcí. Pokud se neupraví *správným způsobem*, něco by se pokazilo. Nástroji gitolite můžeme říct: +K omezení odesílání do určitých větví a určitými uživateli můžete přidat také omezení určující, které soubory mohou uživatelé měnit. Například soubor Makefile (a možná některé programy) by asi neměl kdokoliv měnit, protože je na něm závislá řada dalších věcí. Pokud se neupraví *správným způsobem*, něco by se pokazilo. Nástroji Gitolite můžeme říct: repo foo RW = @junior_devs @senior_devs - VREF/NAME/Makefile = @junior_devs -Uživatelé, kteří přecházejí ze starší verze gitolite by si měli dát pozor na to, že v souvislosti s uvedeným rysem došlo k výrazné změně chování. Věnujte prosím pozornost detailům, které jsou uvedeny v příručce pro přechod k nové verzi. +Uživatelé, kteří přecházejí ze starší verze Gitolite by si měli dát pozor na to, že v souvislosti s uvedeným rysem došlo k výrazné změně chování. Věnujte prosím pozornost detailům, které jsou uvedeny v příručce pro přechod k nové verzi. ### Osobní větve ### Konečně Gitolite má také funkci, která se nazývá „osobní větve“ (nebo raději „jmenný prostor osobních větví“) a může být velmi užitečná v korporátním prostředí. -Hodně výměny kódu probíhá v otevřeném git světě metodou „prosím stáhněte si“. V korporátním prostředí ovšem nebývá jakýkoliv neautorizovaný přístup vítán a pracovní stanice vývojáře nemůže provádět autentizaci, takže můžete na centrální server odesílat, ale musíte požádat někoho jiného, když odtud chcete stahovat. +Hodně výměny kódu probíhá v otevřeném gitovém světě metodou „prosím stáhněte si“. V korporátním prostředí ovšem nebývá jakýkoliv přístup bez prokázání totožnosti vítán a pracovní stanice vývojáře nemůže provádět autentizaci, takže můžete na centrální server odesílat, ale musíte požádat někoho jiného, když odtud chcete stahovat. -To by za normálních okolností způsobilo stejný zmatek ve jménech větví jako v centralizovaných systémech správy verzí a navíc nastavování přístupových práv by se stalo noční můrou pro administrátory. +To by za normálních okolností způsobilo stejný zmatek ve jménech větví jako v centralizovaných systémech správy verzí a navíc nastavování přístupových práv by administrátorovi přidalo práci. Gitolite vám umožní nadefinovat pro každého vývojáře jmenné prostory s prefixy „personal“ nebo „scratch“ (např. `refs/personal//*`). Podrobnosti hledejte v dokumentaci. ### „Wildcard“ repozitáře ### -Gitolite vám umožní určit repozitáře zástupnými znaky (wildcards; ve skutečnosti jde o perlovské regulární výrazy) -- například k náhodnému výběru zadání příkladu můžeme použít `assignments/s[0-9][0-9]/a[0-9][0-9]`. Umožní nám též přidělit nový režim oprávnění (`C`), který uživatelům povoluje vytvářet repozitáře popsané zástupnými znaky, automaticky přidělí vlastnictví konkrétnímu uživateli, který jej vytvořil, umožní mu přidělit oprávnění `R` a `RW` dalším spolupracovníkům atd. Podrobnosti opět hledejte v dokumentaci. +Gitolite vám umožní určit repozitáře zástupnými znaky (wildcards; ve skutečnosti jde o perlovské regulární výrazy) -- jako například u náhodně vybraného příkladu `assignments/s[0-9][0-9]/a[0-9][0-9]`. Umožní nám též přidělit nový režim oprávnění (`C`), který uživatelům povoluje vytvářet repozitáře popsané zástupnými znaky, automaticky přidělí vlastnictví konkrétnímu uživateli, který jej vytvořil, umožní mu přidělit oprávnění `R` a `RW` dalším spolupracovníkům atd. Podrobnosti opět hledejte v dokumentaci. ### Další vlastnosti ### @@ -648,7 +648,7 @@ Vysvětlení Gitolite završíme přehledem několika vlastností, které jsou d **Logování:** Gitolite loguje všechny úspěšné přístupy. Jestliže máte volná pravidla pro přidělování oprávnění vracet změny (práva `RW+`) a stane se, že někdo takto „zkazí“ větev `master`, je tu ještě log soubor, který vám zachrání život, protože v něm můžete postižené SHA najít. -**Přehledy uživatelských oprávnění:** Další příjemnou vlastností je to, co se stane, pokud se pouze pokusíte připojit pomocí SSH na server. Gitolite vám ukáže, ke kterým repozitářům máte přístup a s jakoými oprávněními. Příklad: +**Přehledy uživatelských oprávnění:** Další příjemnou vlastností je to, co se stane, pokud se pouze pokusíte připojit pomocí SSH na server. Gitolite vám ukáže, ke kterým repozitářům máte přístup a s jakými oprávněními. Příklad: hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4 @@ -660,15 +660,15 @@ Vysvětlení Gitolite završíme přehledem několika vlastností, které jsou d R indic_web_input R shreelipi_converter -**Delegace:** Pro opravdu velké instalace můžete delegovat zodpovědnost za skupiny a repozitáře dalším lidem a nechat je samotné spravovat jednotlivé části. To snižuje vytížení hlavního administrátora, který tím přestává být úským místem správy. +**Delegace:** Pro opravdu velké instalace můžete delegovat zodpovědnost za skupiny a repozitáře dalším lidem a nechat je spravovat jednotlivé části nezávisle. To snižuje vytížení hlavního administrátora, který tím přestává být úzkým místem správy. **Zrcadlení:** Gitolite vám pomůže se správou více zrcadel a při výpadku hlavního serveru můžete snadno přepnout na jiný. ## Démon Git ## -Jestliže potřebujete ke svým projektům veřejný, neověřovaný přístup pro čtení, budete muset překročit hranice vymezené protokolem HTTP a začít používat protokol Git. Mluví pro něj především rychlost. Protokol Git je daleko výkonnější, a proto také rychlejší než protokol HTTP a svým uživatelů tím ušetří spoustu času. +Jestliže potřebujete ke svým projektům přístup pro čtení bez ověřování totožnosti, budete muset obejít protokol HTTP a začít používat protokol Git. Mluví pro něj především rychlost. Protokol Git je daleko výkonnější, a proto také rychlejší než protokol HTTP, takže uživatelům ušetří nějaký čas. -I v tomto případě se jedná o neověřený přístup pouze pro čtení. Pokud protokol používáte na serveru mimo firewall, mělo by to být pouze u projektů, které jsou veřejně viditelné okolnímu světu. Pokud je server, na kterém protokol spouštíte, uvnitř firewallu, můžete ho používat u projektů, k nimž má přístup pro čtení velký počet lidí nebo počítačů (servery průběžné integrace nebo servery sestavení), jimž nechcete jednotlivě přiřazovat SSH klíče. +I v tomto případě se jedná o přístup pouze pro čtení bez ověřování totožnosti. Pokud protokol používáte na serveru mimo firewall, mělo by to být pouze u projektů, které jsou veřejně viditelné okolnímu světu. Pokud je server, na kterém protokol spouštíte, uvnitř firewallu, můžete ho používat u projektů, k nimž má přístup pro čtení velký počet lidí nebo počítačů (servery průběžné integrace nebo servery sestavení), jimž nechcete jednotlivě přiřazovat SSH klíče. Ať tak či tak, na protokolu Git jistě oceníte jeho snadné nastavení. V podstatě je třeba spustit tento příkaz: @@ -699,7 +699,7 @@ Při restartování počítače se démon Git spustí automaticky. V případě V jiných systémech možná budete chtít použít `xinetd`, skript systému `sysvinit`, nebo podobný skript – můžete-li spouštět příkaz démonizovaný a sledovaný. -Dále budete muset svému serveru Gitosis sdělit, k jakým repozitářům si přejete povolit neověřený serverový přístup Git. Pokud přidáte jednu část pro každý repozitář, můžete určit repozitáře, z nichž si přejete dovolit démonovi Git načítat data. Chcete-li povolit přístup přes protokol Git k projektu `iphone_project`, přidejte ho na konec souboru `gitosis.conf`: +Dále budete muset svému serveru Gitosis sdělit, k jakým repozitářům si přejete povolit neautentizovaný serverový přístup Git. Pokud pro každý repozitář přidáte sekci, můžete určit repozitáře, z nichž si přejete dovolit démonovi Git načítat data. Chcete-li povolit přístup přes protokol Git k projektu `iphone_project`, přidejte ho na konec souboru `gitosis.conf`: [repo iphone_project] daemon = yes @@ -711,7 +711,7 @@ Pokud nechcete používat Gitosis, ale chcete nastavit démona Git, budete muset $ cd /path/to/project.git $ touch git-daemon-export-ok -Přítomnost tohoto souboru systému Git sděluje, že si přejete obsluhovat tento projekt bez ověřování. +Přítomnost tohoto souboru systému Git sděluje, že si přejete obsluhovat tento projekt bez ověřování totožnosti. Gitosis může také určovat, jaké projekty bude zobrazovat GitWeb. Nejprve budete muset do souboru `/etc/gitweb.conf` vložit následující: @@ -730,15 +730,15 @@ Pokud teď zapíšete a odešlete projekt, GitWeb začne automaticky zobrazovat ## Hostování projektů Git ## -Pokud nemáte chuť absolvovat celý proces nastavování vlastního serveru Git, existuje několik možností hostování vašich projektů Git na externím specializovaném hostingovém místě. Toto řešení vám nabízí celou řadu výhod. Hostingové místo má většinou velmi rychlé nastavení, snadno se na něm spouštějí projekty a nevyžaduje od vás správu ani monitoring serveru. Dokonce i když budete nastavovat a spouštět interně svůj vlastní server, budete možná přesto chtít použít veřejné hostingové místo pro otevřený zdrojový kód – komunita open source vývojářů si vás tak snáze najde a pomůže vám. +Pokud nemáte chuť absolvovat celý proces nastavování vlastního serveru Git, existuje několik možností hostování vašich projektů Git na externím specializovaném hostingovém místě. Toto řešení vám nabízí celou řadu výhod. Hostingové místo má většinou velmi rychlé nastavení, snadno se na něm zakládají projekty a nevyžaduje od vás správu ani monitoring serveru. Dokonce i když budete nastavovat a spouštět interně svůj vlastní server, budete možná přesto chtít použít veřejné hostingové místo pro otevřený zdrojový kód – komunita open source vývojářů si vás tak snáze najde a pomůže vám. -V dnešní době můžete vybírat z velkého počtu možností hostingu. Každá má jiné klady a zápory. Aktuální seznam těchto míst najdete na stránce GitHosting, dostupné z hlavní stránky GitWiki: +V dnešní době můžete vybírat z velkého počtu možností hostingu. Každá má jiné klady a zápory. Aktuální seznam těchto míst najdete na následující stránce: https://git.wiki.kernel.org/index.php/GitHosting Protože se tu nemůžeme věnovat všem možnostem a protože shodou okolností na jednom hostingovém místě pracuji, využijeme tuto část k tomu, abychom ukázali nastavení účtu a vytvoření nového projektu na serveru GitHub. Získáte tak představu, co všechno vás čeká. -GitHub je zdaleka největším hostingovým místem pro projekty Git s otevřeným zdrojovým kódem a je zároveň jedním z velmi mála těch, která nabízejí možnosti jak veřejného, tak soukromého hostingu. Na jednom místě tak můžete mít uložen jak otevřený zdrojový kód, tak soukromý komerční kód. GitHub se ostatně soukromě podílel i na vzniku této knihy. +GitHub je zdaleka největším hostingovým místem pro projekty Git s otevřeným zdrojovým kódem a je zároveň jedním z velmi mála těch, která nabízejí možnosti jak veřejného, tak soukromého hostingu. Na jednom místě tak můžete mít uložen jak otevřený zdrojový kód, tak soukromý komerční kód. Možnost soukromého použití GitHub jsme ostatně používali pro spolupráci při vzniku této knihy. ### GitHub ### @@ -773,7 +773,7 @@ Začněte kliknutím na odkaz „create a new one“ (vytvořit nový) vedle nad Insert 18333fig0405.png Obrázek 4-5. Vytvoření nového repozitáře na serveru GitHub -Vše, co tu bezpodmínečně musíte udělat, je zadat název projektu. Kromě toho můžete přidat i jeho popis. Poté klikněte na tlačítko „Create Repository“ (Vytvořit repozitář). Nyní máte na serveru GitHub vytvořen nový repozitář (viz obrázek 4-6). +Vše, co tu opravdu musíte udělat, je zadat název projektu. Kromě toho můžete přidat i jeho popis. Poté klikněte na tlačítko „Create Repository“ (Vytvořit repozitář). Nyní máte na serveru GitHub vytvořen nový repozitář (viz obrázek 4-6). Insert 18333fig0406.png Obrázek 4-6. Záhlaví s informacemi o projektu na serveru GitHub @@ -805,7 +805,7 @@ Obrázek 4-8. Záhlaví projektu s veřejnou a soukromou adresou URL ### Import ze systému Subversion ### -Máte-li existující veřejný projekt Subversion, který byste rádi importovali do systému Git, GitHub vám s tím často ochotně pomůže. Dole na stránce s instrukcemi najdete odkaz na import ze systému Subversion. Pokud na něj kliknete, zobrazí se formulář s informacemi o importu a textové pole, kam můžete vložit adresu URL svého veřejného projektu Subversion (viz obrázek 4-9). +Máte-li existující veřejný projekt Subversion, který byste rádi importovali do systému Git, GitHub vám s tím obvykle pomůže. Dole na stránce s instrukcemi najdete odkaz na import ze systému Subversion. Pokud na něj kliknete, zobrazí se formulář s informacemi o importu a textové pole, kam můžete vložit adresu URL svého veřejného projektu Subversion (viz obrázek 4-9). Insert 18333fig0409.png Obrázek 4-9. Rozhraní importu ze systému Subversion @@ -840,20 +840,20 @@ Po odeslání projektu nebo jeho naimportování ze systému Subversion budete m Insert 18333fig0413.png Obrázek 4-13. Hlavní stránka projektu na serveru GitHub -Navštíví-li váš projekt ostatní uživatelé, tuto stránku uvidí. Obsahuje několik záložek k různým aspektům vašich projektů. Záložka „Commits“ zobrazuje seznam revizí v obráceném chronologickém pořadí, podobně jako výstup příkazu `git log`. Záložka „Network“ zobrazuje všechny uživatele, kteří rozštěpili váš projekt a přispěli do něj. Záložka „Downloads“ umožňuje nahrávat binární soubory k projektu a přidávat odkazy na tarbally a komprimované verze všech míst ve vašem projektu, které jsou označeny značkou (tagem). Záložka „Wiki“ vám nabízí stránku wiki, kam můžete napsat dokumentaci nebo jiné informace ke svému projektu. Záložka „Graphs“ graficky zobrazuje některé příspěvky a statistiky k vašemu projektu. Hlavní záložka „Source“, na níž se stránka otvírá, zobrazuje hlavní adresář vašeho projektu, a máte-li soubor README, automaticky ho zařadí na konec seznamu. Tato záložka obsahuje rovněž pole s informacemi o poslední zapsané revizi. +Navštíví-li váš projekt ostatní uživatelé, tuto stránku uvidí. Obsahuje několik záložek k různým aspektům vašich projektů. Záložka „Commits“ zobrazuje seznam revizí v obráceném chronologickém pořadí, podobně jako výstup příkazu `git log`. Záložka „Network“ zobrazuje všechny uživatele, kteří se odštěpili od vašeho projektu a zase do něj přispěli. Záložka „Downloads“ umožňuje nahrávat binární soubory k projektu a přidávat odkazy na tarbally a komprimované verze všech míst ve vašem projektu, které jsou označeny značkou (tagem). Záložka „Wiki“ vám nabízí stránku wiki, kam můžete napsat dokumentaci nebo jiné informace ke svému projektu. Záložka „Graphs“ graficky zobrazuje některé příspěvky a statistiky k vašemu projektu. Hlavní záložka „Source“, na níž se stránka otvírá, zobrazuje hlavní adresář vašeho projektu, a máte-li soubor README, automaticky pod adresářem projektu zobrazí jeho obsah. Tato záložka obsahuje rovněž pole s informacemi o poslední zapsané revizi. ### Štěpení projektů ### -Chcete-li přispět do existujícího projektu, k němuž nemáte oprávnění pro odesílání, umožňuje GitHub rozštěpení projektu. Pokud se dostanete na zajímavou stránku projektu a chtěli byste se do projektu zapojit, můžete kliknout na tlačítko „fork“ (rozštěpit) v záhlaví projektu a GitHub vytvoří kopii projektu pro vašeho uživatele. Do ní pak můžete odesílat revize. +Chcete-li přispět do existujícího projektu, k němuž nemáte oprávnění pro odesílání, umožňuje GitHub rozštěpení projektu. Pokud se dostanete na zajímavou stránku projektu a chtěli byste se do projektu zapojit, můžete kliknout na tlačítko „fork“ (rozštěpit -- doslova vidlička) v záhlaví projektu a GitHub vytvoří kopii projektu pro vašeho uživatele. Do ní pak můžete odesílat revize. -Díky tomu se projekty nemusí starat o přidávání uživatelů do role spolupracovníků, aby mohli odesílat své příspěvky. Uživatelé mohou projekt rozštěpit a odesílat do něj revize. Hlavní správce projektu tyto změny natáhne tím, že je přidá jako vzdálené repozitáře a začlení jejich data. +Díky tomu se projekty nemusí starat o přidávání uživatelů do role spolupracovníků, kteří by měli právo zápisu. Uživatelé mohou projekt rozštěpit a odesílat do něj revize. Hlavní správce projektu tyto změny natáhne tím, že je přidá jako vzdálené repozitáře a začlení jejich data. Chcete-li projekt rozštěpit, přejděte na stránku projektu (v tomto případě mojombo/chronic) a klikněte na tlačítko „fork“ v záhlaví (viz obrázek 4-14). Insert 18333fig0414.png Obrázek 4-14. Zapisovatelnou kopii jakéhokoli repozitáře získáte kliknutím na tlačítko „fork“. -Po několika sekundách přejdete na novou stránku svého projektu, která oznamuje, že je tento projekt rozštěpením (fork) jiného projektu (viz obrázek 4-15). +Po několika sekundách přejdete na novou stránku svého projektu, která oznamuje, že je tento projekt odštěpen (fork) z jiného projektu (viz obrázek 4-15). Insert 18333fig0415.png Obrázek 4-15. Vaše rozštěpení projektu @@ -868,4 +868,4 @@ Existuje několik možností, jak vytvořit a zprovoznit vzdálený repozitář Provoz vlastního serveru vám dává celou řadu možností kontroly a umožňuje provozovat server za vaším firewallem. Nastavení a správa takového serveru však obvykle bývají časově náročné. Umístíte-li data na hostovaný server, je jejich nastavení a správa jednoduchá. Svůj zdrojový kód však v takovém případě ukládáte na cizím serveru, což některé organizace nedovolují. -Mělo by být jasně dáno, které řešení nebo jaká kombinace řešení je vhodná pro vás a pro vaši organizaci. +Teď už byste se měli umět rozhodnout, které řešení nebo jaká kombinace řešení se pro vás a pro vaši organizaci hodí. From a56e1a75549fb17b111df1cc2e8a94da6537bd6a Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Thu, 28 Aug 2014 15:48:06 +0200 Subject: [PATCH 208/291] [cs] snippet updated in chapter 1 --- cs/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index 33aa76d00..6a29be757 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -170,7 +170,7 @@ Obrázek 1-7. Instalátor Git pro OS X Jiným obvyklým způsobem je instalace systému Git prostřednictvím systému MacPorts (`http://www.macports.org`). Máte-li systém MacPorts nainstalován, nainstalujte Git příkazem: - $ sudo port install git-core +svn +doc +bash_completion +gitweb + $ sudo port install git +svn +doc +bash_completion +gitweb Není nutné přidávat všechny doplňky, ale pokud budete někdy používat Git s repozitáři systému Subversion, budete pravděpodobně chtít nainstalovat i doplněk +svn (viz kapitola 8). From 71619c4f5bba8d352d907b992b67bfdb8a4e2dae Mon Sep 17 00:00:00 2001 From: Andrew McCarthy Date: Thu, 28 Aug 2014 20:14:48 +0100 Subject: [PATCH 209/291] Remove mention of gitosis in gitolite section. Gitosis is mentioned for no useful reason in the gitolite section. Remove it (fixes #508). --- en/04-git-server/01-chapter4.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown index 88bfff101..e4022c1b0 100644 --- a/en/04-git-server/01-chapter4.markdown +++ b/en/04-git-server/01-chapter4.markdown @@ -601,7 +601,7 @@ That rule will just get added to the ruleset for the `gitolite` repository. At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly. -There are two levels of access control in Gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. This is the only access control that Gitosis had. +There are two levels of access control in Gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. The second level, applicable only to "write" access, is by branch or tag within a repository. The username, the access being attempted (`W` or `+`), and the refname being updated are known. The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched). If a match is found, the push succeeds. A fallthrough results in access being denied. From 4db85c6bd52b056cf8e6d7714404cf3bcd9bee96 Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Thu, 28 Aug 2014 14:48:36 +0200 Subject: [PATCH 210/291] Adding homebrew as alternative to install git It's very easy to install git with brew --- en/01-introduction/01-chapter1.markdown | 6 +++++- es/01-introduction/01-chapter1.markdown | 8 ++++++-- it/01-introduction/01-chapter1.markdown | 6 +++++- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index 9079a47b5..9cd2d5620 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -161,7 +161,7 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: ### Installing on Mac ### -There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7): +There are three easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7): http://sourceforge.net/projects/git-osx-installer/ @@ -174,6 +174,10 @@ The other major way is to install Git via MacPorts (`http://www.macports.org`). You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). +Homebrew (`http://brew.sh/`) is another alternative to install Git. If you have Homebrew installed, install Git via + + $ brew install git + ### Installing on Windows ### Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown index e340e566b..692764e4c 100644 --- a/es/01-introduction/01-chapter1.markdown +++ b/es/01-introduction/01-chapter1.markdown @@ -161,19 +161,23 @@ O si estás en una distribución basada en Debian como Ubuntu, prueba con apt-ge ### Instalando en Mac ### -Hay dos maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de SourceForge (véase Figura 1-7): +Hay tres maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de SourceForge (véase Figura 1-7): http://sourceforge.net/projects/git-osx-installer/ Insert 18333fig0107.png Figura 1-7. Instalador de Git para OS X. -La otra manera es instalar Git a través de MacPorts (`http://www.macports.org`). Si tienes MacPorts instalado, instala Git con: +Una alternativa es instalar Git a través de MacPorts (`http://www.macports.org`). Si tienes MacPorts instalado, instala Git con: $ sudo port install git-core +svn +doc +bash_completion +gitweb No necesitas añadir todos los extras, pero probablemente quieras incluir +svn en caso de que alguna vez necesites usar Git con repositorios Subversion (véase el Capítulo 8). +La segunda alternativa es Homebrew (`http://brew.sh/`). Si ya tienes instalado Homebrew, instala Git con: + + $ brew install git + ### Instalando en Windows ### Instalar Git en Windows es muy fácil. El proyecto msysGit tiene uno de los procesos de instalación más sencillos. Simplemente descarga el archivo exe del instalador desde la página de GitHub, y ejecútalo: diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index e46791bb5..72a6dfeb6 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -168,12 +168,16 @@ Ci sono due metodi per installare facilmente Git su Mac. Il più semplice è usa Insert 18333fig0107.png Figura 1-7. Installer di Git per OS X. -L'altro metodo è installare Git con MacPorts (`http://www.macports.org`). Se hai MacPorts installato puoi farlo con: +La prima alternativa è usando MacPorts (`http://www.macports.org`). Se hai già installato MacPorts puoi installare Git con: $ sudo port install git-core +svn +doc +bash_completion +gitweb Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8). +La seconda alternativa è Homebrew (`http://brew.sh/`). Se hai già installato Homebrew puoi installare Git con: + + $ brew install git + ### Installare su Windows ### Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione più facili. Semplicemente scarica l'eseguibile dalla pagina di GitHub e lancialo: From 0a7234cbce6ab1c40e119e69ba9ddad9d8a80a5b Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Fri, 29 Aug 2014 16:22:04 +0200 Subject: [PATCH 211/291] [cs] first changes during revision of chapter 5 --- cs/05-distributed-git/01-chapter5.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown index f5848226b..da4cbf4b8 100644 --- a/cs/05-distributed-git/01-chapter5.markdown +++ b/cs/05-distributed-git/01-chapter5.markdown @@ -6,7 +6,7 @@ V této kapitole se dozvíte, jak pracovat se systémem Git v distribuovaném pr ## Distribuované pracovní postupy ## -Na rozdíl od centralizovaných systémů správy verzí (CVCS) umožňuje distribuovaný charakter systému Git mnohem větší flexibilitu při spolupráci vývojářů na projektech. V centralizovaných systémech představuje každý vývojář samostatný uzel, pracující více či méně na stejné úrovni vůči centrálnímu úložišti. Naproti tomu je v systému Git každý vývojář potenciálním uzlem i úložištěm, každý vývojář může přispívat kódem do jiných repozitářů i spravovat veřejný repozitář, na němž mohou ostatní založit svou práci a do nějž mohou přispívat. Tím se otvírá široké spektrum možností organizace práce pro váš projekt a/nebo váš tým. Zkusíme se tedy podívat na pár častých postupů, které tato flexibilita umožňuje. Uvedeme přednosti i eventuální slabiny všech těchto postupů. Budete si moci vybrat některý z postupů nebo je navzájem kombinovat a spojovat jejich funkce. +Na rozdíl od centralizovaných systémů správy verzí (CVCS) umožňuje distribuovaný charakter systému Git mnohem větší flexibilitu při spolupráci vývojářů na projektech. V centralizovaných systémech představuje každý vývojář samostatný uzel, pracující více či méně na stejné úrovni vůči centrálnímu úložišti. Naproti tomu je v systému Git každý vývojář potenciálním uzlem i úložištěm, každý vývojář může přispívat kódem do jiných repozitářů i spravovat veřejný repozitář, na němž mohou ostatní založit svou práci a do nějž mohou přispívat. Tím se pro váš projekt a váš tým otvírá široké spektrum pracovních postupů. Zkusíme se tedy podívat na pár častých přístupů, které tato flexibilita umožňuje. Uvedeme jejich přednosti i eventuální slabiny. Budete si moci vybrat některý z postupů nebo je navzájem kombinovat a spojovat jejich vlastnosti. ### Centralizovaný pracovní postup ### @@ -17,12 +17,12 @@ Obrázek 5-1. Centralizovaný pracovní postup To znamená, že pokud dva vývojáři klonují z centrálního úložiště a oba provedou změny, jen první z nich, který odešle své změny, to může provést bez komplikací. Druhý vývojář musí před odesláním svých změn začlenit práci prvního vývojáře do své, aby nepřepsal jeho změny. Tento koncept platí jak pro Git, tak pro Subversion (popř. jakýkoli CVCS). I v systému Git funguje bez problémů. -Pokud pracujete v malém týmu nebo už jste ve své společnosti nebo ve svém týmu zvyklí na centralizovaný pracovní postup, můžete v něm beze všeho pokračovat. Jednoduše vytvořte repozitář a přidělte všem ze svého týmu oprávnění k odesílání dat. Git neumožní uživatelům, aby se navzájem přepisovali. Pokud některý z vývojářů naklonuje data, provede změny a poté se je pokusí odeslat, a jiný vývojář mezitím odeslal svoje revize, server tyto změny odmítne. Git vývojáři při odmítnutí sdělí, že se pokouší odeslat změny, které nesměřují „rychle vpřed“, což není možné provést, dokud nevyzvedne a nezačlení stávající data z repozitáře. +Pokud pracujete v malém týmu nebo už jste ve své společnosti nebo ve svém týmu zvyklí na centralizovaný pracovní postup, můžete v něm beze všeho pokračovat. Jednoduše vytvořte repozitář a přidělte všem ze svého týmu oprávnění k odesílání dat. Git neumožní uživatelům, aby se navzájem přepisovali. Pokud některý z vývojářů naklonuje data, provede změny a poté se je pokusí odeslat, a jiný vývojář mezitím odeslal svoje revize, server tyto změny odmítne. Git vývojáři při odmítnutí sdělí, že se pokouší odeslat změny, které nesměřují „rychle vpřed“, což není možné provést, dokud nevyzvedne a nezačlení (fetch and merge) stávající data z repozitáře. Tento pracovní postup může být pro mnoho lidí zajímavý, protože je to schéma, které jsou zvyklí používat a jsou s ním spokojeni. ### Pracovní postup s integračním manažerem ### -Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze použít pracovní postup, kdy má každý vývojář oprávnění k zápisu do vlastního veřejného repozitáře a oprávnění pro čtení k repozitářům všech ostatních. Tento scénář často zahrnuje jeden standardní repozitář, který reprezentuje „oficiální“ projekt. Chcete-li do tohoto projektu přispívat, vytvořte vlastní veřejný klon projektu a odešlete do něj změny, které jste provedli. Poté odešlete správci hlavního projektu žádost, aby do projektu natáhl vaše změny. Váš repozitář může přidat jako vzdálený repozitář, lokálně otestovat vaše změny, začlenit je do své větve a odeslat zpět do svého repozitáře. Postup práce je následující (viz obrázek 5-2): +Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze použít pracovní postup, kdy má každý vývojář oprávnění k zápisu do vlastního veřejného repozitáře a oprávnění pro čtení k repozitářům všech ostatních. Tento scénář často zahrnuje jeden standardní repozitář, který reprezentuje „oficiální“ projekt. Chcete-li do tohoto projektu přispívat, vytvořte vlastní veřejný klon projektu a odešlete do něj změny, které jste provedli. Poté odešlete správci hlavního projektu žádost, aby do projektu natáhl vaše změny. Správce může váš repozitář přidat jako vzdálený repozitář, lokálně otestovat vaše změny, začlenit je do své větve a odeslat zpět do svého repozitáře. Postup práce je následující (viz obrázek 5-2): 1. Správce projektu odešle data do svého veřejného repozitáře. 2. Přispěvatel naklonuje tento repozitář a provede změny. @@ -34,7 +34,7 @@ Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze p Insert 18333fig0502.png Obrázek 5-2. Pracovní postup s integračním manažerem -Tento pracovní postup je velmi rozšířený na stránkách jako GitHub, kde je snadné rozštěpit projekt a odeslat změny do své odštěpené části, kde jsou pro každého k nahlédnutí. Jednou z hlavních předností tohoto postupu je, že můžete pracovat bez přerušení a správce hlavního repozitáře může natáhnout vaše změny do projektu, kdykoli uzná za vhodné. Přispěvatelé nemusí čekat, až budou jejich změny začleněny do projektu – každá strana může pracovat svým tempem. +Tento pracovní postup je velmi rozšířený na serverech jako je GitHub, kde je snadné rozštěpit projekt a odeslat změny do své odštěpené části, kde jsou pro každého k nahlédnutí. Jednou z hlavních předností tohoto postupu je, že můžete pracovat bez přerušení a správce hlavního repozitáře může natáhnout vaše změny do projektu, kdykoli uzná za vhodné. Přispěvatelé nemusí čekat, až budou jejich změny začleněny do projektu – každá strana může pracovat svým tempem. ### Pracovní postup s diktátorem a poručíky ### From cbfa4f81798d5b34991654a91655467a9de3148d Mon Sep 17 00:00:00 2001 From: "Alessandro P." Date: Sun, 31 Aug 2014 10:14:57 +0200 Subject: [PATCH 212/291] Misspelling uppercase insert -> Insert image 3-8 Cause the misspelling the website do not show the figure in the html tag but only print [..]insert 18333fig0308.png [..] --- it/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/03-git-branching/01-chapter3.markdown b/it/03-git-branching/01-chapter3.markdown index 2e598ea06..de1d4975c 100644 --- a/it/03-git-branching/01-chapter3.markdown +++ b/it/03-git-branching/01-chapter3.markdown @@ -71,7 +71,7 @@ Questo è interessante, perché ora il tuo ramo testing è stato spostato in ava La Figura 3-8 mostra il risultato. -insert 18333fig0308.png +Insert 18333fig0308.png Figura 3-8. HEAD si è spostato ad un altro ramo con un checkout. Questo comando ha fatto due cose. Ha spostato il puntatore HEAD indietro per puntare al ramo master e ha riportato i file nella tua directory di lavoro allo stato in cui si trovavano in quel momento. Questo significa anche che i cambiamenti che farai da questo punto in poi saranno separati da una versione più vecchia del progetto. Essenzialmente riavvolge temporaneamente il lavoro che hai fatto nel tuo ramo testing così puoi muoverti in una direzione differente. From ab98f8f0c6c15c665d1bcf8b4b1a0595805023c9 Mon Sep 17 00:00:00 2001 From: "Alessandro P." Date: Sun, 31 Aug 2014 14:31:24 +0200 Subject: [PATCH 213/291] [it] misspelling temo -> tempo allo stesso temo -> allo stesso tempo --- it/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/03-git-branching/01-chapter3.markdown b/it/03-git-branching/01-chapter3.markdown index 2e598ea06..81aabfc5e 100644 --- a/it/03-git-branching/01-chapter3.markdown +++ b/it/03-git-branching/01-chapter3.markdown @@ -388,7 +388,7 @@ Questo può un po' confondere, quindi vediamo un esempio. Diciamo che hai un ser Insert 18333fig0322.png Figura 3-22. Un clone con Git fornisce un proprio ramo principale e un puntatore origin/master al ramo principale di origine. -Se fai del lavoro sul tuo ramo principale locale, e, allo stesso temo, qualcuno ha inviato degli aggiornamenti al ramo principale di `git.ourcompany.com`, allora la tua storia si muoverà in avanti in modo differente. Inoltre, mentre non hai contatti con il tuo server di partenza, il tuo puntatore `origin/master` non si sposterà (vedi Figura 3-23). +Se fai del lavoro sul tuo ramo principale locale, e, allo stesso tempo, qualcuno ha inviato degli aggiornamenti al ramo principale di `git.ourcompany.com`, allora la tua storia si muoverà in avanti in modo differente. Inoltre, mentre non hai contatti con il tuo server di partenza, il tuo puntatore `origin/master` non si sposterà (vedi Figura 3-23). Insert 18333fig0323.png Figura 3-23. Lavorando in locale ed avendo qualcuno che ha inviato al server remoto qualcosa rende l'avanzamento delle storie differente. From fedcc90c057d1cc27695139ba809fa5183568917 Mon Sep 17 00:00:00 2001 From: "Alessandro P." Date: Mon, 1 Sep 2014 12:26:56 +0200 Subject: [PATCH 214/291] [it] Fixed various misspelling --- it/05-distributed-git/01-chapter5.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown index adb3990f0..102ff0e02 100755 --- a/it/05-distributed-git/01-chapter5.markdown +++ b/it/05-distributed-git/01-chapter5.markdown @@ -105,11 +105,11 @@ Questo modello è stato originariamente scritto da Tim Pope su tpope.net: Se tutti i tuoi messaggi di commit fossero così, per te e gli altri sviluppatori con cui lavori le cose saranno molto più semplici per te e per gli sviluppatore con cui lavori. Il progetto di Git ha dei messaggi di commit ben formattati: ti incoraggio a eseguire `git log --no-merges` per vedere qual è l'aspetto di una cronologia ben leggibile. -Nei esempi che seguono e nella maggior parte di questo libro, per brevità, non formatterò i messaggi accuratamente come descritto: userò invece l'opzione `-m` di `git commit`. Fa' come dico, non come faccio. +Negli esempi che seguono e nella maggior parte di questo libro, per brevità, non formatterò i messaggi accuratamente come descritto: userò invece l'opzione `-m` di `git commit`. Fa' come dico, non come faccio. ### Piccoli gruppi privati ### -La configurazione più semplice che è più facile che incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository. +La configurazione più semplice che è più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository. Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server. Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`) From f2f76f1331ab55702de6c98dd8dc0f86736c98ca Mon Sep 17 00:00:00 2001 From: "Alessandro P." Date: Mon, 1 Sep 2014 12:32:30 +0200 Subject: [PATCH 215/291] [it] Improved sentence readability --- it/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown index 102ff0e02..1ff072e7f 100755 --- a/it/05-distributed-git/01-chapter5.markdown +++ b/it/05-distributed-git/01-chapter5.markdown @@ -109,7 +109,7 @@ Negli esempi che seguono e nella maggior parte di questo libro, per brevità, no ### Piccoli gruppi privati ### -La configurazione più semplice che è più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository. +La configurazione più semplice che più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository. Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server. Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`) From 762b4b1f37610c6fb262a090bb0b93b49cbad984 Mon Sep 17 00:00:00 2001 From: "Alessandro P." Date: Mon, 1 Sep 2014 12:46:43 +0200 Subject: [PATCH 216/291] [it] Added tab space - Fixed '' --- it/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown index 1ff072e7f..8b53f93f0 100755 --- a/it/05-distributed-git/01-chapter5.markdown +++ b/it/05-distributed-git/01-chapter5.markdown @@ -285,7 +285,7 @@ A questo punto lei deve condividere il suo lavoro con John, così fa la push sul Jessica manda una e-mail a John dicendogli che fatto la push del suo lavoro su un branch chiamato `funzioanlitaA` chiedendogli se lui può dargli un'occhiata. Mentre aspetta una risposta da John, Jessica decide di iniziare a lavorare su `funzionalitaB` con Josie. Per iniziare, crea un nuovo branch basandosi sul branch `master` del server: - # Computer di Jessica + # Computer di Jessica $ git fetch origin $ git checkout -b featureB origin/master Switched to a new branch "featureB" From 015820d29ae7bdca10ff94ccc15b35999fa682f6 Mon Sep 17 00:00:00 2001 From: Brennon Bortz Date: Tue, 2 Sep 2014 09:07:57 -0400 Subject: [PATCH 217/291] Update 'git log' completion output --- en/02-git-basics/01-chapter2.markdown | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown index 9aa20341f..8737af541 100644 --- a/en/02-git-basics/01-chapter2.markdown +++ b/en/02-git-basics/01-chapter2.markdown @@ -1176,8 +1176,11 @@ In this case, typing `git co` and then pressing the Tab key twice suggests commi This also works with options, which is probably more useful. For instance, if you’re running a `git log` command and can’t remember one of the options, you can start typing it and press Tab to see what matches: - $ git log --s - --shortstat --since= --src-prefix= --stat --summary + $ git log --s + --shortstat --sparse + --simplify-by-decoration --src-prefix= + --simplify-merges --stat + --since= --summary That’s a pretty nice trick and may save you some time and documentation reading. From 0efe58537fb6dc6006dccd3c80073e6834a0410c Mon Sep 17 00:00:00 2001 From: Tobias Kerst Date: Wed, 3 Sep 2014 03:39:40 +0200 Subject: [PATCH 218/291] [de] Entfernt die Anmerkung von gitosis im Abschnitt zu gitolite MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Gitosis wird im Abschnitt zu gitolite erwähnt, ohne das dies relevant wäre. Dies behebt #508 und geht auf den Fix in #870 ein. --- de/04-git-server/01-chapter4.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown index e0f25980c..432ee1436 100644 --- a/de/04-git-server/01-chapter4.markdown +++ b/de/04-git-server/01-chapter4.markdown @@ -887,9 +887,9 @@ Diese Regel gehört dann zum Regelsatz des `gitolite` Repository. An dieser Stelle fragst Du Dich vielleicht, wie die Zugriffsregeln eigentlich angewandt werden. Lass uns das kurz anschauen. - + -Es gibt zwei Ebenen für die Zugriffsberechtigung in Gitolite. Die erste befindet sich auf Repository Ebene. Wenn Du Lese- oder Schreifzugriff auf jede Ref in einem Repository hast, dann kannst Du damit das ganze Repository sowohl lesen, als auch schreiben. Gitosis kennt nur diese Art der Zugriffsberechtigung. +Es gibt zwei Ebenen für die Zugriffsberechtigung in Gitolite. Die erste befindet sich auf Repository Ebene. Wenn Du Lese- oder Schreifzugriff auf jede Ref in einem Repository hast, dann kannst Du damit das ganze Repository sowohl lesen, als auch schreiben. From aa90017e17b57545f612b32ddc7dc1d22b53f54b Mon Sep 17 00:00:00 2001 From: Tobias Kerst Date: Wed, 3 Sep 2014 03:51:41 +0200 Subject: [PATCH 219/291] [de] Includes homebrew as an alternative to install git. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fügt die in Issue #868 angemerkte Möglichkeit der Installation über Homebrew zur deutschen Übersetzung hinzu. --- de/01-introduction/01-chapter1.markdown | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown index 5c60ced9d..28c1e64e3 100644 --- a/de/01-introduction/01-chapter1.markdown +++ b/de/01-introduction/01-chapter1.markdown @@ -221,7 +221,7 @@ Wenn eine bestimmte Version einer Datei im Git Verzeichnis liegt, gilt sie als ## Git installieren ## - + Lass uns damit anfangen, Git tatsächlich zu verwenden. Der erste Schritt besteht natürlich darin, Git zu installieren und das kann, wie üblich, auf unterschiedliche Weisen geschehen. Die beiden wichtigsten bestehen darin, entweder den Quellcode herunterzuladen und selbst zu kompilieren oder ein fertiges Paket für Dein Betriebssystem zu installieren. @@ -302,6 +302,16 @@ Die andere Möglichkeit ist, Git via MacPorts (http://www.macports.org) zu insta Du brauchst die optionalen Features natürlich nicht mit zu installieren, aber es macht Sinn `+svn` zu verwenden, falls Du jemals Git mit einem Subversion Repository verwenden willst. + + +Alternativ kann man Git auch über Homebrew (`http://brew.sh/`) installieren. Hast Du Homebrew bereits, kannst Du Git einfach über den folgenden Befehl installieren: + + $ brew install git + ### Installation unter Windows ### From efa9203323abb68b8d2d82ba7d51cc13ae76d03d Mon Sep 17 00:00:00 2001 From: Denis C de Azevedo Date: Wed, 3 Sep 2014 02:12:45 -0300 Subject: [PATCH 220/291] [pt-br] fix mispelling concerto -> conserto --- pt-br/03-git-branching/01-chapter3.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pt-br/03-git-branching/01-chapter3.markdown b/pt-br/03-git-branching/01-chapter3.markdown index 21bf4b417..8f9bb99fd 100644 --- a/pt-br/03-git-branching/01-chapter3.markdown +++ b/pt-br/03-git-branching/01-chapter3.markdown @@ -151,8 +151,8 @@ Em seguida, você tem uma correção para fazer. Vamos criar um branch para a co $ git checkout -b 'hotfix' Switched to a new branch "hotfix" $ vim index.html - $ git commit -a -m 'concertei o endereço de email' - [hotfix]: created 3a0874c: "concertei o endereço de email" + $ git commit -a -m 'consertei o endereço de email' + [hotfix]: created 3a0874c: "consertei o endereço de email" 1 files changed, 0 insertions(+), 1 deletions(-) Insert 18333fig0313.png @@ -310,7 +310,7 @@ O comando `git branch` faz mais do que criar e apagar branches. Se você execut Note o caractere `*` que vem antes do branch `master`: ele indica o branch que você está atualmente (fez o checkout). Isso significa que se você fizer um commit nesse momento, o branch `master` irá se mover adiante com seu novo trabalho. Para ver o último commit em cada branch, você pode executar o comando `git branch -v`: $ git branch -v - iss53 93b412c concertar problema em javascript + iss53 93b412c consertar problema em javascript * master 7a98805 Merge branch 'iss53' testing 782fd34 adicionar scott para a lista de autores nos readmes From 956b22e669f861ca311784bd14d7dc2b9d23b667 Mon Sep 17 00:00:00 2001 From: "Alessandro P." Date: Wed, 3 Sep 2014 18:24:01 +0200 Subject: [PATCH 221/291] [it] Sentence improved Miglioramento della frase introduttiva sotto consiglio di @daftano in seguito ad un breve scambio di commenti --- it/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown index 8b53f93f0..6d453984b 100755 --- a/it/05-distributed-git/01-chapter5.markdown +++ b/it/05-distributed-git/01-chapter5.markdown @@ -109,7 +109,7 @@ Negli esempi che seguono e nella maggior parte di questo libro, per brevità, no ### Piccoli gruppi privati ### -La configurazione più semplice che più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository. +La configurazione più semplice che probabilmente incontrerai sarà di un progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository. Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server. Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`) From 68e778d69531cc39350f4987b485e4c60cf473a1 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Wed, 3 Sep 2014 21:10:19 +0200 Subject: [PATCH 222/291] Add a test on badly formated insert directive The directive for inserting an image is: Insert --- Rakefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Rakefile b/Rakefile index d5d31dd16..3aeaebf78 100644 --- a/Rakefile +++ b/Rakefile @@ -197,8 +197,13 @@ def test_lang(lang, out) error_code = true end end - if line.match /^\s*Insert\s(.*)/ - figure_count = figure_count + 1 + if line.match /^\s*Insert\s(.*)/i + if line.match /^\s*Insert\s(.*)/ + figure_count = figure_count + 1 + else + out << "\n#{lang}: Badly cased Insert directive: #{line}\n" + error_code = true + end end end # This extraction is a bit contorted, because the pl translation renamed From 6289f47fc735a3c7aa6110fae688ca32ad1cd072 Mon Sep 17 00:00:00 2001 From: Ciro Santilli Date: Thu, 4 Sep 2014 21:52:30 +0200 Subject: [PATCH 223/291] Mention packed-refs. --- en/09-git-internals/01-chapter9.markdown | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown index 71d41a932..e1e0071a9 100644 --- a/en/09-git-internals/01-chapter9.markdown +++ b/en/09-git-internals/01-chapter9.markdown @@ -331,6 +331,12 @@ Figure 9-4. Git directory objects with branch head references included. When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create. +If a reference is not found under the `refs` directory, Git then searches for it in the `.git/packed-refs` file, which contains space separated SHA-1 path pairs, for example: + + 52d771167707552d8e2a50f602c669e2ad135722 refs/tags/v1.0.1 + +This file exists for performance reasons, as it is more efficient to have a single file rather than many small ones for references that don't change very often. You can tell Git to pack references into that file by using the `git pack-refs` command. + ### The HEAD ### The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this: From 9c936d027ab1492bfb681f5883c4116f8ee7ba51 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Sun, 7 Sep 2014 01:11:26 +0300 Subject: [PATCH 224/291] [ar] translating file editing, checking status, tracking new files, staging modified files, ignoring files --- ar/02-git-basics/01-chapter2.markdown | 61 +++++++++++++-------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 0bea0227d..da77fdd39 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -1,4 +1,4 @@ -# مبادئ Git # +# مبادئ Git # إذا كان هناك فصل واحد عليك قراءته لكي تبدأ بإستخدام Git، فعليك بهذا الفصل! يغطي هذا الفصل جميع الأوامر الأساسية التي عليك معرفتها لكي تتمكن من القيام بأغلب الأمور أثناء استخدامك لـ Git. في نهاية هذا الفصل يجب أن تكون قادراً على انشاء واعداد الـ repository لمشروعك وعلى تحديد الملفات التي ستتم متابعتها والتي ستترك، وعلى تهييئ التغييرات لعمل commit عليها. ستتعلم أيضاً كيف تعد Git لكي تتجاهل بعض أنواع الملفات، كيف تقوم بالتراجع عن الأخطاء التي سترتكبها بسرعة وبسهولة، كيف تتصفح تاريخ مشروعك وكيف تعرض التغيرات بين الـ commits، وكيف تنشر وتسحب (push & pull) التغيرات من الـ repositories البعيدة عنك. @@ -40,27 +40,26 @@ هناك عدد من البروتوكولات المختلفة التي يمكنك اسستعمالها لنقل المعلومات في git. المثال السابق يستعمل بروتوكول 'git://'، ولكن من الممكن أن تجد أيضاً استخداماً لـ 'http(s)://' أو 'user@server:/path.git'، والتي تستعمل بروتوكول SSH في النقل. في الفصل الرابع من الكتاب ستتعرف على الخيارات المتوفرة للتواصل مع الـ repository الخاصة بك وميزات ومساوئ كل منها. ## تسجيل التعديلات في الـ repository ## +لديك repository أصلي ونسخة لتعمل عليها من ملفات المشروع. عليك أن تقوم ببعض التعديلات ثم تعمل commit لهذه التعديلات في repository الخاص بك في كل مرة يصل فيها المشروع إلى نقطة تود تسجيلها. -You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +تذكر أنه كل ملف في مجلد العمل يمكن أن يكون في إحدى الحالتين فقط: مٌتَتَبّع tracked أو غير مٌتَتَبّع untracked. الملفات المٌتتبّعة هي ملفات كانت في أخر snapshot ويمكن إلغاء التعديلات عليها أو التعديل عليها أو وضعه في حالة staged (جاهز من أجل commit). الملفات غير المُتتبّعة هي كل الملفات الآخرى - أي ملف في مجلد العمل لم يكن موجوداً في آخر snapshot وليس معلماً بأنه staged. عندما تقوم باستنساخ repository جميع ملفاتك تكون بحالة متتبّعة tracked و غير معدلة unmodified لأنك قمت للتو بعمل check out ولم تقم بأي تعديل. -Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. - -As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1. +عندما تعدل الملفات، سيقوم git بتأشيرهم على أنهم modified، لأنك قمت بتغيرهم عن آخر commit. تقوم بعمل stage لهذه الملفات المعدلة ثم تقوم بعمل commit لجميع التغيرات في منطقة stage، وتتكرر العملية. يوضع الشكل 2-1 دورة العملية. Insert 18333fig0201.png -Figure 2-1. The lifecycle of the status of your files. +الشكل 2-1. دورة حالة الملفات. -### Checking the Status of Your Files ### +### تفقد حالة ملفاتك ### -The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this: +باستخدام الأمر git status يمكننا معرفة حالة الملفات لدينا. إذا قمت بتشغيل هذا الأمر مباشرة بعد قيامك بعمل clone يجب أن ترى شيئاً يشبه التالي: $ git status # On branch master nothing to commit, working directory clean -This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. +وهذا يعني أنه لديك مجلد عمل نظيف - بمعنى آخر، لايوجد أي ملفات معدلة أو ملفات غير مُتتبّعة. كما أنّ هذا الأمر يخبرك بأي فرع branch أنت تعمل. حالياً، دائماً هو master، وهو الافتراضي؛ في الفصل المقبل سنمر على الأفرع و المرجعيات references بالتفصيل. -Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so: +لنقل بأنك قمت بإضافة ملف جديد على مشروعك، وليكن ملف README بسيط. إذا لم يكن الملف موجوداً مسبقاً، وقمت بتنفيذ الأمر `git status` سترى الملف غير مُتتبّعاً كما يلي: $ vim README $ git status @@ -71,15 +70,15 @@ Let’s say you add a new file to your project, a simple README file. If the fil # README nothing added to commit but untracked files present (use "git add" to track) -You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file. +يمكنك ملاحظة أنّ ملفك الجديد README غير مُتتبّع، فهو تحت تبويب "untracked files" في خرج الأمر. ويعني ذلك أنّ git يرى ملفاً جديداً على commit السابقة؛ علماً أنّ git لن يقوم بإضافة هذا الملف إلى الملفات المتتبعة إلا إذا قمت بطلب ذلك بشكل مباشر، والهدف من ذلك من أجل حماية المشروع من الضم الخاطئ لملفات binary أو أي ملفات لا تود بإضافتها. إلاّ أنّك ترغب في إضافة README إلى الملفات المتتبّعة. وسنقوم بذلك حالاً. -### Tracking New Files ### +### تتبع الملفات الجديدة ### -In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this: +للقيام بتتبع ملف جديد عليه استخدام الأمر `git add` . مثلاً لنقم بتتبع الملف الجديد README: $ git add README -If you run your status command again, you can see that your README file is now tracked and staged: +إذا قمنا بتنفيذ الأمر `git status` مرة أخرى سنلاحظ أن الملف README أصبح متتبعاً وجاهزاً staged للقيام بعملية commit: $ git status # On branch master @@ -89,11 +88,11 @@ If you run your status command again, you can see that your README file is now t # new file: README # -You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively. +نستطيع معرفة بأن الملف staged من خلال ملاحظته تحت بند "changes to be comitted". إذا قمت بعمل commit في هذه اللحظة، سيقوم git بإضافة النسخة الحالية من الملف إلى snapshot. تذكر عندما قمنا بعمل git init سابقاً، ثم قمنا بإضافة الملفات عن طريق git add، كان ذلك للقيام ببدء تتبع الملفات في مجلد المشروع. يقبل الأمر git add مسار لملف أو لمجلد؛ فإذا كان المسار لمجلد سيقوم git بإضافة جميع الملفات والمجلدات ضمنه بشكل تعاودي recursively. -### Staging Modified Files ### +### تجهيز الملفات المعدلة ### -Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this: +لنقم بالتعديل على ملف قمنا بإضافته سابقاً. إذا قمنا مثلاً بالتعديل على ملف متتبع مسبقاً يدعى `benchmarks.rb` وقمنا بتنفيذ الأمر git status، سيكون الخرج مشابهاً للخرج التالي: $ git status # On branch master @@ -108,7 +107,7 @@ Let’s change a file that was already tracked. If you change a previously track # modified: benchmarks.rb # -The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again: +يظهر الملف benchmarks.rb تحت بند "changes not staged for commit" وهذا يعني أن الملف المُتتبّع قد خضع لعملية تعديل لكنه لم يخضع للتجهيز من أجل commit. للقيام بتجهيزه (أو تأشيره للإضافة إلى commit الجديد) يجب علينا تنفيذ الأمر `git add` (لاحظ بأنّه أمر متعدد الوظائف - نستطيع استخدامه لتتبع الملفات الجديدة، تجهيز الملفات من أجل commit، والقيام بأمور أخرى مثل حل الاعتراضات في حال القيام بدمج merge). لنقم بتنفيذ git add الآن لوضع benchmarks.rb بحالة staged، ومن ثم لنقم بتنفيذ الأمر git status لنرى ما الذي قد تغيّر: $ git add benchmarks.rb $ git status @@ -120,7 +119,7 @@ The benchmarks.rb file appears under a section named “Changes not staged for c # modified: benchmarks.rb # -Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time: +كلا الملفين الآن جاهز للإدخال بعملية commit المقبلة. في هذه النقطة، لنفرض أنك تود القيام بتعديل على ملف benchmarks.rb قبل القيام بعملية commit، ستقوم بفتح الملف والتعديل عليه وأنك جاهز للقيام بعملية commit. لكن قبل ذلك، دعنا نقوم بتنفيذ الأمر git status مرة إضافية: $ vim benchmarks.rb $ git status @@ -137,7 +136,7 @@ Both files are staged and will go into your next commit. At this point, suppose # modified: benchmarks.rb # -What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +ما الذي يحصل؟ كيف أصبح benchmarks.rb موجوداً تحت التبويبين staged و unstaged؟ لقد اتضح لنا أنّ git يقوم بتجهيز الملف على حالته عند قيامك بتنفيذ الأمر git add. إذا قمت بعمل commit الآن، ستكون نسخة benchmarks.rb كما كانت عند قيامك بتنفيذ الأمر git add وليس النسخة الجديدة التي حصلنا عليها بعد قيامنا بتعديل الملف. لذا إذا قمنا بتعديل ملف قبل قيامنا بتنفيذ git add، وقبل القيام بعملية commit، علينا تجهيز الملف مرة أخرى لعملية commit، وذلك بتنفيذ الأمر git add مرة جديدة: $ git add benchmarks.rb $ git status @@ -149,26 +148,26 @@ What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is t # modified: benchmarks.rb # -### Ignoring Files ### +### تجاهل الملفات ### -Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file: +غالباً ما تود من git تجاهل صنف من الملفات بحث لا يقوم بإضافتها تلقائياً أو لا يظهرها بأنّها غير متتبعة. تكون هذه الملفات عادة ملفات مولدة بشكل تلقائي مثل ملفات log و الملفات الوسيطة التي تولدها أدوات التطوير لديك. في مثل هذه الحالات/ يمكن إنشاء ملف .gitignore يحوي على أنماط لأسماء الملفات التي نرغب بتجاهلها. هذا مثال عمّا قد يحتويه ملف .gitignore: $ cat .gitignore *.[oa] *~ -The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository. +أول سطر يقوم بتوجيه git إلى تجاهل أي ملفات ذات لواحق من النوع o أو a - ملفات الكائنات وملفات الأرشيف وهي ملفات وسيطة تولدها أدوات بناء الكود عادة. السطر الثاني يوجه git إلى تجاهل أي ملفات تنتهي بالرمز (~) والتي تكون ملفات مؤقتة عادةً تستخدمها بعض برامج تحرير الكود. قد ترغب أيضاً بإضافة مجلدات log و tmp أو pid؛ أو حتى ملفات التوثيق تلقائية التوليد (من الكود عادة)، وغيرها. ينصح بإضافة ملف .gitignore في بداية إنشاء repository حتى نتجنب إضافة بعض الملفات عن طريق الخطأ وتلويث respository. -The rules for the patterns you can put in the .gitignore file are as follows: +قواعد الأنماط التي يمكن وضعها ضمن ملف .gitignore هي كالتالي: -* Blank lines or lines starting with # are ignored. -* Standard glob patterns work. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* الأسطر التي تبدأ بالرمز (#) يتم تجاهلها. +* أنماط glob القياسية تعمل. +* يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً. +* يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط. -Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . +أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. -Here is another example .gitignore file: +مثال عن ملف .gitignore: # a comment – this is ignored # no .a files @@ -182,7 +181,7 @@ Here is another example .gitignore file: # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt -### Viewing Your Staged and Unstaged Changes ### +### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ### If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. From 0fa39cad0a85ea9b848c8c96862f167ae8c660ea Mon Sep 17 00:00:00 2001 From: Ulf Ninow Date: Sun, 7 Sep 2014 11:27:29 +0200 Subject: [PATCH 225/291] fix typo in 01-chapter2 --- de/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown index 525e6382b..c4be80626 100644 --- a/de/02-git-basics/01-chapter2.markdown +++ b/de/02-git-basics/01-chapter2.markdown @@ -1129,7 +1129,7 @@ Dieser Befehl lädt alle Daten aus dem Remote Repository herunter, die noch nich -Wenn Du ein Repository geklont hast, legt der Befehl automatisch einen Verweis auf dieses Repository unter dem Namen `origin` an. D.h. `git fetch origin` lädt alle Neuigkeiten herunter, die in dem Remote Repository von anderen hinzugefügt wurden, seit Du es geklont hast (oder zuletzt `git fetch` ausgeführt hast). Es ist wichtig, zu verstehen, dass der `git fetch` Befehl Daten lediglich in Dein lokales Repository lädt. Er führt sich mit Deinen eigenen Commits in keiner Weise zusammen (mergt) oder modifiziert, woran Du gerade arbeitest. D.h. Du musst die heruntergeladenen Änderungen anschließend selbst manuell mit Deinen eigenen zusammeführen, wenn Du das willst. +Wenn Du ein Repository geklont hast, legt der Befehl automatisch einen Verweis auf dieses Repository unter dem Namen `origin` an. D.h. `git fetch origin` lädt alle Neuigkeiten herunter, die in dem Remote Repository von anderen hinzugefügt wurden, seit Du es geklont hast (oder zuletzt `git fetch` ausgeführt hast). Es ist wichtig, zu verstehen, dass der `git fetch` Befehl Daten lediglich in Dein lokales Repository lädt. Er führt sich mit Deinen eigenen Commits in keiner Weise zusammen (mergt) oder modifiziert, woran Du gerade arbeitest. D.h. Du musst die heruntergeladenen Änderungen anschließend selbst manuell mit Deinen eigenen zusammenführen, wenn Du das willst. From 20603d9eec60eb8ad79c82af91166446fc1b5fca Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Tue, 9 Sep 2014 18:20:13 +0200 Subject: [PATCH 226/291] Translating PR878 --- it/09-git-internals/01-chapter9.markdown | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/it/09-git-internals/01-chapter9.markdown b/it/09-git-internals/01-chapter9.markdown index 56fe57b36..82116868f 100644 --- a/it/09-git-internals/01-chapter9.markdown +++ b/it/09-git-internals/01-chapter9.markdown @@ -345,8 +345,13 @@ Ora, il tuo database Git assomiglia concettualmente alla Figura 9-4. Insert 18333fig0904.png Figura 9-4. La directory degli oggetti Git directory con inclusi i riferimenti branch e head. -Quando esegui comandi come `git branch (branchname)`, Git in realtà esegue il comando `update-ref` per -aggiungere lo SHA-1 dell'ultima commit del branch nel quale siete, in qualsiasi nuovo riferimento vogliate creare. +Quando esegui comandi come `git branch (branchname)`, Git in realtà esegue il comando `update-ref` per aggiungere lo SHA-1 dell'ultima commit del branch nel quale siete, in qualsiasi nuovo riferimento vogliate creare. + +Se Git non trova un riferimento nella directory `refs` lo cercherà nel file `.git/packed-refs`, che contiene coppie di percorsi con i relativi SHA-1. Per esempio: + + 52d771167707552d8e2a50f602c669e2ad135722 refs/tags/v1.0.1 + +Questo file esiste per motivi di prestazioni, perché, per riferimenti che non cambiano spesso, è molto più efficiente avere un unico file, piuttosto che tanti piccolissimi. Puoi far comprimere a Git i riferimenti in questo file con il comando `git pack-refs`. ### Intestazione ### From f93b8a3d28397f848e872db86eb5b941840f66fe Mon Sep 17 00:00:00 2001 From: Davide Fiorentino lo Regio Date: Tue, 9 Sep 2014 18:26:34 +0200 Subject: [PATCH 227/291] [it] updating autocompletion output As per PR #874 --- it/02-git-basics/01-chapter2.markdown | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index aa304ff8e..b3621e6f9 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -1175,8 +1175,11 @@ In questo caso, scrivendo `git co` e premendo poi due volte il tasto Tab, compai Questo funziona anche con le opzioni, che probabilmente è molto più utile. Se per esempio stai eseguendo `git log` e non ricordi un'opzione, puoi premere il tasto Tab per vedere quelle disponibili: - $ git log --s - --shortstat --since= --src-prefix= --stat --summary + $ git log --s + --shortstat --sparse + --simplify-by-decoration --src-prefix= + --simplify-merges --stat + --since= --summary Questo è un trucco davvero utile e permette di risparmiare molto tempo e evitarti la lettura della documentazione. From edfd7c840a99550f10161a986ee54ffd4e3fc0d4 Mon Sep 17 00:00:00 2001 From: "P. Tamami" Date: Wed, 10 Sep 2014 16:00:30 +0700 Subject: [PATCH 228/291] Update 01-chapter3.markdown update sub-head Basic Branching and Merging and partially in sub-sub-header Basic Branching --- id/03-git-branching/01-chapter3.markdown | 38 ++++++++++++------------ 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown index 3762d0418..13bb0bf7b 100644 --- a/id/03-git-branching/01-chapter3.markdown +++ b/id/03-git-branching/01-chapter3.markdown @@ -92,50 +92,50 @@ Hal ini kontras dengan cara yang dilakukan banyak VCS dalam branch, yang butuh m Mari kita lihat mengapa anda harus melakukannya. -## Basic Branching and Merging ## +## Dasar Pencabangan (Branching) dan Penggabungan (Merging) ## -Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps: +Mari kita lihat contoh sederhana dari Pencabangan dan Penggabungan dengan diagram alir yang biasa kita gunakan secara nyata. Anda akan mengikut tahapan berikut : -1. Do work on a web site. -2. Create a branch for a new story you’re working on. -3. Do some work in that branch. +1. Bekerja di jejaring (website). +2. Buat pencabangan untuk hal baru yang sedang dikerjakan. +3. Bekerja di pencabangan tersebut. -At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: +Pada tahap ini, anda akan menerima pesan bahwa ada masalah yang kritis dan anda perlu memperbaikinya. Anda akan melakukan tahapan berikut : -1. Revert back to your production branch. -2. Create a branch to add the hotfix. -3. After it’s tested, merge the hotfix branch, and push to production. -4. Switch back to your original story and continue working. +1. Kembali ke pencabangan saat produksi. +2. Membuat pencabangan untuk memperbaiki masalah. +3. Setelah diuji, gabungkan pencabangan perbaikan tadi, dan tempatkan di bagian produksi. +4. Kembali ke kasus sebelumnya dan kembali bekerja. -### Basic Branching ### +### Dasar Pencabangan ### -First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10). +Pertama, katakan anda sedang mengerjakan sebuah proyek dan telah melakukan *commits* (lihat Gambar 3-10). Insert 18333fig0310.png -Figure 3-10. A short and simple commit history. +Gambar 3-10. Sejarah *commit* yang pendek dan sederhana. -You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: +Anda memutuskan untuk mengerjakan masalah #53 pada apapun jenis sistem pelacak-masalah yang digunakan perusahaan. Untuk memperjelas, Git tidak terikat dengan sistem pelacak-masalah apapun; tapi karena masalah #53 adalah inti topik yang akan dikerjakan, anda akan membuat pencabangan dimana anda bekerja. Untuk membuat pencabangan dan berpindah kesana dalam satu waktu, anda dapat menjalankan perintah `git checkout` dengan tanda `-b` : $ git checkout -b iss53 Switched to a new branch "iss53" -This is shorthand for: +Ini adalah bentuk singkat untuk : $ git branch iss53 $ git checkout iss53 -Figure 3-11 illustrates the result. +Gambar 3-11 menjelaskan hasilnya. Insert 18333fig0311.png -Figure 3-11. Creating a new branch pointer. +Gambar 3-11. Membuat penunjuk baru pencabangan. -You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12): +Anda bekerja di jejaring *website* dan melakukan beberapa *commits*. Dengan melakukannya, menggeser cabang `iss53` kedepan, karena anda menyelesaikannya (demikianlah, HEAD anda penunjuk ke sana; lihat Gambar 3-12) : $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' Insert 18333fig0312.png -Figure 3-12. The iss53 branch has moved forward with your work. +Gambar 3-12. Cabang iss53 telah bergerak kedepan sesuai pekerjaan anda. Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch. From dc4d50f37c8393eaa86a12d9f6b668c53d1929c9 Mon Sep 17 00:00:00 2001 From: Lauri Nurmi Date: Sat, 13 Sep 2014 22:12:32 +0300 Subject: [PATCH 229/291] [fi] Change the words used as translation for stage/staging area/etc. The previously used word is based on the wrong meaning of "stage", not the one intended by Git. --- fi/01-introduction/01-chapter1.markdown | 14 ++--- fi/02-git-basics/01-chapter2.markdown | 70 ++++++++++++------------- fi/NOTES | 3 +- 3 files changed, 44 insertions(+), 43 deletions(-) diff --git a/fi/01-introduction/01-chapter1.markdown b/fi/01-introduction/01-chapter1.markdown index ead7c3bf8..2c562dca0 100644 --- a/fi/01-introduction/01-chapter1.markdown +++ b/fi/01-introduction/01-chapter1.markdown @@ -97,26 +97,26 @@ Tämä tekee Gitin käyttämisestä hauskaa, koska me tiedämme, että voimme ko ### Kolme tilaa ### -Lue nyt huolellisesti. Tämä on pääasia muistaa Gitistä, jos sinä haluat lopun opiskeluprosessistasi menevän sulavasti. Gitillä on kolme pääasiallista tilaa, joissa tiedostosi voivat olla: pysyvästi muutettu (commited), muutettu (modified), ja lavastettu (staged). Pysyvästi muutettu tarkoittaa, että data on turvallisesti varastoitu sinun paikalliseen tietokantaasi. Muutettu tarkoittaa, että olet muuttanut tiedostoa, mutta et ole tehnyt vielä pysyvää muutosta tietokantaasi. Lavastettu tarkoittaa, että olet merkannut muutetun tiedoston nykyisessä versiossaan menemään seuraavaan pysyvään tilannekuvaan. +Lue nyt huolellisesti. Tämä on pääasia muistaa Gitistä, jos sinä haluat lopun opiskeluprosessistasi menevän sulavasti. Gitillä on kolme pääasiallista tilaa, joissa tiedostosi voivat olla: pysyvästi muutettu (commited), muutettu (modified), ja valmisteltu (staged). Pysyvästi muutettu tarkoittaa, että data on turvallisesti varastoitu sinun paikalliseen tietokantaasi. Muutettu tarkoittaa, että olet muuttanut tiedostoa, mutta et ole tehnyt vielä pysyvää muutosta tietokantaasi. Valmisteltu tarkoittaa, että olet merkannut muutetun tiedoston nykyisessä versiossaan menemään seuraavaan pysyvään tilannekuvaan. -Tämä johdattaa meidät kolmeen seuraavaan osaan Git-projektia: Git-hakemisto, työskentelyhakemisto, ja lavastusalue. +Tämä johdattaa meidät kolmeen seuraavaan osaan Git-projektia: Git-hakemisto, työskentelyhakemisto, ja valmistelualue. Insert 18333fig0106.png -Kuva 1-6. Työskentelyhakemisto, lavastusalue, ja Git-hakemisto. +Kuva 1-6. Työskentelyhakemisto, valmistelualue, ja Git-hakemisto. Git-hakemisto on paikka, johon Git varastoi metadatan ja oliotietokannan projektillesi. Tämä on kaikkein tärkein osa Gitiä, ja se sisältää sen, mitä kopioidaan, kun kloonaat tietovaraston toiselta tietokoneelta. Työskentelyhakemisto on yksittäinen tiedonhaku yhdestä projektin versiosta. Nämä tiedostot vedetään ulos pakatusta tietokannasta Git-hakemistosta ja sijoitetaan levylle sinun käytettäväksesi tai muokattavaksesi. -Lavastusalue on yksinkertainen tiedosto, yleensä se sisältyy Git-hakemistoosi, joka varastoi informaatiota siitä, mitä menee seuraavaan pysyvään muutokseen. Sitä viitataan joskus indeksiksi, mutta on tulossa standardiksi viitata sitä lavastusalueeksi. +Valmistelualue on yksinkertainen tiedosto, yleensä se sisältyy Git-hakemistoosi, joka varastoi informaatiota siitä, mitä menee seuraavaan pysyvään muutokseen. Sitä viitataan joskus indeksiksi, mutta on tulossa standardiksi viitata sitä valmistelualueeksi. Normaali Git-työnkulku menee jokseenkin näin: 1. Muokkaat tiedostoja työskentelyhakemistossasi. -2. Lavastat tiedostosi, lisäten niistä tilannekuvia lavastusalueellesi. -3. Teet pysyvän muutoksen, joka ottaa tiedostot sellaisina, kuin ne ovat lavastusalueella, ja varastoi tämän tilannekuvan pysyvästi sinun Git-tietolähteeseesi. +2. Valmistelet tiedostosi, lisäten niistä tilannekuvia valmistelualueellesi. +3. Teet pysyvän muutoksen, joka ottaa tiedostot sellaisina, kuin ne ovat valmistelualueella, ja varastoi tämän tilannekuvan pysyvästi sinun Git-tietolähteeseesi. -Jos tietty versio tiedostosta on Git-hakemistossa, se on yhtä kuin pysyvä muutos. Jos sitä on muokattu, mutta se on lisätty lavastusalueelle, se on lavastettu. Ja jos se on muuttunut siitä, kun se on haettu, mutta sitä ei ole lavastettu, se on muutettu. Luvussa 2 opit enemmän näistä tiloista ja kuinka voit hyödyntää niitä tai ohittaa lavastusosan kokonaan. +Jos tietty versio tiedostosta on Git-hakemistossa, se on yhtä kuin pysyvä muutos. Jos sitä on muokattu, mutta se on lisätty valmistelualueelle, se on valmisteltu. Ja jos se on muuttunut siitä, kun se on haettu, mutta sitä ei ole valmisteltu, se on muutettu. Luvussa 2 opit enemmän näistä tiloista ja kuinka voit hyödyntää niitä tai ohittaa valmisteluvaiheen kokonaan. ## Gitin asennus ## diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown index 2221d8629..259e0b2cb 100644 --- a/fi/02-git-basics/01-chapter2.markdown +++ b/fi/02-git-basics/01-chapter2.markdown @@ -1,6 +1,6 @@ # Gitin perusteet # -Jos voit lukea vain yhden kappaleen päästäksesi vauhtiin Gitin kanssa, se on tämä kappale. Tämä kappale sisältää jokaisen peruskomennon, jonka tarvitset tehdäksesi valtavan määrän asioita, joiden kanssa viimein tulet käyttämään aikaasi Gitillä työskennellessäsi. Tämän kappaleen lopussa, sinun tulisi pystyä konfiguroimaan ja alustamaan tietolähde, aloittamaan ja lopettamaan tiedostojen jäljitys sekä lavastaa ja tehdä pysyviä muutoksia. Me myös näytämme sinulle kuinka asettaa Git niin, että se jättää tietyt tiedostot ja tiedostomallit huomioimatta, kuinka kumota virheet nopeasti ja helposti, kuinka selata projektisi historiaa ja tarkastella muutoksia pysyvien muutosten välillä sekä kuinka työntää ja vetää etätietolähteistä. +Jos voit lukea vain yhden kappaleen päästäksesi vauhtiin Gitin kanssa, se on tämä kappale. Tämä kappale sisältää jokaisen peruskomennon, jonka tarvitset tehdäksesi valtavan määrän asioita, joiden kanssa viimein tulet käyttämään aikaasi Gitillä työskennellessäsi. Tämän kappaleen lopussa, sinun tulisi pystyä konfiguroimaan ja alustamaan tietolähde, aloittamaan ja lopettamaan tiedostojen jäljitys sekä valmistelemaan ja tehdä pysyviä muutoksia. Me myös näytämme sinulle kuinka asettaa Git niin, että se jättää tietyt tiedostot ja tiedostomallit huomioimatta, kuinka kumota virheet nopeasti ja helposti, kuinka selata projektisi historiaa ja tarkastella muutoksia pysyvien muutosten välillä sekä kuinka työntää ja vetää etätietolähteistä. ## Git-tietolähteen hankinta ## @@ -42,9 +42,9 @@ Gitissä on monta erilaista siirtoprotokollaa, joita voit käyttää. Edellinen Sinulla on oikea Git-tietolähde ja tiedonhaku (checkout) tai työkopio projektin tiedostoista. Sinun täytyy tehdä joitain muutoksia ja pysyviä tilannekuvia näistä muutoksista sinun tietolähteeseesi joka kerta, kun projekti saavuttaa tilan, jonka haluat tallentaa. -Muista, että jokainen tiedosto työhakemistossasi voi olla yhdessä kahdesta tilasta: *jäljitetty* tai *jäljittämätön*. *Jäljitetyt* tiedostot ovat tiedostoja, jotka olivat viimeisimmässä tilannekuvassa; ne voivat olla *muokkaamattomia*, *muokattuja* tai *lavastettuja*. *Jäljittämättömät* tiedostot ovat kaikkea muuta - mitkä tahansa tiedostoja työhakemistossasi, jotka eivät olleet viimeisimmässä tilannekuvassa ja jotka eivät ole lavastusalueella. Kun ensimmäisen kerran kloonaat tietolähteen, kaikki tiedostoistasi tulevat olemaan jäljitettyjä ja muokkaamattomia, koska sinä juuri hait ne etkä ole muokannut vielä mitään. +Muista, että jokainen tiedosto työhakemistossasi voi olla yhdessä kahdesta tilasta: *jäljitetty* tai *jäljittämätön*. *Jäljitetyt* tiedostot ovat tiedostoja, jotka olivat viimeisimmässä tilannekuvassa; ne voivat olla *muokkaamattomia*, *muokattuja* tai *valmisteltuja*. *Jäljittämättömät* tiedostot ovat kaikkea muuta - mitkä tahansa tiedostoja työhakemistossasi, jotka eivät olleet viimeisimmässä tilannekuvassa ja jotka eivät ole valmistelualueella. Kun ensimmäisen kerran kloonaat tietolähteen, kaikki tiedostoistasi tulevat olemaan jäljitettyjä ja muokkaamattomia, koska sinä juuri hait ne etkä ole muokannut vielä mitään. -Editoidessasi tiedostoja Git näkee ne muokattuina, koska olet muuttanut niitä viimeisimmän pysyvän muutoksen jälkeen. *Lavastat* nämä muutetut tiedostot, jonka jälkeen muutat kaikki lavastetut muutokset pysyvästi, ja sykli toistuu. Tämä elämänsykli on kuvattu Kuvassa 2-1. +Editoidessasi tiedostoja Git näkee ne muokattuina, koska olet muuttanut niitä viimeisimmän pysyvän muutoksen jälkeen. *Valmistelet* nämä muutetut tiedostot, jonka jälkeen muutat kaikki valmistellut muutokset pysyvästi, ja sykli toistuu. Tämä elämänsykli on kuvattu Kuvassa 2-1. Insert 18333fig0201.png Kuva 2-1. Tiedostojesi tilan elämänsykli. @@ -78,7 +78,7 @@ Jotta voisit jäljittää uusia tiedostoja, sinun täytyy käyttää `git add` - $ git add README -Jos ajat status-komennon uudestaan, näet että `README`-tiedostosi on nyt jäljitetty ja lavastettu: +Jos ajat status-komennon uudestaan, näet että `README`-tiedostosi on nyt jäljitetty ja valmisteltu: $ git status # On branch master @@ -88,9 +88,9 @@ Jos ajat status-komennon uudestaan, näet että `README`-tiedostosi on nyt jälj # new file: README # -Voit nähdä, että se on lavastettu, koska se on otsikon ”Changes to be committed” alla. Jos teet pysyvän muutoksen tässä kohtaa, versio tiedostosta sillä hetkellä kun ajoit `git add` -komennon on se, joka tulee olemaan historian tilannekuvassa. Voit palauttaa mieleen hetken, jolloin ajoit `git init` -komennon aikaisemmin, ajoit sen jälkeen `git add (tiedostot)` -komennon - tämä komento aloitti tiedostojen jäljittämisen hakemistossa. `Git add` -komento ottaa polun nimen joko tiedostolle tai hakemistolle; jos se on hakemisto, komento lisää kaikki tiedostot hakemiston alta rekursiivisesti. +Voit nähdä, että se on valmisteltu, koska se on otsikon ”Changes to be committed” alla. Jos teet pysyvän muutoksen tässä kohtaa, versio tiedostosta sillä hetkellä kun ajoit `git add` -komennon on se, joka tulee olemaan historian tilannekuvassa. Voit palauttaa mieleen hetken, jolloin ajoit `git init` -komennon aikaisemmin, ajoit sen jälkeen `git add (tiedostot)` -komennon - tämä komento aloitti tiedostojen jäljittämisen hakemistossa. `Git add` -komento ottaa polun nimen joko tiedostolle tai hakemistolle; jos se on hakemisto, komento lisää kaikki tiedostot hakemiston alta rekursiivisesti. -### Muutettujen tiedostojen lavastus ### +### Muutettujen tiedostojen valmistelu ### Muutetaanpa tiedostoa, joka on jo jäljitetty. Jos muutat aikaisemmin jäljitettyä `benchmarks.rb`-tiedostoa ja sen jälkeen ajat `status`-komennon uudestaan, saat suunnilleen tämän näköisen tulosteen: @@ -107,7 +107,7 @@ Muutetaanpa tiedostoa, joka on jo jäljitetty. Jos muutat aikaisemmin jäljitett # modified: benchmarks.rb # -`Benchmarks.rb`-tiedosto näkyy kohdan ”Changes not staged for commit” alla - mikä tarkoittaa, että tiedostoa, jota jäljitetään, on muokattu työskentelyhakemistossa, mutta sitä ei vielä ole lavastettu. Lavastaaksesi sen, ajat `git add` -komennon (se on monitoimikomento - käytät sitä aloittaaksesi uusien tiedostojen jäljittämisen, lavastaaksesi tiedostoja, ja tehdäksesi muita asioita, kuten merkataksesi liitoskonfliktitiedostot ratkaistuksi). Ajetaanpa nyt `git add` -komento lavastaaksemme `benchmarks.rb`-tiedoston, ja ajetaan sitten `git status` -komento uudestaan: +`Benchmarks.rb`-tiedosto näkyy kohdan ”Changes not staged for commit” alla - mikä tarkoittaa, että tiedostoa, jota jäljitetään, on muokattu työskentelyhakemistossa, mutta sitä ei vielä ole valmisteltu. Valmistellaksesi sen, ajat `git add` -komennon (se on monitoimikomento - käytät sitä aloittaaksesi uusien tiedostojen jäljittämisen, valmistellaksesi tiedostoja, ja tehdäksesi muita asioita, kuten merkataksesi liitoskonfliktitiedostot ratkaistuksi). Ajetaanpa nyt `git add` -komento valmistellaksemme `benchmarks.rb`-tiedoston, ja ajetaan sitten `git status` -komento uudestaan: $ git add benchmarks.rb $ git status @@ -119,7 +119,7 @@ Muutetaanpa tiedostoa, joka on jo jäljitetty. Jos muutat aikaisemmin jäljitett # modified: benchmarks.rb # -Kummatkin tiedostot ovat lavastettuja ja tulevat menemään seuraavaan pysyvään muutokseen. Oletetaan, että tässä kohdassa muistat pienen muutoksen, jonka haluat tehdä `benchmarks.rb`-tiedostoon, ennen kuin teet pysyvää muutosta. Avaat tiedoston uudestaan ja muutat sitä, jonka jälkeen olet valmis tekemään pysyvän muutoksen. Ajetaan silti `git status` -komento vielä kerran: +Kummatkin tiedostot ovat valmisteltuja ja tulevat menemään seuraavaan pysyvään muutokseen. Oletetaan, että tässä kohdassa muistat pienen muutoksen, jonka haluat tehdä `benchmarks.rb`-tiedostoon, ennen kuin teet pysyvää muutosta. Avaat tiedoston uudestaan ja muutat sitä, jonka jälkeen olet valmis tekemään pysyvän muutoksen. Ajetaan silti `git status` -komento vielä kerran: $ vim benchmarks.rb $ git status @@ -136,7 +136,7 @@ Kummatkin tiedostot ovat lavastettuja ja tulevat menemään seuraavaan pysyvää # modified: benchmarks.rb # -Mitä ihmettä? Nyt `benchmarks.rb` on listattu sekä lavastettuna että lavastamattomana. Miten se on mahdollista? Tapahtuu niin, että Git lavastaa tiedoston juuri sellaisena kuin se on, kun ajat `git add` -komennon. Jos teet pysyvän muutoksen nyt, `benchmark.rb`-tiedoston versio sillä hetkellä, kun ajoit `git add` -komennon, on se, joka menee tähän pysyvään muutokseen, eikä se tiedoston versio, joka on työskentelyhakemistossasi sillä hetkellä, kun ajat `git commit` -komennon. Jos muutat tiedostoa sen jälkeen, kun olet ajanut `git add` -komennon, sinun täytyy ajaa `git add` uudestaan lavastaaksesi uusimman version tiedostosta: +Mitä ihmettä? Nyt `benchmarks.rb` on listattu sekä valmisteltuna että valmistelemattomana. Miten se on mahdollista? Tapahtuu niin, että Git valmistelee tiedoston juuri sellaisena kuin se on, kun ajat `git add` -komennon. Jos teet pysyvän muutoksen nyt, `benchmark.rb`-tiedoston versio sillä hetkellä, kun ajoit `git add` -komennon, on se, joka menee tähän pysyvään muutokseen, eikä se tiedoston versio, joka on työskentelyhakemistossasi sillä hetkellä, kun ajat `git commit` -komennon. Jos muutat tiedostoa sen jälkeen, kun olet ajanut `git add` -komennon, sinun täytyy ajaa `git add` uudestaan valmistellaksesi uusimman version tiedostosta: $ git add benchmarks.rb $ git status @@ -185,11 +185,11 @@ Tässä toinen esimerkki .gitignore-tiedostosta: `**/`-malli on saatavilla Gitin versiosta 1.8.2 lähtien. -### Lavastettujen ja lavastamattomien muutosten tarkastelu ### +### Valmisteltujen ja valmistelemattomien muutosten tarkastelu ### -Jos `git status` -komento on liian epämääräinen sinulle - haluat tietää tarkalleen mitä on muutettu, et ainoastaan sitä, mitkä tiedostot ovat muuttuneet - voit käyttää `git diff` -komentoa. Me käsittelemme `git diff` -kommenon yksityiskohtaisesti myöhemmin; mutta sinä tulet mahdollisesti käyttämään sitä useasti, vastataksesi näihin kahteen kysymykseen: Mitä olet muuttanut, mutta et ole vielä lavastanut? Ja mitä sellaista olet lavastanut, josta olet tekemässä pysyvän muutoksen? Vaikkakin `git status` vastaa näihin kysymyksiin yleisesti, `git diff` näyttää sinulle tarkalleen ne rivit, jotka on lisätty ja poistettu - vähän niin kuin pätsi. +Jos `git status` -komento on liian epämääräinen sinulle - haluat tietää tarkalleen mitä on muutettu, et ainoastaan sitä, mitkä tiedostot ovat muuttuneet - voit käyttää `git diff` -komentoa. Me käsittelemme `git diff` -kommenon yksityiskohtaisesti myöhemmin; mutta sinä tulet mahdollisesti käyttämään sitä useasti, vastataksesi näihin kahteen kysymykseen: Mitä olet muuttanut, mutta et ole vielä valmistellut? Ja mitä sellaista olet valmistellut, josta olet tekemässä pysyvän muutoksen? Vaikkakin `git status` vastaa näihin kysymyksiin yleisesti, `git diff` näyttää sinulle tarkalleen ne rivit, jotka on lisätty ja poistettu - vähän niin kuin pätsi. -Sanotaan vaikka, että muokkaat ja lavastat `README`-tiedostoa uudestaan, jonka jälkeen muokkaat `benchmarks.rb`-tiedostoa, ilman että lavastat sitä. Jos ajat `status`-komennon, näet jälleen kerran jotain tällaista: +Sanotaan vaikka, että muokkaat ja valmistelet `README`-tiedostoa uudestaan, jonka jälkeen muokkaat `benchmarks.rb`-tiedostoa, ilman että valmistelet sitä. Jos ajat `status`-komennon, näet jälleen kerran jotain tällaista: $ git status # On branch master @@ -204,7 +204,7 @@ Sanotaan vaikka, että muokkaat ja lavastat `README`-tiedostoa uudestaan, jonka # modified: benchmarks.rb # -Nähdäksesi, mitä olet muuttanut, mutta et vielä lavastanut, kirjoita `git diff` ilman mitään muita argumentteja: +Nähdäksesi, mitä olet muuttanut, mutta et vielä valmistellut, kirjoita `git diff` ilman mitään muita argumentteja: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -223,9 +223,9 @@ Nähdäksesi, mitä olet muuttanut, mutta et vielä lavastanut, kirjoita `git di log = git.commits('master', 15) log.size -Tämä komento vertailee sitä, mitä sinun työskentelyhakemistossa on verrattuna siihen, mitä sinun lavastusalueellasi on. Tulos kertoo tekemäsi muutokset, joita et ole vielä lavastanut. +Tämä komento vertailee sitä, mitä sinun työskentelyhakemistossa on verrattuna siihen, mitä sinun valmistelualueellasi on. Tulos kertoo tekemäsi muutokset, joita et ole vielä valmistellut. -Jos haluat nähdä, mitä sellaista olet lavastanut, joka menee seuraavaan pysyvään muutokseen, voit käyttää `git diff --cached` -komentoa. (Gitin versiosta 1.6.1 lähtien voit käyttää myös `git diff --staged` -komentoa, joka on helpompi muistaa.) Tämä komento vertailee lavastettuja muutoksia viimeisimpään pysyvään muutokseen. +Jos haluat nähdä, mitä sellaista olet valmistellut, joka menee seuraavaan pysyvään muutokseen, voit käyttää `git diff --cached` -komentoa. (Gitin versiosta 1.6.1 lähtien voit käyttää myös `git diff --staged` -komentoa, joka on helpompi muistaa.) Tämä komento vertailee valmisteltuja muutoksia viimeisimpään pysyvään muutokseen. $ git diff --cached diff --git a/README b/README @@ -240,9 +240,9 @@ Jos haluat nähdä, mitä sellaista olet lavastanut, joka menee seuraavaan pysyv + +Grit is a Ruby library for extracting information from a Git repository -On tärkeää ottaa huomioon, että `git diff` itsessään ei näytä kaikkia muutoksia viimeisimmästä pysyvästä muutoksesta lähtien - vain muutokset, jotka ovat yhä lavastamattomia. Tämä voi olla sekavaa, koska kun olet lavastanut kaikki muutoksesi, `git diff` ei anna ollenkaan tulostetta. +On tärkeää ottaa huomioon, että `git diff` itsessään ei näytä kaikkia muutoksia viimeisimmästä pysyvästä muutoksesta lähtien - vain muutokset, jotka ovat yhä valmistelemattomia. Tämä voi olla sekavaa, koska kun olet valmistellut kaikki muutoksesi, `git diff` ei anna ollenkaan tulostetta. -Toisena esimerkkinä, jos lavastat `benchmarks.rb`-tiedoston ja sitten muokkaat sitä, voit käyttää `git diff` -komentoa nähdäksesi tiedoston lavastetut muutokset ja lavastamattomat muutokset: +Toisena esimerkkinä, jos valmistelet `benchmarks.rb`-tiedoston ja sitten muokkaat sitä, voit käyttää `git diff` -komentoa nähdäksesi tiedoston valmistellut muutokset ja valmistelemattomat muutokset: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb @@ -258,7 +258,7 @@ Toisena esimerkkinä, jos lavastat `benchmarks.rb`-tiedoston ja sitten muokkaat # modified: benchmarks.rb # -Nyt voit käyttää `git diff` -komentoa nähdäksesi, mitä on yhä lavastamatta: +Nyt voit käyttää `git diff` -komentoa nähdäksesi, mitä on yhä valmistelematta: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -271,7 +271,7 @@ Nyt voit käyttää `git diff` -komentoa nähdäksesi, mitä on yhä lavastamatt ##pp Grit::GitRuby.cache_client.stats +# test line -Ja `git diff --cached` -komentoa nähdäksesi, mitä olet lavastanut tähän mennessä: +Ja `git diff --cached` -komentoa nähdäksesi, mitä olet valmistellut tähän mennessä: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb @@ -292,8 +292,8 @@ Ja `git diff --cached` -komentoa nähdäksesi, mitä olet lavastanut tähän men ### Pysyvien muutoksien tekeminen ### -Nyt, kun lavastusalueesi on asetettu niin kuin sen haluat, voit tehdä muutoksistasi pysyviä. Muista, että kaikki, mikä vielä on lavastamatta - mitkä tahansa tiedostot, jotka olet luonut tai joita olet muokannut, joihin et ole ajanut `git add` -komentoa editoinnin jälkeen - eivät mene pysyvään muutokseen. Ne pysyvät muokattuina tiedostoina levylläsi. -Tässä tapauksessa oletamme, että viime kerran, kun ajoit `git status` -komennon, näit, että kaikki oli lavastettu, joten olet valmis tekemään pysyvän muutoksen. Helpoin tapa pysyvän muutoksen tekoon on kirjoittaa `git commit`: +Nyt, kun valmistelualueesi on asetettu niin kuin sen haluat, voit tehdä muutoksistasi pysyviä. Muista, että kaikki, mikä vielä on valmistelematta - mitkä tahansa tiedostot, jotka olet luonut tai joita olet muokannut, joihin et ole ajanut `git add` -komentoa editoinnin jälkeen - eivät mene pysyvään muutokseen. Ne pysyvät muokattuina tiedostoina levylläsi. +Tässä tapauksessa oletamme, että viime kerran, kun ajoit `git status` -komennon, näit, että kaikki oli valmisteltu, joten olet valmis tekemään pysyvän muutoksen. Helpoin tapa pysyvän muutoksen tekoon on kirjoittaa `git commit`: $ git commit @@ -325,11 +325,11 @@ Vaihtoehtoisesti, voit kirjoittaa pysyvän muutoksen viestin suoraan `commit`-ko Nyt olet luonut ensimmäisen pysyvän muutoksen! Voit nähdä, että pysyvä muutos on antanut sinulle tulosteen itsestään: kertoen mihin haaraan teit pysyvän muutoksen (`master`), mikä SHA-1 tarkistussumma pysyvällä muutoksella on (`463dc4f`), kuinka monta tiedostoa muutettiin ja tilastoja pysyvän muutoksen rivien lisäyksistä ja poistoista. -Muista, että pysyvä muutos tallentaa tilannekuvan lavastusalueestasi. Kaikki, mitä et lavastanut on yhä istumassa projektissasi muokattuna; voit tehdä toisen pysyvän muutoksen lisätäksesi ne historiaasi. Joka kerta, kun teet pysyvän muutoksen, olet tallentamassa tilannekuvaa projektistasi. Tilannekuvaa, johon voit palata tai jota voit vertailla myöhemmin. +Muista, että pysyvä muutos tallentaa tilannekuvan valmistelualueestasi. Kaikki, mitä et valmistellut on yhä istumassa projektissasi muokattuna; voit tehdä toisen pysyvän muutoksen lisätäksesi ne historiaasi. Joka kerta, kun teet pysyvän muutoksen, olet tallentamassa tilannekuvaa projektistasi. Tilannekuvaa, johon voit palata tai jota voit vertailla myöhemmin. -### Lavastusalueen ohittaminen ### +### Valmistelualueen ohittaminen ### -Vaikka lavastusalue voi olla uskomattoman hyödyllinen pysyvien muutoksien tekoon tarkalleen niin kuin ne haluat, on lavastusalue joskus hieman liian monimutkainen, kuin mitä työnkulussasi tarvitsisit. Jos haluat ohittaa lavastusalueen, Git tarjoaa siihen helpon oikoreitin. Antamalla `-a`-option `git commit` -komennolle, asettaa Gitin automaattisesti lavastamaan jokaisen jo jäljitetyn tiedoston ennen pysyvää muutosta, antaen sinun ohittaa `git add` -osan: +Vaikka valmistelualue voi olla uskomattoman hyödyllinen pysyvien muutoksien tekoon tarkalleen niin kuin ne haluat, on valmistelualue joskus hieman liian monimutkainen, kuin mitä työnkulussasi tarvitsisit. Jos haluat ohittaa valmistelualueen, Git tarjoaa siihen helpon oikoreitin. Antamalla `-a`-option `git commit` -komennolle, asettaa Gitin automaattisesti valmistelemaan jokaisen jo jäljitetyn tiedoston ennen pysyvää muutosta, antaen sinun ohittaa `git add` -osan: $ git status # On branch master @@ -346,9 +346,9 @@ Huomaa, miten sinun ei tarvitse ajaa `git add` -komentoa `benchmarks.rb`-tiedost ### Tiedostojen poistaminen ### -Poistaaksesi tiedoston Gitistä, sinun täytyy poistaa se sinun jäljitetyistä tiedostoistasi (tarkemmin sanoen, poistaa se lavastusalueeltasi) ja sitten tehdä pysyvä muutos. Komento `git rm` tekee tämän ja myös poistaa tiedoston työskentelyhakemistostasi, joten et näe sitä enää jäljittämättömänä tiedostona. +Poistaaksesi tiedoston Gitistä, sinun täytyy poistaa se sinun jäljitetyistä tiedostoistasi (tarkemmin sanoen, poistaa se valmistelualueeltasi) ja sitten tehdä pysyvä muutos. Komento `git rm` tekee tämän ja myös poistaa tiedoston työskentelyhakemistostasi, joten et näe sitä enää jäljittämättömänä tiedostona. -Jos yksinkertaisesti poistat tiedoston työskentelyhakemistostasi, näkyy se ”Changes not staged for commit” otsikon alla (se on, _lavastamaton_) `git status` -tulosteessasi: +Jos yksinkertaisesti poistat tiedoston työskentelyhakemistostasi, näkyy se ”Changes not staged for commit” otsikon alla (se on, _valmistelematon_) `git status` -tulosteessasi: $ rm grit.gemspec $ git status @@ -360,7 +360,7 @@ Jos yksinkertaisesti poistat tiedoston työskentelyhakemistostasi, näkyy se ” # deleted: grit.gemspec # -Jos ajat tämän jälkeen `git rm` -komennon, se lavastaa tiedostot poistoon: +Jos ajat tämän jälkeen `git rm` -komennon, se valmistelee tiedostot poistoon: $ git rm grit.gemspec rm 'grit.gemspec' @@ -375,7 +375,7 @@ Jos ajat tämän jälkeen `git rm` -komennon, se lavastaa tiedostot poistoon: Seuraavan kerran, kun teet pysyvän muutoksen, tiedosto katoaa ja sitä ei jäljitetä enää. Jos muokkasit tiedostoa ja lisäsit sen jo indeksiin, täytyy sinun pakottaa poisto `-f`-optiolla. Tämä on turvallisuusominaisuus, joka estää vahingossa tapahtuvan datan poistamisen, datan, jota ei ole vielä tallennettu tilannekuvaksi ja jota ei voida palauttaa Gitistä. -Toinen hyödyllinen asia, jonka saatat haluta tehdä, on tiedoston pitäminen työskentelypuussa, mutta samalla sen poistaminen lavastusalueelta. Toisin sanoen, voit haluta pitää tiedoston kovalevylläsi, mutta et halua, että Git jäljittää sitä enää. Tämä on erityisesti hyödyllinen, jos unohdit lisätä jotain `.gitignore`-tiedostoosi ja vahingossa lavastit sellaisen, kuten suuri lokitiedosto tai joukko `.a`-muotoon käännettyjä tiedostoja. Tehdäksesi tämän, käytä `--cached`-optiota: +Toinen hyödyllinen asia, jonka saatat haluta tehdä, on tiedoston pitäminen työskentelypuussa, mutta samalla sen poistaminen valmistelualueelta. Toisin sanoen, voit haluta pitää tiedoston kovalevylläsi, mutta et halua, että Git jäljittää sitä enää. Tämä on erityisesti hyödyllinen, jos unohdit lisätä jotain `.gitignore`-tiedostoosi ja vahingossa valmistelit sellaisen, kuten suuri lokitiedosto tai joukko `.a`-muotoon käännettyjä tiedostoja. Tehdäksesi tämän, käytä `--cached`-optiota: $ git rm --cached readme.txt @@ -682,11 +682,11 @@ Yksi yleinen kumoaminen tapahtuu, kun teet pysyvän muutoksen liian aikaisin ja $ git commit --amend -Tämä komento ottaa lavastusalueesi ja käyttää sitä pysyvään muutokseen. Jos et ole tehnyt muutoksia viimeisimmän pysyvän muutoksesi jälkeen (esimerkiksi, jos ajat tämän komennon heti edellisen pysyvän muutoksesi jälkeen), tilannekuvasi näyttää tarkalleen samalta ja kaikki, mitä muutat, on pysyvän muutoksesi viesti. +Tämä komento ottaa valmistelualueesi ja käyttää sitä pysyvään muutokseen. Jos et ole tehnyt muutoksia viimeisimmän pysyvän muutoksesi jälkeen (esimerkiksi, jos ajat tämän komennon heti edellisen pysyvän muutoksesi jälkeen), tilannekuvasi näyttää tarkalleen samalta ja kaikki, mitä muutat, on pysyvän muutoksesi viesti. Sama pysyvän muutoksen viestin editori aktivoituu, mutta se sisältää jo viestin edellisestä pysyvästä muutoksesta. Voit muokata viestiä samoin kuin aina, mutta se korvaa edellisen pysyvän muutoksesi. -Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi lavastaa muutokset tiedostossa, jonka haluat lisätä tähän pysyvään muutokseen, voit tehdä jotakuinkin seuraavasti: +Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi valmistelee muutokset tiedostossa, jonka haluat lisätä tähän pysyvään muutokseen, voit tehdä jotakuinkin seuraavasti: $ git commit -m 'initial commit' $ git add unohtunut_tiedosto @@ -694,9 +694,9 @@ Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi lavastaa Näiden kolmen komennon jälkeen päädyt yhteen pysyvään muutokseen — toinen pysyvä muutos korvaa ensimmäisen. -### Lavastetun tiedoston lavastuksen purkaminen ### +### Valmistellun tiedoston valmistelun purkaminen ### -Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia lavastusalueellasi ja työskentelyhakemistossasi. Mukava osa on, että komento, jota käytät selvittääksesi näiden kahden alueen tilan, muistuttaa sinua myös, kuinka peruuttaa muutokset niihin. Sanokaamme, esimerkiksi, että olet muuttanut kahta tiedostoa ja haluat tehdä niistä kaksi erillistä pysyvää muutosta, mutta kirjoitit vahingossa `git add *` ja lavastit ne molemmat. Kuinka voit purkaa toisen lavastuksen? `Git status` -komento muistuttaa sinua: +Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia valmistelualueellasi ja työskentelyhakemistossasi. Mukava osa on, että komento, jota käytät selvittääksesi näiden kahden alueen tilan, muistuttaa sinua myös, kuinka peruuttaa muutokset niihin. Sanokaamme, esimerkiksi, että olet muuttanut kahta tiedostoa ja haluat tehdä niistä kaksi erillistä pysyvää muutosta, mutta kirjoitit vahingossa `git add *` ja valmistelit ne molemmat. Kuinka voit purkaa toisen valmistelun? `Git status` -komento muistuttaa sinua: $ git add . $ git status @@ -708,7 +708,7 @@ Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia lavastu # modified: benchmarks.rb # -Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD ...` to unstage". Joten, käyttäkäämme tätä neuvoa purkaaksemme `benchmarks.rb`-tiedoston lavastuksen: +Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD ...` to unstage". Joten, käyttäkäämme tätä neuvoa purkaaksemme `benchmarks.rb`-tiedoston valmistelun: $ git reset HEAD benchmarks.rb benchmarks.rb: locally modified @@ -726,11 +726,11 @@ Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD # modified: benchmarks.rb # -Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muokattu mutta lavastamaton jälleen. +Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muokattu mutta valmistelematon jälleen. ### Muutetun tiedoston muutosten kumoaminen ### -Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Edellisessä esimerkkitulosteessa lavastamaton alue näyttää tältä: +Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Edellisessä esimerkkitulosteessa valmistelematon alue näyttää tältä: # Changes not staged for commit: # (use "git add ..." to update what will be committed) diff --git a/fi/NOTES b/fi/NOTES index fef3c2fe5..84cb89f3c 100644 --- a/fi/NOTES +++ b/fi/NOTES @@ -1,4 +1,5 @@ Chapter 1 - Line 56: What is a proper finnish translation for the word "snapshot" in this case? Translated now as 'tilannekuvat'. Multiline: What is a proper finnish translation for the word "commit" in this case? Or do we need it, is permanen change (like it is now) enought to tell what it is about? - Chapter "The Three Stages" ("Kolme tilaa") has mentioned the "staged" word, what is correct translation for this in finnish? Now translated as "lavastettu". + Chapter "The Three Stages" ("Kolme tilaa") has mentioned the "staged" word, what is correct translation for this in finnish? Was translated as "lavastettu". + -> "lavastettu" is an obvious but bad choice, because it's based on another meaning of "stage", not the one that Git uses. Now translated as "valmisteltu". Line 230: Translation for a word "Backports" From de335675711b41e4b9d1e5f2f339b9f81d3d3a26 Mon Sep 17 00:00:00 2001 From: "P. Tamami" Date: Mon, 15 Sep 2014 16:12:59 +0700 Subject: [PATCH 230/291] Update 01-chapter3.markdown update in a few paragraph at Basic Branching. --- id/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown index 13bb0bf7b..0595c1a6b 100644 --- a/id/03-git-branching/01-chapter3.markdown +++ b/id/03-git-branching/01-chapter3.markdown @@ -137,7 +137,7 @@ Anda bekerja di jejaring *website* dan melakukan beberapa *commits*. Dengan mela Insert 18333fig0312.png Gambar 3-12. Cabang iss53 telah bergerak kedepan sesuai pekerjaan anda. -Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch. +Lalu kemudian, saat kita melihat ada permasalahan dalam situs jejaring, dan kita perlu untuk memperbaikinya segera. Dengan Git, anda tidak perlu memasang pembetulannya bersama dengan perubahan di `iss53`, dan anda tidak perlu melakukan cara yang sulit untuk kembali ke pekerjaan anda sebelumnya di tahap produksi. Yang anda perlukan hanya kembali ke pencabangan *master*. However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch: From 1caee30dd15edb93d6abad3fc4f9c7c485b46f85 Mon Sep 17 00:00:00 2001 From: "P. Tamami" Date: Tue, 16 Sep 2014 15:46:52 +0700 Subject: [PATCH 231/291] Update 01-chapter3.markdown Translate just one paragraph in Basic Branching --- id/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown index 0595c1a6b..ff4bd8c44 100644 --- a/id/03-git-branching/01-chapter3.markdown +++ b/id/03-git-branching/01-chapter3.markdown @@ -139,7 +139,7 @@ Gambar 3-12. Cabang iss53 telah bergerak kedepan sesuai pekerjaan anda. Lalu kemudian, saat kita melihat ada permasalahan dalam situs jejaring, dan kita perlu untuk memperbaikinya segera. Dengan Git, anda tidak perlu memasang pembetulannya bersama dengan perubahan di `iss53`, dan anda tidak perlu melakukan cara yang sulit untuk kembali ke pekerjaan anda sebelumnya di tahap produksi. Yang anda perlukan hanya kembali ke pencabangan *master*. -However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch: +Bagaimanapun, sebelum anda melakukannya, perhatikan bahwa jika dalam kandar kerja anda atau kondisi *staging* memiliki perubahan yang bertentangan dengan pencabangan yang akan anda tinggalkan, Git tidak akan memperbolehkan anda berpindah. Ini adalah cara terbaik untuk meninggalkan pekerjaan dalam keadaan bersih ketika anda akan berpindah pencabangan. Ada beberapa cara untuk melakukan ini (*namely*, *stashing*, dan merubah *commit*) yang akan kita bahas berikutnya. Untuk saat ini, anda telah *commit* seluruh perubahan, sehingga anda dapat kembali ke pencabangan *master*: $ git checkout master Switched to branch "master" From ef7acd6bc7dcae1b2b4c90e3f572c27e74aac1d6 Mon Sep 17 00:00:00 2001 From: Maro Shim Date: Wed, 17 Sep 2014 13:18:35 +0900 Subject: [PATCH 232/291] Update 01-chapter2.markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "마지막으로 커밋한 후에 수정한 것들 전부를 보여주지 않는다." all changes made since your last commit의 번역입니다. 읽다가 조금 이해가 잘 안되어서 원문을 참조했습니다. --- ko/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown index 61764f4ab..da62f4c31 100644 --- a/ko/02-git-basics/01-chapter2.markdown +++ b/ko/02-git-basics/01-chapter2.markdown @@ -243,7 +243,7 @@ README 파일을 수정해서 Staged 상태로 만들고 benchmarks.rb 파일은 + +Grit is a Ruby library for extracting information from a Git repository -꼭 잊지 말아야 할 것이 있는데 `git diff` 명령은 마지막으로 커밋한 후에 수정한 것을 보여주지 않는다. `git diff`는 Unstaged 상태인 것들만 보여준다. 이 부분이 조금 헷갈릴 수 있다. 수정한 파일을 모두 Staging Area에 넣었다면 `git diff` 명령은 아무것도 출력하지 않는다. +꼭 잊지 말아야 할 것이 있는데 `git diff` 명령은 마지막으로 커밋한 후에 수정한 것들 전부를 보여주지 않는다. `git diff`는 Unstaged 상태인 것들만 보여준다. 이 부분이 조금 헷갈릴 수 있다. 수정한 파일을 모두 Staging Area에 넣었다면 `git diff` 명령은 아무것도 출력하지 않는다. benchmarks.rb 파일을 Stage한 후에 다시 수정해도 `git diff` 명령을 사용할 수 있다. 이때는 Staged 상태인 것과 Unstaged 상태인 것을 비교한다: From 81376e39662b5850272420f6637b7a4773e6a029 Mon Sep 17 00:00:00 2001 From: "P. Tamami" Date: Sun, 21 Sep 2014 09:57:08 +0700 Subject: [PATCH 233/291] Update 01-chapter3.markdown update 1 (one) paragraph --- id/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown index ff4bd8c44..8c9184375 100644 --- a/id/03-git-branching/01-chapter3.markdown +++ b/id/03-git-branching/01-chapter3.markdown @@ -144,7 +144,7 @@ Bagaimanapun, sebelum anda melakukannya, perhatikan bahwa jika dalam kandar kerj $ git checkout master Switched to branch "master" -At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. +Saat ini, anda berada dalam kandar kerja dalam kondisi tepat seperti anda belum mengerjakan masalah #53, dan anda dapat konsentrasi mengerjakan perbaikannya. Hal yang perlu diingat adalah: Git mengkondisikan kandar kerja anda agar terlihat sebagaimana anda kembali ke titik pencabangan yang anda tuju. Git menambahkan, menghapus, dan mengubah berkas secara otomatis untuk memastikan bahwa anda bekerja pada pencabangan terakhir yang anda *commit*. Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13): From 1827b5ef76d31602e6969d03e90786dd0877c36c Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Tue, 23 Sep 2014 03:18:26 +0300 Subject: [PATCH 234/291] [ar] translating and --- ar/02-git-basics/01-chapter2.markdown | 37 +++++++++++++-------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index da77fdd39..89e6b9ae2 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -183,9 +183,10 @@ Insert 18333fig0201.png ### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ### -If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. +إذا لم تكتف بالمعلومات التي يقدمها لك أمر `git status` يمكنك استخدام أمر `git diff` للحصول على معلومات تفصيلية حول التغيرات التي طرأت على الملفات. سنقوم لاحقاً بالتعمق في هذا الأمر، لكن الآن سنكتفي بالإشارة إلى الاستخدامات الغالبة له؛ حيث أنك ستستخدمه غالباً للحصول على أجوبة على هذين السؤالين: ما الذي قمنا بالتعديل عليه ولم نجهزه بعد لعملية commit؟ ما الملفات التي أصبحت جاهزة للدخول في عملية commit المقبلة؟ +بالرغم من أنه يمكننا أن نحصل على هذه المعلومات باستخدام أمر `git status` إلا أنّ أمر `git diff` يوضح لنا التغيرات التي جرت على مستوى السطر والحرف - ما الذي قمنا بإضافته وما الذي أزلناه! -Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this: +لنقل أنك قمت بالتعديل على ملف README مرة أخرى وأشرته للإضافة إلى عملية commit وقمت بالتعديل على ملف benchmarks.rb ولم تضفه إلى قائمة الملفات الجاهزة لعملية commit؛ إذا قمت بتنفيذ الأمر `status` ستشاهد مرة أخرى شيئاً من الشكل: $ git status # On branch master @@ -200,7 +201,7 @@ Let’s say you edit and stage the README file again and then edit the benchmark # modified: benchmarks.rb # -To see what you’ve changed but not yet staged, type `git diff` with no other arguments: +لترى ما قمت بالتعديل عليه ولم تجهزه للإضافة نفذ الأمر `git diff` بدون إضافات: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -219,9 +220,9 @@ To see what you’ve changed but not yet staged, type `git diff` with no other a log = git.commits('master', 15) log.size -That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged. +يقوم هذا الأمر بعمل مقارنة بين الملفات ضمن مجلد العمل والملفات الموجودة في منطقة التعديلات المجهزة للإضافة staging area. وتخبرنا نتيجته بالتعديلات التي أجريناها ولم نقم بتجهيزها للإضافة إلى عملية commit المقبلة. -If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit: +لمشاهدة الملفات ذات الحالة staged والتي ستدخل في عملية commit المقبلة، يمكن استخدام الأمر `git diff --cached` (بالنسبة للإصدارات 1.6.1 وما بعد من git يمكنك أيضاً استخدام الأمر `git diff --staged` )، كالتالي: $ git diff --cached diff --git a/README b/README @@ -236,9 +237,9 @@ If you want to see what you’ve staged that will go into your next commit, you + +Grit is a Ruby library for extracting information from a Git repository -It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output. +من الجدير بالذكر أن أمر `git diff` لوحده لا يقوم بعرض جميع التعديلات التي تمت من آخر commit - فهو يقوم بعرض فقط التعديلات التي لم تؤشر على أنها staged. ويمكن أن يسبب ذلك بعض الإرباك، حيث أنك إذا قمت بإضافة جميع التعديلات إلى قائمة staged فلن يقوم بعرض أي شي في خرج تنفيذه. -For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged: +كمثال أيضاً، إذا قمنا بإضافة benchmarks.rb إلى قائمة staged ومن ثم قمنا بالتعديل عليه من جديد، يمكننا استخدام أمر `git diff` للحصول على لائحة بالتغييرات التي حصلت ولم تضف إلى قائمة staged كالتالي: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb @@ -254,7 +255,6 @@ For another example, if you stage the benchmarks.rb file and then edit it, you c # modified: benchmarks.rb # -Now you can use `git diff` to see what is still unstaged $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -267,7 +267,7 @@ Now you can use `git diff` to see what is still unstaged ##pp Grit::GitRuby.cache_client.stats +# test line -and `git diff --cached` to see what you’ve staged so far: +وباستخدام `git diff --cached` نتمكن من رؤية ما تم تجهيزه للإضافة إلى عملية commit القادمة: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb @@ -286,16 +286,15 @@ and `git diff --cached` to see what you’ve staged so far: log = git.commits('master', 15) log.size -### Committing Your Changes ### +### القيام بعملية (اعتماد) commit للتغيّرات ### -Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk. -In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`: +بعد اكمال تجهيز الملفات التي ترغب بإضافتها إلى النسخة snapshot الجديدة، يمكنك تنفيذ أمر commit ليتم اعتماد التعديلات التي أجريتها في سجل git. تذكر أنّ أي ملف لم يتم تجهيزه - سواء لم تقم بإضافته باستخدام الأمر git add بعد إنشاءه أو التعديل عليه - لن يدخل في هذه الإعتمادية، وستبقى على أنها ملفات تم تعديلها في مجلد العمل. أبسط طريقة لاعتماد التعديلات هي القيام بأمر `git commit` كالتالي: $ git commit -Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). +تنفيذ هذا الأمر سيطلب منا إدخال رسالة عملية commit - عادة ما يتم فتح محرر النصوص المشار إليه بمتغير البيئة `$EDITOR`. يمكنك تهيئته عن طريق الأمر `git config --global core.editor` كما شاهدنا في الفصل الأول. -The editor displays the following text (this example is a Vim screen): +يقوم محرر النصوص بعرض هذه الشاشة (مثالنا باستخدام VIM): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. @@ -310,20 +309,20 @@ The editor displays the following text (this example is a Vim screen): ~ ".git/COMMIT_EDITMSG" 10L, 283C -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +يمكنك ملاحظة أن رسالة عملية commit تحوي على خرج آخر عملية `git status` على شكل تعليقات بالإضافة إلى سطر فارغ في بداية الملف. يمكنك إزالة هذه التعليقات، أو يمكنك تركها لمساعدتك بتذكر ما قمت باعتماد تعديلاته. يمكنك الحصول على معلومات أكثر تفصلياً إذا قمت بتمرير الخيار `-v` إلى الأمر `git commit`. حيث يقوم ذلك بإضافة خرج أمر `git diff` إلى رسالة commit على شكل تعليقات أيضاً. عند إغلاق المحرر يقوم git بإنشاء commit ويتجاهل التعليقات. -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +علماً أنّه يمكنك كتابة رسالة الاعتمادية مباشرة من خلال تمرير الخيار `-m` إلى الأمر `git commit` على الشكل التالي: $ git commit -m "Story 182: Fix benchmarks for speed" [master]: created 463dc4f: "Fix benchmarks for speed" 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 README -Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +مبروك، لقد قمت بعمل أول commit لك! يعطيك خرج العملية معلومات عنها: في أي فرع branch تم الإعتماد (هنا master)، ما قيمة هاش SHA-1 الخاصة بالعملية ( هنا `463dc4f`)، عدد الملفات التي تغيّرت، بالإضافة إلى إحصاءات حول الأسطر التي أضيفت وأزيلت في هذه العملية. -Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later. +تذكر أنّ عملية commit تأخذ صورة عن الملفات في قائمة staged. أي شيء لم تقم بإضافته إلى هذه القائمة ما زال في مجلد العمل بحالة "معدل" modified؛ يمكنك القيام بإضافتهم من خلال عملية commit جديدة إلى التأريخ في git. نستنتج أنّه في كل عملية commit يقوم git بأخذ "صورة" snapshot عن المشروع يمكننا العودة لها لاحقاً أو مقارنتها أو غير ذلك.. -### Skipping the Staging Area ### +### تجاوز منطقة التجهيز Staging Area ### Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: From 35636c0d6b2956a2696e650fac821409d09ae36e Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Sun, 7 Sep 2014 01:11:26 +0300 Subject: [PATCH 235/291] [ar] translating file editing, checking status, tracking new files, staging modified files, ignoring files --- ar/02-git-basics/01-chapter2.markdown | 61 +++++++++++++-------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 0bea0227d..da77fdd39 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -1,4 +1,4 @@ -# مبادئ Git # +# مبادئ Git # إذا كان هناك فصل واحد عليك قراءته لكي تبدأ بإستخدام Git، فعليك بهذا الفصل! يغطي هذا الفصل جميع الأوامر الأساسية التي عليك معرفتها لكي تتمكن من القيام بأغلب الأمور أثناء استخدامك لـ Git. في نهاية هذا الفصل يجب أن تكون قادراً على انشاء واعداد الـ repository لمشروعك وعلى تحديد الملفات التي ستتم متابعتها والتي ستترك، وعلى تهييئ التغييرات لعمل commit عليها. ستتعلم أيضاً كيف تعد Git لكي تتجاهل بعض أنواع الملفات، كيف تقوم بالتراجع عن الأخطاء التي سترتكبها بسرعة وبسهولة، كيف تتصفح تاريخ مشروعك وكيف تعرض التغيرات بين الـ commits، وكيف تنشر وتسحب (push & pull) التغيرات من الـ repositories البعيدة عنك. @@ -40,27 +40,26 @@ هناك عدد من البروتوكولات المختلفة التي يمكنك اسستعمالها لنقل المعلومات في git. المثال السابق يستعمل بروتوكول 'git://'، ولكن من الممكن أن تجد أيضاً استخداماً لـ 'http(s)://' أو 'user@server:/path.git'، والتي تستعمل بروتوكول SSH في النقل. في الفصل الرابع من الكتاب ستتعرف على الخيارات المتوفرة للتواصل مع الـ repository الخاصة بك وميزات ومساوئ كل منها. ## تسجيل التعديلات في الـ repository ## +لديك repository أصلي ونسخة لتعمل عليها من ملفات المشروع. عليك أن تقوم ببعض التعديلات ثم تعمل commit لهذه التعديلات في repository الخاص بك في كل مرة يصل فيها المشروع إلى نقطة تود تسجيلها. -You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +تذكر أنه كل ملف في مجلد العمل يمكن أن يكون في إحدى الحالتين فقط: مٌتَتَبّع tracked أو غير مٌتَتَبّع untracked. الملفات المٌتتبّعة هي ملفات كانت في أخر snapshot ويمكن إلغاء التعديلات عليها أو التعديل عليها أو وضعه في حالة staged (جاهز من أجل commit). الملفات غير المُتتبّعة هي كل الملفات الآخرى - أي ملف في مجلد العمل لم يكن موجوداً في آخر snapshot وليس معلماً بأنه staged. عندما تقوم باستنساخ repository جميع ملفاتك تكون بحالة متتبّعة tracked و غير معدلة unmodified لأنك قمت للتو بعمل check out ولم تقم بأي تعديل. -Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. - -As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1. +عندما تعدل الملفات، سيقوم git بتأشيرهم على أنهم modified، لأنك قمت بتغيرهم عن آخر commit. تقوم بعمل stage لهذه الملفات المعدلة ثم تقوم بعمل commit لجميع التغيرات في منطقة stage، وتتكرر العملية. يوضع الشكل 2-1 دورة العملية. Insert 18333fig0201.png -Figure 2-1. The lifecycle of the status of your files. +الشكل 2-1. دورة حالة الملفات. -### Checking the Status of Your Files ### +### تفقد حالة ملفاتك ### -The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this: +باستخدام الأمر git status يمكننا معرفة حالة الملفات لدينا. إذا قمت بتشغيل هذا الأمر مباشرة بعد قيامك بعمل clone يجب أن ترى شيئاً يشبه التالي: $ git status # On branch master nothing to commit, working directory clean -This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. +وهذا يعني أنه لديك مجلد عمل نظيف - بمعنى آخر، لايوجد أي ملفات معدلة أو ملفات غير مُتتبّعة. كما أنّ هذا الأمر يخبرك بأي فرع branch أنت تعمل. حالياً، دائماً هو master، وهو الافتراضي؛ في الفصل المقبل سنمر على الأفرع و المرجعيات references بالتفصيل. -Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so: +لنقل بأنك قمت بإضافة ملف جديد على مشروعك، وليكن ملف README بسيط. إذا لم يكن الملف موجوداً مسبقاً، وقمت بتنفيذ الأمر `git status` سترى الملف غير مُتتبّعاً كما يلي: $ vim README $ git status @@ -71,15 +70,15 @@ Let’s say you add a new file to your project, a simple README file. If the fil # README nothing added to commit but untracked files present (use "git add" to track) -You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file. +يمكنك ملاحظة أنّ ملفك الجديد README غير مُتتبّع، فهو تحت تبويب "untracked files" في خرج الأمر. ويعني ذلك أنّ git يرى ملفاً جديداً على commit السابقة؛ علماً أنّ git لن يقوم بإضافة هذا الملف إلى الملفات المتتبعة إلا إذا قمت بطلب ذلك بشكل مباشر، والهدف من ذلك من أجل حماية المشروع من الضم الخاطئ لملفات binary أو أي ملفات لا تود بإضافتها. إلاّ أنّك ترغب في إضافة README إلى الملفات المتتبّعة. وسنقوم بذلك حالاً. -### Tracking New Files ### +### تتبع الملفات الجديدة ### -In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this: +للقيام بتتبع ملف جديد عليه استخدام الأمر `git add` . مثلاً لنقم بتتبع الملف الجديد README: $ git add README -If you run your status command again, you can see that your README file is now tracked and staged: +إذا قمنا بتنفيذ الأمر `git status` مرة أخرى سنلاحظ أن الملف README أصبح متتبعاً وجاهزاً staged للقيام بعملية commit: $ git status # On branch master @@ -89,11 +88,11 @@ If you run your status command again, you can see that your README file is now t # new file: README # -You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively. +نستطيع معرفة بأن الملف staged من خلال ملاحظته تحت بند "changes to be comitted". إذا قمت بعمل commit في هذه اللحظة، سيقوم git بإضافة النسخة الحالية من الملف إلى snapshot. تذكر عندما قمنا بعمل git init سابقاً، ثم قمنا بإضافة الملفات عن طريق git add، كان ذلك للقيام ببدء تتبع الملفات في مجلد المشروع. يقبل الأمر git add مسار لملف أو لمجلد؛ فإذا كان المسار لمجلد سيقوم git بإضافة جميع الملفات والمجلدات ضمنه بشكل تعاودي recursively. -### Staging Modified Files ### +### تجهيز الملفات المعدلة ### -Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this: +لنقم بالتعديل على ملف قمنا بإضافته سابقاً. إذا قمنا مثلاً بالتعديل على ملف متتبع مسبقاً يدعى `benchmarks.rb` وقمنا بتنفيذ الأمر git status، سيكون الخرج مشابهاً للخرج التالي: $ git status # On branch master @@ -108,7 +107,7 @@ Let’s change a file that was already tracked. If you change a previously track # modified: benchmarks.rb # -The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again: +يظهر الملف benchmarks.rb تحت بند "changes not staged for commit" وهذا يعني أن الملف المُتتبّع قد خضع لعملية تعديل لكنه لم يخضع للتجهيز من أجل commit. للقيام بتجهيزه (أو تأشيره للإضافة إلى commit الجديد) يجب علينا تنفيذ الأمر `git add` (لاحظ بأنّه أمر متعدد الوظائف - نستطيع استخدامه لتتبع الملفات الجديدة، تجهيز الملفات من أجل commit، والقيام بأمور أخرى مثل حل الاعتراضات في حال القيام بدمج merge). لنقم بتنفيذ git add الآن لوضع benchmarks.rb بحالة staged، ومن ثم لنقم بتنفيذ الأمر git status لنرى ما الذي قد تغيّر: $ git add benchmarks.rb $ git status @@ -120,7 +119,7 @@ The benchmarks.rb file appears under a section named “Changes not staged for c # modified: benchmarks.rb # -Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time: +كلا الملفين الآن جاهز للإدخال بعملية commit المقبلة. في هذه النقطة، لنفرض أنك تود القيام بتعديل على ملف benchmarks.rb قبل القيام بعملية commit، ستقوم بفتح الملف والتعديل عليه وأنك جاهز للقيام بعملية commit. لكن قبل ذلك، دعنا نقوم بتنفيذ الأمر git status مرة إضافية: $ vim benchmarks.rb $ git status @@ -137,7 +136,7 @@ Both files are staged and will go into your next commit. At this point, suppose # modified: benchmarks.rb # -What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +ما الذي يحصل؟ كيف أصبح benchmarks.rb موجوداً تحت التبويبين staged و unstaged؟ لقد اتضح لنا أنّ git يقوم بتجهيز الملف على حالته عند قيامك بتنفيذ الأمر git add. إذا قمت بعمل commit الآن، ستكون نسخة benchmarks.rb كما كانت عند قيامك بتنفيذ الأمر git add وليس النسخة الجديدة التي حصلنا عليها بعد قيامنا بتعديل الملف. لذا إذا قمنا بتعديل ملف قبل قيامنا بتنفيذ git add، وقبل القيام بعملية commit، علينا تجهيز الملف مرة أخرى لعملية commit، وذلك بتنفيذ الأمر git add مرة جديدة: $ git add benchmarks.rb $ git status @@ -149,26 +148,26 @@ What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is t # modified: benchmarks.rb # -### Ignoring Files ### +### تجاهل الملفات ### -Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file: +غالباً ما تود من git تجاهل صنف من الملفات بحث لا يقوم بإضافتها تلقائياً أو لا يظهرها بأنّها غير متتبعة. تكون هذه الملفات عادة ملفات مولدة بشكل تلقائي مثل ملفات log و الملفات الوسيطة التي تولدها أدوات التطوير لديك. في مثل هذه الحالات/ يمكن إنشاء ملف .gitignore يحوي على أنماط لأسماء الملفات التي نرغب بتجاهلها. هذا مثال عمّا قد يحتويه ملف .gitignore: $ cat .gitignore *.[oa] *~ -The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository. +أول سطر يقوم بتوجيه git إلى تجاهل أي ملفات ذات لواحق من النوع o أو a - ملفات الكائنات وملفات الأرشيف وهي ملفات وسيطة تولدها أدوات بناء الكود عادة. السطر الثاني يوجه git إلى تجاهل أي ملفات تنتهي بالرمز (~) والتي تكون ملفات مؤقتة عادةً تستخدمها بعض برامج تحرير الكود. قد ترغب أيضاً بإضافة مجلدات log و tmp أو pid؛ أو حتى ملفات التوثيق تلقائية التوليد (من الكود عادة)، وغيرها. ينصح بإضافة ملف .gitignore في بداية إنشاء repository حتى نتجنب إضافة بعض الملفات عن طريق الخطأ وتلويث respository. -The rules for the patterns you can put in the .gitignore file are as follows: +قواعد الأنماط التي يمكن وضعها ضمن ملف .gitignore هي كالتالي: -* Blank lines or lines starting with # are ignored. -* Standard glob patterns work. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* الأسطر التي تبدأ بالرمز (#) يتم تجاهلها. +* أنماط glob القياسية تعمل. +* يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً. +* يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط. -Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . +أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. -Here is another example .gitignore file: +مثال عن ملف .gitignore: # a comment – this is ignored # no .a files @@ -182,7 +181,7 @@ Here is another example .gitignore file: # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt -### Viewing Your Staged and Unstaged Changes ### +### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ### If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. From 5e9c6a0416d1c02876a07c8af351c3ecf5aba310 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Tue, 23 Sep 2014 03:18:26 +0300 Subject: [PATCH 236/291] [ar] translating and --- ar/02-git-basics/01-chapter2.markdown | 37 +++++++++++++-------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index da77fdd39..89e6b9ae2 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -183,9 +183,10 @@ Insert 18333fig0201.png ### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ### -If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. +إذا لم تكتف بالمعلومات التي يقدمها لك أمر `git status` يمكنك استخدام أمر `git diff` للحصول على معلومات تفصيلية حول التغيرات التي طرأت على الملفات. سنقوم لاحقاً بالتعمق في هذا الأمر، لكن الآن سنكتفي بالإشارة إلى الاستخدامات الغالبة له؛ حيث أنك ستستخدمه غالباً للحصول على أجوبة على هذين السؤالين: ما الذي قمنا بالتعديل عليه ولم نجهزه بعد لعملية commit؟ ما الملفات التي أصبحت جاهزة للدخول في عملية commit المقبلة؟ +بالرغم من أنه يمكننا أن نحصل على هذه المعلومات باستخدام أمر `git status` إلا أنّ أمر `git diff` يوضح لنا التغيرات التي جرت على مستوى السطر والحرف - ما الذي قمنا بإضافته وما الذي أزلناه! -Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this: +لنقل أنك قمت بالتعديل على ملف README مرة أخرى وأشرته للإضافة إلى عملية commit وقمت بالتعديل على ملف benchmarks.rb ولم تضفه إلى قائمة الملفات الجاهزة لعملية commit؛ إذا قمت بتنفيذ الأمر `status` ستشاهد مرة أخرى شيئاً من الشكل: $ git status # On branch master @@ -200,7 +201,7 @@ Let’s say you edit and stage the README file again and then edit the benchmark # modified: benchmarks.rb # -To see what you’ve changed but not yet staged, type `git diff` with no other arguments: +لترى ما قمت بالتعديل عليه ولم تجهزه للإضافة نفذ الأمر `git diff` بدون إضافات: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -219,9 +220,9 @@ To see what you’ve changed but not yet staged, type `git diff` with no other a log = git.commits('master', 15) log.size -That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged. +يقوم هذا الأمر بعمل مقارنة بين الملفات ضمن مجلد العمل والملفات الموجودة في منطقة التعديلات المجهزة للإضافة staging area. وتخبرنا نتيجته بالتعديلات التي أجريناها ولم نقم بتجهيزها للإضافة إلى عملية commit المقبلة. -If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit: +لمشاهدة الملفات ذات الحالة staged والتي ستدخل في عملية commit المقبلة، يمكن استخدام الأمر `git diff --cached` (بالنسبة للإصدارات 1.6.1 وما بعد من git يمكنك أيضاً استخدام الأمر `git diff --staged` )، كالتالي: $ git diff --cached diff --git a/README b/README @@ -236,9 +237,9 @@ If you want to see what you’ve staged that will go into your next commit, you + +Grit is a Ruby library for extracting information from a Git repository -It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output. +من الجدير بالذكر أن أمر `git diff` لوحده لا يقوم بعرض جميع التعديلات التي تمت من آخر commit - فهو يقوم بعرض فقط التعديلات التي لم تؤشر على أنها staged. ويمكن أن يسبب ذلك بعض الإرباك، حيث أنك إذا قمت بإضافة جميع التعديلات إلى قائمة staged فلن يقوم بعرض أي شي في خرج تنفيذه. -For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged: +كمثال أيضاً، إذا قمنا بإضافة benchmarks.rb إلى قائمة staged ومن ثم قمنا بالتعديل عليه من جديد، يمكننا استخدام أمر `git diff` للحصول على لائحة بالتغييرات التي حصلت ولم تضف إلى قائمة staged كالتالي: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb @@ -254,7 +255,6 @@ For another example, if you stage the benchmarks.rb file and then edit it, you c # modified: benchmarks.rb # -Now you can use `git diff` to see what is still unstaged $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -267,7 +267,7 @@ Now you can use `git diff` to see what is still unstaged ##pp Grit::GitRuby.cache_client.stats +# test line -and `git diff --cached` to see what you’ve staged so far: +وباستخدام `git diff --cached` نتمكن من رؤية ما تم تجهيزه للإضافة إلى عملية commit القادمة: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb @@ -286,16 +286,15 @@ and `git diff --cached` to see what you’ve staged so far: log = git.commits('master', 15) log.size -### Committing Your Changes ### +### القيام بعملية (اعتماد) commit للتغيّرات ### -Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk. -In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`: +بعد اكمال تجهيز الملفات التي ترغب بإضافتها إلى النسخة snapshot الجديدة، يمكنك تنفيذ أمر commit ليتم اعتماد التعديلات التي أجريتها في سجل git. تذكر أنّ أي ملف لم يتم تجهيزه - سواء لم تقم بإضافته باستخدام الأمر git add بعد إنشاءه أو التعديل عليه - لن يدخل في هذه الإعتمادية، وستبقى على أنها ملفات تم تعديلها في مجلد العمل. أبسط طريقة لاعتماد التعديلات هي القيام بأمر `git commit` كالتالي: $ git commit -Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). +تنفيذ هذا الأمر سيطلب منا إدخال رسالة عملية commit - عادة ما يتم فتح محرر النصوص المشار إليه بمتغير البيئة `$EDITOR`. يمكنك تهيئته عن طريق الأمر `git config --global core.editor` كما شاهدنا في الفصل الأول. -The editor displays the following text (this example is a Vim screen): +يقوم محرر النصوص بعرض هذه الشاشة (مثالنا باستخدام VIM): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. @@ -310,20 +309,20 @@ The editor displays the following text (this example is a Vim screen): ~ ".git/COMMIT_EDITMSG" 10L, 283C -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +يمكنك ملاحظة أن رسالة عملية commit تحوي على خرج آخر عملية `git status` على شكل تعليقات بالإضافة إلى سطر فارغ في بداية الملف. يمكنك إزالة هذه التعليقات، أو يمكنك تركها لمساعدتك بتذكر ما قمت باعتماد تعديلاته. يمكنك الحصول على معلومات أكثر تفصلياً إذا قمت بتمرير الخيار `-v` إلى الأمر `git commit`. حيث يقوم ذلك بإضافة خرج أمر `git diff` إلى رسالة commit على شكل تعليقات أيضاً. عند إغلاق المحرر يقوم git بإنشاء commit ويتجاهل التعليقات. -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +علماً أنّه يمكنك كتابة رسالة الاعتمادية مباشرة من خلال تمرير الخيار `-m` إلى الأمر `git commit` على الشكل التالي: $ git commit -m "Story 182: Fix benchmarks for speed" [master]: created 463dc4f: "Fix benchmarks for speed" 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 README -Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +مبروك، لقد قمت بعمل أول commit لك! يعطيك خرج العملية معلومات عنها: في أي فرع branch تم الإعتماد (هنا master)، ما قيمة هاش SHA-1 الخاصة بالعملية ( هنا `463dc4f`)، عدد الملفات التي تغيّرت، بالإضافة إلى إحصاءات حول الأسطر التي أضيفت وأزيلت في هذه العملية. -Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later. +تذكر أنّ عملية commit تأخذ صورة عن الملفات في قائمة staged. أي شيء لم تقم بإضافته إلى هذه القائمة ما زال في مجلد العمل بحالة "معدل" modified؛ يمكنك القيام بإضافتهم من خلال عملية commit جديدة إلى التأريخ في git. نستنتج أنّه في كل عملية commit يقوم git بأخذ "صورة" snapshot عن المشروع يمكننا العودة لها لاحقاً أو مقارنتها أو غير ذلك.. -### Skipping the Staging Area ### +### تجاوز منطقة التجهيز Staging Area ### Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: From 6ec6c76a4308fd1941f03c39f3145b2e38262086 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= Date: Tue, 23 Sep 2014 22:07:43 +0200 Subject: [PATCH 237/291] [fr] fix mistranslation --- fr/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/03-git-branching/01-chapter3.markdown b/fr/03-git-branching/01-chapter3.markdown index 2f6370579..c6c7f1246 100644 --- a/fr/03-git-branching/01-chapter3.markdown +++ b/fr/03-git-branching/01-chapter3.markdown @@ -584,7 +584,7 @@ Cette commande vous fournit une branche locale modifiable basée sur l'état act L'extraction d'une branche locale à partir d'une branche distante crée automatiquement ce qu'on appelle une _branche de suivi_. Les branches de suivi sont des branches locales qui sont en relation directe avec une branche distante. Si vous vous trouvez sur une branche de suivi et que vous tapez `git push`, Git sélectionne automatiquement le serveur vers lequel pousser vos modifications. -De même, `git pull` sur une de ces branches récupère toutes les références distantes et les fusionne automatiquement dans la branche distante correspondante. +De même, `git pull` sur une de ces branches récupère toutes les références distantes et fusionne automatiquement la branche distante correspondante dans la branche actuelle. Lorsque vous clonez un dépôt, il crée généralement automatiquement une branche `master` qui suit `origin/master`. C'est pourquoi les commandes `git push` et `git pull` fonctionnent directement sans plus de paramétrage. From 43a54d1a4a8e0bf73f54b65db7867883e24b0b87 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Tue, 23 Sep 2014 23:31:40 +0300 Subject: [PATCH 238/291] [ar] translating until section 'Viewing the Commit History', fixing mixxing '`' --- ar/02-git-basics/01-chapter2.markdown | 119 +++++++++++++------------- 1 file changed, 59 insertions(+), 60 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 89e6b9ae2..8cbf79f6b 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -165,7 +165,7 @@ Insert 18333fig0201.png * يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً. * يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط. -أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. +أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (`*`) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. مثال عن ملف .gitignore: @@ -324,7 +324,7 @@ Insert 18333fig0201.png ### تجاوز منطقة التجهيز Staging Area ### -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +منطقة التجهيز تكون أحياناً معقدة أكثر مما تحتاج في عملك إلا أنّها مفيدة لعمل commits تماماً كما تودهم أن يكونوا. إذا أردت تجاوز منطقة التجهيز، يوفر git اختصاراً بسيطاً لذلك. باستخدام الأمر `git commit -a` يقوم git بإضافة الملفات المتتبعة إلى منطقة التجهيز بشكل تلقائي، كأنك قمت بعمل `git add`: $ git status # On branch master @@ -337,13 +337,13 @@ Although it can be amazingly useful for crafting commits exactly how you want th [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+), 0 deletions(-) -Notice how you don’t have to run `git add` on the benchmarks.rb file in this case before you commit. +لاحظ بأنك لاتحتاج إلى تنفيذ الأمر `git add` على ملف benchmark.rb قبل القيام بعملية commit. -### Removing Files ### +### إزالة الملفات ### -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around. +لحذف ملف من git، يجب عليك إزالته من قائمة الملفات المتتبعة (وبشكل أدق، إزالته من منطقة التجهيز) ومن ثم القيام بعملية commit. الأمر `git rm` يقوم بعمل ذلك كما يقوم بحذف الملف من مجلد العمل الخاص بك لذا لن تراه بعد الآن في قائمة الملفات غير المتتبعة في المرة المقبلة. -If you simply remove the file from your working directory, it shows up under the “Changes not staged for commit” (that is, _unstaged_) area of your `git status` output: +إذا قمت بإزالة الملف من مجلد العمل، يظهر تحت بند "تعديلات غير مجهزة للاعتماد" (أي _unstaged_) من خرج الأمر `git status`: $ rm grit.gemspec $ git status @@ -355,7 +355,7 @@ If you simply remove the file from your working directory, it shows up under the # deleted: grit.gemspec # -Then, if you run `git rm`, it stages the file’s removal: +فإذا قمت بتنفيذ أمر `git rm` يقوم بتجهيز عملية الحذف ليتم اعتمادها: $ git rm grit.gemspec rm 'grit.gemspec' @@ -368,31 +368,31 @@ Then, if you run `git rm`, it stages the file’s removal: # deleted: grit.gemspec # -The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git. +وفي المرة المقبلة التي ستقوم فيها بعمل commit، سيتم إزالة الملف من قائمة التتبع. إذا قمت مسبقاً بتعديل الملف وإضفته إلى الفهرس، يجب عليه تنفيذ عملية الحذف قسرياً وذلك بإضافة الخيار `-f`. يتم اتباع هذه الطريقة بغية حماية البيانات من أية عمليات حذف "عرضية" لملفات لم يتم تسجيلها ضمن git ولايمكن استعادتها بعد ذلك. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option: +أما إذا أردت إزالة الملف من منطقة التجهيز مع الحفاظ عليه في مجلد العمل (أي إزالته من تتبع git مع بقاءه على وسيطة التخزين) - وهو شيء مفيد إذا قمت بنسيان إضافة شيء ما إلى ملف `.gitignore` وأضفته عن طريق الخطأ ؛ كملف log كبير مثلاً - استخدم الخيار `--cached` مع الأمر `git rm` كالتالي: $ git rm --cached readme.txt -You can pass files, directories, and file-glob patterns to the `git rm` command. That means you can do things such as +يمكنك تمرير أسماء ملفات، مجلدات، وأنماط glob للأمر `git rm`. وهذا يعني بأنه يمكننا عمل أشياء كالتالي: $ git rm log/\*.log -Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this: +لاحظ الشرطة العكسية (`\`) قبل رمز النجمة `*`. إنّها ضرورية لأن git يقوم بعمل توسعة الأسماء الخاصة به بالإضافة إلى التوسعة الخاصة بسطر الأوامر. هذا الأمر يقوم بحذف كافة الملفات التي تملك اللاحقة `.log` في مجلد `/log`. أو يمكنك عمل شيء كالتالي: $ git rm \*~ -This command removes all files that end with `~`. +وهذا الأمر يقوم بحذف كافة الملفات المنتهية بالمحرف `~`. -### Moving Files ### +### نقل الملفات ### -Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later. +على خلاف أغلب أنظمة إدارة الإصدارات VCS الأخرى، لا يقوم git بتعقب حركة الملفات بشكل صريح. إذا قمت بإعادة تسمية ملف ضمن git، لايتم تسجيل أي بيانات وصفية metadata في git تقوم بأنك قمت بإعادة تسمية الملف. لكن، git ذكي جداً في استعياب ذلك - وسنقوم بمناقشة الأمر بعد قليل. -Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like +إذا أردت القيام بإعادة تسمية ملف يمكنك استخدام أمر `mv` في git كالتالي: $ git mv file_from file_to -and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file: +إذا قمنا بتنفيذ الأمر والنظر إلى خرج أمر `git status`: $ git mv README.txt README $ git status @@ -405,23 +405,23 @@ and it works fine. In fact, if you run something like this and look at the statu # renamed: README.txt -> README # -However, this is equivalent to running something like this: +وهو مكافئ للقيام بتنفيذ الأوامر التالي على التسلسل: $ mv README.txt README $ git rm README.txt $ git add README -Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +يدرك git بأنك قمت بعملية إعادة تسمية، لذا فالإختلاف الوحيد بين الطريقتين هو أنّ `git mv` عبارة عن أمر واحد، وليس ثلاثة أوامر. يمكن الاستفادة من هذه الخاصة باستخدام أية أدوات للقيام بعمليات إعادة التسمية، واستخدام add/rm قبل القيام بعملية commit. -## Viewing the Commit History ## +## مراجعة تأريخ عمليات commit ## -After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command. +بعد قيامك بعدد من عمليات الاعتماد commit، أو استنساخ repository بسجل تأريخ، ربما ستود إلقاء نظرة على ما جرى. أبسط وأقوى أداة لعمل ذلك هي الأمر `git log`. -These examples use a very simple project called simplegit that I often use for demonstrations. To get the project, run +هذه الأمثلة تستخدم مشروع بسيط جداً يدعى simplegit أقوم باستخدامه في عمليات العرض بأغلب الأحيان. للحصول على المشروع قم باستنساخه عن موقع github كالتالي: git clone git://github.com/schacon/simplegit-progit.git -When you run `git log` in this project, you should get output that looks something like this: +عندما تقوم بعمل `git log` ضمن المشروع، سيظهر لديك خرج مشابه للتالي: $ git log commit ca82a6dff817ec66f44342007202690a93763949 @@ -442,11 +442,11 @@ When you run `git log` in this project, you should get output that looks somethi first commit -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and e-mail, the date written, and the commit message. +بتنفيذ الأمر بدون بارمترات، يقوم git بعرض عمليات commit في repository بترتيب زمني معكوس - من الأحدث إلى الأقدم. كما يقوم بعرض بجانب كل commit هاش SHA-1 checksum الخاص بها، اسم وبريد الكاتب الإلكتروني، تاريخ الاعتماد، ورسالة الاعتماد. -A huge number and variety of options to the `git log` command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most-used options. +يمكن إرفاق الأمر `git log` بعدد كبير من الخيارات للحصول على المعلومات التي نريدها بالضبط.. تجد في الأسفل مثالاً عن أكثر الخيارات استخداماً. -One of the more helpful options is `-p`, which shows the diff introduced in each commit. You can also use `-2`, which limits the output to only the last two entries: +أحد أهم الخيارات هو `-p`، والذي يقوم بإظهار الفوارق المستحدثة بين عمليات commit المختلفة. يمكن أيضاً استخدام الخيار `-2` ليحد خرج النتيجة إلى آخر عمليتين: $ git log –p -2 commit ca82a6dff817ec66f44342007202690a93763949 @@ -486,8 +486,7 @@ One of the more helpful options is `-p`, which shows the diff introduced in each -end \ No newline at end of file -This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +هذا الخيار يعرض نفس المعلومات بالإضافة خرج diff بعده مباشرة. فهو مهم جداً من أجل مراجعة الكود واستعراض ما الذي تغير بشكل سريع ضمن سلسلة من عمليات commit. يمكنك أيضاً استخدام خيارات للتلخيص مع أمر `git log`. على سبيل المثال، إذا أردت رؤية بعض الإحصاءات المختصرة لكل commit، يمكنك استخدام الخيار `stat`: $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 @@ -519,43 +518,43 @@ You can also use a series of summarizing options with `git log`. For example, if lib/simplegit.rb | 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 0 deletions(-) -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end. -Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The oneline option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +كما ترى باستخدام الخيار `--stat` يتم عرض قائمة من الملفات المعدلة، عدد الملفات التي تغيرت، وعدد الأسطر التي أضيفت أو أزيلت. كما يضع ملخصاً للمعلومات في النهاية. +يوجد خيار مفيد آخر وهو `--pretty`. هذا الخيار يغير خرج السل إلى صيغ غير الافتراضية. يوجد بعضها مركب مسبقاً. مثلاً `oneline` يقوم بطباعة كل commit على سطر لوحدها، وهذا أمر مفيد في حال كنت تنظر إلى العديد من عمليات commit. بالإضافة إلى `short`، `full` و `fuller` والتي تعرض خرجاً تقريباً بنفس الصيغة مع معلومات أكثر أو أقل: $ git log --pretty=oneline ca82a6dff817ec66f44342007202690a93763949 changed the version number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code a11bef06a3f659402fe7563abf99ad00de2209e6 first commit -The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git: +أكثر الخيارات أهمية هو `format`، والذي يسمح لك بتحديد صيغة الخرج بشكل صريح بما يتناسب مع إعرابها آلياً - حيث أنك تعرف أنّه لن يتغير عند التحديث إلى git: $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 11 months ago : changed the version number 085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code a11bef0 - Scott Chacon, 11 months ago : first commit -Table 2-1 lists some of the more useful options that format takes. - - Option Description of Output - %H Commit hash - %h Abbreviated commit hash - %T Tree hash - %t Abbreviated tree hash - %P Parent hashes - %p Abbreviated parent hashes - %an Author name - %ae Author e-mail - %ad Author date (format respects the –date= option) - %ar Author date, relative - %cn Committer name - %ce Committer email - %cd Committer date - %cr Committer date, relative - %s Subject - -You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in Chapter 5. - -The oneline and format options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository: +الجدول 2-1 يعرض بعض الخيارات المفيدة التي يمكن إضافتها إلى الصيغة. + + الخيار وصف الخرج + %H Commit هاش + %h الهاش الاعتمادي المختصر + %T هاش الشجرة + %t هاش الشجرة المختصر + %P هاشات الوالد + %p هاشات الوالد المختصرة + %an اسم الكاتب + %ae بريد الكاتب الإلكتروني + %ad تاريخ الكاتب (يراعي الصيغة –date= option) + %ar تاريخ الكاتب - نسبياً + %cn اسم منفذ الاعتماد + %ce بريد منفذ الاعتماد الإلكتروني + %cd تاريخ منفذ الاعتماد + %cr تاريخ منفذ الاعتماد - نسبياً + %s العنوان + +قد تتسائل عن الاختلاف بين _الكاتب_ AUTHOR و _منفذ الاعتماد_ COMMITTER. الكاتب هو الشخص الذي كتب العمل بداية، بينما منفذ الاعتماد هو آخر شخص طبق العمل. لذا، إذا أرسلت باتشاً إلى مشروع وأحد المطورين الرئيسين قام بتطبيق الباتش، تأخذان كلاكما الاعتمادية - أنت ككاتب وهو كمنفذ اعتماد. + +وتكون هذه الخيارات مفيدة أكثر بالترافق مع الخيار `--graph`. حيث يضيف هذا الأمر غراف ASCII بسيط يوضح تأريخ الأفرع و الدمج، لاحظ التالي: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap @@ -569,17 +568,17 @@ The oneline and format options are particularly useful with another `log` option * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local -Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command. +يوجد مجموعة من الخيارات البسيطة مع أمر `git log`. يوضح الجدول 2-2 قائمة من الخيارات التي قمنا بتغطيتها حتى الآن وبعض صيغ التنسيق الشائعة والتي قد تكون مفيدة، وبجانبها شرح مبسط عن التغيير الذي تجريه على الخرج. - Option Description - -p Show the patch introduced with each commit. - --stat Show statistics for files modified in each commit. + الخيار الوصف + -p يظهر الباتش المدخل مع كل عملية commit. + --stat يظهر إحصاءات حول التعديلات التي حصلت على الملفات مع كل عملية commit. --shortstat Display only the changed/insertions/deletions line from the --stat command. - --name-only Show the list of files modified after the commit information. - --name-status Show the list of files affected with added/modified/deleted information as well. - --abbrev-commit Show only the first few characters of the SHA-1 checksum instead of all 40. + --name-only يظهر قائمة الملفات المعدلة. + --name-status يظهر قائمة الملفات المعدلة عن طريق الإضافة والحذف وغير ذلك. + --abbrev-commit يظهر أول مجموعة من هاش SHA-1 بدلاً عن كامل الأحرف 40. --relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format. - --graph Display an ASCII graph of the branch and merge history beside the log output. + --graph عرض غراف ASCII مع الخرج يظهر عمليات التفريع و الدمج. --pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). ### Limiting Log Output ### From da580c9c661c27dd44f7ac350b35e176052cab22 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Sun, 7 Sep 2014 01:11:26 +0300 Subject: [PATCH 239/291] [ar] translating file editing, checking status, tracking new files, staging modified files, ignoring files --- ar/02-git-basics/01-chapter2.markdown | 61 +++++++++++++-------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 0bea0227d..da77fdd39 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -1,4 +1,4 @@ -# مبادئ Git # +# مبادئ Git # إذا كان هناك فصل واحد عليك قراءته لكي تبدأ بإستخدام Git، فعليك بهذا الفصل! يغطي هذا الفصل جميع الأوامر الأساسية التي عليك معرفتها لكي تتمكن من القيام بأغلب الأمور أثناء استخدامك لـ Git. في نهاية هذا الفصل يجب أن تكون قادراً على انشاء واعداد الـ repository لمشروعك وعلى تحديد الملفات التي ستتم متابعتها والتي ستترك، وعلى تهييئ التغييرات لعمل commit عليها. ستتعلم أيضاً كيف تعد Git لكي تتجاهل بعض أنواع الملفات، كيف تقوم بالتراجع عن الأخطاء التي سترتكبها بسرعة وبسهولة، كيف تتصفح تاريخ مشروعك وكيف تعرض التغيرات بين الـ commits، وكيف تنشر وتسحب (push & pull) التغيرات من الـ repositories البعيدة عنك. @@ -40,27 +40,26 @@ هناك عدد من البروتوكولات المختلفة التي يمكنك اسستعمالها لنقل المعلومات في git. المثال السابق يستعمل بروتوكول 'git://'، ولكن من الممكن أن تجد أيضاً استخداماً لـ 'http(s)://' أو 'user@server:/path.git'، والتي تستعمل بروتوكول SSH في النقل. في الفصل الرابع من الكتاب ستتعرف على الخيارات المتوفرة للتواصل مع الـ repository الخاصة بك وميزات ومساوئ كل منها. ## تسجيل التعديلات في الـ repository ## +لديك repository أصلي ونسخة لتعمل عليها من ملفات المشروع. عليك أن تقوم ببعض التعديلات ثم تعمل commit لهذه التعديلات في repository الخاص بك في كل مرة يصل فيها المشروع إلى نقطة تود تسجيلها. -You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. +تذكر أنه كل ملف في مجلد العمل يمكن أن يكون في إحدى الحالتين فقط: مٌتَتَبّع tracked أو غير مٌتَتَبّع untracked. الملفات المٌتتبّعة هي ملفات كانت في أخر snapshot ويمكن إلغاء التعديلات عليها أو التعديل عليها أو وضعه في حالة staged (جاهز من أجل commit). الملفات غير المُتتبّعة هي كل الملفات الآخرى - أي ملف في مجلد العمل لم يكن موجوداً في آخر snapshot وليس معلماً بأنه staged. عندما تقوم باستنساخ repository جميع ملفاتك تكون بحالة متتبّعة tracked و غير معدلة unmodified لأنك قمت للتو بعمل check out ولم تقم بأي تعديل. -Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. - -As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1. +عندما تعدل الملفات، سيقوم git بتأشيرهم على أنهم modified، لأنك قمت بتغيرهم عن آخر commit. تقوم بعمل stage لهذه الملفات المعدلة ثم تقوم بعمل commit لجميع التغيرات في منطقة stage، وتتكرر العملية. يوضع الشكل 2-1 دورة العملية. Insert 18333fig0201.png -Figure 2-1. The lifecycle of the status of your files. +الشكل 2-1. دورة حالة الملفات. -### Checking the Status of Your Files ### +### تفقد حالة ملفاتك ### -The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this: +باستخدام الأمر git status يمكننا معرفة حالة الملفات لدينا. إذا قمت بتشغيل هذا الأمر مباشرة بعد قيامك بعمل clone يجب أن ترى شيئاً يشبه التالي: $ git status # On branch master nothing to commit, working directory clean -This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail. +وهذا يعني أنه لديك مجلد عمل نظيف - بمعنى آخر، لايوجد أي ملفات معدلة أو ملفات غير مُتتبّعة. كما أنّ هذا الأمر يخبرك بأي فرع branch أنت تعمل. حالياً، دائماً هو master، وهو الافتراضي؛ في الفصل المقبل سنمر على الأفرع و المرجعيات references بالتفصيل. -Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so: +لنقل بأنك قمت بإضافة ملف جديد على مشروعك، وليكن ملف README بسيط. إذا لم يكن الملف موجوداً مسبقاً، وقمت بتنفيذ الأمر `git status` سترى الملف غير مُتتبّعاً كما يلي: $ vim README $ git status @@ -71,15 +70,15 @@ Let’s say you add a new file to your project, a simple README file. If the fil # README nothing added to commit but untracked files present (use "git add" to track) -You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file. +يمكنك ملاحظة أنّ ملفك الجديد README غير مُتتبّع، فهو تحت تبويب "untracked files" في خرج الأمر. ويعني ذلك أنّ git يرى ملفاً جديداً على commit السابقة؛ علماً أنّ git لن يقوم بإضافة هذا الملف إلى الملفات المتتبعة إلا إذا قمت بطلب ذلك بشكل مباشر، والهدف من ذلك من أجل حماية المشروع من الضم الخاطئ لملفات binary أو أي ملفات لا تود بإضافتها. إلاّ أنّك ترغب في إضافة README إلى الملفات المتتبّعة. وسنقوم بذلك حالاً. -### Tracking New Files ### +### تتبع الملفات الجديدة ### -In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this: +للقيام بتتبع ملف جديد عليه استخدام الأمر `git add` . مثلاً لنقم بتتبع الملف الجديد README: $ git add README -If you run your status command again, you can see that your README file is now tracked and staged: +إذا قمنا بتنفيذ الأمر `git status` مرة أخرى سنلاحظ أن الملف README أصبح متتبعاً وجاهزاً staged للقيام بعملية commit: $ git status # On branch master @@ -89,11 +88,11 @@ If you run your status command again, you can see that your README file is now t # new file: README # -You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively. +نستطيع معرفة بأن الملف staged من خلال ملاحظته تحت بند "changes to be comitted". إذا قمت بعمل commit في هذه اللحظة، سيقوم git بإضافة النسخة الحالية من الملف إلى snapshot. تذكر عندما قمنا بعمل git init سابقاً، ثم قمنا بإضافة الملفات عن طريق git add، كان ذلك للقيام ببدء تتبع الملفات في مجلد المشروع. يقبل الأمر git add مسار لملف أو لمجلد؛ فإذا كان المسار لمجلد سيقوم git بإضافة جميع الملفات والمجلدات ضمنه بشكل تعاودي recursively. -### Staging Modified Files ### +### تجهيز الملفات المعدلة ### -Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this: +لنقم بالتعديل على ملف قمنا بإضافته سابقاً. إذا قمنا مثلاً بالتعديل على ملف متتبع مسبقاً يدعى `benchmarks.rb` وقمنا بتنفيذ الأمر git status، سيكون الخرج مشابهاً للخرج التالي: $ git status # On branch master @@ -108,7 +107,7 @@ Let’s change a file that was already tracked. If you change a previously track # modified: benchmarks.rb # -The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again: +يظهر الملف benchmarks.rb تحت بند "changes not staged for commit" وهذا يعني أن الملف المُتتبّع قد خضع لعملية تعديل لكنه لم يخضع للتجهيز من أجل commit. للقيام بتجهيزه (أو تأشيره للإضافة إلى commit الجديد) يجب علينا تنفيذ الأمر `git add` (لاحظ بأنّه أمر متعدد الوظائف - نستطيع استخدامه لتتبع الملفات الجديدة، تجهيز الملفات من أجل commit، والقيام بأمور أخرى مثل حل الاعتراضات في حال القيام بدمج merge). لنقم بتنفيذ git add الآن لوضع benchmarks.rb بحالة staged، ومن ثم لنقم بتنفيذ الأمر git status لنرى ما الذي قد تغيّر: $ git add benchmarks.rb $ git status @@ -120,7 +119,7 @@ The benchmarks.rb file appears under a section named “Changes not staged for c # modified: benchmarks.rb # -Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time: +كلا الملفين الآن جاهز للإدخال بعملية commit المقبلة. في هذه النقطة، لنفرض أنك تود القيام بتعديل على ملف benchmarks.rb قبل القيام بعملية commit، ستقوم بفتح الملف والتعديل عليه وأنك جاهز للقيام بعملية commit. لكن قبل ذلك، دعنا نقوم بتنفيذ الأمر git status مرة إضافية: $ vim benchmarks.rb $ git status @@ -137,7 +136,7 @@ Both files are staged and will go into your next commit. At this point, suppose # modified: benchmarks.rb # -What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +ما الذي يحصل؟ كيف أصبح benchmarks.rb موجوداً تحت التبويبين staged و unstaged؟ لقد اتضح لنا أنّ git يقوم بتجهيز الملف على حالته عند قيامك بتنفيذ الأمر git add. إذا قمت بعمل commit الآن، ستكون نسخة benchmarks.rb كما كانت عند قيامك بتنفيذ الأمر git add وليس النسخة الجديدة التي حصلنا عليها بعد قيامنا بتعديل الملف. لذا إذا قمنا بتعديل ملف قبل قيامنا بتنفيذ git add، وقبل القيام بعملية commit، علينا تجهيز الملف مرة أخرى لعملية commit، وذلك بتنفيذ الأمر git add مرة جديدة: $ git add benchmarks.rb $ git status @@ -149,26 +148,26 @@ What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is t # modified: benchmarks.rb # -### Ignoring Files ### +### تجاهل الملفات ### -Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file: +غالباً ما تود من git تجاهل صنف من الملفات بحث لا يقوم بإضافتها تلقائياً أو لا يظهرها بأنّها غير متتبعة. تكون هذه الملفات عادة ملفات مولدة بشكل تلقائي مثل ملفات log و الملفات الوسيطة التي تولدها أدوات التطوير لديك. في مثل هذه الحالات/ يمكن إنشاء ملف .gitignore يحوي على أنماط لأسماء الملفات التي نرغب بتجاهلها. هذا مثال عمّا قد يحتويه ملف .gitignore: $ cat .gitignore *.[oa] *~ -The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository. +أول سطر يقوم بتوجيه git إلى تجاهل أي ملفات ذات لواحق من النوع o أو a - ملفات الكائنات وملفات الأرشيف وهي ملفات وسيطة تولدها أدوات بناء الكود عادة. السطر الثاني يوجه git إلى تجاهل أي ملفات تنتهي بالرمز (~) والتي تكون ملفات مؤقتة عادةً تستخدمها بعض برامج تحرير الكود. قد ترغب أيضاً بإضافة مجلدات log و tmp أو pid؛ أو حتى ملفات التوثيق تلقائية التوليد (من الكود عادة)، وغيرها. ينصح بإضافة ملف .gitignore في بداية إنشاء repository حتى نتجنب إضافة بعض الملفات عن طريق الخطأ وتلويث respository. -The rules for the patterns you can put in the .gitignore file are as follows: +قواعد الأنماط التي يمكن وضعها ضمن ملف .gitignore هي كالتالي: -* Blank lines or lines starting with # are ignored. -* Standard glob patterns work. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* الأسطر التي تبدأ بالرمز (#) يتم تجاهلها. +* أنماط glob القياسية تعمل. +* يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً. +* يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط. -Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . +أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. -Here is another example .gitignore file: +مثال عن ملف .gitignore: # a comment – this is ignored # no .a files @@ -182,7 +181,7 @@ Here is another example .gitignore file: # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt -### Viewing Your Staged and Unstaged Changes ### +### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ### If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. From 91143f4c7769a0d08bd66edcf83a5b91a8e4c353 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Tue, 23 Sep 2014 03:18:26 +0300 Subject: [PATCH 240/291] [ar] translating and --- ar/02-git-basics/01-chapter2.markdown | 37 +++++++++++++-------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index da77fdd39..89e6b9ae2 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -183,9 +183,10 @@ Insert 18333fig0201.png ### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ### -If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. +إذا لم تكتف بالمعلومات التي يقدمها لك أمر `git status` يمكنك استخدام أمر `git diff` للحصول على معلومات تفصيلية حول التغيرات التي طرأت على الملفات. سنقوم لاحقاً بالتعمق في هذا الأمر، لكن الآن سنكتفي بالإشارة إلى الاستخدامات الغالبة له؛ حيث أنك ستستخدمه غالباً للحصول على أجوبة على هذين السؤالين: ما الذي قمنا بالتعديل عليه ولم نجهزه بعد لعملية commit؟ ما الملفات التي أصبحت جاهزة للدخول في عملية commit المقبلة؟ +بالرغم من أنه يمكننا أن نحصل على هذه المعلومات باستخدام أمر `git status` إلا أنّ أمر `git diff` يوضح لنا التغيرات التي جرت على مستوى السطر والحرف - ما الذي قمنا بإضافته وما الذي أزلناه! -Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this: +لنقل أنك قمت بالتعديل على ملف README مرة أخرى وأشرته للإضافة إلى عملية commit وقمت بالتعديل على ملف benchmarks.rb ولم تضفه إلى قائمة الملفات الجاهزة لعملية commit؛ إذا قمت بتنفيذ الأمر `status` ستشاهد مرة أخرى شيئاً من الشكل: $ git status # On branch master @@ -200,7 +201,7 @@ Let’s say you edit and stage the README file again and then edit the benchmark # modified: benchmarks.rb # -To see what you’ve changed but not yet staged, type `git diff` with no other arguments: +لترى ما قمت بالتعديل عليه ولم تجهزه للإضافة نفذ الأمر `git diff` بدون إضافات: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -219,9 +220,9 @@ To see what you’ve changed but not yet staged, type `git diff` with no other a log = git.commits('master', 15) log.size -That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged. +يقوم هذا الأمر بعمل مقارنة بين الملفات ضمن مجلد العمل والملفات الموجودة في منطقة التعديلات المجهزة للإضافة staging area. وتخبرنا نتيجته بالتعديلات التي أجريناها ولم نقم بتجهيزها للإضافة إلى عملية commit المقبلة. -If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit: +لمشاهدة الملفات ذات الحالة staged والتي ستدخل في عملية commit المقبلة، يمكن استخدام الأمر `git diff --cached` (بالنسبة للإصدارات 1.6.1 وما بعد من git يمكنك أيضاً استخدام الأمر `git diff --staged` )، كالتالي: $ git diff --cached diff --git a/README b/README @@ -236,9 +237,9 @@ If you want to see what you’ve staged that will go into your next commit, you + +Grit is a Ruby library for extracting information from a Git repository -It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output. +من الجدير بالذكر أن أمر `git diff` لوحده لا يقوم بعرض جميع التعديلات التي تمت من آخر commit - فهو يقوم بعرض فقط التعديلات التي لم تؤشر على أنها staged. ويمكن أن يسبب ذلك بعض الإرباك، حيث أنك إذا قمت بإضافة جميع التعديلات إلى قائمة staged فلن يقوم بعرض أي شي في خرج تنفيذه. -For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged: +كمثال أيضاً، إذا قمنا بإضافة benchmarks.rb إلى قائمة staged ومن ثم قمنا بالتعديل عليه من جديد، يمكننا استخدام أمر `git diff` للحصول على لائحة بالتغييرات التي حصلت ولم تضف إلى قائمة staged كالتالي: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb @@ -254,7 +255,6 @@ For another example, if you stage the benchmarks.rb file and then edit it, you c # modified: benchmarks.rb # -Now you can use `git diff` to see what is still unstaged $ git diff diff --git a/benchmarks.rb b/benchmarks.rb @@ -267,7 +267,7 @@ Now you can use `git diff` to see what is still unstaged ##pp Grit::GitRuby.cache_client.stats +# test line -and `git diff --cached` to see what you’ve staged so far: +وباستخدام `git diff --cached` نتمكن من رؤية ما تم تجهيزه للإضافة إلى عملية commit القادمة: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb @@ -286,16 +286,15 @@ and `git diff --cached` to see what you’ve staged so far: log = git.commits('master', 15) log.size -### Committing Your Changes ### +### القيام بعملية (اعتماد) commit للتغيّرات ### -Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk. -In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`: +بعد اكمال تجهيز الملفات التي ترغب بإضافتها إلى النسخة snapshot الجديدة، يمكنك تنفيذ أمر commit ليتم اعتماد التعديلات التي أجريتها في سجل git. تذكر أنّ أي ملف لم يتم تجهيزه - سواء لم تقم بإضافته باستخدام الأمر git add بعد إنشاءه أو التعديل عليه - لن يدخل في هذه الإعتمادية، وستبقى على أنها ملفات تم تعديلها في مجلد العمل. أبسط طريقة لاعتماد التعديلات هي القيام بأمر `git commit` كالتالي: $ git commit -Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). +تنفيذ هذا الأمر سيطلب منا إدخال رسالة عملية commit - عادة ما يتم فتح محرر النصوص المشار إليه بمتغير البيئة `$EDITOR`. يمكنك تهيئته عن طريق الأمر `git config --global core.editor` كما شاهدنا في الفصل الأول. -The editor displays the following text (this example is a Vim screen): +يقوم محرر النصوص بعرض هذه الشاشة (مثالنا باستخدام VIM): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. @@ -310,20 +309,20 @@ The editor displays the following text (this example is a Vim screen): ~ ".git/COMMIT_EDITMSG" 10L, 283C -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +يمكنك ملاحظة أن رسالة عملية commit تحوي على خرج آخر عملية `git status` على شكل تعليقات بالإضافة إلى سطر فارغ في بداية الملف. يمكنك إزالة هذه التعليقات، أو يمكنك تركها لمساعدتك بتذكر ما قمت باعتماد تعديلاته. يمكنك الحصول على معلومات أكثر تفصلياً إذا قمت بتمرير الخيار `-v` إلى الأمر `git commit`. حيث يقوم ذلك بإضافة خرج أمر `git diff` إلى رسالة commit على شكل تعليقات أيضاً. عند إغلاق المحرر يقوم git بإنشاء commit ويتجاهل التعليقات. -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this: +علماً أنّه يمكنك كتابة رسالة الاعتمادية مباشرة من خلال تمرير الخيار `-m` إلى الأمر `git commit` على الشكل التالي: $ git commit -m "Story 182: Fix benchmarks for speed" [master]: created 463dc4f: "Fix benchmarks for speed" 2 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 README -Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +مبروك، لقد قمت بعمل أول commit لك! يعطيك خرج العملية معلومات عنها: في أي فرع branch تم الإعتماد (هنا master)، ما قيمة هاش SHA-1 الخاصة بالعملية ( هنا `463dc4f`)، عدد الملفات التي تغيّرت، بالإضافة إلى إحصاءات حول الأسطر التي أضيفت وأزيلت في هذه العملية. -Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later. +تذكر أنّ عملية commit تأخذ صورة عن الملفات في قائمة staged. أي شيء لم تقم بإضافته إلى هذه القائمة ما زال في مجلد العمل بحالة "معدل" modified؛ يمكنك القيام بإضافتهم من خلال عملية commit جديدة إلى التأريخ في git. نستنتج أنّه في كل عملية commit يقوم git بأخذ "صورة" snapshot عن المشروع يمكننا العودة لها لاحقاً أو مقارنتها أو غير ذلك.. -### Skipping the Staging Area ### +### تجاوز منطقة التجهيز Staging Area ### Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: From 95ae9439cad6ebecff175ded38c7fbe7bbb009d1 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Tue, 23 Sep 2014 23:31:40 +0300 Subject: [PATCH 241/291] [ar] translating until section 'Viewing the Commit History', fixing mixxing '`' --- ar/02-git-basics/01-chapter2.markdown | 119 +++++++++++++------------- 1 file changed, 59 insertions(+), 60 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 89e6b9ae2..8cbf79f6b 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -165,7 +165,7 @@ Insert 18333fig0201.png * يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً. * يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط. -أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. +أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (`*`) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً. مثال عن ملف .gitignore: @@ -324,7 +324,7 @@ Insert 18333fig0201.png ### تجاوز منطقة التجهيز Staging Area ### -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +منطقة التجهيز تكون أحياناً معقدة أكثر مما تحتاج في عملك إلا أنّها مفيدة لعمل commits تماماً كما تودهم أن يكونوا. إذا أردت تجاوز منطقة التجهيز، يوفر git اختصاراً بسيطاً لذلك. باستخدام الأمر `git commit -a` يقوم git بإضافة الملفات المتتبعة إلى منطقة التجهيز بشكل تلقائي، كأنك قمت بعمل `git add`: $ git status # On branch master @@ -337,13 +337,13 @@ Although it can be amazingly useful for crafting commits exactly how you want th [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+), 0 deletions(-) -Notice how you don’t have to run `git add` on the benchmarks.rb file in this case before you commit. +لاحظ بأنك لاتحتاج إلى تنفيذ الأمر `git add` على ملف benchmark.rb قبل القيام بعملية commit. -### Removing Files ### +### إزالة الملفات ### -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around. +لحذف ملف من git، يجب عليك إزالته من قائمة الملفات المتتبعة (وبشكل أدق، إزالته من منطقة التجهيز) ومن ثم القيام بعملية commit. الأمر `git rm` يقوم بعمل ذلك كما يقوم بحذف الملف من مجلد العمل الخاص بك لذا لن تراه بعد الآن في قائمة الملفات غير المتتبعة في المرة المقبلة. -If you simply remove the file from your working directory, it shows up under the “Changes not staged for commit” (that is, _unstaged_) area of your `git status` output: +إذا قمت بإزالة الملف من مجلد العمل، يظهر تحت بند "تعديلات غير مجهزة للاعتماد" (أي _unstaged_) من خرج الأمر `git status`: $ rm grit.gemspec $ git status @@ -355,7 +355,7 @@ If you simply remove the file from your working directory, it shows up under the # deleted: grit.gemspec # -Then, if you run `git rm`, it stages the file’s removal: +فإذا قمت بتنفيذ أمر `git rm` يقوم بتجهيز عملية الحذف ليتم اعتمادها: $ git rm grit.gemspec rm 'grit.gemspec' @@ -368,31 +368,31 @@ Then, if you run `git rm`, it stages the file’s removal: # deleted: grit.gemspec # -The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git. +وفي المرة المقبلة التي ستقوم فيها بعمل commit، سيتم إزالة الملف من قائمة التتبع. إذا قمت مسبقاً بتعديل الملف وإضفته إلى الفهرس، يجب عليه تنفيذ عملية الحذف قسرياً وذلك بإضافة الخيار `-f`. يتم اتباع هذه الطريقة بغية حماية البيانات من أية عمليات حذف "عرضية" لملفات لم يتم تسجيلها ضمن git ولايمكن استعادتها بعد ذلك. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option: +أما إذا أردت إزالة الملف من منطقة التجهيز مع الحفاظ عليه في مجلد العمل (أي إزالته من تتبع git مع بقاءه على وسيطة التخزين) - وهو شيء مفيد إذا قمت بنسيان إضافة شيء ما إلى ملف `.gitignore` وأضفته عن طريق الخطأ ؛ كملف log كبير مثلاً - استخدم الخيار `--cached` مع الأمر `git rm` كالتالي: $ git rm --cached readme.txt -You can pass files, directories, and file-glob patterns to the `git rm` command. That means you can do things such as +يمكنك تمرير أسماء ملفات، مجلدات، وأنماط glob للأمر `git rm`. وهذا يعني بأنه يمكننا عمل أشياء كالتالي: $ git rm log/\*.log -Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this: +لاحظ الشرطة العكسية (`\`) قبل رمز النجمة `*`. إنّها ضرورية لأن git يقوم بعمل توسعة الأسماء الخاصة به بالإضافة إلى التوسعة الخاصة بسطر الأوامر. هذا الأمر يقوم بحذف كافة الملفات التي تملك اللاحقة `.log` في مجلد `/log`. أو يمكنك عمل شيء كالتالي: $ git rm \*~ -This command removes all files that end with `~`. +وهذا الأمر يقوم بحذف كافة الملفات المنتهية بالمحرف `~`. -### Moving Files ### +### نقل الملفات ### -Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later. +على خلاف أغلب أنظمة إدارة الإصدارات VCS الأخرى، لا يقوم git بتعقب حركة الملفات بشكل صريح. إذا قمت بإعادة تسمية ملف ضمن git، لايتم تسجيل أي بيانات وصفية metadata في git تقوم بأنك قمت بإعادة تسمية الملف. لكن، git ذكي جداً في استعياب ذلك - وسنقوم بمناقشة الأمر بعد قليل. -Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like +إذا أردت القيام بإعادة تسمية ملف يمكنك استخدام أمر `mv` في git كالتالي: $ git mv file_from file_to -and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file: +إذا قمنا بتنفيذ الأمر والنظر إلى خرج أمر `git status`: $ git mv README.txt README $ git status @@ -405,23 +405,23 @@ and it works fine. In fact, if you run something like this and look at the statu # renamed: README.txt -> README # -However, this is equivalent to running something like this: +وهو مكافئ للقيام بتنفيذ الأوامر التالي على التسلسل: $ mv README.txt README $ git rm README.txt $ git add README -Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +يدرك git بأنك قمت بعملية إعادة تسمية، لذا فالإختلاف الوحيد بين الطريقتين هو أنّ `git mv` عبارة عن أمر واحد، وليس ثلاثة أوامر. يمكن الاستفادة من هذه الخاصة باستخدام أية أدوات للقيام بعمليات إعادة التسمية، واستخدام add/rm قبل القيام بعملية commit. -## Viewing the Commit History ## +## مراجعة تأريخ عمليات commit ## -After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command. +بعد قيامك بعدد من عمليات الاعتماد commit، أو استنساخ repository بسجل تأريخ، ربما ستود إلقاء نظرة على ما جرى. أبسط وأقوى أداة لعمل ذلك هي الأمر `git log`. -These examples use a very simple project called simplegit that I often use for demonstrations. To get the project, run +هذه الأمثلة تستخدم مشروع بسيط جداً يدعى simplegit أقوم باستخدامه في عمليات العرض بأغلب الأحيان. للحصول على المشروع قم باستنساخه عن موقع github كالتالي: git clone git://github.com/schacon/simplegit-progit.git -When you run `git log` in this project, you should get output that looks something like this: +عندما تقوم بعمل `git log` ضمن المشروع، سيظهر لديك خرج مشابه للتالي: $ git log commit ca82a6dff817ec66f44342007202690a93763949 @@ -442,11 +442,11 @@ When you run `git log` in this project, you should get output that looks somethi first commit -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and e-mail, the date written, and the commit message. +بتنفيذ الأمر بدون بارمترات، يقوم git بعرض عمليات commit في repository بترتيب زمني معكوس - من الأحدث إلى الأقدم. كما يقوم بعرض بجانب كل commit هاش SHA-1 checksum الخاص بها، اسم وبريد الكاتب الإلكتروني، تاريخ الاعتماد، ورسالة الاعتماد. -A huge number and variety of options to the `git log` command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most-used options. +يمكن إرفاق الأمر `git log` بعدد كبير من الخيارات للحصول على المعلومات التي نريدها بالضبط.. تجد في الأسفل مثالاً عن أكثر الخيارات استخداماً. -One of the more helpful options is `-p`, which shows the diff introduced in each commit. You can also use `-2`, which limits the output to only the last two entries: +أحد أهم الخيارات هو `-p`، والذي يقوم بإظهار الفوارق المستحدثة بين عمليات commit المختلفة. يمكن أيضاً استخدام الخيار `-2` ليحد خرج النتيجة إلى آخر عمليتين: $ git log –p -2 commit ca82a6dff817ec66f44342007202690a93763949 @@ -486,8 +486,7 @@ One of the more helpful options is `-p`, which shows the diff introduced in each -end \ No newline at end of file -This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +هذا الخيار يعرض نفس المعلومات بالإضافة خرج diff بعده مباشرة. فهو مهم جداً من أجل مراجعة الكود واستعراض ما الذي تغير بشكل سريع ضمن سلسلة من عمليات commit. يمكنك أيضاً استخدام خيارات للتلخيص مع أمر `git log`. على سبيل المثال، إذا أردت رؤية بعض الإحصاءات المختصرة لكل commit، يمكنك استخدام الخيار `stat`: $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 @@ -519,43 +518,43 @@ You can also use a series of summarizing options with `git log`. For example, if lib/simplegit.rb | 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 0 deletions(-) -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end. -Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The oneline option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +كما ترى باستخدام الخيار `--stat` يتم عرض قائمة من الملفات المعدلة، عدد الملفات التي تغيرت، وعدد الأسطر التي أضيفت أو أزيلت. كما يضع ملخصاً للمعلومات في النهاية. +يوجد خيار مفيد آخر وهو `--pretty`. هذا الخيار يغير خرج السل إلى صيغ غير الافتراضية. يوجد بعضها مركب مسبقاً. مثلاً `oneline` يقوم بطباعة كل commit على سطر لوحدها، وهذا أمر مفيد في حال كنت تنظر إلى العديد من عمليات commit. بالإضافة إلى `short`، `full` و `fuller` والتي تعرض خرجاً تقريباً بنفس الصيغة مع معلومات أكثر أو أقل: $ git log --pretty=oneline ca82a6dff817ec66f44342007202690a93763949 changed the version number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code a11bef06a3f659402fe7563abf99ad00de2209e6 first commit -The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git: +أكثر الخيارات أهمية هو `format`، والذي يسمح لك بتحديد صيغة الخرج بشكل صريح بما يتناسب مع إعرابها آلياً - حيث أنك تعرف أنّه لن يتغير عند التحديث إلى git: $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 11 months ago : changed the version number 085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code a11bef0 - Scott Chacon, 11 months ago : first commit -Table 2-1 lists some of the more useful options that format takes. - - Option Description of Output - %H Commit hash - %h Abbreviated commit hash - %T Tree hash - %t Abbreviated tree hash - %P Parent hashes - %p Abbreviated parent hashes - %an Author name - %ae Author e-mail - %ad Author date (format respects the –date= option) - %ar Author date, relative - %cn Committer name - %ce Committer email - %cd Committer date - %cr Committer date, relative - %s Subject - -You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in Chapter 5. - -The oneline and format options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository: +الجدول 2-1 يعرض بعض الخيارات المفيدة التي يمكن إضافتها إلى الصيغة. + + الخيار وصف الخرج + %H Commit هاش + %h الهاش الاعتمادي المختصر + %T هاش الشجرة + %t هاش الشجرة المختصر + %P هاشات الوالد + %p هاشات الوالد المختصرة + %an اسم الكاتب + %ae بريد الكاتب الإلكتروني + %ad تاريخ الكاتب (يراعي الصيغة –date= option) + %ar تاريخ الكاتب - نسبياً + %cn اسم منفذ الاعتماد + %ce بريد منفذ الاعتماد الإلكتروني + %cd تاريخ منفذ الاعتماد + %cr تاريخ منفذ الاعتماد - نسبياً + %s العنوان + +قد تتسائل عن الاختلاف بين _الكاتب_ AUTHOR و _منفذ الاعتماد_ COMMITTER. الكاتب هو الشخص الذي كتب العمل بداية، بينما منفذ الاعتماد هو آخر شخص طبق العمل. لذا، إذا أرسلت باتشاً إلى مشروع وأحد المطورين الرئيسين قام بتطبيق الباتش، تأخذان كلاكما الاعتمادية - أنت ككاتب وهو كمنفذ اعتماد. + +وتكون هذه الخيارات مفيدة أكثر بالترافق مع الخيار `--graph`. حيث يضيف هذا الأمر غراف ASCII بسيط يوضح تأريخ الأفرع و الدمج، لاحظ التالي: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap @@ -569,17 +568,17 @@ The oneline and format options are particularly useful with another `log` option * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local -Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command. +يوجد مجموعة من الخيارات البسيطة مع أمر `git log`. يوضح الجدول 2-2 قائمة من الخيارات التي قمنا بتغطيتها حتى الآن وبعض صيغ التنسيق الشائعة والتي قد تكون مفيدة، وبجانبها شرح مبسط عن التغيير الذي تجريه على الخرج. - Option Description - -p Show the patch introduced with each commit. - --stat Show statistics for files modified in each commit. + الخيار الوصف + -p يظهر الباتش المدخل مع كل عملية commit. + --stat يظهر إحصاءات حول التعديلات التي حصلت على الملفات مع كل عملية commit. --shortstat Display only the changed/insertions/deletions line from the --stat command. - --name-only Show the list of files modified after the commit information. - --name-status Show the list of files affected with added/modified/deleted information as well. - --abbrev-commit Show only the first few characters of the SHA-1 checksum instead of all 40. + --name-only يظهر قائمة الملفات المعدلة. + --name-status يظهر قائمة الملفات المعدلة عن طريق الإضافة والحذف وغير ذلك. + --abbrev-commit يظهر أول مجموعة من هاش SHA-1 بدلاً عن كامل الأحرف 40. --relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format. - --graph Display an ASCII graph of the branch and merge history beside the log output. + --graph عرض غراف ASCII مع الخرج يظهر عمليات التفريع و الدمج. --pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). ### Limiting Log Output ### From 3bdbbf64bb91bb100eca3d955dd6a31328e1d310 Mon Sep 17 00:00:00 2001 From: "Ammar M. Zerouk" Date: Wed, 24 Sep 2014 05:51:00 +0300 Subject: [PATCH 242/291] [ar] translating 'limiting log output' --- ar/02-git-basics/01-chapter2.markdown | 30 +++++++++++++-------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown index 8cbf79f6b..72948c863 100644 --- a/ar/02-git-basics/01-chapter2.markdown +++ b/ar/02-git-basics/01-chapter2.markdown @@ -581,30 +581,30 @@ Insert 18333fig0201.png --graph عرض غراف ASCII مع الخرج يظهر عمليات التفريع و الدمج. --pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). -### Limiting Log Output ### +### تحديد خرج السجل ### -In addition to output-formatting options, git log takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which show only the last two commits. In fact, you can do `-`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +بالإضافة تحديد شكل الخرج، يسمح git بأخذ مجموعة جزئية فقط من الخرج. وقد قمت بمشاهدة ذلك مسبقاً - الخيار `-2` المستخدم لعرض آخر عمليتي commit. في الواقع يمكنك استخدام `-` حيث `n` هي عدد صحيح لعرض آخر `n` عملية commit. في الحقيقة، لن تستخدمها على الغالب، لأن git يقوم بتمرير كامل الخرج لبرنامج تصفح لتتمكن من تصفح عمليات commit صفحة صفحة. -However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks: +من الخيارات الهامة جداً، المحددات الزمنية مثل `--since` و `--until`. على سبيل المثال، هذا الأمر يعطيك قائمة بعمليات commit التي حصلت في آخر أسبوعين: $ git log --since=2.weeks -This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”. +ويعمل هذا الأمر مع أنواع كثيرة من الصيغ - يمكنك تحديد تاريخ محدد ("2008-01-15") أو تاريخ نسبي مثل "2 years 1 day 3 minutes ago". -You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) +يكطمط أيضاً تصفية قائمة عمليات commit من خلال محددات البحث. مثلاً خيار `--author` يقوم بتصفية النتائج وفق كاتب محدد، و `--grep` يقوم بالفلترة عن طريق كلمة مفتاحية. (لاحظ أنّه إذا قمت بإضافة خياراي author و grep، يجب عليك إضافة الخيار `--all-match` أو سيقوم git بعمل مطابقة مع أحدهما فقط). -The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +آخر الخيارات الهامة التي يمكن تمريرها إلى الأمر `git log` كمصناف هي المسار. إذا قمت بتحديد مجلد أو اسم ملف، يمكنك تحديد الخرج إلى عمليات commit التي آثرت في هذا المسار. ودائماً ما يكون آخر خيار يوضع في `log` ويسبق بداشين double dashes (`--`) ليفصل المسارات عن الخيارات. -In Table 2-3 we’ll list these and a few other common options for your reference. +في الجدول 2-3 - نعرض الخيارات التي يمكن إضافتها مع log. - Option Description - -(n) Show only the last n commits - --since, --after Limit the commits to those made after the specified date. - --until, --before Limit the commits to those made before the specified date. - --author Only show commits in which the author entry matches the specified string. - --committer Only show commits in which the committer entry matches the specified string. + خيار وصف + -(n) يظهر آن n عملية commit. + --since, --after تحديد عمليات commit بعد التاريخ الذي يتلوها. + --until, --before تحديد عمليات commit حتى التاريخ الذي يتلوها. + --author فقط أظهر عمليات commit التابعة لهذا الكاتب. + --committer فقط أظهر عمليات commit التابعة لهذا المعتمد. -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this: +على سبيل المثال، إذا أردت رؤية أي عمليات commit عدلت ملفات الاختبار في تأريخ الكود المصدري والتي قام Junio Hamano بعملها ولم يتم دمجها في شهر أوكتوبر 2008، يمكن كتابة هذا الأمر: $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ @@ -615,7 +615,7 @@ For example, if you want to see which commits modifying test files in the Git so 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria. +من بين 20 ألف عملية commit تقريباً في تأريخ git الخاص بهذا الكود المصدري، أظهر الأمر فقط عمليات الاعتماد الستة المطابقة لمحددات البحث. ### Using a GUI to Visualize History ### From 4577559eb6f77e233b8d221d75fd4a2ebc1e0225 Mon Sep 17 00:00:00 2001 From: Franz Holzinger Date: Wed, 24 Sep 2014 07:24:52 +0200 Subject: [PATCH 243/291] Update 01-chapter2.markdown Dateien, die bisher nocht nicht ==> 'noch nicht' --- de/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown index c4be80626..bb13f3dbd 100644 --- a/de/02-git-basics/01-chapter2.markdown +++ b/de/02-git-basics/01-chapter2.markdown @@ -115,7 +115,7 @@ Sagen wir Du fügst eine neue `README` Datei zu Deinem Projekt hinzu. Wenn die D -Alle Dateien, die in der Sektion „Untracked files“ aufgelistet werden, sind Dateien, die bisher nocht nicht versioniert sind. Dort wird jetzt auch die Datei `README` angezeigt. Mit anderen Worten, die Datei `README` wird in diesem Bereich gelistet, weil sie im letzen Snapshot (Commit) von Git nicht enthalten ist. Git nimmt eine solche Datei nicht automatisch in die Versionskontrolle auf, sondern man muss Git dazu ausdrücklich auffordern. Ansonsten würden generierte Binärdateien oder andere Dateien, die Du nicht in Deinem Repository haben willst, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie deshalb zur Versionskontrolle hinzu. +Alle Dateien, die in der Sektion „Untracked files“ aufgelistet werden, sind Dateien, die bisher noch nicht versioniert sind. Dort wird jetzt auch die Datei `README` angezeigt. Mit anderen Worten, die Datei `README` wird in diesem Bereich gelistet, weil sie im letzen Snapshot (Commit) von Git nicht enthalten ist. Git nimmt eine solche Datei nicht automatisch in die Versionskontrolle auf, sondern man muss Git dazu ausdrücklich auffordern. Ansonsten würden generierte Binärdateien oder andere Dateien, die Du nicht in Deinem Repository haben willst, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie deshalb zur Versionskontrolle hinzu. ### Neue Dateien zur Versionskontrolle hinzufügen ### From c2c69ebe94d423458ef8d670bda7602a73436d4a Mon Sep 17 00:00:00 2001 From: Franz Holzinger Date: Wed, 24 Sep 2014 07:27:00 +0200 Subject: [PATCH 244/291] Update 01-chapter3.markdown Mit anderen Worten kann Git den neuen Commit, durch verfolgen der Commitabfolge ==> "durch Verfolgen" --- de/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown index fd2081a01..aa24fbd22 100644 --- a/de/03-git-branching/01-chapter3.markdown +++ b/de/03-git-branching/01-chapter3.markdown @@ -280,7 +280,7 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü -Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit, durch verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt. +Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit, durch Verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt. From 22b36e13d62dad0a933f79a8fccb0c6f20c51791 Mon Sep 17 00:00:00 2001 From: Franz Holzinger Date: Wed, 24 Sep 2014 07:30:48 +0200 Subject: [PATCH 245/291] Update 01-chapter3.markdown Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen: ==> "Um einen lokalen Branch mit einem anderen Namen zu versehen als jenem im Remote-Branch, kannst Du einfach die erste Variante mit einem neuen lokalen Branch-Namen verwenden:" --- de/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown index aa24fbd22..f37dca23d 100644 --- a/de/03-git-branching/01-chapter3.markdown +++ b/de/03-git-branching/01-chapter3.markdown @@ -724,7 +724,7 @@ Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, wel -Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen: +Um einen lokalen Branch mit einem anderen Namen zu versehen als jenem im Remote-Branch, kannst Du einfach die erste Variante mit einem neuen lokalen Branch-Namen verwenden: $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. From d72851e87037b00dff48da717b5b205e4e050b6f Mon Sep 17 00:00:00 2001 From: Cheng Lian Date: Sat, 27 Sep 2014 14:53:56 +0800 Subject: [PATCH 246/291] Update 01-chapter9.markdown --- zh/09-git-internals/01-chapter9.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown index 0c29420fc..5b4e631bb 100644 --- a/zh/09-git-internals/01-chapter9.markdown +++ b/zh/09-git-internals/01-chapter9.markdown @@ -109,7 +109,7 @@ Git 初始化了 `objects` 目录，同时在该目录下创建了 `pack` 和 `i 100644 blob 8f94139338f9404f26296befa88755fc2598c289 Rakefile 040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0 lib -`master^{tree}` 表示 `branch` 分支上最新提交指向的 tree 对象。请注意 `lib` 子目录并非一个 blob 对象，而是一个指向另一个 tree 对象的指针： +`master^{tree}` 表示 `master` 分支上最新提交指向的 tree 对象。请注意 `lib` 子目录并非一个 blob 对象，而是一个指向另一个 tree 对象的指针： $ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0 100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b simplegit.rb From 978b7dd809ff21b02efe9af6c7deece97980dcbb Mon Sep 17 00:00:00 2001 From: Marco Buttu Date: Tue, 30 Sep 2014 16:26:52 +0200 Subject: [PATCH 247/291] Fixed some typos in the section "Per Iniziare - Basi di Git" --- it/01-introduction/01-chapter1.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown index 85216ff53..18a222ff6 100644 --- a/it/01-introduction/01-chapter1.markdown +++ b/it/01-introduction/01-chapter1.markdown @@ -41,7 +41,7 @@ Inoltre, molti di questi sistemi trattano bene l'avere più repository remoti su ## Una Breve Storia di Git ## -Come per molte grandi cose della vita, Git è nato con un po' di distruzione creativa e polemiche infuocate. Il kernel di Linux è un progetto software open source di grande portata abbastanza. Per buona parte del tempo (1991-2002) della manutenzione del kernel Linux le modifiche al software venivano passate sotto forma di patch e file compressi. Nel 2002, il progetto del kernel Linux iniziò ad utilizzare un sistema DVCS proprietario chiamato BitKeeper. +Come per molte grandi cose della vita, Git è nato con un po' di distruzione creativa e polemiche infuocate. Il kernel di Linux è un progetto software open source di grande portata. Per buona parte del tempo (1991-2002) della manutenzione del kernel Linux le modifiche al software venivano passate sotto forma di patch e file compressi. Nel 2002, il progetto del kernel Linux iniziò ad utilizzare un sistema DVCS proprietario chiamato BitKeeper. Nel 2005 il rapporto tra la comunità che sviluppa il kernel Linux e la società commerciale che aveva sviluppato BitKeeper si ruppe, e fu revocato l'uso gratuito di BitKeeper. Ciò indusse la comunità di sviluppo di Linux (e in particolare Linus Torvalds, il creatore di Linux) a sviluppare uno strumento proprio, basandosi su alcune delle lezioni apprese durante l'utilizzo di BitKeeper. Alcuni degli obiettivi del nuovo sistema erano i seguenti: @@ -69,7 +69,7 @@ Git non considera i dati né li registra in questo modo. Git considera i propri Insert 18333fig0105.png Figura 1-5. Git immagazzina i dati come snapshot del progetto nel tempo. -Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a dispoizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati vedremo le ramificazioni (i _branch_) in Git nel Capitolo 3. +Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a disposizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati e vedremo le ramificazioni (i _branch_) in Git nel Capitolo 3. ### Quasi Tutte le Operazioni Sono Locali ### @@ -81,13 +81,13 @@ Questo significa anche che sono pochissime le cose che non puoi fare se sei offl ### Git Ha Integrità ### -Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capira che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene. +Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capitare che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene. Il meccanismo che Git usa per fare questo checksum è un hash chiamato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come: 24b9da6552252987aa493b52f8696cd6d3b00373 -Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa non in base al nome del file, ma nel suo database indirizzabile per l'hash del suo contenuto. +Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa nel suo database, e il riferimento ad un file non è basato sul nome del file, ma sull'hash del suo contenuto. ### Git Generalmente Aggiunge Solo Dati ### @@ -97,7 +97,7 @@ Questo rende piaceole l'uso di Git perché sappiamo che possiamo sperimentare se ### I Tre Stati ### -Ora, presta attenzione. La prima cosa da ricordare sempre di Git se vuoi affrontare al meglio il processo di apprendimento. I tuoi file in Git possono essere in tre stati: _committed_ (committati), _modified_ (modificati) e _staged_ (in stage). Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit. +Ora, presta attenzione. La prima cosa da ricordare sempre di Git se vuoi affrontare al meglio il processo di apprendimento è che i tuoi file in Git possono essere in tre stati: _committed_ (committati), _modified_ (modificati) e _staged_ (in stage). Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit. Questo ci porta alle tre sezioni principali di un progetto Git: la directory di Git, la directory di lavoro e l'area di stage. @@ -113,8 +113,8 @@ L'area di stage è un file, contenuto generalmente nella directory di Git, con t Il flusso di lavoro (_workflow_) di base in Git funziona così: 1. Modifica i file nella tua directory di lavoro -2. Fanno lo stage, aggiungendone le istantanee all'area di stage -3. Committa, che salva i file nell'area di stage in un'istantanea (_snapshot_) permanente nella tua directory di Git. +2. Fanne lo stage, aggiungendone le istantanee all'area di stage +3. Committa, ovvero salva i file nell'area di stage in un'istantanea (_snapshot_) permanente nella tua directory di Git. Se una particolare versione di un file è nella directory git, viene considerata già committata. Se il file è stato modificato, ma è stato aggiunto all'area di staging, è _in stage_. E se è stato modificato da quando è stata estratto, ma non è _in stage_, è modificato. Nel Capitolo 2, imparerai di più su questi stati e come trarne vantaggio o saltare la parte di staging. From 1b9f2649f922747ff7c8927b1274070afbcdb0ba Mon Sep 17 00:00:00 2001 From: proSoHard Date: Wed, 1 Oct 2014 14:12:15 +0700 Subject: [PATCH 248/291] Corrected: decimal, not hex --- en/09-git-internals/01-chapter9.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown index 07101cddd..c64266683 100644 --- a/en/09-git-internals/01-chapter9.markdown +++ b/en/09-git-internals/01-chapter9.markdown @@ -718,7 +718,7 @@ For example, say you run `git push origin master` in your project, and `origin` The `git-receive-pack` command immediately responds with one line for each reference it currently has — in this case, just the `master` branch and its SHA. The first line also has a list of the server’s capabilities (here, `report-status` and `delete-refs`). -Each line starts with a 4-byte hex value specifying how long the rest of the line is. Your first line starts with 005b, which is 91 in hex, meaning that 91 bytes remain on that line. The next line starts with 003e, which is 62, so you read the remaining 62 bytes. The next line is 0000, meaning the server is done with its references listing. +Each line starts with a 4-byte hex value specifying how long the rest of the line is. Your first line starts with 005b, which is 91 in decimal, meaning that 91 bytes remain on that line. The next line starts with 003e, which is 62, so you read the remaining 62 bytes. The next line is 0000, meaning the server is done with its references listing. Now that it knows the server’s state, your `send-pack` process determines what commits it has that the server doesn’t. For each reference that this push will update, the `send-pack` process tells the `receive-pack` process that information. For instance, if you’re updating the `master` branch and adding an `experiment` branch, the `send-pack` response may look something like this: From 1db3e3d817cb71eccc8c1ba9586357e4f2f04d96 Mon Sep 17 00:00:00 2001 From: proSoHard Date: Wed, 1 Oct 2014 11:48:57 +0700 Subject: [PATCH 249/291] Windows guide to make ebooks epub mobi --- README.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 0230cddf5..b6556fd75 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,7 @@ On Fedora (16 and later) you can run something like this:: $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug rubygem-rdiscount $ makeebooks en # will produce a mobi -On MacOS you can do like this:: +On MacOS you can do like this: 1. INSTALL ruby and rubygems 2. `$ gem install rdiscount` @@ -31,6 +31,18 @@ On MacOS you can do like this:: * xelatex: http://tug.org/mactex/ 4. `$ makeebooks zh` #will produce a mobi +On Windows you can do like this: + +1. Install ruby and related tool from http://rubyinstaller.org/downloads/ + * RubyInstaller (ruby & gem) + * Development Kit (to build rdiscount gem) +2. Open `cmd` and `$ gem install rdiscount` +3. Install Calibre for Windows from http://calibre-ebook.com/download +4. `$ SET ebook_convert_path=c:\Program Files\Calibre2\ebook-convert.exe`. Modify to suit with your Calibre installed path. +5. Make ebooks: + * `$ ruby makeebooks vi` #will produce a mobi + * `$ SET FORMAT=epub` then `$ ruby makeebooks vi` #will produce an epub + ## Notes on pandoc Please use Pandoc version 1.11.1 or later as older versions (confirmed on 1.9.1.1) has a [bug](https://github.com/jgm/pandoc/issues/964) which hides a word after tilde `~`. You can do `pandoc -v` to see which version you have installed. From 8b5b4cf8895d4028c088ef96ebe0106638f5036f Mon Sep 17 00:00:00 2001 From: Marco Buttu Date: Fri, 3 Oct 2014 16:15:56 +0200 Subject: [PATCH 250/291] fixed some typos --- it/02-git-basics/01-chapter2.markdown | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index b3621e6f9..2c519d965 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -192,7 +192,7 @@ Il pattern `**/` è disponibile in Git dalla version 1.8.2. Se `git status` è troppo vago per te - vuoi sapere cos'è stato effettivamente modificato e non solo quali file — puoi usare il comando `git diff`. Tratteremo più avanti `git diff` con maggior dettaglio, ma probabilmente lo userai molto spesso per rispondere a queste due domande: Cos'è che hai modificato ma non è ancora in `stage`? E cos'hai nello `stage` che non hai ancora committato? Sebbene `git status` risponda a queste domande in modo generico, `git diff` mostra le righe effettivamente aggiunte e rimosse — la patch così com'è. -Supponiamo che tu habbia modificato nuovamente `README` e `benchmarks.rb` ma messo nello `stage` solo il primo. Se esegui il comando `status`, vedrai qualcosa come questo: +Supponiamo che tu abbia modificato nuovamente `README` e `benchmarks.rb` ma messo nello `stage` solo il primo. Se esegui il comando `status`, vedrai qualcosa come questo: $ git status On branch master @@ -611,7 +611,7 @@ Queste sono solo alcune opzioni semplici per la formattazione dell'output di `gi Opzione Descrizione @@ -717,7 +717,7 @@ Ci sono circa 20,000 commit nella cronologia dei sorgenti di git, questo comando ### Usare una GUI per visualizzare la cronologia ### -Se vuoi usare uno strumento più grafico per visualizzare la cronologia delle tuoe commit, puoi provare un programma in Tck/Tk chiamato `gitk` che viene distribuito con Git. Gitk è fondamentalmente uno strumento grafico come `git log`, e accetta quasi tutte le opzioni di filtro supportate da `git log`. Se digiti `gitk` dalla riga di comando nel tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2. +Se vuoi usare uno strumento più grafico per visualizzare la cronologia delle tue commit, puoi provare un programma in Tck/Tk chiamato `gitk` che viene distribuito con Git. Gitk è fondamentalmente uno strumento grafico come `git log`, e accetta quasi tutte le opzioni di filtro supportate da `git log`. Se digiti `gitk` dalla riga di comando nel tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2. Insert 18333fig0202.png Figura 2-2. Il grafico della cronologia con gitk. @@ -983,7 +983,7 @@ Creare un'etichetta annotate in Git è semplice. Il modo più facile è specific v1.3 v1.4 -`-m` specifica il messaggio per l'etichetta, che viene salvato con l'a stessa. Se non specifichi un messaggio per un'etichetta annotata, Git lancerà il tuo editor così da scriverla. +`-m` specifica il messaggio per l'etichetta, che viene salvato con la stessa. Se non specifichi un messaggio per un'etichetta annotata, Git lancerà il tuo editor così da scriverla. Puoi vedere i dati dell'etichetta assieme alla commit etichettata con il comando `git show`: @@ -1059,7 +1059,7 @@ Se ora lanci `git show` per questa etichetta, non vedrai altre informazioni aggi ### Verificare le etichette ### -Per verificarele un'etichetta firmata, usa `git tag -v [nome-tag]`. Questo comando usa GPG per verificare la verifica. Affinché funzioni hai bisogno che la chiave pubblica del firmatario sia nel tuo portachiavi: +Per verificare un'etichetta firmata, usa `git tag -v [nome-tag]`. Questo comando usa GPG per verificare la verifica. Affinché funzioni hai bisogno che la chiave pubblica del firmatario sia nel tuo portachiavi: $ git tag -v v1.4.2.1 object 883653babd8ee7ea23e6a5c392bb739348b1eb61 @@ -1162,7 +1162,7 @@ Se usi una shell Bash, Git fornisce uno script carino per il completamento autom source ~/.git-completion.bash -Se vuoi che Git usi il comletamento automatico in Bash per tutti gli utenti, copia lo script nella directory `/opt/local/etc/bash_completion.d` sui sistemi Mac o in `/etc/bash_completion.d/` sui sistemi Linux. Questa è una directory di script che Bash carica automaticamente, per fornire il completamento automatico nella shell. +Se vuoi che Git usi il completamento automatico in Bash per tutti gli utenti, copia lo script nella directory `/opt/local/etc/bash_completion.d` sui sistemi Mac o in `/etc/bash_completion.d/` sui sistemi Linux. Questa è una directory di script che Bash carica automaticamente, per fornire il completamento automatico nella shell. Se stai usando Windows con Git Bash, che è il predefinito quando installi Git su Windows con msysGit, il completamento automatico dovrebbe essere preconfigurato. From e431db502444441473b1be7ef8d02ca86c42a628 Mon Sep 17 00:00:00 2001 From: Marco Buttu Date: Fri, 3 Oct 2014 16:56:29 +0200 Subject: [PATCH 251/291] other typos in git basics --- it/02-git-basics/01-chapter2.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown index 2c519d965..c2512d22b 100644 --- a/it/02-git-basics/01-chapter2.markdown +++ b/it/02-git-basics/01-chapter2.markdown @@ -79,7 +79,7 @@ Per iniziare a tracciare un nuovo file, si usa il comando `git add`. Per traccia $ git add README -Se lanci nuovamente il comando per lo stato, puoi vedere il tuo file `README` ora è tracciato e nell'area si `stage`: +Se lanci nuovamente il comando per lo stato, puoi vedere che il tuo file `README` ora è tracciato e nell'area di `stage`: $ git status On branch master @@ -109,7 +109,7 @@ Modifichiamo un file che è già tracciato. Se modifichi un file tracciato chiam modified: benchmarks.rb -Il file benchmarks.rb appare nella sezione chiamata "Changes not staged for commit" — che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add` (è un comando multifunzione — lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose segnare come risolti i conflitti causati da un `merge`). Esegui `git add` per mettere in `stage` il file benchmarks.rb, e riesegui `git status`: +Il file benchmarks.rb appare nella sezione chiamata "Changes not staged for commit" — che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add` (è un comando multifunzione — lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose, ad esempio per segnare come risolti i conflitti causati da un `merge`). Esegui `git add` per mettere in `stage` il file benchmarks.rb, e riesegui `git status`: $ git add benchmarks.rb $ git status @@ -139,7 +139,7 @@ Entrambi i file sono nello `stage` e staranno nella prossima commit. A questo pu modified: benchmarks.rb -Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`. Come è possibile? È saltato fuori che Git ha messo in `stage` il file esattamente com'era quando hai eseguito `git add`. Se committi ora, la versione di `benchmarks.rb` che verrà committata sarà quella che avevi quando hai eseguito il `git add`, non la versione del file che trovi nella directory di lavoro quando esegui `git commit`. Se modifichi un file dopo che hai eseguito `git add`, ridevi eseguire `git add` per mettere nello `stage` l'ultima versione del file: +Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`. Come è possibile? È saltato fuori che Git ha messo in `stage` il file esattamente com'era quando hai eseguito `git add`. Se committi ora, la versione di `benchmarks.rb` che verrà committata sarà quella che avevi quando hai eseguito il `git add`, non la versione del file che trovi nella directory di lavoro quando esegui `git commit`. Se modifichi un file dopo che hai eseguito `git add`, devi rieseguire `git add` per mettere nello `stage` l'ultima versione del file: $ git add benchmarks.rb $ git status @@ -153,7 +153,7 @@ Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage` ### Ignorare File ### -Spesso hai un tipo di file che non vuoi che Git li aggiunga automaticamente e nemmeno te li mostri come tracciati. Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare. Questo è un `.gitignore` d'esempio: +Spesso hai dei file che non vuoi che Git aggiunga automaticamente e nemmeno che te li mostri come tracciati. Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare. Questo è un `.gitignore` d'esempio: $ cat .gitignore *.[oa] @@ -170,7 +170,7 @@ Queste sono le regole per i pattern che puoi usare in `.gitignore`: I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. L'asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso `a`, `b`, o `c`); il punto interrogativo (`?`) corrisponden ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere all'interno dell'intervallo (in questo caso da 0 a 9). -Questo è un altro esempio di file .gitignore: +Questo è un altro esempio di file `.gitignore`: # un commento - questo è ignorato # escludi i file .a From 7cdcc04dcd312f4844fb7cec07be75e0df2f7a5c Mon Sep 17 00:00:00 2001 From: Southparkfan Date: Tue, 7 Oct 2014 18:21:00 +0200 Subject: [PATCH 252/291] Spelling - locale -> lokale --- nl/04-git-server/01-chapter4.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown index 1068d2e82..ab47353e7 100644 --- a/nl/04-git-server/01-chapter4.markdown +++ b/nl/04-git-server/01-chapter4.markdown @@ -450,7 +450,7 @@ Je bent nu klaar voor de start. Als je alles juist hebt ingesteld, kun je nu met Dat betekent dat Gitosis je herkend heeft, maar je buitensluit omdat je geen Git commando's aan het doen bent. Dus, laten we een echt Git commando doen; je gaat de Gitosis beheer repository clonen: - # op je locale computer + # op je lokale computer $ git clone git@gitserver:gitosis-admin.git Nu heb je een directory genaamd `gitosis-admin`, die twee hoofd gedeeltes heeft: @@ -493,7 +493,7 @@ Wanneer je wijzigingen aan het `gitosis-admin` project maakt, moet je de verande To git@gitserver:gitosis-admin.git fb27aec..8962da8 master -> master -Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als een remote aan je locale versie van je project toe te voegen en te pushen. Je hoeft geen bare repositories handmatig meer te maken voor nieuwe projecten op de server — Gitosis maakt ze automatisch als het de eerste push ziet: +Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als een remote aan je lokale versie van je project toe te voegen en te pushen. Je hoeft geen bare repositories handmatig meer te maken voor nieuwe projecten op de server — Gitosis maakt ze automatisch als het de eerste push ziet: $ git remote add origin git@gitserver:iphone_project.git $ git push origin master From 8583ee115684941ab3b749a1f84a041bf538d698 Mon Sep 17 00:00:00 2001 From: nesrinkalender Date: Wed, 8 Oct 2014 12:02:16 +0300 Subject: [PATCH 253/291] 3. chapter Summary translated --- tr/03-git-branching/01-chapter3.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown index a9a150577..d8105b75d 100644 --- a/tr/03-git-branching/01-chapter3.markdown +++ b/tr/03-git-branching/01-chapter3.markdown @@ -593,6 +593,6 @@ You have to merge that work in at some point so you can keep up with the other d If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble. -## Summary ## +## Özet ## -We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. +Git'in temel branch ve merge işlemlerinden bahsettik. Artık rahatça yeni branch oluşturabilir, branchler arasından geçiş yapabilir ve local branchler ile merge işlemi yapabilirsiniz. Aynı zamanda branchlerinizi paylaşılan bir sunucuya göndererek paylaşabilmelisiniz ya da başkalarıyla ortak branchlerde çalışabilmeli ve branchlerinizi paylaşmadan önce rebase edebilmelisiniz. From 6f19538993ca43f5c06ba7e6865c3c4a862b45ee Mon Sep 17 00:00:00 2001 From: nesrinkalender Date: Thu, 9 Oct 2014 15:50:14 +0300 Subject: [PATCH 254/291] Add 4. chapter and translate until The SSH Protocol --- tr/04-git-server/01-chapter4.markdown | 47 +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 tr/04-git-server/01-chapter4.markdown diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown new file mode 100644 index 000000000..77290b36a --- /dev/null +++ b/tr/04-git-server/01-chapter4.markdown @@ -0,0 +1,47 @@ +# Uzak Serverda Git # + +Şu anda, Git kullanırken günlük ihtiyacınız olacak işleri yapabiliyor olmalısınız. Ancak, Git üzerinde takım arkadaşlarınızla işbirliğinde bulunmak için bir uzak Git reposuna ihtiyacınız var. Diğer insanların yerel repoları üzerinde pull ya da push işlemleri yapmanız teknik olarak mümkün olsa da, bunu yapmak cesurcadır çünkü dikkatli olmazsanız insanların çalışmalarını karman çorman etmek oldukça kolaydır. Bunun dışında, ulaşmak istediğiniz Git reposunun sahibi offline olsa da ulaşabileceğiniz ve doğruluğu daha güvenilir ortak bir repo genellikle kullanışlı bir seçenektir. Bunun için, takım arkadaşlarıyla işbirliğinde tercih edilen en yaygın yöntem, takımdaki insanların yazma ve okuma izinlerinin olduğu ortak bir repo kullanmaktır. Bu ortak repoya bundan sonra "Git Sunucusu" diyeceğiz. Fakat yakında farkedeceğiniz üzere Git çok az sistem kaynağı kullanır ve bunun için bütün bir sunucu kullanmaya genelde gerek olmaz. + +Bir Git Suncusu çalıştırmak kolaydır. Öncelikle, sunucunuzla hangi protokollerden iletişim kuracağınızı belirlemelisiniz. Bu bölümün ilk kısmında mevcut protokoller ve bunları artıları/eksilerinden bahsedeceğiz. Gelecek bölümlerde ise bu protokollerı kullanarak bazı tipik kurulumlarla sunucunuzu nasıl ayağa kaldıracağınızı anlatacağız. Son olarak, bazı hosted(3. kişiler tarafından barındırılan) servislerden bahsedeceğiz. Eger kodunuzun başka insanların sunucularında barınması sizin için problem değilse ve bakım-kurulum işleri ile uğraşmak istemiyorsanız bu seçenekleri de değerlendirebilirsiniz. + +Eğer kendi sunucunuzu kurmak ile ilgilenmiyorsanız, doğrudan bu bölümün son kısmına geçebilir ve kullanabileceğiniz bazı servisleri görebilirsiniz. Sonrasında dağıtık kaynak kontrol ortamlarında çalışmanın getiri ve götürülerinden bahsedeceğimiz bir sonraki bölüme geçebilirsiniz. + +Bir uzak repo _çıplak(bare) repo_ genellikle hiç bir şey eklenmemiş, boş bir haldedir. Repo yalnızca işbirliği noktası olarak kullanılacağından, projenin disk üzerinde bir kopyasını tutmak anlamsızdır. Yalnızca Git bilgisi yeterlidir. En basit anlatımıyla, çıplak repo projeinizin yalnızca `.git` klasörünü içerir. + +## Protokoller ## + +Git data transferi için başlıca dört adet ağ protokolü kullanır: Local, Secure Shell (SSH), Git and HTTP. Burada bu protokoller nedir ve temel koşullarda hangisini kullanmalıyız ya da kullanmamalıyoz tartışacağız. + +Burada önemli olarak HTTP protokolünü ayrı tutacağız, çünkü Git kurulan bütün serverlerda HTTP protokolü bulunması gerekir. + +### Lokal Protokoller ### + +En temel olanı, uzak reponun diskimizdeki başka bir klasör olduğu lokal protokoldür. Bu genellikle ekibinizdeki herkes NFS mount vb. şeklinde paylaşılan dosyalara erişiyorsa veya az kullanılan bir yöntem olarak; işler herkesin kullanıcı girişi yaptığı bir bilgisayar üzerinde yürütülüyorsa kullanılır. İkincisi ideal olmaz, çünkü tüm repoların aynı bilgisayarda bulunması bir kayıpta felaket olurdu. + +Eğer paylaşılan bir dosya sisteminiz varsa, local file-based reponuzdan clone,push ve pull işlemlerini yapabilirsiniz. Bunları yapmak için URL olarak reponuzun klasör yolunu kullanmalısınız. Örneğin, lokal repo kolanlayım, böyle bir komut çalıştırabilirsiniz. + + $ git clone /opt/git/project.git + +Ya da: + + $ git clone file:///opt/git/project.git + +Eğer URL'inizin başında açıkça `file://` belirtirseniz, Git biraz farklı çalışır. Sadece yolu belirtirseniz; ve kaynak ile hedef aynı dosya sisteminde ise, Git ihtiyacı olan objeleri hardlink ile bağlamaya çalışır. Eğer aynı dosya sisteminde değillerse; gerekli ihtiyacı olan dosyaları üzerinde bulunduğu sistemin standart kopyalama fonksiyonalitesini kullanarak kopyalayacaktır. Eğer `file://`ı belirtirseniz; Git normalde dosyaları transfer etmek için kullandığı ve daha verimsiz olan ağ üzerinden transfer yöntemini kullanmaz. `file://`ı belirtmenin ana sebebi genellikle başka bir versiyon kontrol sisteminden içe aktarma gibi işlemler yapıldıktan sonra (bakım işlemleri ile ilgili 9. bölümü inceleyin) yabancı referanslar ve kalıntı objeler içeren reponuzun temiz bir kopyasını almaktır. Biz daha hızlı olduğu için burada normal yolu kullanacağız. + +Varolan bir Git projesine lokal repo eklemek için aşağıdaki gibi bir kod çalıştırmalısınız; + + $ git remote add local_proj /opt/git/project.git + +Sonra, bir network üzerinden yapıyormuşsunuz gibi o remote üzerinde pull ve push yapabilirsiz. + +#### Artıları #### + +File-based depoların artıları basit olmaları ile mevcut dosya izinlerini ve ağ erişimini kullanabilir olmasıdır. Eğer paylaşılan bir dosya sisteminiz varsa, ekibiniz için bir repo kurmak çok kolay bir işlemdir. Herhangi diğer bir paylaşılan klasörde yaptığınız gibi, herkesin paylaşılan izinlerinin olduğu bare repo kopyasında kalırsınız ve yazma/okuma izinlerini ayarlayabilirsiniz. Bir sonraki bölümde “Serverda Git.” bare reponun kopyasını nasıl export alırız ele alacağız. + +Bu aynı zamanda başkasının reposundan çalışmasını hızlıca almak için güzel bir seçenek. Eğer siz ve arkadaşınız aynı projede çalışıyorsanız onlar sizin yaptıklarınızı kontrol etmek isteyeceklerdir, bunun için `git pull /home/john/project` gibi bir komut çalıştırmak genellikle servera push etmek ve pull etmekten daha kolaydır. + +#### Eksileri #### + +Bu yöntemin eksileri genellikle paylaşılan erişimi kurmak ve bir çok yerden erişmek temel ağ erişiminden daha zordur. Eğer evinizdeki bilgisiyarınızdan uzak diskinize push etmek istiyorsanız ağ tabanlı erişim zor ve yavaş olabilir. + +Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır. \ No newline at end of file From 9e060121abb6708a1e5b0f772cf7c5057de8a118 Mon Sep 17 00:00:00 2001 From: nesrinkalender Date: Thu, 9 Oct 2014 17:54:00 +0300 Subject: [PATCH 255/291] Add 4. chapter all --- tr/04-git-server/01-chapter4.markdown | 821 +++++++++++++++++++++++++- 1 file changed, 820 insertions(+), 1 deletion(-) diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown index 77290b36a..5ff831afb 100644 --- a/tr/04-git-server/01-chapter4.markdown +++ b/tr/04-git-server/01-chapter4.markdown @@ -44,4 +44,823 @@ Bu aynı zamanda başkasının reposundan çalışmasını hızlıca almak için Bu yöntemin eksileri genellikle paylaşılan erişimi kurmak ve bir çok yerden erişmek temel ağ erişiminden daha zordur. Eğer evinizdeki bilgisiyarınızdan uzak diskinize push etmek istiyorsanız ağ tabanlı erişim zor ve yavaş olabilir. -Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır. \ No newline at end of file +Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır. + +### SSH Protokolü ### + +Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır. + +Git reposunu SSH üzerinden clonelarken, URL'i ssh:// şeklinde belirtmelisiniz. Örnek: + + $ git clone ssh://user@server/project.git + +Ya da SSH için kısaca scp-like yazımını kullanabilirsiniz: + + $ git clone user@server:project.git + +Siz bir kullanıcı belirlemezseniz, Git geçerli oturum açmış olan kullanıcıyı varsayar. + +#### Artıları #### + +SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğre SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. + +#### Eksileri #### + +Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir. + +### Git Protokolü ### + +Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare. + +#### Artıları #### + +Git Protokol'ü mevcut en hızlı transfer protokolüdür. Eğer kimlik doğrulaması gerektirmeyen büyük bir projeniz varsa Git protokolü kullanmak doğru seçim olacaktır. Git Protokol'ü şifreleme ve kimlik doğrulama olmadan aynı mekanızmayı kullanır. + +#### Eksileri #### + +Git Protokolü'nün olumsuz yönlerinden bir tanesi doğrulama olmamasıdır. Projeye tek erişim olması istenmeyen bir durumdur. Genellik push (yazma) erişimine sahip geliştiriciler için SSH ile eşleştirme gerekir ve herkes `git://` kullanır. +Muhtemelen kurulumu en zor olan protokoldür. It must run its own daemon, which is custom — bu bölümün kurulumuna “Gitosis” kısmında değineceğiz — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. 9418 portuna erişebilmek için bir güvenlik duvarı karşınıza çıkacaktır bu port genellikle izin verilen bir port değildir. Büyük kurumların arkasındaki firewall'lar genellikle bu portu tanımaz ve bloke ederler. + +### HTTP / S Protokolü ### + +Son olarak HTTP / S Protokolü. Kurulum basitliği açısından en güzeli HTTP ya da HTTPS protokolüdür. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (Git hook hakkında bilgi için 7. bölüme bakınız). At that point, anyone who can access the web server under which you put the repository can also clone your repository. HTTP üzerinden reponuza erişim izni vermek için: + + $ cd /var/www/htdocs/ + $ git clone --bare /path/to/git_project gitproject.git + $ cd gitproject.git + $ mv hooks/post-update.sample hooks/post-update + $ chmod a+x hooks/post-update + +That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. SSH üzerinden bir repo pushlamak için bu komut çalıştırılır, ardından diğer insanlarda bu komut ile clonelayabilir. + + $ git clone http://example.com/gitproject.git + +In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. Git verileri statik dosyalar olarak tutulur. (detaylar için bölüm 9'a bakınız). + +HTTP üzerinden push yapmak mümkündür, yaygın olarak kullanılan bir teknik değildir ve karışık WebDAV gereksinimleri kurmayı gerektirir. Nadiren kullanıldığı için kitapta yer almıyor. Eğer HTTP ile push yapmak ile ilgileniyorsanız konu ile ilgili `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` linkini inceleyebilirsiniz. Bir diğer nokta eğer sunucunuz yazma ve güncelleme işlemleri için WebDAV destekliyorsa, belirli Git özellikleri olmadan, herhangi bir WebDAV sunucusu kullanabilirsiniz; + +#### Artıları #### + +En temel artısı kurulumu kolaydır. Sunduğu bir çok komut ile Git reponuza ulşamak için kolaylıklar sağlar. Ve bunu yapmak sadece birkaç dakika sürer. HTTP protokolü sunucunuz üzerinde bir yoğunluk yapmaz. Çünkü genellikle statik bir HTTP sunucusu kullanır, bir Apache server saniye binlerce dosya transfer edebilir fakat küçük sunucular için bu zor olabilir. + +You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS. + +Bir diğer güzel üzelliği de HTTP protokolü firewall tarafından tanınan yaygın bir protokoldür. + +#### Eksileri #### + +HTTP üzerinden reponuz için hizmet almanızın olumsuz yanı verimsiz olmasıdır. Genellikle klonlama işlemleri uzun sürer ve diğer ağ protokollerinden daha fazla ağ hacmi vardır. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. HTTP protokolü ve diğer protokoller hakkında verimlilik karşılaştırmaları için bölüm )'a bakınız. + +## Server'da Git ## + +Başlangıçta bir Git serverını ayarlamak için; varolan bir repoyu henuz hiç bir şey içermeyen, yeni bir repoya aktarmalısnız. +Yeni bir boş repo oluşturmak için, `--bare` seçeneği ile komutu çalıştırın. + + $ git clone --bare my_project my_project.git + Cloning into bare repository 'my_project.git'... + done. + +Şuan `my_project.git` dizininde Git dizinin bir kopyası bulunmaktadır. + +Bu komutta aynı işlemi yapar + + $ cp -Rf my_project/.git my_project.git + +Configrasyon dosyamızda birkaç küçük farklılık vardır; but for your purpose, this is close to the same thing. Bir çalışma dizini olmadan kendi başına Git deposunu alır, ve yalnız bunun için özel bir dizin oluşturur. + +### Server'a Boş Bir Dizin Oluşturmak ### + +Elimizde bol bir dizinimiz var, tüm yapmamız gereken bunu server'a koymak ve protokol ayarlarını yapmak. SSH erişimi olan ve `git.example.com` adında bir server kurduğumuzu varsayalım, ve `/opt/git` dizini altında tüm depolarımızı saklayalım. Boş reponuzu kopyalayarak yeni repo oluşturabilirsiniz: + + $ scp -r my_project.git user@git.example.com:/opt/git + +Bu noktada `/opt/git` dizinine okuma ve SSH erişimi olan kullanıcılar aşağıdaki komut ile reponuzu klonlayabilir + + $ git clone user@git.example.com:/opt/git/my_project.git + +Bir kullanıcnın server içinde SSHs ve `/opt/git/my_project.git` dizinine yazma erişimi varsa, otomatik olarak push yapma izni olacaktır. Eğer `git init` komutunu `--shared` seçeneği ile çalıştırırsanız Git uygun olarak izinleri verecektir. + + $ ssh user@git.example.com + $ cd /opt/git/my_project.git + $ git init --bare --shared + +Git üzerinde boş bir repo oluşturmak ve SSH izinleri vermenin ne kadar kolay olduğunu gördünüz. Şimdi projelerde birlikte çalışabilirsiniz. + +It’s important to note that this is literally all you need to do to run a useful Git server to which several people have access — just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You’re ready to go — nothing else needed. + +Önümüzdeki bölümlerde, daha sofistike kurulumları göreceğiz. Bunlar kullanıcı izinleri, web UI kurmak, Gitosis aracını kullanarak ve daha fazla, her kullanıcı için kullanıcı hesapları oluşturmak zorunda değiliz gibi konular. However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository. + +### Küçük Ayarlar ### + +Eğer kuruluşunuza Git ile çalışıyorsanız ve birkaç developer varsa bu işler sizin için kolay olabilir. Bir Git sunucusu kurmanın en karmaşık yönlerinden biri, kullanıcı yönetimidir. Bazı repolar için belirli kullanıcılara okuma bazılarına okuma/yazma erişimi vermek istiyorsanız izinleri düzenlemek zor olabilir. + +#### SSH Erişimi #### + +Eğer mevcut server'ınıza tüm developerların SSH erişimi var ise ilk repo kurulumu için pek bir iş yapmanız gerekmiyor (son bolumde bahsettiğimiz gibi). Eğer daha complex erişim izinleri istiyorsanız, sunucuda çalışan işletim sisteminin normal dosya sistemi izinleri ile düzenleyebilirsiniz. + +If you want to place your repositories on a server that doesn’t have accounts for everyone on your team whom you want to have write access, o zaman onlar için SSH erişimi kurmanız gerekiyor. Biz bunu yapmak için SSH sunucusunun yüklü olduğu bir sunucunuz varsayalım. + +Takımdaki herkese erişim vermenin birkaç yolu vardır. İlki basittir ama biraz zahmetli olabilir, herkes için bir hesap oluşturmak. `adduser` çalıştırmak ve her kullanıcı için geçici parolalar oluşturmak istemeyebilirsiniz.. + +İkinci method tek bir 'git' kullanıcısı oluşturmak, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. Bu noktada, herkes 'git' kullanıcısı ile bu makineye erişebilecek. This doesn’t affect the commit data in any way — the SSH user you connect as doesn’t affect the commits you’ve recorded. + +Bunu yapmanın bir başka yolu, bir LDAP sunucusuna veya zaten kurdunuz bazı diğer merkezi kimlik doğrulama kaynağından SSH sunucusu kimlik doğrulamasına sahip olmaktır. Böylece her kullanıcı makine üzerinden shell erişimi alabilir. + +## SSH Key Oluşturmak ## + +Git serverlerda kimlik doğrulaması için SSH public keys kullanıyor. Eğer oluşturulmuş yoksa her kullanıcı için sistem bir key oluşturur. İlk olarak hazırda bir key var mı kontrol edilir. Varsayılan olarak, bir kullanıcının SSH anahtarları o kullanıcının ~ /. ssh dizininde depolanır. Eğer oluşturulmuş bir key varsa onu kolayca listeleyebilirsiniz. + + $ cd ~/.ssh + $ ls + authorized_keys2 id_dsa known_hosts + config id_dsa.pub + +Dosyalarına baktığında iki şey arıyoruz something and something.pub, burada genellikle bir şey `id_dsa` or `id_rsa`. `.pub` dosya ortak anahtardır, ve diğer dosyaların özel anahtarıdır. Eğer bu dosyalar yok ise (or you don’t even have a `.ssh` directory), `ssh-keygen` ile bu dosyaları oluşturabilirsiniz, Linux/Mac sistemlerinde SSH paketi Windows MSysGit paketi ile geliyor: + + $ ssh-keygen + Generating public/private rsa key pair. + Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): + Enter passphrase (empty for no passphrase): + Enter same passphrase again: + Your identification has been saved in /Users/schacon/.ssh/id_rsa. + Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. + The key fingerprint is: + 43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local + +Eğer anahtarı kaydetmek isterseniz (`.ssh/id_rsa`) önce kaydetmek istediğiniz yeri sorar, ve sonra iki kez parolanızı sorar, eğer parolanızı yazmak istemiyorsanız boş geçin. + +Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). Yapmaları gereken `.pub` dosyasının ve içeriğini kopyalamak olduğunu bunu e-posta atmak. Örnek public key: + + $ cat ~/.ssh/id_rsa.pub + ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU + GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 + Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA + t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En + mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx + NrRFi9wrf+M7Q== schacon@agadorlaptop.local + +Birden fazla işletim sistemlerinde SSH key oluşturma ile ilgili kapsamlı bilgi için bknz: Github klavuzu SSH keys http://github.com/guides/providing-your-ssh-key. + +## Sunucu Kurma ## + +Şimdi baştan sona adım adım sunucu tarafına SSH erişimi kuralım. Bu örnekte, kullanıcılarınızı doğrulamak için `authorized_keys` methodu kullanacağız. Ayrıca Ubuntu gibi standart bir Linux dağıtımı kullanıyoruz varsayacağız. Öncelikle, bir 'git' kullanıcı ve bu kullanıcı için bir `.ssh` dizin oluşturun. + + $ sudo adduser git + $ su git + $ cd + $ mkdir .ssh + +Sonra, you need to add some developer SSH public keys to the `authorized_keys` file for that user. Let’s assume you’ve received a few keys by e-mail and saved them to temporary files. Yine, public keyimiz aşağıdaki gibi olacaktır: + + $ cat /tmp/id_rsa.john.pub + ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L + ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k + Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez + Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv + O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq + dAv8JggJICUvax2T9va5 gsg-keypair + +Sizin `authorized_keys` dosyanıza sadece bunlar eklenecek: + + $ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys + $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys + $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys + +Şimdi,boş bir repository oluşturmak için `git init` komutunu `--bare` özelliği ile çalıştırın, which initializes the repository without a working directory: + + $ cd /opt/git + $ mkdir project.git + $ cd project.git + $ git --bare init + +Sonra, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let’s use `gitserver` as the hostname of the server on which you’ve set up your 'git' user and repository. If you’re running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is: + + # on Johns computer + $ cd myproject + $ git init + $ git add . + $ git commit -m 'initial commit' + $ git remote add origin git@gitserver:/opt/git/project.git + $ git push origin master + +Bu noktada, yapılan değişiklikler kolayca yedeklenir: + + $ git clone git@gitserver:/opt/git/project.git + $ cd project + $ vim README + $ git commit -am 'fix for the README file' + $ git push origin master + +Bu method ile, kolayca Git server üzerinde okuma/yazma yapabilirsiniz. + +As an extra precaution, you can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. If you set this as your 'git' user’s login shell, then the 'git' user can’t have normal shell access to your server. To use this, specify `git-shell` instead of bash or csh for your user’s login shell. To do so, you’ll likely have to edit your `/etc/passwd` file: + + $ sudo vim /etc/passwd + +Alt kısımda bu şekilde bir çıktı görmelisiniz: + + git:x:1000:1000::/home/git:/bin/sh + +Change `/bin/sh` to `/usr/bin/git-shell` (or run `which git-shell` to see where it’s installed). Satırınız böyle görünmelidir: + + git:x:1000:1000::/home/git:/usr/bin/git-shell + +Şimdi, the 'git' user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this: + + $ ssh git@gitserver + fatal: What do you think I am? A shell? + Connection to gitserver closed. + +## Genel Erişim ## + +Peki projenize anonim olarak erişmek isterseniz? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don’t want to have to generate SSH keys all the time — you just want to add simple anonymous read access. + +Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that `post-update` hook we mentioned in the first section of this chapter. Let’s work from the previous example. Say you have your repositories in the `/opt/git` directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we’ll demonstrate some basic Apache configurations that should give you an idea of what you might need. + +Öncelikle hook'u etkinleştirmemiz gerekiyor: + + $ cd project.git + $ mv hooks/post-update.sample hooks/post-update + $ chmod a+x hooks/post-update + +Peki bu `post-update` hook ne yapar? Temelde şunları yapar: + + $ cat .git/hooks/post-update + #!/bin/sh + # + # An example hook script to prepare a packed repository for use over + # dumb transports. + # + # To enable this hook, rename this file to "post-update". + # + + exec git-update-server-info + +Bu SSH üzerinden sunucuya push yaptığınızda, Git HTTP almak için gereken dosyaları günceleyecek ve bu komutu çalıştıracak. + +Daha sonra, Apache sunucumuza VirtualHost girişi ekmemiz gerekecek. Here, we’re assuming that you have wildcard DNS set up to send `*.gitserver` to whatever box you’re using to run all this: + + + ServerName git.gitserver + DocumentRoot /opt/git + + Order allow, deny + allow from all + + + +You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read-access the repositories, çünkü CGI komut dosyası çalıştıran Apache örneği (varsayılan) kullanıcı olarak çalışıyor olacak. + + $ chgrp -R www-data /opt/git + +Apache'yi yeniden başlattığınızda, sizin projeniz dizininizin altında oluşan URL ile clonelanabilir: + + $ git clone http://git.gitserver/project.git + +This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we’ll cover this option in the next section, if you prefer that route. + +## GitWeb ## + +Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1). + +Insert 18333fig0401.png +Figure 4-1. The GitWeb web-based user interface. + +If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option. + + $ git instaweb --httpd=webrick + [2009-02-21 10:02:21] INFO WEBrick 1.3.1 + [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] + +That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It’s pretty easy on your part. When you’re done and want to shut down the server, you can run the same command with the `--stop` option: + + $ git instaweb --httpd=webrick --stop + +If you want to run the web interface on a server all the time for your team or for an open source project you’re hosting, you’ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. We’ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: + + $ git clone git://git.kernel.org/pub/scm/git/git.git + $ cd git/ + $ make GITWEB_PROJECTROOT="/opt/git" \ + prefix=/usr gitweb + $ sudo cp -Rf gitweb /var/www/ + +Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: + + + ServerName gitserver + DocumentRoot /var/www/gitweb + + Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch + AllowOverride All + order allow,deny + Allow from all + AddHandler cgi-script cgi + DirectoryIndex gitweb.cgi + + + +Again, GitWeb can be served with any CGI capable web server; if you prefer to use something else, it shouldn’t be difficult to set up. At this point, you should be able to visit `http://gitserver/` to view your repositories online, and you can use `http://git.gitserver` to clone and fetch your repositories over HTTP. + +## Gitosis ## + +Keeping all users’ public keys in the `authorized_keys` file for access works well only for a while. When you have hundreds of users, it’s much more of a pain to manage that process. You have to shell onto the server each time, and there is no access control — everyone in the file has read and write access to every project. + +At this point, you may want to turn to a widely used software project called Gitosis. Gitosis is basically a set of scripts that help you manage the `authorized_keys` file as well as implement some simple access controls. The really interesting part is that the UI for this tool for adding people and determining access isn’t a web interface but a special Git repository. You set up the information in that project; and when you push it, Gitosis reconfigures the server based on that, which is cool. + +Installing Gitosis isn’t the simplest task ever, but it’s not too difficult. It’s easiest to use a Linux server for it — these examples use a stock Ubuntu 8.10 server. + +Gitosis requires some Python tools, so first you have to install the Python setuptools package, which Ubuntu provides as python-setuptools: + + $ apt-get install python-setuptools + +Next, you clone and install Gitosis from the project’s main site: + + $ git clone https://github.com/tv42/gitosis.git + $ cd gitosis + $ sudo python setup.py install + +That installs a couple of executables that Gitosis will use. Next, Gitosis wants to put its repositories under `/home/git`, which is fine. But you have already set up your repositories in `/opt/git`, so instead of reconfiguring everything, you create a symlink: + + $ ln -s /opt/git /home/git/repositories + +Gitosis is going to manage your keys for you, so you need to remove the current file, re-add the keys later, and let Gitosis control the `authorized_keys` file automatically. For now, move the `authorized_keys` file out of the way: + + $ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak + +Next you need to turn your shell back on for the 'git' user, if you changed it to the `git-shell` command. People still won’t be able to log in, but Gitosis will control that for you. So, let’s change this line in your `/etc/passwd` file + + git:x:1000:1000::/home/git:/usr/bin/git-shell + +back to this: + + git:x:1000:1000::/home/git:/bin/sh + +Now it’s time to initialize Gitosis. You do this by running the `gitosis-init` command with your personal public key. If your public key isn’t on the server, you’ll have to copy it there: + + $ sudo -H -u git gitosis-init < /tmp/id_dsa.pub + Initialized empty Git repository in /opt/git/gitosis-admin.git/ + Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ + +This lets the user with that key modify the main Git repository that controls the Gitosis setup. Next, you have to manually set the execute bit on the `post-update` script for your new control repository. + + $ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update + +You’re ready to roll. If you’re set up correctly, you can try to SSH into your server as the user for which you added the public key to initialize Gitosis. You should see something like this: + + $ ssh git@gitserver + PTY allocation request failed on channel 0 + ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. + Connection to gitserver closed. + +That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository: + + # on your local computer + $ git clone git@gitserver:gitosis-admin.git + +Now you have a directory named `gitosis-admin`, which has two major parts: + + $ cd gitosis-admin + $ find . + ./gitosis.conf + ./keydir + ./keydir/scott.pub + +The `gitosis.conf` file is the control file you use to specify users, repositories, and permissions. The `keydir` directory is where you store the public keys of all the users who have any sort of access to your repositories — one file per user. The name of the file in `keydir` (in the previous example, `scott.pub`) will be different for you — Gitosis takes that name from the description at the end of the public key that was imported with the `gitosis-init` script. + +If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned: + + $ cat gitosis.conf + [gitosis] + + [group gitosis-admin] + members = scott + writable = gitosis-admin + +It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project. + +Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on: + + [group mobile] + members = scott + writable = iphone_project + +Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect: + + $ git commit -am 'add iphone_project and mobile group' + [master 8962da8] add iphone_project and mobile group + 1 file changed, 4 insertions(+) + $ git push origin master + Counting objects: 5, done. + Compressing objects: 100% (3/3), done. + Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:gitosis-admin.git + fb27aec..8962da8 master -> master + +You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push: + + $ git remote add origin git@gitserver:iphone_project.git + $ git push origin master + Initialized empty Git repository in /opt/git/iphone_project.git/ + Counting objects: 3, done. + Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. + Total 3 (delta 0), reused 0 (delta 0) + To git@gitserver:iphone_project.git + * [new branch] master -> master + +Notice that you don’t need to specify the path (in fact, doing so won’t work), just a colon and then the name of the project — Gitosis finds it for you. + +You want to work on this project with your friends, so you’ll have to re-add their public keys. But instead of appending them manually to the `~/.ssh/authorized_keys` file on your server, you’ll add them, one key per file, into the `keydir` directory. How you name the keys determines how you refer to the users in the `gitosis.conf` file. Let’s re-add the public keys for John, Josie, and Jessica: + + $ cp /tmp/id_rsa.john.pub keydir/john.pub + $ cp /tmp/id_rsa.josie.pub keydir/josie.pub + $ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub + +Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`: + + [group mobile] + members = scott john josie jessica + writable = iphone_project + +After you commit and push that change, all four users will be able to read from and write to that project. + +Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead: + + [group mobile] + members = scott josie jessica + writable = iphone_project + + [group mobile_ro] + members = john + readonly = iphone_project + +Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically: + + [group mobile_committers] + members = scott josie jessica + + [group mobile] + members = @mobile_committers + writable = iphone_project + + [group mobile_2] + members = @mobile_committers john + writable = another_iphone_project + +If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project. + +## Gitolite ## + +This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with. There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg]. + +[gldpg]: http://sitaramc.github.com/gitolite/progit.html +[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html + +Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to). + +Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others. + +### Installing ### + +Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind. You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed. In the examples below, we will use the `git` account on a host called `gitserver`. + +Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation. + +To begin, create a user called `git` on your server and login to this user. Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `.pub` (we'll use `scott.pub` in our examples). Then run these commands: + + $ git clone git://github.com/sitaramc/gitolite + $ gitolite/install -ln + # assumes $HOME/bin exists and is in your $PATH + $ gitolite setup -pk $HOME/scott.pub + +That last command creates new Git repository called `gitolite-admin` on the server. + +Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your Gitolite setup by making changes to this repository and pushing. + +### Customising the Install ### + +While the default, quick, install works for most people, there are some ways to customise the install if you need to. Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite. + +### Config File and Access Control Rules ### + +Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got: + + $ cd ~/gitolite-admin/ + $ ls + conf/ keydir/ + $ find conf keydir -type f + conf/gitolite.conf + keydir/scott.pub + $ cat conf/gitolite.conf + + repo gitolite-admin + RW+ = scott + + repo testing + RW+ = @all + +Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name. + +Adding users is easy. To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation. Add, commit, and push the change, and the user has been added. + +The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here. + +You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro". + + @oss_repos = linux perl rakudo git gitolite + @secret_repos = fenestra pear + + @admins = scott + @interns = ashok + @engineers = sitaram dilbert wally alice + @staff = @admins @engineers @interns + +You can control permissions at the "ref" level. In the following example, interns can only push the "int" branch. Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit. And the admins can do anything (including rewind) to any ref. + + repo @oss_repos + RW int$ = @interns + RW eng- = @engineers + RW refs/tags/rc[0-9] = @engineers + RW+ = @admins + +The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against. So we call it a "refex"! Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes. + +Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`. + +An important feature of the config file’s syntax is that all the rules for a repository need not be in one place. You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so: + + repo gitolite + RW+ = sitaram + +That rule will just get added to the ruleset for the `gitolite` repository. + +At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly. + +There are two levels of access control in Gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. This is the only access control that Gitosis had. + +The second level, applicable only to "write" access, is by branch or tag within a repository. The username, the access being attempted (`W` or `+`), and the refname being updated are known. The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched). If a match is found, the push succeeds. A fallthrough results in access being denied. + +### Advanced Access Control with "deny" rules ### + +So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`. However, Gitolite allows another permission: `-`, standing for "deny". This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*! + +Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ. Here’s how to do that: + + RW master integ = @engineers + - master integ = @engineers + RW+ = @engineers + +Again, you simply follow the rules top down until you hit a match for your access mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied. Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it. + +### Restricting pushes by files changed ### + +In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell Gitolite: + + repo foo + RW = @junior_devs @senior_devs + + - VREF/NAME/Makefile = @junior_devs + +Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details. + +### Personal Branches ### + +Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment. + +A lot of code exchange in the Git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there. + +This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin. + +Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal//*`); please see the documentation for details. + +### "Wildcard" repositories ### + +Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc. Again, please see the documentation for details. + +### Other Features ### + +We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation. + +**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed. + +**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here’s an example: + + hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4 + + R anu-wsd + R entrans + R W git-notes + R W gitolite + R W gitolite-admin + R indic_web_input + R shreelipi_converter + +**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently. This reduces the load on the main admin, and makes him less of a bottleneck. + +**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down. + +## Git Daemon ## + +For public, unauthenticated read access to your projects, you’ll want to move past the HTTP protocol and start using the Git protocol. The main reason is speed. The Git protocol is far more efficient and thus faster than the HTTP protocol, so using it will save your users time. + +Again, this is for unauthenticated read-only access. If you’re running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. If the server you’re running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don’t want to have to add an SSH key for each. + +In any case, the Git protocol is relatively easy to set up. Basically, you need to run this command in a daemonized manner: + + git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ + +`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on. + +You can daemonize this process a number of ways, depending on the operating system you’re running. On an Ubuntu machine, you use an Upstart script. So, in the following file + + /etc/event.d/local-git-daemon + +you put this script: + + start on startup + stop on shutdown + exec /usr/bin/git daemon \ + --user=git --group=git \ + --reuseaddr \ + --base-path=/opt/git/ \ + /opt/git/ + respawn + +For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories — you can easily do this by creating a new user 'git-ro' and running the daemon as them. For the sake of simplicity we’ll simply run it as the same 'git' user that Gitosis is running as. + +When you restart your machine, your Git daemon will start automatically and respawn if it goes down. To get it running without having to reboot, you can run this: + + initctl start local-git-daemon + +On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow. + +Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file: + + [repo iphone_project] + daemon = yes + +When that is committed and pushed up, your running daemon should start serving requests for the project to anyone who has access to port 9418 on your server. + +If you decide not to use Gitosis, but you want to set up a Git daemon, you’ll have to run this on each project you want the Git daemon to serve: + + $ cd /path/to/project.git + $ touch git-daemon-export-ok + +The presence of that file tells Git that it’s OK to serve this project without authentication. + +Gitosis can also control which projects GitWeb shows. First, you need to add something like the following to the `/etc/gitweb.conf` file: + + $projects_list = "/home/git/gitosis/projects.list"; + $projectroot = "/home/git/repositories"; + $export_ok = "git-daemon-export-ok"; + @git_base_url_list = ('git://gitserver'); + +You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this: + + [repo iphone_project] + daemon = yes + gitweb = yes + +Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`. + +## Hosted Git ## + +If you don’t want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code — it’s generally easier for the open source community to find and help you with. + +These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. To see an up-to-date list, check out the following page: + + https://git.wiki.kernel.org/index.php/GitHosting + +Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved. + +GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book. + +### GitHub ### + +GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project. + +GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done. + +### Setting Up a User Account ### + +The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. + +Insert 18333fig0402.png +Figure 4-2. The GitHub plan page. + +Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3). + +Insert 18333fig0403.png +Figure 4-3. The GitHub user signup form. + +If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems. +Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4). + +Insert 18333fig0404.png +Figure 4-4. The GitHub user dashboard. + +Next you can create a new repository. + +### Creating a New Repository ### + +Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5). + +Insert 18333fig0405.png +Figure 4-5. Creating a new repository on GitHub. + +All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6). + +Insert 18333fig0406.png +Figure 4-6. GitHub project header information. + +Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7). + +Insert 18333fig0407.png +Figure 4-7. Instructions for a new repository. + +These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use + + $ git init + $ git add . + $ git commit -m 'initial commit' + +When you have a Git repository locally, add GitHub as a remote and push up your master branch: + + $ git remote add origin git@github.com:testinguser/iphone_project.git + $ git push origin master + +Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8). + +Insert 18333fig0408.png +Figure 4-8. Project header with a public URL and a private URL. + +The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you. + +The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one. + +### Importing from Subversion ### + +If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9). + +Insert 18333fig0409.png +Figure 4-9. Subversion importing interface. + +If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports. + +### Adding Collaborators ### + +Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work. + +Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10). + +Insert 18333fig0410.png +Figure 4-10. GitHub administration page. + +To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11). + +Insert 18333fig0411.png +Figure 4-11. Adding a collaborator to your project. + +When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12). + +Insert 18333fig0412.png +Figure 4-12. A list of collaborators on your project. + +If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project. + +### Your Project ### + +After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13. + +Insert 18333fig0413.png +Figure 4-13. A GitHub main project page. + +When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information. + +### Projeleri Forklamak ### + +If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it. + +This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work. + +To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14). + +Insert 18333fig0414.png +Figure 4-14. Get a writable copy of any repository by clicking the "fork" button. + +After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15). + +Insert 18333fig0415.png +Figure 4-15. Your fork of a project. + +### GitHub Özeti ### + +That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly. + +## Özet ## + +You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. + +Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that. + +It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. From b1758890ccbafbe26f79b3b45b9fe1c1f69f9e15 Mon Sep 17 00:00:00 2001 From: nesrinkalender Date: Fri, 10 Oct 2014 17:54:31 +0300 Subject: [PATCH 256/291] update SSH Protocol --- tr/04-git-server/01-chapter4.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown index 5ff831afb..7308fc4aa 100644 --- a/tr/04-git-server/01-chapter4.markdown +++ b/tr/04-git-server/01-chapter4.markdown @@ -48,7 +48,7 @@ Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edeme ### SSH Protokolü ### -Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır. +Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır. Git reposunu SSH üzerinden clonelarken, URL'i ssh:// şeklinde belirtmelisiniz. Örnek: @@ -62,11 +62,11 @@ Siz bir kullanıcı belirlemezseniz, Git geçerli oturum açmış olan kullanıc #### Artıları #### -SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğre SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. +SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğeri SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Son olarak SSH'ın bir artısı da verileri akatarmadan önce mümkün olduğunca kompakt hale getiriyor. #### Eksileri #### -Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir. +Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir.Yalnızca kurumsal ağ içerisinde bunu kullanıyorsanız SSH kullanmanız gereken protokollerden belki de tekidir. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir. ### Git Protokolü ### From 11b94e362231f6a76a6eeadd6092660866bdb7a4 Mon Sep 17 00:00:00 2001 From: nesrinkalender Date: Mon, 13 Oct 2014 14:10:48 +0300 Subject: [PATCH 257/291] add chapter 5 and translate until Commit Guideline --- tr/04-git-server/01-chapter4.markdown | 795 +-------------------- tr/05-distributed-git/01-chapter5.markdown | 215 ++++++ 2 files changed, 216 insertions(+), 794 deletions(-) create mode 100644 tr/05-distributed-git/01-chapter5.markdown diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown index 7308fc4aa..a291eeba0 100644 --- a/tr/04-git-server/01-chapter4.markdown +++ b/tr/04-git-server/01-chapter4.markdown @@ -70,797 +70,4 @@ Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanları ### Git Protokolü ### -Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare. - -#### Artıları #### - -Git Protokol'ü mevcut en hızlı transfer protokolüdür. Eğer kimlik doğrulaması gerektirmeyen büyük bir projeniz varsa Git protokolü kullanmak doğru seçim olacaktır. Git Protokol'ü şifreleme ve kimlik doğrulama olmadan aynı mekanızmayı kullanır. - -#### Eksileri #### - -Git Protokolü'nün olumsuz yönlerinden bir tanesi doğrulama olmamasıdır. Projeye tek erişim olması istenmeyen bir durumdur. Genellik push (yazma) erişimine sahip geliştiriciler için SSH ile eşleştirme gerekir ve herkes `git://` kullanır. -Muhtemelen kurulumu en zor olan protokoldür. It must run its own daemon, which is custom — bu bölümün kurulumuna “Gitosis” kısmında değineceğiz — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. 9418 portuna erişebilmek için bir güvenlik duvarı karşınıza çıkacaktır bu port genellikle izin verilen bir port değildir. Büyük kurumların arkasındaki firewall'lar genellikle bu portu tanımaz ve bloke ederler. - -### HTTP / S Protokolü ### - -Son olarak HTTP / S Protokolü. Kurulum basitliği açısından en güzeli HTTP ya da HTTPS protokolüdür. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (Git hook hakkında bilgi için 7. bölüme bakınız). At that point, anyone who can access the web server under which you put the repository can also clone your repository. HTTP üzerinden reponuza erişim izni vermek için: - - $ cd /var/www/htdocs/ - $ git clone --bare /path/to/git_project gitproject.git - $ cd gitproject.git - $ mv hooks/post-update.sample hooks/post-update - $ chmod a+x hooks/post-update - -That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. SSH üzerinden bir repo pushlamak için bu komut çalıştırılır, ardından diğer insanlarda bu komut ile clonelayabilir. - - $ git clone http://example.com/gitproject.git - -In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. Git verileri statik dosyalar olarak tutulur. (detaylar için bölüm 9'a bakınız). - -HTTP üzerinden push yapmak mümkündür, yaygın olarak kullanılan bir teknik değildir ve karışık WebDAV gereksinimleri kurmayı gerektirir. Nadiren kullanıldığı için kitapta yer almıyor. Eğer HTTP ile push yapmak ile ilgileniyorsanız konu ile ilgili `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` linkini inceleyebilirsiniz. Bir diğer nokta eğer sunucunuz yazma ve güncelleme işlemleri için WebDAV destekliyorsa, belirli Git özellikleri olmadan, herhangi bir WebDAV sunucusu kullanabilirsiniz; - -#### Artıları #### - -En temel artısı kurulumu kolaydır. Sunduğu bir çok komut ile Git reponuza ulşamak için kolaylıklar sağlar. Ve bunu yapmak sadece birkaç dakika sürer. HTTP protokolü sunucunuz üzerinde bir yoğunluk yapmaz. Çünkü genellikle statik bir HTTP sunucusu kullanır, bir Apache server saniye binlerce dosya transfer edebilir fakat küçük sunucular için bu zor olabilir. - -You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS. - -Bir diğer güzel üzelliği de HTTP protokolü firewall tarafından tanınan yaygın bir protokoldür. - -#### Eksileri #### - -HTTP üzerinden reponuz için hizmet almanızın olumsuz yanı verimsiz olmasıdır. Genellikle klonlama işlemleri uzun sürer ve diğer ağ protokollerinden daha fazla ağ hacmi vardır. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. HTTP protokolü ve diğer protokoller hakkında verimlilik karşılaştırmaları için bölüm )'a bakınız. - -## Server'da Git ## - -Başlangıçta bir Git serverını ayarlamak için; varolan bir repoyu henuz hiç bir şey içermeyen, yeni bir repoya aktarmalısnız. -Yeni bir boş repo oluşturmak için, `--bare` seçeneği ile komutu çalıştırın. - - $ git clone --bare my_project my_project.git - Cloning into bare repository 'my_project.git'... - done. - -Şuan `my_project.git` dizininde Git dizinin bir kopyası bulunmaktadır. - -Bu komutta aynı işlemi yapar - - $ cp -Rf my_project/.git my_project.git - -Configrasyon dosyamızda birkaç küçük farklılık vardır; but for your purpose, this is close to the same thing. Bir çalışma dizini olmadan kendi başına Git deposunu alır, ve yalnız bunun için özel bir dizin oluşturur. - -### Server'a Boş Bir Dizin Oluşturmak ### - -Elimizde bol bir dizinimiz var, tüm yapmamız gereken bunu server'a koymak ve protokol ayarlarını yapmak. SSH erişimi olan ve `git.example.com` adında bir server kurduğumuzu varsayalım, ve `/opt/git` dizini altında tüm depolarımızı saklayalım. Boş reponuzu kopyalayarak yeni repo oluşturabilirsiniz: - - $ scp -r my_project.git user@git.example.com:/opt/git - -Bu noktada `/opt/git` dizinine okuma ve SSH erişimi olan kullanıcılar aşağıdaki komut ile reponuzu klonlayabilir - - $ git clone user@git.example.com:/opt/git/my_project.git - -Bir kullanıcnın server içinde SSHs ve `/opt/git/my_project.git` dizinine yazma erişimi varsa, otomatik olarak push yapma izni olacaktır. Eğer `git init` komutunu `--shared` seçeneği ile çalıştırırsanız Git uygun olarak izinleri verecektir. - - $ ssh user@git.example.com - $ cd /opt/git/my_project.git - $ git init --bare --shared - -Git üzerinde boş bir repo oluşturmak ve SSH izinleri vermenin ne kadar kolay olduğunu gördünüz. Şimdi projelerde birlikte çalışabilirsiniz. - -It’s important to note that this is literally all you need to do to run a useful Git server to which several people have access — just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You’re ready to go — nothing else needed. - -Önümüzdeki bölümlerde, daha sofistike kurulumları göreceğiz. Bunlar kullanıcı izinleri, web UI kurmak, Gitosis aracını kullanarak ve daha fazla, her kullanıcı için kullanıcı hesapları oluşturmak zorunda değiliz gibi konular. However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository. - -### Küçük Ayarlar ### - -Eğer kuruluşunuza Git ile çalışıyorsanız ve birkaç developer varsa bu işler sizin için kolay olabilir. Bir Git sunucusu kurmanın en karmaşık yönlerinden biri, kullanıcı yönetimidir. Bazı repolar için belirli kullanıcılara okuma bazılarına okuma/yazma erişimi vermek istiyorsanız izinleri düzenlemek zor olabilir. - -#### SSH Erişimi #### - -Eğer mevcut server'ınıza tüm developerların SSH erişimi var ise ilk repo kurulumu için pek bir iş yapmanız gerekmiyor (son bolumde bahsettiğimiz gibi). Eğer daha complex erişim izinleri istiyorsanız, sunucuda çalışan işletim sisteminin normal dosya sistemi izinleri ile düzenleyebilirsiniz. - -If you want to place your repositories on a server that doesn’t have accounts for everyone on your team whom you want to have write access, o zaman onlar için SSH erişimi kurmanız gerekiyor. Biz bunu yapmak için SSH sunucusunun yüklü olduğu bir sunucunuz varsayalım. - -Takımdaki herkese erişim vermenin birkaç yolu vardır. İlki basittir ama biraz zahmetli olabilir, herkes için bir hesap oluşturmak. `adduser` çalıştırmak ve her kullanıcı için geçici parolalar oluşturmak istemeyebilirsiniz.. - -İkinci method tek bir 'git' kullanıcısı oluşturmak, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. Bu noktada, herkes 'git' kullanıcısı ile bu makineye erişebilecek. This doesn’t affect the commit data in any way — the SSH user you connect as doesn’t affect the commits you’ve recorded. - -Bunu yapmanın bir başka yolu, bir LDAP sunucusuna veya zaten kurdunuz bazı diğer merkezi kimlik doğrulama kaynağından SSH sunucusu kimlik doğrulamasına sahip olmaktır. Böylece her kullanıcı makine üzerinden shell erişimi alabilir. - -## SSH Key Oluşturmak ## - -Git serverlerda kimlik doğrulaması için SSH public keys kullanıyor. Eğer oluşturulmuş yoksa her kullanıcı için sistem bir key oluşturur. İlk olarak hazırda bir key var mı kontrol edilir. Varsayılan olarak, bir kullanıcının SSH anahtarları o kullanıcının ~ /. ssh dizininde depolanır. Eğer oluşturulmuş bir key varsa onu kolayca listeleyebilirsiniz. - - $ cd ~/.ssh - $ ls - authorized_keys2 id_dsa known_hosts - config id_dsa.pub - -Dosyalarına baktığında iki şey arıyoruz something and something.pub, burada genellikle bir şey `id_dsa` or `id_rsa`. `.pub` dosya ortak anahtardır, ve diğer dosyaların özel anahtarıdır. Eğer bu dosyalar yok ise (or you don’t even have a `.ssh` directory), `ssh-keygen` ile bu dosyaları oluşturabilirsiniz, Linux/Mac sistemlerinde SSH paketi Windows MSysGit paketi ile geliyor: - - $ ssh-keygen - Generating public/private rsa key pair. - Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): - Enter passphrase (empty for no passphrase): - Enter same passphrase again: - Your identification has been saved in /Users/schacon/.ssh/id_rsa. - Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. - The key fingerprint is: - 43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local - -Eğer anahtarı kaydetmek isterseniz (`.ssh/id_rsa`) önce kaydetmek istediğiniz yeri sorar, ve sonra iki kez parolanızı sorar, eğer parolanızı yazmak istemiyorsanız boş geçin. - -Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). Yapmaları gereken `.pub` dosyasının ve içeriğini kopyalamak olduğunu bunu e-posta atmak. Örnek public key: - - $ cat ~/.ssh/id_rsa.pub - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU - GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 - Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA - t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En - mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx - NrRFi9wrf+M7Q== schacon@agadorlaptop.local - -Birden fazla işletim sistemlerinde SSH key oluşturma ile ilgili kapsamlı bilgi için bknz: Github klavuzu SSH keys http://github.com/guides/providing-your-ssh-key. - -## Sunucu Kurma ## - -Şimdi baştan sona adım adım sunucu tarafına SSH erişimi kuralım. Bu örnekte, kullanıcılarınızı doğrulamak için `authorized_keys` methodu kullanacağız. Ayrıca Ubuntu gibi standart bir Linux dağıtımı kullanıyoruz varsayacağız. Öncelikle, bir 'git' kullanıcı ve bu kullanıcı için bir `.ssh` dizin oluşturun. - - $ sudo adduser git - $ su git - $ cd - $ mkdir .ssh - -Sonra, you need to add some developer SSH public keys to the `authorized_keys` file for that user. Let’s assume you’ve received a few keys by e-mail and saved them to temporary files. Yine, public keyimiz aşağıdaki gibi olacaktır: - - $ cat /tmp/id_rsa.john.pub - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L - ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k - Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez - Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv - O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq - dAv8JggJICUvax2T9va5 gsg-keypair - -Sizin `authorized_keys` dosyanıza sadece bunlar eklenecek: - - $ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys - $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys - $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys - -Şimdi,boş bir repository oluşturmak için `git init` komutunu `--bare` özelliği ile çalıştırın, which initializes the repository without a working directory: - - $ cd /opt/git - $ mkdir project.git - $ cd project.git - $ git --bare init - -Sonra, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let’s use `gitserver` as the hostname of the server on which you’ve set up your 'git' user and repository. If you’re running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is: - - # on Johns computer - $ cd myproject - $ git init - $ git add . - $ git commit -m 'initial commit' - $ git remote add origin git@gitserver:/opt/git/project.git - $ git push origin master - -Bu noktada, yapılan değişiklikler kolayca yedeklenir: - - $ git clone git@gitserver:/opt/git/project.git - $ cd project - $ vim README - $ git commit -am 'fix for the README file' - $ git push origin master - -Bu method ile, kolayca Git server üzerinde okuma/yazma yapabilirsiniz. - -As an extra precaution, you can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. If you set this as your 'git' user’s login shell, then the 'git' user can’t have normal shell access to your server. To use this, specify `git-shell` instead of bash or csh for your user’s login shell. To do so, you’ll likely have to edit your `/etc/passwd` file: - - $ sudo vim /etc/passwd - -Alt kısımda bu şekilde bir çıktı görmelisiniz: - - git:x:1000:1000::/home/git:/bin/sh - -Change `/bin/sh` to `/usr/bin/git-shell` (or run `which git-shell` to see where it’s installed). Satırınız böyle görünmelidir: - - git:x:1000:1000::/home/git:/usr/bin/git-shell - -Şimdi, the 'git' user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this: - - $ ssh git@gitserver - fatal: What do you think I am? A shell? - Connection to gitserver closed. - -## Genel Erişim ## - -Peki projenize anonim olarak erişmek isterseniz? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don’t want to have to generate SSH keys all the time — you just want to add simple anonymous read access. - -Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that `post-update` hook we mentioned in the first section of this chapter. Let’s work from the previous example. Say you have your repositories in the `/opt/git` directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we’ll demonstrate some basic Apache configurations that should give you an idea of what you might need. - -Öncelikle hook'u etkinleştirmemiz gerekiyor: - - $ cd project.git - $ mv hooks/post-update.sample hooks/post-update - $ chmod a+x hooks/post-update - -Peki bu `post-update` hook ne yapar? Temelde şunları yapar: - - $ cat .git/hooks/post-update - #!/bin/sh - # - # An example hook script to prepare a packed repository for use over - # dumb transports. - # - # To enable this hook, rename this file to "post-update". - # - - exec git-update-server-info - -Bu SSH üzerinden sunucuya push yaptığınızda, Git HTTP almak için gereken dosyaları günceleyecek ve bu komutu çalıştıracak. - -Daha sonra, Apache sunucumuza VirtualHost girişi ekmemiz gerekecek. Here, we’re assuming that you have wildcard DNS set up to send `*.gitserver` to whatever box you’re using to run all this: - - - ServerName git.gitserver - DocumentRoot /opt/git - - Order allow, deny - allow from all - - - -You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read-access the repositories, çünkü CGI komut dosyası çalıştıran Apache örneği (varsayılan) kullanıcı olarak çalışıyor olacak. - - $ chgrp -R www-data /opt/git - -Apache'yi yeniden başlattığınızda, sizin projeniz dizininizin altında oluşan URL ile clonelanabilir: - - $ git clone http://git.gitserver/project.git - -This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we’ll cover this option in the next section, if you prefer that route. - -## GitWeb ## - -Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1). - -Insert 18333fig0401.png -Figure 4-1. The GitWeb web-based user interface. - -If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option. - - $ git instaweb --httpd=webrick - [2009-02-21 10:02:21] INFO WEBrick 1.3.1 - [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] - -That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It’s pretty easy on your part. When you’re done and want to shut down the server, you can run the same command with the `--stop` option: - - $ git instaweb --httpd=webrick --stop - -If you want to run the web interface on a server all the time for your team or for an open source project you’re hosting, you’ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. We’ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: - - $ git clone git://git.kernel.org/pub/scm/git/git.git - $ cd git/ - $ make GITWEB_PROJECTROOT="/opt/git" \ - prefix=/usr gitweb - $ sudo cp -Rf gitweb /var/www/ - -Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost: - - - ServerName gitserver - DocumentRoot /var/www/gitweb - - Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch - AllowOverride All - order allow,deny - Allow from all - AddHandler cgi-script cgi - DirectoryIndex gitweb.cgi - - - -Again, GitWeb can be served with any CGI capable web server; if you prefer to use something else, it shouldn’t be difficult to set up. At this point, you should be able to visit `http://gitserver/` to view your repositories online, and you can use `http://git.gitserver` to clone and fetch your repositories over HTTP. - -## Gitosis ## - -Keeping all users’ public keys in the `authorized_keys` file for access works well only for a while. When you have hundreds of users, it’s much more of a pain to manage that process. You have to shell onto the server each time, and there is no access control — everyone in the file has read and write access to every project. - -At this point, you may want to turn to a widely used software project called Gitosis. Gitosis is basically a set of scripts that help you manage the `authorized_keys` file as well as implement some simple access controls. The really interesting part is that the UI for this tool for adding people and determining access isn’t a web interface but a special Git repository. You set up the information in that project; and when you push it, Gitosis reconfigures the server based on that, which is cool. - -Installing Gitosis isn’t the simplest task ever, but it’s not too difficult. It’s easiest to use a Linux server for it — these examples use a stock Ubuntu 8.10 server. - -Gitosis requires some Python tools, so first you have to install the Python setuptools package, which Ubuntu provides as python-setuptools: - - $ apt-get install python-setuptools - -Next, you clone and install Gitosis from the project’s main site: - - $ git clone https://github.com/tv42/gitosis.git - $ cd gitosis - $ sudo python setup.py install - -That installs a couple of executables that Gitosis will use. Next, Gitosis wants to put its repositories under `/home/git`, which is fine. But you have already set up your repositories in `/opt/git`, so instead of reconfiguring everything, you create a symlink: - - $ ln -s /opt/git /home/git/repositories - -Gitosis is going to manage your keys for you, so you need to remove the current file, re-add the keys later, and let Gitosis control the `authorized_keys` file automatically. For now, move the `authorized_keys` file out of the way: - - $ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak - -Next you need to turn your shell back on for the 'git' user, if you changed it to the `git-shell` command. People still won’t be able to log in, but Gitosis will control that for you. So, let’s change this line in your `/etc/passwd` file - - git:x:1000:1000::/home/git:/usr/bin/git-shell - -back to this: - - git:x:1000:1000::/home/git:/bin/sh - -Now it’s time to initialize Gitosis. You do this by running the `gitosis-init` command with your personal public key. If your public key isn’t on the server, you’ll have to copy it there: - - $ sudo -H -u git gitosis-init < /tmp/id_dsa.pub - Initialized empty Git repository in /opt/git/gitosis-admin.git/ - Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ - -This lets the user with that key modify the main Git repository that controls the Gitosis setup. Next, you have to manually set the execute bit on the `post-update` script for your new control repository. - - $ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update - -You’re ready to roll. If you’re set up correctly, you can try to SSH into your server as the user for which you added the public key to initialize Gitosis. You should see something like this: - - $ ssh git@gitserver - PTY allocation request failed on channel 0 - ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. - Connection to gitserver closed. - -That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository: - - # on your local computer - $ git clone git@gitserver:gitosis-admin.git - -Now you have a directory named `gitosis-admin`, which has two major parts: - - $ cd gitosis-admin - $ find . - ./gitosis.conf - ./keydir - ./keydir/scott.pub - -The `gitosis.conf` file is the control file you use to specify users, repositories, and permissions. The `keydir` directory is where you store the public keys of all the users who have any sort of access to your repositories — one file per user. The name of the file in `keydir` (in the previous example, `scott.pub`) will be different for you — Gitosis takes that name from the description at the end of the public key that was imported with the `gitosis-init` script. - -If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned: - - $ cat gitosis.conf - [gitosis] - - [group gitosis-admin] - members = scott - writable = gitosis-admin - -It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project. - -Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on: - - [group mobile] - members = scott - writable = iphone_project - -Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect: - - $ git commit -am 'add iphone_project and mobile group' - [master 8962da8] add iphone_project and mobile group - 1 file changed, 4 insertions(+) - $ git push origin master - Counting objects: 5, done. - Compressing objects: 100% (3/3), done. - Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. - Total 3 (delta 0), reused 0 (delta 0) - To git@gitserver:gitosis-admin.git - fb27aec..8962da8 master -> master - -You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push: - - $ git remote add origin git@gitserver:iphone_project.git - $ git push origin master - Initialized empty Git repository in /opt/git/iphone_project.git/ - Counting objects: 3, done. - Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. - Total 3 (delta 0), reused 0 (delta 0) - To git@gitserver:iphone_project.git - * [new branch] master -> master - -Notice that you don’t need to specify the path (in fact, doing so won’t work), just a colon and then the name of the project — Gitosis finds it for you. - -You want to work on this project with your friends, so you’ll have to re-add their public keys. But instead of appending them manually to the `~/.ssh/authorized_keys` file on your server, you’ll add them, one key per file, into the `keydir` directory. How you name the keys determines how you refer to the users in the `gitosis.conf` file. Let’s re-add the public keys for John, Josie, and Jessica: - - $ cp /tmp/id_rsa.john.pub keydir/john.pub - $ cp /tmp/id_rsa.josie.pub keydir/josie.pub - $ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub - -Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`: - - [group mobile] - members = scott john josie jessica - writable = iphone_project - -After you commit and push that change, all four users will be able to read from and write to that project. - -Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead: - - [group mobile] - members = scott josie jessica - writable = iphone_project - - [group mobile_ro] - members = john - readonly = iphone_project - -Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically: - - [group mobile_committers] - members = scott josie jessica - - [group mobile] - members = @mobile_committers - writable = iphone_project - - [group mobile_2] - members = @mobile_committers john - writable = another_iphone_project - -If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project. - -## Gitolite ## - -This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with. There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg]. - -[gldpg]: http://sitaramc.github.com/gitolite/progit.html -[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html - -Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to). - -Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others. - -### Installing ### - -Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it. You need an account on a Unix server of some kind. You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed. In the examples below, we will use the `git` account on a host called `gitserver`. - -Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation. - -To begin, create a user called `git` on your server and login to this user. Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `.pub` (we'll use `scott.pub` in our examples). Then run these commands: - - $ git clone git://github.com/sitaramc/gitolite - $ gitolite/install -ln - # assumes $HOME/bin exists and is in your $PATH - $ gitolite setup -pk $HOME/scott.pub - -That last command creates new Git repository called `gitolite-admin` on the server. - -Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation. You administer your Gitolite setup by making changes to this repository and pushing. - -### Customising the Install ### - -While the default, quick, install works for most people, there are some ways to customise the install if you need to. Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite. - -### Config File and Access Control Rules ### - -Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got: - - $ cd ~/gitolite-admin/ - $ ls - conf/ keydir/ - $ find conf keydir -type f - conf/gitolite.conf - keydir/scott.pub - $ cat conf/gitolite.conf - - repo gitolite-admin - RW+ = scott - - repo testing - RW+ = @all - -Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name. - -Adding users is easy. To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation. Add, commit, and push the change, and the user has been added. - -The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here. - -You can group users or repos for convenience. The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro". - - @oss_repos = linux perl rakudo git gitolite - @secret_repos = fenestra pear - - @admins = scott - @interns = ashok - @engineers = sitaram dilbert wally alice - @staff = @admins @engineers @interns - -You can control permissions at the "ref" level. In the following example, interns can only push the "int" branch. Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit. And the admins can do anything (including rewind) to any ref. - - repo @oss_repos - RW int$ = @interns - RW eng- = @engineers - RW refs/tags/rc[0-9] = @engineers - RW+ = @admins - -The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against. So we call it a "refex"! Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes. - -Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`. - -An important feature of the config file’s syntax is that all the rules for a repository need not be in one place. You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so: - - repo gitolite - RW+ = sitaram - -That rule will just get added to the ruleset for the `gitolite` repository. - -At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly. - -There are two levels of access control in Gitolite. The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository. This is the only access control that Gitosis had. - -The second level, applicable only to "write" access, is by branch or tag within a repository. The username, the access being attempted (`W` or `+`), and the refname being updated are known. The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched). If a match is found, the push succeeds. A fallthrough results in access being denied. - -### Advanced Access Control with "deny" rules ### - -So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`. However, Gitolite allows another permission: `-`, standing for "deny". This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*! - -Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ. Here’s how to do that: - - RW master integ = @engineers - - master integ = @engineers - RW+ = @engineers - -Again, you simply follow the rules top down until you hit a match for your access mode, or a deny. Non-rewind push to master or integ is allowed by the first rule. A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied. Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it. - -### Restricting pushes by files changed ### - -In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch. For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*. You can tell Gitolite: - - repo foo - RW = @junior_devs @senior_devs - - - VREF/NAME/Makefile = @junior_devs - -Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details. - -### Personal Branches ### - -Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment. - -A lot of code exchange in the Git world happens by "please pull" requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there. - -This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin. - -Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal//*`); please see the documentation for details. - -### "Wildcard" repositories ### - -Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example. It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc. Again, please see the documentation for details. - -### Other Features ### - -We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation. - -**Logging**: Gitolite logs all successful accesses. If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed. - -**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server. Gitolite shows you what repos you have access to, and what that access may be. Here’s an example: - - hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4 - - R anu-wsd - R entrans - R W git-notes - R W gitolite - R W gitolite-admin - R indic_web_input - R shreelipi_converter - -**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently. This reduces the load on the main admin, and makes him less of a bottleneck. - -**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down. - -## Git Daemon ## - -For public, unauthenticated read access to your projects, you’ll want to move past the HTTP protocol and start using the Git protocol. The main reason is speed. The Git protocol is far more efficient and thus faster than the HTTP protocol, so using it will save your users time. - -Again, this is for unauthenticated read-only access. If you’re running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. If the server you’re running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don’t want to have to add an SSH key for each. - -In any case, the Git protocol is relatively easy to set up. Basically, you need to run this command in a daemonized manner: - - git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ - -`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on. - -You can daemonize this process a number of ways, depending on the operating system you’re running. On an Ubuntu machine, you use an Upstart script. So, in the following file - - /etc/event.d/local-git-daemon - -you put this script: - - start on startup - stop on shutdown - exec /usr/bin/git daemon \ - --user=git --group=git \ - --reuseaddr \ - --base-path=/opt/git/ \ - /opt/git/ - respawn - -For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories — you can easily do this by creating a new user 'git-ro' and running the daemon as them. For the sake of simplicity we’ll simply run it as the same 'git' user that Gitosis is running as. - -When you restart your machine, your Git daemon will start automatically and respawn if it goes down. To get it running without having to reboot, you can run this: - - initctl start local-git-daemon - -On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow. - -Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file: - - [repo iphone_project] - daemon = yes - -When that is committed and pushed up, your running daemon should start serving requests for the project to anyone who has access to port 9418 on your server. - -If you decide not to use Gitosis, but you want to set up a Git daemon, you’ll have to run this on each project you want the Git daemon to serve: - - $ cd /path/to/project.git - $ touch git-daemon-export-ok - -The presence of that file tells Git that it’s OK to serve this project without authentication. - -Gitosis can also control which projects GitWeb shows. First, you need to add something like the following to the `/etc/gitweb.conf` file: - - $projects_list = "/home/git/gitosis/projects.list"; - $projectroot = "/home/git/repositories"; - $export_ok = "git-daemon-export-ok"; - @git_base_url_list = ('git://gitserver'); - -You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this: - - [repo iphone_project] - daemon = yes - gitweb = yes - -Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`. - -## Hosted Git ## - -If you don’t want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code — it’s generally easier for the open source community to find and help you with. - -These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. To see an up-to-date list, check out the following page: - - https://git.wiki.kernel.org/index.php/GitHosting - -Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved. - -GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book. - -### GitHub ### - -GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project. - -GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done. - -### Setting Up a User Account ### - -The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page. - -Insert 18333fig0402.png -Figure 4-2. The GitHub plan page. - -Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3). - -Insert 18333fig0403.png -Figure 4-3. The GitHub user signup form. - -If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems. -Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4). - -Insert 18333fig0404.png -Figure 4-4. The GitHub user dashboard. - -Next you can create a new repository. - -### Creating a New Repository ### - -Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5). - -Insert 18333fig0405.png -Figure 4-5. Creating a new repository on GitHub. - -All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6). - -Insert 18333fig0406.png -Figure 4-6. GitHub project header information. - -Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7). - -Insert 18333fig0407.png -Figure 4-7. Instructions for a new repository. - -These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use - - $ git init - $ git add . - $ git commit -m 'initial commit' - -When you have a Git repository locally, add GitHub as a remote and push up your master branch: - - $ git remote add origin git@github.com:testinguser/iphone_project.git - $ git push origin master - -Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8). - -Insert 18333fig0408.png -Figure 4-8. Project header with a public URL and a private URL. - -The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you. - -The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one. - -### Importing from Subversion ### - -If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9). - -Insert 18333fig0409.png -Figure 4-9. Subversion importing interface. - -If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports. - -### Adding Collaborators ### - -Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work. - -Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10). - -Insert 18333fig0410.png -Figure 4-10. GitHub administration page. - -To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11). - -Insert 18333fig0411.png -Figure 4-11. Adding a collaborator to your project. - -When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12). - -Insert 18333fig0412.png -Figure 4-12. A list of collaborators on your project. - -If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project. - -### Your Project ### - -After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13. - -Insert 18333fig0413.png -Figure 4-13. A GitHub main project page. - -When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information. - -### Projeleri Forklamak ### - -If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it. - -This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work. - -To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14). - -Insert 18333fig0414.png -Figure 4-14. Get a writable copy of any repository by clicking the "fork" button. - -After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15). - -Insert 18333fig0415.png -Figure 4-15. Your fork of a project. - -### GitHub Özeti ### - -That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly. - -## Özet ## - -You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. - -Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that. - -It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. +Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. Bir reponun Git protokolü üzerinden sunulması için, 'git-daemon-export-ok' dosyasını oluşturmalısınız - Daemon, içinde bu dosya olmayan bir git reposunu sunmaz. - fakat bunun dışında, güvenlik yoktur. Ya clonelanabilir bir Git reposu mevcuttur ya da herkes clonelayamaz. Bu, genel olarak bu protokol üzerinden psuh yapıldığı anlamına gelir. Push erişimi sağlar; fakat eksik bir kimlik doğrulamada internet üzerinde projenizin URL'i bulunur ve push edilebilir. Fakat bu durum çok nadir olur. \ No newline at end of file diff --git a/tr/05-distributed-git/01-chapter5.markdown b/tr/05-distributed-git/01-chapter5.markdown new file mode 100644 index 000000000..f65ed4a81 --- /dev/null +++ b/tr/05-distributed-git/01-chapter5.markdown @@ -0,0 +1,215 @@ +# Dağıtık Git # + +Artık tüm developerların kodunu paylaşacağı bir uzak git reposuna sahipsiniz ve yerel çalışma akışınızda kullanacağınız temel Git komutlarına aşinasınız. Artık Git'in size sağladığı bazı dağıtık çalışma akışlarını nasıl kullanacağımıza bakacacağız. + +Bu bölümde, dağıtık bir Git ortamında katılımcı ve koordinatör olarak nasıl çalışacağınızı göreceksiniz. Bir çok geliştiricinin çalıştığı projelere nasıl katkı sağlayacağınızı ve projenin sürdürülebilirliğini nasıl sağlayacağınızı öğreneceksiniz. + +## Dağıtık Çalışma Akışları ## + +Merkezi Versiyon Kontrol Sistemlerinden (CVCSs) farklı olarak, Git'in dağıtık yapısı geliştiricilerin projelerde nasıl işbirliği yapacağı konusunda daha esnek davranmanıza izin verir. Merkezi sistemlerde, her bir geliştirici merkez çevresinde az veya çok çalışan bir noktacıktır. Git'te ise; her bir geliştirici potansiyel olarak bir noktacık veya bir merkez olabilir. Her bir geliştirici başka repolar üzerindeki kodlara katkı sağlayabilir ve aynı zamanda başkalarının katkı sağladığı bir reponun koordinatörlüğünü üstlenebilir. Bu takımınıza ve projenize sonsuz sayıda çalışma akışı için imkan sağlar. Burada bu esnekliğin avantajlarını kullanan bazı çok kullanılan çalışma tasarım desenlerinden(pattern) bahsedeceğim. Her bir desenin güçlü ve zayıf yanlarının üzerinden geçeceğim. Böylece bunlardan birini seçebilirsiniz ya da ihtiyaçlarınıza göre şekillendirerek/karıştırarak kullanabilirsiniz. + +### Merkezi Çalışma Akışı (Centralized Workflow) ### + +Merkezi sistemlerde, genellikle tek bir katılım modeli vardır: Merkezi Çalışma Akışı. Kod katılımını kabul edebilen tek bir merkez veya repo bulunur ve herkes çalışmasını bu merkezle senkronize eder. Geliştiriciler bu merkezin çevresindeki noktacıklardır ve bu tek merkeze senkronize olurlar (Resim 5-1). + +Insert 18333fig0501.png +Resim 5-1. Merkezi çalışma akışı. + +Bu şu anlama gelir; eğer iki geliştirici bir merkezden repoyu klonlar ve değişiklikler yapar, ardından ilk geliştirici değişikliklerini merkeze gönderirse herhangi bir sıkıntı olmaz. Ancak ikinci geliştirici ilk geliştiricinin değişiklilerinin üzerine yazmadığından emin olmak için değişikliklerini göndermeden önce merkezi reponun son halini kendisine almalı ve kendi değişiklikleriyle birleştirmelidir. Bu konsept Git ya da Subversion (ya da herhangi bir CVCS)'de mevcuttur, ve Git'de çok iyi çalışır. + +Eğer küçük bir takımsanız veya merkezi çalışma akışından hali hazırda memnunsanız bu akışı Git ile kullanmaya devam edebilirsiniz. Tek bir repo oluşturun, ve takımdaki herkese bu repoya push edebilme izni verin; Git geliştiricilerin birbirlerinin değişikliklerini ezmesine izin vermeyecektir. Eğer bir geliştirici repoyu klonlar, değişiklikler yapar ve ardından değişikliklerini push etmeye çalışırsa ve o esnada başka bir geliştirici değişiklikler yapıp push ettiyse git sunucusu değişiklikleri reddedecektir. non-fast-forward(hızlı-ileri-olmayan?) değişiklikler yaptığı şeklinde bir hata alacak ve repodan fetch ve merge yapmadığı sürece değişikliklerini gönderemeyecektir. +Bu paradigma birçok insanı kendine çeker çünkü birçok kişiye tanıdık gelen ve rahat olabildikleri bir konsepttir. + +### Entegrasyon Yöneticili Çalışma Akışı (Integration-Manager Workflow) ### + +Git birden çok uzak repoyla çalışmanıza izin verdiğinden, her geliştiricinin kendi reposuna yazma izni ve diğer tüm repolara okuma izni olan bir çalışma akışı mümkündür. Bu senaryoda genellikle projeyi "resmi" olarak temsil eden ve doğruluğndan emin olunan bir repo bulunur. Bu repoya katkıda bulunmak için reponun kendinize ait olan klonun oluşturur ve kendi reponuz üzerinde çalışırsınız. Sonrasında ana proje reposunu yöneten kişiye sizin reponuzdaki değişiklikleri ana repoya alması için bir istekte bulunursunuz. Yönetici sizin reponuzu kendisine uzak sunucu olarak ekler, değişikliklerinizi test eder, ana repodaki branch ile birleştirir ve ana repoya gönderir. Bu işlem aşağıdaki şu şekilde ilerler (Resim 5-2): + +1. Yönetici projenin genel reposuna push eder. +2. Geliştirici o repoyu kendisine klonlar ve değişiklilerini yapar. +3. Geliştirici değişikliklerini kendi reposuna gönderir. +4. Geliştirici yöneticiye değişiklilerini çekmesi için bir istekte bulunur (email vs.). +5. Yönetici geliştiricinin reposunu kendisine bir remote olarak ekler ve local olarak değişiklikleri birleştirir. +6. Yönetici birleştirilmiş değişiklikleri ana repoya gönderir. + +Insert 18333fig0502.png +Figure 5-2. Entegrasyon Yöneticili Çalışma Akışı + +Bir projeyi fork etmek ve o fork üzerinde çalışmak gibi işlemlerin kolay olduğu, Github gibi sitelerle birlikte bu çok kullanılan bir çalışma akışıdır. Bu yaklaşımın ana kazanımlarından biri geliştirici çalışmaya devam ederken yönetici geliştiricinin değişikliklerini herhangi bir zamanda ana repoya alabilir. Katılımcılar projenin kendi değişikliklerini dahil etmesini beklemek zorunda değildir. Herkes kendi alanında çalışabilir. + +### Diktatör ve Yüzbaşılar Çalışma Akışı (Dictator and Lieutenants Workflow) ### + +Bu çoklu repo çalışma akışının bir varyasyonudur. Genellikle yüzlerce katılımcının olduğu devasa projelerde kullanılır; meşhur bir örnek Linux çekirdeğidir. Bir çok entegrasyon yöneticisi projenin çeşitli yerlerinden sorumludur; bu kişiler yüzbaşılardır. Tüm yüzbaşıların üstünde ise 'iyiliksever diktatör' denilen tek bir entegrasyon yöneticisi vardır. İyiliksever diktatörün reposu tüm katılımcıların pull etmesi gereken referans repo konumundadır. Bu işlem aşağıdaki şu şekilde ilerler (Resim 5-3): + +1. Normal geliştiriciler kendi topic branch(konu dalı)lerinde çalışırlan ve değişikliklerini diktatörün master branchi üzerinde rebase ederler. +2. Yüzbaşılar geliştiricilerin branchlerini kendi master branchlerine birleştirirler. +3. Diktatör yüzbaşıların master branchini kendi master branchine birleştirir. +4. Diktatör kendi master branchini referans repoya gönderir. Böylece diğer developerlar bunun üzerine rebase edebilirler. + +Insert 18333fig0503.png +Resim 5-3. Diktatör ve Yüzbaşılar Çalışma Akışı. + +Bu tarz bir çalışma akışı çok yaygın değildir fakat büyük projelerde veya çok hiyerarşik ortamlarda kullanışlı olabilir. Çünkü bu akış proje liderine (diktatör) görevlerin çoğunu dağıtma ve büyük kod setlerini entegre etmeden önce toplama imkanı sunar. + +Bunlar Git gibi dağıtık sistemlerde mümkün olan çalışma akışlarından çok yaygın olan birkaçıydı. Sizin takım yapınıza ve çalışma şeklinize uygun olan daha başka yöntemler bulunabilir. Artık (umarım) hangi çalışma akışı kombinasyonunun size uyacağına karar verebilirsiniz. Şimdi daha özele inen bazı örneklerle değişik senaryolarda mümkün olabilecek rollerin çalışma akışlarından bahsedelim. + +## Bir Projeye Katılım Sağlamak ## + +Artık değişik çalışma akışlarını biliyor ve temel Git kullanımını iyice kavramış olmanız gerekiyor. Bu bölümde, bir projeye katkı sağlarken kullanılabilecek bazı genel pattern(desen)lardan bahsedeceğiz. + +Bu işlemi açıklamanın en zor tarafı, nasıl yapılacağı ile ilgili çok fazla sayıda varyasyon olmasıdır. Çünkü Git çok esnektir ve insanlar bir arada çok farklı şekillerde çalışabilirler ve her proje birbirinden farklıdır. Bu da bir projeye nasıl katılım sağlanacağı konusunu anlatmayı problemli bir hale getirmektedir. İlişkili bazı değişkenler; aktif katılımcı sayısı, seçilen çalışma akışı, commit erişiminiz ve belki dışarıdan katılım metodudur. + +İlk değişken; aktif katılımcı sayısı. Kaç kişi bu projeye ne sıklıkla kod katılımı sağlıyorlar? Birçok durumda iki-üç geliştiriciniz ve her geliştirici için günde birkaç commit olacaktır; atıl projeler için belki daha az. Fakat gerçekten büyük şirketler ve projeler için, binlerce geliştirici ve her gün düzinelerce hatta yüzlerce yama olabilir. Bu önemlidir çünkü geliştici sayısı arttıkça, kodunuzun temizce uygulanması ve kolayca birleştirilmesi konusunda daha çok sıkıntı yaşayacaksınız. Değişiklikleriniz, siz çalışırken veya değişikliklerinizin birleştirilmesini beklerken başka geliştiricilerin değişikliklerinin birleştirilmiş olmasından dolayı eski kalmış ya da kısmen/tamamen bozulmaya sebep olmuş olabilir. Peki kodunuzu nasıl düzenli olarak güncel ve değişikliklerinizi güncel tutacaksınız? + +Diğer değişken; projeniz için kullandığınız çalışma akışı. Her geliştiricinin kod üzerinde eşit yazma hakları olacak şekilde merkezi mi? Projede tüm yamaları kontrol eden bir entegrasyon yöneticisi var mı? Tüm yamalar başka geliştiriciler kontrol edilip mi onaylanıyor? Siz bu süreçte var mısınız? Bir yüzbaşı sistemi var ve öncelikle değişikliklerinizi onlara mı göndermek durumundasınız? + +Diğer bir sorun ise commit erişiminiz. Çünkü bir projeye doğrudan yazma izninizin olup olmaması o projede uygulanması gereken çalışma akışını çok etkiler. Eğer yazma izniniz yoksa, prje katılımcıların çalışmalarını ne şekilde kabul etmeyi tercih ediyor? Bir politikasi var mı? Tek seferde ne kadarlık bir katılım sağlıyorsunuz? Ne sıklıkla katılım sağlıyorsunuz? + +Tüm bu sorular nasıl verimli bir şekilde katılım sağlayacağınızı, sizin için ne şekilde çalışma akışları mevcut olacağını ve tercih edildiğini etkileyecektir. Bunların her birini ve yönlerini, basitten karmaşığa doğru giderek ve bir seri kullanım durumları halinde inceleyeceğiz. Sonrasında ihtiyaç duyduğunuz çalışma akışını bu örneklerden yola çıkarak oluşturabilirsiniz. + +### Commit Prensipleri ### + +Özel kullanım durumlarına bakmadan önce, commit mesajları hakkında küçük bir not düşelim. Commit oluşturmak ile ilgili iyi prensiplere sahip olmak ve bunlara uymayı sürdürmek Git ile çalışmayı ve diğer geliştiricilerle yapılan işbirliğini çok kolaylaştırır. Git projesinin kendisine gönderilen yamalar iyi commitler oluşturmak için bize birçok ipucu sunmaktadır. Aynı zamanda Git kaynak kodunda `Documentation/SubmittingPatches` dosyasını okuyabilirsiniz. + +Öncelikle, hiç bir beyaz-boşluk hatasını göndermek istemezsiniz. Git bunun kontrolü için kolay bir yol sunmaktadır. Commit etmeden önce `git diff --check` çalıştırırsanız, Git olası beyaz-boşluk hatalarını bulacak ve sizin için listeleyecektir. Bir örnek: (terminaldeki kırmızı renkler `X` ile değiştirilmiştir) + + $ git diff --check + lib/simplegit.rb:5: trailing whitespace. + + @git_dir = File.expand_path(git_dir)XX + lib/simplegit.rb:7: trailing whitespace. + + XXXXXXXXXXX + lib/simplegit.rb:26: trailing whitespace. + + def command(git_cmd)XXXX + +Eğer commit etmeden önce bu komutu çalıştırırsanız, neredeyse muhtemelen diğer geliştiricileri rahatsız edecek olan beyaz-boşlukları commit ediyor olduğunuzu görürsünüz. + +Her bir commit'i mantıklı bir biçimde ayrılmış olarak yapın. Yapabiliyorsanız, değişikliklerinizi olabildiğince hafif yapın. Yani tüm haftasonu 5 sorun üzerine çalışıp da Pazartesi günü hepsini tek bir devasa commit halinde göndermeyin. Haftasonu boyunca commit yapmadıysanız bile, Pazartesi günü staging alanını kullanarak çözdüğünüz sorunların her birini mantıklı mesajlar içeren ayrı commitler haline getirin. Eğer bazı değişiklikler aynı dosyayı etkiliyorsa `git add --patch` kullanarak dosyaları kısmı olarak staginge almaya çalışın (6. bölümde bahsedeceğiz). 5 commit ya da tek commit yaptığınızda projenin sonuçtaki hali değişmez. Ama sizinle birlikte çalışanların işlerini neden zorlaştıralım ki? Bu yaklaşım aynı zamanda gerekirse değişikliklerden birini ya da birkaçını çıkarmak ya da geri çevirmek gerektiğinde de çok işe yarayacaktır. 6. Bölüm geçmişi baştan yazmak ve dosyaları interaktif olarak stage etmek için gerekli olan birçok kullanışlı Git ipuçlarını içermektedir. Temiz ve anlaşılabilir bir geçmiş oluşturmak için bu araçları kullanın. + +Aklımızdan çıkarmamamız gereken son şey ise commit mesajıdır. Kaliteli ve anlaşılabilir commit mesajları yazmayı alışkanlık haline getirmek Git ile çalışmayı ve işbirliği yapmayı çok kolaylaştıracaktır. Genel bir kural olarak, mesajınız 50 karakterden uzun olmayan ve değişiklikleri kısaca anlatan bir satır ardından bir boş satır ve devamında ayrıntılı bir açıklama şeklinde olmalıdır. Git projesinde bu detaylı açıklamanızın sizi bu değişikliğe iten sebepleri ve sizin yaptığınızla önceki arasındaki farkları açıklamanız istenmektedir. Aşağıdaki örnek ilk olarak Tim Pope tarafından tpope.net'te İngilizce olarak yazılmıştır: + + Kısa (50 ya da daha az karakter) bir özet + + Gerekiyorsa, daha detaylı ve açıklayıcı bir metin. Satır uzunluğunu + 72 karakter civarında tutmaya çalışın. İlk satırı bir e-mailin konusu + ve bu metni de mailin kendisi olarak düşünebilirsiniz. Boş satır + ise konu ve mailin metnini ayırmaktadır. Eğer detaylı metin yazıyorsanız + bu boş satır önemlidir çünkü kullanmadığınız durumlarda rebase gibi + araçlar karışık hale gelebilir. + + Yeni paragraf yazmanız gerektiğinde yine boş bir satır bırakın. + + - Bullet listeler de kullanılabilir + + - Tipik olarak bir tire ya da yıldızı takip eden bir boşluk ve metin şeklinde + liste elemanları oluşturulabilir. + +Eğer tüm commit mesajlarınız böyle görünürse, herşey siz ve birlikte çalıştığınız geliştiriciler için daha kolay olacaktır. Git projesinin kendisi çok iyi formatlanmış commit mesajlarına sahiptir. İyi formatlanmış commit mesajlarına sahip bir proje geçmişinin nasıl göründüğünü görmeniz için sizi, Git projesi üzerinde `git log --no-merges` komutunu çalıştırmaya davet ediyorum. + +Bu kitabın tamamı boyunca sadelik uğruna mesajları böyle güzel biçimde yazmayacağım. Bunun yerine `git commit` komutunu `-m` ayarı ile çağırarak mesajlarını yazacağım. İmamın dediğini yap, yaptığını yapma :) + +### Özel(dışarıya kapalı) Küçük Takım ### + +Muhtemelen karşılacağınız en temel senaryo, özel bir projeye üzerinde çalışan iki veya daha fazla geliştiricidir. Özel derken, kapalı kaynaklı ve proje dışındaki insanlar tarafından kaynağı görülemeyen projelerden bahsediyorum. Siz ve tüm geliştiriciler projeye yazma hakkına sahipler. + +Bu ortamda, Subversion ya da başka bir merkezi sistemde takip ettiğiniz çalışma akışını takip edebilirsiniz. Offline commit ve büyük ölçüde daha kolay olan branchler ve birleştirmenin avantajlarını halen kullanabilirsiniz. Ama çalışma akışı halen çok benzer olabilir, en temel fark ise birleştirmelerin sunucuda olması yerine istemci tarafında commit anında olmasıdır. +İki geliştiricinin ortak bir repoda çalışmaya başlamasıyla ne olacağına bakalım. İlk geliştirici Burak repoyu klonlar, bir değişiklik yapar ve yerel olarak commit eder. (Örnekleri kısaltmak adına protokol mesajları yerine `...` yazıyorum) + + # Burak's Machine + $ git clone john@githost:simplegit.git + Initialized empty Git repository in /home/burak/simplegit/.git/ + ... + $ cd simplegit/ + $ vim lib/simplegit.rb + $ git commit -am 'geçersiz varsayılan değer kaldırıldı' + [master 738ee87] geçersiz varsayılan değer kaldırıldı + 1 files changed, 1 insertions(+), 1 deletions(-) + +İkinci geliştirici Nesrin de aynı şeyi yapar. Repoyu klonlar ve bir değişiklik commit eder: + + # Nesrin's Machine + $ git clone nesrin@githost:simplegit.git + Initialized empty Git repository in /home/nesrin/simplegit/.git/ + ... + $ cd simplegit/ + $ vim TODO + $ git commit -am 'sıfırlama görevi eklendi' + [master fbff5bc] sıfırlama görevi eklendi + 1 files changed, 1 insertions(+), 0 deletions(-) + +Şimdi Nesrin çalışmasını uzak sunucudaki repoya pushlar: + + # Nesrin's Machine + $ git push origin master + ... + To nesrin@githost:simplegit.git + 1edee6b..fbff5bc master -> master + +Burak da kendi değişikliğini pushlamaya çalışır: + + # Burak's Machine + $ git push origin master + To burak@githost:simplegit.git + ! [rejected] master -> master (non-fast forward) + error: failed to push some refs to 'burak@githost:simplegit.git' + +Burak'a izin verilmez çünkü o esnada Nesrin push yapmıştır. Eğer önceden Subversion kullandıysanız bunu anlamanız önemlidir. 2 geliştirici farklı dosyaları düzenlemiştir. Eğer farklı dosyalarda değişiklik yapıldıysa Subversion otomatik olarak sunucuda bir birleştirme yapacaktır. Git'te ise commitleri kendi yerelinizde birleştirmelisiniz. Burak push yapmadan önce Nesrin'in değişikliklerini kendisine çekmeli, ve kendi değişiklikleriyle birleştirmelidir: + + $ git fetch origin + ... + From burak@githost:simplegit + + 049d078...fbff5bc master -> origin/master + +Bu noktada Burak'ın yerel reposu Resım 5-4'teki gibi gorunecektir. + +Insert 18333fig0504.png +Figure 5-4. Burak'ın baştakı reposu. + +Artık Burak Nesrin'in yaptığı değişikliklerin bir referansına sahip. Şimdi kendi değişiklikleri ile Nesrin'in değişikliklerini birleştirip sonrasında repoya push edebilir. + + $ git merge origin/master + Merge made by recursive. + TODO | 1 + + 1 files changed, 1 insertions(+), 0 deletions(-) + +Eğer birleştirme sorunsuz giderse Burak'ın commit geçmişi Resim 5-5deki gibi olacaktır. + +Insert 18333fig0505.png +Figure 5-5. `origin/master` ile birleştirdikten sonra Burak'ın reposu. + +Şimdi, Burak herşeyin hala düzgün olduğundan emin olmak için test edip ardından değişikliklerini sunucuya gönderebilir: + + $ git push origin master + ... + To burak@githost:simplegit.git + fbff5bc..72bbc59 master -> master + +Sonuç olarak Burak'ın commit geçmişi Resim 5-6daki gibi görünür. + +Insert 18333fig0506.png +Figure 5-6. Origin sunucuya gönderdikten sonra Burak'ın commit geçmişi. + +Aynı esnada Nesrin de bir konu branchinde çalışmaktadır. `issue54` isminde bir branch oluşturmuş ve bu branche 3 commit yapmıştır ve henüz Burak'ın yaptığı değişiklileri kendisine çekmemiştir. Commit geçmişi Resim 5-7deki gibidir. + +Insert 18333fig0507.png +Figure 5-7. Nesrin'in baştaki commit geçmişi. + +Nesrin Burak ile senkronize olmak ister ve fetch eder: + + # Nesrin's Machine + $ git fetch origin + ... + From nesrin@githost:simplegit + fbff5bc..72bbc59 master -> origin/master + +Bu Burak'ın pushladığı çalışmaları çeker. Jessica'nın geçmişi şimdi Resim 5-8deki gibidir. + +Insert 18333fig0508.png +Figure 5-8. Burak'ın değişikliklerini fetch ettikten sonra Nesrin'in geçmişi. + +Nesrin kendi branchinin hazır olduğunu düşünür, fakat neleri birleştirmesi gerektiğini görmek istemektedir. `git log` çalıştırarak bunu görebilir: + + $ git log --no-merges origin/master ^issue54 + commit 738ee872852dfaa9d6634e0dea7a324040193016 + Author: Burak Can + Date: Fri May 29 16:01:27 2009 -0700 + + geçersiz varsayılan değer kaldırıldı \ No newline at end of file From 904748994541dd6967d88e1e1e848151551f9a1c Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 14 Oct 2014 22:50:52 +0200 Subject: [PATCH 258/291] Fix tab mistakes in tables This fix is not totally bullet proof, because for cjk languages, the characters have a double width. The script that transforms the tab aligned values into a markdown table are not ready for double width characters. --- ko/02-git-basics/01-chapter2.markdown | 12 ++++++------ nl/02-git-basics/01-chapter2.markdown | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown index da62f4c31..58f792191 100644 --- a/ko/02-git-basics/01-chapter2.markdown +++ b/ko/02-git-basics/01-chapter2.markdown @@ -614,15 +614,15 @@ The lines must be formatted as follows --> - 옵션 설명 + 옵션 설명 -p 각 커밋에 적용된 패치를 보여준다. --word-diff diff 결과를 단어 단위로 보여준다. --stat 각 커밋에서 수정된 파일의 통계정보를 보여준다. - --shortstat `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다. - --name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다. - --name-status 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다. - --abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다. - --relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다. + --shortstat `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다. + --name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다. + --name-status 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다. + --abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다. + --relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다. --graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다. --pretty 지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format은 원하는 형식으로 출력하고자 할 때 사용한다. --oneline `--pretty=oneline --abbrev-commit` 옵션을 함께 사용한 것과 동일하다. diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown index a87e88310..571dc9150 100644 --- a/nl/02-git-basics/01-chapter2.markdown +++ b/nl/02-git-basics/01-chapter2.markdown @@ -655,7 +655,7 @@ The lines must be formatted as follows --name-status Toon ook de lijst van bestanden die beïnvloed zijn door de toegevoegde/gewijzigde/verwijderde informatie. --abbrev-commit Toon alleen de eerste paar karakters van de SHA-1 checksum in plaats van alle 40. --relative-date Toon de datum in een relatief formaat (bijvoorbeeld, "2 weken geleden"), in plaats van het volledige datum formaat. - --graph Toon een ASCII grafiek van de branch- en merge-geschiedenis naast de log output. + --graph Toon een ASCII grafiek van de branch- en merge-geschiedenis naast de log output. --pretty Toon commits in een alternatief formaat. De opties bevatten oneline, short, full, fuller, en format (waarbij je je eigen formaat specificeert). --oneline Een gemaks-optie, staat voor `--pretty=oneline --abbrev-commit`. From 0fed91962aa670319a2451f54540d7944b6e3eac Mon Sep 17 00:00:00 2001 From: Ryo Inoue Date: Wed, 15 Oct 2014 00:51:25 +0900 Subject: [PATCH 259/291] Improve translation (Ch. 1.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 原文： > Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; --- ja/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown index 8f779f48d..a02b234e4 100644 --- a/ja/01-introduction/01-chapter1.markdown +++ b/ja/01-introduction/01-chapter1.markdown @@ -57,7 +57,7 @@ Insert 18333fig0103.png ## Gitの基本 ## では、要するにGitとは何なのでしょうか。これは、Gitを吸収するには重要な節です。なぜならば、もしGitが何かを理解し、Gitがどうやって稼動しているかの根本を理解できれば、Gitを効果的に使う事が恐らくとても容易になるからです。 -Gitを学ぶときは、SubversionやPerforceのような他のVCSsに関してあなたが恐らく知っていることは、意識しないでください。このツールを使うときに、ちょっとした混乱を回避することに役立ちます。Gitは、ユーザー・インターフェイスがとてもよく似ているのにも関わらず、それら他のシステムとは大きく異なって、情報を格納して取り扱います（訳者注：「取り扱う」の部分はthinksなので、「見なします」と訳す方が原語に近い）。これらの相違を理解する事は、Gitを扱っている間の混乱を、防いでくれるでしょう。 +Gitを学ぶときは、SubversionやPerforceのような他のVCSsに関してあなたが恐らく知っていることは、意識しないでください。このツールを使うときに、ちょっとした混乱を回避することに役立ちます。ユーザー・インターフェイスがよく似ているにも関わらず、Gitの情報の格納の仕方や情報についての考え方は、それら他のシステムとは大きく異なっています。これらの相違を理解する事は、Gitを扱っている間の混乱を、防いでくれるでしょう。 ### スナップショットで、差分ではない ### From 04b3b3231c455cfc25716b72b46f013243c0d4bc Mon Sep 17 00:00:00 2001 From: Hiroshi Manabe Date: Thu, 16 Oct 2014 23:24:28 +0900 Subject: [PATCH 260/291] [ja] Revised the translation (chapter 01). --- ja/01-introduction/01-chapter1.markdown | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown index a02b234e4..afdbfaa44 100644 --- a/ja/01-introduction/01-chapter1.markdown +++ b/ja/01-introduction/01-chapter1.markdown @@ -1,44 +1,43 @@ # 使い始める # -この章は、Gitを使い始めることに関してになります。まずはバージョン管理システムの背景に触れ、その後にGitをあなたのシステムで動かす方法、そしてGitで作業を始めるための設定方法について説明します。この章を読み終えるころには、なぜGitが広まっているか、なぜGitを使うべきなのか、それをするための準備が全て整っているだろうということを、あなたはきっと理解しているでしょう。 +この章は、Gitを使い始めることについてのものです。まずはバージョン管理システムの背景に触れ、次にGitをあなたのシステムで動かす方法、最後にGitで作業を始めるための設定方法について説明します。この章を読み終えるころには、なぜGitがあるのか、なぜGitを使うべきなのかを理解し、また使い始めるための準備が全て整っていることと思います。 ## バージョン管理に関して ## -バージョン管理とは何でしょうか、また、なぜそれを気にする必要があるのでしょうか？ -バージョン管理とは、変更を一つのファイル、もしくは時間を通じたファイルの集合に記録するシステムで、そのため後で特定バージョンを呼び出すことができます。現実にはコンピューター上のほとんどあらゆるファイルのタイプでバージョン管理を行なう事ができますが、本書の中の例では、バージョン管理されるファイルとして、ソフトウェアのソースコードを利用します。 +バージョン管理とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを示していますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。 -もしあなたが、グラフィックス・デザイナー、もしくはウェブ・デザイナーであって、（あなたが最も確実に望んでいるであろう）画像もしくはレイアウトの全てのバージョンを管理したいのであれば、バージョン管理システム（VCS）はとても賢く利用できるものです｡VCSを使ってできることとしては、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更を見直したり、誰が最後に問題を引き起こすだろう何かを修正したか、誰が、何時、課題を導入したかを確認したりといった様々なことがあります。VCSを使うということはまた、一般的に、何かをもみくちゃにするか、ファイルを失うとしても、簡単に復活させることができることを意味します。加えて、とても僅かな諸経費で、それら全てを得ることができます。 +もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てバージョンを保存しておきたいとすると（きっとそうしたいですよね）、バージョン管理システム（VCS）を使うというのはいい考えです。VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。それに、これらのことにかかるオーバーヘッドは僅かなものです。 ### ローカル・バージョン管理システム ### -多くの人々の選り抜きのバージョン管理手法は、他のディレクトリ（もし彼らが賢いのであれば、恐らく日時が書かれたディレクトリ）にファイルをコピーするというものです。このアプローチは、とても単純なためにすごく一般的ですが、信じられない間違い傾向もあります。どのディレクトリにいるのか忘れやすいですし、偶然に間違ったファイルに書き込んだり、意図しないファイルに上書きしたりします。 +多くの人々が使っているバージョン管理手法は、他のディレクトリ（気の利いた人であれば、日時のついたディレクトリ）にファイルをコピーするというものです。このアプローチはとても単純なので非常に一般的ですが、信じられないほど間違いが起こりやすいものです。どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。 -この問題を扱うため、大昔にプログラマは、バージョン管理下で全ての変更をファイルに保持するシンプルなデータベースを持つ、ローカルなバージョン管理システムを開発しました（図1-1参照）。 +この問題を扱うため、はるか昔のプログラマは、ローカルのVCSを開発しました。それは、バージョン管理下のファイルに対する全ての変更を保持するシンプルなデータベースによるものでした（図1-1参照）。 Insert 18333fig0101.png 図1-1. ローカル・バージョン管理図解 -もっとも有名なVCSツールの一つが、RCSと呼ばれるシステムでした。今日でも依然として多くのコンピューターに入っています。人気のMac OS Xオペレーティング・システムさえも、開発者ツールをインストールしたときは、rcsコマンドを含みます。このツールは基本的に、ディスク上に特殊フォーマットで、一つのリビジョンからもう一つのリビジョンへのパッチ（これはファイル間の差分です）の集合を保持することで稼動します。そういうわけで、全てのパッチを積み上げることで、いつかは、あらゆる時点の、あらゆるファイルのように見えるものを再生成する事ができます。 +もっとも有名なVCSツールの一つは、RCSと呼ばれるシステムでした。今日でも、依然として多くのコンピューターに入っています。人気のMac OS Xオペレーティング・システムでも、開発者ツールをインストールするとrcsコマンドが入っています。このツールは基本的に、リビジョン間のパッチ（ファイル間の差分）の集合を特殊なフォーマットでディスク上に保持するという仕組みで動いています。こうすることで、任意のファイルについて、それが過去の任意の時点でどういうものだったかということを、パッチを重ね上げていくことで再現することができます。 ### 集中バージョン管理システム ### -次に人々が遭遇した大きな問題は、他のシステムの開発者と共同制作をする必要があることです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。CVSやSubversion、Perforceのような、これらのシステムは、全てのバージョン管理されたファイルと、その中央の場所からファイルをチェック・アウトする多数のクライアントを含む単一のサーバーを持ちます。長年の間、これはバージョン管理の標準となって来ました（図1-2参照）。 +次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。このようなシステムにはCVS、Subversion、Perforceなどがありますが、それらは全てのバージョン管理されたファイルを持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。長年の間、これはバージョン管理の標準でした（図1-2参照）。 Insert 18333fig0102.png 図1-2. 集中バージョン管理図解 -この構成は、特にローカルVCSと比較して、多くの利点を提供します。例えば、全ての人は、プロジェクトのその他の全ての人々が何をしているのか、一定の程度は知っています。管理者は、誰が何をできるのかについて、きめ細かい統制手段を持ちます。このため、一つのCVCSを管理するということは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。 +この構成には、特にローカルVCSと比べると、多くの利点があります。例えば、プロジェクトのその他の全ての人々が何をしているのか、全員がある程度は知っています。管理者は、誰が何をできるのかについて、きめ細かくコントロールできます。それに、一つのCVCSを管理するのは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。 -しかしながら、この構成はまた、深刻な不利益も持ちます。もっとも明白なのは、中央サーバーで発生する単一障害点です。もし、そのサーバーが1時間の間停止すると、その1時間の間は誰も全く、共同作業や、彼らが作業を進めている全てに対してバージョン変更の保存をすることができなくなります。もし中央データベースがのっているハードディスクが破損し、適切なバックアップが保持されていないとすると、人々が偶然にローカル・マシンに持っていた幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）を除いた、プロジェクト全体の履歴を失うことになります。ローカルVCSシステムも、これと同じ問題に悩まされます。つまり、単一の場所にプロジェクトの全体の履歴を持っているときはいつでも、全てを失う事を覚悟することになります。 +しかし、この構成には深刻なマイナス面もあります。もっとも明白なのは、中央サーバーという単一障害点です。そのサーバーが1時間の間停止すると、その1時間の間は全員が、共同作業も全くできず、作業中のものにバージョンをつけて保存をすることもできなくなります。もし中央データベースのあるハードディスクが破損し、適切なバックアップが保持されていなければ、完全に全てを失ってしまいます。プロジェクトの全ての履歴は失われ、残るのは個人のローカル・マシンにたまたまあった幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）ぐらいです。ローカルVCSシステムも、これと同じ問題があります。つまり、一つの場所にプロジェクトの全体の履歴を持っていると、全てを失うリスクが常にあります。 ### 分散バージョン管理システム ### -ここから分散バージョン管理システム(DVCSs)に入ります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングします。故にどのサーバーが故障したとして、故障したサーバーを介してそれらのDVCSが共同作業をしていたとしても、あらゆるクライアント・リポジトリは修復のためにサーバーにコピーして戻す事ができます。そのサーバーを介してコラボレーションしていたシステムは, どれか一つのクライアントのリポジトリからサーバー復旧の為バックアップをコピーすることができます. 全てのチェックアウトは、実は全データの完全バックアップなのです(図1-3を参照)。 +ここで分散バージョン管理システム(DVCSs)の出番になります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングするのです。そのため、あるサーバーが故障して、DVCSがそのサーバーを介して共同作業をしていたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。チェックアウトは全て、実際は全データの完全バックアップなのです(図1-3を参照)。 Insert 18333fig0103.png 図1-3. 分散バージョン管理システムの図解 -そのうえ、これらのDVCSの多くは、 連携する複数のリモート・リポジトリを扱いながら大変よく機能するため、同一のプロジェクト内において、同時に異なった方法で、異なる人々のグループと共同作業が可能です。このことは、集中システムでは不可能であった階層モデルのような、幾つかの様式のワークフローを始めることを許します。 +さらに、これらのDVCSの多くは、複数のリモート・リポジトリで作業をするということがうまく扱えるようになっているので、異なった方法で異なる人々のグループと同時に同じプロジェクト内で共同作業することができます。このため、階層モデルなどの、集中システムでは不可能な幾つかのワークフローが構築できるようになっています。 ## Git略史 ## From 1e136d26f3beb70739a3eb3986a9a0afb48f9f42 Mon Sep 17 00:00:00 2001 From: Hiroshi Manabe Date: Fri, 17 Oct 2014 21:21:37 +0900 Subject: [PATCH 261/291] [ja] Fixed the translation according to the advices. --- ja/01-introduction/01-chapter1.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown index afdbfaa44..97f5d508b 100644 --- a/ja/01-introduction/01-chapter1.markdown +++ b/ja/01-introduction/01-chapter1.markdown @@ -6,7 +6,7 @@ バージョン管理とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを示していますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。 -もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てバージョンを保存しておきたいとすると（きっとそうしたいですよね）、バージョン管理システム（VCS）を使うというのはいい考えです。VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。それに、これらのことにかかるオーバーヘッドは僅かなものです。 +もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てのバージョンを保存しておきたいとすると（きっとそうしたいですよね）、バージョン管理システム（VCS）を使うというのはいい考えです。VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。それに、これらのことにかかるオーバーヘッドは僅かなものです。 ### ローカル・バージョン管理システム ### @@ -21,18 +21,18 @@ Insert 18333fig0101.png ### 集中バージョン管理システム ### -次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。このようなシステムにはCVS、Subversion、Perforceなどがありますが、それらは全てのバージョン管理されたファイルを持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。長年の間、これはバージョン管理の標準でした（図1-2参照）。 +次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。このようなシステムにはCVS、Subversion、Perforceなどがありますが、それらはバージョン管理されたファイルを全て持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。長年の間、これはバージョン管理の標準でした（図1-2参照）。 Insert 18333fig0102.png 図1-2. 集中バージョン管理図解 -この構成には、特にローカルVCSと比べると、多くの利点があります。例えば、プロジェクトのその他の全ての人々が何をしているのか、全員がある程度は知っています。管理者は、誰が何をできるのかについて、きめ細かくコントロールできます。それに、一つのCVCSを管理するのは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。 +この構成には、特にローカルVCSと比べると、多くの利点があります。例えば、プロジェクトの他のみんなが何をしているのか、全員がある程度わかります。管理者は、誰が何をできるのかについて、きめ細かくコントロールできます。それに、一つのCVCSを管理するのは、全てのクライアントのローカル・データベースを取り扱うより、ずっと簡単です。 しかし、この構成には深刻なマイナス面もあります。もっとも明白なのは、中央サーバーという単一障害点です。そのサーバーが1時間の間停止すると、その1時間の間は全員が、共同作業も全くできず、作業中のものにバージョンをつけて保存をすることもできなくなります。もし中央データベースのあるハードディスクが破損し、適切なバックアップが保持されていなければ、完全に全てを失ってしまいます。プロジェクトの全ての履歴は失われ、残るのは個人のローカル・マシンにたまたまあった幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）ぐらいです。ローカルVCSシステムも、これと同じ問題があります。つまり、一つの場所にプロジェクトの全体の履歴を持っていると、全てを失うリスクが常にあります。 ### 分散バージョン管理システム ### -ここで分散バージョン管理システム(DVCSs)の出番になります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングするのです。そのため、あるサーバーが故障して、DVCSがそのサーバーを介して共同作業をしていたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。チェックアウトは全て、実際は全データの完全バックアップなのです(図1-3を参照)。 +ここで分散バージョン管理システム(DVCSs)の出番になります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングするのです。そのため、あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。チェックアウトは全て、実際は全データの完全バックアップなのです(図1-3を参照)。 Insert 18333fig0103.png 図1-3. 分散バージョン管理システムの図解 From 1ea1ef4bf15ce6488856653f3950e618bb30ca0a Mon Sep 17 00:00:00 2001 From: JuanLuM Date: Tue, 21 Oct 2014 11:41:40 +0200 Subject: [PATCH 262/291] Improve understanding what git does --- es/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown index 44f715729..f8aa9eb93 100644 --- a/es/03-git-branching/01-chapter3.markdown +++ b/es/03-git-branching/01-chapter3.markdown @@ -15,7 +15,7 @@ Para ilustrar esto, vamos a suponer, por ejemplo, que tienes una carpeta con tre $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' -Cuando creas una confirmación con el comando `git commit`, Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y guarda en el repositorio Git una copia de cada uno de los archivos contenidos en ella/s. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al nodo correspondiente del árbol de proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario. +Cuando creas una confirmación con el comando `git commit`, Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y las guarda como objetos árbol en el repositorio Git. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al objeto árbol raiz del proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario. En este momento, el repositorio de Git contendrá cinco objetos: un "blob" para cada uno de los tres archivos, un árbol con la lista de contenidos de la carpeta (más sus respectivas relaciones con los "blobs"), y una confirmación de cambios (commit) apuntando a la raiz de ese árbol y conteniendo el resto de metadatos pertinentes. Conceptualmente, el contenido del repositorio Git será algo parecido a la Figura 3-1 From 1a0218935d778012c845a04b890729410f9380ee Mon Sep 17 00:00:00 2001 From: JuanLuM Date: Wed, 22 Oct 2014 09:03:21 +0200 Subject: [PATCH 263/291] Remove errata - 01-chapter3.markdown - es --- es/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown index f8aa9eb93..cd69282b4 100644 --- a/es/03-git-branching/01-chapter3.markdown +++ b/es/03-git-branching/01-chapter3.markdown @@ -174,7 +174,7 @@ Ahora, los cambios realizados están ya en la instantánea (snapshot) de la conf Insert 18333fig0314.png Figura 3-14. Tras la fusión (merge), la rama `master` apunta al mismo sitio que la rama `hotfix`. -Tras haber resuelto el problema urgente que te habií interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`: +Tras haber resuelto el problema urgente que te había interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`: $ git branch -d hotfix Deleted branch hotfix (3a0874c). From 7c1a2498e37b5ee245c57ed54168a7d678901ca9 Mon Sep 17 00:00:00 2001 From: JuanLuM Date: Wed, 22 Oct 2014 13:17:15 +0200 Subject: [PATCH 264/291] Reorganize to improve understanding --- es/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown index cd69282b4..7ba3c8877 100644 --- a/es/03-git-branching/01-chapter3.markdown +++ b/es/03-git-branching/01-chapter3.markdown @@ -424,7 +424,7 @@ Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboraci Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viéndolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto. -La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de `serverfix` en el servidor esté bajo la rama remota `origin/serverfix`: +La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota `origin/serverfix` una referencia a donde esté la versión de `serverfix` en el servidor: $ git fetch origin remote: Counting objects: 20, done. From 7192c2693d709c1492f11bdf6bdf0c73e39ff454 Mon Sep 17 00:00:00 2001 From: Christian Sauer Date: Wed, 22 Oct 2014 10:24:38 -0400 Subject: [PATCH 265/291] Fix git stash-unapply example The example for `git stash-unapply` starts with `git stash` which will create a new stash and not apply a stash to the working copy. The first command should be either `git stash apply` (which is what I changed it to) or `git stash apply stash@{0}` or a variant thereof. --- az/06-git-tools/01-chapter6.markdown | 2 +- cs/06-git-tools/01-chapter6.markdown | 2 +- de/06-git-tools/01-chapter6.markdown | 2 +- en/06-git-tools/01-chapter6.markdown | 2 +- fr/06-git-tools/01-chapter6.markdown | 2 +- it/06-git-tools/01-chapter6.markdown | 2 +- ja/06-git-tools/01-chapter6.markdown | 2 +- ko/06-git-tools/01-chapter6.markdown | 2 +- nl/06-git-tools/01-chapter6.markdown | 2 +- no-nb/06-git-tools/01-chapter6.markdown | 2 +- pl/06-git-tools/01-chapter6.markdown | 2 +- pt-br/06-git-tools/01-chapter6.markdown | 2 +- ru/06-git-tools/01-chapter6.markdown | 2 +- zh-tw/06-git-tools/01-chapter6.markdown | 2 +- zh/06-git-tools/01-chapter6.markdown | 2 +- 15 files changed, 15 insertions(+), 15 deletions(-) diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown index a6f0108af..2b18d87e0 100644 --- a/az/06-git-tools/01-chapter6.markdown +++ b/az/06-git-tools/01-chapter6.markdown @@ -501,7 +501,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash: You may want to create an alias and effectively add a `stash-unapply` command to your git. For example: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index 768f9c2f9..516af28d3 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -518,7 +518,7 @@ Jestliže nespecifikujete konkrétní odklad, Git předpokládá odklad posledn Můžete si také vytvořit alias a do svého gitu přidat například příkaz `stash-unapply`: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown index 0a16b2f0a..69f395bde 100644 --- a/de/06-git-tools/01-chapter6.markdown +++ b/de/06-git-tools/01-chapter6.markdown @@ -660,7 +660,7 @@ An dieser Stelle noch einmal der Hinweis, dass Git den zuletzt erstellten Stash Wenn Du dieses Feature öfters benötigst, ist es wahrscheinlich sinnvoll, einen Alias `stash-unapply` in Git dafür anzulegen: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 18044f27e..39eb135f3 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -501,7 +501,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash: You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown index 81009134a..7be8d77ba 100644 --- a/fr/06-git-tools/01-chapter6.markdown +++ b/fr/06-git-tools/01-chapter6.markdown @@ -577,7 +577,7 @@ La création d'un alias permettra d'ajouter effectivement la commande `stash-una Par exemple : $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown index e358907eb..1fc8f9db6 100644 --- a/it/06-git-tools/01-chapter6.markdown +++ b/it/06-git-tools/01-chapter6.markdown @@ -501,7 +501,7 @@ Di nuovo, se non specifichi un accantonamento, Git assume che sia l'ultimo: Puoi voler creare un alias per avere un comando `stash-unapply` nel tuo Git. Per esempio: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown index 40379d5ee..85bb6a482 100644 --- a/ja/06-git-tools/01-chapter6.markdown +++ b/ja/06-git-tools/01-chapter6.markdown @@ -496,7 +496,7 @@ apply オプションは、スタックに隠した作業を再度適用する 次の例のようにエイリアスを作れば、Git に `stash-unapply` コマンドを追加したのと事実上同じことになります。 $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... 何か作業をして ... $ git stash-unapply diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown index ae30bf7f2..d6ad75bad 100644 --- a/ko/06-git-tools/01-chapter6.markdown +++ b/ko/06-git-tools/01-chapter6.markdown @@ -497,7 +497,7 @@ Stash를 명시하지 않으면 Git은 가장 최근의 Stash를 사용한다: `stash-unapply`라는 alias를 만들고 편리하게 할 수도 있다: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown index d4cc79d8f..6049137da 100644 --- a/nl/06-git-tools/01-chapter6.markdown +++ b/nl/06-git-tools/01-chapter6.markdown @@ -538,7 +538,7 @@ Nogmaals: als je geen stash specificeert gaat Git van de meest recente stash uit Wellicht wil je een alias maken en effectief een `stash-unapply` commando aan je Git toevoegen. Bijvoorbeeld: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown index eaa9b42a0..f7254cf30 100644 --- a/no-nb/06-git-tools/01-chapter6.markdown +++ b/no-nb/06-git-tools/01-chapter6.markdown @@ -501,7 +501,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash: You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown index 2bb6cb043..a00cf9ea0 100644 --- a/pl/06-git-tools/01-chapter6.markdown +++ b/pl/06-git-tools/01-chapter6.markdown @@ -683,7 +683,7 @@ Możesz chcieć stworzyć alias i dodać komendę `stash-unapply` do Gita. Na pr $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown index 8b4da423a..1b4cefba7 100644 --- a/pt-br/06-git-tools/01-chapter6.markdown +++ b/pt-br/06-git-tools/01-chapter6.markdown @@ -497,7 +497,7 @@ Novamente, se você não especificar um stash, Git assume que é o stash mais re Você pode querer criar um alias e adicionar explicitamente um comando `stash-unapply` no seu git. Por exemplo: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown index 470168f78..05b60d68a 100644 --- a/ru/06-git-tools/01-chapter6.markdown +++ b/ru/06-git-tools/01-chapter6.markdown @@ -501,7 +501,7 @@ Insert 18333fig0601.png Если хотите, сделайте псевдоним и добавьте в свой Git команду `stash-unapply`. Например, так: $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown index 9315aedd9..73c4ba300 100644 --- a/zh-tw/06-git-tools/01-chapter6.markdown +++ b/zh-tw/06-git-tools/01-chapter6.markdown @@ -500,7 +500,7 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊 你可能會想要新建一個別名，在你的 git 增加一個 `stash-unapply` 命令，這樣更有效率。例如： $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown index b0929d272..26bb33096 100644 --- a/zh/06-git-tools/01-chapter6.markdown +++ b/zh/06-git-tools/01-chapter6.markdown @@ -500,7 +500,7 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上 你可能会想要新建一个別名，在你的 Git 里增加一个 `stash-unapply` 命令，这样更有效率。例如： $ git config --global alias.stash-unapply '!git stash show -p | git apply -R' - $ git stash + $ git stash apply $ #... work work work $ git stash-unapply From 64c9194e3640c5f73f11ffebe07f56de8e1f2d28 Mon Sep 17 00:00:00 2001 From: Scott Chacon Date: Tue, 28 Oct 2014 09:37:41 +0100 Subject: [PATCH 266/291] Rename README.md to README.original.md --- README.md => README.original.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename README.md => README.original.md (100%) diff --git a/README.md b/README.original.md similarity index 100% rename from README.md rename to README.original.md From 8e850958178917a3550aaf4a58c7177b3483ce38 Mon Sep 17 00:00:00 2001 From: Scott Chacon Date: Tue, 28 Oct 2014 09:40:48 +0100 Subject: [PATCH 267/291] Create new README --- README.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 000000000..39d3f6dfa --- /dev/null +++ b/README.md @@ -0,0 +1,9 @@ +# Pro Git, 1st Edition + +This is the source for the 1st edition of the Pro Git book. The second edition has since been released and is what will be maintained and published going forward. Please suggest any changes to that version instead. + +You can find the new edition at: + +https://github.com/progit/progit2 + +If you're looking for the original README content, it can be found in the [README.original.md](README.original.md) file. From 160b086cb3dc241f1be66fb73020b2d5ae6cc743 Mon Sep 17 00:00:00 2001 From: Tom Schady Date: Tue, 16 Dec 2014 11:09:03 -0600 Subject: [PATCH 268/291] correct the branch name to distinguish from subdir --- az/06-git-tools/01-chapter6.markdown | 2 +- cs/06-git-tools/01-chapter6.markdown | 2 +- de/06-git-tools/01-chapter6.markdown | 2 +- en/06-git-tools/01-chapter6.markdown | 2 +- fr/06-git-tools/01-chapter6.markdown | 2 +- it/06-git-tools/01-chapter6.markdown | 2 +- ja/06-git-tools/01-chapter6.markdown | 2 +- nl/06-git-tools/01-chapter6.markdown | 2 +- no-nb/06-git-tools/01-chapter6.markdown | 2 +- pl/06-git-tools/01-chapter6.markdown | 2 +- pt-br/06-git-tools/01-chapter6.markdown | 2 +- ru/06-git-tools/01-chapter6.markdown | 2 +- zh-tw/06-git-tools/01-chapter6.markdown | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown index 2b18d87e0..ccf9797c0 100644 --- a/az/06-git-tools/01-chapter6.markdown +++ b/az/06-git-tools/01-chapter6.markdown @@ -1095,7 +1095,7 @@ Now you have the root of the Rack project in your `rack_branch` branch and your $ ls README -You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project: +You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack_branch` branch into the `rack` subdirectory of your `master` branch of your main project: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index 516af28d3..24e5a12d3 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -1136,7 +1136,7 @@ Nyní máte kořenový adresář s projektem Rack ve větvi `rack_branch` a vlas $ ls README -Projekt Rack chcete do projektu `master` natáhnout jako podadresář. V systému Git k tomu slouží příkaz `git read-tree`. O příkazu `read-tree` a jeho příbuzných se více dočtete v kapitole 9, nyní však vězte, že načte kořenový strom jedné větve do vaší aktuální oblasti připravených změn a do pracovního adresáře. Přepnuli jste zpět na větev `master` a větev `rack` natáhnete do podadresáře `rack` své větve `master` hlavního projektu: +Projekt Rack chcete do projektu `master` natáhnout jako podadresář. V systému Git k tomu slouží příkaz `git read-tree`. O příkazu `read-tree` a jeho příbuzných se více dočtete v kapitole 9, nyní však vězte, že načte kořenový strom jedné větve do vaší aktuální oblasti připravených změn a do pracovního adresáře. Přepnuli jste zpět na větev `master` a větev `rack_branch` natáhnete do podadresáře `rack` své větve `master` hlavního projektu: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown index 69f395bde..e0af3d441 100644 --- a/de/06-git-tools/01-chapter6.markdown +++ b/de/06-git-tools/01-chapter6.markdown @@ -1458,7 +1458,7 @@ Nach der Ausführung der drei Befehle befindet sich das Rack-Projekt in Deinem B -Jetzt möchten wir das Rack-Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging-Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt: +Jetzt möchten wir das Rack-Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging-Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack_branch` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown index 39eb135f3..286ee7237 100644 --- a/en/06-git-tools/01-chapter6.markdown +++ b/en/06-git-tools/01-chapter6.markdown @@ -1119,7 +1119,7 @@ Now you have the root of the Rack project in your `rack_branch` branch and your $ ls README -You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project: +You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack_branch` branch into the `rack` subdirectory of your `master` branch of your main project: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown index 7be8d77ba..07adf11d4 100644 --- a/fr/06-git-tools/01-chapter6.markdown +++ b/fr/06-git-tools/01-chapter6.markdown @@ -1316,7 +1316,7 @@ Si vous récupérez l'une puis l'autre branche, vous pouvez voir que vous avez d Pour tirer le projet Rack dans votre projet `master` comme un sous-répertoire, vous pouvez utiliser la commande `git read-tree`. Vous apprendrez davantage sur `read-tree` et compagnie dans le chapitre 9, mais pour le moment, sachez qu'il lit la racine d'une de vos branches et l'inscrit dans votre index et votre répertoire de travail. -Vous venez juste de commuter vers votre branche `master` et vous tirez la branche `rack` vers le sous-répertoire `rack` de votre branche `master` de votre projet principal : +Vous venez juste de commuter vers votre branche `master` et vous tirez la branche `rack_branch` vers le sous-répertoire `rack` de votre branche `master` de votre projet principal : $ git read-tree --prefix=rack/ -u rack_branch diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown index 1fc8f9db6..50559d39e 100644 --- a/it/06-git-tools/01-chapter6.markdown +++ b/it/06-git-tools/01-chapter6.markdown @@ -1120,7 +1120,7 @@ Ora hai la root del progetto Rack nel tuo branch `rack_branch` e il tuo progetto $ ls README -Ora vuoi inviare il progetto Rack nel tuo progetto `master` come una sottodirectory e in Git puoi farlo con `git read-tree`. Conoscerai meglio `read-tree` e i suoi amici nel Capitolo 9, ma per ora sappi che legge la radice di un branch nella tua area di staging della tua directory di lavoro. Sei appena ritornato nel tuo branch `master` e hai scaricato il branch `rack` nella directory `rack` del branch `master` del tuo progetto principale: +Ora vuoi inviare il progetto Rack nel tuo progetto `master` come una sottodirectory e in Git puoi farlo con `git read-tree`. Conoscerai meglio `read-tree` e i suoi amici nel Capitolo 9, ma per ora sappi che legge la radice di un branch nella tua area di staging della tua directory di lavoro. Sei appena ritornato nel tuo branch `master` e hai scaricato il branch `rack_branch` nella directory `rack` del branch `master` del tuo progetto principale: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown index 85bb6a482..ddf152a2f 100644 --- a/ja/06-git-tools/01-chapter6.markdown +++ b/ja/06-git-tools/01-chapter6.markdown @@ -1102,7 +1102,7 @@ Git でこれと同じことをするためのよい方法は、それぞれの $ ls README -Rack プロジェクトを `master` プロジェクトのサブディレクトリとして取り込みたくなったときには、`git read-tree` を使います。`read-tree` とその仲間たちについては第 9 章で詳しく説明します。現時点では、とりあえず「あるブランチのルートツリーを読み込んで、それを現在のステージングエリアと作業ディレクトリに書き込むもの」だと認識しておけばよいでしょう。まず `master` ブランチに戻り、`rack` ブランチの内容を `master` ブランチの `rack` サブディレクトリに取り込みます。 +Rack プロジェクトを `master` プロジェクトのサブディレクトリとして取り込みたくなったときには、`git read-tree` を使います。`read-tree` とその仲間たちについては第 9 章で詳しく説明します。現時点では、とりあえず「あるブランチのルートツリーを読み込んで、それを現在のステージングエリアと作業ディレクトリに書き込むもの」だと認識しておけばよいでしょう。まず `master` ブランチに戻り、`rack_branch` ブランチの内容を `master` ブランチの `rack` サブディレクトリに取り込みます。 $ git read-tree --prefix=rack/ -u rack_branch diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown index 6049137da..4309c372c 100644 --- a/nl/06-git-tools/01-chapter6.markdown +++ b/nl/06-git-tools/01-chapter6.markdown @@ -1146,7 +1146,7 @@ Nu heb je de root van het Rack project in je `rack_branch` branch en je eigen pr $ ls README -Je gaat nu het Rack project in je `master` project pullen als een subdirectory. Je kunt dat in Git doen met `git read-tree`. Je zult meer over `read-tree` en zijn vriendjes leren in Hoofdstuk 9, maar weet voor nu dat het de roottree van een branch in je huidige staging area en werkdirectory leest. Je hebt zojuist teruggewisseld naar je `master` branch, en je pulled de `rack` branch in de `rack` subdirectory van de `master` branch van je hoofdproject: +Je gaat nu het Rack project in je `master` project pullen als een subdirectory. Je kunt dat in Git doen met `git read-tree`. Je zult meer over `read-tree` en zijn vriendjes leren in Hoofdstuk 9, maar weet voor nu dat het de roottree van een branch in je huidige staging area en werkdirectory leest. Je hebt zojuist teruggewisseld naar je `master` branch, en je pulled de `rack_branch` branch in de `rack` subdirectory van de `master` branch van je hoofdproject: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown index f7254cf30..453854fb3 100644 --- a/no-nb/06-git-tools/01-chapter6.markdown +++ b/no-nb/06-git-tools/01-chapter6.markdown @@ -1113,7 +1113,7 @@ Now you have the root of the Rack project in your `rack_branch` branch and your $ ls README -You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project: +You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack_branch` branch into the `rack` subdirectory of your `master` branch of your main project: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown index a00cf9ea0..9e4d7353a 100644 --- a/pl/06-git-tools/01-chapter6.markdown +++ b/pl/06-git-tools/01-chapter6.markdown @@ -1502,7 +1502,7 @@ Masz teraz zawartość projektu Rack w gałęzi `rack_branch`, a swój projekt w $ ls README -Chcesz jednak, pobrać projekt Rack do swojej gałęzi `master` jako podkatalog. Możesz to zrobić, za pomocą komendy Gita `git read-tree`. Dowiesz się więcej na temat komendy `read-tree` i jej podobnych w rozdziale 9, ale na teraz wiedz, że odczytuje ona drzewo projektu w jednej gałęzi i włącza je do obecnego katalogu i przechowalni. Ponownie zmieniasz gałąź na `master` i pobierasz gałąź `rack` do podkatalogu `rack` w gałęzi `master` w projekcie: +Chcesz jednak, pobrać projekt Rack do swojej gałęzi `master` jako podkatalog. Możesz to zrobić, za pomocą komendy Gita `git read-tree`. Dowiesz się więcej na temat komendy `read-tree` i jej podobnych w rozdziale 9, ale na teraz wiedz, że odczytuje ona drzewo projektu w jednej gałęzi i włącza je do obecnego katalogu i przechowalni. Ponownie zmieniasz gałąź na `master` i pobierasz gałąź `rack_branch` do podkatalogu `rack` w gałęzi `master` w projekcie: diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown index 1b4cefba7..2f5916f52 100644 --- a/pt-br/06-git-tools/01-chapter6.markdown +++ b/pt-br/06-git-tools/01-chapter6.markdown @@ -1091,7 +1091,7 @@ Agora você tem a raiz do projeto Rack no seu branch `rack_branch` e o seu proje $ ls README -Você quer colocar o projeto Rack no seu projeto `master` como um subdiretório. Você pode fazer isso no Git com `git read-tree`. Você irá aprender mais sobre `read-tree` e seus companheiros no Capítulo 9, mas por enquanto saiba que ele escreve a raiz da árvore de um branch na sua área de seleção e diretório de trabalho. Você volta para o branch `master`, você coloca o branch `rack` no subdiretório `rack` no branch `master` do seu projeto principal: +Você quer colocar o projeto Rack no seu projeto `master` como um subdiretório. Você pode fazer isso no Git com `git read-tree`. Você irá aprender mais sobre `read-tree` e seus companheiros no Capítulo 9, mas por enquanto saiba que ele escreve a raiz da árvore de um branch na sua área de seleção e diretório de trabalho. Você volta para o branch `master`, você coloca o branch `rack_branch` no subdiretório `rack` no branch `master` do seu projeto principal: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown index 05b60d68a..e6801beb6 100644 --- a/ru/06-git-tools/01-chapter6.markdown +++ b/ru/06-git-tools/01-chapter6.markdown @@ -1095,7 +1095,7 @@ Git решает эту задачу, используя подмодули (sub $ ls README -Допустим, вы хотите поместить проект Rack в подкаталог своего проекта в ветке `master`. Вы можете сделать это в Git'е командой `git read-tree`. Вы узнаете больше про команду `read-tree` и её друзей в главе 9, а пока достаточно знать, что она считывает корень дерева одной ветки в индекс и рабочий каталог. Вам достаточно переключиться обратно на ветку `master` и вытянуть ветку `rack` в подкаталог `rack` основного проекта из ветки `master`: +Допустим, вы хотите поместить проект Rack в подкаталог своего проекта в ветке `master`. Вы можете сделать это в Git'е командой `git read-tree`. Вы узнаете больше про команду `read-tree` и её друзей в главе 9, а пока достаточно знать, что она считывает корень дерева одной ветки в индекс и рабочий каталог. Вам достаточно переключиться обратно на ветку `master` и вытянуть ветку `rack_branch` в подкаталог `rack` основного проекта из ветки `master`: $ git read-tree --prefix=rack/ -u rack_branch diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown index 73c4ba300..d45286922 100644 --- a/zh-tw/06-git-tools/01-chapter6.markdown +++ b/zh-tw/06-git-tools/01-chapter6.markdown @@ -1108,7 +1108,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫 $ ls README -要將 Rack 專案當作子目錄拉取到你的 `master` 專案中。你可以在 Git 中用 `git read-tree` 來實現。你會在第9章學到更多與 `read-tree` 和它的朋友相關的東西，目前你會知道它讀取一個分支的根目錄樹到當前的暫存區和工作目錄。你只要切換回你的 `master` 分支，然後拉取 `rack` 分支到你主專案的 `master` 分支的 `rack` 子目錄： +要將 Rack 專案當作子目錄拉取到你的 `master` 專案中。你可以在 Git 中用 `git read-tree` 來實現。你會在第9章學到更多與 `read-tree` 和它的朋友相關的東西，目前你會知道它讀取一個分支的根目錄樹到當前的暫存區和工作目錄。你只要切換回你的 `master` 分支，然後拉取 `rack_branch` 分支到你主專案的 `master` 分支的 `rack` 子目錄： $ git read-tree --prefix=rack/ -u rack_branch From 940b5cc898e3dd929eaffb559f91f23842d30384 Mon Sep 17 00:00:00 2001 From: berniedurfee-ge Date: Thu, 18 Dec 2014 15:34:38 -0500 Subject: [PATCH 269/291] Update 01-chapter1.markdown Added install of more required Yum packages: perl-devel, asciidoc and xmlto --- en/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown index 9cd2d5620..62f97d3b9 100644 --- a/en/01-introduction/01-chapter1.markdown +++ b/en/01-introduction/01-chapter1.markdown @@ -129,7 +129,7 @@ If you can, it’s generally useful to install Git from source, because you’ll To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: $ yum install curl-devel expat-devel gettext-devel \ - openssl-devel zlib-devel + openssl-devel zlib-devel perl-devel asciidoc xmlto $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev From 476339756aa1b9c66ed240ac4f193c8052569d80 Mon Sep 17 00:00:00 2001 From: jooneyp Date: Wed, 24 Dec 2014 01:34:57 +0900 Subject: [PATCH 270/291] Update 01-chapter4.markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 오타 / 의역 수정. --- ko/04-git-server/01-chapter4.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown index b093a204d..30b3c455a 100644 --- a/ko/04-git-server/01-chapter4.markdown +++ b/ko/04-git-server/01-chapter4.markdown @@ -62,7 +62,7 @@ SSH를 통해 Git 저장소를 Clone하려면 `ssh://`로 시작하는 URL을 #### 장점 #### -SSH는 장점이 매우 많은 프로토콜이다. 첫째, 누가 리모트에서 저장소에 접근하는지 알고 싶다면 SSH를 사용해야 한다. 둘째, SSH는 상대적으로 설정하기 쉽다. SSH 데몬은 정말 흔하다. 네트워크 관리자은 SSH 데몬을 다루어본 경험이 있고 대부분의 OS 배포판에는 SSH 데몬과 관리도구가 모두 들어 있다. 셋째, SSH를 통해 접근하면 보안에 안전하다. 모든 데이터는 암호화되어 인증된 상태로 전송된다. 마지막으로 SSH는 전송 시 데이터를 가능한 압축하기 때문에 효율적이다. +SSH는 장점이 매우 많은 프로토콜이다. 첫째, 누가 리모트에서 저장소에 접근하는지 알고 싶다면 SSH를 사용해야 한다. 둘째, SSH는 상대적으로 설정하기 쉽다. SSH 데몬은 정말 흔하다. 거의 모든 네트워크 관리자는 SSH 데몬을 다루어본 경험을 가지고 있을것이고, 대부분의 OS 배포판에는 SSH 데몬과 관리도구가 들어 있다. 셋째, SSH를 통해 접근하면 보안에 안전하다. 모든 데이터는 암호화되어 인증된 상태로 전송된다. 마지막으로 SSH는 전송 시 데이터를 가능한 압축하기 때문에 효율적이다. #### 단점 #### @@ -70,7 +70,7 @@ SSH의 단점은 익명으로 접근할 수 없다는 것이다. 심지어 읽 ### Git 프로토콜 ### -Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다. +Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push를 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다. #### 장점 #### @@ -96,7 +96,7 @@ post-update 훅은 Git에 포함되어 있으며 `git update-server-info`라는 여기서는 Apache 서버가 기본으로 사용하는 `/var/www/htdocs`을 루트 디렉토리로 사용하지만 다른 웹 서버를 사용해도 된다. 단순히 Bare 저장소를 HTTP 문서 루트에 넣으면 된다. Git 데이터는 일반적인 정적 파일처럼 취급된다(*9장*에서 정확히 어떻게 처리하는지 다룰 것이다). -HTTP를 통해서 Push하는 것도 가능하다. 단지 이 방법은 잘 사용하지 않는 WebDAV 환경을 완벽하게 구축해야 한다. 잘 사용하지 않기 때문에 이 책에서도 다루지 않는다. HTTP 프로토콜로 Push하고 싶으면 `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` 읽고 저장소를 만들면 된다. HTTP를 통해서 Push하는 방법의 좋은 점은 WebDAV 서버를 아무거나 골라 쓸 수 있다는 것이다. 그래서 WebDAV를 지원하는 웹 호스팅 업체를 이용하면 이 기능을 사용할 수 있다. +HTTP를 통해서 Push하는 것도 가능하다. 단지 이 방법은 잘 사용하지 않는 WebDAV 환경을 완벽하게 구축해야 한다. 잘 사용하지 않기 때문에 이 책에서도 다루지 않는다. HTTP 프로토콜로 Push하고 싶으면 `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` 을 읽고 저장소를 만들면 된다. HTTP를 통해서 Push하는 방법의 좋은 점은 WebDAV 서버를 아무거나 골라 쓸 수 있다는 것이다. 그래서 WebDAV를 지원하는 웹 호스팅 업체를 이용하면 이 기능을 사용할 수 있다. #### 장점 #### From a45874e65dc5aa34159ad9e5450781d882d7a96f Mon Sep 17 00:00:00 2001 From: Jeffrey Slort Date: Thu, 15 Jan 2015 23:11:13 +0100 Subject: [PATCH 271/291] lid woorden en aanwijzende voornaam woorden in gehele boek consistent gemaakt mbt het woord tool --- nl/02-git-basics/01-chapter2.markdown | 4 ++-- nl/06-git-tools/01-chapter6.markdown | 4 ++-- nl/07-customizing-git/01-chapter7.markdown | 8 ++++---- nl/08-git-and-other-scms/01-chapter8.markdown | 10 +++++----- nl/09-git-internals/01-chapter9.markdown | 4 ++-- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown index 571dc9150..4267aba69 100644 --- a/nl/02-git-basics/01-chapter2.markdown +++ b/nl/02-git-basics/01-chapter2.markdown @@ -459,9 +459,9 @@ Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt ## De commit geschiedenis bekijken ## -Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit-geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando. +Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit-geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. De meest basale en krachtige tool om dit te doen is het `git log` commando. -Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruikt. Om het project op te halen, voer dit uit +Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruik. Om het project op te halen, voer dit uit git clone git://github.com/schacon/simplegit-progit.git diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown index 4309c372c..ea741e603 100644 --- a/nl/06-git-tools/01-chapter6.markdown +++ b/nl/06-git-tools/01-chapter6.markdown @@ -585,7 +585,7 @@ Je moet wel oppassen met deze techniek, omdat het amenden de SHA-1 van de commit ### Meerdere commit berichten wijzigen ### -Om een commit te wijzigen die verder terug in je geschiedenis zit, moet je meer complexe tools gebruiken. Git heeft geen geschiedenis-wijzig tool, maar je kunt het rebase tool gebruiken om een serie commits op de HEAD te rebasen waarop ze origineel gebaseerd, in plaats van ze naar een andere te verhuizen. Met het interactieve rebase tool kun je dan na iedere commit die je wilt wijzigen stoppen en het bericht wijzigen, bestanden toevoegen, of doen wat je ook maar wilt. Je kunt rebase interactief uitvoeren door de `-i` optie aan `git rebase` toe te voegen. Je moet aangeven hoe ver terug je commits wilt herschrijven door het commando te vertellen op welke commit het moet rebasen. +Om een commit te wijzigen die verder terug in je geschiedenis zit, moet je meer complexe tools gebruiken. Git heeft geen geschiedenis-wijzig tool, maar je kunt de rebase tool gebruiken om een serie commits op de HEAD te rebasen waarop ze origineel gebaseerd, in plaats van ze naar een andere te verhuizen. Met de interactieve rebase tool kun je dan na iedere commit die je wilt wijzigen stoppen en het bericht wijzigen, bestanden toevoegen, of doen wat je ook maar wilt. Je kunt rebase interactief uitvoeren door de `-i` optie aan `git rebase` toe te voegen. Je moet aangeven hoe ver terug je commits wilt herschrijven door het commando te vertellen op welke commit het moet rebasen. Bijvoorbeeld, als je de laatste drie commit berichten wilt veranderen, of een van de commit berichten in die groep, dan geef je de ouder van de laatste commit die je wilt wijzigen mee als argument aan `git rebase -i`, wat `HEAD~2^` of `HEAD~3` is. Het kan makkelijker zijn om de `~3` te onthouden, omdat je de laatste drie commits probeert te wijzigen; maar houd in gedachten dat je eigenlijk vier commits terug aangeeft; de ouder van de laatste commit die je wilt veranderen: @@ -671,7 +671,7 @@ Als je dan opslaat en de editor sluit, zal Git je branch terugzetten naar de oud ### Een commit samenpersen (squashing) ### -Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht: +Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met de interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht: # # Commands: diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown index 53edfbce1..47f93a847 100644 --- a/nl/07-customizing-git/01-chapter7.markdown +++ b/nl/07-customizing-git/01-chapter7.markdown @@ -172,7 +172,7 @@ Zie de manpage van `git config` voor alle sub-instellingen die je kunt instellen ### Externe merge en diff tools ### -Alhoewel Git een interne implementatie van diff heeft, deze heb je tot nu toe gebruikt, kan je in plaats daarvan een extern tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijn grafisch tool is en omdat het gratis is. +Alhoewel Git een interne implementatie van diff heeft, deze heb je tot nu toe gebruikt, kan je in plaats daarvan een externe tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijne grafische tool is en omdat het gratis is. Als je dit wilt proberen, P4Merge werkt op alle grote platformen, dus je zou het moeten kunnen doen. Ik zal in de voorbeelden paden gebruiken die op Mac en Linux systemen werken; voor Windows moet je `/usr/local/bin` veranderen in een pad naar een uitvoerbaar bestand op jouw machine. @@ -228,15 +228,15 @@ in plaats van de uitvoer van diff op de commando regel, wordt een instantie van Insert 18333fig0701.png Figuur 7-1. P4Merge. -Als je twee branches probeert te mergen en je krijgt vervolgens merge conflicten, kan je het `git mergetool` commando uitvoeren. P4Merge wordt dan opgestart om je het conflict op te laten lossen met behulp van dat GUI tool. +Als je twee branches probeert te mergen en je krijgt vervolgens merge conflicten, kan je het `git mergetool` commando uitvoeren. P4Merge wordt dan opgestart om je het conflict op te laten lossen met behulp van de GUI tool. -Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen zodat ze bijvoorbeeld het KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen: +Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen zodat ze bijvoorbeeld de KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen: $ cat /usr/local/bin/extMerge #!/bin/sh /Applications/kdiff3.app/Contents/MacOS/kdiff3 $* -Nu zal Git het KDiff3 tool gebruiken voor het tonen van diff en het oplossen van merge conflicten. +Nu zal Git de KDiff3 tool gebruiken voor het tonen van diff en het oplossen van merge conflicten. Git is 'af fabriek' al ingesteld om een aantal andere mergeconflict-oplossings tools te gebruiken zonder dat je de cmd configuratie op hoeft te zetten. Je kunt je merge tool op kdiff3 instellen, opendiff, tkdiff, meld, xxdiff, emerge, vimdiff of gvimdiff. Als je niet geïnteresseerd bent in het gebruik van KDiff3 als diff, maar het liever alleen wilt gebruiken voor merge conflict oplossing, en het kdiff3 commando zit in je pad, dan kun je dit uitvoeren diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown index 8a17493e8..c21fd812c 100644 --- a/nl/08-git-and-other-scms/01-chapter8.markdown +++ b/nl/08-git-and-other-scms/01-chapter8.markdown @@ -36,7 +36,7 @@ Veel succes en plezier bij het vertalen... # Git en andere systemen # -Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, het bidirectionele Subversion uitwissel tool van Git. +Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, de bidirectionele Subversion uitwissel tool van Git. Op een gegeven moment zal je een bestaande project willen omzetten naar Git. Het tweede gedeelte van dit hoofdstuk beschrijft hoe je projecten naar Git kunt migreren: eerst uit Subversion, dan vanuit Perforce, en als laatste via een eigen import script voor een niet standaard import geval. @@ -44,7 +44,7 @@ Op een gegeven moment zal je een bestaande project willen omzetten naar Git. Het Op dit moment maakt het merendeel van open source ontwikkelprojecten en een groot aantal bedrijfsprojecten gebruik van Subversion om hun broncode te beheren. Het is het populairste open source VCS en bestaat al bijna tien jaar. Het lijkt ook in veel aspecten op CVS, wat daarvoor de grootste speler was in de code-beheer wereld. -Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Dit tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met de spreekwoordelijke griffel en leisteen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur dusdanig te veranderen dat Git volledig gesupport kan worden. De Subversion brug is het uitwisselings-medicijn naar de DCVS wereld. +Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Deze tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met de spreekwoordelijke griffel en leisteen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur dusdanig te veranderen dat Git volledig gesupport kan worden. De Subversion brug is het uitwisselings-medicijn naar de DCVS wereld. ### git svn ### @@ -123,7 +123,7 @@ Nu zou je een geldig Git repository moeten hebben, waar de branches en tags in g tags/release-2.0.2rc1 trunk -Het is belangrijk om op te merken dat dit tool je remote references een andere namespace heeft toebedeeld. Als je normaal een Git repository cloned, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]` - waarbij in de namespace de naam van de remote wordt gebruikt. Echter, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder gebruik te maken van namespaces. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien: +Het is belangrijk om op te merken dat deze tool je remote references een andere namespace heeft toebedeeld. Als je normaal een Git repository cloned, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]` - waarbij in de namespace de naam van de remote wordt gebruikt. Echter, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder gebruik te maken van namespaces. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien: $ git show-ref 1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master @@ -458,7 +458,7 @@ Het volgende systeem waar je naar gaat kijken om vanuit te importeren is Perforc $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/contrib/fast-import -In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en het `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P4PORT omgevingsvariabele laten wijzen naar het Perforce depot: +In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en de `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P4PORT omgevingsvariabele laten wijzen naar het Perforce depot: $ export P4PORT=public.perforce.com:1666 @@ -718,7 +718,7 @@ Hier heb je 't, een mooie, schone Git repository. Het is belangrijk om te op te $ ls file.rb lib -Je kunt nog veel meer doen met het `fast-import` tool: verschillende bestandsmodi verwerken, binaire gegevens, meerdere branches en mergen, tags, voortgangsindicatoren, enzovoorts. Een aantal voorbeelden voor complexe scenario's zijn voorhanden in de `contrib/fast-import` directory van de Git broncode, een van de betere is het `git-p4` script dat ik zojuist behandeld heb. +Je kunt nog veel meer doen met de `fast-import` tool: verschillende bestandsmodi verwerken, binaire gegevens, meerdere branches en mergen, tags, voortgangsindicatoren, enzovoorts. Een aantal voorbeelden voor complexe scenario's zijn voorhanden in de `contrib/fast-import` directory van de Git broncode, een van de betere is het `git-p4` script dat ik zojuist behandeld heb. ## Samenvatting ## diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown index ac6228145..24f23e8f6 100644 --- a/nl/09-git-internals/01-chapter9.markdown +++ b/nl/09-git-internals/01-chapter9.markdown @@ -896,7 +896,7 @@ Vervolgens, stel dat je verloren commit om een of andere reden niet in de reflog $ git branch –D recover-branch $ rm -Rf .git/logs/ -Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit nu herstellen? Één manier is om gebruik te maken van het `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object: +Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit nu herstellen? Één manier is om gebruik te maken van de `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object: $ git fsck --full dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4 @@ -1010,4 +1010,4 @@ De grootte van je ingepakte repository is omlaag gegaan naar 7 K, wat veel beter Je moet een redelijk goed begrip hebben van wat Git op de achtergrond doet en, tot een bepaalde hoogte, hoe het geimplementeerd is. Dit hoofdstuk heeft een aantal plumbing commando's besproken – commando's die op een lager niveau zitten en eenvoudige zijn dan de porcelain commando's waarover je in de rest van het boek gelezen hebt. Begrijpen hoe Git op een lager niveau werkt zou het makkelijker moeten maken om te begrijpen waarom het doet wat het doet en ook om je eigen applicaties te schrijven en hulp scripts om jouw specifieke workflow voor je te laten werken. -Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtig tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je deze nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en dat je je prettig voelt bij het gebruik van Git op meer geavanceerde manieren. +Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtige tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je deze nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en dat je je prettig voelt bij het gebruik van Git op meer geavanceerde manieren. From 32cd1e5e9883fcc7eddd480e561e2251edee17b4 Mon Sep 17 00:00:00 2001 From: 8loser <8loser@users.noreply.github.com> Date: Sun, 1 Feb 2015 01:14:26 +0800 Subject: [PATCH 272/291] Update 01-chapter2.markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "提供"->"提交" --- zh-tw/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown index 7ffc67937..52d741749 100644 --- a/zh-tw/02-git-basics/01-chapter2.markdown +++ b/zh-tw/02-git-basics/01-chapter2.markdown @@ -331,7 +331,7 @@ A `**/` pattern is available in Git since version 1.8.2. 現在讀者已建立第一個提交！ 讀者可從輸出的訊息看到此提交、放到哪個分支（`master`）、SHA-1查核碼（`463dc4f`）、有多少檔案被更動，以及統計此提交有多少列被新增及移除。 -記得提交記錄讀者放在暫存區的快照。 任何讀者未暫存的仍然保持在已被修改狀態；讀者可進行其它的提交，將它增加到歷史。 每一次讀者執行提供，都是記錄專案的快照，而且以後可用來比對或者復原。 +記得提交記錄讀者放在暫存區的快照。 任何讀者未暫存的仍然保持在已被修改狀態；讀者可進行其它的提交，將它增加到歷史。 每一次讀者執行提交，都是記錄專案的快照，而且以後可用來比對或者復原。 ### 跳過暫存區域 ### From 2eeff6aa43eddd143d0b496ed39c5b20041e52d2 Mon Sep 17 00:00:00 2001 From: Geno1024 <754097987@qq.com> Date: Mon, 16 Feb 2015 11:06:46 +0800 Subject: [PATCH 273/291] Translate a few sentences into zh-CN --- zh/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zh/02-git-basics/01-chapter2.markdown b/zh/02-git-basics/01-chapter2.markdown index 2a95c60f4..dc4affb53 100644 --- a/zh/02-git-basics/01-chapter2.markdown +++ b/zh/02-git-basics/01-chapter2.markdown @@ -183,10 +183,10 @@ Insert 18333fig0201.png build/ # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt doc/*.txt - # ignore all .txt files in the doc/ directory + # 忽略 doc/ 目录下所有扩展名为 txt 的文件 doc/**/*.txt -A `**/` pattern is available in Git since version 1.8.2. +`**\`通配符从 Git 版本 1.8.2 以上已经可以使用。 ### 查看已暂存和未暂存的更新 ### From 6aa4e9e609e7a936cb10f95a1be692cebc703c03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Ewald?= Date: Sat, 28 Feb 2015 00:10:25 +0100 Subject: [PATCH 274/291] Update 01-chapter3.markdown --- de/03-git-branching/01-chapter3.markdown | 134 +++++++++++------------ 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown index f37dca23d..fdcf42280 100644 --- a/de/03-git-branching/01-chapter3.markdown +++ b/de/03-git-branching/01-chapter3.markdown @@ -14,7 +14,7 @@ Manche Leute bezeichnen Gits Branching-Modell als dessen „Killer-Feature“, w -Um wirklich zu verstehen wie Git Branching durchführt, müssen wir einen Schritt zurück gehen und untersuchen wie Git die Daten speichert. Wie Du Dich vielleicht noch an Kapitel 1 erinnerst, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern als Serie von Schnappschüssen. +Um wirklich zu verstehen wie Git Branching durchführt, müssen wir einen Schritt zurück gehen und untersuchen, wie Git die Daten speichert. Wie Du Dich vielleicht noch an Kapitel 1 erinnerst, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern als Serie von Schnappschüssen. @@ -33,7 +33,7 @@ Wenn Du einen Commit mit dem Kommando `git commit` erstellst, erzeugt Git für j -Dein Git-Repository enthält nun fünf Objekte: einen Blob für den Inhalt jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert welcher Dateiname zu welchem Blob gehört, sowie einen Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. Prinzipiell sehen Deine Daten im Git Repository wie in Abbildung 3-1 aus. +Dein Git-Repository enthält nun fünf Objekte: einen Blob für den Inhalt jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert, welcher Dateiname zu welchem Blob gehört, sowie einen Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. Prinzipiell sehen Deine Daten im Git Repository wie in Abbildung 3-1 aus. @@ -130,7 +130,7 @@ Abbildung 3-8. HEAD zeigt nach einem Checkout auf einen anderen Branch. -Das Kommando hat zwei Dinge veranlasst. Zum einen bewegt es den HEAD-Zeiger zurück zum `master`-Branch, zum anderen setzt es alle Dateien im Arbeitsverzeichnis auf den Bearbeitungsstand des letzte Commits in diesem Zweig zurück. Das bedeutet aber auch, dass nun alle Änderungen am Projekt vollkommen unabhängig von älteren Projektversionen erfolgen. Kurz gesagt, werden alle Änderungen aus dem `testing`-Zweig vorübergehend rückgängig gemacht und Du hast die Möglichkeit einen vollkommen neuen Weg in der Entwicklung einzuschlagen. +Das Kommando hat zwei Dinge veranlasst. Zum einen bewegt es den HEAD-Zeiger zurück zum `master`-Branch, zum anderen setzt es alle Dateien im Arbeitsverzeichnis auf den Bearbeitungsstand des letzten Commits in diesem Zweig zurück. Das bedeutet aber auch, dass nun alle Änderungen am Projekt vollkommen unabhängig von älteren Projektversionen erfolgen. Kurz gesagt, werden alle Änderungen aus dem `testing`-Zweig vorübergehend rückgängig gemacht und Du hast die Möglichkeit, einen vollkommen neuen Weg in der Entwicklung einzuschlagen. @@ -141,7 +141,7 @@ Lass uns ein paar Änderungen machen und mit einem Commit festhalten: -Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Befehlen vollbracht. +Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst, es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Befehlen vollbracht. @@ -150,7 +150,7 @@ Abbildung 3-9. Die Historie läuft auseinander. -Branches können in Git spielend erstellt und entfernt werden, da sie nur kleine Dateien sind, die eine 40 Zeichen lange SHA-1 Prüfsumme der Commits enthalten, auf die sie verweisen. Einen neuen Zweig zu erstellen erzeugt ebenso viel Aufwand wie das Schreiben einer 41 Byte großen Datei (40 Zeichen und einen Zeilenumbruch). +Branches können in Git spielend erstellt und entfernt werden, da sie nur kleine Dateien sind, die eine 40 Zeichen lange SHA-1 Prüfsumme der Commits enthalten, auf die sie verweisen. Einen neuen Zweig zu erstellen, erzeugt ebenso viel Aufwand wie das Schreiben einer 41 Byte großen Datei (40 Zeichen und einen Zeilenumbruch). @@ -172,7 +172,7 @@ Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branc 1. Arbeite an einer Webseite. -2. Erstell einen Branch für irgendeine neue Geschichte, an der Du arbeitest. +2. Erstelle einen Branch für irgendeine neue Geschichte, an der Du arbeitest. 3. Arbeite in dem Branch. @@ -185,7 +185,7 @@ In diesem Augenblick kommt ein Anruf, dass ein kritisches Problem aufgetreten is 1. Schalte zurück zu Deinem „Produktiv“-Zweig. -2. Erstelle eine Branch für den Hotfix. +2. Erstelle einen Branch für den Hotfix. 3. Nach dem Testen führst Du den Hotfix-Branch mit dem „Produktiv“-Branch zusammen. 4. Schalte wieder auf Deine alte Arbeit zurück und werkel weiter. @@ -203,7 +203,7 @@ Abbildung 3-10. Eine kurze, einfache Commit-Historie -Du hast Dich dafür entschieden an dem Issue #53, des Issue-Trackers XY, zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren kannst Du das Kommando `git checkout` mit der Option `-b` verwenden: +Du hast Dich dafür entschieden, am Issue #53 des Issue-Trackers XY zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen, um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren, kannst Du das Kommando `git checkout` mit der Option `-b` verwenden: $ git checkout -b iss53 Switched to a new branch 'iss53' @@ -238,18 +238,18 @@ Abbildung 3-12. Der `iss53`-Branch hat mit Deiner Arbeit Schritt gehalten. -Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit der Internet-Seite gibt, das Du umgehend beheben sollst. Mit Git musst Du Deine Fehlerkorrektur nicht zusammen mit den `iss53`-Änderungen einbringen. Und Du musst keine Zeit damit verschwenden Deine bisherigen Änderungen rückgängig zu machen, bevor Du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles was Du tun musst, ist zu Deinem MASTER-Branch wechseln. +Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit der Internet-Seite gibt, das Du umgehend beheben sollst. Mit Git musst Du Deine Fehlerkorrektur nicht zusammen mit den `iss53`-Änderungen einbringen. Und Du musst keine Zeit damit verschwenden, Deine bisherigen Änderungen rückgängig zu machen, bevor Du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles was Du tun musst, ist zu Deinem MASTER-Branch wechseln. -Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst. +Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor, wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst. $ git checkout master Switched to branch 'master' -Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, als Du mit der Arbeit an Issue #53 begonnen hast und Du kannst Dich direkt auf Deinen Hotfix konzentrieren. Dies ist ein wichtiger Moment um sich vor Augen zu halten, dass Git Dein Arbeitsverzeichnis auf den Zustand des Commits, auf den dieser Branch zeigt, zurücksetzt. Es erstellt, entfernt und verändert Dateien automatisch, um sicherzustellen, dass Deine Arbeitskopie haargenau so aussieht wie der Zweig nach Deinem letzten Commit. +Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, als Du mit der Arbeit an Issue #53 begonnen hast und Du kannst Dich direkt auf Deinen Hotfix konzentrieren. Dies ist ein wichtiger Moment, um sich vor Augen zu halten, dass Git Dein Arbeitsverzeichnis auf den Zustand des Commits, auf den dieser Branch zeigt, zurücksetzt. Es erstellt, entfernt und verändert Dateien automatisch, um sicherzustellen, dass Deine Arbeitskopie haargenau so aussieht wie der Zweig nach Deinem letzten Commit. @@ -269,7 +269,7 @@ Abbildung 3-13. Der Hotfix-Branch basiert auf dem zurückliegenden Master-Branch -Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und führe ihn mit dem Master-Branch zusammen, um ihn in die Produktionsumgebung zu integrieren. Das machst Du mit dem `git merge`-Kommando: +Mach Deine Tests, stelle sicher, dass sich der Hotfix verhält wie erwartet und führe ihn mit dem Master-Branch zusammen, um ihn in die Produktionsumgebung zu integrieren. Das machst Du mit dem `git merge`-Kommando: $ git checkout master $ git merge hotfix @@ -280,7 +280,7 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü -Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit, durch Verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt. +Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit durch Verfolgen der Commitabfolge direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt. @@ -316,7 +316,7 @@ Abbildung 3-15. Dein `iss53`-Branch kann sich unabhängig weiterentwickeln. -An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nicht in Deinen `iss53`-Zweig eingeflossen sind. Falls nötig kannst Du den `master`-Branch allerdings mit dem Kommando `git merge master` mit Deinem Zweig kombinieren. Oder Du wartest, bis Du den `iss53`-Branch später in den Master-Zweig zurückführst. +An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nicht in Deinen `iss53`-Zweig eingeflossen sind. Falls nötig, kannst Du den `master`-Branch allerdings mit dem Kommando `git merge master` mit Deinem Zweig kombinieren. Oder Du wartest, bis Du den `iss53`-Branch später in den Master-Zweig zurückführst. @@ -324,7 +324,7 @@ An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nic -Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du diese mit der `master` Branch zusammenführen möchtest. Das passiert, indem Du ein `merge` in die `iss53` Branch machst, ähnlich dem `merge` mit der `hotfix` Branch von vorhin. Alles was Du machen musst, ist ein `checkout` der Branch, in die Du das `merge` machen willst und das Ausführen des Kommandos `git merge`: +Angenommen, Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du diese mit der `master` Branch zusammenführen möchtest. Das passiert, indem Du ein `merge` in die `iss53` Branch machst, ähnlich dem `merge` mit der `hotfix` Branch von vorhin. Alles was Du machen musst, ist ein `checkout` der Branch, in die Du das `merge` machen willst und das Ausführen des Kommandos `git merge`: $ git checkout master $ git merge iss53 @@ -335,7 +335,7 @@ Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du -Das sieht ein bisschen anders aus als das `hotfix merge` von vorhin. Hier läuft Deine Entwicklungshistorie auseinander. Ein `commit` auf Deine Arbeits-Branch ist kein direkter Nachfolger der Branch in die Du das `merge` gemacht hast, Git hat da einiges zu tun, es macht einen 3-Wege `merge`: es geht von den beiden `snapshots` der Branches und dem allgemeinen Nachfolger der beiden aus. Abbildung 3-16 zeigt die drei `snapshots`, die Git in diesem Fall für das `merge` verwendet. +Das sieht ein bisschen anders aus als das `hotfix merge` von vorhin. Hier läuft Deine Entwicklungshistorie auseinander. Ein `commit` auf Deine Arbeits-Branch ist kein direkter Nachfolger der Branch, in die Du das `merge` gemacht hast, Git hat da einiges zu tun, es macht einen 3-Wege `merge`: es geht von den beiden `snapshots` der Branches und dem allgemeinen Nachfolger der beiden aus. Abbildung 3-16 zeigt die drei `snapshots`, die Git in diesem Fall für das `merge` verwendet. @@ -403,7 +403,7 @@ Alles, was einen 'merge' Konflikt aufweist und nicht gelöst werden konnte, wird -Das heisst, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'checkout' aktiviert als Du das 'merge' gemacht hast) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst Du Dich entweder für einen der beiden Teile entscheiden oder Du ersetzt den Teil komplett: +Das heißt, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'checkout' aktiviert als Du das 'merge' gemacht hast) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst Du Dich entweder für einen der beiden Teile entscheiden oder Du ersetzt den Teil komplett: