Altium Designer를 사용한 하드웨어를 위한 Git 소개

소개

몇 년 전, 저는 잠시 동안 힙하고 카페인이 가득한 스타트업 환경에서 일하다가 좀 더 경험이 풍부한 회사의 엔지니어링 직무로 전환했습니다. 그때 저는 기술 문화와 도구 사이의 이항 연결을 깨달았습니다. 우리가 생각하는 방식과 우리가 일하는 방식은 우리에게 제공되는 도구에 의해 형성되며, 우리의 필요와 관습이 우리가 선택하는 도구에 영향을 미칩니다.

제가 일했던 새로운 회사는 3D 프린터, 사내 버그 추적 소프트웨어, 심지어 좋은 CMS에도 익숙하지 않았습니다. 모든 것이 다소 구식이었습니다. 이것은 제 동료들과 저의 일상적인 창작물에 상당한 영향을 미쳤습니다.

예를 들어, 지난 수십 년 동안 업계는 TO220 패키지에서 D2PAK으로 전환되었습니다. 동시에, 엔지니어들은 JBC가 제조한 고출력 납땜 인두와 같은 도구를 갖추게 되었습니다.

장비가 잘 갖춰진 실험실에 접근할 수 있는 젊은 엔지니어가 이번 십년에 TO220에 있는 어떤 인기 있는 IC를 고려할까요? 저는 그렇지 않다고 생각합니다. 마지막 세대의 납땜 인두가 있다면 D2PAK을 다루는 것이 훨씬 쉽고, 나사, 와셔, 절연 포일을 다루는 번거로움이 없습니다. 이 간단한 변화는 엔지니어가 현대 기준으로 더 미적으로 매력적인 제품을 만들 수 있는 평평한 보드를 설계하도록 유도할 수 있습니다.

Git은 전체 산업을 뒤집은 드문 예입니다. 십 년 전, 소프트웨어 엔지니어링 관리자들은 빠르게 움직이고 문제를 일으키는 접근 방식을 채택하는 것을 미친 짓으로 여겼을 것입니다. 하드웨어와 PCB 설계를 위한 Git은 리비전 추적, 버전 제어, 설계 변경 사항을 되돌리는 것을 가능하게 함으로써 개발자들이 오픈 소스 프로젝트에 대한 노력을 항상 인정받고 검증받을 수 있도록 해주었습니다. 이는 Git blame이라는 기능 덕분입니다. 십 년 전, 오픈 소스 프로젝트에 대한 기여를 인정받는 것은 정치에 달려 있었습니다. 이러한 모든 예는 우리가 Git에 감사할 수 있는 변화들입니다.

본질적으로 전자 산업은 소프트웨어보다 느리게 움직이지만, 많은 혁신이 우리의 일상 업무로 스며들고 있습니다. Altium Designer®는 올해 Altium 365®와 Concord Pro™의 도입으로 업계를 선도하고 있으며, 다른 중요한 플레이어들은 때때로 십 년 전에 출시된 기능으로 겨우 따라잡고 있습니다. 하드웨어와 PCB 설계를 위한 Git은 그 변화를 주도하는 기술 중 하나입니다.

Git이란?

매우 간단하게, Git은 버전 제어 시스템(VCS)입니다. 소프트웨어 개발자들이 코드 변경 사항을 추적하고 관리하기 위해 사용하는 소프트웨어(기본 프로토콜과 데이터 형식 포함)입니다. 이번 십년에 소프트웨어 개발자로 일한다면, 데스크탑에 폴더를 복제하여 시도해보는 대신, 대부분 Git 기반의 VCS를 사용할 것입니다.

Git은 소프트웨어 개발에서 코드 변경 사항을 추적하는 데 대단히 인기가 있지만, 어떤 파일 세트의 변경 사항을 추적하는 데에도 사용될 수 있습니다. 이 파일들은 코드를 포함할 필요가 없으며, PCB 설계 파일, 설계 문서, PCB 제조 파일 및 프로젝트에 필요한 기타 파일일 수 있습니다. 하드웨어를 위한 Git은 기계 설계, PCB 설계, 펌웨어 등에 Git 생태계를 자연스럽게 확장한 것입니다.

Git은 상업적 사용을 위해 무료로 제공됩니다. 이는 오픈 소스이며 GNU 일반 공중 사용 허가서에 따라 배포됩니다. 각 Git 디렉토리는 별도의 엔터티이며 자체적으로 항목의 전체 이력을 포함하는 저장소입니다. Git 저장소에 배치된 모든 파일은 누가, 언제, 각 비트까지 완전히 추적할 수 있습니다. Git 저장소는 네트워크 접근을 요구하지 않으며, 각 저장소는 원격이라는 이름의 서버와 완전히 독립적입니다.

그러므로 현재 세계에서 가장 인기 있는 VCS가 Git이라는 것은 놀랄 일이 아닙니다. 대부분의 시장 점유율 분석에서 Git이 75% 이상을 차지하고 있으며, 가장 인기 있는 대안인 SVN은 2012년 이후로 감소하고 있습니다. SVN(Altium Designer에서도 지원하는 레거시 VCS)을 요구하는 구인 공고의 수도 감소하는 추세입니다 반면 Git은 인기를 얻고 있습니다.

Git의 역사

Git은 2005년 리눅스 커널의 창시자이자 개발자인, 전설적인 인물인 리누스 토발즈에 의해 만들어지고 작성되었습니다. 리눅스 커뮤니티는 BitKeeper라는 상업 소프트웨어의 무료 사용권을 부여받았습니다. 2005년 4월, BitKeeper의 저자는 리눅스 팀의 주요 멤버이자 Samba 파일 서버의 발명가인 Andrew Tridgell이 BitKeeper 프로토콜을 (주장되는 바에 따르면) 역공학을 기반으로 한 오픈 소스 클라이언트 작업을 시작한 후 라이선스를 철회했습니다. BitKeeper 라이선스는 역공학을 명시적으로 금지합니다.

따라서 리누스 토발즈는 BitKeeper에 상당히 영감을 받았지만, 남아 있는 대안 중에서 그의 요구 사항을 충족시킬 만한 것이 없다고 판단하여 자신만의 버전 관리 시스템을 만들기로 결정했습니다.

토발즈는 당시 사용되고 있던 인기 있는 CVS(Concurrent Version Systems)와 매우 다른 새로운 소프트웨어가 될 것이라고 결정했습니다. 그는 현재 시스템이 패치를 적용하는 데 오랜 시간이 걸릴 수 있으며, 팀과 동기화할 때 한 번에 수백 개의 패치를 적용해야 했기 때문에 그들의 성능이 턱없이 부족하다는 것을 깨달았습니다. 그는 다음과 같은 일련의 요구 사항을 제시했습니다:

• BitKeeper가 가능하게 한 분산 워크플로우와 유사합니다. 사용자는 오프라인으로 작업하고 나중에 동기화할 수 있어야 합니다.
• 데이터 손상과 같은 사고로부터 보호됩니다
• 악의적인 공격으로부터 안전합니다
• 2초 미만으로 패치를 계산할 수 있어야 합니다

Git 작업은 2005년 4월 초에 시작되었습니다. 2005년 6월 16일, 소프트웨어가 급하게 필요했던 이유인 리눅스 커널의 버전 2.6.12가 출시되었습니다. 그 후 Git의 개발 및 유지 관리는 개발에 기여하고 여전히 기여하며 소프트웨어를 사용하기 쉽게 만든 것으로 널리 인정받는 Junio Amano에게 넘겨졌습니다. Git 1.0은 2005년 12월에 출시되었습니다.

네이밍 컨벤션

왜 Git인가? 적어도 이상한 이름입니다! 영국에서 대부분의 사람들이 알고 있듯이, 이 용어는 종종 조금 천박하거나, 옥스퍼드 온라인 사전에 따르면 "불쾌하거나 경멸적인 사람"을 의미하는 데 사용됩니다. 추가적으로 보고된 의미로는 "바보" (18세기에서 19세기 슬랭 (영국)) 또는 "사생아" (18세기 중반에서 19세기 슬랭 (미국)), 이 둘 모두 세상을 바꿀 예술 작품을 만들기 위해 숨어 있는 외로운 천재의 신화에 아주 시적으로 어울립니다.

Torvalds는 그의 시스템을 "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보다 배우고 사용하기가 훨씬 더 복잡한 경향이 있으며, 이는 부분적으로 Git이 훨씬 더 강력하고 효율적이기 때문입니다.

다행히도 Altium Designer와 Concord Pro는 이러한 문제의 대부분을 해결합니다. 명령 줄을 통해 Git의 강력한 기능에 완전히 접근할 수 있는 동시에, Concord Pro의 사용자 인터페이스와 엄격한 통합이 작업을 쉽고 직관적으로 만듭니다. 동시에 Altium 365는 서버 측 문제를 모두 처리합니다.

하드웨어용 Git은 어떻게 작동하나요?

Git은... 매우 이상하게 느껴질 수 있습니다! 주로, 명명법은 많은 엔지니어들이 익숙해진 클래식한 복사-붙여넣기, 압축 및 이메일과는 상당히 다른 워크플로우를 반영합니다.

브랜치(그리고 병합)

브랜치 모델은 SVN과 같은 다른 VCS와 Git을 구분하는 가장 인기 있는 기능 중 하나입니다. Git은 여러 개의 브랜치를 가질 수 있으며, 이는 로컬과 원격 모두에 해당됩니다. 나무의 가지가 줄기에서나 서로에서 갈라지듯이, Git 브랜치도 다른 브랜치에서 싹튼다. 나무의 "줄기" 또는 주 브랜치는 master라고 합니다. 브랜치는 쉽게 생성, 병합, 삭제할 수 있습니다. 이러한 작업이 어떻게 작동하는지는 다음과 같습니다:

• 각 브랜치는 독립적이며, 원격으로 작업할 때 다른 사람의 발등을 밟을 필요가 없습니다. 자신만의 여러 브랜치를 가질 수도 있으며, 각 브랜치는 자신의 소프트웨어 또는 하드웨어 디자인의 약간 다른 변형을 포함하고 있으며, 파일을 수동으로 닫고 다시 열지 않고도 같은 디렉토리 내에서 전환할 수 있습니다.
• 소프트웨어 세계에서는 master라고 하는 생산 브랜치와 develop이라고 하는 두 번째 작업 진행 중인 브랜치를 가지고, 필요한 새 기능과 수정을 위해 많은 작은 브랜치를 가지는 것이 경험칙입니다. 하드웨어 프로젝트에도 같은 접근 방식을 취할 수 있습니다. 실제로, 하드웨어를 위한 PCB 디자인과 다른 프로젝트를 전문으로 하는 많은 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 브랜치에서 파생됩니다. 준비가 되면 develop만이 마스터로 병합될 수 있습니다.

분산화와 속도

Git은 여러 가지 이유로 다른 버전 관리 시스템보다 빠릅니다. 각 사용자는 원본 저장소를 클론할 수 있으며, 커밋은 정기적으로 로컬 브랜치에 수행되고 원격으로는 덜 자주 전송될 수 있습니다. 분산화되지 않은 다른 VCS는 원격 서버의 용량에 제한을 받으며, 모든 요청을 충족시키기 위해 상당히 느려져야 합니다.

이 로컬 우선 접근 방식은 파일이 상당히 클 수 있는 전자 산업에서 특히 중요합니다. PCB 디자인은 수백 개의 3D 바디를 포함할 경우 파일 크기가 수십 메가바이트에 이를 수 있습니다. 반면, 소스 코드 파일은 대부분 몇 백 킬로바이트에 불과합니다.

제가 마지막으로 근무했던 회사에서는 VPN을 통해 접근할 수 있는 본사에 호스팅된 SVN 저장소가 있었으며, 프로젝트 파일과 문서를 저장하는 데 사용되었습니다. 어떤 작업이든 영원히 걸리는 것 같았고, 우리의 제한된 인터넷 연결은 수천 개의 파일을 관리하기 위한 모든 요청으로 자주 막혔습니다.

Git은 또한 C 언어로 작성되어 있어, 다른 고급 언어에 비해 오버헤드가 최소화됩니다. 작업에 따라 Git은 SVN보다 몇 배에서 수백 배 더 빠를 수 있습니다.

분산화되고 오프라인 우선 접근 방식은 또한 Git을 네트워크에 훨씬 가볍게 만듭니다. 귀사가 광대역에 접근할 수 없더라도, 점심 시간이나 퇴근 후에 데이터를 푸시할 수 있으며, 일상 업무에서 성능 손실이 없습니다.

Concord Pro에서는 인터넷 연결에 접근할 수 있을 때 Altium 365의 모든 혜택을 누릴 수 있으며, Altium Designer 라이선스를 로밍하고 오프라인으로 계속 작업할 수 있습니다.

스테이징 영역

Git을 사용할 때 파일이 버전 관리 하에 실제로 있을 수 있다고 간주되기 전에 세 단계를 거친다는 것을 인식하는 것이 중요합니다:

1. Untracked
2. Staged
3. Committed

Untracked는 파일이 디스크에 존재하지만 버전 관리 시스템 밖에 있다는 것을 의미합니다. Untracked 파일은 그 다음 staged 될 수 있는데, 이는 버전 관리 시스템에 추가되었지만 아직 커밋되지 않았다는 것을 의미합니다. 이 시점에서, staged된 변경 사항을 커밋할 수 있습니다. 스테이징 시스템은 커밋을 준비하기 위해 사용되지만, 주로 명령줄 작업에서 사용되는 기능입니다.

Altium을 통해 Git을 사용할 때, 작업을 단순화하는 그래픽 사용자 인터페이스 덕분에 서버에 변경 사항을 저장할 때 스테이징 접근 방식이 자동으로 백그라운드에서 적용됩니다.

저장소 생성하기

새 프로젝트를 생성할 때 서버 측에서 저장소가 자동으로 생성됩니다. 아래 창에서 Fermium LTD 작업 공간 내에서 템플릿을 사용하여 새 PCB 프로젝트를 생성하고 있습니다. 프로젝트를 생성하는 즉시, 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은 PCB 디자이너들에게 버전 관리, 공유 및 리비전 관리를 위한 포괄적인 워크플로우를 제공합니다. 이 인기 있는 시스템은 현대 프로그래머들의 문화를 형성하는 데 도움을 주었습니다. 이제 Altium Designer® 및 Altium 365® 플랫폼을 통해 디자이너들은 PCB 설계를 위한 Git 기능에 접근할 수 있습니다.

오늘 Altium 365의 시험판을 시작하여 예제 프로젝트가 포함된 전자 개발의 21세기 스타일을 완전히 경험해 보세요. 더 궁금한 점이 있으신가요? 오늘 Altium의 전문가와 대화하세요.