Вы ищете техническое решение человеческой проблемы. Это редко работает.
Вот несколько подходов, которые я или использовал в прошлом, или имел в виду, фактически не имея возможности использовать их на практике. Некоторые могут не относиться к вашему делу, в зависимости от занимаемой вами должности в команде (если вы возглавляете команду с отличной репутацией, скорее всего, у вас будет лучшая возможность отстаивать свою точку зрения, чем если вы студент, который только что присоединился к команде на время вашей стажировки).
Обсудите эту проблему со своими коллегами и объясните последствия крупных коммитов. Может быть, они просто не понимают, что сложные слияния являются прямым следствием редких коммитов, а небольшие частые коммиты сделают слияния (относительно) легкими.
Я знал многих программистов, которые были просто убеждены, что слияния всегда сложны. Они выполняли не более одного коммита в день, избегая использования мощных инструментов, таких как diff и auto-merge в Visual Studio, и имели плохую практику ручного слияния (если только «Take mine» без дальнейшей проверки diff на самом деле является хорошей практикой). Для них это не имеет ничего общего с ними , и был присущ характер слияния.
Приведите конкретные примеры того, что происходит в других компаниях (особенно тех, к которым ваши коллеги относятся с большим уважением). Они могут просто не знать, что это проблема, и быть уверенными, что каждая команда делает максимум один коммит в день.
Некоторые люди не знают, что есть команды из 5-10 участников, которые производят до 50 толчков в производство, что в среднем составляет 5-10 коммитов в день на человека. Они могут не понять ни как это возможно, ни почему кто-то это сделает.
Подавать пример. Делай достаточно мало, возьми себя в руки. Если возможно, сделайте короткую презентацию, показывающую их и ваши слияния бок о бок в течение недели (я не уверен, легко ли извлечь такую информацию из системы контроля версий). Подчеркните возможные ошибки, которые они совершили во время слияния, и сравните их с количеством ошибок, которые вы сделали (которые должны быть близки к нулю).
Используйте «Я сказал вам» технику, когда это необходимо . Когда вы видите, что ваши коллеги страдают от болезненного слияния, громко комментируйте, что небольшие частые коммиты могут сделать слияния (относительно) безболезненными.
Объясните, что для совершения коммита не существует минимальной продолжительности. Коммит может даже соответствовать незначительным изменениям, сделанным за несколько секунд. Переименование файла, удаление устаревшего комментария, исправление опечатки - все это задачи, которые можно выполнить немедленно.
Программисты не должны бояться делать крошечные коммиты, а скорее объединять множество изменений в один огромный коммит.
При необходимости работайте с людьми, а не с командой. Если есть человек, который особенно отказывается делать частые, небольшие коммиты, поговорите с этим человеком индивидуально, чтобы понять, почему он отказывается от него.
Они могут дать совершенно веские причины, которые могут дать вам подсказку о том, что происходит с командой. Несколько причин, которые я слышал сам:
«Мой учитель / наставник сказал мне, что лучше всего делать один коммит в день». Меня это не удивляет, учитывая то , что я слышал от своих учителей в колледже .
«Мои коллеги сказали мне, что я должен делать меньше коммитов». Мне тоже говорили об этом в некоторых командах, и я понимаю их точку зрения. У нас был журнал, который был практически заполнен моими коммитами (это не сложно сделать, когда четыре товарища по команде даже не делают один коммит в день), что расстроило моих коллег.
«Я думал, что небольшие коммиты затрудняют нахождение ревизии». Как-то верный момент, даже когда команда прилагает усилия для написания описательных сообщений журнала.
«Я не хочу тратить слишком много места на нашем сервере контроля версий». Человек, очевидно, не понимает, как хранятся коммиты (и как дешево это место для хранения).
«Я думаю, что коммит должен соответствовать конкретной задаче». Учитывая, что часто задача соответствует некоторой работе, выполняемой за один день (например, на досках задач визуального управления), это не совпадение. Затем человек должен научиться определять разницу между заданием в отставании (от 2 до 8 часов работы) и логически изолированным изменением, которое должно быть совершено (от нескольких секунд до нескольких часов работы). Это также связано с пунктом 5.
Ищите причину, по которой команда не выполняет коммиты чаще. Вы можете быть удивлены результатами.
Недавно в другом ответе я упомянул, что скорость фиксации имеет значение, и даже сотни миллисекунд могут подтолкнуть разработчиков к фиксации с меньшей частотой.
Другие причины могут включать в себя:
Слишком сложные правила для написания сообщения коммита.
Правило, которое заставляет разработчика связывать коммит с задачей из системы отслеживания ошибок.
Страх сломать сборку.
Нежелание иметь дело с риском сломать сборку прямо сейчас: если вы делаете коммит вечером в пятницу перед самым отъездом, вы можете отложить работу со сломанной сборкой до понедельника.
Страх перед слиянием.
Определите, понимают ли разработчики, что есть и другие преимущества для частого принятия . Например, платформа Continuous Integration является огромным стимулом для частых коммитов , поскольку она позволяет точно определить, где была введена регрессия .
Я предпочел бы, чтобы платформа CI говорила мне, что я сломал сборку в ревизии 5023, которая состоит из изменения двух методов в одном файле, который я сделал пятнадцать минут назад, а не в ревизии 5023, состоящей из изменений, которые охватывают четыре дюжины файлов и представляют 13 часов работы.