Лучшие практики работы с Git

Git - это, по большому счету, самая распространенная система контроля версий на планете. С помощью этого инструмента разработчикам стало гораздо проще сотрудничать и эффективнее работать. Git упрощает отслеживание изменений кода, обеспечивает скорость, целостность данных и поддержку распределенных нелинейных рабочих процессов. 
\r\nОдним словом, git берет то, что в противном случае могло бы стать хаосом в жизни разработчика, и структурирует это таким образом, чтобы проектом было легче управлять и эффективнее его реализовывать.
\r\nЕсли вы и ваша команда только начинаете использовать git, то вы будете в восторге. А если вы уже давно используете git, то, возможно, вам приходилось работать с командой, которая не совсем эффективно использует этот инструмент. Независимо от того, на каком этапе своего пути вы находитесь в git, существуют лучшие практики, которые следует применять на каждом шагу. Следуя этим советам, вы не только значительно улучшите свой опыт работы с git, но и сделаете совместную работу более гладкой и эффективной.

Давайте рассмотрим некоторые из этих лучших практик. Они будут применимы независимо от языка, на котором вы используете Git. Поэтому независимо от того, являетесь ли вы разработчиком Java, JavaScript, .NET, C++, Ruby, Python или PHP, работаете ли вы в одиночку или в команде корпоративного уровня, эти лучшие практики будут применимы.

Одноцелевые фиксации

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

\r\n\t
• Повышает эффективность проверки кода.
\r\n\t
• Упрощает откат кода к предыдущему состоянию.
\r\n\t
• Отслеживает изменения в системе тикетов.
\r\n\t
• Упрощает просмотр журнала git.
\r\n

Писать информативные сообщения о фиксации

Очень важной особенностью коммитов является добавление к ним сообщений. Эти сообщения носят информативный характер, чтобы ваша команда имела четкое представление о том, что вы сделали в рамках фиксации. Если вы просто добавите общее или бессмысленное сообщение о фиксации, вы не окажете команде никакой пользы.
\r\nКогда вы создаете фиксацию, обязательно добавляйте информативное сообщение, которое четко указывает, какую работу вы выполнили. Оно должно быть кратким, но в то же время содержать достаточно информации, чтобы всем участникам процесса было понятно, что именно вы сделали.
\r\nПолезная фиксация может выглядеть следующим образом:

\r\n

feature: добавлена функция X

\r\n\r\n

^--^ ^---------------^
\r\n| |
\r\n| +-> Краткое описание новой добавленной функции.
\r\n|
\r\n+-------> Тип функции, добавленной при фиксации.

\r\n

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

Коммитить рано и коммитить часто

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

Отказ от множественных фиксаций

В какой-то момент вы обнаружите, что слишком большое количество одноцелевых коммитов делает работу с git-репозиторием сложной. Подумайте об этом следующим образом: Если у вас есть 100 коммитов для каждой созданной вами ветки, это может привести к огромному количеству коммитов. Поэтому, вместо того чтобы оставить все эти единичные коммиты как есть, удалите их командой git rebase. При этом откроется редактор со списком коммитов и возможностью действовать в соответствии с ними. 
\r\nЦель состоит в том, чтобы сделать ваш репозиторий настолько информативным и чистым, насколько это возможно.

Никогда не изменяйте историю

После отправки фиксации не следует изменять ее в истории проекта. Если это сделать, то становится практически невозможно вести последовательный контроль версий. Поэтому даже если у вас возникнет соблазн использовать git rebase для удаления коммитов, делайте это только на ветках, которые вы не используете.
\r\nВетка, с которой вы работаете, всегда должна оставаться с полной историей (и коммитами). Это так, даже если вы допустили большую ошибку в фиксации. Исправьте эту ошибку и создайте другой коммит, чтобы все знали, что проблема решена.

Использование меток

Метка - это снимок состояния ветки в определенный момент времени. Считайте, что метка - это именованный указатель на конкретную фиксацию. Это очень полезно, когда необходимо указать важную точку в истории проекта. Например, вы можете отметить точки выпуска, такие как v1.0, v1.2 или v2.0. Теги облегчают эту задачу.
\r\nGit позволяет создавать как легкие, так и аннотированные метки. Легкий тег похож на ветку, которая не изменяется, в то время как аннотированные теги хранятся в базе данных Git как полноценные объекты. Аннотированные теги могут также содержать контрольную сумму, имя теггера, адрес электронной почты, дату, сообщение о теге, а также могут быть подписаны и проверены с помощью GNU Privacy Guard (GPG).
\r\nНаиболее распространенным тегом является аннотированный тег. 

Заключение

Git - это инструмент, который должен использовать каждый разработчик программного обеспечения для контроля версий. И если вы используете Git, важно настроить его и следовать лучшим практикам, чтобы быть уверенным в том, что ваша работа будет безболезненной и эффективной.