GIT: что за зверь и зачем он нужен разработчикам

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

Я знаком с многими компаниями, где с ним работают, и где не работают. И, конечно, разница во внутренних процессах очевидна! В одной команде будет контроль и слаженность, в другой — споры и выяснение, кто и что делал.

Я решил подготовить несколько статей на эту тему, чтобы максимально широко ее осветить. Данная статья будет вводной и обобщенной, чтобы познакомить вас с Git и показать, насколько это крутой и полезный инструмент.

Говоря правильными словами, Git — это распределенная система контроля версий. Разработчикам он дает возможность контролировать изменения в файлах, а также совместно слаженно работать над проектами.

Если обратиться к истории создания, Линус Торвальдс создал Git как раз для того, чтобы сотрудники-разработчики вносили изменения в его проект — Linux.

Неважно, какой у вас проект — Linux, Яндекс, сайт ООО “Рога и копыта” или парикмахерской “Светлана”. Git подойдет для любого объема проекта.

1. Вы видите и контролируете все изменения файлов на сайте (кто, что и когда делал)
2. В случае необходимости (или внезапно возникших проблем, требующих немедленного отката), вы можете вернуться к предыдущим версиям файла
3. Избирательность в файлах — не нужно давать разработчику полный доступ к сайту/проду, а это в свою очередь повышает “безопасность” продакшена, т.к. оригинальный полный доступ имеет только тим-лид
4. Разработчик работает локально на своем рабочем столе, а не на продакшене
5. Глобально всё это уменьшает процент появления различных ошибок на сайте, т.к. перед тем как выгрузить файл на сайт, его должен одобрить тим-лид (Буквально! После код-ревью и непосредственно перед выгрузкой тим-лид нажимает кнопку “Одобрить” и тогда файл уходит на сайт)
6. You name it!

Все это в сумме значительно упрощает работу всей команды разработчиков.

Когда ты фрилансер, конечно, Git — это что-то скорее для повышения своих скиллов или работа над собственной дисциплиной и такая разминка перед работой в большой веб-студии. (Лайфхак: напишите в резюме, что вы работали с Git и вас заберут с руками и ногами! Но не обещаю. Но знающие такой скилл оценят.)

Но действительно крупные и/или серьезные игроки среди веб-агентств понимают, насколько Git полезен. А если не понимают, то я с радостью расскажу.

Представим несколько различных ситуаций, которые точно происходили в любой веб-студии:

• Двум разным разработчикам нужно сделать две разные задачи в одном файле сайта (например, внести какие-то изменения в верстке и по бэк-энду). Не во всех же компаниях есть фулстеки.

В этой ситуации есть несколько выходов: поочередно вносить изменения на проде/поочередно вносить изменения локально на рабочих столах/делать через Git.

Какой мы можем получить результат от каждого варианта?

В первом случае, работа поочередная! Невозможно двум разработчикам одновременно работать над одним файлом. А что если изменения срочные и дедлайн был вчера? А что если один разработчик сильно затягивает процесс и долго работает? А что, если кто-то уронит сайт и безвозвратно утратит свои наработки?

Во втором случае, возможна одновременная работа. Но как объединить два разных кода? Как смержить изменения в один файл? И где гарантия, что ни один кусочек кода не потеряется?

Третий вариант — самый безопасный, самый оптимальный вариант. Во-первых, два разработчика могут работать над одним файлом, не терять время, разрабатывать разные функции и минимизировать конфликты при слиянии, ведь Git дает возможность работать каждому на своей ветке. Во-вторых, если кто-то что-то уронил, можно восстановить любую предыдущую версию сайта.

• Команда разработчиков работает над одним крупным проектом, где ежедневно нужно вносить правки. У каждого свои задачи, пусть опять в одном файле.
  Как распределить новые изменения между всеми разработчиками?
  Скинуть текстом в общий рабочий чат? Попросить тим-лида скопировать все кусочки кода и выгрузить их самостоятельно?
  Нет, запуллить мастер-ветку, т.е. запросить изменения в файле из главной/основной ветки в Git.

Расскажу о Git, как о системе.

Git — это система репозиториев и веток внутри них (другое название, бранч, но не в ресторане).

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

Если необходимо внести изменения, то создается ветка. После того, как разработчик внес изменения на локальном рабочем столе, он выгружает файл с изменениями в эту ветку. Таких ответвлений от одной ветки может быть множество, и работа может проходить параллельно, не затрагивая и не ломая основной сайт. Если разработчик совершил ошибку, и ему нужно вернуться на предыдущую версию файла, он также может это сделать, не затрагивая другие файлы. Когда все разработчики закончили работу и все изменения внесены и проверены тим-лидом, все ответвления объединяются (другое название, мержатся) в основную ветку (или мастер-ветку) и выгружается на сайт.

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

Далее, нужен сильный скилловый тим-лид. Именно тим-лид контролирует все процессы, происходящие на Git. Помимо того, актуальными могут быть знания GitHub Actions, GitLab. Так же тим-лид должен обучать разработчиков по работе с Git и актуализировать их знания.

Как только вы со всеми договорились и все согласны работать в новом формате, можно начинать техническое “открытие”. Для этого нужно:

1. Установить Git (инструкция по установке есть на официальном сайте);
2. Установить Docker/Open Server/MAMP/XAMPP;
3. Создать аккаунт на GitHub и раздать всем доступы от него;
4. Создать репозитории по всем актуальным проектам (советую добавить инструкцию по работе с репозиториями в файл README);
5. Настроить GitHub Actions, например, на выгрузку файлов на деплой на продакшен, чтобы с мастер-ветки перенести файлы на работающий сайт;
6. Создать SSH-ключ на локальном компьютере и добавить его в настройки сервера. Это позволит подключаться к серверу без пароля.

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