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

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

Удаленный репозиторий

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

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

Использование удаленного репозитория лежит в основе распределенной разработки с помощью Git и обязательно к использованию.

Выглядит это следующим образом:

Удаленный репозиторий (remote repo) здесь выступает единым источником истины о состоянии проекта. Для работы каждый разработчик скачивает (pull) себе полную копию всей истории изменений с сервера в локальный репозиторий (local repo) и работает так, как я показывал в прошлой статье, т. е. вносит изменения и коммитит их в локальный репозиторий.

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

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

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

Наверняка у вас возник вопрос: если разработка ведется параллельно, то что будет, если два разработчика изменят один и тот же файл и одновременно отправят это на сервер? Чье изменение будет принято и что будет с конфликтующим изменением?

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

А пока о сервере – где его взять? Если вы энтузиаст или коммерческая компания, просто используйте интернет-сервисы типа GitHub, GitLab, Bitbucket и т. д. Кроме Git-сервера они предоставят вам удобные инструменты для командной работы.

Если вы закрытая/военная организация или у вас серьезная коммерческая тайна, то не отправляйте свои наработки в интернет. Вместо этого разверните тот же GitLab или Bitbucket в защищенной внутренней сети предприятия. По опыту GitLab можно установить и настроить за пару дней, чтобы разработчики начали полноценно его использовать.

Создание репозитория

Для примера рассмотрим GitHub. Это самый популярный Git-сервис, потому что он позволяет вам бесплатно создавать закрытые репозитории, доступ к которым будет только у вас и ваших коллег.

Я все свои проекты храню на нем, даже если работаю над ними один.

Чтобы сделать свой первый репозиторий, вам нужно зарегистрироваться на GitHub.com и в правом верхнем углу нажать + -> New repository.

Затем введите имя репо и обязательно выберите Private, чтобы скрыть репозиторий ото всех. Если потом захотите открыть, сделаете это в настройках репо. Жмем Create repository, готово!

Теперь, чтобы начать работу, надо клонировать (clone) ваш пустой репозиторий на компьютер и начать создавать коммиты.

Форк репозитория

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

Сначала вы должны сделать важную вещь – скопировать репозиторий из моего GitHub-аккаунта в свой. Это называется «сделать форк» (fork) репозитория. В форкнутом репозитории вы сможете хозяйничать, как захотите, и вносить любые изменения. Потом сможете легко удалить его из своего аккаунта. На мой исходный репо это все никак не повлияет.

Перейдите в мой репо MATLAB-Git-Demo и нажмите в правом верхнем углу кнопку Fork, затем выберите свой аккаунт. После короткого ожидания перед вами предстанет ваш личный репозиторий MATLAB-Git-Demo, с ним дальше и будете работать.

На странице вашего репо нажмите зеленую кнопку Code. Открывается меню с вариантами клонирования репозитория. Копируем git-адрес из поля HTTPS. По этому адресу мы и будем синхронизироваться с репозиторием.

Клонирование репозитория

Теперь запускаем MATLAB и в главном меню выбираем HOME -> New -> Project -> From Git. В поле Repository Path вставляем скопированный git-адрес, а в Sandbox указываем папку, в которую хотим клонировать удаленный репозиторий. Чтобы не запутаться, назовем папку MATLAB-Git-Demo. После чего нажимаем Retrieve, затем Yes.

Происходит полное клонирование удаленного репозитория со всеми файлами и историей изменений в так называемую «песочницу». В данном случае терминология несколько отличается от той, что принята в Гите, но отражает суть. Мы получаем локальный репозиторий, в котором будем вести разработку, не боясь сломать наш источник истины на сервере. Будем создавать новые коммиты, периодически пушить их в удаленный репо и не забывать подтягивать последние изменения от коллег.

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

Кстати, клонировать репозиторий даже проще в приложении GitHub Desktop, но это оставляю вам на самостоятельную проработку.

После переходим в созданную папку с локальным репозиторием.

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

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

Для начала в скрипте sin_params.m поменяем значение A на 20. Допустим, мы решили в два раза увеличить значение, чтобы система работала лучше. Получаем следующий скрипт:

A = 20;
w = pi / 4;

И давайте в модели sin_model.slx и в тригонометрическом блоке поменяем функцию с косинуса на синус. Не забываем сохранить модель.

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

В окошке Current Folder с файлами проекта кликаем на пустом месте правой кнопкой и выбираем Source Control -> View and Commit Changes…

Открывается окно коммита. Сверху мы видим список измененных файлов. Вы можете кликнуть на каждый из них правой кнопкой и посмотреть, какие именно изменения мы собираемся закоммитить, это пункт Compare to Ancestor. То есть мы сравниваем текущую измененную версию файла с его предком из истории версий. Если вы не хотите коммитить какое-то изменение прямо сейчас, снимите галочку возле файла. А если хотите безвозвратно откатить изменение и вернуть файл в состояние прошлого коммита, выбирайте Revert Local Changes.

Пишем описание коммита в поле Comment и фиксируем изменения в истории кнопкой Commit.

Можете полюбоваться вашим коммитом в истории изменений, выбрав Source Control -> Branches.

Теперь мы хотим сразу же отправить наш коммит на сервер в удаленный репозиторий, чтобы коллеги были в курсе нашего изменения у читывали его при работе, для этого выбираем Source Control -> Push.

Проверим, как сработал пуш. Возвращаемся на страничку вашего форкнутого репозитория на GitHub, обновляем ее и нажимаем на ссылку 9 commits чуть выше и правее списка файлов. Попадаем в историю изменений, где в самом верху вы должны увидеть ваш свежий коммит. Нажмите на него, и откроется список изменений в этом коммите. Вы прямо на GitHub видите, что поменялось в текстовом скрипте sin_params.m, но изменения в модели сервис показать не может. Их можно посмотреть только в MATLAB, как мы разбирали в прошлый раз.

Теперь все ваши коллеги должны обновить свои локальные репозитории, чтобы подтянуть ваши изменения. Это нормально, если вы выполняете pull по несколько раз в день, а то и чаще. Рекомендую плюс к этому делать pull перед каждым коммитом, чтобы снизить вероятность конфликтов, о чем мы тоже как-нибудь поговорим.

Закроем текущую тему тем, что вернемся в MATLAB и выберем Source Control -> Pull. Как вы поняли, именно так в MATLAB подтягиваются изменения. В текущей ситуации ничего не произойдет, потому что у вас и так последняя версия репо, но привычку закрепляем.

Кстати, делать pull/push на постоянной основе намного удобнее через приложение GitHub Desktop. За это отвечает большая третья кнопка, на которой обычно написано Fetch origin.

Фетч означает, что при нажатии вы получаете последнюю информацию о состоянии удаленного репозитория. И если там появятся новые коммиты, кнопка сменит название на pull и позволит их подтянуть. А как только вы сделаете новый локальный коммит, кнопка переименуется в Push и позволит отравить изменения на сервер.

Заключение

Полученных навыков вам хватит, чтобы начать работать с удаленными репозиториями в одиночку. Или даже в небольшой команде, но при условии, что вы договоритесь не редактировать одновременно одни и те же файлы, особенно модели Simulink и «живые» скрипты mlx.

А если договориться не получится, то вы начнете периодически спотыкаться о конфликты Гита. Это обычно вызывает много боли на практике. Если вам интересно узнать про возникновение и разрешение конфликтов подробнее, пишите в комменты. Будет интерес – будет новая статья!

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