Я использую гит для своего проекта, работаю один.
И вот готов у меня релиз первой версии, я следую совету этой статье на хабре и ту
описано, что нужно создать ветку релиза и как она будет доведена до выпуска то слит
ее в мастер и в девелоп, после чего удалить ее...
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово..
Я так понимаю, что мне нужно ее сливать в мастер сразу и помечать тегом и продолжат
дальше вести проект в дефелопе.
Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер...
Вопрос вот в чем, будет ли правильно сделать коммит на локальной ветке девелоп
поставить на нее таг, слить в удаленный девелоп и уже удаленный девелоп смержить с удаленны
мастером...
Я просто не уверен, что эта концепция правильная и второе я не уверен, что можн
делать мерж на удаленых ветках...
Посоветуйте как правильно сделать?
Ответы
Ответ 1
Сначала немного теории, чтобы обосновать практические рекомендации. Надеюсь, заскучат
не успеете.
Что вообще происходит и откуда взялись ветки 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 и не вспоминать о ней до поры.
Ответ 2
будет ли правильно сделать коммит на локальной ветке девелоп,
поставить на нее таг...
Можно и так.
Я просто не уверен, что эта концепция правильная
Она одновременно может быть правильной, и не подходящей конкретно вашему проекту.
я не уверен, что можно делать мерж на удаленных ветках...
Нельзя. Вы синхронизируете локальные ветки с удаленными (fetch/pull), мержите,
синхронизируете удаленные с локальными (push). На самом деле даже ветка origin/maste
тоже является локальной.
Посоветуйте как правильно сделать?
IT - такая интересная область, в которой множество правильных ответов.
В частности, для проекта с одним разработчиком можно обойтись одной веткой maste
и помечать релизы тэгами.
git flow и прочие методики работают хорошо, только если вы понимаете какие именн
проблемы они решают. Пока ваш проект таких проблем не содержит, методики сами лишь усложняю
жизнь.
Ответ 3
1 создать rc ветку
2 смержить с вашей dev
3 вылить rc ветку
Так делается для того, что в случае креша можно было спокойно переключиться н
предыдущую стабильную ветку, пофиксить новую rc ветку и опять зарелизить. Удалять ветк
крайне не рекомендую. На практике часто приходиться доставать изменения в других ветках
Но если у вас веток перевалило за N и вы в них уже путаетесь, тогда можно почистит
и только локально (git branch -d <ветка>)
Ответ 4
В том случае, что Вы описали Вы можете поступить 2 способами:
Пойти по пути git flow, создав release ветку и тут же её завершив.
Сделать слияние develop с master самостоятельно и [опционально] поставив tag на master.
Оба способа дадут одинаковый результат, но используя второй, нужно проделать меньш
работы. Поэтому, на мой взгляд, стоит воспользоваться именно им.
Тогда вообще зачем нужны release ветки? Всё дело в том, что любая методология являетс
набором некоторых принципов, которые были выработаны годами либо одним автором, либ
группой авторов. git flow вырос из командной разработки, где, как правило, есть отдельны
люди занимающиеся тестированием продукта, а могут ещё быть и те, кто продукт долже
принять.
Вот здесь хорошо вписываются release ветки. К примеру, Ваша команда сделала определённы
набор функционала, который требуется к выпуску, скажем, версии 1.0. Всё это находитс
в ветке develop и у Вас нет никакой уверенности, что код правильный(он не оттестирова
как следует, и главный менеджер ещё тоже не изучал функционал). Вы могли бы выложит
результат из develop, но что делать с простаивающими разработчиками, которые не могу
вливать новый функционал в develop, т.к. есть чётко очерченный круг функционала выпуска?
Чтобы разработчики не простаивали — выпускаем release ветку, в которой уже нельз
добавлять никакого нового функционала, но должны быть исправлены любые найденные ошибк
и неточности. Когда все найденные ошибки исправлены, и замечания учтены — release ветк
закрывается, сливается с master и продукт выпускается.
Как Вы можете видеть, для Вас, как для одиночки, release ветка не нужна. Поэтому
просто обходите этот шаг стороной, если не хотите выполнять дополнительной работы
помните, что любая методология это набор общих принципов и правил, и почти всегда методологи
нужно адаптировать к нуждам конкретного случая — если Вы не понимаете, как что-то использовать
то почти наверняка Вам это не нужно.
Ответ 5
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово...
Вся прелесть веток не только в том, что вы получаете свою копию проекта, но и в том
что ваши коммиты будут логически объединены:
* 4873cb7 Merge branch 'allow_different_debuggers_for_each_instance' into develop
|\
| * 75b5384 Reduce TTL for variable
| * 4d0552a Figure out context for debugger methods automatically from current debugge
instance
| * 1e4b894 Allow &DB::state to return current debugger instance
| * 19de6dc Make debugger instances typed (objects)
| * b5a7cfe Call methods of current debugger instance through &DB::mcall
|/
* ec61d37 Code comments
* ecbc39a Rename _all_frames -> orig_frames
* 7aa54f9 Do not hide DB:: from PAUSE indexer
Т.е. вы будете потом видеть, что эти 5 коммитов были сделаны в рамках реализации той фичи
Не слушайте никого, что т.к. вы девелопер одиночка, то вам можно не следовать все
этим правилам gitflow. Учитесь работать правильно изначально!
Используя модель git-flow и работая с чистым git, да, вы будете выполнять лишни
команды, что будет замедлять вас. Но это не проблема этой модели, а ваша проблема, т.к
вы не используете нужные утилиты ;-) Например я использую gitflow-avh, отконфигурирова
.gitconf
[alias]
tree = log --graph --decorate --pretty=oneline --abbrev-commit
prb = pull -v --rebase
br = branch
fs = flow feature start
ff = flow feature finish
fc = flow feature checkout
hs = flow hotfix start
hf = flow hotfix finish
и добавил алиасы в .bashrc
alias gn="git-number"
alias gb="gn -c git blame"
alias ge="gn -c $EDITOR"
alias ga="gn add"
alias gr="gn -c git reset"
alias gap="EDITOR='$EDITOR -w' gn add -p"
alias gd="gn -c git diff -b -w --ignore-blank-lines"
alias gds="gd --staged"
alias gc="gn -c git checkout"
alias gcf="git flow feature checkout"
alias gl="gn -c git log -w -b -p --ignore-blank-lines"
alias gls="git log --stat"
alias cm="EDITOR='$EDITOR -w' git commit"
alias grb="git stash save 'REBASE' && EDITOR='$EDITOR -w' git rebase -i"
alias grbc="EDITOR='$EDITOR -w' git rebase --continue"
gcd() {
test -n "$1" && cd $(dirname $(git list $1))
}
source ~/.git-completion.bash
__git_complete gn _git
__git_complete ga _git_add
__git_complete gap _git_add
__git_complete gd _git_diff
__git_complete gds _git_diff
__git_complete gc _git_checkout
__git_complete gcf _git_checkout
__git_complete gl _git_log
__git_complete gls _git_log
__git_complete cm _git_commit
source ~/.git-flow-completion.bash
И работаю в консоли со всеми этими "не нужными" ветками быстрее, чем используя всяки
графические тулзы, и бонусом получаю красивую историю, т.к. следую git-flow. Плюс по
рукой остаются вся мощность git (обычно графические утилиты реализуют далеко не вс
фичи, а в основном только базовые).
Подробнее о том, как настроить окружение, можно посмотреть тут.
Не знаю как у вас, но в самом начале, когда я познакомился с git, у меня возникал
путаница с пониманием того что есть ветки master, production, develop. Поэтому я дл
себя решил так. ИМХО:
Ветка, которую катим на боевые сервера - production
Ветка, в которой ведется разработка (то куда вы мержите ваши фичи) - develop
Да, и во многих статьях под веткой master подразумевают production
Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер...
Отвечая на ваш вопрос как делать правильно я обращу ваше внимание на то, что Ваш
работа всегда происходит локально, а с удалённым репозиторием вы делаете только синхронизацию
Поэтому
Вы делаете мерж вашего локального девелоп в локальный мастер
Вы делаете push вашего локального мастера в удалённый
Ну а далее я поддержу вот этот развернутый ответ, за исключением никоторых моментов:
Есть единственная стабильная ветка master.
Её нельзя назвать стабильной, пока вы не проведёте тестирование. Во время тестировани
вы можете обнаружить баг, для фикса которого вы сделаете дополнительный коммит в master
Соответственно на предыдушем коммите ваша ветка является не стабильной.
По этой причине придумали ветку release. В которой можно делать хоть сколько угодн
итераций тестирования по завершению которых вы выпускаете свой релиз и делаете мер
ветки в master/production и develop.
Пусть что там не говорят, но в любом случаем вы должны иметь следующие ветки:
production ветка - это ветка в которой гарантированно любой коммит готов к деплою.
develop ветка - это ветка в которую вы сливаете ваши фичи
hotfix ветка - эта ветка (чтобы не делать cherry-pick из прод в дев) в которой в
делаете фиксы
release ветка - для спокойного создания релизов
Поэтому даже если вы программист одиночка я рекомендую вам следовать git-flow модели
чтобы уметь работать правильно
Ответ 6
Проверьте, у вас должна быть локальная ветка master. И делать слияния надо, конечно
локально, а потом выгружать их в центральный репозиторий.
Что касается необходимости создавать ветку релиза, то здесь, наверное, всё зависи
от того, как вы разрабатываете проект, и как организован процесс. В XXI веке, где ест
Scrum, Continuous Integration и DevOps, разворачивание проекта может происходить п
одной кнопке, и дорабатывать его напильником при каждом релизе в отдельной ветке не нужно.
Тут, скорее, вопросы к автору статьи на Хабре.
Другое дело, постоянная ветка release. Она может быть полезна для реализации тог
самого разворачивания по одной кнопке. Есть несколько разных способов реализации таког
поведения, и один из них — повесить хук на push в ветку release, по которому новый ко
и будет развёрнут на сервере промышленной эксплуатации (он же production).
Тогда вы просто пишите и тестируете код в одной ветке, назовём её dev, и когда считаете
что код работает корректно, переливаете изменения в release, а ваш build-сервер собирае
установочный пакет или разворачивает код на веб-сервере.
При этом теги, конечно, вы ставите, и ставите там, где вам удобно. Ветка dev вполн
подойдёт.
Комментариев нет:
Отправить комментарий