Linux Kernel은 전 세계 수천 명의 개발자가 동시에 개발하는 초대형 오픈소스 프로젝트입니다. 이러한 프로젝트에서는 수정된 파일 전체를 전달하는 대신 패치(Patch) 라는 변경 내역만 공유하는 방식이 사용됩니다.
커널 개발자는 새로운 기능을 추가하거나 버그를 수정한 뒤 Git Commit을 만들고, 이를 Patch 파일로 변환하여 메일링 리스트(Linux Kernel Mailing List, LKML)에 제출합니다.
패치는 단순한 텍스트 파일이 아니라 어떤 파일이 어떻게 변경되었는지 기록한 변경 이력입니다.
이번 글에서는 Linux Kernel 패치의 개념부터 diff, git diff, git format-patch, git apply, git am의 차이와 실무 활용법까지 자세히 알아보겠습니다.
Linux Kernel 패치란?
패치(Patch)는 기존 소스 코드에서 변경된 내용만 기록한 파일입니다.
기본 구조는 다음과 같습니다.
Original Source
↓
Code Modify
↓
Patch 생성
↓
Patch 적용
↓
Updated Source전체 소스를 다시 배포하지 않고 변경된 부분만 전달할 수 있습니다.
왜 Patch를 사용할까?
커널은 매우 큰 프로젝트입니다.
예를 들어 한 줄만 수정했다고 전체 소스를 전달하는 것은 매우 비효율적입니다.
패치를 사용하면
- 변경 내용만 공유
- 코드 리뷰 용이
- 버전 관리 편리
- 충돌 확인 가능
- 이메일 전송 가능
등의 장점이 있습니다.
diff 명령으로 Patch 생성
가장 기본적인 방법은 diff 명령입니다.
예시
diff -u old.c new.c > fix.patch생성된 Patch는 다음과 같은 구조를 가집니다.
--- old.c
+++ new.c
@@ -5,3 +5,4 @@
printf("Hello");
+printf("Linux");+는 추가된 줄,
-는 삭제된 줄을 의미합니다.
git diff
Git에서는 git diff를 사용합니다.
git diff특정 파일만 비교하려면
git diff kernel/sched/core.c현재 수정된 내용을 Patch 형태로 확인할 수 있습니다.
Patch 저장
Patch 파일로 저장하려면
git diff > scheduler.patch이후 다른 개발자에게 전달하면 됩니다.
git format-patch
커널 개발에서는 가장 많이 사용하는 명령입니다.
git format-patch HEAD~1생성 결과
0001-fix-scheduler-bug.patch이 Patch에는
- Commit Message
- Author
- Date
- 변경 내용
까지 모두 포함됩니다.
format-patch의 구조
대표적인 구조
Commit Message
↓
Author
↓
Date
↓
Diff
↓
Signed-off-by단순한 diff보다 훨씬 많은 정보를 포함합니다.
여러 Commit을 Patch로 만들기
최근 3개의 Commit
git format-patch HEAD~3특정 브랜치 비교
git format-patch main여러 개의 Patch 파일이 생성됩니다.
Patch 적용
기본 Patch는
git apply fix.patch로 적용합니다.
이 방식은 Commit 정보는 복원하지 않습니다.
git am
Kernel 개발에서는 대부분
git am 0001-fix.patch을 사용합니다.
이 방식은
- Commit Message
- Author
- Date
- Commit Hash
등을 최대한 유지하면서 적용합니다.
git apply와 git am의 차이
| 명령 | 특징 |
|---|---|
| git apply | 변경 내용만 적용 |
| git am | Commit까지 복원 |
커널 개발에서는 git am 사용이 일반적입니다.
Patch 충돌
Patch 적용 중 충돌이 발생할 수도 있습니다.
예시
Patch failed
↓
Conflict
↓
Manual Fix
↓
Continue충돌 해결 후
git am --continue를 실행합니다.
취소하려면
git am --abort를 사용합니다.
Patch 확인
적용 전 확인
git apply --check fix.patch문제가 없다면 출력 없이 종료됩니다.
Patch 통계
변경된 줄 수 확인
git diff --stat예시
kernel/sched/core.c
12 insertions
4 deletions어떤 파일이 얼마나 변경되었는지 확인할 수 있습니다.
Signed-off-by
커널에서는 대부분 다음 문구를 포함합니다.
Signed-off-by: Hong Gil Dong <hong@example.com>이는 개발자가 해당 코드를 제출할 권리가 있음을 확인하는 서명입니다.
자동 추가하려면
git commit -s를 사용합니다.
Patch 제출 과정
Kernel Patch는 일반적으로 다음 순서로 제출합니다.
Modify Source
↓
Commit
↓
format-patch
↓
Review
↓
Email (LKML)
↓
Review Feedback
↓
MergeGitHub Pull Request가 아닌 메일링 리스트를 사용하는 것이 Linux Kernel의 특징입니다.
실무에서 자주 사용하는 명령어
현재 변경 확인
git diffPatch 생성
git diff > fix.patchCommit 기반 Patch 생성
git format-patch HEAD~1Patch 적용
git apply fix.patchCommit 포함 적용
git am 0001.patchPatch 확인
git apply --check fix.patchPatch 통계
git diff --stat실무 사례
예를 들어 스케줄러 버그를 수정했다고 가정해 보겠습니다.
실무에서는 다음과 같은 순서로 작업합니다.
kernel/sched/core.c수정git diff로 변경 내용 확인git commit -s로 커밋 생성git format-patch HEAD~1실행- 생성된 Patch 파일을 LKML에 제출
- 리뷰어 피드백 반영
- 수정 후 새로운 Patch 버전(v2, v3 등) 생성
- 최종 승인 후 메인라인 커널에 병합
이처럼 Linux Kernel 개발에서는 Patch 중심의 협업 방식이 표준으로 사용됩니다.
자주 묻는 질문
git diff와 git format-patch의 차이는 무엇인가요?
git diff는 단순히 변경 내용을 보여주거나 저장하는 기능입니다. 반면 git format-patch는 Commit 정보, 작성자, 날짜, Commit 메시지까지 포함한 정식 Patch 파일을 생성합니다.
git apply와 git am 중 어떤 것을 사용해야 하나요?
단순히 코드 변경만 적용하려면 git apply를 사용하면 됩니다. Commit 이력까지 유지하며 적용하려면 git am을 사용하는 것이 좋으며, Linux Kernel 개발에서는 git am이 표준입니다.
Linux Kernel은 왜 GitHub Pull Request 대신 Patch를 사용하나요?
Linux Kernel은 오랫동안 메일링 리스트 기반으로 개발되어 왔으며, 전 세계 개발자들이 이메일을 통해 Patch를 검토하고 토론하는 문화가 정착되어 있습니다. 이 방식은 대규모 오픈소스 프로젝트의 협업과 리뷰에 최적화되어 있습니다.
마무리
Linux Kernel의 Patch 시스템은 대규모 오픈소스 협업을 가능하게 하는 핵심 요소입니다. diff와 git diff는 변경 사항을 확인하는 데 사용되고, git format-patch와 git am은 Commit 정보를 유지하면서 변경 사항을 공유하고 적용하는 데 활용됩니다. Patch 기반 개발 방식을 이해하면 Linux Kernel뿐 아니라 다양한 오픈소스 프로젝트의 협업 방식도 쉽게 이해할 수 있습니다.