Как правильно отправить релиз на git?
1,00
р.
Я использую гит для своего проекта, работаю один.
И вот готов у меня релиз первой версии, я следую совету этой статье на хабре и тут описано, что нужно создать ветку релиза и как она будет доведена до выпуска то слить ее в мастер и в девелоп, после чего удалить ее...
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово... Я так понимаю, что мне нужно ее сливать в мастер сразу и помечать тегом и продолжать дальше вести проект в дефелопе.
Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер...
Вопрос вот в чем, будет ли правильно сделать коммит на локальной ветке девелоп , поставить на нее таг, слить в удаленный девелоп и уже удаленный девелоп смержить с удаленным мастером...
Я просто не уверен, что эта концепция правильная и второе я не уверен, что можно делать мерж на удаленых ветках...
Посоветуйте как правильно сделать?
Ответ
Сначала немного теории, чтобы обосновать практические рекомендации. Надеюсь, заскучать не успеете.
Что вообще происходит и откуда взялись ветки develop и release
Указанная вами статья – про модель рабочего процесса под названием git flow. Это в целом хорошая модель. Она была придумана, чтобы упорядочить бардак и анархию при совместной работе над кодом в больших проектах, и именно в них она эффективна. Если у вас сто человек работает над одним приложением, если вы вынуждены поддерживать старые версии (исправлять баги и критические уязвимости), если в день делаются сотни коммитов — берите, не пожалеете.
А для команд, которые
немногочисленны, примерно до 10 человек работают по agile и дробят задачи настолько, чтобы они делались за день-два используют в основном самую последнюю версию продукта и не должны тащить старые версии
... git flow попросту не нужен. Он создаёт больше проблем, чем решает.
Как сделать проще
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово
Правильно! Вам и девелоп-то не нужен.
Для небольших команд и соло-разработки больше подходят «легковесные» модели организации рабочего процесса. Самая популярная называется GitHub Flow, от неё отличаются некоторыми деталями и бóльшей глубиной проработки GitLab Flow и Simple Git workflow (Atlassian).
Суть всех простых моделей рабочего процесса
Есть единственная стабильная (постоянная, долгоживущая) ветка master. Любая фича или исправление бага делается в отдельной ветке, которая ветвится от master. Как только фича или багфикс готов, прошёл ревью и тестирование, соответствующая ветка мержится в master. Потом ветка обязательно удаляется, чтобы не копить хлам.
Кроме очевидной простоты преимущество в том, что код не пишется «в стол» и не залёживается в релизных ветках, а выпускается как можно быстрее. Чем короче путь от идеи до продакшена — тем лучше для дела. Клиенты (пользователи) быстрее получают новые фичи, а вы быстрее получаете обратную связь от клиентов и деньги за эти фичи.
Как создавать и называть ветки
Принято начинать название feature-ветки с номера задачи в трекере задач.
git checkout master git checkout -b 123-featurebranch
Вы же где-то ведёте список задач? Начните, если нет, и вот почему:
Чтобы не держать их в голове, т.к. это ненадёжно и съедает ресурсы мозга Чтобы вы могли их оценивать, планировать, выбирать приоритеты Чтобы хранить информацию о багах и способах их воспроизвести. Тренировка для командной работы вы наверняка не будете всю жизнь работать соло. Если проект в опенсорсе, то кто-нибудь придёт и заведёт вам задачу-пожелание или задачу-багрепорт. Или возьмёт вашу задачу и сделает, просто так, даром. Нельзя сделать задачу, которая не описана, верно?
Формулируйте маленькие, атомарные задачи, чтобы работа в ветке шла 1-3 дня, не больше. Это важно для работы соло и критически важно для командной работы.
Локальные ветки желательно тоже пушить на удалённый сервер, это хороший способ не потерять код, когда пролил чай в ноутбук, rm -rf /, пожар, кража, метеорит...
git push -u origin 123-featurebranch:
Как мержить ветки
Есть два основных способа:
Ветку можно замержить вручную, локально. В командной строке это так: git checkout master git merge --no-ff 123-featurebranch git push
Если вы используете GitHub, GitLab, Bitbucket — можно открыть пулл/мерж-реквест и потом его замержить. При этом фактически мержатся удалёные ветки, потом вам нужно будет подтянуть себе результат мержа (git pull). Этот способ помогает проводить инспекцию кода в команде и разное автоматизированное тестирование, но если вы работаете один, мерж-реквесты почти не нужны.
Особенности:
Мержить ветки нужно через --no-ff, чтобы всегда создавался мерж-коммит. Он поможет вам просматривать историю, он помогает найти ветку, в которой был сделан коммит, и точно обозначает место, где эту ветку замержили, его можно отменить с помощью git revert. Любите мерж-коммиты, они вам пригодятся. Не нужно мержить в master то, что не готово, не доделано и т.п. Ветка master священна, в ней всегда должен быть рабочий код. Никогда не нужно мержить ветку master в ветку фичи. Исключения — подтягивание кода из мажорного релиза в долгоживущую ветку, разные ветки для разных тестовых окружений и прочие ситуации, которые почти не встречаются при соло-разработке небольшого проекта.
Релиз
Когда вы готовы сделать релиз, просто возьмите нужный мерж-коммит и повесьте на него тег. Используйте аннотированные (annotated) теги. В них сохраняется дата и автор, как в коммите. Таким образом сохранится информация о том, кто именно и когда принял решение о выпуске релиза.
git tag -a v1.0 -m "Version 1.0"
Чтобы запушить теги на удалённый сервер, делайте так:
git push --follow-tags
Параметр --follow-tags нужен для того, чтобы запушить только аннотированные теги и не пушить легковесные (lightweight), если они у вас вдруг есть.
Не отмечайте релизными тегами коммиты в feature-ветках. Замержили, протестировали результат, отметили тегом полученный мерж-коммит. Всё, что не в master, не может быть релизом.
Для создания номеров версий используйте семантическое версионирование.
Выпускайте релизы как можно чаще
Поскольку ветка master всегда обязана содержать работающий код и вы всегда мержите в неё только готовые фичи, каждый мерж — это фактически маленький релиз. При этом обязательно каждый раз пересобирайте приложение. Не факт, что его нужно сразу выпускать для всех пользователей — слишком частые обновления приложения могут их раздражать.
Но постарайтесь собрать группу бета-тестеров (начните с себя), для которых вы будете выпускать приложение после каждого мержа ветки в master. Таким образом вы ускорите получение обратной связи, а чем быстрее цикл ОС, тем быстрее развивается ваше приложение и ваши навыки. В этом суть Agile.
Практика
С учётом вышесказанного, предлагаю такой план действий.
Замержить (слить) develop в master. Повесить на полученный мерж-коммит тег. Удалить ветку develop и не вспоминать о ней до поры.
И вот готов у меня релиз первой версии, я следую совету этой статье на хабре и тут описано, что нужно создать ветку релиза и как она будет доведена до выпуска то слить ее в мастер и в девелоп, после чего удалить ее...
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово... Я так понимаю, что мне нужно ее сливать в мастер сразу и помечать тегом и продолжать дальше вести проект в дефелопе.
Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер...
Вопрос вот в чем, будет ли правильно сделать коммит на локальной ветке девелоп , поставить на нее таг, слить в удаленный девелоп и уже удаленный девелоп смержить с удаленным мастером...
Я просто не уверен, что эта концепция правильная и второе я не уверен, что можно делать мерж на удаленых ветках...
Посоветуйте как правильно сделать?
Ответ
Сначала немного теории, чтобы обосновать практические рекомендации. Надеюсь, заскучать не успеете.
Что вообще происходит и откуда взялись ветки develop и release
Указанная вами статья – про модель рабочего процесса под названием git flow. Это в целом хорошая модель. Она была придумана, чтобы упорядочить бардак и анархию при совместной работе над кодом в больших проектах, и именно в них она эффективна. Если у вас сто человек работает над одним приложением, если вы вынуждены поддерживать старые версии (исправлять баги и критические уязвимости), если в день делаются сотни коммитов — берите, не пожалеете.
А для команд, которые
немногочисленны, примерно до 10 человек работают по agile и дробят задачи настолько, чтобы они делались за день-два используют в основном самую последнюю версию продукта и не должны тащить старые версии
... git flow попросту не нужен. Он создаёт больше проблем, чем решает.
Как сделать проще
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово
Правильно! Вам и девелоп-то не нужен.
Для небольших команд и соло-разработки больше подходят «легковесные» модели организации рабочего процесса. Самая популярная называется GitHub Flow, от неё отличаются некоторыми деталями и бóльшей глубиной проработки GitLab Flow и Simple Git workflow (Atlassian).
Суть всех простых моделей рабочего процесса
Есть единственная стабильная (постоянная, долгоживущая) ветка master. Любая фича или исправление бага делается в отдельной ветке, которая ветвится от master. Как только фича или багфикс готов, прошёл ревью и тестирование, соответствующая ветка мержится в master. Потом ветка обязательно удаляется, чтобы не копить хлам.
Кроме очевидной простоты преимущество в том, что код не пишется «в стол» и не залёживается в релизных ветках, а выпускается как можно быстрее. Чем короче путь от идеи до продакшена — тем лучше для дела. Клиенты (пользователи) быстрее получают новые фичи, а вы быстрее получаете обратную связь от клиентов и деньги за эти фичи.
Как создавать и называть ветки
Принято начинать название feature-ветки с номера задачи в трекере задач.
git checkout master git checkout -b 123-featurebranch
Вы же где-то ведёте список задач? Начните, если нет, и вот почему:
Чтобы не держать их в голове, т.к. это ненадёжно и съедает ресурсы мозга Чтобы вы могли их оценивать, планировать, выбирать приоритеты Чтобы хранить информацию о багах и способах их воспроизвести. Тренировка для командной работы вы наверняка не будете всю жизнь работать соло. Если проект в опенсорсе, то кто-нибудь придёт и заведёт вам задачу-пожелание или задачу-багрепорт. Или возьмёт вашу задачу и сделает, просто так, даром. Нельзя сделать задачу, которая не описана, верно?
Формулируйте маленькие, атомарные задачи, чтобы работа в ветке шла 1-3 дня, не больше. Это важно для работы соло и критически важно для командной работы.
Локальные ветки желательно тоже пушить на удалённый сервер, это хороший способ не потерять код, когда пролил чай в ноутбук, rm -rf /, пожар, кража, метеорит...
git push -u origin 123-featurebranch:
Как мержить ветки
Есть два основных способа:
Ветку можно замержить вручную, локально. В командной строке это так: git checkout master git merge --no-ff 123-featurebranch git push
Если вы используете GitHub, GitLab, Bitbucket — можно открыть пулл/мерж-реквест и потом его замержить. При этом фактически мержатся удалёные ветки, потом вам нужно будет подтянуть себе результат мержа (git pull). Этот способ помогает проводить инспекцию кода в команде и разное автоматизированное тестирование, но если вы работаете один, мерж-реквесты почти не нужны.
Особенности:
Мержить ветки нужно через --no-ff, чтобы всегда создавался мерж-коммит. Он поможет вам просматривать историю, он помогает найти ветку, в которой был сделан коммит, и точно обозначает место, где эту ветку замержили, его можно отменить с помощью git revert. Любите мерж-коммиты, они вам пригодятся. Не нужно мержить в master то, что не готово, не доделано и т.п. Ветка master священна, в ней всегда должен быть рабочий код. Никогда не нужно мержить ветку master в ветку фичи. Исключения — подтягивание кода из мажорного релиза в долгоживущую ветку, разные ветки для разных тестовых окружений и прочие ситуации, которые почти не встречаются при соло-разработке небольшого проекта.
Релиз
Когда вы готовы сделать релиз, просто возьмите нужный мерж-коммит и повесьте на него тег. Используйте аннотированные (annotated) теги. В них сохраняется дата и автор, как в коммите. Таким образом сохранится информация о том, кто именно и когда принял решение о выпуске релиза.
git tag -a v1.0 -m "Version 1.0"
Чтобы запушить теги на удалённый сервер, делайте так:
git push --follow-tags
Параметр --follow-tags нужен для того, чтобы запушить только аннотированные теги и не пушить легковесные (lightweight), если они у вас вдруг есть.
Не отмечайте релизными тегами коммиты в feature-ветках. Замержили, протестировали результат, отметили тегом полученный мерж-коммит. Всё, что не в master, не может быть релизом.
Для создания номеров версий используйте семантическое версионирование.
Выпускайте релизы как можно чаще
Поскольку ветка master всегда обязана содержать работающий код и вы всегда мержите в неё только готовые фичи, каждый мерж — это фактически маленький релиз. При этом обязательно каждый раз пересобирайте приложение. Не факт, что его нужно сразу выпускать для всех пользователей — слишком частые обновления приложения могут их раздражать.
Но постарайтесь собрать группу бета-тестеров (начните с себя), для которых вы будете выпускать приложение после каждого мержа ветки в master. Таким образом вы ускорите получение обратной связи, а чем быстрее цикл ОС, тем быстрее развивается ваше приложение и ваши навыки. В этом суть Agile.
Практика
С учётом вышесказанного, предлагаю такой план действий.
Замержить (слить) develop в master. Повесить на полученный мерж-коммит тег. Удалить ветку develop и не вспоминать о ней до поры.
