Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».

За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.

Поговорим как раз об этом — о том, что формирует культуру работы с Git: начнём с конвенций именования коммитов и закончим практиками работы в пуллреквесте. В конце статьи я поделюсь полезными ссылками на интерактивные обучалки, шпаргалки и гайды.

Содержание:

• Организация веток

• Именование веток

• Именование коммитов

• Код‑ревью и пуллреквесты

• Чек‑лист: что узнать перед началом работы с пуллреквестами

• Оформление пуллреквеста

• Работа в пуллреквесте: проверяют вашу работу

• Работа в пуллреквесте: вы проверяете чужую работу

• Примеры работы в пуллреквесте

• Полезные материалы по Git

Организация веток

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

Преимущества ветвления: 

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

• Упрощение управления версиями. Ветвление позволяет легко отслеживать различные версии проекта и управлять ими. Например, можно иметь стабильную ветку для выпуска продукта и отдельные ветки для разработки новых функций. Обычно ветка master или main является версией production ready кода.

• Облегчение интеграции изменений. Когда работа в одной ветке завершена, можно сливать изменения обратно в главную ветку (master или main). Процесс слияния merge помогает постепенно интегрировать новый код и убедиться, что он совместим с основной версией проекта.

• Безопасность тестирования. Работая в отдельных ветках, можно свободно тестировать изменения без риска нарушить работоспособность основной версии. Если что-то пойдёт не так, всегда можно вернуться к последней стабильной версии, не откатывая все изменения в проекте.

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

• Личное развитие и организация. Работа в ветках помогает развивать хорошие привычки в управлении кодом и дисциплинирует процесс разработки, — важные навыки для любого программиста.

Бывает, вполне достаточно иметь основную ветку (master или main) и заводить отдельные под новый функционал. Однако, когда команда большая или их несколько, такой подход может быть неудобным и неэффективным. 

Например, в master могут прийти конфликтующие изменения от разных разработчиков. Или может быть непонятно, как организовать тестирование: если ещё более-менее очевидно, как протестировать одну фичу, то как протестировать связку нескольких, не вливая всё в master? Ведь master должен содержать в себе только production ready код.

В таком случае нужен более гибкий и масштабируемый подход.

Каждая команда выбирает способ организовывать ветки в соответствии со своими процессами и потребностями — вариантов много. Я расскажу про один из популярных подходов — Git Flow.

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

Основные элементы Git Flow:

• main (ранее master) — основная ветка с кодом, который в данный момент используется в продакшене. Все изменения, которые попадают в эту ветку, должны быть готовы к развёртыванию.

• develop — эта ветка служит основой для разработки нового функционала. Все новые фичи сначала разрабатываются в отдельных ветках, а затем сливаются с develop.

• feature — для каждой отдельной задачи создаётся отдельная ветка от develop. Это позволяет разработчикам работать над новым функционалом без нарушения стабильности основного кода. Как только задача готова и прошла ревью, ветка сливается обратно в develop.

• release — ветка создаётся, когда в develop накапливается достаточно новых фичей для следующего релиза. В ней команда может делать последние исправления, добавлять документацию и выполнять другие задачи, связанные с подготовкой к выпуску. После завершения работ ветка release сливается с main и develop, чтобы убедиться, что все последние изменения будут включены в будущие разработки.

• hotfix — такие ветки используются для срочного исправления ошибок в коде, который уже находится в продакшене. Ветка hotfix создается от main, а после исправления ошибки сливается обратно в main и develop.

Подход Git Flow — лишь один из множества возможных вариантов, как можно организовать систему взаимодействия веток и работы над версиями кода. Но что важно — система веток даёт нам возможность не только параллельно разрабатывать разный функционал или поддерживать старые версии, но и в целом на основе этого построить другие процессы: разных видов тестирования, деплоя.

Именование веток

Осознанный подход к такой утилитарной вещи, как имя ветки, делает работу более продуктивной и комфортной. Давайте разберёмся, какую пользу это приносит команде и проекту, а также какую именно метаинформацию добавить в название.

Преимущества грамотного именования веток:

• Чистота и удобство управления версиями в проекте. Например, специальные префиксы feature или hotfix могут указывать на масштаб изменений и влияние добавляемой функциональности на продукт, то есть характеризовать MINOR или PATCH изменения в концепции семантического версионирования (или семвер, как его ещё иногда называют сокращённо). Если хотите узнать про семвер больше, рекомендую статью на Хабре.

• Лёгкая навигация по проекту. По информативным и понятным названиям веток легче искать изменения и даже находить отсылки к конкретным задачам из таск-трекера (например, из Jira).

• Возможность настраивать автоматизацию на ветки, названные в соответствии с определёнными конвенциями: например, доставлять изменения на те или иные окружения, создавать docker-образы, прогонять линты и тесты, отправлять уведомления.

Общепринятые рекомендации по именованию:

• Используйте короткие, но описательные имена. Имя должно быть информативным, чтобы по нему можно было понять, над чем ведётся работа. Пусть оно будет достаточно коротким, чтобы его было легко запомнить и удобно вводить в поиске IDE или GitHub’а.

• Делите слова в имени ветки дефисами или нижним подчёркиванием, придерживайтесь единообразия. Это общепринятый подход, лучше не пользоваться пробелами или camelCase. Если вы используете дефисы для разделения слов в имени ветки, старайтесь всегда именовать ветки именно так, избегайте смешивания подходов.

  ✅ Удачные именования	❌ Неудачные
  feature-add-login-page	feature-add_login_page
  feature/add-login-page	feature_add_login-page
  feature/PROJ-123-add-login-page	FeatureAddLoginPage
  	feature-AddLoginPage
  	feature_proj-123_AddLoginPage
  В этом случае символ / допустим, потому что выделяет префикс, — это общепринятый подход.	Уже сложнее читать, труднее настраивать автоматизацию — слишком много разномастных символов и паттернов.

• Старайтесь не использовать спецсимволы: @, <, >, $. Из-за них иногда могут ломаться скрипты автоматизации.

• Используйте префиксы для разных типов веток. Префиксы помогают быстро идентифицировать тип ветки и характер изменений.
  
  Общепринятые префиксы: feature/ — новые функции (например, feature/new-login-form), bugfix/ или fix/ — исправление ошибок (например, fix/login-error), hotfix/ — срочные исправления прямо в рабочей ветке, release/ — подготовка релизов (например, release/1.0.1), refactor/ — структурные изменения кода, не влияющие на функциональность, docs/ — обновления документации.

• Включите в имя идентификатор задачи. Если ваш проект использует систему управления задачами (например, Jira), добавьте её идентификатор. Это облегчит отслеживание задач и связанных с ними изменений в коде. Пример: feature/PROJ-123-add-login-page

• Избегайте слишком общих имён. Например, fix или update слишком общие и не дают чёткого представления о содержании ветки. Постарайтесь быть более специфичными.

• Придерживайтесь единого подхода всей командой. Договоритесь с коллегами, ведь согласованность в именовании облегчает ориентацию в ветках и управление ими, особенно в больших проектах.

• Избегайте использования служебных слов Git в качестве префиксов. Слова типа head, master, tag могут вызвать путаницу, если пользоваться ими в именованиях.

Информативное имя ветки — это ещё одна возможность позаботиться о том, чтобы работать над проектом было проще и комфортнее. Для вас и ваших коллег это станет простым способом быстро получить информацию об изменениях (например, из номера задачи и/или описания) и настроить автоматизацию. 

Именование коммитов

Информативные сообщения к коммитам помогают вам и вашим коллегам ориентироваться в изменениях, облегчают навигацию по истории проекта и упрощают отладку и поиск ошибок. 

Например, вы можете быстро найти конкретный коммит, если нужно точечно достать изменения из одной ветки и перенести их в другую с помощью команды git cherry-pick. Также вы сможете автоматически формировать ченджлоги (changelogs) к проекту на основе сделанных описаний — например, с помощью пакета auto-changelog.

Правила грамотных комментариев к коммитам:

• Избегайте односложных сообщений: «ок», «work», «wip», «fix» — они совсем не информативны. Ни в процессе ревью, ни позже, если понадобится найти какое-то конкретное изменение, они совсем не помогут.

• Формулируйте сообщение конкретно. Оно должно давать чёткое представление о том, что было изменено и почему. Когда пишете сообщение, попробуйте задать себе эти вопросы и записать краткий ответ в одно предложение.

• Избегайте неоднозначности. В продолжение предыдущего пункта — лучше избегать нечётких формулировок: «исправление ошибок», «фикс багов» или «улучшения». Будьте конкретными в том, что было сделано.

• Старайтесь укладываться в 72 символа. Сообщение должно оставаться кратким, чтобы его можно было читать без прокрутки. Если нужно более подробное описание, после первой строки оставьте пустую строку, а затем добавьте подробности.

• Укажите номер из таск-трекера, если ваш коммит связан с определённой задачей или ошибкой, которые заведены в Jira или Trello.

• Используйте стандарт Conventional Commit (подробнее о нём — в доп. материалах в конце раздела). Он поможет писать ёмкие, но лаконичные сообщения. Конвенция предлагает в начало сообщения ставить специальный префикс — тип коммита, описывающий характер изменений.
  
  Примеры префиксов: feat — новая функциональность; fix — исправление бага; style — изменение форматирования, удаление комментариев, пропущенных точек с запятыми; refactor — рефакторинг, улучшение кода, не вносящее никакой новой функциональности и не являющееся фиксом.

  ✅ Удачные именования	❌ Неудачные
  Fix: Resolve race condition in user authentication	fixed stuff
  Refactor: Split order processing into separate functions	more changes
  Add: Implement search feature in main navigation	updated files
  Feat: Improve performance with lazy load implementation for images	сhanged style

Чаще всего сообщения к коммитам пишут на английском языке. Английский считается международным, это язык современной IT-индустрии. Достаточно часто разработчики работают в многонациональных командах или с зарубежными заказчиками. В таком случае ведение работы в репозитории полностью на английском делает возможным общение между всеми членами команды.

Часто даже в полностью русскоязычных командах используют английский для названия веток и сообщений к коммитам. Если вся коммуникация вокруг проекта строится на русском языке, вполне приемлемо писать сообщения на русском. Главное, придерживаться единого стиля в команде.

Дополнительные материалы:

• How to Write Better Git Commit Messages – A Step-By-Step Guide — отличная статья на FreeCodeCamp, раскрывающая множество аспектов.

• Conventional Commits — спецификация для добавления человеко- и машиночитаемого смысла в сообщения коммитов.

• Commit Message Guide — туториал на Google Developers.

Код-ревью и пуллреквесты

Пуллреквесты и ревью — это не только про код, это ещё и про коммуникацию, общение и взаимодействие внутри команды. А ещё про ценности: например, обмен знаниями, обучение, взаимопомощь, стремление сделать лучше. Если подойти к процессу осознанно, он принесёт команде и каждому участнику очень много пользы.

Код-ревью помогает:

• быть в курсе контекста по разным задачам в проекте;

• совместно принимать решения: от стайлгайдов и выбора библиотек до архитектуры;

• улучшать качество кода и вырабатывать оптимальные решения;

• оценить масштабируемость и поддерживаемость решения, учесть возможные риски и граничные случаи (corner cases) ещё на этапе разработки нового функционала;

• обратить внимание на необходимость переиспользования каких-то компонентов или утилит;

• быстрее знакомить новых сотрудников с проектом;

• обучаться и улучшать свои навыки — как хард-, так и софтскилы.

Если хотите узнать о теме немного больше, советую посмотреть небольшой доклад «Код-ревью с уважением» Ангелины Купцовой с митапа SPB Frontend и почитать статью «Что такое код-ревью» от Доки.

В следующих разделах я подробнее расскажу про пуллреквесты: о чём спросить команду до начала работы, как оформить пуллреквест и отработать комментарии, а также как быть хорошим ревьюером.

Чек-лист: что узнать перед началом работы с пуллреквестами

Работа с Git в конкретной команде и работа с пуллреквестом в частности всегда отражает устройство процессов. Поэтому, когда вы присоединяетесь к новой команде или к новому проекту, важно на старте собрать максимум информации.

До начала работы нужно узнать:

• В какую базовую ветку base branch делать пуллреквест — это не всегда main (master).

• Кого ставить в ревьюеры — иногда это почти вся команда, а иногда конкретный человек: тимлид или техлид.

• Сколько аппрувов получить, прежде чем замерджить ветку, — не всегда это ограничение автоматизировано в репозитории.

• Есть ли какие-то соглашения по именованию веток и коммитов. Нужно ли сквошить squash коммиты. Некоторые команды в конце работы над пуллреквестом обязательно объединяют все изменения в один коммит — так проще ориентироваться в истории.

• Что использовать — merge или rebase. Одни команды не накладывают ограничений, другие выбирают тот или иной способ. У каждого подхода есть плюсы и минусы, подробнее об этом рассказывают в статье на Хабре.

• Какая автоматизация настроена в ветке на разные события (новый коммит, мердж изменений). Самостоятельно посмотрите в репозитории (GitHub или другом) блок Checks или файлы автоматизации, если они есть. Например, это будет файл с названием .gitlab-ci.yaml, либо yaml файлы в директории .github — читайте подробнее по ссылкам.

  Уточните, какие проверки являются обязательными, если вам сложно ориентироваться в файлах или они хранятся не в рабочем репозитории. Часто в проектах автоматизация настроена так, что пуллреквест нельзя замерджить, если не прошли линтеры и тесты.

  

• Как и куда выкладываются изменения, когда ветка замерджена, на какое окружение. Когда вы пушите новый коммит или мерджите ветку, на некое окружение (например, dev или staging) выкладываются изменения, чтобы уйти на проверку QA-инженеру. Уточните, нужно ли нажимать Deploy вручную или выполнить какие-то команды. Иногда публикация изменений может быть автоматизирована.

Оформление пуллреквеста

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

Правила оформления пуллреквеста:

• Используйте краткие, но информативные названия. Обычно прописывается название ветки, но вы можете его отредактировать.

• Убедитесь, что делаете пуллреквест в верную базовую ветку, чтобы избежать ошибок и необходимости откатывать изменения.

• Напишите описание. Укажите название задачи, которую вы реализовывали, приложите ссылку на неё из таск-трекера, кратко опишите, что сделали. Также можете оставить комментарии или вопросы;

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

Работа в пуллреквесте: проверяют вашу работу

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

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

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

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

Иногда может случиться так, что вы неверно поняли комментарий, который вам оставил ревьюер, поэтому имплементировали изменение неверно. Или вы реализовали кусочек кода определённым образом, учитывая факты и нюансы, которые знаете только вы. А ревьюер, не обладая этой информацией, просит исправлений. 

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

Как сделать работу над изменениями эффективнее:

• Реагируйте на комментарии от ревьюера. Может показаться обременительным отвечать на каждый комментарий, особенно если их много, но в итоге это сэкономит всем время и силы.
  
  В ответ на комментарии, которые не вызывают у вас вопросов или возражений, можете просто написать краткое «Исправлено», “Fixed” или даже просто поставить какой-то смайл. Это поможет и вам не потеряться среди сообщений, и ревьюеру понимать, что вы увидели его сообщение и согласны с ним.
  
  Кроме того, это делает общение в пуллреквесте более человечным, больше располагает к обсуждению, чем просто множество никак не прокомментированных сообщений от ревьюера.

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

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

Работа в пуллреквесте: вы проверяете чужую работу

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

Звучит, вероятно, очень сложно и пугающе, особенно если этот процесс совсем в новинку. Однако начинать всегда с чего-то приходится — постараюсь помочь вам советами.

Общие принципы и рекомендации: 

• Не бойтесь задавать вопросы. Бывает так, что вас поставили в ревьюеры, вы смотрите в код… и не понимаете практически ничего. Конструкции сложные, контекст непонятен, неясно, что в принципе происходит и зачем. Часто в таком случае велик соблазн сделать вид, что вам всё ясно, и просто поставить аппрув, чтобы не «скомпрометировать свою экспертизу».
  
  В долгосрочной перспективе от такого подхода никто не выигрывает: ни вы, ваши знания, глубина понимания контекста проекта, вовлечённость в работу, ни ваша команда и продукт. Формальное, поверхностное ревью не решает свои задачи (о них мы говорили чуть выше).
  
  Поэтому, если вы оказались в такой ситуации, лучше постараться сформулировать вопросы и задать их в ПР. Или предложить автору пуллреквеста созвониться и пройтись по коду вместе. Чаще всего люди очень хорошо на это реагируют, особенно если вы присоединились к проекту не так давно.
  
  Возможно, своими вопросами в ПР вы поможете и другим лучше понять имплементированное решение. Несколько таких созвонов/встреч, и вы заметите, что уже намного лучше ориентируетесь в том, что видите.

• Убедитесь, что код работает и соответствует требованиям, описанным в задаче. Этот пункт некоторые могут посчитать спорным, ведь кажется, что проверка на соответствие требованиям не входит в задачи код-ревью.
  
  На мой взгляд, если код не решает задачу, ради которой он был написан, то вдумчивое ревью кода немного теряет свою ценность. Если функционал не работает, то для конечного продукта уже становится не так важно, насколько хорошо написан код.
  
  Поэтому важно, чтобы код и решал проблему, для решения которой создавался, и соответствовал хорошим практикам. Хорошая идея — начать ревью с того, что вы соберёте у себя ветку локально и проверите, что всё действительно работает, как задумано. Тем более что иногда у автора пуллреквеста может немного замылиться взгляд и он(а) просто не заметит, что что-то работает не так.
  
  Из моего опыта  намного лучше, если разные мелкие недочёты, связанные с логикой работы, отлавливаются ещё на этапе ревью, а не на этапе тестирования.

• Будьте дружелюбны. Пассивная или вполне себе неприкрытая агрессия (например, взять и поставить эмодзи ? вместо развёрнутого комментария), токсичные и ироничные комментарии, переходы на личности, высказывания в повелительном наклонении без каких-либо пояснений — всё это ведёт к тому, что ревью перестает решать свои задачи.

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

• Аргументированно доносите свои мысли. Не универсальная формула, но здорово, если комментарии строятся по принципу: высказывание или вопрос + пояснение, почему вы так считаете + (опционально) предложение своей идеи или ссылка на полезный источник, подтверждающий мысль. Это поможет построить действительно конструктивное обсуждение и не убить массу времени на выяснение деталей.

• Хвалите ? Почему-то работа в пуллреквесте почти у всех ассоциируется исключительно с критикой. А ведь закреплять хорошие привычки и договорённости можно и обратным способом — отмечая что-то, что сделано хорошо.

Это были ценности, на которые стоит ориентироваться, — всё же эта статья про культуру. Если вы хотите разобраться именно с механикой, я добавила несколько ссылок с более конкретными рекомендациями, на что обращать внимание в процессе ревью.

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

Дополнительные материалы:

• Review checklist

• Checklist for reviewing your own React code

• A complete guide to code reviews

• What to look for in a code review

Примеры работы в пуллреквесте

Многие проекты с открытым исходным кодом существуют и развиваются за счёт коммуникации в issues и пуллреквестах. Это помогает делиться контекстом, координировать работу, обучать и делиться информацией, решать проблемы и принимать решения совместно. 

Посмотрите, как это происходит в репозитории опенсорсного сервиса документации Дока, которое пишет комьюнити. Обратите внимание на то, как описаны и названы пуллреквесты и ветки, на разделение по коммитам и диалогу в пуллреквесте — участники обсуждают тему, обмениваются соображениями и мыслями, планируют совместную работу.

JS: Исправляет ошибки и форматирует (часть 8)

Добавляет статью про микротаски и макротаски

Другой пример:

Betaflight (опенсорсный софт контроллеров для дронов): Reduce RX task minimum update rate to 22Hz, to improve 25Hz link stability #13435

Полезные материалы по Git

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

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

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

• Что такое системы контроля версий — суперматериал на суперресурсе Дока;

• Git CLI — базовые команды с объяснениями, тоже на Доке;

• GitHowTo — шикарный интерактивный тур на русском;

• Git Branching — интерактивная, геймифицированная обучалка по основным командам и ветвлению в Git, посмотрите демотур, чтобы понять, как это выглядит;

• Как реализовать простой контроль версий с помощью JavaScript, чтобы лучше разобраться в Git — отличная статья с массой примеров и определением основных сущностей и алгоритмов;

• Git cheatsheet, Git intro — две шпаргалки по основным командам с кратким описанием

• First Aid Git — удобно организованная коллекция часто задаваемых вопросов;

• Чёрт побери, Git!?! — подборка частых факапов с их решениями, классный ресурс);

• Git — инструмент для совместной работы, с нуля и до регламента в команде — доклад Школы разработки интерфейсов Яндекса. Отличное объяснение того, что такое blob, commit, head, index, working tree, а также чем git merge отличается от git rebase.

• Modern Git Commands and Features You Should Be Using — да-да, в Git тоже добавляют новые фичи ?

• Внутри .git — обзор содержимого служебной директории Git-репозитория для лучшего понимания устройства Git.

• Основы работы с Git — бесплатный курс от Яндекс Практикума.