Size: a a a

2020 February 07

GG

George Gaál in DevOps
Хочешь - пуш коммит с описанием джира тикета, который он решает, прямо в девелоп
источник

D

Denis 災 nobody in DevOps
это как с тикетами, "давайте сделать 1 тикет где будем решать все задачи", Ничего кроме хаоса и бардака это не даст.
источник

N

Navern in DevOps
Надо не ветки переставлять...)
источник

D

Denis 災 nobody in DevOps
Alexander
В тимлиде :D
он как раз нормальный похоже
источник

ЕО

Евгений Омельченко in DevOps
Denis 災 nobody
это как с тикетами, "давайте сделать 1 тикет где будем решать все задачи", Ничего кроме хаоса и бардака это не даст.
+
источник

A

Alexander in DevOps
Denis 災 nobody
он как раз нормальный похоже
Если у них корень проблемы в постановке задач исполнителям, то таки в нем.
источник

BG

Bogdan (SirEdvin) Gladyshev in DevOps
Plomipu Dmitri
Я не спрашивал зачем нужны отдельные ветки и чем это лучше. Я это итак прекрасно знаю. Но вы упускаете другой подводный камень. Если веток слишком много и мы не успеваем все ветки замерджить, закрывать и потом и вовсе удалять, то потом возникает такие путаницы, кто что делал и возникает такой клубок из спутавшихся ниток. Поэтому я и говорю, что иногда ветку можно делать обобщённой для ряда коммитов, если фичи делаются для одной и той же проблемы.
А потом одна из мелких задач внезапно зависает в воздухе и остальные мелкие задачи ей заблокированы. Ну или сидишь черипикаешь
источник

BG

Bogdan (SirEdvin) Gladyshev in DevOps
Или же все эти мелкие задачи оказываются невлитыми
источник

BG

Bogdan (SirEdvin) Gladyshev in DevOps
Это реальные кейсы с работы, если что :(
источник

D

Denis 災 nobody in DevOps
Alexander
Если у них корень проблемы в постановке задач исполнителям, то таки в нем.
я пока вижу "мне лень делать git branch -b", хотя кто знает что там творится
источник

PD

Plomipu Dmitri in DevOps
я не возникаю. Но то что много веток (больше 20 штук - за неделю ) - это больше - чем +. Книжка официальна по гиту и то говорит, что это плохая практика в разработке, когда их не просто много, а СЛИШКОМ МНОГО.
источник

D

Denis 災 nobody in DevOps
20 штук и в день это норма
источник

A

Alexander in DevOps
Bogdan (SirEdvin) Gladyshev
А потом одна из мелких задач внезапно зависает в воздухе и остальные мелкие задачи ей заблокированы. Ну или сидишь черипикаешь
Значит она не мелкая и ее нужно разбить на подзадачи. Или она мелкая, но заблокирована по внешним причинам (но зачем тогда черрипикать?)
источник

PD

Plomipu Dmitri in DevOps
тяжелее сопровождать проект
источник

D

Denis 災 nobody in DevOps
но должно хватать тех, кто их обрабатывает, принимает и удаляет
источник

BG

Bogdan (SirEdvin) Gladyshev in DevOps
Alexander
Значит она не мелкая и ее нужно разбить на подзадачи. Или она мелкая, но заблокирована по внешним причинам (но зачем тогда черрипикать?)
Ну, она мелкая, но заблокирована по внешним причинам. А в этом ветке еще 5 мелких задач. Тут или оно зависает, или черипикать, разве нет?
источник

A

Alexander in DevOps
Plomipu Dmitri
я не возникаю. Но то что много веток (больше 20 штук - за неделю ) - это больше - чем +. Книжка официальна по гиту и то говорит, что это плохая практика в разработке, когда их не просто много, а СЛИШКОМ МНОГО.
Плохая практика, когда много одновременно открытых веток. Сколько у вас народу в команде?
источник

A

Alexander in DevOps
Bogdan (SirEdvin) Gladyshev
Ну, она мелкая, но заблокирована по внешним причинам. А в этом ветке еще 5 мелких задач. Тут или оно зависает, или черипикать, разве нет?
Зачем ты несколько задач суешь в одну ветку? Взял таск - открыл ветку
источник

D

Denis 災 nobody in DevOps
Plomipu Dmitri
я не возникаю. Но то что много веток (больше 20 штук - за неделю ) - это больше - чем +. Книжка официальна по гиту и то говорит, что это плохая практика в разработке, когда их не просто много, а СЛИШКОМ МНОГО.
там же должно быть описано, что в их понимании "слишком". Каждую строку кода в свой бранч - да. Должно быть целостной задачей. А то что задач может быть 20 в день - это может быть норма и больше от организации процессов зависит.
источник

BG

Bogdan (SirEdvin) Gladyshev in DevOps
Прочитайте комментарий, на который я ответил :(
источник