Введение в систему контроля версий Git
Системы контроля версий были придуманы для версионирования часто изменяемых файлов. Наибольшее применение они нашли в разработке программ. Представьте, что есть файл index.html. В течение нескольких лет его обновляют сотрудники компании. При помощи несложных манипуляций система контроля версий позволяет держать единственный экземпляр файла index.html, без всяких index1.html, index_new.html и т.д. Т.е помогает избежать бардака на рабочем месте. Можно безболезненно откатиться на раннюю версию index.html, просматривать историю изменений построчно, начать доработки с любой версии файла. Также за счет принципов, заложенных в работе системы, идет выигрыш по занимаемому месту на жестком диске. В реальных проектах под системой контроля версий находятся сотни и тысячи файлов с программными кодами, проводятся более сложные операции, к примеру: объединение наработок, откат изменений, отправка их на сервер в сети интернет (так можно вести разработку удаленным командам), либо наоборот запрос обновлений содержимого файла с сервера.
Применительно к работе вне IT-индустрии системы контроля версий имеют проблему. Один файл с кодом обычно имеет до нескольких тысяч строк кода, это максимум сотня-другая кб. При работе с любыми изображениями, аудио и видео единицы измерений сразу меняют порядок, переходя в мб. Т.е. эффективность снижается, как только мы начинаем работать с бинарными файлами, потому что они имеют большой размер, а также хуже сжимаются. Грубо говоря, положив в систему контроля версий картинку весом 10 мб и сделав пару изменений, мы никакого профита по занимаемому пространству не получим в сравнении с ведением дел а-ля «файл1.psd». Однако в середине 2010-х были придуманы определенные фишки, позволяющие преодолеть эти проблемы.  
Есть несколько популярных систем контроля версий: Mercurial, SVN, CSV и Git. В этой статье я буду использовать Git с расширением LFS (Large File Storage). Для начала работы надо скачать Git for Windows сhttps://git-scm.com/downloads   - там выбрать 64-разрядную версию для Windows. Для Mac и Linux тоже все есть. При установке программы ничего не менять, жать везде далее. На компьютере программа займет до 250 мб. После окончания установки в меню «Пуск» появится папка «Git». В ней выбрать «Git GUI» для запуска графической версии программы (вариант «Git Bash» – консольная версия для любителей вбивать команды текстом). Откроется следующее окно

Жать «Create New Repository» для создания нового проекта, а в дальнейшем для работы с уже существующими проектами выбирать «Open Existing Repository». В следующем окне выбрать папку с файлами, которые необходимо положить в систему контроля версий

Жать «Create». На экране появится основной интерфейс программы, а на жестком диске в проекте будет создана скрытая папка .git со служебными файлами.

Нужно сделать пару настроек после первого запуска программы. В «Edit – Options» найти по два поля «User Name» и «Email Address». Это глобальные и локальные имя пользователя и почтовый адрес. Можно ввести любую правдоподобную информацию, т.к. в настоящий момент для нас это лишь внутренняя настройка, формально нужная для обозначения инициатора при внесении изменений в системе. Жать «Save».

Для учебных целей Git LFS ставить не обязательно, можно проводить абсолютно все действия без расширения, только работа с изображениями получится неэффективной. Те, кто решили его поставить, делают это всего один раз после установки программы. В меню выбрать «Repository – Git Bash». В появившемся окне консоли ввести git lfs install и жать Enter

В консоли еще нужно указать расширение файлов, которые вы хотите контролировать. Делать это придется каждый раз при старте нового проекта или при желании отслеживать файлы иного формата, чем был задан ранее.  В статье работа идет только с jpg. Поэтому вводим git lfs track "*.jpg", жать Enter

Добавим в папку картинку формата jpg. Как только файл будет перенесен, то в интерфейсе программы его имя появится в списке «Unstaged Changes» (обновление интерфейса программы как в браузере по F5). Чтобы зафиксировать текущее состояние файла в системе контроля версий, надо сделать два шага:

1) Первый шаг - перенести изменения файла из «Unstaged Changes» в «Staged Changes». Делается это с помощью пункта «Stage Changed Files To Commit» из меню «Commit».

«Staged Changes» – это своего рода промежуточный этап, на котором записи состояния в систему пока не происходит. Он удобен, если вы планируете делать изменения в нескольких отслеживаемых файлах, а затем одним махом записать в систему контроля версий состояния всех измененных файлов. Другая ситуация – вы передумали записывать состояние одного файла и решили вернуть его в прошлый список («Unstaged Changes»). Если вы сделаете изменения в файле из списка «Staged Changes», то он автоматически переместится обратно в «Unstaged Changes».    

2) Второй шаг – запись в систему контроля версий, еще этот шаг называют коммит. По правилам хорошего тона следует ввести комментарий к коммиту, чтобы в будущем было легче ориентироваться в изменениях. После завершения этого шага все, что перечислено в списке «Staged Changes», исчезнет оттуда и запишется в систему контроля версий. Если у вас были файлы в «Unstaged Changes», то для них изменений в системе не произойдет. Если же сложится ситуация, когда не будет файлов в списке «Staged Changes», а вы нажмете «Commit», то записывать в систему нечего. Вылезет такое предупреждение.

Но т.к. у нас в «Staged Changes» есть новый файл, то все должно пройти как по маслу.

Надо нажать кнопку «Commit», второй шаг будет успешно завершен. Чтобы посмотреть, что сейчас произошло, можно открыть на панели меню «Repository – Visualize master’s History» (либо пукнт ниже «Visualize All Branch History»)

Откроется структура проекта.

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

Представим, что нам дали задание на доработку изображения. Мы выполнили указания, получилось следующее.

Как помним, при любом редактировании файла он попадает в «Unstaged Changes». Выполняем два шага для записи изменений в систему контроля версий, смотрим структуру проекта.

На ветке master появился новый коммит, а желтый круг изменил положение. Осуществим еще пару изменений картинки, при каждом удобном случае делая коммит с пояснением.

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

Представим, вы получили указание на смену тематики работы. Надо переделывать картинку, взяв за основу ее третью версию. Чтобы перейти на другое состояние файла, прямо в окне просмотра истории следует щелкнуть правой кнопкой мыши на коммите с описанием «third version of picture…», в появившемся меню будет пункт «Create new branch»

После выбора пункта меню появится окно, где требуется ввести имя для новой ветки коммитов: латиницей, без пробелов и спецсимволов. Жать «Create».

В результате будет создана отдельная ветка для коммитов в систему контроля версий. Они не будут затрагивать прошлую ветку master. Новая ветка (в примере названа royal_theme_branch) тоже подсвечена зеленым. Мы пока не переключились на эту ветку, о чем свидетельствует желтый круг, находящийся на master. Чтобы перейти на royal_theme_branch, надо нажать на этой ветке правой клавишей мыши и выбрать «Check out this branch».

Посмотрим, что произойдет со структурой проекта и самим изображением

Желтый круг в интерфейсе сменил расположение: это значит, что текущей веткой является royal_theme_branch. Изображение вернулось на третью версию. Делаем доработки для картинки. Вносим изменения в систему контроля версий.

На этом шаге я ошибочно указал не тот комментарий к коммиту, вместо «fourth verision…» написал «third version». Проблему легко устранить, т.к. для последнего совершенного коммита возможно изменить описание с помощью «Amend Last Commit» из пункта меню «Commit»

Я ввел правильное описание, теперь посмотрим на историю проекта

Сейчас лучше видно древовидную структуру проекта, с двумя ветками. Выйдем из истории в основной интерфейс программы. Переключимся на последний коммит из master: для этого надо выбрать пункт меню «Branch – Checkout», в появившемся окне выделяем master и жмем «Checkout»

Мы сейчас находимся на этой версии картинки

Сделаем еще одну ветку от master, за точку отсчета взяв вторую версию. Вносим изменения, делаем коммит, смотрим историю.

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

В истории отмечено красным кругом, что есть те самые незакомиченные изменения, которые и хотелось бы убрать. В основном интерфейсе программы выбираем «Commit – Revert Changes»

Все вернулось обратно

Для того, чтобы убрать версионирование файлов в проекте, просто удалите скрытую папку .git.  

Про координацию работы в команде с использованием системы контроля версий. Если удаленно есть несколько человек, которые на своих компьютерах используют подобные системы, логично было бы создать место, чтобы централизованно хранить изменения, поступающие ото всех работников. Для этого созданы сервисы хостинга проектов (репозиториев) Bitbucket и GitHub. Для тренировки на GitHub можно создавать бесплатно публичные репозитории, правда они видны всем подряд в интернете (приватные репозитории платны). Для начала использования нужно пройти регистрацию, после чего настроить профиль, создать репозиторий.

Если вы намерены это организовывать, то необходимо познакомить всех участников проекта с понятиями pull/push/fetch в системе git. Также нужно разобраться с правами, кто может комиттить в заданный репозиторий.

Ничего не мешает делать описанное выше, если команда работает не удаленно, а в одном офисе с наличием доступа в интернет. Но иногда есть смысл сделать аналог GitHub внутри организации, чтобы не зависеть от сторонних ресурсов. Тогда надо на выделенном железе развернуть git-сервер, т.е. локально будет система, схожая по функциональности с GitHub. Чаще всего решают ставить GitLab, он бесплатный; попроще варианты, но более сырые - gitea и gogs.

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

- Шпаргалка по работе с Git на русском: https://eax.me/git-commands/ 

- Памятки в графическом виде на английском (о принципе работы системы и основные команды): https://www.quora.com/What-is-the-best-Git-cheat-sheet 

- Небольшое справочное руководство по Git на русском: https://git-scm.com/book/ru/v2 

- Четыре видео на русском из цикла «Git - для новичков», каждое по 10 минут: https://www.youtube.com/playlist?list=PLY4rE9dstrJyTdVJpv7FibSaXB4BHPInb 

- Двухминутное видео про Git LFS на английском: https://www.youtube.com/watch?v=uLR1RNqJ1Mw 

- Человек из Autodesk поясняет про «How to handle large files in Git» на английском (25 минут) https://www.youtube.com/watch?v=YQzNfb4IwEY 

- Если визуально не нравится интерфейс стандартного Git GUI, то альтернативные варианты (SourceTree, TortoiseGit и т.д.) здесь: https://git-scm.com/downloads/guis 

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

урокиgitсистема контроля версий

Комментарии (15)

+4
breezeshaman
Никто не каментит, ибо видит что тут что то умное, и боится глупым показаться, написав что то про непонимание всего этого )
+9
Jähman'
Скорее непонимание как это вообще применимо к 3д.
Особенно весело будет, если потребуется одновременный доступ к разным версиям одного файла. ;)
А так-то да, для кода чудесная и незаменимая вещь.
0
kokoasfalt
> одновременный доступ к разным версиям одного файла

Если я правильно понял, эта задача решается клонированием локального репозитория в другую папку:https://stackoverflow.com/questions/21045061/git-clone-from-another-directory 

git clone C:\folder1 folder2

Про применение к 3d есть вопросы, да.. Ну наверняка здесь кто-то работает в других программах, с фотошопом, unity3d - статья может быть для них полезной. Для 3d max тоже можно использовать, вот дискуссию в интернете отрыл -https://forums.autodesk.com/t5/3ds-max-forum/3ds-max-with-git-source-control/td-p/4193588  , а при поиске по 3ddd.ru нашелhttps://3ddd.ru/forum/thread/show/davaite_soberem_samye_topovye_laifkhaki_po_rabote_v_3ds_max#post1279285  Возможно, MastaMan расскажет про опыт с Perforce
+3
Jähman'
Вот мы и вернулись обратно к тому от чего пытались уйти. К созданию дублирующегося контента. И все оттого, что ни diff ни merge невозможен для подобных файлов. В результате функционал гита сокращается до аннотирования изменений и отката до какого-либо из состояний.
В фотошопе версионирование решается слоями, имхо.

зы. В дискуссии по ссылке увы сошлись не в пользу гита
+1
kokoasfalt
В задачах той дискуссии да. Если планируется использовать 3ds Max Interactive, то git может быть полезен, вот даже рекомендации на оф. сайтеhttps://help.autodesk.com/view/3DSMAX/2018/ENU/?guid=__interactive_help_getting_started_set_up_project_version_control_html  В целом вы правы.

upd еще нюанс вспомнился: если идет работа с stl, то при загрузке репозитория на github будет diff -https://blog.github.com/2013-04-09-stl-file-viewing/ 
0
RomanRyazh
Обычно очень многими недооцениваемая информация. А ведь для 3Dшников git очень даже нужен, в первую очередь имею ввиду игроделов
+2
olegwer
Мало кто оценит здесь такое.
Git для избранных )
0
Jähman'
Тема на самом деле интересная.
Кто как решает проблему внесения и отката изменений в рабочие файлы?
+1
-NiK-
Рабочие файлы в смысле сцены?
Можно тупо включить инкрементальный сейв и гадить файлами в папку, а потом чистить руками.

Мой вариант - Можно объединить полезное с полезным. Версии с бэкапом. Настроить риалтайм бэкап софтину (я юзаю goodsync) на версионный бэкап и автоматическую очистку через, например, 30 дней.
Я тупо сохраняю сцену через ctrl+s, а служба в фоне её бэкапит на бэкапный диск и добавляет дату-время. Автоочистка позволяет забыть про засирание бэкапного диска, а наличие сотен версий позволяет откатиться куда угодно. Вариант конечно ленивый, как раз для таких как я :) Но спасал меня не раз, в том числе от ошибочного удаления файлов.
0
BlessOd
Если начинать с Git то с терминала, не понимая как работает Git сразу в ГУЙ лезть....
Ну и я конечно не читал весь ваш опус, гит сохраняет не новый файли только изменения в файле.
Видимо решает расширением LFS (Large File Storage)....
Но имхо такие костыли ради чего не понятно
+1
kokoasfalt
Посчитал, что для аудитории 3ddd легче начать с GUI. Не надо держать в памяти множество незнакомых магических слов.
Про понимание git - ссылки интересующимся я предоставил
+1
xbuf
имхо для работы в 3д максе это все не нужно. нужен просто нормальный и ёмкий хдд + софт позволяющий удобно работать со всеми необходимыми библиотеками на нём. :)
+3
MastaMan
Мы используем Perforce, он тоже на git. Позволяет держать все файлы локально с кешированием на сервер. Таким образом, можно работать в команде. У него довольно простой интерфейс, без всяких терминалов. И он используется для спецефических задач. В архвизе он не прижился, все уже удобно incremental save и просто плодить версии в той же папке.
+3
bryarey
ИМХО, художникам/моделлерам намного проще пользоваться Tortoise SVN. Никаких клиентов, консолей - два пункта в контекстном меню решают 99% задач: Commit и Update. Очень легко, проще, чем в гите, открыть любую версию файла, не откатывая весь проект. Единственное что - нужен кто-то, кто сможет все установить и настроить, и решать проблемы в случае их возникновения.

Еще добавлю, что для удаленной работы на github/bitbucket репозиторий заводить не стоит: там объем хранилища ограничен жестко двумя Гб, и даже LFS не спасает - там тоже лимиты. Для больших проектов с большим количеством контента надо заводить свой сервер.

В общем, однозначно: системы контроля версий рулят! Забудьте о дурацком нейминге в стиле project_new2_final_last. Для одной задачи один файл, а система сама помнит все его версии, каждое изменение.
-1
lauder
Весь это технический геморрой заменят обычный Dropbox, который хранит все версии всех файлов до 30 дней для обычного акка и до года для бизнеса. Заодно не надо тратится на хранилище и бекапы всего и вся