# Першыя крокі #

Гэтая глава прысвечана пачатку працы з Git. Мы пачнем з тлумачэння асноў працы прылад кантролю версій, затым пяройдзем да таго як атрымаць працуючы Git ў сваёй сістэме і, урэшце, як наладзіць яго так, каб з ім можна было пачаць працаваць. Напрыканцы гэтай главы вы будзеце мець разуменне для чаго наогул прызначаны Git, чаму ім варта карыстацца і мець усе неабходныя наладкі дзеля гэтага.

## Пра кантроль версій ##

Што такое кантроль версій і навошта ён патрэбны? Кантроль версій — гэта сістэма, якая запісвае змены, што адбыліся з файлам ці наборам файлаў з цягам часу, так што вы можаце вярнуцца да розных версій пазней. У прыкладах гэтай кнігі мы будзем працаваць з зыходнікамі праграмнага забеспечэння ў якасці файлаў, версіі якіх будуць кантралявацца, але, насамрэч, вы можаце выкарыстоўваць гэтую магчымасць практычна з любым тыпам файла, які існуе на вашым кампутары.

Калі вы графічны ці web дызайнер і маеце намер захоўваць кожную версію малюнкаў ці слаёў (што вам больш патрэбна), то выкарыстанне сістэмы кантролю версій (СКВ; Version Control System, VCS) гэта вельмі разумны выбар. Гэта дазволіць вам вярнуць файлы да папярэдняга стану, вярнуць увесь праект да папярэдняга стану, параўнаць змены паміж рознымі станамі, убачыць хто апошнім змяняў нешта, што можа выклікаць праблемы, хто прапанаваў змену і калі, і шмат іншага. Выкарыстанне СКВ у асноўным значыць, што калі вы сапсавалі нешта ці страцілі файлы, то гэта можна лёгка ўзнавіць. Як дадатак, гэта не запатрабуе вялікіх намаганняў і выдаткаў з вашага боку.  

### Лакальныя сістэмы кантролю версій ###

Шмат людзей ў якасці метаду кантролю версій выбірае капіяванне файлаў у іншую тэчку (магчыма, з датай у назве, калі чалавек досыць разумны). Гэты падыход вельмі распаўсюджаны з-за сваёй прастаты, але ён пакідае неверагодна шмат магчымасцяў для памылак. Вельмі лёгка забыцца ў якой тэчцы вы зараз і выпадкова запісаць не ў той файл, ці зкапіяваць зусім не туды, куды вы збіраліся.

Каб развязаць гэтую праблему праграмісты шмат часу таму распрацавлі лакальныя СКВ, якія выкарыстоўваюць простую базу дадзеных каб захоўваць ўсе змены ў файлах, версіі якіх адсочваюцца (гл. Малюнак 1-1).

Insert 18333fig0101.png 
Малюнак 1-1. Схема лакальнага кантролю версій.

Адной з папулярных у той час СКВ была rcs, якая ўсё яшчэ пастаўляецца з вялікай колькасцю кампутараў. Нават папулярная аперацыйная сістэма Mac OS X усталёўвае rcs у складзе пакета Developer Tools. Праца гэтай прылады заснаваная на захаванні на дыску ў спецыяльным фармаце набораў латак (patch) (гэта запісы розніцы паміж дзьвума файламі) для кожнай змены файла. Гэта дапамагае вярнуць файл да любога з зафіксаваных станаў, паслядоўна накладыючы латкі адну за адной.

### Цэнтралізаваныя сістэмы кантролю версій ###

Наступнай сур'ёзнай праблемай, з якой людзі сутыкнуліся была неабходнасць супрацоўнічаць з распрацоўшчыкамі за іншымі кампутарамі. Централізаваныя сістэмы кантролю версій (ЦСКВ) былі распрацаваныя каб развязаць гэтую праблему. Такія сістэмы як CVS, Subversion і Perforce складаюцца з сервера, на якім захоўваюцца ўсе дадзеныя па версіях файлаў, і некаторай колькасці кліенцкіх машын, якія атрымліваюць файлы з сервера. Шмат год такая схема з'яўлялася стандартам кантролю версій (гл. Малюнак 1-2).

Insert 18333fig0102.png 
Малюнак 1-2. Схема цэнтралізаванага кантролю версій.

Гэты падыход мае шмат пераваг, асабліва ў параўнанні з лакальнымі СКВ. Напрыклад, усе дакладна ведаюць што асатнія робяць і што наогул адбываецца ў праекце. Адміністратары маюць зручную магчымасць кантролю за тым хто што можа зрабіць. І гэта значна прасцей, чым адміністраванне лакальных баз дадзеных СКВ на кожнай кліенцкай машыне.

Аднак, гэты падыход мае і некаторыя сур'ёзныя мінусы. Самы відавочны з іх — центральны сервер яўляе сабою пункт, крах якога цягне за сабою крах усёй сістэмы. Калі гэты сервер спыніць працу на гадзіну — у гэтую гадзіну ніхто не зможа абмяняцца з супрацоўнікамі вынікамі сваёй працы ці захаваць новую версію таго, над чым ён ці яна зараз працуе. Калі жосткі дыск, на якім змешчаная цэнтральная база дадзеных пашкоджаны, а актуальных рэзервовых копій няма, то вы згубіце абсалютна ўсё: усю гісторыю праекту, за выключэннем тых здымкаў, што карыстальнікі выпадкова мелі на сваіх лакальных кампутарах. Лакальныя СКВ пакутуюць на тую ж праблему: калі ты маеш усю гісторыю праекта толькі ў адным месцы, то ты рызыкуеш згубіць усё.

### Размеркаваныя сістэмы кантролю версій ###

І вось тут у гульню ўступаюць размеркаваныя сістэмы кантролю версій (РСКВ). У РСКВ (такіх як Git, Mercurial, Bazaar ці Darcs) кліенты не толькі атрымліваюць апошнія здымкі файлаў: яны атрымліваюць поўную копію сховішча. Такім чынам, калі любы з сервераў праз які ідзе абмен вынікамі працы памрэ, то любое з кліенцкіх сховішчаў можа быць зкапіявана на сервер каб аднавіць усю інфармацыю. Кожнае сховішча на кожным з працоўных месцаў насамрэч поўная рэзервовая копія ўсіх дадзеных (гл. Малюнак 1-3).

Insert 18333fig0103.png 
Малюнак 1-3. Схема размеркаванага кантролю версій.

Апроч таго, шмат якія з гэтых сістэм выдатна працуюць з некалькімі аддаленымі сховішчамі, так што вы можаце адначасова па-рознаму узаемадзейнічаць з некалькімі рознымі групамі людзей у межах аднаго праекта. Гэта дазваляе наладжваць розные тыпы паслядоўнасцяў дзеянняў, што немагчыма з цэнтралізаванымі сістэмамі, такімі як іерархічныя мадэлі.

## Кароткая гісторыя Git ##

Як і шмат іншых вялікіх рэчаў у жыцці, Git пачынаўся з стваральнага разбурэння і палымяных спрэчак. Ядро Linux — праграмны праект з адкрытымі зыходнікамі даволі вялікага аб'ёму. На пряцягу большай часткі перыяду існавання ядра Linux змены ў ім распаўсюджваліся у выглядзе патчаў і архіваваных файлаў. У 2002 годзе праект распрацоўкі ядра Linux пачаў карыстацца BitKeeper — прапрыетарнай РСКВ

У 2005 годзе адносіны паміж суполкай распрацоўшчыкаў ядра Linux і камерцыйнай кампаніяй, што распрацоўвала BitKeeper сапсаваліся і бясплатна карыстацца гэтай утылітай стала немагчыма. Гэта запатрабавала ад суполкі распрацоўшчыкаў Linux (і, ў прыватнасці, Лінуса Торвальдса (Linus Torvalds), стваральніка Linux'а) стварыць іх уласную сістэму, заснаваную на некаторых з урокаў, якія яны вынеслі для сябе з досведу карыстання BitKeeper. Некаторыя з мэтаў новай сітэмы ніжэй:

*	Хуткасць
*	Просты дызайн
*	Моцная падтрымка нелінейнай распрацоўкі (сотні паралельных галін)
*	Цалкам размеркаваная
*	Магчымасць эфектыўна працаваць з вялікімі праектамі, кшталту ядра Linux (хуткасць і памер дадзеных)

З часу свайго з'яўлення ў 2005 годзе Git развіваўся і сталеў каб быць лёгкім у выкарыстанні і пры гэтым захоўваць гэтыя першапачатковыя якасці. Ён неверагодна хуткі, вельмі эфектыўны ў працы з вялікімі праектамі і мае неверагодную сістэму кіравання галінамі для нелінейных праектаў (гл. главу 3).

## Асновы Git ##

Такім чынам, што ж такое Git, калі ў двух словах? Гета вельмі важны для засваення раздзел, таму што калі вы зразумееце што такое Git і фундаментальныя асновы таго як ён працуе, то  эфектыўнае выкарыстанне Git можа стаць значна больш простым для вас. Пад час вывучэння Git пастарайцеся не абапірацца на ўспаміны пра іншыя СКВ, кшталту Subversion і Perforce, гэта дапаможа пазбегнуць памылак і разгубленасці пад час выкарыстання гэтай прылады. Git захоўвае інфармацыю і успрымае яе вельмі непадобна на іншыя сістэмы, нават не гледзячы на даволі блізкае падабенства карыстальніцкага інтэрфейсу. Разуменне гэтых адрозненняў дапаможа прадухіліць памылкі і разгубленасць пад час работы з Git.

### Здымкі, а не адрозненні ###

Асноўнае адрозненне Git ад любой іншай СКВ (уключаючы Subversion і кампанію) — тое як Git ўяўляе сабе дадзеныя, якіе захоўвае. Канцэптуальна, большасць іншых сістэм захоўвае інфармацыю ў выглядзе набор змяненнеў. Гэтыя сістэмы (CVS, Subversion, Perforce, Bazaar і гэтак далей) ставяцца да інфармацыі, якую яны захозваюць, як да набора адрозненняў для кожнага з файлаў у параўнанні з папярэднім станам, як гэта паказана на Малюнку 1-4.

Insert 18333fig0104.png 
Малюнак 1-4. Іншыя сістэмы звычайна захоўваюць дадзеныя ў выглядзе набора зменаў для базавай версіі кожнага файла.

Git ўспрымае данныя ў сховішчы інакш. Замест таго, каб успрымаць іх як наборы зменаў, Git ставіцца да дадзеных хутчэй як да набора здымкаў стану невялікай файлавай стэмы. Кожны раз, калі вы захоўваеце дадзеныя вашага праекду ў Git, ён па-сутнасці, робіць здымак таго, як вашыя файлы выглядаюць ў гэты момант і спасылку на гэты здымак. Для павышэння эфектыўнасці, калі файл не змяняўся, то Git не захоўвае яго яшчэ раз, а проста робіць спасылку на яго папярэдні стан, які ўжо быў захаваны. Гіт успрымае дадзеныя больш падобна на тое, што паказана на Малюнку 1-5.

Insert 18333fig0105.png 
Малюнак 1-5. Git захоўвае дадзеныя як здымкі стану праекта пэўнага часу.

Гэта вельмі сур'ёзна адрознівае Git ад практычна ўсіх іншых СКВ. Гэта вымушае Git пераглядзець амаль усе аспекты кіравання версіямі, якія большасць іншых сістэм узялі з сістэм папярэдняга пакалення. Гэта робіць Git больш падобным на невялікую файлавую сістэму з неверагодна магутнымі прыладамі, створанымі каб працаваць павер яе, чым на звычайную СКВ. Некаторыя з пераваг, які дае такі падыход да захоўвання дадзеных, мы разгледзім ў Раздзеле 3, пад час вывучэння працы з галінамі.

### Практычна ўсе аперацыі выконваюцца лакальна ###

Большасць аперацый у Git патрабуюць для працы толькі лакальныя файлы і рэсурсы, бо звычайна інфармацыя з іншых кампутараў у сетцы не патрэбныя. Калі вы карысталіся ЦСКВ, дзе большасць аперацый маюць дадатковыя затрымкі, звязаныя з працай праз сець, то гэты аспект Git прымусіць думаць, што богі хуткасці блаславілі гэтую сістэмы неверагоднымі здольнасцямі. Большасць аперацый выглядае практычна імгненнымі, паколькі ўся гісторыя праекта захоўваецца непасрэдна на вашым лакальным дыску.

Напрыклад, каб паглядзець гісторыю праекта Git не трэба звяртацца да сервера, каб атрымаць гісторыю і адлюстраваць яе для вас — можна проста прачытаць яе непасрэдна з вашай лакальнай базы дадзеных. Гэта значыць, што вы убачыце гісторыю праекта практычна імгненна. Калі вы захацелі ўбачыць розніцу паміж бягучай версіяй файла і той, што была месяц таму, Git можа праглядзець файл месячнай даўніны і вылічыць розніцу паміж версіямі лакальна, замест таго капрасіць у сервера зрабіць гэта, альбо выцягваць старую версію з сервера і потым зноўку ж вылічваць розніцу лакальна.

Да таго ж, гэта значыць што вельмі няшмат чаго нельга зрабіць калі вы па-за сеткай ці VPN. Калі вы ў самалёце ці ў цягніку і хочаце крыху папрацаваць, то вы можаце захоўваць праект ў СКВ (ці рабіць каміты, як яшчэ кажуць) без аніякіх праблем і перашкод ажно пакуль не з'явіцца сетка, з дапамогай якой вы зможаць выгрузіць змены. Калі вы прыйшлі дадому не і здолелі наладзіць VPN, вы ўсё яшчэ ў стане працаваць. У многіх іншых сістэмах вельмі цяжка, калі наогул магчыма рабіць так. У Perforce, напрыклад, вы няшмат што можаць зрабіць, калі няма сувязі з серверам, а ў Subversion і CVS вы можаце рэдактаваць файлы, але не будзеце ў стане захаваць змены ў сваю базу дадзеных (паколькі сувязі з базай дадзеных няма). Можа гэта і не выглядае вялікім дасягненнем, але вы будзеце здзіўленыя, убачыўшы наколькі гэта можа змяніць справу.

### Git падтрымлівае цэласнасць ###

Для ўсяго ў Git'е вылічваецца кантрольная сума перад тым, як захаваць і затым гэтая кантрольная сума выкарыстоўваецца як спалылка на аб'ект. Гэта значыць, што немагчыма змяніць змест якога-небудзь файла ці тэчкі, каб Git не даведаўся пра гэта. Гэты функцыянал убудаваны ў Git на самых нізкіх узроўнях і з'яўляецца неад'емнай часткай яго філасофіі. Вы не можаце згубіць інфармацыю пры перадачы ці атрыманні пашкоджаннага файла без таго, габ Git не змог выявіць гэтага.

Механізм, які выкарыстоўвае Git для вылічэнне кантрольнай сумы называецца SHA-1 хэш. Гэта страка з 40 знакаў, складаючаяся з шастнадцацірычных знакаў (0-9 і a-f) і вылічваецца па зместу файла ці тэчкі, знаходзячыхся ў Git'е. SHA-1 хэш выглядае прыкладна так:

	24b9da6552252987aa493b52f8696cd6d3b00373

Вы будзеце бачыць гэтыя хэшы паўсюль у Git'е тамушта ён выкарыстоўвае іх так шмат. Фактычна, Git захоўвае ўсё не па імені, у базе дадзеных адрасацыя адбываецца па значэнні хэша кантэнту. 

### Git як правіла, толькі дадае дадзеныя ###

Калі вы робіце дзеянні ў Git, амаль усе з іх толькі дадаюць дадзеныя ў базу дадзеных. Вельмі цяжка як-небуць прымусіць сістэму зрабіць нешта, што немагчыма адмяніць або прымусіць яе сцерці дадзеныя. Як і ў любой СКВ, вы можаце страціць або сапсаваць змены, якія вы яшчэ не зафіксавалі; але пасля таго як вы зафіксавалі здымак ў Git, вельмі цяжка страціць, асабліва калі вы рэгулярна змяшчаеце вашу базу дадзеных на іншы рэпазітар.

Гэта робіць працу з Git радасцю, таму што мы ведаем, што можам эксперыментаваць без небяспекі моцна сапсаваць становішча. Для больш глыбокага погляд на тое, як Git захоўвае свае дадзеныя і як вы можаце аднавіць дадзеныя, якія здаюцца страчанымі, глядзіце "Пад вокладкай" у главе 9.

### Тры станы ###

Цяпер, звярніце ўвагу. Гэта галоўнае, што вам трэба памятаць аб Git, калі вы хочаце, каб астатак вашага навучальнага працэсу прайшоў гладка. У Git ёсць тры асноўныя станы, у якіх вашы файлы могуць знаходзіцца: зафіксаваны, зменены, і падрыхтаваныя. Зафіксаваны значыць, што дадзеныя бяспечна захаваны ў вашу лакальную базу дадзеных. Зменены значыць, што вы змянілі файл, але яшчэ не зафіксавалі ў вашай базе дадзеных. Падрыхтаваны значыць, што вы адзначылі зменены файл для ўключэння ў наступны каміт. 

Такім чынам ёсць тры часткі у праекце з выкарыстаннем Git: каталог Git (the Git directory), працоўны катлог (the working directory), і вобласць падрыхтаваных файлаў (the staging area).

Insert 18333fig0106.png 
Малюнак 1-6. Працоўны каталог (the working directory), вобласць падрыхтаваных файлаў(the staging area), і каталог Git(the Git directory).

У каталозе Git захоўваюцца метаданныя і аб'екты базы дадзеных вашага праекту. Гэта найбольшая важная частка Git, і гэта менавіта тое, што капіруецца, калі вы кланіруеце рэпазітар з другога кампутара. 

Працоўны каталог - гэта копія пэўная версіі праекта. Гэтыя файлы вымаюцца з сціснутай базы дадзеных у каталогу Git і размяшчаюцца на дыску, каб вы карысталіся імі ці змянялі.

Вобласць падрыхтаваных файлаў - гэта проста файл, звычайна змешчаны у каталогу Git, які захоўвае інфармацыю аб тым, што будзе выкарастана ў наступным каміце. Яго часам называюць індэксам, але становіцца стандартам называць яго вобласцю падрыхтаваных файлаў.

Стандартня праца з Git выглядае прыкладна так:

1. Вы змяняеце файлы ў вашым працоўным каталогу.
2. Вы падрыхтоўваеце файлы, дабаўляючы іх здымак у вашу вобласць падрыхтаваных файлаў.
3. Вы робіце каміт(фіксуеце), у выніку чаго здымак з вобласці падрыхтаваных файлаў захоўваецца ў вашым каталогу Git.

Калі бягучая версія файла супадае с той, што ў каталогу Git, файл знаходзіцца ў зафіксаваным стане. Калі файл зменены, але толькі дададзены ў вобласць падрыхтаваных файлаў, такі файл знаходзіцца ў падрыхтаваным стане. І калі файл был зменены пасля выгрузкі с базы дадзеных, але не дадзены ў вобласць падрыхтаваных файлаў, ён знаходзіцца ў змененым стане. У главе 2 вы даведаецеся больш аб гэтых станах і як выкарыстаць іх перавагі ці прапусціць частку падрытоўкі ўвогуле.

## Усталёўка Git ##

Давайце пачнем выкарыстоўваць Git. Першае, што вам трэба зрабіць - гэта ўсталяваць яго.Вы можаце зрабіць гэта двумя спосабамі; ёсць два асноўных - усталяваць з зыходных файлаў ці ўсталяваць існуючы пакет для вашай платформы.

### Усталёўка з зыходных файлаў ###

Калі ў вас ёсць магчымасць, звычайна лепша ўсталяваць Git з зыходных файлаў, таму што вы атрымаеце найноўшую версію. Кожная версія Git звычайна ўключае карысныя паляпшэнні ітэрфейса карытсальніка, таму ўсталёўка з зыходных файлаў - найлепшы шлях, калі вы не маеце праблем з кампіляцыяй праграм з зыходных фалаў. Таксама многія дыстрыбутывы Linux змяшчаюць вельмі старыя пакеты; такім чынам толькі калі вы не выкарыстоўваеце вельмы свежы дыстрыбутыў ці вы на эксперэментальнай ветцы, усталёўка з зыходных файлаў - лепшы выбар.

Каб усталяваць Git, вам неабходна мець наступныя бібліятэкі, ад якіх Git залежыць: curl, zlib, openssl, expat, і libiconv. На прыклад, калі вы карыстаецеся сістэмай, якая змяшчае yum (як Fedora) ці apt-get (як сістэмы заснаваныя на Denian), вы можаце выкарыстаць адну з наступных каманд для ўсталёўкі ўсіх залежнасцей: 

	$ 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.6.0.5.tar.gz
	$ cd git-1.6.0.5
	$ make prefix=/usr/local all
	$ sudo make prefix=/usr/local install

Пасля гэтага вы можаце атрымаць пракет Git праз ваш усталяваны Git для атрымання абнаўленняў:

	$ git clone git://git.kernel.org/pub/scm/git/git.git
	
### Усталёўка на Linux ###

Калі вы жадаеце ўсталяваць Git на Linux праз бінарны ўстаноўшчык, вы можаце зрабіць гэта з дапамогай звычайнага менеджэра пакетаў вашага дыстрыбутыву. Калі ў вас Fedora, вы можаце скарыстацца yum:

	$ yum install git-core

Ці калі ў вас дыстрыбутыў на базе Debian, напрыклад Ubuntu, паспрабуйце apt-get:

	$ apt-get install git

### Усталёўка на Mac ###

Ёсць два лёгкіх пуці ўсталёкі Git на Mac. Самы лёгкі - выкарыстаць графічны ўсталёўшчык, які вы можаце спампаваць са старонкі SourceForge(гл. Малюнак 1-7):

	http://sourceforge.net/projects/git-osx-installer/

Insert 18333fig0107.png 
Малюнак 1-7. Усталёўчшык Git на OS X.

Іншы распаўсюджаны спосаб - гэта ўсталёука праз MacPorts (`http://www.macports.org`). Калі ў вас ёсць MacPorts, усталюйце Git гэтак:

	$ sudo port install git-core +svn +doc +bash_completion +gitweb

Вам не трэба ўсталёўваць усе дадткі, але верагодна вы захочаце уключыць +svn у выпадку, калі вам калі-небудзь прыйдзеца карыстацца Git на Subversion рэпазітарах (глядзі Главу 8).

### Усталёўка ў Windows ###

Усталёўка Git на Windows вельмі лёгкая. Працэдура ўсталёўкі праекта msysGit адна з найбольш лёгкіх. Проста спампуйце exe-файл інсталятара са старонкі GitHub, і выканайце яго:

	http://msysgit.github.com/

Пасля яго ўсталёўкі вы маеце як кансольную версію (уключаюцы SSH кліент, які спатрэбіцца ў далейшым), так і стандартную графічную.

## Першапачатковыя налады Git ##

Цяпер, калі ў вашай сістэме ёсць Git, вы захочаце зрабіць некалькі рэчаў для наладкі вашага Git. Вы павінны зрабіць гэта толькі адзін раз - пры абнаўленні налады застаюцца. Вы можаце змяніць іх у любы час, выканаўшы каманды яшчэ раз.

Git пастаўляецца з утылітай, якая называецца git config, якая дае магчымасць вам праглядаць і ўсталёўваць параметры наладкі, якія кантралююць усе аспекты працы і знешняга выгляду Git. Гэтыя параметры могуць змяшчацца ў трох месцах:

*	файл `/etc/gitconfig` : Змяшчае значэнні для ўсіх карыстальнікаў вашай сістэмы і ўсіх іх рэпазітараў. Калі вы перадаеце параметр ` --system` утыліце `git config`, яна чытае і запісвае параметры ў гэта файл. 
*	файл `~/.gitconfig` : Выкарыстоўваецца для вашага ўліковага запісу. Вы можаце запісваць і чытаць з гэтага файла пры ўказанні параметра `--global`. 
*	канфігурацыйны файл у каталогу Git (гэта `.git/config`) у тым рэпазітары, які вы выкарыстоўваеце ў данны момант: вызначае параметры для канкрэтнага гэтага рэпазітару. Кожны ўзровень змяняе значэнні папярэдняга ўзроўню, такім чынам значэнні ў `.git/config` перакрываюць адпаведныя ў `/etc/gitconfig`.

У Windows Git шукае файл `.gitconfig` у каталогу`$HOME` directory (`C:\Documents and Settings\$USER` для большасці карастыльнікаў). Таксама ён шукае /etc/gitconfig, але ўжо адносна карнявога каталогу MSys, які знаходзіцца там, дзе вы вырашылі ўсталяваць Git.

### Ваша ідэнтыфікацыя ###

Першае, што вам трэба зрабіць, калі вы ўсталявалі Git, - задаць ваша імя і адрас e-mail. Гэта важна таму, што кожны каміт у Git выкарыстоўвае гэтую інфармацыю, і яна ўключаецца ў каміты, перадаваемыя вамі, і далей ня можа быць зменена:

	$ git config --global user.name "John Doe"
	$ git config --global user.email johndoe@example.com

Зноў-такі, вам трэба зрабіць гэта толькі адзін раз, калі перадалі параметр `--global`, таму шта Git будзе заўжды выкарыстоўваць гэту інфармацыю для ўсяго, што вы будзеце рабіць на гэтай сістэме. Калі вы хочаце змяніць гэта на іншае імя ці адрас e-mail для канкрэтнага праекта, вы можаце выканаць каманду без параметра `--global`, калі вы знаходзіцеся ў каталогу праекта.

### Ваш рэдактар ###

Цяпер, калі вы наладзілі данныя ідэнтыфікацыі, вы можаце наладзіць тэкставы рэдактар, які будзе выкарыстоўвацца, калі Git'у трэба, каб вы ўвялі паведамленне. Па змаўчанні 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, якія даступны на данным узроўні:

	$ git config --list
	user.name=Scott Chacon
	user.email=schacon@gmail.com
	color.status=auto
	color.branch=auto
	color.interactive=auto
	color.diff=auto
	...

Вы можаце бачыць параметры больш аднаго разу, бо Git счытвае аднолькавыя параметры з розных файлаў (`/etc/gitconfig` і `~/.gitconfig` для прыкладу). У такім выпадку Git выкарыстоўвае апошняе значэнне для кожнага знайдзеннага параметра.

Таксама вы можаце праверыць што для Git з'яўляецца значэннем для канкрэтнага параметра, выканаўшы `git config {параметр}`:

	$ git config user.name
	Scott Chacon

## Атрыманне даведкі ##

Калі вам патрэбна даведка пры выкарыстанні Git, ёсць тры спосабы для атрымання старонкі кіраўніцтва для любой каманды Git:

	$ git help <дзеяслоў>
	$ git <дзеяслоў> --help
	$ man git-<дзеяслоў>

Напрыклад вы можаце атрымать даведку па камандзе config, выканаўшы

	$ git help config

Гэты каманды выдатны тым, што вы можаце выкарыстаць іх усюды, нават калі вы не падключаны да сеткі.
Калі старонкі кіраўніцтва і гэтай кнігі не дастаткова і вы маеце патрэбу ў асабістай дапамозе, вы можаце паспрабаваць канал `#git` ці `#github` IRC серверы Freenode (irc.freenode.net). Гэтыя каналы амаль заўсёды напоўнены сотнямі людзей, якія добра ведаюць Git і звычайна гатовы дапамагчыare often willing to help.

## Вынікі ##

Цяпер у вас павінна быць агульнае разуменне што такое Git і чым ён адрозніваецца ад СКВ, якія вы магчыма выкарыстоўвалі. Таксама вы павінны мець працуючую версію Git у вашай сістэме з вашымі наладамі ідэнтыфікацыі. Прыйшоў час вывучаць некаторыя асновы Git.