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

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

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

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

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

Например, коммит с текстом "JRA-123 #close #comment task completed" установит тикет Jira JRA-123 в статус закрытого, оставив в нем комментарий "task completed".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда вы завершили работу над веткой фич, хорошей практикой является использование запросов на выгрузку (pull requests), чтобы вернуть свои изменения в основной поток репозитория. Pull-запросы создаются разработчиками функции или задачи. Обычно старший разработчик или DevOps отвечает за проверку изменений перед тем, как принять их в основную линию.

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

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

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

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