![\"\"](\"https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png\")
\n<\/div>\nОбщее<\/h2>\n
В нашем проекте ветка develop<\/b> — ветка, которая содержит стабильный результат, который можно зарелизить на прод.<\/p>\n
Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи\/задачи:<\/p>\n
- \n
- стабильного качества (по мнению разработчика (всегда) и менеджера (аппрув менеджера требуется, если этого требует конкретная задача);<\/li>\n
- из спринта, который в работе (то есть те задачи, которые должны быть в ближайшем релизе).<\/li>\n<\/ul>\n
Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop. Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).<\/p>\n
Правила именования<\/h2>\n
Каждый коммит и пулл-реквест должны именоваться в следующем формате:<\/p>\n
\n
[Sentry] EDS-1004: <пояснение><\/p>\n<\/blockquote>\n
В квадратных скобках можно указать часть системы, которая затрагивается — это упростит поиск коммита, если что-то сломается. Списка частей системы нет, выбирайте на свой вкус. Из общих советов — это должно быть что-то широкое, чтобы был понятен контекст, но не слишком широкое, чтобы не терялся смысл.<\/p>\n
EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.
\nПлюс почти все таск-трекеры позволяют сконнектиться с Gitlab\/Github\/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab\/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.<\/p>\nРабота с ветками<\/h2>\n
- \n
- Из ветки main (или аналогичных prod\/master) создается ветка develop.<\/li>\n
- На каждую фичу создаётся новая ветка вида feature\/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера,
— краткое описание задачи на английском языке. Например: `feature\/TASK-1777-change-forms-for-clients`.<\/li>\n - Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.<\/li>\n
- Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.<\/li>\n
- Для релиза ветку develop мерджим в ветку main через MR в Gitlab\/Githab\/etc.<\/li>\n
- Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix\/XXX-short-description.<\/li>\n
- Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.<\/li>\n
- После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.<\/li>\n
- Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.<\/li>\n
- Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать git pull, чтобы подтягивать все изменения c ветки develop. Это позволит подтягивать все изменения текущего спринта и разрешать конфликты как можно быстрее. Свою задачу можно протестировать на стейдже, залив её туда без мерджа.<\/li>\n<\/ol>\n", "date_published": "2025-07-15T11:15:15+03:00", "date_modified": "2025-07-15T11:15:05+03:00", "image": "https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png", "_date_published_rfc2822": "Tue, 15 Jul 2025 11:15:15 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "49", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png" ] } }, { "id": "47", "url": "https:\/\/maxkuznetsov.ru\/all\/udalenie-staryh-lokalnyh-vetok-v-git-repozitorii\/", "title": "Удаление старых локальных веток в Git-репозитории", "content_html": "
На долгих проектах при следовании gitflow или похожих подходов с feature-ветками часто накапливаются локальные ветки, которые уже были смёрджены в develop.<\/p>\n
Старые ненужные ветки можно удалить одной командой:<\/p>\n
git branch --merged develop | grep -v "^\\*\\\\|develop\\\\|main\\\\|master" | xargs -n 1 git branch -d<\/code><\/pre>При этом текущие ветки, несмердженные в develop, останутся.<\/p>\n", "date_published": "2025-02-27T22:57:05+03:00", "date_modified": "2025-02-27T22:57:00+03:00", "_date_published_rfc2822": "Thu, 27 Feb 2025 22:57:05 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "47", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css" ], "og_images": [] } }, { "id": "30", "url": "https:\/\/maxkuznetsov.ru\/all\/git-intro\/", "title": "Как быстро изучить Git с нуля", "content_html": "
\n![\"\"](\"https:\/\/maxkuznetsov.ru\/pictures\/git-intro.png\")
\n<\/div>\nGit — это система версионирования документов. Она позволяет пользователям создавать несколько параллельных версий, независимо управлять ими и сливать друг в друга с автоматическим нахождением конфликтных строк.<\/p>\n
Когда документ правит один человек, то никаких проблем не возникает, хотя иногда хочется видеть историю изменений с возможностью вернуться на предыдущую версию. А что, если над документом работают два человека?<\/p>\n
\n
— Вась, только что залил новую версию отчёта. Добавил одну страницу в третью главу.
\n— Ёпт, а я третью главу уже с нуля переписал...
\n— ...
\n— Ладно, давай подходи к моему компу со своим файлом, счас вместе глянем как это разрулить.<\/p>\n<\/blockquote>\nРаньше приходилось либо разбивать такой документ на несколько, чтобы можно было менять каждую часть независимо, либо договариваться, кто что правит, либо слать файл со своими правками, а потом ждать, когда человек пришлёт версию с его внесёнными правками.<\/p>\n
А что, если документ содержит сто страниц и его будут править десять человек?<\/p>\n
Git<\/h2>\n
Первая версия Git<\/b> была создана Линусом Торвальдсом — автором операционной системы Linux. Собственно, с помощью Git она и разрабатывалась.<\/p>\n
Первыми с проблемой параллельного редактирования файлов столкнулись программисты, они и разработали решение — Git. Он позволяет хранить файлы в общем хранилище, а также каждому участнику создавать их копию локально. Можно менять файлы, создавать свои версии, откатываться на предыдущие, а потом отправлять финальную версию в хранилище. Гит самостоятельно объединит версии разных людей, либо укажет на конфликт, если, например, оба человека изменили одну и ту же строку. По такому же принципу работает Google Docs и подобные сервисы.<\/p>\n
Курсы<\/h3>\n
Для изучения Git достаточно изучить<\/p>\n
- \n
- [4h] Githowto<\/a> — курс на русском, нужно пройти хотя бы первые 38 уроков, чтобы можно было использовать git в реальной жизни.<\/li>\n
- [15m] Шпаргалка по gitflow<\/a> — способ организации веток, чтобы в них не запутаться на средних и больших проектах.<\/li>\n<\/ul>\n
В Githowto сразу же рассказывают, как установить git. Иногда git уже включён в систему по умолчанию, поэтому можно и не устанавливать. Проверить его наличие можно командой в терминале:<\/p>\n
$ git --version\r\ngit version 2.24.1 (Apple Git-126)<\/code><\/pre>Если ничего не вывелось, значит git не установлен.<\/p>\n
Вопросы для самопроверки после курса<\/h3>\n
- \n
- Что такое unstaged, staged и commited состояния у файлов?<\/li>\n
- Что такое ветки, как создавать их, переключаться между ними и объединять?<\/li>\n
- Как нужно именовать ветки согласно gitflow (master, develop, feature, hotfix, release)?<\/li>\n
- В каких случаях git самостоятельно сливает файлы, а в каких создаёт конфликты?<\/li>\n
- Как выглядит конфликт и что нужно сделать, чтобы его разрешить?<\/li>\n
- Как откатить изменения закоммиченного файла?<\/li>\n
- Как откатить изменения закоммиченного и запушенного в удалённый реп файла?<\/li>\n
- Что такое git stash и как им пользоваться?<\/li>\n
- Что такое репозитории — локальные и удалённые? Как склонировать репозиторий? Как запушить в реп?<\/li>\n
- Для каких файлов GIT подходит, а с какими работает плохо: текстовые и бинарные файлы?<\/li>\n
- Как исключить файлы из-под контроля Git (.gitignore)?<\/li>\n
- Установите алиасы для частых комманд: git ci, git st, git hist, git br, git co.<\/li>\n<\/ul>\n
Дополнительная практика [1h]<\/h2>\n
Для начала создайте папку проекта с двумя файлами в разметке Markdown. Если не работали с markdown, то считайте их обычными текстовыми файлами.<\/p>\n
- \n
- README.md<\/li>\n<\/ul>\n
# Знакомство с GIT\r\nЕсть отличные курсы:\r\n- http:\/\/gitimmersion.com\/\r\n- https:\/\/githowto.com\/ru\r\n\r\nА также статья в блоге https:\/\/maxkuznetsov.ru\/.<\/code><\/pre>- \n
- CHANGELOG.md<\/li>\n<\/ul>\n
- Изучен курс GitHowTo\r\n- Ознакомился с Git flow подходом\r\n- Прочитал статью https:\/\/maxkuznetsov.ru\/all\/git-intro и сделал задания<\/code><\/pre>Задачи<\/h3>\n
- \n
- Добавьте поддержку Git в этот проект. Сделайте первый коммит, включающий оба этих файла.<\/li>\n
- Создайте от мастера новую feature\/md-updates-vasya.
\nВ реальной жизни master используется только для продакшена, а для основной разработки — ветка develop. Новые правки лучше всегда делать в отдельной feature\/* ветке, а потом сливать её в develop или master, если вы работаете без develop.<\/i><\/li>\n- Зарегистрируйтесь в github.com и создайте пустой репозиторий.<\/li>\n
- Запушьте локальный репозиторий в созданный удалённый репозиторий.<\/li>\n
- Измените первые строки в обоих файлах. Сделайте коммит, включив в него только изменения из CHANGELOG.md.
\nСлучай из жизни: мы сделали кучу изменений в файлах, а потом поняли, что надо бы сохранить последнюю рабочую версию, но без последних лишних измнений.<\/i><\/li>\n- Откатите (soft) последний коммит и сделайте новый, но уже с изменениями из обоих файлов. Попробуйте также вариант без отката: «git commit —amend».<\/li>\n
- Запушьте ветку в удаленный репозиторий и создайте там Pull Request в master.<\/li>\n
- Создайте локально новую папку, куда склонируйте ваш удалённый репозиторий. У вас должно быть на компьютере две папки, смотрящие на один и тот же репозиторий. Этим мы имитируем ситуацию, когда два человека с разных компьютеров работают с одним репом. Назовём эти два локальных репозитория: первый — репозиторий Васи, второй — Пети.<\/li>\n
- В новом репо Пети создайте ветку feature\/md-updates-petya из master.<\/li>\n
- Измените первые строки в обоих файлах (иначе, чем в feature\/md-updates-vasya), закоммитьте, запушьте и создайте PullRequest на Github.<\/li>\n
- В интерфейсе Github примите первый Pull-Request из ветки Васи, а потом убедитесь, что получили конфликт в Пулл-реквесте от Пети.
\nТак часто бывает в жизни, когда над одним кодом работает больше одного человека. Чем больше команда, тем чаще конфликты.<\/i><\/li>\n- Разрулите конфликт в локальном репозитории в ветке Пети и обновите Пулл-реквест.<\/li>\n
- Примите в github.com обновлённый Пулл-реквест от Пети.<\/li>\n
- В репозитории Васи переключитесь в master и сделайте git pull. Убедитесь, что ветка feature\/md-updates-vasya удалена.<\/li>\n
- Оказалось, что вмёрдженная ветка от Пети содержала баги, поэтому нужно её откатить. Откатите её в репозитории Пети с помощью revert и c полной перезаписью публичной истории. Можно делать без Пулл-реквеста в этот раз.<\/li>\n
- Посмотрите, как изменилась история в репозитории Васи до git pull и после git pull.<\/li>\n
- В репозитории Васи добавьте в .gitignore файл CHANGELOG.md, чтобы Git перестал его отслеживать. (Подсказка: «git rm» с флагом «—cached».) Запушьте в удалённый реп.<\/li>\n
- Зайдите в Github и проверьте, что CHANGELOG.md больше нет в репозитории.<\/li>\n<\/ol>\n
GUI клиенты<\/h2>\n
В реальной жизни работать с гитом через консоль приходится редко. Есть клиенты Git с визуальным интерфейсом, например:<\/p>\n
- \n
- встроенные в IDE<\/li>\n
- Sourcetree<\/a> — мой личный выбор<\/li>\n
- Git Kraken<\/a><\/li>\n
- Git Tortoise<\/a><\/li>\n<\/ul>\n
Но ими проще пользоваться, когда ты понимаешь, что они делают под капотом.<\/p>\n", "date_published": "2020-04-28T16:22:21+03:00", "date_modified": "2020-04-28T16:22:14+03:00", "image": "https:\/\/maxkuznetsov.ru\/pictures\/git-intro.png", "_date_published_rfc2822": "Tue, 28 Apr 2020 16:22:21 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "30", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css", "system\/library\/highlight\/highlight.js", "system\/library\/highlight\/highlight.css" ], "og_images": [ "https:\/\/maxkuznetsov.ru\/pictures\/git-intro.png" ] } } ], "_e2_version": 3559, "_e2_ua_string": "E2 (v3559; Aegea)" }
- Git Kraken<\/a><\/li>\n
- CHANGELOG.md<\/li>\n<\/ul>\n
- README.md<\/li>\n<\/ul>\n
- [15m] Шпаргалка по gitflow<\/a> — способ организации веток, чтобы в них не запутаться на средних и больших проектах.<\/li>\n<\/ul>\n