Комментарии 22
В тех местах одна система контроля версий — это Новая_папка, Новая_папка1, Новая_папка_от_Димы, Новая_папка_15092021
Однако есть сложные моменты которые играют против контроля версий
Первый момент в том что делать коммит после каждого мелкого изменения слишком напряжно и отвлекает от работы. Я скажем делаю коммиты после сильных рефакторингов раз в день. Но тогда сравнение таких версий становиться практически нецелесообразным, там невозможно или слишком трудозатратно в деталях увидеть что изменилось особенно в моделях Simulink и Stateflow.
Второй момент что MATLAB создает при кодогенерации значительно больше разнообразных временных файлов чем показано в статье. Т.е. огромный объем временной информации все равно попадет в коммит, это еще более затруднит анализ различий.
В третьих серьезные проекты имеют серьезные гигабайтные размеры. И системы контроля версий с такими размерами откатываются на предыдущие версии очень долго. Настолько долго что оперативное восстановление предыдущих версий будет длиться дольше чем просто вспомнить через другие каналы что с тех пор изменилось. Т.е. проще держать прошлые проекты в отдельной папке.
В четвертых версии моделей с целью кодогенерации должны быть как-то синхронизированы с общим кодом фирмваре, т.е. с кодом программистов микроконтроллеров у которых свой контроль версий.
Словом в статье не затронуты проблемы масштабируемости и разнообразия юзкейсов и все представлено обманчиво гладко.
Я давно использую контроль версий, но только как архиватор где названия комитов выполняют роль комментариев. Но иногда досаждает что название коммитов уже нельзя отредактировать.
Вопрос можно ли в гите редактировать названия коммитов?
Т.е. огромный объем временной информации все равно попадет в коммит, это еще более затруднит анализ различий.
Значит, нужно больше прописать в .gitignore (и использовать шаблоный для всех проектов).
В третьих серьезные проекты имеют серьезные гигабайтные размеры. И системы контроля версий с такими размерами откатываются на предыдущие версии очень долго.
Как правило, гигабайтные файлы --- бинарные, их восстановление --- практически копирование, вклад системы контроля версий минимальный. (Я не настоящий сварщик, но на самом деле, гигабайтные модели выглядят, как будто что-то пошло не так.) При необходимости быстро и много раз переключаться между несколькими версиями может быть удобнее через git worktree вытянуть каждую версию в отдельную папку (а потом удалить эти папки). Из-за природы git подтягивание изменений с большими бинарными файлами будет проблемой, это да, увы.
В четвертых версии моделей с целью кодогенерации должны быть как-то синхронизированы с общим кодом фирмваре, т.е. с кодом программистов микроконтроллеров у которых свой контроль версий.
Проблем не специфична для Simulink, она же возникает, когда разрабатываются несколько связанных сервисов, но поддерживать обратную совместимость API нецелесообразно. Идеального решения нет. Либо монорепозитарий, либо иметь головной проект, который подключает все остальные как субмодули, фиксируя набор их версий.
Вопрос можно ли в гите редактировать названия коммитов?
Можно (git commit --amend, git rebase -i), но не стоит. Скорее, вам нужны git notes.
— необходимость контроля за разделением прав (кто-что и куда может «пушить», иначе можно «положить» весь проект)
— невозможность отслеживания сколько раз скачали репо, насколько он популярен(да, есть прообразы: forking и поставить звезду проекту, но не все знают и не все пользуются);
— помимо своего проекта, необходимо еще писать полноценное readme, контролировать gitignore, необходимость читать issues;
— issues, на которые надо тратить время и которые месяцами могут висеть без ответа, из-за чего пользователи пишут «it seems the project is dead»;
— доступ к github.com точно никогда не ограничат за размещение там «вдруг запрещенного контента»?
Добавлю к тому, что написал kozlyuk.
С количеством коммитов важно найти золотую середину, как вам будет удобно работать. При рефакторинге я обычно делаю крупные коммиты, и мне там не особо интересно смотреть на все изменения, если проходят все тесты. При добавлении новых фич стараюсь делать по коммиту на каждую фичу или фикс - так потом проще составлять changelog/release notes.
Гигабайтные размеры это действительно проблема, рекомендую очень придирчиво относиться к тому, какие типы файлов вы коммитите, а какие отправляете в игнор. Папку годогенерации, например, со всеми мейк-файлами, бинарниками и т.д. я сразу добавляю в .gitignore. Скомпилированные прошивки - туда же. Если хотите хранить в гите сгенерированный код, лучше отдельно выдирать его из папки кодогенерации и хранить в отдельном репозитории. А сгенерированные бинарники либо прикладываете к релизу (функционал платформ GitHub/GitLab), либо храните просто в папочке, либо можно использовать специальные системы контроля версий для бинарников. Гит он все-таки больше для кода и легких файлов.
Синхронизацию кода между проектами гит тоже упрощает. Как минимум, у каждого коммита есть уникальный хеш-код, который, например, можно указывать в названии или версии прошивки.
Насчет того, что статья поверхностная, это вы верно заметили. В гите еще куча функций, заморочек, методик работы, хороших практик. Тут главное, не бояться начать, а дальше все приходит с практикой. Планирую раскрывать тему дальше в новых статьях.
Видите как все сразу усложнилось.
А слабо взять здесь сразу и перечислить конкретно все временные файлы MATLAB которые не надо хранить в репозитарии?
Или все же это рисеч и итерации на плечи тех кому вы советуете контроль версий?
А ведь системы резервного копирования все сделают быстрее.
И не надо ломать голову что поместить в .gitignore, а потом еще и следить не добавил ли MATLAB еще какие-нибудь тонны новых временных файлов и не ушли ли некоторые важные файлы касающиеся модели в сторонние директории, скажем актуальные конфигурации инструментов.
Такой список уже составлен, он покрывает процентов 90% всех файлов: https://github.com/github/gitignore/blob/master/Global/MATLAB.gitignore
На самом деле все усложниться еще больше. Git действительно надо изучать, в том числе методом проб и ошибок. Я статью специально упростил, чтобы снизить порог входа для новичков. Ну и показать, что даже в своих небольших локальных проектах гит полезен.
Важно понимать, что контроль версий - это краеугольный инструмент для разработки. Вести без него даже средний проект на несколько человек это просто самоубийство. То есть можно конечно (что я вижу часто в инженерке), но это приводит к таким проблемам, что лучше весь отдел обучить гиту, чем потерять проект на полпути из-за того что на показательные испытания попала кривая прошивка непонятно кем, когда и из какого кода собранная, в результате устройство сломалось, а что чинить, не понятно (такое тоже видел).
Резервное копирование данных - еще один очень важный инструмент, но контроль версий он конечно не заменяет.
можно откатить коммит как минимум
Все-таки git - это прежде всего для текстовых файлов, можно не только откатиться к старой версии, но и увидеть какие конкретно изменения были произведены. А если хранить в git бинарные файлы, то во-первых не видны изменения, во вторых очень быстро расходуется место на диске.
С другой стороны, удобство git - это возможность легкого обмена актуальной версией проекта. Доводилось мне передавать через git 100 мегабайтные файлы 3DMax, но скажу в свое оправдание, что основная моя работа была с кодом, а тяжелые файлы довелось редактировать всего 5-6 раз.
Когда модели симулинк были текстовыми файлами, было поприятнее)
Впрочем, и сейчас в качестве бинарников они весят мало, так что даже старые репозитории с большой историей не отъедают больше нескольких ГБ. А отслеживать изменения через интерфейс Simulink в принципе достаточно удобно, хоть и требует пары лишних телодвижений :)
Ну мы у себя в simintech тоже давно встроили меню вызова git клиента, но так что бы не сказал что это супервостребованная фича, но некоторые пользуются. Чаще git используют отдельно от рабочего софта. Но так дело полезное.
Уважаемый коллега! Хотелось написать, не прошло и 10 лет. Но статья и инструмент очень полезны. Следует помнить, что матлабом для решения научных задач часто пользуются совсем не программисты, например физики и технари, они понятия не имеют об ООП и прочих вещах. А в статье прямо по полочкам разложена инструкция, что делать, что бы не потерять наработки и не прокосячить с версиями файлов, с которыми могут работать еще и коллеги.
Огромная благодарность Вам от не программистов, пытающихся решать инженерные и научные задачи при помощи программирования и имитационного моделирования.
По моему опыту те, кто далек от программирования, лучше всего понимают гит с Sourcetree (который показывает разноцветные цепочки бранчей) и вот такой картинкой перед глазами:
Не говоря о том, что гит уже давно интегрирован в Матлаб: он не только показывает статус файлов разноцветными кружками, но и умеет в commit, pull и все прочее. Поэтому при работе с Матлабом другие GUI не особо и нужны.
Понимаю, о чем вы. В этой статье хотелось не научить полноценно работать с гитом (тут одной статьей не обойдешься), а объяснить инженерам, что гит им необходим, и помочь войти в тему. А дальше обязательно нужно рассказать про ветки и удаленные репозитории.
За рекомендацию Sourcetree спасибо, посмотрю, что там. А работать с гитом только из матлаба мне лично очень больно, не хотелось отпугивать новичков бесконечными контекстными меню :)
суровым инженерам, которые программируют микроконтроллеры для самонаводящихся ракет, только и надо, что светить свой код в GitHub'e (принадлежит Microsoft'у если что).
MATLAB + Git: как управлять изменениями скриптов и моделей Simulink без бардака и боли