{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "Максим Кузнецов: заметки с тегом gitflow",
    "_rss_description": "Простыми словами о веб-разработке",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/maxkuznetsov.ru\/tags\/gitflow\/",
    "feed_url": "https:\/\/maxkuznetsov.ru\/tags\/gitflow\/json\/",
    "icon": "https:\/\/maxkuznetsov.ru\/user\/userpic@2x.jpg?1586398004",
    "author": {
        "name": "Максим Кузнецов",
        "url": "https:\/\/maxkuznetsov.ru\/",
        "avatar": "https:\/\/maxkuznetsov.ru\/user\/userpic@2x.jpg?1586398004"
    },
    "items": [
        {
            "id": "49",
            "url": "https:\/\/maxkuznetsov.ru\/all\/instrukciya-kak-rabotat-s-git\/",
            "title": "[Инструкция] Как работать с Git",
            "content_html": "<p>(Это инструкция, которую приходится копировать из проекта в проект, поэтому размещаю и в блоге.)<\/p>\n<h2>Gitflow<\/h2>\n<p>Идейно система работы с ветками берётся из Gitflow, но с упрощениями.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/maxkuznetsov.ru\/pictures\/gitflow.png\" width=\"1043\" height=\"371\" alt=\"\" \/>\n<\/div>\n<h2>Общее<\/h2>\n<p>В нашем проекте ветка <b>develop<\/b> — ветка, которая содержит стабильный результат, который можно зарелизить на прод.<\/p>\n<p>Следуя этому принципу, в рамках работы по спринту в ветку develop вливаются фичи\/задачи:<\/p>\n<ul>\n<li>стабильного качества (по мнению разработчика (всегда) и менеджера (аппрув менеджера требуется, если этого требует конкретная задача);<\/li>\n<li>из спринта, который в работе (то есть те задачи, которые должны быть в ближайшем релизе).<\/li>\n<\/ul>\n<p>Если ведется работа по фиче, которая не войдет в ближайший релиз, она не вливается в develop.  Тестирование такой задачи можно проводить, подключая ветку фичи на свободную дев площадку (не вливая ее в develop ветку).<\/p>\n<h2>Правила именования<\/h2>\n<p>Каждый коммит и пулл-реквест должны именоваться в следующем формате:<\/p>\n<blockquote>\n<p>[Sentry] EDS-1004: <пояснение><\/p>\n<\/blockquote>\n<p>В квадратных скобках можно указать часть системы, которая затрагивается — это упростит поиск коммита, если что-то сломается. Списка частей системы нет, выбирайте на свой вкус. Из общих советов — это должно быть что-то широкое, чтобы был понятен контекст, но не слишком широкое, чтобы не терялся смысл.<\/p>\n<p>EDS-1004 — даёт понимание по какой задаче была изменена строка в кода (через git blame), а потом по задаче можно найти ПОЧЕМУ это было сделано.<br \/>\nПлюс почти все таск-трекеры позволяют сконнектиться с Gitlab\/Github\/etc, и тогда коммиты и ПРы будут показываться в таск-трекре. А в Gitlab\/Github все упоминания задач будут отображаться ссылками на таск-трекер автоматически.<\/p>\n<h2>Работа с ветками<\/h2>\n<ol start=\"1\">\n<li>Из ветки main (или аналогичных prod\/master) создается ветка develop.<\/li>\n<li>На каждую фичу создаётся новая ветка вида feature\/XXX-short-description от ветки develop. XXX — номер задачи из таск-трекера, <short-description> — краткое описание задачи на английском языке. Например: `feature\/TASK-1777-change-forms-for-clients`.<\/li>\n<li>Когда фича готова (это значит, что разработчик считает, что фича выполнена корректно и протестирована локально) ветка фичи отправляется через Пулл-реквест в ветку develop. При создании Пулл-реквеста обязательно нужно выбрать галку «удалить ветку после мерджа», чтобы не разводить кладбище веток в git.<\/li>\n<li>Разработчик не забывает регулярно подтягивать ветку develop в свою ветку фичи в процессе разработки, чтобы уменьшить количество конфликтов при последующем MR в develop.<\/li>\n<li>Для релиза ветку develop мерджим в ветку main через MR в Gitlab\/Githab\/etc.<\/li>\n<li>Если в ветке prod обнаруживается критичный баг, то от main создается ветка hotfix\/XXX-short-description.<\/li>\n<li>Как только исправление на ветке hotfix завершено, она мержится с ветками main, а затем с develop.<\/li>\n<li>После каждого мерджа тестируем в первую очередь новый функционал, потом все остальное.<\/li>\n<li>Если разработчик не успевает сделать свою задачу до релиза, то ветка фичи не мерджится в ветку develop.<\/li>\n<li>Если фича большая и не попадает в ближайший релиз, то разработку продолжаем в той же ветке под фичу, пока ее полностью не сделаем. Не забываем делать 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"
                ]
            }
        }
    ],
    "_e2_version": 3559,
    "_e2_ua_string": "E2 (v3559; Aegea)"
}