Git за пол часа, быстрый старт, экспресс-курс

Введение

Git — это децентрализованная система контроля версий (СКВ).

В современном мире используется в любом IT-проекте размерами свыше очень малого. Зачем она нам нужна, ведь я сохраняю свои проект?! Ответ прост: «работаете Вы, работаете, например, пишите диплом. Написали где-то две трети. Вздохнули. Вы ведь молодец, и это за ночь до сдачи. Пошли за очередной порцией кофе. Подходите к столу, а Ваша любимая кошка решает пробежать у Вас под ногами. Кофе летит на ноутбук, экран гаснет, кошка летит в окно, весь дом поднимается на уши, услышав Ваш истошный крик. Диплома как будто и не было». И это лишь один из примеров. Подобное можно перечислять чуть ли не бесконечно, и такие истории будут взяты из реальной жизни реальных людей. Удалил случайно с флешки единственную копию, накрылся жёсткий диск, украли компьютер, перебои в электричестве и сгорание ПК…

Польза от системы контроля версий Git

Git Ваш компьютер не спасёт, но убережёт Вашу работу, наработки, и пару сотен нервов. Но это только если Вы пользуетесь системой контроля версий. По мимо безопасного хранения Ваших данных, Git предоставляет возможность работать нескольким людям над одним и тем же проектом без необходимости бегать друг к другу с флешками или дисками содержащими исходники программ. «Я делаю это, ты делаешь то. Делаем в двух ветках, потом сливаем в одну». Две задачи выполняются параллельно и друг другу не мешают. А потом, в самом конце, когда уже все ошибки поправлены и приведено к подобающему виду, достигнутые результаты объединяются (например) в одну директорию и эта самая директория является конечным результатом проекта. Данный пример утрирован, но показывает на элементарных вещах смысл надобности использования СКВ.

Ещё один из примеров: пишите Вы, пишите… и не замечаете как допускаете ошибку, которая «кладёт» всю систему. Не приятно, правда? Но! Вы пользовались системой контроля версий и помните, что семь сохранений назад начали работать над кодом, который «обрушил» систему. Что нужно сделать? Правильно! Вернуть состояние системы к тому моменту, когда она работала так, как от неё ожидали. Благодаря Git и коммитам, которые делали, откатываемся на семь коммитов назад и вуаля! Наша система работает так, как от неё ожидается и в коде нет кода, который сотворил всё то нехорошее.

Небольшая иллюстрация того, зачем нужен Git при работе в команде.

Пояснение иллюстрации:

1. изображение вверху слева показывает визуализацию веток (branches) на неком выделенном этапе проекта;
2. двое разработчиков (слева) работают где-то (один в Майями, другой в Воркуте) над JavaScript-кодом, третий разработчик (справа) работает (в Сингапуре) над стилями;
3. используя Git и некий хостинг кода (о них поговорим почти в конце статьи) им не нужно перекидывать файлы друг другу на почту или в Telegram;
4. первому достаточно сказать «запушил анимацию на клиенте, всё стабильно»;
5. другой с помощью пары элементарных команд (по сравнению с действительно сложными) скачает все наработки первого разработчика;

Установка программного обеспечения

1. Скачайте с официального сайта необходимый пакет. Можно выбрать для разных операционных систем здесь. Или скачать напрямую
   1. скачивайте только с официального сайта, сборки других умных людей могут являться не безопасными и только навредят Вашей системе;
   2. для Windows здесь (в данной статье будет рассмотрена именно Windows-версия, использоваться будет Windows 10, но сути дела это не меняет, только некоторые нюансы касающиеся безопасности, которые будут рассмотрены, и разница в графическом интерфейсе);
   3. для Linux инструкция здесь;
2. Запустите на установку как любую другую программу (далее будет проиллюстрирован процесс инсталляции с грамотной расстановкой флагов), если интересуют подробности инсталляции Git на компьютер с Windwos, то рекомендую к прочтению следующую статью;
3. *На Windows 10 при запуске инсталлятора операционная система потребует разрешение на установку, нужна права администратора;
4. 
5. 
6. 
7. 
8. 
9. 
10. 
11. 
12. 
13. 
14. 

У Вас откроется окно CMD (оно же командная строка). Если этот произошло, то всё хорошо, можете её закрыть. Если же не открылось окошко, то перейдите в меню «Пуск»

Откройте меню пуск

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

Настройка Git

Настройка Git состоит из ввода набора команд с необходимыми аргументами. На самом деле звучит просто на столько же, как и является. Страшно только в первый раз, дальше это становится обыденностью.

Для полной и грамотной настройки нам потребуется:

1. действующая почта (yandex, google, mail — не важно какая);
2. придумать логин на английском;

Откройте «Git Bash«, он должен находиться в меню «Пуск«. Откроется окно командной строки, оно будет немного другим, нежели чем привычная командная строка (это касается только дизайнерской составляющей). Ниже приведён скриншот, показывающий разницу.

Пояснение:

1. окно сверху — это Git Bash;
2. окно снизу — это окно CMD (командной строки);

Как можно заметить, разница в цвете. При работе с Git используется Git Bash, так как он хоть и похож своим функционалом на CMD (Вы можете осуществлять действия в Git Bash те же, что и в CMD), но всё же они разные. Git Bash подхватывает на лету настройки Git, тем самым позволяя не использовать пароли при каждой отправке на сервер. CMD настройки не подхватывает, но функционал Git доступен из CMD. Если интересно почитать о настройке более подробно, рекомендую к прочтению эту статью.

Приступим к настройке:

1. Откройте Git Bash, должно появиться окно;
2. Username для Git

   Shell

   git config --global user.name "myName"

   1	git config --global user.name "myName"

3. Email для Git

   Shell

   git config --global user.name "myEmail@yandex.ru"

   1	git config --global user.name "myEmail@yandex.ru"

4. Настройка Git

   Shell

   git config --global core.autocrlf true

   1	git config --global core.autocrlf true

5. Настройка окончания строк для Git

   Shell

   git config --global core.safecrlf warn

   1	git config --global core.safecrlf warn

6. Просмотр настроек Git

   Shell

   git config --list

   1	git config --list

В конфиге, который открыли последней командой, отобразится вся введённая информация. Убедитесь, что она соответствует действительности в тех пунктах, которые заполнили в пунктах со 2-го по 5-ый включительно.

На этом настройка Git завершена. Если Вы опытный программист, но не могли вспомнить пункты выше, то можете закончить чтение статьи и перейти к работе. Остальным же рекомендую продолжить увеличивать свои запасы знаний.

Хостинги кода

Git, всего лишь система, инструмент для реализации. Для того, чтобы обмениваться наработками, необходимо такое место, где-то на просторах сети Интернет, где будет доступ к данным для других. Так появились хостинги кода. Наиболее популярными на данный момент времени являются:

1. GitHub — используется, в основном, как хостинг для разработок в области открытого программного обеспечения (Open source проекты). Ссылка на GitHub здесь;
2. Bitbucket — используется для корпоративных нужд, приватных репозиториев, хорошее место для коммерческих разработок начиная от Landing page на заказ и заканчивая многомиллионными Enterprise-проектами. Ссылка на Bitbucket здесь;

Каким пользоваться лучше? И тем, и тем. GitHub прекрасно подойдёт для хранения портфолио или разработок, которыми хотите поделиться. Ниже будет рассмотрено как настроить безопасное соединение по SSH для GitHub и Bitbicket соответственно. Рекомендую зарегистрироваться на GitHub и начать им пользоваться, так как он наиболее дружелюбен в освоении для людей вообще не знакомых с хостингами кода. При регистрации на каждом из них рекомендую использовать одну и ту же почту, что использовалась при настройке Git, в будущем будет меньше проблем и жизнь станет счастливее.

Настройка SSH или безопасное соединение с  хостингом

Для взаимодействия с хостингом кода можно использовать HTTPS-соединение или же соединение по SSH, последнее является наиболее предпочтительным. Чтобы использовать HTTPS-соединение не нужны никакие дополнительные настройки, но в процессе использования будут возникать раздражающие моменты (требоваться ручная авторизация и подобное). С SSH обстоятельства обстоят иначе, требуются предварительные настройки, но зато позже будет на ряд головной боли меньше. Необходимо создать ключи доступа, которыми позже будут оперировать наш установленный и настроенный Git и конкретный хостинг кода. Рассмотрим создание и настройку SSH-соединения:

1. откройте Git Bash;
2. введите команду
   
   Настройка SSH-соединения для Git

   Shell

   ssh-keygen

   1	ssh-keygen

   
   и нажмите Enter
   1. будет задан ряд вопросов, на каждом вопросе нажимайте Enter, не вводите ничего, иначе при каждой отправке будете вводить пароль для доступа по SSH;
3. завершением создания ключей будет являться прямоугольник, отображённый в консоле, с «интересным» содержимым.
4. перейдите в скрытую директорию, где размещены эти самые ключи доступа необходимые для SSH-соединения используя команду
   
   Скрытая директория с ключами SSH

   Shell

   cd ~/.ssh/

   1	cd ~/.ssh/

   
   если не возникло никаких ошибок пути, то ключи были созданы корректно;
5. выполните следующую команду
   
   Просмотр содержимого директории

   Shell

   dir

   1

   dir

   
   на экране появятся имена файлов, находящихся в данной директории (id_rsa и id_rsa.pub);
6. файл id_rsa содержит Ваш секретный ключи, его нельзя ни в коем случае никому и никогда отправлять, как бы сильно его у Вас не просили — он только Ваш и ни чей больше;
7. файл id_rsa.pub содержит публичный ключ, которым и будем оперировать в дальнейшей настройке;
8. прочтите и скопируйте данные публичного ключа, для этого выполните команду
   
   Чтение публичного ключа

   Shell

   cat id_rsa.pub

   1	cat id_rsa.pub

   
   на экране отобразится «страшная» строка, начинающаяся с «ssh-rsa» и дальше много букв латинского алфавита, выделите её мышкой от начала (с ssh-rsa) до конца строки и скопируйте комбинацией клавиш CTRL+C;
9. на этом моменте работа с ключами на клиенте (то есть, на Вашем компьютере) завершена, дальше будем настраивать серверную сторону;

Настройка SSH-доступа для GitHub

1. откройте GitHub;
2. перейдите в раздел настроек своего профиля;
3. найдите в меню слева «SSH and GPG keys» и перейдите в данный пункт меню;
4. найдите кнопку «Add SSH key» и кликните на неё;
5. Вас перекинет на страницу добавления SSH-ключа (либо перейдите на неё сразу здесь);
6. поле «Title» заполните на своё усмотрение, позже это значение нужно будет только для навигации по ключам;
7. поле «Key» необходимо заполнить той самой «страшной» строкой (публичный ключ), которую Вы не забыли скопировать;
8. нажмите кнопку «Add SSH key» и ключ добавлен;
   1. если возникли ошибки — проверяйте, всё ли Вы скопировали, GitHub скажет в чём ошибка;

Настройка SSH-доступа для Bitbucket

1. откройте Bitbucket;
2. внизу кликните на Вашу аватарку, откроется небольшой список;
3. найдите в списке «Bitbucket settings» (или перейдите по этой ссылке);
4. найдите в меню слева, но не на краю экрана, пункт «SSH Keys» и перейдите в него;
5. найдите кнопку «Add key» и кликните на неё, откроется окошко;
6. поле «Label» заполните на своё усмотрение, в дальнейшем значение данного поля будет нужно только для навигации по ключам;
7. в поле «Key» разместите скопированный публичный ключ (та самая «страшная» строка);
8. нажмите кнопку «Add key» и ключ добавлен;
   1. если возникли ошибки — проверяйте, всё ли Вы скопировали, Bitbucket скажет в чём ошибка;

Первый коммит

Пуш или отправка на сервер

Зачем отправлять на сервер актуальные версии файлов? Да чтобы вся команда имела удалённый и свободный доступ к самым новым файлам и имела возможность максимально эффективно делать свою работу. Есть такие задачи, при которых эффективность одной головы команды зависит от другой, хоть и частично. Рассмотрим отправку на сервер внесённых изменений после того, как изменения были зафиксированы в коммите.

1. Для отправки зафиксированных изменений выполните команду:
   
   Отправка изменений на сервер

   Shell

   git push

   1

   git push

   1. Возможно, после клонирования пустого репозитория, git попросит явно указать в какую ветку мы хотим залить наши изменения;
   2. Дополним предыдущую команду и выполним её:
   3. Правка команды и отправка на сервер

      Shell

      git push origin master

      1	git push origin master

2. Если всё прошло успешно, то никаких ошибок мы не получим;
3. Возможно получение предупреждений из-за разности окончания строк (зависит от операционной системы). Но они никак не повлияют на коммит, благодаря грамотным настройкам;
4. Заходим на хостинг кода, куда заливали. Ищем репозиторий, куда залили только что свеженький файл, и любуемся его содержимым на сервере, куда можно зайти с любого устройства с подключённым интернетом из любого уголка планеты Земля;

Создание веток (branches) и как не мешать другим

В командной работе важен вклад каждой головы. Одна лениться и больше отпирается, чем делает — в проекте появляются уязвимые точки. Не обязательно пахать как стахановец, достаточно выполнять свои функции и задачи грамотно, достаточно и не по принципу Вовочки. Не знаешь — спроси у Team-Lead’а или у лица ответственного за назначенную задачу. У каждого своя область ответственности и поэтому важно помогать друг другу, а не мешать.

Зачем ветки, если есть master?

Если использовать одну корневую ветку (master) для вливания своих изменений всеми членами команды, то постоянно придётся обновлять данные каждому, ибо залить своё не приняв изменения другого нельзя. Получаем массовое неудобство и конфликты версий, о которых нам в «ласковой» форме сообщит Git. Поэтому были созданы ветки или branches. В миру, корневая ветка (она же ветка master) используется как эталонная для репозитория (или проекта, зависит от масштабов), поэтому в неё попадают данные только с позволения Team-Lead’а или же ответственного лица за данный участок проекта. Все, кто занимается добавлением своих данных или внесением изменений в существующие файлы, должны использовать ветки. Так как эталонной является ветка master, то дополнительные ответвления нужно проводить от ветки master.

Ветка (branch) — это ответвление проекта от некой ветки, которое позволяет вести изменение файлов параллельно с другими участниками команды и заливать на сервер без опаски испортить эталонную ветку.

Рассмотрим создание и работу с новой веткой:

1. «отщипнёмся» от корневой директории, для этого выполните команду
   
   Создание дополнительной ветки Git

   Shell

   git branch newBranch

   1	git branch newBranch

   
   создастся новая ветка, но Вы всё ещё находитесь в ветке master (смотрите на аргумент в скобках около указания пути), необходимо осуществить переход на новую ветку;
   1. важный момент: именем ветки может быть только одно слово;
2. переход на новую ветку осуществляется с помощью команды
   
   Переход на ветку

   Shell

   git checkout newBranch

   1	git checkout newBranch

   
   смотрите на аргумент в скобках около указания пути, там вместо master будет newBranch;
3. предположим, что мы делали-делали свою задачу и хотим впервые положить в дополнительную ветку newBranch, для этого нужно зафиксировать изменения, добавить коммит, но заливать изменения следует несколько другим способом
   
   Отправка изменений на сервер с доп ветки

   Shell

   git push -u origin newBranch

   1	git push -u origin newBranch

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

   Shell

   git push

   1

   git push

4. Смотрите в репозитории, там появилась Ваша ветка, теперь Ваши коммиты, отправленные на сервер, не будут мешать остальным;

Что дальше?

А дальше делаете свою задачу, обычно следуют правилу: одна ветка — одна задача. Названия веток соответственно совпадает с названием задачи, обычно с её идентификационным уникальным номером в списке задач.

1. делаете задачу;
2. коммитите атомарные изменения;
3. проверяете;
4. правите;
5. когда посчитаете, что задача выполнена полностью и удоволетворяет требованиям установленным в проекте — сообщаете ответственному лицу за данный участок проекта или Team-Lead’у;
6. происходит проверка ветки;
   1. если всё замечательно, то дополнительная ветка сливается с корневой веткой master;
   2. если задача выполнена не корректно или не правильно, то дорабатываем и правим;
      1. смотрим пункт пять;

Слияние дополнительных веток с корневой

Закончили задачу, решение было одобрено головами свыше. Настало время влить свои изменения в эталонную ветку master. Это делается либо ответственным лицом или Team-Lead’ом, либо самим разработчиком, зависит от правил на проекте.

Выполните следующие команды:

1. осуществим переход в корневую ветку
   
   Переход в корневую директорию

   Shell

   git checkout master

   1	git checkout master

2. произведём слияние дополнительной ветки и эталонной
   
   Слияние веток

   Shell

   git merge newBranch

   1	git merge newBranch

   1. на этом этапе могут произойти ошибки слияния, если кто-то правил Ваши файлы параллельно. Это так называемые ошибки слияния, необходимо вручную решить какие изменения принимаем, а какие отторгаем;
3. появится автоматический коммит слияния, необходимо залить на сервер изменения
   
   Отправка на сервер

   Shell

   git push

   1

   git push

Конец

На этом, экспресс-курс по системе контроля версия Git, завершён! Благодарю за внимание!