Введение в Git для аппаратного обеспечения с Altium Designer

Введение

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

Новая компания, где я работал, не была привыкшей к 3D-принтерам, внутреннему программному обеспечению для отслеживания ошибок или даже к хорошей системе управления контентом (CMS). Все это было довольно старомодно. Это оказало значительное влияние на то, что мы с коллегами создавали каждый день.

Примером может служить последние пару десятилетий, когда индустрия перешла от корпусов TO220 к D2PAK. В то же время инженеры оснастили себя паяльниками с высокой пиковой мощностью, такими как производимые JBC.

Рассмотрел бы молодой инженер, имеющий доступ к хорошо оснащенной лаборатории, какой-либо популярный ИС в корпусе TO220 в этом десятилетии? Я так не думаю. Работать с D2PAK гораздо проще, не нужно возиться с винтами, шайбами и изоляционной фольгой, если у вас есть паяльник последнего поколения. Это простое изменение может направить инженера на проектирование более плоских плат, что часто может привести к созданию более эстетичных продуктов по современным стандартам.

Git является редким примером инструмента, который полностью перевернул целую индустрию. Десять лет назад менеджеры по разработке программного обеспечения считали бы сумасшедшими тех, кто принимает подход действуй быстро и ломай вещи. Git для аппаратного и PCB-дизайна сделал это возможным, позволяя отслеживать изменения, контролировать версии и откатывать изменения в дизайне. Разработчики теперь уверены, что их усилия по проектам с открытым исходным кодом всегда могут быть признаны и проверены благодаря функции, называемой Git blame. Десять лет назад признание за вклад в проекты с открытым исходным кодом оставалось за политикой. Это все примеры изменений, за которые мы можем поблагодарить Git.

Хотя по своей природе электронная индустрия развивается медленнее, чем программное обеспечение, многие инновации постепенно проникают в нашу повседневную работу. Altium Designer®, с введением Altium 365® и Concord Pro™ в этом году, лидирует в индустрии, в то время как другие ключевые игроки стараются не отставать, иногда с функциями, выпущенными более десяти лет назад. Git для аппаратного и PCB-дизайна - одна из технологий, стимулирующих этот изменение.

Что такое Git?

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

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

Git свободно доступен для коммерческого использования. Он является открытым исходным кодом и распространяется под лицензией GNU General Public License. Каждый каталог Git является отдельной сущностью и сам по себе представляет собой репозиторий, содержащий полную историю своих элементов. Каждый файл, помещенный в репозиторий Git, полностью отслеживаем до каждого бита, кем и когда. Репозитории Git не требуют доступа к сети, при этом каждый репозиторий полностью независим от сервера(ов), которые называются удаленными.

Поэтому неудивительно, что в настоящее время он является самой популярной системой управления версиями в мире. Большинство анализов доли рынка показывают, что доля Git превышает 75%, а самая популярная альтернатива, SVN, находится в упадке с 2012 года. Количество вакансий, требующих SVN (устаревшая система управления версиями, также поддерживаемая Altium Designer) также сокращается, в то время как популярность Git растет.

История Git

Git был создан и написан в 2005 году Линусом Торвальдсом, человеком, легендой, создателем и разработчиком ядра Linux, для отслеживания собственной разработки ядра. Сообществу Linux было предоставлено бесплатное использование коммерческого программного обеспечения под названием BitKeeper. В апреле 2005 года автор BitKeeper отозвал лицензию после того, как выдающийся член команды Linux и изобретатель файлового сервера Samba, Эндрю Триджелл, начал работу над клиентом с открытым исходным кодом, основанным на (предположительно) реверс-инжиниринге протокола BitKeeper. Лицензия BitKeeper явно запрещала реверс-инжиниринг.

Таким образом, Линус Торвальдс решил создать собственную систему управления версиями, не очень слабо вдохновленную BitKeeper, поскольку ни одна из оставшихся альтернатив не соответствовала его требованиям.

Торвальдс решил, что новое программное обеспечение будет сильно отличаться от популярных в то время CVS (Concurrent Version Systems). Он понял, что текущие системы могут тратить много времени на применение патчей, и поскольку ему нужно было применять сотни патчей одновременно при синхронизации со своей командой, их производительность была далека от приемлемой. Он выдвинул ряд требований:

• Распределенный рабочий процесс, аналогичный тому, что позволял BitKeeper. Пользователь должен иметь возможность работать офлайн и синхронизироваться позже.
• Защита от несчастных случаев, таких как повреждение данных
• Защита от злонамеренных атак
• Возможность вычисления патчей менее чем за две секунды

Работа над созданием Git началась в начале апреля 2005 года. 16 июня 2005 года была выпущена версия 2.6.12 ядра Linux, ради которой программное обеспечение было срочно нужно. Затем разработка и поддержка Git были переданы Джунио Амано, который внес и продолжает вносить вклад в его развитие и широко признан за делание программного обеспечения удобным в использовании; Git версии 1.0 был выпущен в декабре 2005 года.

Система именования

Почему Git? Странное имя, по меньшей мере! Как многие люди в Великобритании знают, этот термин часто применяется к кому-то, кто немного нахален или, согласно Оксфордскому онлайн-словарю, "неприятный или презренный человек". Кроме того, сообщается, что значения включают "дурак" (сленг 18-го до 19-го века (Великобритания)) или "незаконнорожденный ребенок" (сленг середины 18-го до 19-го века (США)), оба из которых вполне поэтично вписываются в его миф о одиноком гениальном отшельнике, прячущемся, чтобы создать произведение искусства, которое изменит мир.

Торвальдс дал несколько причин для названия своей системы "Git", которое можно выбрать в зависимости от того, что пользователь чувствует в данный день, или, возможно, как он себя чувствовал в разные моменты при написании системы! Он часто описывает его как "глупый трекер содержимого" в официальной документации, и определение Git как:

• "Случайная комбинация из 3 букв, которую нельзя произнести".
• Неправильное произношение слова "get"!
• Глобальный информационный трекер, если он работает по плану
• Глупый, презренный и отвратительный, когда не работает.

О, юмор программистов.

Недостатки

Git не идеален, однако, и имеет некоторые недостатки. Сложная для понимания структура данных и странная номенклатура без сомнения в их числе. Это включает Git для аппаратных проектов, где применяется та же структура файлов и операции.

Cherry-picking, Checkout, Index, Clone, Push, Stash, Pull/Pull Request, Tag, Upstream, Fork, Rebase, Origin, Fetch и HEAD (всегда пишется заглавными буквами, не знаю почему) - вот некоторые из самых странных терминов, которые вы можете встретить в мире программного обеспечения.

Может быть сложно понять, как настроить репозиторий как серверное программное обеспечение, и понять отношения между локальными и удаленными репозиториями наряду с операциями для их синхронизации. Git, как правило, гораздо сложнее в изучении и использовании, чем SVN, частично из-за того, что он гораздо более мощный и эффективный.

К счастью, Altium Designer и Concord Pro берут на себя большинство из этих проблем. Пока у нас есть полный доступ к мощности Git через командную строку, пользовательский интерфейс и строгая интеграция Concord Pro делают его использование легким и интуитивно понятным. В то же время, Altium 365 берет на себя все серверные проблемы.

Как работает Git для аппаратного обеспечения?

Git может показаться... очень странным! Номенклатура, в основном, отражает рабочий процесс, который существенно отличается от классического копирования и вставки, архивирования и отправки по электронной почте, к которым многие инженеры привыкли.

Ветвление (и слияние)

Модель ветвления, пожалуй, самая популярная особенность, которая отличает Git от других систем управления версиями, таких как SVN. В Git может быть несколько веток, как локальных, так и удаленных. Как ветви дерева разделяются от ствола или друг от друга, так и ветки Git отходят от других веток. "Ствол" дерева, или основная ветка, называется master. Ветки можно легко создавать, объединять и удалять. Вот как работают эти операции:

• Каждая ветка независима, и при удаленной работе вам не придется мешать другим. Вы даже можете иметь несколько веток самостоятельно, каждая ветка содержит немного разную версию вашего собственного программного или аппаратного обеспечения, и их можно переключать в одной и той же директории без необходимости закрывать и вновь открывать файлы вручную.
• В мире программного обеспечения правилом хорошего тона является наличие производственной ветки, называемой master, и второй ветки, находящейся в разработке, называемой develop, а также столько мелких веток, сколько необходимо для новых функций и исправлений. Тот же подход можно применить к аппаратным проектам. Фактически, на GitHub есть множество репозиториев с дизайнами печатных плат и другими проектами, специально для аппаратного обеспечения.
• Не все ветки должны быть объединены в ветку master. Часто разработчики понимают, что новая функция не является гениальной идеей, и ветку можно просто удалить, когда она больше не нужна.

[Режим ботаника ВКЛ]

Так как же работает эта умная функция? Ветка, по сути, является указателем на коммит. Коммит — это набор изменений файлов, добавлений или удалений, отправленных в репозиторий. Коммит имеет 40-символьную криптографическую контрольную сумму SHA-1, которая записывается в файл. Каждый коммит также включает указатель на родительский коммит, от которого он произошел.

Есть много дополнительных промежуточных шагов, например, файлы преобразуются в контрольные суммы двоичных блобов и организуются в директории через двоичное дерево. Также вычисляется контрольная сумма дерева. Поскольку все хешируется криптографически, нет возможности изменить (или испортить) данные или историю без изменения хеша последнего коммита. Криптографическое хеширование делает историю Git относительно постоянной, так что будьте вежливы при написании сообщений коммитов!

[Режим ботаника ВЫКЛ]

Рабочие процессы в Git для аппаратного обеспечения

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

Среди наиболее популярных, модель *Централизованного рабочего процесса* часто используется людьми, которые имеют опыт работы с централизованными системами управления версиями, когда они начинают использовать Git (который является *децентрализованным*) в первый раз. Модель *Централизованного рабочего процесса* почти исключительно полагается на ветку master, куда все коммиты отправляются и откуда извлекаются, заставляя Git имитировать поведение SVN и удаленных файловых систем.

Рабочий процесс с использованием ветвления функционала является эволюцией *Централизованного рабочего процесса*. Разработка ведется на отдельных ветках, которые затем сливаются с мастер-веткой. Я являюсь энтузиастом этой модели в электронной инженерии и с нетерпением жду, когда Altium объявит о поддержке ветвления, чтобы воспользоваться ею. Примеры веток функционала могут быть “fix_current_generator_oscillation”, “upgrade_microcontroller”, “lower_power_consumption” или “reduce_thermal_drift”.

В рабочем процессе GitFlow, возможно, самом сложном среди популярных рабочих процессов, мастер-ветка содержит только полные версии дизайна, можно думать о ней как о board_v_1.0, board_v_1.1 и т. д. Разработка ведется на отдельной ветке под названием develop, и от нее отходят ветки функционала и исправлений. Только ветка develop может быть слияна с мастер-веткой, когда она готова.

Децентрализация и скорость

Git работает быстрее других систем управления версиями по нескольким причинам. Каждый пользователь может клонировать оригинальный репозиторий, и коммиты могут регулярно делаться в локальные ветки и отправляться на удаленный сервер менее часто. Другие VCS, которые не так децентрализованы, ограничены возможностями удаленного сервера, который должен значительно замедляться, чтобы удовлетворить все их запросы.

Этот подход с приоритетом локальной работы особенно важен в электронной промышленности, так как файлы могут быть довольно большими. Не редкость, когда дизайн печатной платы занимает десятки мегабайт, особенно с сотнями 3D-моделей. Файлы исходного кода, с другой стороны, обычно занимают всего несколько сотен килобайт.

В последней компании, где я работал, у нас был репозиторий SVN, размещенный в главном офисе, доступный через VPN, где мы хранили файлы проектов и документацию. Любая операция занимала вечность, и наше ограниченное интернет-соединение часто перегружалось всеми запросами по управлению тысячами файлов.

Git также написан на языке C, что означает минимальные накладные расходы по сравнению с другими языками высокого уровня. В зависимости от операции, Git может быть от нескольких раз до сотен раз быстрее, чем SVN.

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

На Concord Pro вы можете наслаждаться всеми преимуществами Altium 365, когда у вас есть доступ к интернету, а затем перенести лицензию Altium Designer и продолжить работу в оффлайне.

Промежуточные области

При работе с Git важно понимать, что файлы проходят три стадии, прежде чем они действительно могут быть считаться находящимися под контролем версий:

1. Неотслеживаемые
2. Подготовленные
3. Зафиксированные

Неотслеживаемые — это когда файл существует на диске, но находится вне системы контроля версий. Затем неотслеживаемый файл может быть подготовлен, что означает его добавление в систему контроля версий, но ещё не зафиксирован. На этом этапе подготовленные изменения могут быть зафиксированы. Система подготовки используется для подготовки к фиксации, но эта функция используется в основном при работе через командную строку.

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

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

Репозитории автоматически создаются на стороне сервера, когда вы создаёте новый проект. В окне ниже я создаю новый проект печатной платы из шаблона в моём рабочем пространстве Fermium LTD. Как только я создам проект, он будет доступен в моём рабочем пространстве Altium 365, и платформа автоматически создаст Git-репозиторий для нового проекта.

Начальная настройка репозитория

Репозитории, созданные с помощью Concord Pro, автоматически настраиваются, так что в репозиторий Git проекта уже зафиксированы только необходимые файлы, в то время как локальные резервные копии и LOG-файлы не включены. Обычно необходимо было бы соответствующим образом настроить файл ".Gitignore" и позаботиться о том, чтобы не фиксировать ненужные файлы, но Concord Pro заботится об этом.

Настройка учётных данных

Для доступа к репозиториям Git обычно необходимо настроить SSH-ключи и учётные данные пользователя как на стороне сервера, так и на стороне клиента. Concord Pro автоматически заботится об этом, когда добавляется новый пользователь.

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

Клонирование - это процесс, с помощью которого Git создает локальную копию удаленного репозитория. Вручную клонировать большие репозитории с бинарными файлами, такими как файлы PcbDoc и SchDoc, обычно требует экспертного уровня работы с командной строкой Git. Altium Designer и Concord Pro автоматически клонируют репозиторий на ваш локальный компьютер в фоновом режиме, когда вы открываете удаленный проект.

Разрешение конфликтов и сравнение изменений

Concord Pro позволяет сравнивать изменения между различными ревизиями, как локальными, так и удаленными, через панель управления хранилищем. В следующем примере я добавил объект текстовой заметки и зафиксировал изменения локально, но не отправил их в удаленный репозиторий.

Это предоставляет нам полный функционал, необходимый на платформе Git для аппаратного обеспечения.

Заключение

Git является мощным инструментом, и git для аппаратного обеспечения предоставляет конструкторам печатных плат комплексный рабочий процесс для контроля версий, обмена и управления ревизиями. Эта популярная система помогла сформировать культуру современных программистов. Теперь с Altium Designer® и платформой Altium 365® конструкторы могут использовать функции Git для проектирования печатных плат.

Вы можете начать пробную версию Altium 365 сегодня, которая загружена примерами проектов, чтобы полностью ощутить разработку электроники в стиле 21-го века. Есть вопросы? Обратитесь к эксперту Altium сегодня.