Мы у себя в проекте (используем Jira) пишем комментарии к коммитам так: "-: "
За 5 лет ни раз не испытывали неудоств и даже это многократно помогало, например, когда нужно было по blame скрипта определить каким коммитом вносились изменения в конкретные строки и по тайтлу коммита было легко определить из какого таска эти изменения пришли.

xotey83 8 июл 2016 в 16:25

Извините, хабрапарсер съел теги. Комментарии к коммитам: "<task_id> : <commit_title>"

НЛО прилетело и опубликовало эту надпись здесь

crocodile2u 8 июл 2016 в 17:03

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

НЛО прилетело и опубликовало эту надпись здесь

xotey83 8 июл 2016 в 19:06

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

НЛО прилетело и опубликовало эту надпись здесь

Apathetic 9 июл 2016 в 20:21

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

Scf 8 июл 2016 в 12:59

Восьмой совет должен быть нулевым. Итак:

(0) Общайтесь, общайтесь, общайтесь! В больших компаниях безумно важен т.н. "нетворкинг" и его применение может поднять вашу эффективность в разы. Знание проектов, сопряженных с вашими, и людей, которые в них работают, позволяет принимать более качественные решения в своем проекте. Иметь знакомых, которым можно задать вопрос по предметной области, попросить поделиться опытом работы с какой-либо технологией или третьей командой — бесценно. У других команд могут быть наработки, которые не грех и перенять.

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

Timeless 8 июл 2016 в 14:22

Абсолютно верно, еще добавлю что очень полезно (особенно с удаленными коллегами) выстраивать личные (но без фанатизма :) ) отношения.

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

В терминах РПГ — в диалогах появляются дополнительные опции :) Которые ускоряют/упрощают получение ресурсов и дают более реальную информацию о положении вещей

sshikov 8 июл 2016 в 19:31

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

miraage 8 июл 2016 в 14:09

Мы недавно ввели практику делать пулл с флагом --rebase, чтобы избежать мердж коммитов.
А feature/hotfix ветки вливаем с --no-ff.

defuz 8 июл 2016 в 14:15

Мне одно не понятно: неужели все эти советы становятся актуальными только после «50 проектов в solution’е»? Или может это такая специфика энтерпрайза: бить проект на 50 подпроектов по 1000 строк в каждом?

marshinov 8 июл 2016 в 14:23

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

Shamov 8 июл 2016 в 16:54

Не совсем так. Если бы так поступали все и всегда, то было бы плохо. Многие из этих советов полезны для больших проектов и вредны для небольших. Обычно команда из трёх человек эффективна именно потому, что в ней бардак. Если навести в ней порядок, то её эффективность упадёт в разы. Ведь на поддержание порядка расходуется организационный ресурс, которого в небольшой команде вырабатывается очень мало. Чтобы в команде вырабатывалось много организационного ресурса, в ней должно быть много менеджеров, которые только тем и занимаются, что непрерывно согласуют что-нибудь друг с другом, планируют последовательность действий, разрабатывают формальные подходы для непонятных ситуаций и т.д. А если в команде из трёх человек будет два менеджера, то скорость разработки скорее всего будет ниже приемлемого уровня. Энтерпрайз же может себе позволить иметь 200 менеджеров на каждые 100 разработчиков. Эти 100 разработчиков успевают разрабатывать то, что приносит столько денег, что их хватает всем.

marshinov 8 июл 2016 в 19:13

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

Shamov 8 июл 2016 в 21:35

Естественно. Гит и микропланирование в рамках одного дня — это мастхэв при любом раскладе. Даже при работе в соло-режиме.

spamas 8 июл 2016 в 16:31

Эффективность энтерпрайз проекта на мой взгляд, прежде всего напрямую зависит от правильной иерархии и насколько хорошо каждый участник понимает своё в ней место.
Как показал мой опыт, имеет место именно незнание и часто нежелание думать сверх своих поставленных задач. «Я закомитил, моя хата с краю», «мы не можем сделать деплой, потому что другая команда сделала свою часть не так, как мы предполагали», «мы уже закончили свою часть, а они даже не начинали!» — это наиболее распространенные ответы которые мне приходилось слышать при авральных ситуациях.
Прежде всего надо строго определить рамки ответственности каждой команды в проекте, а также глобальных feature leads, ведущих инженеров которые будут отвечать за области(features) в продукте и не будут привязаны ни к одной из команд. Нужно это для того, чтобы команды имели арбитражную сторону к которой можно обратиться за разъяснениями и инструкциями «как всё должно быть на самом деле» в конкретной фиче.

Ivan22 11 июл 2016 в 11:02

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий