Максим Кузнецов: заметки с тегом git

[Инструкция] Как работать с Git

Максим Кузнецов — Tue, 15 Jul 2025 11:15:15 +0300

(Это инструкция, которую приходится копировать из проекта в проект, поэтому размещаю и в блоге.)

Gitflow

Идейно система работы с ветками берётся из Gitflow, но с упрощениями.

Общее

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

Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи/задачи:

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

Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop. Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).

Правила именования

Каждый коммит и пулл-реквест должны именоваться в следующем формате:

[Sentry] EDS-1004: <пояснение>

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

EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.
Плюс почти все таск-трекеры позволяют сконнектиться с Gitlab/Github/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.

Работа с ветками

Из ветки main (или аналогичных prod/master) создается ветка develop.
На каждую фичу создаётся новая ветка вида feature/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера, — краткое описание задачи на английском языке. Например: `feature/TASK-1777-change-forms-for-clients`.
Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.
Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.
Для релиза ветку develop мерджим в ветку main через MR в Gitlab/Githab/etc.
Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix/XXX-short-description.
Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.
После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.
Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.
Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать git pull, чтобы подтягивать все изменения c ветки develop. Это позволит подтягивать все изменения текущего спринта и разрешать конфликты как можно быстрее. Свою задачу можно протестировать на стейдже, залив её туда без мерджа.

Удаление старых локальных веток в Git-репозитории

Максим Кузнецов — Thu, 27 Feb 2025 22:57:05 +0300

На долгих проектах при следовании gitflow или похожих подходов с feature-ветками часто накапливаются локальные ветки, которые уже были смёрджены в develop.

Старые ненужные ветки можно удалить одной командой:

git branch --merged develop | grep -v "^\*\\|develop\\|main\\|master" | xargs -n 1 git branch -d

При этом текущие ветки, несмердженные в develop, останутся.

Как быстро изучить Git с нуля

Максим Кузнецов — Tue, 28 Apr 2020 16:22:21 +0300

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

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

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

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

А что, если документ содержит сто страниц и его будут править десять человек?

Git

Первая версия Git была создана Линусом Торвальдсом — автором операционной системы Linux. Собственно, с помощью Git она и разрабатывалась.

Первыми с проблемой параллельного редактирования файлов столкнулись программисты, они и разработали решение — Git. Он позволяет хранить файлы в общем хранилище, а также каждому участнику создавать их копию локально. Можно менять файлы, создавать свои версии, откатываться на предыдущие, а потом отправлять финальную версию в хранилище. Гит самостоятельно объединит версии разных людей, либо укажет на конфликт, если, например, оба человека изменили одну и ту же строку. По такому же принципу работает Google Docs и подобные сервисы.

Курсы

Для изучения Git достаточно изучить

[4h] Githowto — курс на русском, нужно пройти хотя бы первые 38 уроков, чтобы можно было использовать git в реальной жизни.
[15m] Шпаргалка по gitflow — способ организации веток, чтобы в них не запутаться на средних и больших проектах.

В Githowto сразу же рассказывают, как установить git. Иногда git уже включён в систему по умолчанию, поэтому можно и не устанавливать. Проверить его наличие можно командой в терминале:

$ git --version
git version 2.24.1 (Apple Git-126)

Если ничего не вывелось, значит git не установлен.

Вопросы для самопроверки после курса

Что такое unstaged, staged и commited состояния у файлов?
Что такое ветки, как создавать их, переключаться между ними и объединять?
Как нужно именовать ветки согласно gitflow (master, develop, feature, hotfix, release)?
В каких случаях git самостоятельно сливает файлы, а в каких создаёт конфликты?
Как выглядит конфликт и что нужно сделать, чтобы его разрешить?
Как откатить изменения закоммиченного файла?
Как откатить изменения закоммиченного и запушенного в удалённый реп файла?
Что такое git stash и как им пользоваться?
Что такое репозитории — локальные и удалённые? Как склонировать репозиторий? Как запушить в реп?
Для каких файлов GIT подходит, а с какими работает плохо: текстовые и бинарные файлы?
Как исключить файлы из-под контроля Git (.gitignore)?
Установите алиасы для частых комманд: git ci, git st, git hist, git br, git co.

Дополнительная практика [1h]

Для начала создайте папку проекта с двумя файлами в разметке Markdown. Если не работали с markdown, то считайте их обычными текстовыми файлами.

README.md

# Знакомство с GIT
Есть отличные курсы:
- http://gitimmersion.com/
- https://githowto.com/ru

А также статья в блоге https://maxkuznetsov.ru/.

CHANGELOG.md

- Изучен курс GitHowTo
- Ознакомился с Git flow подходом
- Прочитал статью https://maxkuznetsov.ru/all/git-intro и сделал задания

Задачи

Добавьте поддержку Git в этот проект. Сделайте первый коммит, включающий оба этих файла.
Создайте от мастера новую feature/md-updates-vasya.
В реальной жизни master используется только для продакшена, а для основной разработки — ветка develop. Новые правки лучше всегда делать в отдельной feature/* ветке, а потом сливать её в develop или master, если вы работаете без develop.
Зарегистрируйтесь в github.com и создайте пустой репозиторий.
Запушьте локальный репозиторий в созданный удалённый репозиторий.
Измените первые строки в обоих файлах. Сделайте коммит, включив в него только изменения из CHANGELOG.md.
Случай из жизни: мы сделали кучу изменений в файлах, а потом поняли, что надо бы сохранить последнюю рабочую версию, но без последних лишних измнений.
Откатите (soft) последний коммит и сделайте новый, но уже с изменениями из обоих файлов. Попробуйте также вариант без отката: «git commit —amend».
Запушьте ветку в удаленный репозиторий и создайте там Pull Request в master.
Создайте локально новую папку, куда склонируйте ваш удалённый репозиторий. У вас должно быть на компьютере две папки, смотрящие на один и тот же репозиторий. Этим мы имитируем ситуацию, когда два человека с разных компьютеров работают с одним репом. Назовём эти два локальных репозитория: первый — репозиторий Васи, второй — Пети.
В новом репо Пети создайте ветку feature/md-updates-petya из master.
Измените первые строки в обоих файлах (иначе, чем в feature/md-updates-vasya), закоммитьте, запушьте и создайте PullRequest на Github.
В интерфейсе Github примите первый Pull-Request из ветки Васи, а потом убедитесь, что получили конфликт в Пулл-реквесте от Пети.
Так часто бывает в жизни, когда над одним кодом работает больше одного человека. Чем больше команда, тем чаще конфликты.
Разрулите конфликт в локальном репозитории в ветке Пети и обновите Пулл-реквест.
Примите в github.com обновлённый Пулл-реквест от Пети.
В репозитории Васи переключитесь в master и сделайте git pull. Убедитесь, что ветка feature/md-updates-vasya удалена.
Оказалось, что вмёрдженная ветка от Пети содержала баги, поэтому нужно её откатить. Откатите её в репозитории Пети с помощью revert и c полной перезаписью публичной истории. Можно делать без Пулл-реквеста в этот раз.
Посмотрите, как изменилась история в репозитории Васи до git pull и после git pull.
В репозитории Васи добавьте в .gitignore файл CHANGELOG.md, чтобы Git перестал его отслеживать. (Подсказка: «git rm» с флагом «—cached».) Запушьте в удалённый реп.
Зайдите в Github и проверьте, что CHANGELOG.md больше нет в репозитории.

GUI клиенты

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

встроенные в IDE
Sourcetree — мой личный выбор
Git Kraken
Git Tortoise

Но ими проще пользоваться, когда ты понимаешь, что они делают под капотом.