ES
Их нелогично связывать, если это разные сервисы.
Size: a a a
2017 September 13
A
А почему гит не должен быть завязан на трекере задач, если GitLab его предоставляет?
а если вдруг в bitbucket вздумается переехать?
ES
а если вдруг в bitbucket вздумается переехать?
очень странно писать клиент для GitLab и не использовать его функционал...
KT
гит и гитлаб - разные вещи
A
гит и гитлаб - разные вещи
+
KT
проставлять у каждого коммита отсылки на задачу - не нужно
KT
если надо в сообщении коммита указать почему-то то ок, но не как правило
ES
проставлять у каждого коммита отсылки на задачу - не нужно
я так понимаю, что и ветки тоже?
KT
ES
окей
AK
но в задаче на которую есть остылка есть проблема
AK
или ещё другая инфа
AK
а погодите
AK
это канал не тот
AK
тут это правило частное
KT
обычно ветка называется по решаемой проблеме, а в сообщениях коммитов уже идет объяснение сделанных изменений в коде
IG
@terrakok что-то я начал исправлять MR и впал в ступор. Вроде как в дальнейшем нужно же создавать MR той же самой ветки? Или не обязательно? Потому что если да, то это получается мне нужно держать две ветки: одну в которой я всё выполнил, и вторую только для MR. И переключать её на нужный коммит из первой ветки каждый раз когда вы посмотрите MR :D
KT
есть пустая ветка ФИЧА
вы от нее создаете ветку ШАГ_1, делаете первый шаг и создаете МР_1 в ФИЧА
пока я его не принял, вы от ветки ШАГ_1 создаете ШАГ_2 и делаете следующий шаг
тем временем я отклонил МР_1, вы возвращаетесь к ШАГ_1, исправляете и обновляете МР_1.
после этого, пока я смотрю МР_1, вы втягиваете изменения из ШАГ_1 в ШАГ_2 и продолжаете
и так далее
вы от нее создаете ветку ШАГ_1, делаете первый шаг и создаете МР_1 в ФИЧА
пока я его не принял, вы от ветки ШАГ_1 создаете ШАГ_2 и делаете следующий шаг
тем временем я отклонил МР_1, вы возвращаетесь к ШАГ_1, исправляете и обновляете МР_1.
после этого, пока я смотрю МР_1, вы втягиваете изменения из ШАГ_1 в ШАГ_2 и продолжаете
и так далее
KT
это стандартный гитфлоу
IG
Понял. Логично, туплю