Использование контроля версий с Unity3D

Эта статья призвана стать полным руководством о том, как правильно управлять версиями ваших проектов Unity!

Контроль версий — один из важнейших инструментов в арсенале любого разработчика. Он позволяет вам легко откатить изменения, если вы случайно что-то сломали, сравнить старые и новые версии вашего кода, чтобы увидеть, что отличается, и позволяет командам работать над одним и тем же кодом без случайной перезаписи работы друг друга. До недавнего времени только проекты Unity Pro могли должным образом контролировать версию. Однако, начиная с Unity 3.5, теперь можно управлять проектами контроля версий и в бесплатной версии Unity.

---

Что такое контроль версий?

Система контроля версий, или VCS, отслеживает изменения, внесенные в файлы в папке, также известной как «рабочая копия». Эти изменения хранятся вместе с папкой в ​​базе данных, известной как «хранилище». Каждый раз, когда вы что-то меняете в своей рабочей копии, вам нужно зафиксировать эти изменения в репозитории. Затем VCS сравнивает то, что уже находится в хранилище, с входящими изменениями и сохраняет только различия. Это делает хранилище настолько маленьким, насколько это возможно.

Для этого проекта мы будем использовать Mercurial, который является распределенной VCS. В отличие от централизованных систем VCS, таких как Subversion (SVN), которые обычно полагаются на удаленный репозиторий, хранящийся на сервере, распределенная VCS может размещать локальные репозитории, иногда называемые «локальными филиалами», непосредственно на вашем компьютере. Это означает, что вы можете вносить изменения, фиксировать их в своем местном филиале, тестировать их и даже отбрасывать их, если что-то ломается, и все это без необходимости подвергать членов вашей команды изменениям, пока вы не узнаете, что они совершенны. Если вы уверены, что вы можете «вставить» эти изменения в удаленный репозиторий, чтобы ваша команда «втянула» их в свои локальные филиалы.

---

Подготовка проекта Unity для контроля версий

Проект Unity требует определенной метаинформации, чтобы запомнить, какие компоненты и соединения установлены в различных активах. Традиционно эта метаинформация хранилась в виде набора двоичных файлов в папке «Библиотека» проекта Unity. Однако этот «двоичный двоичный объект» нельзя объединить должным образом, поэтому изменения, сделанные двумя людьми, могут растоптать друг друга, что приведет к сбою в редакторе, даже если они редактируют разные ресурсы.

Решением этой проблемы является включение метафайлов в настройках проекта.

• Нажмите «Правка»> «Настройки проекта»> «Редактор».
• Под заголовком контроля версий измените режим на метафайлы
• Нажмите Файл> Сохранить

Это заставит Unity создавать метафайлы рядом с каждым активом в папке «Ресурсы проекта». Теперь, когда ресурс редактируется в редакторе, только ресурс и связанный с ним метафайл будут сообщать об изменениях, а не вся папка библиотеки.

---

Установка Mercurial

И Windows, и OSX имеют установщики Mercurial. Посетите веб-сайт Mercurial и нажмите большую кнопку загрузки. Сайт автоматически распознает, какую операционную систему вы используете, и скачает соответствующий установщик.

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

Чтобы убедиться, что Mercurial установлен правильно, откройте командную строку. В Windows нажмите Пуск и введите cmd в поле поиска. В OSX откройте Spotlight и найдите терминал .

В командной строке введите:

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

А чтобы получить справку по конкретной команде, просто введите имя команды после справки:

ПРИМЕЧАНИЕ: команды Mercurial всегда начинаются с hg , элемента для ртути в периодической таблице. К счастью, этот бит умного наименования был использован, потому что его легко набирать.

---

Инициализация репозитория

Первое, что нам нужно сделать, это предоставить нашей папке проекта репозиторий.

В командной строке введите:

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

---

Проверка статуса

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

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

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

---

Добавление файлов в репозиторий

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

Отдельные файлы могут быть добавлены:

Целые папки могут быть добавлены:

Давайте добавим каждый не версионный файл (со знаком вопроса в отчете о состоянии) одним махом, не указав ни одного имени файла вообще:

Выполните проверку статуса.

Любые добавленные файлы теперь должны иметь рядом с собой букву А , указывающую, что они были добавлены в репозиторий и теперь отслеживаются Mercurial.

---

Передача изменений

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

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

Чтобы убедиться, что фиксация прошла успешно, нам нужно проверить журнал:

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

Пустой отчет о состоянии означает, что все было правильно зафиксировано.

ПРИМЕЧАНИЕ. Рекомендуется часто совершать коммиты. Каждый коммит должен быть как можно более «атомарным». То есть это должно быть легко описано простой фразой, такой как «увеличенная высота прыжка игрока». Если вы обнаружите, что вам нужно использовать «и» или запятые в ваших сообщениях о коммите, то, вероятно, пришло время сделать два отдельных коммита. Причина этого заключается в том, чтобы упростить откат определенных изменений, внесенных вами при возникновении проблем.

---

Исправление ошибок

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

Выполните проверку состояния, чтобы убедиться, что все откатилось правильно.

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

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

Чтобы вернуться к определенной ревизии, нам нужно указать номер ревизии с помощью флага -r . Мы также должны указать Mercurial «отменить все», используя флаг -a . Наконец, нам нужно сообщить Mercurial, что мы не хотим, чтобы он создавал какие-либо резервные файлы, используя флаг —no-backup .

Выполните проверку состояния, чтобы убедиться, что все вернулось правильно.

ПРИМЕЧАНИЕ. Если вы опустите флаг —no-backup , Mercurial создаст файлы резервных копий для всех файлов, затронутых процедурой возврата. Эти файлы резервных копий будут иметь расширение .orig . Не добавляйте файлы .orig .

---

Игнорирование нежелательных файлов

Теперь, когда мы исправили свою ошибку, давайте удостоверимся, что это больше не повторится. Мы хотим навсегда игнорировать папки Library и Temp, чтобы они не могли быть добавлены случайно, когда в следующий раз мы получим триггер, удовлетворенный командой add.

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

Используя ваш любимый текстовый редактор, введите следующее:

Это сообщает Mercurial, что мы хотим использовать синтаксис в стиле оболочки (известный как синтаксис «glob»), чтобы игнорировать папки Library и Temp, игнорировать несколько временных файлов, которые создает MonoDevelop, и игнорировать файлы .orig на тот случай, если мы случайно создадим их при возвращаясь.

Сохраните файл в корне папки вашего проекта как .hgignore (отмечая точку в начале). Затем выполните еще одну проверку статуса:

Файл .hgignore теперь должен быть указан в отчете о состоянии, но папка «Библиотека», папка «Temp» и другие игнорируемые файлы не должны. Таким образом, мы можем безопасно использовать команду add без необходимости использовать точные имена файлов, а затем зафиксировать результаты.

Проверьте журнал, чтобы убедиться, что фиксация прошла успешно.

ПРИМЕЧАНИЕ. Дополнительную информацию о файлах hgignore можно найти здесь .

---

Отправка изменений в удаленный репозиторий

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

Первое, что вам нужно сделать, это найти хост Mercurial. Существуют несколько, в том числе BitBucket и Kiln ; У обоих есть бесплатные аккаунты для небольших команд. В нашем случае мы будем использовать BitBucket, но оба сервиса работают практически одинаково. После того, как вы зарегистрировали учетную запись в любой службе, обязательно создайте новый репозиторий, используя их веб-интерфейс.

После создания ищите «путь клона». Это должно выглядеть примерно так:

hg clone https://bitbucket.org/username/reponame

Обычно эта команда используется для создания локальной копии хранилища. Но у нас уже есть локальный репозиторий, и мы хотим вместо этого отправить изменения из него в удаленный репозиторий. Для этого мы можем взять URL-адрес в конце строки клона и использовать его в качестве места назначения для команды push.

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

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

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

А затем извлеките все изменения, которые вы или кто-либо другой внесете со временем:

Затем вам нужно будет выполнить «обновление», чтобы убедиться, что ваша рабочая копия обновлена:

Но чтобы сэкономить время, вы можете выполнить извлечение и обновить все сразу, используя флаг -u :

ПРИМЕЧАНИЕ. Mercurial будет запрашивать вас всякий раз, когда двоичный файл обновляется или объединяется. Если вы не уверены, что внесли изменения в локальные двоичные файлы, всегда выбирайте параметр «(O) прочее» вместо параметра «(L) ocal» .

---

Настройки, чтобы сделать жизнь проще

Есть несколько утомительных аспектов повторного ввода одних и тех же команд, таких как необходимость не забывать вводить имя пользователя при фиксации, необходимость вводить пароль каждый раз, когда вы нажимаете, и т. Д. Многие из этих настроек могут быть сохранены в так называемой файл hgrc . Чтобы создать файл hgrc , используйте ваш любимый текстовый редактор и введите следующее:

Это сообщает Mercurial, какой путь использовать по умолчанию для команд push и pull. Обязательно замените этот поддельный адрес реальным адресом вашего удаленного хранилища. Далее введите следующее:

Это сообщает Mercurial, какое имя пользователя использовать по умолчанию при фиксации. Еще раз замените его правильными учетными данными и убедитесь, что адрес электронной почты совпадает с тем, с которым вы зарегистрировались. Наконец, введите:

Это сообщает Mercurial, какие учетные данные использовать при отправке в безопасный удаленный репозиторий, чтобы вам не приходилось вводить имя пользователя и пароль при каждом нажатии или отправке. Обязательно замените префикс самой короткой частью адреса вашего хоста и не включайте в префикс протокол http:// . Затем замените имя пользователя и пароль на то, которое вы зарегистрировали на своем хосте. Схема сообщает Mercurial, с какими протоколами пытаться соединиться.

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

---

Вывод

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

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