Wprowadzenie do Git dla sprzętu z Altium Designer

Wstęp

Kilka lat temu tymczasowo przeszedłem z pracy w hipernowoczesnym startupie do pracy inżynierskiej w bardziej doświadczonej firmie. Wtedy zdałem sobie sprawę z dwumianowego połączenia między kulturą techniczną a narzędziami. To, jak myślimy i jak pracujemy, jest kształtowane przez dostępne nam narzędzia, ponieważ nasze potrzeby i zwyczaje wpływają na wybór narzędzi, których używamy.

Nowa firma, w której pracowałem, nie była przyzwyczajona do drukarek 3D, wewnętrznego oprogramowania do śledzenia błędów czy nawet dobrego systemu CMS. Wszystko to było dość staromodne. Miało to znaczący wpływ na to, co codziennie tworzyli moi koledzy i ja.

Przykładem może być ostatnie kilka dekad, kiedy to branża przeszła od obudów TO220 do D2PAK. W tym samym czasie inżynierowie wyposażyli się w lutownice o wysokiej mocy szczytowej, takie jak te produkowane przez JBC.

Czy młody inżynier mający dostęp do dobrze wyposażonego laboratorium w ogóle rozważyłby użycie popularnego układu scalonego w obudowie TO220 w tej dekadzie? Nie sądzę. Praca z D2PAKami jest znacznie łatwiejsza, nie trzeba się bawić w śruby, podkładki i izolacyjną folię, pod warunkiem że ma się lutownicę ostatniej generacji. Ta prosta zmiana może skłonić inżyniera do projektowania płaskich płyt, co często prowadzi do tworzenia bardziej estetycznie przyjemnych produktów według współczesnych standardów.

Git jest rzadkim przykładem narzędzia, które całkowicie odmieniło całą branżę. Dziesięć lat temu menedżerowie inżynierii oprogramowania uznani byliby za szaleńców za przyjęcie podejścia działaj szybko i psuj rzeczy. Git dla sprzętu i projektowania PCB umożliwił śledzenie rewizji, kontrolę wersji i cofanie zmian w projektach. Dzięki temu deweloperzy mają pewność, że ich wysiłki na rzecz projektów open-source zawsze mogą być przypisane i zweryfikowane, dzięki funkcji zwanej Git blame. Dekadę temu, bycie rozpoznanym za swój wkład w projekty open-source było kwestią polityki. To wszystko przykłady zmian, za które możemy dziękować Gitowi.

Chociaż z natury rzeczy branża elektroniczna rozwija się wolniej niż oprogramowanie, wiele innowacji stopniowo przenika do naszej codziennej pracy. Altium Designer®, wprowadzając w tym roku zarówno Altium 365® jak i Concord Pro™, wyznaczył kierunek w branży, z którym inni ważni gracze starają się nadążyć, czasami z funkcjami wydanymi ponad dekadę temu. Git dla sprzętu i projektowania PCB jest jedną z technologii napędzających tę zmianę.

Czym jest Git?

W bardzo prostych słowach, Git to system kontroli wersji (VCS). To oprogramowanie (włączając w to protokoły i formaty danych), używane przez programistów do śledzenia i zarządzania zmianami w kodzie. Jeśli jesteś programistą pracującym w tej dekadzie, nie duplikujesz folderów na swoim pulpicie, aby coś wypróbować, najprawdopodobniej używasz VCS opartego na Git.

Chociaż Git jest niezwykle popularny do śledzenia zmian w kodzie podczas tworzenia oprogramowania, można go używać do śledzenia zmian w dowolnym zestawie plików. Pliki te nie muszą zawierać kodu, mogą to być twoje pliki projektowe PCB, dokumentacja projektowa, pliki produkcyjne PCB i wszelkie inne pliki, których potrzebujesz do swojego projektu. Git dla sprzętu jest naturalnym rozszerzeniem ekosystemu Git na projektowanie mechaniczne, projektowanie PCB, firmware i wiele więcej.

Git jest dostępny za darmo do użytku komercyjnego. Jest to oprogramowanie open-source i jest dystrybuowane na licencji GNU General Public License. Każdy katalog Git jest oddzielną jednostką i sam w sobie jest repozytorium zawierającym kompletną historię swoich elementów. Każdy plik umieszczony w repozytorium Git jest w pełni śledzalny do każdego bitu, przez kogo i kiedy. Repozytoria Git nie wymagają dostępu do sieci, przy czym każde repozytorium jest całkowicie niezależne od serwera(ów), które przyjmują nazwę zdalnych.

Nie powinno więc dziwić, że obecnie jest to najpopularniejszy system kontroli wersji (VCS) na świecie. Większość analiz udziału w rynku pokazuje Git powyżej 75%, a najpopularniejsza alternatywa, SVN, jest w spadku od 2012 roku. Liczba wolnych miejsc pracy wymagających SVN (starszy system kontroli wersji, również wspierany przez Altium Designer) również maleje, podczas gdy popularność Git rośnie.

Historia Git

Git został stworzony i napisany w 2005 roku przez Linusa Torvaldsa, człowieka, legendę, twórcę i programistę jądra Linux, aby śledzić rozwój własnego jądra. Społeczność Linuxa otrzymała darmowy dostęp do komercyjnego oprogramowania o nazwie BitKeeper. W kwietniu 2005 roku autor BitKeepera wycofał licencję po tym, jak wybitny członek zespołu Linuxa i wynalazca serwera plików Samba, Andrew Tridgell, zaczął pracować nad klientem open-source opartym na (rzekomo) zreverse-inżynierowanym protokole BitKeepera. Licencja BitKeepera wyraźnie zabrania reverse-engineeringu.

W związku z tym Linus Torvalds zdecydował się stworzyć własny system kontroli wersji, luźno inspirowany BitKeeperem, ponieważ żadna z pozostałych alternatyw nie była nawet bliska spełnieniu jego wymagań.

Torvalds zdecydował, że nowe oprogramowanie będzie bardzo różne od popularnych wówczas systemów CVS (Concurrent Version Systems). Zdał sobie sprawę, że obecne systemy mogą potrzebować dużo czasu na zastosowanie łatek, a ponieważ musiał aplikować setki łatek naraz podczas synchronizacji ze swoim zespołem, ich wydajność była daleka od akceptowalnej. Wymyślił serię wymagań:

• Rozproszony przepływ pracy podobny do tego, co umożliwiał BitKeeper. Użytkownik powinien być w stanie pracować offline i synchronizować się później.
• Ochrona przed wypadkami takimi jak uszkodzenie danych
• Bezpieczeństwo przed złośliwymi atakami
• Możliwość obliczenia łatek w mniej niż dwie sekundy

Prace nad pisanie Git rozpoczęły się na początku kwietnia 2005 roku. 16 czerwca 2005 roku została wydana wersja 2.6.12 jądra Linuxa, co było powodem, dla którego oprogramowanie było pilnie potrzebne. Rozwój i utrzymanie Git zostały następnie przekazane Junio Amano, który przyczynił się i nadal przyczynia do jego rozwoju, i jest powszechnie uznawany za osobę, która uczyniła oprogramowanie łatwym w użyciu; Git w wersji 1.0 został wydany w grudniu 2005 roku.

Konwencja nazewnictwa

Dlaczego Git? Dziwna nazwa, delikatnie mówiąc! Jak większość ludzi w Wielkiej Brytanii wie, termin ten często jest przypisywany komuś, kto jest trochę bezczelny lub, według Oxford Online Dictionary, "nieprzyjemna lub godna pogardy osoba". Dodatkowo zgłaszane znaczenia to "głupiec" (slang z XVIII do XIX wieku (UK)) lub "nieślubne dziecko" (slang z połowy XVIII do XIX wieku (USA)), oba pasują dość poetycko do jego mitu samotnego geniusza pustelnika, ukrywającego się, aby stworzyć dzieło sztuki, które zmieni świat.

Torvalds podał kilka powodów nazwania swojego systemu "Git", które można wybrać w zależności od tego, co użytkownik czuje danego dnia, lub prawdopodobnie jak się czuł w różnych momentach pisania systemu! Często opisuje go jako "głupi śledzik treści" w oficjalnej dokumentacji, a definicja Git to:

• "Losowe połączenie 3 liter, których nie da się wymówić".
• Błędna wymowa "get"!
• Globalny śledzik informacji, jeśli działa zgodnie z planem
• Głupi, godny pogardy i nikczemny, gdy nie działa.

Ach, humor programistów.

Wady

Git nie jest jednak doskonały i ma pewne wady. Trudna do zrozumienia struktura danych i dziwna nomenklatura są bez wątpienia wśród nich. Dotyczy to również Git dla projektów sprzętowych, gdzie wymuszona jest ta sama struktura plików i operacje.

Cherry-picking, Checkout, Index, Clone, Push, Stash, Pull/Pull Request, Tag, Upstream, Fork, Rebase, Origin, Fetch i HEAD (zawsze pisane wielkimi literami, nie mam pojęcia dlaczego) to niektóre z najdziwniejszych terminów, jakie można znaleźć w świecie oprogramowania.

Może być trudno zrozumieć, jak skonfigurować repozytorium jako oprogramowanie po stronie serwera, oraz zrozumieć relację między repozytoriami lokalnymi i zdalnymi wraz z operacjami, aby je zsynchronizować. Git ma tendencję do bycia znacznie bardziej skomplikowanym niż SVN do nauki i użytkowania, częściowo ze względu na to, że jest znacznie bardziej potężny i wydajny.

Na szczęście, Altium Designer i Concord Pro radzą sobie z większością tych problemów. Chociaż mamy pełny dostęp do mocy Git przez linię poleceń, interfejs użytkownika i ścisła integracja Concord Pro sprawiają, że obsługa jest łatwa i intuicyjna. W tym samym czasie, Altium 365 radzi sobie ze wszystkimi problemami po stronie serwera.

Jak działa Git dla sprzętu?

Git może wydawać się... bardzo dziwny! Terminologia, przede wszystkim, odzwierciedla przepływ pracy, który znacznie różni się od klasycznego kopiowania, wklejania, kompresowania i wysyłania e-maili, do których wielu inżynierów jest przyzwyczajonych.

Branżowanie (i Scalanie)

Model branżowania to być może najpopularniejsza funkcja, która odróżnia Git od innych systemów kontroli wersji, takich jak SVN. Git może mieć wiele gałęzi, zarówno lokalnych, jak i zdalnych. Podobnie jak gałąź drzewa rozgałęzia się z pnia lub z innej gałęzi, tak gałęzie Gita wyrastają z innych gałęzi. "Pień" drzewa, czyli główna gałąź, nazywana jest master. Gałęzie można łatwo tworzyć, scalać i usuwać. Oto jak działają te operacje:

• Każda gałąź jest niezależna i, pracując zdalnie, nie musisz wchodzić nikomu w drogę. Możesz nawet mieć wiele gałęzi samodzielnie, każda gałąź zawierająca nieco inną wersję własnego projektu oprogramowania lub sprzętu, i można je przełączać w tym samym katalogu bez konieczności zamykania i ponownego otwierania plików ręcznie.
• W świecie oprogramowania zasadą jest posiadanie gałęzi produkcyjnej, nazywanej master, i drugiej gałęzi będącej w trakcie prac, nazywanej develop, oraz tyle małych gałęzi, ile potrzeba na nowe funkcje i poprawki. To samo podejście można zastosować w projektach sprzętowych. W rzeczywistości istnieje wiele repozytoriów GitHub z projektami PCB i innymi projektami specjalnie dla sprzętu.
• Nie wszystkie gałęzie muszą być scalane z gałęzią master. Często deweloperzy stwierdzają, że nowa funkcja nie jest wcale takim przebłyskiem geniuszu i gałąź można po prostu usunąć, gdy nie jest już potrzebna.

[Tryb nerdowski WŁĄCZONY]

Więc jak działa ta sprytna funkcja? Gałąź to w zasadzie wskaźnik do commita. Commit to zestaw zmian plików, dodatków lub usunięć wprowadzonych do repozytorium. Commit ma 40-znakowy kryptograficzny sum kontrolny SHA-1, który jest zapisywany do pliku. Każdy commit zawiera również wskaźnik do commita rodzica, od którego pochodzi.

Istnieje wiele dodatkowych pośrednich kroków, na przykład pliki są konwertowane na sumy kontrolne binarne bloby i organizowane w katalogach za pomocą drzewa binarnego. Obliczana jest również suma kontrolna drzewa. Ponieważ wszystko jest kryptograficznie hashowane, nie ma możliwości zmiany (lub uszkodzenia) danych lub historii bez zmiany sumy kontrolnej ostatniego commita. Kryptograficzne hashowanie sprawia, że historia Gita jest do pewnego stopnia trwała, więc bądź uprzejmy, pisząc wiadomości commitów!

[Tryb nerdowski WYŁĄCZONY]

Przepływy pracy w Gicie dla sprzętu

Dzięki rozproszonej naturze Gita dla sprzętu i zaawansowanemu systemowi branżowania, jak również wielu innym funkcjom, użytkownicy mogą przyjąć dowolny przepływ pracy.

Wśród najpopularniejszych, model *Centralised Workflow* jest często używany, gdy ludzie, którzy mają doświadczenie z centralizowanym systemem kontroli wersji, zaczynają używać Gita (który jest *zdecentralizowany*) po raz pierwszy. Model *Centralised Workflow* opiera się prawie wyłącznie na gałęzi master, gdzie wszystkie commity są pushowane i fetchowane, sprawiając, że Git naśladuje zachowanie SVN i zdalnych systemów plików.

Workflow Feature Branching jest ewolucją *Centralizowanego Workflow*. Prace rozwojowe są prowadzone na oddzielnych gałęziach, które następnie są scalane z gałęzią główną. Jestem entuzjastycznym zwolennikiem tego modelu w inżynierii elektronicznej i z niecierpliwością czekam, aż Altium ogłosi wsparcie dla gałęzi, aby móc z tego skorzystać. Przykłady gałęzi funkcji mogą obejmować “fix_current_generator_oscillation”, “upgrade_microcontroller”, “lower_power_consumption” lub “reduce_thermal_drift”.

W workflow GitFlow, być może najbardziej skomplikowanym wśród popularnych workflow, gałąź główna zawiera tylko kompletne wydania projektu, można to sobie wyobrazić jako board_v_1.0, board_v_1.1, itd. Rozwój odbywa się na oddzielnej gałęzi zwanej develop, a funkcje i poprawki wychodzą z gałęzi develop. Tylko develop może być scalany z gałęzią główną, gdy jest gotowy.

Decentralizacja i szybkość

Git jest szybszy niż inne systemy kontroli wersji z kilku powodów. Każdy użytkownik może sklonować oryginalne repozytorium, a zmiany mogą być regularnie wprowadzane do lokalnych gałęzi i wysyłane do zdalnego repozytorium rzadziej. Inne systemy kontroli wersji, które nie są tak zdecentralizowane, są ograniczone przez pojemność zdalnego serwera, który musi znacznie zwolnić, aby zaspokoić wszystkie ich żądania.

To podejście lokalne jest szczególnie ważne w przemyśle elektronicznym, ponieważ pliki mogą być dość duże. Nie jest rzadkością, aby projekt PCB zajmował dziesiątki megabajtów, zwłaszcza przy setkach obiektów 3D. Pliki źródłowe z drugiej strony zazwyczaj mają kilkaset KBajtów.

W ostatniej firmie, dla której pracowałem, mieliśmy repozytorium SVN znajdujące się w głównym biurze, dostępne przez VPN, gdzie przechowywaliśmy pliki projektowe i dokumentację. Wykonywanie jakiejkolwiek operacji trwało wieki, a nasze ograniczone połączenie internetowe było często zapchane przez wszystkie żądania zarządzania tysiącami plików.

Git jest również napisany w języku C, co oznacza, że jego narzut jest minimalny w porównaniu z innymi językami wysokiego poziomu. W zależności od operacji, Git może być od kilku do setek razy szybszy niż SVN.

Zdecentralizowane podejście offline sprawia również, że Git jest znacznie lżejszy dla sieci. Nawet jeśli Twoja firma nie ma dostępu do szerokopasmowego internetu, możesz wysłać dane w porze lunchu lub po pracy, bez utraty wydajności w codziennej pracy.

Na Concord Pro możesz cieszyć się wszystkimi korzyściami Altium 365, kiedy masz dostęp do połączenia internetowego, a następnie przenieść swoją licencję Altium Designer i kontynuować pracę offline.

Obszary stagingowe

Pracując z Gitem, istotne jest zrozumienie, że pliki przechodzą przez trzy etapy, zanim można je rzeczywiście uznać za objęte kontrolą wersji:

1. Nieśledzone (Untracked)
2. Zgromadzone (Staged)
3. Zatwierdzone (Committed)

Nieśledzone oznacza, że plik istnieje na dysku, ale jest poza systemem kontroli wersji. Nieśledzony plik może następnie zostać zgromadzony, co oznacza, że został dodany do systemu kontroli wersji, ale jeszcze nie zatwierdzony. W tym momencie zgromadzone zmiany mogą zostać zatwierdzone. System zgromadzeń jest używany do przygotowania do zatwierdzenia, ale funkcja ta jest używana głównie w operacjach z linii poleceń.

Korzystając z Gita przez Altium, dzięki graficznemu interfejsowi użytkownika, który upraszcza operacje, podejście zgromadzeń jest stosowane automatycznie w tle, gdy zapisujesz zmiany na serwerze.

Tworzenie repozytorium

Repozytoria są automatycznie tworzone po stronie serwera, gdy tworzysz nowy projekt. W poniższym oknie tworzę nowy projekt PCB z szablonu w mojej przestrzeni roboczej Fermium LTD. Gdy tylko utworzę projekt, będzie on dostępny w mojej przestrzeni roboczej Altium 365, a platforma automatycznie utworzy repozytorium Git dla nowego projektu.

Początkowa konfiguracja repozytorium

Repozytoria utworzone za pomocą Concord Pro są automatycznie konfigurowane, więc tylko niezbędne pliki są już zatwierdzone w repozytorium Git projektu, podczas gdy lokalne kopie zapasowe i pliki LOG nie są. Zwykle konieczne byłoby odpowiednie skonfigurowanie pliku o nazwie ".Gitignore" oraz dbanie o niezatwierdzanie niepotrzebnych plików, ale Concord Pro zajmuje się tym.

Konfiguracja poświadczeń

Do dostępu do repozytoriów Git, zazwyczaj konieczne jest skonfigurowanie kluczy SSH i poświadczeń użytkownika zarówno po stronie serwera, jak i klienta. Concord Pro zajmuje się tym automatycznie, gdy dodawany jest nowy użytkownik.

Klonowanie repozytoriów

Klonowanie to proces, przez który Git replikuje zdalne repozytorium do lokalnej kopii. Ręczne klonowanie dużych repozytoriów z plikami binarnymi, takimi jak pliki PcbDoc i SchDoc, zwykle wymagałoby zaawansowanej obsługi Git z linii poleceń. Altium Designer i Concord Pro automatycznie klonują repozytorium na lokalny komputer w tle, gdy otwierasz zdalny projekt.

Rozwiązywanie konfliktów i porównywanie zmian

Concord Pro pozwala porównywać zmiany między różnymi rewizjami, zarówno lokalnymi, jak i zdalnymi, za pomocą panelu menedżera magazynu. W poniższym przykładzie dodałem obiekt notatki tekstowej i zatwierdziłem zmiany lokalnie, ale nie wysłałem ich do zdalnego repozytorium.

To daje nam pełną funkcjonalność potrzebną na platformie Git dla sprzętu.

Wnioski

Git jest potężnym narzędziem, a git dla sprzętu daje projektantom PCB kompleksowy przepływ pracy do kontroli wersji, udostępniania i zarządzania rewizjami. Ten popularny system pomógł ukształtować kulturę współczesnych programistów. Teraz dzięki Altium Designer® i platformie Altium 365®, projektanci mogą korzystać z funkcji Git dla projektowania PCB.

Możesz dzisiaj rozpocząć próbę Altium 365, załadowaną przykładowymi projektami, aby w pełni doświadczyć elektronicznego rozwoju w stylu XXI wieku. Masz więcej pytań? Porozmawiaj z ekspertem z Altium już dziś.