Git-flow хотфиксы во время спринта

#git #git_flow

Есть основные ветки dev, master.
В дев ветке ведутся работы по текущему релизу.
В средине спринта приходит реквест свыше на реализацию фичи, фича будет(должна быть)
выпущена раньше текущего релиза. 
Что должно быть дальше? Новая бранча от мастера в которой будет реализация новой
фичи, после чего мастер мерджим в дев? Где бы можно было бы почитать про правильные
подходы для таких случаев? 

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

Ответы

Ответ 1

Думаю, вряд ли в подобной ситуации найдется "канонично" верный ответ. Причиной тому
является то, что если вы работаете по agile спринтам, то добавление крупного функционала
посреди спринта не является адекватной практикой. Так, что фактически описанный вами
git-flow не совместим с подобным стилем разработки (когда неожиданно прилетает задание).

Предположу, что функционал, который у вас находится сейчас в dev вам в любом случае
еще понадобится, по этому выбрасывать его не вариант. В связи с этим предложил бы следующее
решение:


Временно оставить dev в покое.
От master сделать отдельную ветку под фичу, в которой будет вестись разработка. 
Довести разработку в ветке до конца, влить в master после приемки/тестирования/релиза/апрува.
Подлить в dev изменения из master и продолжить работу в dev


Если, подобные ситуация с вклиниванием блока задач или огромной фичи для вас являются
нормальной практикой, то я бы предложил вам немного пересмотреть git-flow в сторону
следующего подхода:


После релиза от master ветки создается (или актуализируется dev).
Для каждой крупной фичи или сгруппированного по смыслу блока задач делается отдельная
ветка от dev.
В каждой такой отдельном ветке ведется разработка фичи (или блока задач) параллельно
до момента готовности.
Когда фича (или блок задач) в ветке проходит приемку/тестирование ветка подливается
в dev.
Когда все тематические ветки из спринта прошли приемку/тестирование отладку, эти
ветки сливаются в dev и происходит приемочное тестирование.
После успешного прохождения приемки в master подливается dev и происходит релиз.
Переходим к шагу 2


Такой git-flow будет более гибким и позволит вам вклинивать такие внезапные задачи
"сверху" без катастрофических последствий в репозитории. Тематические ветки всегда
есть возможность обновить с dev (если туда сольются какие-то другие фичи) - актуализировать.


Ответ 2

Не встречал еще на практике адекватного использование git-flow.

Либо в dev треш, и ветки мержатся сразу в master, а затем в dev для вида.

Либо вся работа ведется в dev, и мержится в master для вида. Во втором случае dev
и master совпадают по содержимому.

Предлагаю рассмотреть вариант отказа от git-flow, во всяком случае от ветки dev.
Проще и понятнее создавать рабочие и релизные ветки из master.

А ответ на поставленный вопрос - хотфикс.

Git. Почему родителями считаются более поздние коммиты?

#git #git_flow

Разбирался в основах Git и в главе, посвященной основам слияния  появился вопрос. 

Почему родителями считаются более поздние коммиты, расположенные в "кроне" графа
и стрелки идут к ним, а не от них?

Ведь по логике, они являются "слепками" с предыдущего состояния.

Например, используя эту картинку, объясняется слияние ветки hotfix в ветку master


  ветка, которую мы слили (*прим - hotfix), указывала на коммит, являющийся прямым
родителем коммита, на котором мы сейчас находимся (**прим - master), Git просто сдвинул
её указатель вперёд




И из этого описания получается, что С4 является родителем С2, хотя дело обстоит ровно
наоборот (С4 содержит parentId, который указывает на С2)
    

Ответы

Ответ 1

Подозреваю, что тут имеет место ошибка перевода.

"Родительский коммит" это пометка внутри каждого коммита о том, какое состояние было
до него, в формате коммит-хэша. Пометка необязательно одна. Может быть и ноль (для
начального коммита) и больше одной (для слияния).

Как правило, родительский коммит делается до потомка, но реально время на структуру
графа коммитов не влияет, только вышеописанные "пометки". Нарушение этого скорее экзотика,
но возможно.

Касательно стрелочек сложилось два прямо противоположных стиля:


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


Какого-то предпочитаемого нет. Разве что там, где повествуют об устройстве Git, предпочитают
второй стиль, как лучше соответствующий реальному устройству Git, а не удобной абстрактной
картине к головах разработчиков.


Ответ 2

Номера указывают на верный хронологический порядок. C0 — это корень дерева, первый
коммит. От него идут другие коммиты. Когда создается новый коммит, он получает указатель
на текущий актуальный коммит, тот становится родителем нового коммита. Указатель —
это строка из 40 символов хеша SHA-1.

Разумеется, каждый коммит может быть родителем скольки угодно других коммитов. В
мерж-коммитах может быть два или более родителя — несколько строк с SHA-1.

Именно такой указатель изображается стрелочкой. По стрелочкам можно пройти до конца
— корневого коммита. В редких специально созданных случаях корней может быть более
одного — git позволяет сделать слияние двух несвязанных деревьев.

Как задать шаблон для имен веток, вроде topic/myfeature или bugfixes/myfeature?

#git #git_branch #git_flow #source_tree

Добрый день, сейчас я работаю с git репозиторием, на котором ветки организованы в
папки: фичи в папке topic/myfeature, багфиксы в папке bugfixes/myfeature.

Собственно вопрос такой, могу ли я сконфигурировать дефолтное имя вообще всех новых
веток которые я создаю, используя сам git или инструментарий sourcetree? То есть я
хочу чтобы когда я нажимаю "создать новую ветку" мне предлагалось автоматически создать
ветку с названием topic/*.

То есть мне нужно предустановленное название ветки которую я создаю. Самой ветки,
имя репозитория к этому отношения не имеет.
    

Ответы

Ответ 1

То, что вы описываете - это расширение git-flow, вводящее высокоуровневые операции
для управления потоком разработки. Судя по именованию - большинство разработчиков в
вашей комманде использут/использовали именно его.

SourceTree умеет работать с этим расширением. По нажатию на кнопку "Git Flow" на
тулбаре открывается диалог инициализации Git Flow:



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

После инициализации, по нажатию на кнопку Git Flow будет показыватся диалог операций,
позволяющий начинать и завершать работу над фичами, релизами, хотфиксами и т.д:


Ответ 2

git remote -v
# View existing remotes
# origin  https://github.com/OWNER/REPOSITORY.git (fetch)
# origin  https://github.com/OWNER/REPOSITORY.git (push)

git remote rename origin topic
# Change remote name from 'origin' to 'topic'

git remote -v
# Verify remote's new name
# topic  https://github.com/FORKER/REPOSITORY.git (fetch)
# topic  https://github.com/FORKER/REPOSITORY.git (push)


локальный конфиг хранится тут, если что

vim .git/config

Организация работы c Git

#git #git_flow

Добрый день.
Имеется следующий вопрос по реализации GIT схемы.

В нашей работе мы используем два сервера.  


Develop (на нем мы хотим тестировать и показывать промежуточные
результаты)  
Production (на него выкладываем только готовые модули)


У нас 8 разработчиков, каждый работает со своей локальной копией проекта. В течение
дня разработчики должны выкладывать промежуточные результаты на develop сервер, после
подтверждения работы модуля (конкретного разработчика) - необходимо сливать изменения
на боевой сервер (production).

Как вы посоветуете реализовать схему работы с GIT? (сколько веток? как осуществлять
deploy на production, и т.д)

Спасибо. 



Спасибо за ваш ответ. Схема нашей работы. 1. Разработчик правит модуль. 2. Разработчик
делает commit на Develop (здесь возникает вопрос - какие ветки создать, учитывая что
у нас 8 разработчиков; в большинстве случаев каждый разработчик работает со своим модулем,
стоит создать каждому свою ветку или делать коммит в мастер?) 3. Пользователь проверяет
/ тестирует работу модуля и если все работает то этот модуль необходимо выложить на
production сервер. Как реализовать эту схему? Раньше мы не использовали git поэтому
мы не совсем понимаем всех аспектов работы с гитом. Мы будем благодарны если Вы опишите
git схему в нашем конкретном случае. (подобные статьи мы читали но возникает больше
вопросов) Спасибо. 

Еще есть сложность в понимании следующего: 
Каждый разработчик комитит в мастер ветку для того чтобы дать возможность пользователям
посмотреть результат (домен develop предположим)
Вася и Петя выложили работу своего модуля в ветку мастер, модуль Васи готов а модуль
Пети необходимо доработать, как в этом случаи производить мерж ветки мастер с production
(ведь модуль Пети еще не готов) 
    

Ответы

Ответ 1

По тому, что вы описываете, похоже, что вы стремитесь релизить как можно чаще и тестировать
все изменения перед отправкой на бой. Это правильные цели.


  В течение дня разработчики должны выкладывать промежуточные результаты на develop
сервер


Обычно изменения не мержат в общую ветку, пока фича не доделана. Каждый лишний мерж
— потеря сил и времени. А если изменения придётся откатывать, будет совсем тяжело.

Ветки, задачи, релизы

Можно попробовать такую схему:


Разработчики делают новую ветку от master для каждой новой фичи. Каждый день они
делают коммиты в эту ветку. Когда фича готова, ветку мержат обратно в master и для
новой фичи начинают новую ветку. 
Мержить очень рекомендую с созданием мерж-коммита (git merge --no-ff). Подробнее
о том, как ветвить и мержить: Правильное именование веток

Перед мержем желательно выполнить такие задачи:


Ревью кода, его делает тимлид.
Тестирование, его проводит тестировщик. Если нет возможности автоматически деплоить
на сервер, то пусть забирает себе нужную ветку git fetch; git checkout 123-branchname
и поднимает сайт локально. Если менялся дизайн, верстка, юзабилити и прочее, их тоже
нужно протестировать.


Тестирование и ревью кода можно делать просто через ветки, а можно добавить пулл-реквесты.
Зачем нужен pull request, если есть push?


Код из ветки master деплоится на сервер staging автоматически, каждый раз, когда
происходит коммит в master. Автоматизация — за счет git hooks или сервера непрерывной
интеграции, в зависимости от ваших возможностей и ресурсов.

На этом сервере:


Тестировщик смотрит на интеграцию изменений от разных разработчиков.
Менеджер или кто там ответственен за продукт смотрит на готовность фичи.

Когда очередной коммит в master признаётся годным для деплоя на бой, ответственный
за релиз человек делает мерж в ветку production. Из этой ветки тем же механизмом автоматически
обновляется сервер production.




Как деплоить

Если можете, разделите сервер git и сервер с сайтом. Деплой через git pull плохо
масштабируется, лучше настроить через rsync, тогда вы легко сможете использовать дополнительные
тестовые сервера. Настройка и развертывание проекта c помощью Git

Что такое непрерывная интеграция?

Проблема: Последнее вливание ветки разработчика в ветку develop занял три дня, пр
этом пришлось разрулить порядка 100 конфликтов.

Условия: В динамическом проекте 3 разработчика и мы работаем по Git Flow. Разработчик
создают свою ветку от ветки develop, а через некоторое время (от 3 дней до 3 недель
в зависимости от сложности задачи) вливают в неё изменения. Возможны глобальные и перекрестны
изменения.

Задача: минимизировать затраты времени на интеграцию изменений разработчиков в ветк
develop.

Из опробованных средств было соглашение о стремлении к частому вливанию изменени
в develop. Это, определенно, не помогло. По идее сервер непрерывной интеграции долже
решать эту проблему, но я не могу понять каким образом. В данный момент у нас есть TeamCity
который я развернул для того чтобы он запускал тесты при каждом коммите. И я полага
что всё-таки не это является основной обязанностью сервера непрерывной интеграции :)

Если непрерывная интеграция подразумевает постоянный merge изменений в develop, т
мне становится недоступной ситуация когда я могу в отдельной ветке поломать часть функционала
заменив в течении недели на новый. Если я сливаю изменения с develop моя текущая работ
влияет на работу другого разработчика (или это даже плюс?). Но даже если делать вливани
в develop только когда все тесты проходят, не думаю что это решит проблему: достаточн
крупное изменение будет означать может только один коммит в пару дней (upd поправка
так может случиться с учетом если примем решение коммитить только валидный код, а сложно
изменение ломает функционал надолго).

Я хочу услышать как в ваших проектах организована работа с сервером непрерывной интеграции
Как вы бы организовали нашу работу исходя из текущих условий?
    

Ответы

Ответ 1

Непрерывная Интеграция - это процесс объединения копий нескольких разработчиков 
общую ветвь несколько раз в день.


Continuous integration
Trunk (software)


Хотя распределенные системы контроля версий позволяют не иметь центрального репозитория
именно из-за наличия общих ветвей, объединяющих изменения, основной компонент инфраструктур
непрерывной интеграции это прежде всего центральный репозиторий, развернутый на сервер
(Github, Bitbucket, Gitlab).

В дополнение к этому, часто применяются серверы Continuous Integration, основна
функция которых - осуществлять сборку и проверку проекта, например TeamCity.

Сервер Continuous Integration никак не поможет с техническими конфликтами систем
контроля версий, но он может выявить часть логических конфликтов, например - некомпилирующийс
проект, или поломанный тест даже после бесконфликтного с точки зрения системы контрол
версий слияния.

В некоторый случаях сервер CI может выявить конфликты слияния, например - с помощь
функции Automatic Merge в TeamCity (начиная с версии 8.1).

Незаменимая вещь - отчет сборке, включая результаты автоматических тестов на кажду
фиксацию изменения в Trunk, а так же в других опубликованных ветвях. Это позволяет увидеть
если кто-то влил изменения, ломающие тест.

У нас собираются все опубликованные feature-ветви, поэтому можно даже отследить
как поломанный неделю назад в чьей-то ветке тест мигрировал в trunk, и попросить этог
разработчика срочно пофиксить тест.

Проблемы объединения изменений возникают, когда разработчик слишком долго не объединя
изменения, и сильно "разломал" свою ветвь. При этом проблема больше не в том, что разработчи
не публиковал изменения, которые еще не готовы, а в том, что он не "подливал" себе чужи
изменения. Не случайно идеология Git - Pull, don't push. Тех, кто делает только pus
и редко делает pull даже называли "пушистиками" в русском сообществе программистов.

Небольшой пример - я взялся рефакторить некоторый класс A, удалил из него публичны
метод GetX, и заменил в 10 местах использование этого метода на другой, GetY.

Предположим, что никто из разработчиков в своих ветвях не пытается вносить изменени
в класс A. Это хорошо, потому что даже если мои изменения затронули 10 мест по всем
решению, Git имеет шанс разрулить конфликты этих 10 файлов. Кто-то редактировал некоторы
из этих файлов, но не трогал ту строку, где вы скоро замените GetX на GetY.

Зато один из разработчиков привнес новое использование публичного метода GetX, потом
что он не знал, что этого метода уже как бы нет, и уже интегрировал это изменение 
Trunk. Это уже настоящий конфликт, который Git никогда не сможет разрулить. Мало тог
- Git может и не сообщить об этом логическом конфликте, потому что с точки зрения контрол
версий файлов конфликта нет! Этот конфликт обнаружится на этапе компиляции, а некоторы
другие логические конфликты и на этапе компиляции не обнаруживаются, и здесь становитс
ясна роль сервера CI, который выдаст отчет о тестах.

Так вот - если вы подливаете себе новые изменения других разработчиков часто, т
вы тут же обнаружите этот конфликт, и тут же в своей ветке замените этот GetX на GetY
поговорите с другими, чтобы они по возможности не делали этого, и все окей - продолжайт
дальше "ломать".

Еще один момент - компилируете ли вы перед тем, как сделать merge своей ветви в trunk
А что, сделали pull прямо перед push, и все окей, гит доволен. Все сделали pull, и вс
ругаются, что у них не собирается проект.

Вот для этого и нужен сервер Continuous Integration, в который вы можете опубликоват
свою ветвь, сделать pull request, увидеть что сборка прошла, потом уже делаете merge.

У нас TeamCity шлет письма всем разработчикам, если не прошел билд, или упали тесты
Это очень помогает: сам не заметишь - другие тут же сообщат. Поэтому публикуйте сво
ветви, и настройте TeamCity чтобы он собирал буквально все, и гонял по возможности тесты
У нас на каждый коммит гоняются только некоторый набор тестов, так, чтобы билд укладывалс
в 7 минут примерно. Ночью на транке тестируется билд с полным набором тестов, включа
базу данных - это несколько часов.

Есть и несколько других методов, как можно уменьшить количество конфликтов.

Во-первых, постарайтесь разбить задачу на мелкие шаги, которые меняют решение поэтапно
Иногда изменение реализации можно сделать отдельно от изменения API. В первую очеред
идут изменения, которые затрагивают API классов, потому что из этих изменений возникае
большинство конфликтов. Предупредите других о таких изменениях во всеуслышание, согласуйт
и как можно быстрее добейтесь объединения таких изменений, потом убедитесь, что вс
сделали pull этих ваших изменений.

Здесь помогает утренний скрам, так как другие могут вовремя узнать о том, что в
планируете делать, и посоветовать, как обеспечить "бесконфликтность".

Иногда можно реализовать изменение так, что новая фича, даже будучи не до конца реализованной
не поломает приложения. Например - у нас с десяток интеграций с однотипными партнерами
и добавление партнера - это два-четыре месяца. Никто не ныряет в бранч - фича прост
присутствует в коде в отключенном на уровне конфигурации режиме. Первый этап, которы
подразумевает некоторый рефакторинг API, добавление какого-то базового класса, каких-т
значений в справочники - производится по возможности быстро, и интегрируется в trunk
возможно это даже будет некий аврал, но такие вещи делаются задолго до следующего релиза
После этого можно перейти к постоянной интеграции, и спокойно "пилить" хоть год.

Другой вариант - если фича, ради которой разработчики уходят в свой бранч на неделю
затрагивает публичные интерфейсы существующих классов, то можно выделить задачу по изменени
API в отдельный бранч, интегрировать его часто, и в основном бранче фичи подливать себ
эти изменения так же, как его подливают себе остальные. Хорошо что Git позволяет практическ
мгновенно переключаться между ветвями.

У нас предусмотрены ветки обслуживания релизов.
Например - все основные изменения интегрируются в транк часто, а в ветку релиза ничег
никогда не интегрируется. Там делаются только небольшие, точечные изменения, направленны
на устранение критических ошибок. Никакого форматирования кода, никакого рефакторинга
Все эти изменения подливаются в trunk сразу же, и уже там находится лучшее решение
исправляющее ошибку более обстоятельно для следующего релиза. Это позволяет избежат
конфликтов интеграции этих ветвей практически полностью.

Естественно, есть и неотъемлемые свойства самого проекта, которые могут косвенн
влиять на количество конфликтов - это принципы SOLID, о которых уже упомянули в други
ответах, при нарушении которых приходится делать изменения сразу в нескольких местах.


Ответ 2

Процитирую принципы из книги «Непрерывная Интеграция», Пол М. Дюваль, Стивен Матиас
Эндрю Гловер. Принципы в качестве заголовоков, текст — мои собственные комментарии.

1. Передавайте код часто

Это означает, что инфраструктура должна позволять делать частые коммиты и часты
мержи в основную ветку, а разработчик должен пользоваться этой возможностью. 

Хорошо, когда разработчик может взять коммит с небольшими изменениями и на этом коммит
запустить функциональные и интеграционные тесты. Если где-то есть ошибка, он замети
ее сразу же. При этом юнит-тестов может быть недостаточно, т.к. код может отлично отрабатыват
в изолированном окружении, но сломается где-то выше, на уровне интеграции с другим
компонентами. Чем более сложен программный продукт, тем интеграция сложнее и тем важне
это требование.

Для этого нужна СDCI-инфраструктура, которая позволяет на каждом коммите не тольк
проводить юнит-тесты, но и создавать приближенное к боевому окружение, на котором можн
проводить тесты — как автоматические, так и ручные.

Ещё один аспект — это одна ветка на одну фичу. Чем меньшими порциями вносятся изменения
тем легче их отслеживать.


  достаточно крупное изменение будет означать может только один коммит в пару дней.  
  
  через некоторое время (от 3 дней до 3 недель, в зависимости от сложности задачи
вливают в неё изменения


Над чем здесь можно работать: 


Фичи меньшего размера. 3 недели это достаточно долго.
Более частые коммиты. Коммит != фича. (Я вообще воспринимаю коммиты как сохраненк
в опасной стрелялке и делаю коммит перед каждой дверью в темном углу).
Чтобы любой промежуточный коммит можно было запустить в псевдо-боевом окружении 
прогнать все тесты, включая интеграционные.


2. Не передавайте сбойный код

Тут всё достаточно просто. Если регрессионная проверка показывает, что новые изменени
вносят баг, эти изменения не нужно сливать в dev. Вроде бы очевидно, но очень неосмотрительн
будет предполагать, что 1) все тесты точно пройдены и 2) если они не пройдены, то разработчи
не будет сливать свою ветку.

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


  Если я сливаю изменения с develop моя текущая работа влияет на работу другого разработчик
(или это даже плюс?)


Не то чтобы плюс или минус, просто реальность. Подумайте о том, чтобы сливать develo
и текущую фичу в каком-то отдельном месте. Возможно, для тестирования интеграции ва
понадобится слить сразу несколько фич от разных разработчиков. Либо, если интеграци
не на уровне кода, а на уровне отдельных компонент (например, вы пишете сервер, а коллег
пишет клиент), то поднимайте полное окружение, в котором компоненты будут построен
из ваших веток с фичами.

Только когда вы убедились, что в тестовой ветке интеграция успешна, сливайте результа
в develop.

3. Ликвидируйте проблемы построения немедленно

Чинить ошибки построения — очень приоритетная задача. Если где-то сломался скрип
построения, или упал сервер интеграции, или устарели тесты — нужно идти и чинить. Тако
вот ограничение непрерывной интеграции.

Если построение выполняется правильно, но ошибки есть в коде — та же ситуация. Задач
не считается выполненной, пока не выполнены все проверки и не проведена успешная интеграци
(как слияние в dev, так и развертывание на боевом окружении). 

4. Пишите автоматизированные проверки разработки

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

Мануальные проверки тоже можно автоматизировать в части управления. Если какая-т
часть системы требует ручного тестирования, возможным решением будет при запуске автоматизированног
построения создавать задачу на ручное — либо в системе управления тестированием, либ
в трекере задач.

Отчет в системе управления тестированием выглядит примерно так  (это testrail):



Автоматизированные проверки — это не только функциональные тесты в каком-нибудь xUni
и не обязательно каждая проверка отвечает на вопрос "да/нет". Можно автоматизироват
и производить:


Построение под все платформы, для которых вы производите свой продукт. Включает 
себя создание установочных пакетов и их успешную установку через стандартные механизм
распространения (Google Play, .msi/.exe, репозиторий с deb-пакетами, скрипт для развертывани
сайта...)  
Создание и проверку резервных копий. Ага, бэкапы нужно проверять. Бывают битые бэкапы
бывает что система дает сбой и перестает делать бэкапы.
Нагрузочное тестирование, если у вас сайт или сервис с API. Полученную статистик
нужно как-то анализировать. Можно встраивать проверки на соответствие SLA.


5. Все проверки и инспекции должны быть пройдены

Это можно понять двумя способами:


Акцент на слово «пройдены». Достаточно очевидное правило — если тесты не проходят
значит код ошибочный (или сломались тесты). 
Акцент на слово «все». Может так случиться, что разработчик просто закомментируе
тест, который не проходит, если обнаруживаемую ошибку он пока что не собирается править.


Страховкой от таких ситуаций служат инструменты оценки покрытия кода. Оценка покрыти
должна быть обязательным этапом автоматизированного построения. Тогда можно будет увидеть
что, например, все тесты проходят, но покрытие уменьшилось либо просто недостаточное.

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

6. Выполняйте закрытое построение

Под закрытым понимается интеграционное построение для целей тестирования. Автор
книги имеют в виду построение на своей рабочей машине, но нередко используется специально
тестовое окружение. Например, если вы пишете клиент-серверное приложение, то можно использоват
специально выделенный сервер, на котором развертывается тестируемая версия.

В идеале построение производится на каждый коммит разработчика (а коммиты происходя
часто). Это реализуется за счет связи между системой контроля версий и системой непрерывно
интеграции (например, Jenkins или TeamCity). При обнаружении новой версии в вашей рабоче
ветке система должна автоматически запускать построение (в это входит и компиляция и
когда необходимо, развертывание на тестовом контуре), следом за которым идут различны
тесты. 

Сервер непрерывной интеграции должен быть достаточно мощным, чтобы отрабатывать компиляци
хотя бы не медленнее, чем на собственной машине разработчика. Некоторые задачи в принцип
нереализуемы на рабочей машине, например нагрузочное тестирование через WiFi тестируе
только сам WiFi. Это также снимает распространенную проблему, когда код компилируетс
очень долго, а разработчик уходит гулять/есть/спать/домой.

7. Избегайте получения сбойного кода

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

Не используйте сбойный код даже если он общается с вашим кодом через какой-то интерфейс
Может оказаться, что вы написали какую-то заплатку для компенсации ошибки на той стороне
Потом ошибка будет исправлена и придется вырезать заплатку.

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


Ответ 3

Непрерывная интеграция подразумевает только сборку билдов. Мержи она никак не оговаривает.

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


Ваши разработчики редко вливают изменения из develop в feature branch-и. 
Т.е. вы не решаете мерж-конфликты между двумя ветками по мере их появления, а откладывает
"на потом". 
Вот это "потом" и вылазит при попытке смержить. Не обязательно физически мержит
изменения - git rerere умеет записывать результаты мержа без коммита.
Вы заводите ветки не по фичам, а по людям. У вас три девелопера, и они одновременн
пишут три фичи? Сконцентрируйтесь на одной. Работа двух девелоперов на одной ветке 
это нормально!
Вы используете относительно тяжеловесный процесс (git flow) на небольшом проект
(вас всего трое). Возможно, вам стоит посмотреть в сторону GitHub Flow. Пуллреквест
на github сильно облегчат вам жизнь - тем, что в них есть явный индикатор немержабельност
веток. И кроме того, TeamCity умеет собирать чек-билды на merge-ветках - результата
автомержа - так что вы будете видеть реальную картину.


Дополнение из комментариев:

GitHub, и как и многие  остальные системы с поддержкой PR, не просто проверяют возможност
автомержа. Они реально проводят мерж, и создают новый head с именем вида merge/номер_pr
TeamСity подхватывает его и запускает билд. Т.е. проверяется


возможен ли мерж вообще
пройдут ли тесты если вы смержите (до того, как вы действительно смержили)


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

Основная идея непрерывной интеграции - это действительно непрерывная автоматическа
интеграция. Если у вас TeamCity используется только ради проверки ручного мержа - т
он вам не нужен. Он просто экономит вам одно нажатие кнопки раз в пару дней. 

Билды надо собирать на каждый коммит (коммитать и пушить часто и по чуть-чуть - в
же все равно в отдельный бранчах работаете) и на каждый потенциальный мерж - т.е. действительн
непрерывно.


Ответ 4

В похожей ситуации гугление подсказало: она возникает из-за того, что технически
средства — а именно git — не заменяют организации совместной работы.

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

Это может также свидетельствовать, что проект в самом начале, и идёт шлифовка то
части, которая называется ядром.

Соответственно, вариантами решений будут:


Обсуждение и утверждение регламента совместной разработки (кто и что, когда и ка
может менять).
Рефакторинг ядра — разбиение его не более мелкие независимые классы.
Аккуратное распределение работ между участниками команды.


Сервер непрерывной интеграции не решает проблему слияний. Слияния это специфика Mercurial/Git
распределённых систем версионирования. Сервер непрерывной интеграции позволяет контролироват
появление проблем интеграции, которые могут возникнуть и в CVS, и в SVN, и даже пр
обмене файлами на дискетах.


Ответ 5

Постараюсь ответить на ваш вопрос
Хочу услышать как в ваших проектах организована работа с сервером непрерывной интеграции
Как вы бы организовали нашу работу исходя из текущих условий?

Вот список используемого софта (за исключением студий для разработок) Выбор SVN ил
GIT не критичен, это дело вкуса. Данный пример реализован у нас на предприятии.

TortoiseSVN — это бесплатный Windows-клиент с открытыми исходным кодом для систем
управления версиями Apache™ Subversion®. 
Статус каждого версированного файла и папки отображается при помощи маленькой пометк
поверх основного значка. Таким образом, вы сразу можете видеть состояние вашей рабоче
копии. CVS отслеживает только историю отдельных файлов, тогда как Subversion реализуе
«виртуальную» версионную файловую систему, которая отслеживает изменения в целых деревья
папок во времени. 

Redmine — открытое серверное веб-приложение для управления проектами и задачами (
том числе для отслеживания ошибок). Redmine написан на Ruby и представляет собой приложени
на основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласн
GNU General Public License.
Данный продукт предоставляет следующие возможности:


ведение нескольких проектов;
гибкая система доступа, основанная на ролях;
система отслеживания ошибок;
диаграммы Ганта и календарь;
ведение новостей проекта, документов и управление файлами;
оповещение об изменениях с помощью RSS-потоков и электронной почты;
вики для каждого проекта;
форумы для каждого проекта;
учёт временных затрат;
настраиваемые произвольные поля для инцидентов, временных затрат, проектов и пользователей;
лёгкая интеграция с системами управления версиями (SVN, CVS, Git, Mercurial, Bazaa
и Darcs);
создание записей об ошибках на основе полученных писем;
поддержка множественной аутентификации LDAP;
возможность самостоятельной регистрации новых пользователей;
многоязычный интерфейс (в том числе русский);
поддержка СУБД MySQL, PostgreSQL, SQLite, Oracle.


Jenkins.

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

Инструмент непрерывной интеграции. Запускается в контейнере сервлетов (расширяе
функциональные возможности сервера), таких как Apache Tomcat или GlassFish. Поддерживае
инструментарий для работы с разными системами контроля версий, в нашем случае Subversion
может собирать проекты, а также исполнять shell-скрипты и команды Windows. Автономна
сборка проектов на сервере Jenkins может быть назначена на разные события, например
производиться по расписанию, либо стартовать, когда другая сборка уже собрана, либ
при запросе определённого URL, выкачивая перед этим все обновления из svn, и собира
их на всех операционных системах автономно.

Плюсы использования Jenkins:


Когда кто-то ломает проект, вы узнаете об этом сразу, что позволяет
быстро устранить проблему;
Вы можете автоматизировать прогон тестов, развертывать приложения на
тестовых серверах, выполнять проверку code style и тому подобные
вещи;
Также в Jenkins можно хранить собранные deb-пакеты, отчеты о прогоне
тестов или Javadoc/Doxygen/EDoc-документацию;


Данное решение, которое я вам предложу настроено приблизительно на 15-20 программистов
Все программисты соблюдают одно простое правило. "Перед коммитом скачай Update, провер
совместимость с твоими изменениями и вливай." Так как проект большой. Сделано всег
две ветки.

1) Первая. В нее вливаются все изменения разработчиков. И каждый божий  день Jenkin
непрерывно ее интегрирует. В случае если-что, то пошло не так, то он отправляет уведомлени
тому, кто поломал сборку. Сборка к стати производиться на множество ОС.

2) Тестовая. Как правило каждую неделю она мержится с первой. А в течении недел
производит сборки под разные ОС. Тестировщики ее пытаются нагнуть.

3) За редким исключением выделяется отдельная ветка для разработчика. Это делаетс
в случае, если он начинает вносить серьезные изменения в ядро или библиотеку общег
пользования. После того, как ему удастся смержить две ветки, он получает разрешени
на коммит.


Ответ 6

Википедия считает так:


  Непрерывная интеграция (CI, англ. Continuous Integration) — это практика разработк
программного обеспечения, которая заключается в выполнении частых автоматизированны
сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычно
проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграци
является заключительной. Она может непредсказуемо задержать окончание работ. Перехо
к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её боле
предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.


Короче говоря, это выход обновлений по расписанию. Причём достаточно часто и автоматизированн
(например, через Makefile)

Как правильно отправить релиз на git?

Я использую гит для своего проекта, работаю один.

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

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

Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер... 

Вопрос вот в чем, будет ли правильно сделать коммит на локальной ветке девелоп 
поставить на нее таг, слить в удаленный девелоп и уже удаленный девелоп смержить с удаленны
мастером...

Я просто не уверен, что эта концепция правильная и второе я не уверен, что можн
делать мерж на удаленых ветках...

Посоветуйте как правильно сделать?
    

Ответы

Ответ 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 вполн
подойдёт.

Как правильно отправить релиз на git?

Я использую гит для своего проекта, работаю один.
И вот готов у меня релиз первой версии, я следую совету этой статье на хабре и тут описано, что нужно создать ветку релиза и как она будет доведена до выпуска то слить ее в мастер и в девелоп, после чего удалить ее...
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово... Я так понимаю, что мне нужно ее сливать в мастер сразу и помечать тегом и продолжать дальше вести проект в дефелопе.
Но у меня локально есть только ветка девелоп и удалено есть девелоп и мастер...
Вопрос вот в чем, будет ли правильно сделать коммит на локальной ветке девелоп , поставить на нее таг, слить в удаленный девелоп и уже удаленный девелоп смержить с удаленным мастером...
Я просто не уверен, что эта концепция правильная и второе я не уверен, что можно делать мерж на удаленых ветках...
Посоветуйте как правильно сделать?

Ответ

Сначала немного теории, чтобы обосновать практические рекомендации. Надеюсь, заскучать не успеете.
Что вообще происходит и откуда взялись ветки develop и release
Указанная вами статья – про модель рабочего процесса под названием git flow. Это в целом хорошая модель. Она была придумана, чтобы упорядочить бардак и анархию при совместной работе над кодом в больших проектах, и именно в них она эффективна. Если у вас сто человек работает над одним приложением, если вы вынуждены поддерживать старые версии (исправлять баги и критические уязвимости), если в день делаются сотни коммитов — берите, не пожалеете.
А для команд, которые
немногочисленны, примерно до 10 человек; работают по agile и дробят задачи настолько, чтобы они делались за день-два; используют в основном самую последнюю версию продукта и не должны тащить старые версии;
... git flow попросту не нужен. Он создаёт больше проблем, чем решает.
Как сделать проще
Но зачем мне создавать ветку релиза если у меня в ветке девелоп уже все готово
Правильно! Вам и девелоп-то не нужен.
Для небольших команд и соло-разработки больше подходят «легковесные» модели организации рабочего процесса. Самая популярная называется GitHub Flow, от неё отличаются некоторыми деталями и бóльшей глубиной проработки GitLab Flow и Simple Git Flow (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 и не вспоминать о ней до поры.