Все мы знаем, что среда MATLAB заточена под людей, которые не обязательно являются профессиональными программистами, – математиков, инженеров, аналитиков и даже студентов.
С одной стороны, это большой плюс – люди просто решают свою прикладные задачи без заморочек с выбором библиотек, архитектурой ПО и прочим ООП.
С другой стороны, часто можно наблюдать, что, находясь в песочнице Матлаба, люди оказываются оторваны от мира «большого программирования» со своими устоявшимися подходами и инструментами.
Понятно, что не всем условным математикам нравится глубоко в это все погружаться. Но при этом мне очень досадно наблюдать, как суровые инженеры, которые программируют микроконтроллеры для самонаводящихся ракет, не могут даже настроить систему контроля версий, не говоря уже об автоматизированном тестировании и прочих девопсах.
В этой статье я хочу показать инженерам, как можно без боли контролировать изменения скриптов MATLAB и моделей Simulink. А также попытаюсь донести матлаберам, не знакомым с системой контроля версий (а таких большинство), что для них это необходимый инструмент на каждый день.
Чтобы не потерять вас в самом начале, привожу краткую серию ответов на вопросы, которые мне часто задают новички в этой теме.
Что такое «система контроля версий»?
Это отдельная бесплатная программа, которая работает вместе с MATLAB и сохраняет всю историю того, что вы изменяли в своем проекте: какой добавляли код, как изменяли настройки модели и т. д.
Самая популярная и мощная называется Git, сегодня будем говорить о ней.
Зачем она мне нужна?
Чтобы ваш проект не выглядел так
Намного комфортнее хранить старые версии моделей и кода где-то в истории изменений, чем в куче в одной папке. Ведь вы на следующий же день забываете, какой именно файл актуальный и почему нельзя удалять старые. Контроль версий – самый удобный способ превратить проект из помойки во что-то понятное и приятное.
Круто. И все?
Нет, не все. Только с системой контроля версий вы сможете нормально работать над одним проектом всей командой. Вы имеете полную историю изменений всех файлов проекта. Вы видите кто, когда и что конкретно изменил.
А еще без этого вы в принципе не сможете полноценно автоматизировать тестирование и использовать прочие прелести из мира DevOps.
Наконец, работа с системой контроля версий – это один из самых базовых и необходимых навыков, если вы захотите перейти в IT-отрасль или серьезную зарубежную компанию.
А для студентов, которые наше все, это вообще мастхэв – стыдно не владеть Гитом в 2021.
Ладно, попробую. Это сложно?
Не очень, за вечер можно освоить базу. Если вы совсем не знаете, что такое Git, то уйдет пара вечеров. Хорошая новость – в Гугле и на Ютубе вы найдете тонны материалов, где все объясняют на пальцах.
Предупреждение
Когда вы более-менее освоитесь с контролем версий и Git, то по-другому вы не сможете и на захотите работать в принципе. При создании каждого нового проекта вы первым делом будете добавлять его в Git. Вы перетащите все старые проекты в Git. Вы научите коллег работать в Git. Вы будете вспоминать старые времена как свои темные века.
Я сам все это проходил. И многие коллеги проходили. Поэтому я и пишу об этом так уверенно.
Итак, я постарался максимально вас мотивировать, чтобы вы смогли преодолеть тот небольшой порог, с которым сейчас столкнетесь. К делу.
Установка GitHub Desktop
Предположим, что MATLAB у вас уже установлен. Осталось научить его контролю версий с помощью Git.
И если вы еще не в курсе, то знайте, что сам Git – это консольная утилита, то есть работать с ним нужно из черного окна терминала. Поэтому все уроки по Гиту, что вы найдете в интернете, изобилуют разными командами.
Хорошая новость в том, что сегодня мы писать команды не будем и обойдемся исключительно возможностями Матлаба и еще одного специального приложения с функционалом Git.
Этого вам хватит, чтобы войти в тему и освоить самые базовые принципы контроля версий. Ну а продолжив освоение, вы в любом случае установите Git и освоите парочку команд, без этого никуда.
А пока что мы скачаем так называемый Git GUI-клиент. Подобных приложений создано десятки, если не сотни. Их задача – позволить вам работать с Гитом быстро и удобно с помощью мышки и без командной строки.
Моим любимым Git-приложением является GitHub Desktop. Оно сильно упрощает работу с Гитом и делает ее приятной рутиной. Оно красивое, удобное и без излишеств. Я пользуюсь им буквально каждый день и вам советую.
Честно говоря, я сомневаюсь, что до сих пор остались люди, которые работают с Гитом на десктопе исключительно из командной строки (а если и есть, то они меня пугают ????).
Скачиваем GitHub Desktop с официального сайта и устанавливаем. Для начала пропускаем этап, связанный с созданием аккаунта, а затем вводим свое имя и почту (эти данные нужны для Гита и никуда не передаются, пока вы сами не захотите).
Важно: при желании приложение GitHub Desktop также может загрузить ваш код в интернет на портал GitHub.com (сначала нужно там зарегистрироваться), чтобы вы его там бесплатно хранили и имели возможность работать совместно. Об этом поговорим в другой статье. Без вашего ведома, приложение никуда отправлять код не будет.
Итак, у нас установлены MATLAB и GitHub Desktop. Пора внедрить контроль версий в наш проект.
Создание репозитория
Repository переводится как «хранилище». В Гите репозиторием называется папка, в которой хранится ваш проект (код, модели, данные…) плюс полная история изменений всех файлов проекта.
Давайте сначала создадим пустой Git-репозиторий, а затем перенесем в него проект. Для создания нового репо используем GitHub Desktop. Выбираем File -> New Repository… и затем обязательно вводим название новой папки проекта MyProject, а также указываем путь родительской папки, в которой будет создана папка проекта (например, папка Документы\MATLAB):
Открываем созданную папку в Матлабе и видим там какой-то непонятный файл .gitattributes:
Это служебный файл Гита, который для нас создал GitHub Desktop. Подобные файлы используют, чтобы тонко настроить репозиторий и то, как Гит с ним работает. В нашем случае .gitattributes не особо нужен, но трогать его не будем, чтобы не запутаться.
Тут у вас возникает вопрос: а что тогда делает нашу обычную пустую папку MyProject Гит-репозиторием, который будет хранить все изменения?
Ответ: наличие скрытой директории .git, которая также автоматом создалась в нашей папке. Именно в ней и будет храниться вся история изменений. Лазить в эту папку лишний раз не стоит, менять в ней что-то вручную нельзя, удалять – тем более, потеряете всю историю. Просто знайте, что она существует и делает всю работу, хоть вы ее и не видите:
Дальнейшие действия вы можете выполнять для любого своего проекта MATLAB/Simulink. Просто выберите проект и скопируйте все его файлы в MyProject.
Я же для наглядности создам простейший проект с нуля, чтобы не отвлекать вас от сути.
Для начала создаем простейший скрипт sin_params.m, допустим, с параметрами модели:
A = 10;
w = pi / 2;И простейшую Симулинк-модель sin_model.slx:
Скачать скрипт и модель вы можете по ссылке.
Итак, мы имеем не что иное, как локальный репозиторий Git с нашим проектом. Осталось добавить ему истории!
Учёт изменений
Теперь посмотрим, как вы будете работать с Git каждый день.
Переходим в GitHub Desktop, в котором уже открыта наша папка с проектом. Это приложение скорее всего будет запущено у вас постоянно вместе с Матлабом.
Мы видим, что изменилось в вашем проекте – добавилось аж 6 новых файлов! При этом полезных из них только два – скрипт и модель, остальные файлы временные, их создал Симулинк для ускорения симуляции.
Примем простое правило: всякие временные и прочие левые файлы в историю изменений добавлять не надо. Добавляйте только те файлы, которые вы разрабатываете. А чтобы остальные не мешались, сразу добавим их в игнор Гита. Для этого выберем в меню Repository -> Repository settings…, в окошке выбираем Ignored files и вводим в текстовое поле следующее:
slprj
*.slxcТеперь Гит не будет обращать внимания на всю папку slprj и файлы с расширением slxc. А в списке добавленных файлов мы видим скрипт, модель и новый файл .gitignore, в котором и хранится список игнорируемых файлов.
Теперь давайте зафиксируем наши изменения проекта в истории. Как вы видите в списке, из изменений у нас – создание трех новых файлов.
В терминологии Гита фиксация любых изменений называется «коммит» (commit). Поэтому вместо «зафиксировать изменения» будем говорить просто «закоммитить», привыкайте.
Итак, галочками уже отмечены изменения, которые хотим закоммитить. Осталось придумать им ёмкое описание. Например, напишем: «Добавил скрипт с параметрами и модель». Что писать и на каком языке – решайте сами. Только помните, что названия коммитов помогут и пригодятся вам в будущем, потому не пишите откровенную ерунду.
После этого жмём кнопку Commit и тем самым сохраняем наши изменения в истории. На сами файлы проекта это никак не влияет. Просто изменения сохранены куда-то в недра в папки .git.
Теперь полюбуемся нашим коммитом в истории изменений на вкладке Commits. Вы можете посмотреть название коммита и что конкретно было изменено. Такое исследование истории никак не влияет на файлы проекта и не изменяет их. Считайте, что вы просто читаете логи.
Кстати, обратите внимание, что, когда Матлаб понимает, что в текущей папке есть контроль версий, он цветными иконками показывает статус файлов по сравнению с последним коммитом (не изменён, изменён, удален, конфликтует и т. д.). Это одна из фич интеграции MATLAB и Git:
Теперь поменяем параметры в нашем скрипте:
A = 10;
w = pi / 4;А в модели поменяем sin на cos. Не забываем сохранить.
Одна из стратегий работы с Гитом (которой не обязательно придерживаться) – делать отдельный коммит на каждое изменение. Так и поступим. Сначала пометим галочкой и закоммитим изменение скрипта, потом также поступим с моделью. История стала интереснее:
Анализ изменений
Теперь посмотрим, как Гит позволяет вспомнить, какие конкретно изменения были когда-то внесены в наш репозиторий.
Для этого выделим коммит, в котором мы меняли параметры, и приложение тут же показывает нам, что конкретно в этом текстовом файле поменялось:
А вот с моделью Симулинк это полноценно не сработает, потому что файл бинарный и Гит не может его расшифровать. Зато Матлаб сможет. В Матлабе кликаем правой кнопкой на модели в окне Current Folder и в меню выбираем Source Control -> Compare to Revision. Выбираем один из старых коммитов и жмем Compare to Local.
Открывается инструмент анализа изменений Simulink-модели. Все изменения показаны в дереве, и вы тут же можете посмотреть, как модель выглядела до и после изменения:
Заключение
Я думаю, этого пока достаточно. Мы рассмотрели самые-самые основы Git, чтобы вы просто могли начать. За кадром остались такие важные вопросы, как откат к старым версиям, отправка репозитория на сервер для совместной работы и не только.
Мы поговорим о них следующих статьях, если эта тема вам зайдет. Так что не стесняйтесь задавать вопросы в комментариях, делиться опытом и ставить плюсики. Спасибо за прочтение, все материалы можете скачать по ссылке.
Комментарии (22)
Indemsys
15.09.2021 22:54+1Однако есть сложные моменты которые играют против контроля версий
Первый момент в том что делать коммит после каждого мелкого изменения слишком напряжно и отвлекает от работы. Я скажем делаю коммиты после сильных рефакторингов раз в день. Но тогда сравнение таких версий становиться практически нецелесообразным, там невозможно или слишком трудозатратно в деталях увидеть что изменилось особенно в моделях Simulink и Stateflow.
Второй момент что MATLAB создает при кодогенерации значительно больше разнообразных временных файлов чем показано в статье. Т.е. огромный объем временной информации все равно попадет в коммит, это еще более затруднит анализ различий.
В третьих серьезные проекты имеют серьезные гигабайтные размеры. И системы контроля версий с такими размерами откатываются на предыдущие версии очень долго. Настолько долго что оперативное восстановление предыдущих версий будет длиться дольше чем просто вспомнить через другие каналы что с тех пор изменилось. Т.е. проще держать прошлые проекты в отдельной папке.В четвертых версии моделей с целью кодогенерации должны быть как-то синхронизированы с общим кодом фирмваре, т.е. с кодом программистов микроконтроллеров у которых свой контроль версий.
Словом в статье не затронуты проблемы масштабируемости и разнообразия юзкейсов и все представлено обманчиво гладко.
Я давно использую контроль версий, но только как архиватор где названия комитов выполняют роль комментариев. Но иногда досаждает что название коммитов уже нельзя отредактировать.
Вопрос можно ли в гите редактировать названия коммитов?
kozlyuk
15.09.2021 23:17Т.е. огромный объем временной информации все равно попадет в коммит, это еще более затруднит анализ различий.
Значит, нужно больше прописать в .gitignore (и использовать шаблоный для всех проектов).
В третьих серьезные проекты имеют серьезные гигабайтные размеры. И системы контроля версий с такими размерами откатываются на предыдущие версии очень долго.
Как правило, гигабайтные файлы --- бинарные, их восстановление --- практически копирование, вклад системы контроля версий минимальный. (Я не настоящий сварщик, но на самом деле, гигабайтные модели выглядят, как будто что-то пошло не так.) При необходимости быстро и много раз переключаться между несколькими версиями может быть удобнее через git worktree вытянуть каждую версию в отдельную папку (а потом удалить эти папки). Из-за природы git подтягивание изменений с большими бинарными файлами будет проблемой, это да, увы.
В четвертых версии моделей с целью кодогенерации должны быть как-то синхронизированы с общим кодом фирмваре, т.е. с кодом программистов микроконтроллеров у которых свой контроль версий.
Проблем не специфична для Simulink, она же возникает, когда разрабатываются несколько связанных сервисов, но поддерживать обратную совместимость API нецелесообразно. Идеального решения нет. Либо монорепозитарий, либо иметь головной проект, который подключает все остальные как субмодули, фиксируя набор их версий.
Вопрос можно ли в гите редактировать названия коммитов?
Можно (git commit --amend, git rebase -i), но не стоит. Скорее, вам нужны git notes.
zoldaten
16.09.2021 12:09сюда бы я еще добавил:
— необходимость контроля за разделением прав (кто-что и куда может «пушить», иначе можно «положить» весь проект)
— невозможность отслеживания сколько раз скачали репо, насколько он популярен(да, есть прообразы: forking и поставить звезду проекту, но не все знают и не все пользуются);
— помимо своего проекта, необходимо еще писать полноценное readme, контролировать gitignore, необходимость читать issues;
— issues, на которые надо тратить время и которые месяцами могут висеть без ответа, из-за чего пользователи пишут «it seems the project is dead»;
— доступ к github.com точно никогда не ограничат за размещение там «вдруг запрещенного контента»?
roslovets Автор
16.09.2021 14:24Это вы уже пишите про сайт GitHub,com и оформление репозитория для совместной работы. Эту тему тоже планирую осветить.
P.S. К сожалению, в свете последних событий блокировка гитхаба не кажется нереалистичным сценарием. Впрочем, на приложение GitHub Desktop из статьи это не повлияет.
roslovets Автор
16.09.2021 14:22Добавлю к тому, что написал kozlyuk.
С количеством коммитов важно найти золотую середину, как вам будет удобно работать. При рефакторинге я обычно делаю крупные коммиты, и мне там не особо интересно смотреть на все изменения, если проходят все тесты. При добавлении новых фич стараюсь делать по коммиту на каждую фичу или фикс - так потом проще составлять changelog/release notes.
Гигабайтные размеры это действительно проблема, рекомендую очень придирчиво относиться к тому, какие типы файлов вы коммитите, а какие отправляете в игнор. Папку годогенерации, например, со всеми мейк-файлами, бинарниками и т.д. я сразу добавляю в .gitignore. Скомпилированные прошивки - туда же. Если хотите хранить в гите сгенерированный код, лучше отдельно выдирать его из папки кодогенерации и хранить в отдельном репозитории. А сгенерированные бинарники либо прикладываете к релизу (функционал платформ GitHub/GitLab), либо храните просто в папочке, либо можно использовать специальные системы контроля версий для бинарников. Гит он все-таки больше для кода и легких файлов.
Синхронизацию кода между проектами гит тоже упрощает. Как минимум, у каждого коммита есть уникальный хеш-код, который, например, можно указывать в названии или версии прошивки.
Насчет того, что статья поверхностная, это вы верно заметили. В гите еще куча функций, заморочек, методик работы, хороших практик. Тут главное, не бояться начать, а дальше все приходит с практикой. Планирую раскрывать тему дальше в новых статьях.
Indemsys
16.09.2021 20:33Видите как все сразу усложнилось.
А слабо взять здесь сразу и перечислить конкретно все временные файлы MATLAB которые не надо хранить в репозитарии?
Или все же это рисеч и итерации на плечи тех кому вы советуете контроль версий?
А ведь системы резервного копирования все сделают быстрее.
И не надо ломать голову что поместить в .gitignore, а потом еще и следить не добавил ли MATLAB еще какие-нибудь тонны новых временных файлов и не ушли ли некоторые важные файлы касающиеся модели в сторонние директории, скажем актуальные конфигурации инструментов.roslovets Автор
17.09.2021 18:53+1Такой список уже составлен, он покрывает процентов 90% всех файлов: https://github.com/github/gitignore/blob/master/Global/MATLAB.gitignore
На самом деле все усложниться еще больше. Git действительно надо изучать, в том числе методом проб и ошибок. Я статью специально упростил, чтобы снизить порог входа для новичков. Ну и показать, что даже в своих небольших локальных проектах гит полезен.
Важно понимать, что контроль версий - это краеугольный инструмент для разработки. Вести без него даже средний проект на несколько человек это просто самоубийство. То есть можно конечно (что я вижу часто в инженерке), но это приводит к таким проблемам, что лучше весь отдел обучить гиту, чем потерять проект на полпути из-за того что на показательные испытания попала кривая прошивка непонятно кем, когда и из какого кода собранная, в результате устройство сломалось, а что чинить, не понятно (такое тоже видел).
Резервное копирование данных - еще один очень важный инструмент, но контроль версий он конечно не заменяет.
raamid
16.09.2021 02:03Все-таки git - это прежде всего для текстовых файлов, можно не только откатиться к старой версии, но и увидеть какие конкретно изменения были произведены. А если хранить в git бинарные файлы, то во-первых не видны изменения, во вторых очень быстро расходуется место на диске.
С другой стороны, удобство git - это возможность легкого обмена актуальной версией проекта. Доводилось мне передавать через git 100 мегабайтные файлы 3DMax, но скажу в свое оправдание, что основная моя работа была с кодом, а тяжелые файлы довелось редактировать всего 5-6 раз.
roslovets Автор
16.09.2021 14:27Когда модели симулинк были текстовыми файлами, было поприятнее)
Впрочем, и сейчас в качестве бинарников они весят мало, так что даже старые репозитории с большой историей не отъедают больше нескольких ГБ. А отслеживать изменения через интерфейс Simulink в принципе достаточно удобно, хоть и требует пары лишних телодвижений :)
timofeevka
16.09.2021 08:25Ну мы у себя в simintech тоже давно встроили меню вызова git клиента, но так что бы не сказал что это супервостребованная фича, но некоторые пользуются. Чаще git используют отдельно от рабочего софта. Но так дело полезное.
roslovets Автор
16.09.2021 14:29Я сам с гитом 95% времени работаю из приложения GitHub Desktop. Из матлаба разве что проверяю изменения в моделях и приложениях App Designer - тут других вариантов нет.
Вообще, как я понял, сейчас модно встраивать интеграцию с Git во все среды разработки :)
lumen_xp
16.09.2021 10:55Уважаемый коллега! Хотелось написать, не прошло и 10 лет. Но статья и инструмент очень полезны. Следует помнить, что матлабом для решения научных задач часто пользуются совсем не программисты, например физики и технари, они понятия не имеют об ООП и прочих вещах. А в статье прямо по полочкам разложена инструкция, что делать, что бы не потерять наработки и не прокосячить с версиями файлов, с которыми могут работать еще и коллеги.
Огромная благодарность Вам от не программистов, пытающихся решать инженерные и научные задачи при помощи программирования и имитационного моделирования.
qbertych
16.09.2021 12:17Ой. Учить инженеров гиту на примере бинарных файлов, да еще и без работы с удаленным репозиторием — это ну такое.
По моему опыту те, кто далек от программирования, лучше всего понимают гит с Sourcetree (который показывает разноцветные цепочки бранчей) и вот такой картинкой перед глазами:Скрытый текст
Не говоря о том, что гит уже давно интегрирован в Матлаб: он не только показывает статус файлов разноцветными кружками, но и умеет в commit, pull и все прочее. Поэтому при работе с Матлабом другие GUI не особо и нужны.roslovets Автор
16.09.2021 14:34Понимаю, о чем вы. В этой статье хотелось не научить полноценно работать с гитом (тут одной статьей не обойдешься), а объяснить инженерам, что гит им необходим, и помочь войти в тему. А дальше обязательно нужно рассказать про ветки и удаленные репозитории.
За рекомендацию Sourcetree спасибо, посмотрю, что там. А работать с гитом только из матлаба мне лично очень больно, не хотелось отпугивать новичков бесконечными контекстными меню :)
valgavchanin
16.09.2021 18:29суровым инженерам, которые программируют микроконтроллеры для самонаводящихся ракет, только и надо, что светить свой код в GitHub'e (принадлежит Microsoft'у если что).
roslovets Автор
16.09.2021 18:32Согласен, тем кто работает на военку противопоказано в принципе заливать свой код в интернет. Лучше использовать локальный GitLab.
К слову я о портале GitHub для хранения кода в статье ничего не писал. Наверно надо пояснить в тексте, что приложение GitHub Desktop никуда само код не отправляет.
GreySS
|как суровые инженеры, которые программируют микроконтроллеры для самонаводящихся |ракет
В тех местах одна система контроля версий — это Новая_папка, Новая_папка1, Новая_папка_от_Димы, Новая_папка_15092021
s1im
Новая_папка_от_Димы (Финальная! НЕ УДАЛЯТЬ), Новая_папка_от_Димы (Финальная2! НЕ УДАЛЯТЬ),