소스 코드 관리
분기 모델
PX4 프로젝트는 3가지 Git 분기 모델을 사용합니다.
리베이스를 통한 기록을 유지하며 Github 흐름을 배제합니다. 그러나, 전세계의 역동적인 개발팀과 수시로 병합 작업을 진행합니다.
새로운 기능을 추가하려면, Github에 가입한 다음 저장소를 포크하고, 새 브랜치를 생성하고, 변경 사항을 추가하고, 마지막으로 풀 리퀘스트를 전송합니다. 변경사항은 지속적 통합 테스트를 통과한 다음에 병합됩니다.
코드 기여는 BSD 3절 라이선스를 준수하여여 하며, 코드에는 사용에 제약 사항을 부과하지 않아야 합니다.
코드 스타일 형식
PX4는 코드 서식에 astyle을 사용합니다. 유효 버전은 다음과 같습니다.
astyle 2.06 (추천)
astyle 3.01 (추천)
설치가 완료되면, ./Tools/astyle/check_code_style_all.sh
에서 형식을 확인할 수 있습니다. 출력은 깨끗한 마스터 브랜치에서 형식 검사를 통과
하여야 합니다. 이 결과가 나왔다면, make format
을 사용하여 모든 파일을 자동으로 확인하고 포맷할 수 있습니다.
파일 명명법
다음 파일 명명 규칙을 따라야 합니다.
C++ 소스 파일의 이름은 CamelCase로 지정하고, 클래스 이름과 동일하여야 합니다. 예:
FooThing
이라는 클래스가 포함된 C++ 파일의 이름은FooThing.cpp
이어야 합니다.C++ 헤더 파일의 이름은
.hpp
접미사를 제외하고, 소스 파일과 동일하여야 합니다.C 호환이 필요한 C++ 헤더 파일에는 접미사
.h
가 있어야 합니다.폴더명은
modules
/drivers
/systemcmds
/etc 내의 첫 번째 수준에 대한snake_case
입니다. 그러나 소스 및 헤더 파일과 일치하도록 더 깊게 중첩되면 CamelCase로 이름을 지정하여야 합니다.테스트 파일에는
FooThingTest.cpp
와 같이Test
접미사가 있어야 합니다.위의 규칙에 대한 한 가지 예외는 MAVLink 메시지 이름과 일치하는 ALL_UPPERCASE.hpp인 src/modules/mavlink/streams의 MAVLink 스트림입니다.
소스 내 문서 작업
PX4 개발자는 소스 내에서 적절한 문서를 작성하는 것이 좋습니다.
현재 두 가지 소스 기반 문서 유형이 있습니다.
PRINT_MODULE_*
메소드는 두 모듈 런타임과 모듈 & 이 가이드의 명령 참조 사용 지침에 모두 사용됩니다.API는 여기 소스 코드에 문서화되어 있습니다.
좋은 예제로는 응용 프로그램/모듈 템플릿과 모듈 참조에서 링크된 파일이 있습니다.
가치가 추가되거나 중복되지 않는 다른 소스 문서를 권장합니다.
개발자는 목적을 유추할 수 있도록 C++ 엔터티(클래스, 함수, 변수 등)의 이름을 지정하여 명시적 문서의 필요성을 줄일 수 있습니다.
C++ 엔티티 이름에서 쉽게 가정할 수 있는 문서를 추가하지 마십시오.
일반적으로 특이 사항이나 오류 처리에 대한 정보를 추가할 수 있습니다.
필요시에는 Doxgyen 태그를 사용합니다.
@class
,@file
,@param
,@return
,@brief
,@var
,@see
,@note
. 좋은 예는 src/modules/events/send_event.h입니다.
커밋과 커밋 메시지
사소한 변경에 대하여도 자세한 설명한 여러 단락 커밋 메시지를 기록하십시오. 쉽게 이해할 수 있는 한 줄 요약과 자세한 세부정보도 기록하십시오.
****git commit -s
**를 사용하여 모든 커밋을 승인합니다. ** 이렇게 하면 signed-off-by:
가 추가됩니다. 마지막 줄에 이름과 이메일을 입력합니다.
이 커밋 가이드는 Linux 커널과 Linus Torvalds가 관리하는 프로젝트에 대한 모범 사례들을 참고로 작성되었습니다.
Last updated