Използване на Git
Софтуер, източници и снимки
Отдавна исках да опитам някаква разпределена система за контрол на версиите, но очите ми се плъзгаха между Bazaar, Mercurial и Git. Въпреки това, веднъж на Хабре, другарят VlK написа отлична статия, която ме подтикна да опитам Git на първо място. Когато прочетох тази статия, възникнаха въпроси, чиито отговори бяха прости експерименти или четене на документацията. Ето защо реших да напиша тази статия, за да улесня другите потребители, които решат да използват Git. Освен това аз самият използвам Windows и това леко се отразява на използването на Git, за което също ще бъде писано.
И сега това е втората версия на статията, тъй като с пускането на Git 1.7 много се промени, включително към по-добро. :)
Разпределени системи за контрол на версиите
Класическите системи за контрол на версиите като CVS, SVN или, да не говорим, SourceSafe, са проектирани по такъв начин, че винаги има главно хранилище, което съдържа всички промени в кода, който е преминал през него. В класическите системи за контрол на версиите понятията хранилище и работно копие на източниците са строго разделени. Работното копие на разработчиците съдържа моментна снимка на текущото състояние на изходните кодове в хранилището.
За разлика от това, в разпределените системи за контрол на версиите всеки разработчик има свое собствено хранилище и папката на хранилището е папката източник (изглежда, че последното твърдение не е вярно за всички разпределени системи, но за Git е). Освен това, в общия случай може да няма едно основно хранилище и всички те могат да бъдат еквивалентни. Друг е въпросът, че в действителност вероятно има едно хранилище, което се счита за основно и където са източниците наокончателно сглобяване. Но от друга страна, разпределената система ви позволява да изграждате йерархии на хранилища, когато разработчикът изпраща промени в едно хранилище, което се счита за основно за него, а след това промените от няколко такива основни хранилища се изпращат до най-важното хранилище.
В допълнение, разпределените системи са удобни, ако разработчикът няма постоянен достъп до основното хранилище. В този случай алгоритъмът на неговата работа ще бъде както следва:
- Програмистът клонира оригиналното хранилище на своя компютър
Първоначално Git беше създаден от Линус Торвалдс (да, същият) с цел да създаде система за контрол на версиите, в която да бъде лесно да се създават клонове от основния клон на източника, както и да направи възможно най-лесния обмен на промени чрез познати (особено в Linux) пачове. В крайна сметка ще се съгласите, че е удобно да изпращате промените си по обикновена електронна поща, без да имате достъп за писане до хранилището.
Начало на работа
Ще приемем, че вече сте инсталирали Git. За да разберем как да работим с него, все още няма да използваме никакви графични черупки. Но за да демонстрирам състоянието на хранилището и клоновете, ще направя екранни снимки от програмата QGit, която показва всичко много ясно.
Нека започнем с Git с този пример. Нека създадем два файла в отделна папка (за мен ще се казва демо). Един от тях, наречен hello.py (скрипт на Python, но това няма значение в случая), ще има следното съдържание:
А вторият файл засега ще е празен и ще се казва description.txt, за да видите как Git работи с файлове, съдържащи български букви в името.
По този начин структурата на папките, която имаме в момента, е следната:
Сега да създадете хранилище задемо папка, влезте в нея и изпълнете следната команда от командния ред:
След това в конзолата ще се покаже съобщение, че е създадено празно хранилище.
Инициализирано празно Git хранилище в . /demo/.git/
Тук вместо ". " ще имате пълния път до вашата демо папка.
След тази команда ще бъде създадена подпапка .git в папката demo, която съхранява всички версии на промените. За разлика от CVS и SVN, тази папка ще бъде единична и няма да се появява във всяка подпапка.
Сега нашето дърво на папките изглежда така:
Нека засега игнорираме съдържанието на папката git.
Хранилището е създадено, но, както вече споменахме, то все още е празно, създадените от нас файлове не са добавени към него. За да видите в какво състояние е хранилището, изпълнете командата в същата демонстрационна папка
В резултат на това ще видим следния текст:
Тук Git ни казва, че в момента сме в началния клон на хранилището при първоначалния комит. Не знам как да преведа думата ангажиране (фиксация?), Така че контекстът да е ясен, така че нека използваме този жаргон в бъдеще.
Git също пише, че имаме два файла, които не са в хранилището, имената им са hello.py и някои \356\357\350\361\340\355\350\345.txt. Както може би се досещате, последното име е файлът description.txt. По подразбиране, за символи, които не са в първите 128 знака от ASCII символния набор, Git извежда техните кодове. Нека деактивираме тази функция.
Настройки на Git
Всички Git настройки се съхраняват в текстови файлове. Има няколко такива файла, форматът им е един и същ, разликата между тези файлове е в техния обхват.
Вторият файл се намира в папката на потребителския профил, например в Windows XP това е файлът C:\Documents and Settings\USERNAME\.gitconfig.
И третият конфигурационен файл се намира във всяко хранилище в папката .git и се нарича config.
Приоритетът на настройката е както следва. Първо се преглежда файлът с настройки в текущото хранилище, за настройки, които не са посочени там, се чете файлът в потребителския профил, а за останалите настройки се преглежда системната конфигурация в папката Git\etc\.
По този начин можем гъвкаво да конфигурираме работата с хранилища и в същото време можем да пренесем общите настройки за различни хранилища на по-високо ниво, за да не ги конфигурираме във всяко хранилище.
Всички настройки са разделени на секции, а форматът на конфигурационните файлове е както следва:
Сега обратно към нашето хранилище. Да изключим изобразяването на български букви като техни кодове. За да направите това, просто задайте параметъра quotepath от основния раздел на false.
Отворете конфигурационния файл в папката .git, която създадохме, и добавете следния ред към секцията [core].
Сега нашият файл с настройки изглежда така: