Git (1) Установка, Настройка и Инициализация

Вместо вступления

Прежде всего, нужно понять, что Git – не такая уж и страшная вещь, как может поначалу показаться. Да, вы можете заметить, что объем «небольшого» туториала вышел более чем внушительным, но, уверяю вас, это отнюдь не показатель сложности! Скорее возможностей, которые Git способен предоставить разработчику. Поэтому будьте мужественным и дочитайте статью до конца.


 

В данной статье я не стану говорить о работе, с какими бы там ни было сторонними оболочками (TortoiseGit, SourceTree) – только со стандартными интерфейсами. Освещения особых тонкостей Git тоже не ждите – здесь только самое необходимое. Задача этой статьи: дать читателю базовые представления о Git и работе с ним, рассказать об основных операциях, помочь освоиться, а далее читатель сам сможет выбрать тот интерфейс, который сочтет удобным, и углубить свои знания самостоятельно, если сочтет нужным.




Пожалуй, пора приступать к самой сути. А начну с того, что расскажу немного о…

Немного о Git

Как вы уже могли прочитать в Википедии (вы ведь любознательный юзер, не так ли?), Git – система управления версиями некоторого проекта. Что же скрывается под этой весьма туманной формулировкой? Попробую объяснить «на пальцах»:

Давайте представим, что вы играете в видео игру. Например, в RPG. Ваш персонаж развивается, получает экспу, совершенствуется. Вы косите недругов налево и направо несколькими кликами мышки.

Но кто не делает ошибок? Однажды вы заворачиваете за очередной угол очередного подземелья и (OMG) натыкаетесь на соперника, который слишком силен! И в момент, когда ваше поражение уже совсем очевидно вы просто – что делаете? Правильно! Загружаете свое последнее сохранение! Если у вас есть привычка сохраняться часто и к месту, то ваш игровой прогресс не слишком пострадает.

Теперь все снова хорошо: вы живы и здоровы, и больше не пойдете туда, где вас поджидает смерть. Или пойдете, в надежде все же одолеть врага? Впрочем, это уже не важно. А важно то, что каких бы ошибок вы не наделали, у вас всегда есть возможность все исправить, просто откатившись немного назад. Именно эту возможность, «просто откатиться» до прошлой версии, если что-то испортили, и предоставляет Git, с той лишь разницей, что речь идет не о видео игре, а об IT-проекте, и играть вы можете не один, а в компании, причем каждый из участников также сможет играть вашим персонажем и сохранять свой прогресс.

Каждое «сохранение» в Git не перезаписывает предыдущее, поэтому в любой момент вы можете вернуться к любой версии своего проекта, а не только к последней. Такие «сохранения» называются коммитами (commit) или фиксациями. Ряд идущих друг за другом коммитов образуют ветвь (branch). Для наглядности я набросал в графическом редакторе рисунок:

image001

Здесь мы видим четыре коммита, образующих ветвь master: первый коммит – состояние проекта на момент старта, второй и третий коммиты – промежуточные состояния, а четвертый коммит – текущее состояние проекта (его актуальная версия). Название master носит основная ветвь проекта. Если бы проект был деревом, а на самом деле так оно и есть, то ветвь master была бы стволом этого дерева.

Все дерево проекта хранится в специальном хранилище – репозитории (repository), который физически может располагаться на вашем жестком диске (локальный репозиторий) или на удаленном сервере (глобальный репозиторий). Правом доступа к локальному репозиторию обладает только один человек; с глобальным могут оперировать несколько персон.

От любой ветви могут быть ответвлены и другие ветви, которые также будут состоять из коммитов. Здесь у пытливого читателя должен возникнуть вопрос: «А зачем от основной ветви может понадобиться ответвлять другие?» Чтобы дать на этот вопрос исчерпывающий ответ, снова смоделируем ситуацию:

Некто Вася пишет калькулятор. Это очень сложный калькулятор, и одному Васе просто не справиться! Именно поэтому он приглашает к себе в команду Петю. Петя охотно соглашается, он полон идей и желания трудиться (всем бы так). Поэтому он просит Васю поскорее выделить ему конкретную задачу, на которую он бы мог направить свою энергию. У Васи уже готов некоторый базовый код, и он решается поручить Пете внедрение некоторой крутой фичи. Сам же Вася, там временем, планирует продолжать работу с основным кодом.

И вот тут-то и начинаются проблемы. Если Вася и Петя будут работать одновременно, то у них могут появиться коллизии, т.е. такие строки кода, в которые оба участника внесут разные изменения. И чьи изменения, в таком случае, считать приоритетными? Правильный ответ: изменения обоих программистов! Ведь каждый из них менял проект, чтобы реализовать свою конкретную подзадачу. Именно поэтому под каждую подзадачу, выделенную одному из участников, удобно отводить отдельную ветвь.




Учитывая это, Петя ответвляет от master ветвь feature и продолжает работать уже в ней. Одновременно с ним Вася продолжает совершенствовать свою часть кода, и они не мешают друг другу.

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

После того, как Вася замерджил ветви master и feature, ветвь feature замыкается, но продолжает существовать. Примерный процесс разработки этого выдуманного Васей и Петей проекта я запечатлел в виде схемы, которую вы можете видеть ниже:

image002

В более сложных проектах от ветви feature может быть ответвлена еще одна или несколько ветвей, а от них еще и еще… ровно столько, сколько понадобится. Если код, разрабатываемый в конкретной ветви, не оправдывает ожиданий, то ветвь может быть полностью удалена. Ветвление делает командную разработку более слаженной и удобной, что является еще одним преимуществом Git.

На этом можно считать теоретическую часть статьи законченной. Прежде, чем идти дальше, рекомендую перечитать ее еще раз, уделяя особое внимание основным понятиям: repository, commit, branch, merge. Как только почувствуете, что освоились, переходите к следующей части.

Установка

Для начала нужно скачать сам Git, представленный набором утилит. Скачать актуальную версию можно отсюда.

image003

Я буду описывать работу с Git под Windows, используя стандартный графический интерфейс, включенный в поставку. Также каждое свое действие я буду дублировать в виде консольной команды для Git Bash (терминал Git). Ввиду того, что данное руководство предназначается для новичков, все объяснения механизма работы системы будут проходить на примере работы в Git Gui, а замечания относительно консоли я буду заключать в рамки кода. Объяснения будут вестись параллельно, поэтому вне зависимости от того, какой интерфейс вы решите использовать, это руководство окажется вам полезным. Если вам интересно, базовый список консольных команд можно посмотреть тут.

Скачав последнюю версию Git для используемой вами системы, переходим к установке. Я не вижу смысла заострять внимание на этом пункте, т.к. никаких настроек при установке производить не нужно – мы все настроим уже после нее. Единственное – укажите путь установки, не содержащий кириллицу. Все остальное оставьте по умолчанию. Если у вас возникнут какие-нибудь проблемы, не стесняйтесь, спрашивайте.

После установки вы уже можете создать свой собственный локальный репозиторий, в котором будете работать только вы. Для тренировки давайте так и сделаем.

Откройте проводник и создайте где-нибудь папку, в которой будет располагаться ваше хранилище. Я на своем ПК расположил ее по такому адресу: D:\MyTestProject

Далее нужно открыть эту папку и инициализировать в нее Git. Делается это правым кликом мышки по пустой области папки и выбором из контекстного меню пункта «Git Init Here».

image004

После этого в нашей рабочей папке появится скрытая папка .git. Здесь я не стану описывать, что содержит эта папка, однако, если вам очень это интересно, вы можете почитать об этом в другой статье. Скажу лишь, что в ней содержатся некоторые файлы с параметрами данного хранилища.

Теперь ваш собственный репозиторий располагается в папке MyTestProject. Все файлы, которые будет содержать эта папка, могут быть проиндексированы и в дальнейшем закоммичены в хранилище.

image005

Примечание: Папка, в которую вы инициализируете Git, должна быть пуста на момент инициализации! Также убедитесь, что у вас в настройках проводника включен показ скрытых файлов.

Для закрепления полученных знаний настоятельно рекомендую создать еще один репозиторий-«песочницу» в который вы будете самостоятельно вносить изменения в следующих разделах туториала, опять же, для тренировки.

Настройка

Теперь, когда наш репозиторий инициализирован и готов к работе, давайте откроем графический интерфейс и посмотрим, что там есть интересного. Кликните ПКМ на пустой области папки и выберете пункт «Git Gui». Появится окно графического интерфейса Git.

image007

image006

Далее мы более подробно разберем, для чего нужна каждая из областей главного окна Git Gui, но для начала нужно настроить Git. Выберем пункт «Редактировать» в главном меню окна и кликнем на «Настройки…». В открывшемся меню нас интересуют только пункты «Имя пользователя» и «Адрес электронной почты».

image008

Обратите внимание, что настройки разделены на две практически идентичные колонки: одна – настройки только для данного репозитория, другая – для всех репозиториев сразу. Рекомендуется заполнить указанные поля в обеих колонках, затем кликаем «Сохранить». После выполнения данных пунктов окно Git Gui можно временно свернуть.

ПРОДОЛЖЕНИЕ

Автор

MatrixDeity

MatrixDeity

Хреновый модератор

Буду благодарен, если поделитесь:
SFML вопросы, прошу, задавайте на форуме.

Добавить комментарий