# 1. Git 기반 소스코드 형상 관리 및 오픈소스 기여 워크플로우

PX4-Autopilot은 일개 기업이 폐쇄적으로 찍어내는 공산품이 아니다. 전 세계 대학 랩과 모빌리티 기업 소속의 수천 명의 천재들이 하나의 코드 베이스(Codebase)를 향해 수만 개의 패치(Patch)를 동시다발적으로 폭격하는 아비규환의 글로벌 오픈소스 전장이다. 이 거대한 지적 자산의 타워가 붕괴하지 않고 오히려 정밀하게 진화할 수 있는 유일한 매커니즘은, 분산 버전 제어 시스템의 제왕인 **Git(깃)**의 철벽같은 형상 관리 이데올로기 덕분이다.

제어기 코드 한 줄을 수정하고 기체에 올리는 개발자라면, 단순히 코딩을 잘하는 것을 넘어 이 거대한 Git의 격자망 안에서 어떻게 소스를 조작하고 파생시키고 최종적으로 Main 스트림에 융합시킬 것인지 그 작전술을 터득해야 한다. 서브모듈(Submodule)의 지뢰밭 회피법부터 Pull Request(PR) 승인을 위한 컨벤션(Convention)까지 실무적 워크플로우를 분석한다.

서브모듈(Git Submodule) 아키텍처: 분리된 우주들의 묶음
초보자가 PX4 다운로드를 흉내 내며 가장 흔히 저지르는 죽음의 오타는 git clone https://github.com/PX4/PX4-Autopilot.git 이라고만 입력하고 끝내는 행위다. 들어가서 빌드를 때리면 즉시 수천 개의 “디렉토리 없음” 에러 폭격을 맞는다.
PX4의 본체 폴더는 আসলে(사실상) 빈 껍데기에 불과하다. 그 내장(Intestines)인 NuttX 운영체제, MAVLink 통신 프로토콜, EKF2 수학 엔진, uAVCAN 칩 드라이버들은 전부 독립된 별도의 깃 레포지토리들이며, PX4 본체는 단지 이 외부 우주들의 특정 시간표 커밋 해시(Commit Hash) 번호표만을 Submodule 형태로 들고 있을 뿐이다.
반드시 git submodule update --init --recursive 명령을 발포하여 텅 빈 디렉토리 안쪽으로 원격 본체들을 소환해 채워 넣어야 한다. 브랜치(Branch)를 옮겨 다닐 때마다 이 서브모듈 동기화 펌프질을 까먹으면, 구형 MAVLink 헤더와 신형 PX4 파서가 충돌하여 피의 빌드 에러 파티가 열리게 된다.

분기(Branching) 모델과 기능 개발 주기
소스 코드의 수정을 가할 때는 절대 성역인 main 브랜치에 직접 총창을 꽂지 말라.

1. 로컬 격리망 생성: git checkout -b feature/my_custom_controller 로 독립적인 작업 평행우주를 만들어 내라.
2. 세분화된 커밋: 한 번에 수천 줄을 엎고 “작업 끝” 커밋 하나를 날리는 것은 리뷰어에 대한 테러 행위다. 쪼갤 수 있는 최소한 논리적 모듈별 단위로 커밋 객체를 조각내어(git add -p), 시간의 흐름을 지문처럼 남겨라.
3. Rebase 융합 지향: 내 코딩이 끝났다고 바로 푸시하지 마라. 그 며칠 사이 세계 어딘가의 누군가가 이미 수십 개의 코드를 main에 꽂아 넣었을 것이다. git fetch origin 후 git rebase origin/main 을 단행하여, 내 코드가 최신 지구촌 타임라인 선상에서 충돌(Conflict) 없이 융합되는지 스스로 피를 흘려가며 충돌 해결(Conflict Resolution)을 완수해야 한다.

이후 GitHub에 브랜치를 푸시하고 **Pull Request(PR)**를 올리면, 수백 개의 샌드박스 서버(CI 버추얼 머신)가 동시에 깨어나 당신의 코드를 컴파일하고, SITL 시뮬레이터 수백 대의 드론을 띄워 추락 여부를 검증한다. 이 지옥의 관문을 100% 에러 없이 통과한 코드만이 커미터(Committer)의 축복 아래 비로소 인류의 공통 자산(Main Repo)으로 합병(Merge) 조치 되는 것이다.