LINUX.ORG.RU

Стратегия использования feature branches совместно с долгоживущей dev бранчей

 , ,


0

2

Дано: в master должен попадать только готовый функционал.

Разработка ведется в dev бранче, периодически ведется двухсторонний обмен коммитами между ними (rebase из master-а в сторону dev и merge из dev в master).

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

Возникли проблемы при реализации очень «долгой» фичи, которая предусматривает еще и несколько вариантов имлементации.

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

Ясно, что нужно использовать несколько долгоживущие feature бранчи, ответвеленные от dev.

Предложение «сеньора» использовать stash (карманы) считаю в этом случае не очень хорошим.

Как мне дальше поступить?

Перемещено leave из general

Какая-то надуманная проблема. Создаешь свой бранч и время от времени делаешь rebase на dev бранч, фикся конфликты и тд ... И потом, когда твоя фича готова, делаешь рулл реквест в dev, и делов-то.

joy4eg ★★★★★
()
Ответ на: комментарий от joy4eg

Создаешь свой один feature бранч как форк от dev, где реализуется первый вариант.

Одновременно от того же самого состояния dev-а создается второй feature-branch со второй реализацией, которая вбудет позже имплементирована).

ОК?

EnterpriseMobility
() автор топика
Ответ на: комментарий от EnterpriseMobility

На основании статьи на хабре я понял, что нужно обязательно делать feature-бранчи.

Я создал две feature ветки на основании одного и того же состояния dev-ветки.

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

В другой feature-ветке я удалил изменения, внесенные ранее (подготовил к опрощенной реализации), закоммитил изменения и перенес измения в dev мержом.

Тем же мержом нужно в мастер

ОК?

EnterpriseMobility
() автор топика

чтобы обмен коммитами продолжал бы фунционировать.

Оно что, по графику что-ли?

Далаешь feature branch на кажюдую фича и раз в пару недель(или когда там надо) ребейзишь на голову dev.

И да, worktree облегчает жизнь ;)

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)

stash это больше приватная (точнее локальная) штука - типа стэка

anonymous
()
Ответ на: комментарий от EnterpriseMobility

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

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от EnterpriseMobility

Одновременно от того же самого состояния dev-а создается второй feature-branch со второй реализацией, которая вбудет позже имплементирована

Зачем? Когда соберешься реализовывать второй вариант, тогда и отбранчуешься от актуального состояния

annulen ★★★★★
()

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

Схуяле? Сделал-смёржил, какой еще блин обмен коммитами с разломанной веткой?

Ясно, что нужно использовать несколько долгоживущие feature бранчи, ответвеленные от dev.

Да насрать сколько он живёт, в мастер идёт только то, что до конца реализовано, оттестировано и зааппрувлено. «Обмен коммитами» оставь свингерам-экстрималам, feature ветку можно синкать с мастером, мастер с ней - нельзя до завершения фичи

anonymous
()
Ответ на: комментарий от anonymous

feature ветку можно синкать с мастером, мастер с ней - нельзя до завершения фичи

ППКС. а теперь внимание вопрос: а долбоеб, что, эти две feature веткуи от своего dev-а фокрнул, а не от мастера?

Ну в смысле не так понял бабро-хабру?

Варианты ответов:

1) Да, я лох

2) Нет, не лох

3) А не пох?

EnterpriseMobility
() автор топика
Ответ на: комментарий от EnterpriseMobility

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

ilammy ★★★
()
Ответ на: комментарий от EnterpriseMobility

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

anonymous
()
Ответ на: комментарий от EnterpriseMobility

Implying CTO что-то мешает быть шизофреником или идиотом. Тебя же вот наняли явно не без его участия

anonymous
()
Ответ на: комментарий от anonymous

спасибо, о великий Git эксперт! На каких курсах тебя готовили? GoIT?

EnterpriseMobility
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.