Даже после нескольких лет работы с git я до сих пор иногда испытываю благоговейный трепет перед его возможностями. Возможность для разработчиков одновременно работать над разными частями одного и того же проекта с помощью веток потрясающая. Хотя эти ветки могут помочь повысить производительность, обеспечивая одновременный прогресс, они также могут привести к напрасной трате времени и размышлений, если используются без надлежащих соглашений об именах.
Если вы думали, что переменные были единственными элементами, которые вызывали проблемы при неправильном названии, просто попробуйте поработать с командой из 10 разработчиков, которые используют разные соглашения об именах для создания веток функций. Это может сделать поиск ветки в лучшем случае рутиной, а в худшем - головной болью. Ключ к хорошему именованию веток — говорить ровно столько, сколько вам нужно. В этой статье я расскажу вам о некоторых передовых методах и стратегиях написания целенаправленных и информативных имен веток git.
Прежде чем мы перейдем к тому, как выглядит хорошее имя, я приведу пример моего любимого соглашения:
Начнем с цели
Первое, о чем будут заботиться разработчики при работе над нашим обзором вашего кода, — это цель ветки. Что вы пытаетесь сделать с этим. Является ли эта ветка полноценной функцией или исправлением серьезной производственной ошибки? Это ветка, которая фокусируется на создании или поддержке тестов? Какова цель, очень важно и должно быть в начале имени вашей ветки.
В какой вы команде?
Если в вашей компании много отдельных проектов или отделов разработки, важно добавить еще один флаг, чтобы упростить фильтрацию между командами. Если вы работаете в магазине, а ваш друг занимается выставлением счетов, то имеет смысл добавить «ecomm» к вашим билетам, и они могут добавить «счет» к своим. Это помогает дифференцировать билеты и поможет сохранить разумные и упорядоченные номера билетов.
Всегда указывайте номера выпусков
Ваши билеты, вероятно, имеют номера, и названия ваших филиалов тоже должны быть! Да, легко связать тикеты Asana или Jira с вашего PR, но было бы неплохо иметь номер тикета и в названии вашего филиала? Не забудьте указать этот номер, чтобы помочь пользователям легко находить ветки, которые они должны просмотреть, добавить или от которых нужно отказаться!
Использование дефисов, косых черт и подчеркиваний
Еще одно соглашение, которое упростит понимание ваших ветвей, — это использование дефисов и косых черт. Конечно, вы можете отделить каждое слово или набор чисел дефисом, более надежный шаблон дефисов, косых черт и подчеркиваний сделает ваши ветки еще более удобными для чтения. Примером неправильного использования этого является «feature-claims-45-fix-dead-link». Хотя вся необходимая информация есть, читать ее не так просто. Вместо этого мы могли бы использовать что-то вроде «feature/claims-45_add-policy-comparison». Этот шаблон дает понять другим разработчикам, что ветвь — это функция для отдела претензий вашего бизнеса, это 45-й билет для этого бизнеса, и цель состоит в том, чтобы добавить сравнение политик. Намного лучше!
Будьте краткими
Хотя заманчиво написать очень описательную цель для каждой из ваших ветвей, чем короче, тем лучше. Хотя может потребоваться дополнительный контекст, если вы уже включили идентификатор проблемы или заявки, то нет необходимости вводить роман.
Называть или не называть
Некоторые компании выступают за добавление имени автора к названию филиала. Я не рекомендую это по двум причинам. Во-первых, если вы используете Github, то должно быть достаточно просто использовать пользовательский интерфейс для фильтрации заявок определенных разработчиков. Эта фильтрация и поиск упрощают учет с помощью других средств, помимо именования.
Во-вторых, префикс всех ветвей с чьим-то именем нарушает согласованные соглашения об именах. Если вы начнете с имени, то пользователям придется сканировать, чтобы определить, является ли ветвь исправлением, функцией, тестом или чем-то еще. Наряду с этим более длинные имена быстро загромождают билет и лишают лаконичности чистого именования.
Если у вас нет очень веской причины, я бы воздержался от добавления имен разработчиков в ваши ветки. Чем меньше, тем лучше при улучшении удобочитаемости и влиянии именования на вашу ветку.
Заключительные мысли
Проверка кода никогда не должна быть рутиной. Из-за этого важно сделать ваши имена веток git как можно более легко читаемыми. Дайте мне знать в комментариях, если вы и ваша команда используете другие соглашения для именования веток!
Примечания
https://codingsight.com/git-branching-naming-convention-best-practices/
