Жать «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 в тексте выше. Надеюсь, статья будет полезна и не попадет под категорию «сильному не нужно, слабому не поможет».