Лучшие практики для контроля версий

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

Один коммит должен относиться только к одной задаче или тикету, если только одна строка кода волшебным образом не исправляет несколько ошибок. Если вы работаете над более крупной функцией, разбейте её на более мелкие задачи и сделайте коммиты для каждой.

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

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

При работе с системой тикетов задач, такой как Jira или GitLab, еще лучше включить номер тикета в ваш коммит. Многие системы могут быть настроены для работы вместе с умными коммитами, чтобы вы могли фактически ссылаться на тикеты и изменять их статус из сообщения вашего коммита.

Например, коммит, который гласит «JRA-123 #close #comment задача завершена», закроет тикет Jira JRA-123, оставив комментарий «задача завершена» в тикете.

Для получения дополнительной информации о настройке этого рабочего процесса смотрите документацию в Jira или сервис Pivotal Tracker в GitLab.

Единственный раз, когда следует использовать «commit -a» (команда Git для «коммит всех изменений») или любой из её аналогов, это при первом коммите проекта. Обычно это происходит, когда единственными файлами в проекте являются README.md.

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

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

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

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

Рабочие процессы Plastic SCM немного отличаются, потому что вы можете работать в централизованных, распределенных или многосайтовых конфигурациях.

Многосайтовые конфигурации могут быть довольно уникальными, при этом каждый пользователь работает либо в централизованном, либо в распределенном рабочем процессе.

Рассмотрите следующий пример:

• Две команды
• У каждой команды есть локальный сервер
• Члены команды проверяют локально или распределенно на каждом сайте, но получают выгоду от скорости близкого локального сервера
• Серверы обмениваются данными друг с другом, чтобы оставаться полностью или частично синхронизированными

Независимо от того, с каким VCS ваша команда решит работать, убедитесь, что все чувствуют себя комфортно, используя его, и понимают инструменты, которые у них есть.

Если вы работаете с Git, не всем нужно использовать один и тот же GUI-клиент. Но сделайте приоритетом, чтобы все чувствовали себя комфортно с рабочим процессом commit > pull > push. Другими словами, они должны иметь знания, чтобы коммитить только те файлы, которые им нужны.

Если вы работаете с Plastic SCM, поощряйте художников в вашей команде привыкать к Gluon, удобному GUI для упрощения их рабочего процесса. Gluon позволяет вам выбирать файлы, над которыми вы хотите работать, устраняя необходимость загружать и управлять всем проектом. Это также позволяет вам блокировать файлы, что предотвращает работу других над ними. Когда вы закончите, отправьте файлы обратно в репозиторий и снова разблокируйте их по мере необходимости.

При работе над долгосрочным проектом с несколькими циклами выпуска ветвление функций очень полезно для вашего рабочего процесса. Часто команды работают из одной ветки репозитория, вероятно, называемой trunk, master или main.

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

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

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

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

Perforce Helix Core использует систему, называемую Streams , чтобы облегчить этот стиль рабочего процесса. При создании депо для работы вам нужно настроить его как тип депо потока. Затем вы можете использовать Stream Graph view, чтобы создать новые потоки. Каждому потоку (кроме основного потока) необходимо иметь родительский поток, чтобы изменения могли быть скопированы обратно вверх по потоку.

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

Как только вы завершите работу над веткой функции, хорошей практикой будет использовать запросы на слияние, чтобы вернуть ваши изменения в основной поток репозитория. Запросы на слияние создаются разработчиками функции или задачи. Обычно ответственность за проверку изменений лежит на старшем разработчике или DevOps перед их принятием в основной поток.

Plastic SCM и Perforce оба имеют автоматизированные инструменты для управления слиянием веток обратно в основной поток. Plastic SCM делает это с помощью Mergebot, который автоматически сливает ветки репозитория, как только они были проверены и прошли валидацию. Perforce имеет дополнительную платформу, Helix Swarm, используемую для управления обзорами кода, которая также может быть настроена с автоматизированным тестированием.

Даже если вы работаете над индивидуальным проектом, принципы организации и управления версиями могут быть очень полезными.

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

Таким образом, когда вы начнете интегрировать другие инструменты, такие как Jira, GitLab, инструменты сборки или автоматизированное тестирование, работа, которую вы уже проделали по структурированию вашего проекта и рабочего процесса, станет полезной.