| 전략 | 브랜치 구성 | 적합한 상황 |
|---|---|---|
| git-flow | main·develop·feature·release·hotfix | 배포 주기가 길고 여러 버전을 동시 지원 |
| GitHub flow | main + 짧은 feature + PR | 배포가 잦고 운영 버전이 하나 |
| trunk-based | main 직접 + 기능 플래그 | 하루 여러 번 배포, 자동화 테스트가 탄탄 |
git-flow 는 develop 이 통합 브랜치, main 은 배포된 상태만 담습니다. 브랜치 종류가 많은 만큼 규칙을 지키는 비용도 큽니다.
작은 팀이 자주 배포한다면 GitHub flow 로 충분합니다. main 하나와 짧은 feature 브랜치, PR 리뷰만으로 돌아갑니다. 여러 버전을 동시에 운영해야 하는 큰 팀은 git-flow 의 release·hotfix 분리가 필요합니다.
하루에도 여러 번 배포하는 팀은 trunk-based 를 씁니다. 브랜치를 오래 유지하지 않는 대신 기능 플래그로 미완성 코드를 숨깁니다. 테스트 자동화 없이 trunk-based 를 쓰면 main 이 쉽게 깨집니다.
| 접두어 | 용도 | 예시 |
|---|---|---|
feature/ |
기능 개발 | feature/42-login |
fix/ |
버그 수정 | fix/13-null-error |
hotfix/ |
운영 긴급 수정 | hotfix/1.2.1-payment |
release/ |
배포 준비 | release/1.2 |
이슈 번호를 브랜치 이름에 넣으면 이슈 트래커와 자동으로 연결하는 도구가 많습니다. 설명은 짧은 영어 소문자와 하이픈으로 씁니다.
제목은 50자 이내로 무엇을 바꿨는지 명령형으로 씁니다. 제목과 본문 사이는 빈 줄로 구분합니다. 본문은 72자에서 줄바꿈하고 "무엇을" 보다 "왜" 바꿨는지를 적습니다.
이슈 번호는 제목 끝에 (#42) 로 붙이거나 본문에 Closes #42 로 적습니다. Closes 를 쓰면 GitHub 같은 호스팅에서 병합 시 이슈를 자동으로 닫아 줍니다.
| 접두어 | 의미 |
|---|---|
feat |
새 기능 |
fix |
버그 수정 |
docs |
문서만 변경 |
refactor |
동작 변화 없는 구조 개선 |
chore |
빌드·설정 등 잡일 |
feat(auth): 소셜 로그인 추가 처럼 괄호 안에 범위(scope)를 적을 수 있습니다. 기존 API 를 깨는 변경은 본문 맨 아래에 BREAKING CHANGE: 설명 줄을 따로 둡니다.
git config commit.template .gitmessage.txt 를 설정하면 git commit 편집기가 이 파일 내용으로 열립니다. 제목·본문·이슈 형식을 미리 적어 두면 매번 같은 틀을 기억할 필요가 없습니다. 템플릿 파일 자체는 저장소에 커밋해 팀이 공유합니다.
Windows 편집기는 줄 끝에 CRLF, 리눅스·macOS 는 LF 를 씁니다. 같은 파일을 서로 다른 OS 에서 저장하면 diff 전체가 바뀐 것처럼 보입니다.
| core.autocrlf 값 | 체크아웃 시 | 커밋 시 |
|---|---|---|
true |
LF 를 CRLF 로 변환 | CRLF 를 LF 로 변환 |
input |
그대로 유지 | CRLF 를 LF 로 변환 |
false |
그대로 유지 | 그대로 유지 |
이 값은 사람마다 로컬 설정이라 팀 전체를 맞추기 어렵습니다. 그래서 팀 규칙은 core.autocrlf false 로 통일하고, 대신 저장소의 .gitattributes 로 줄 끝을 강제하는 방식을 씁니다.
* text=auto eol=lf 는 텍스트로 인식되는 모든 파일을 저장소 안에서 항상 LF 로 저장합니다. Windows 전용 스크립트만 예외로 *.bat eol=crlf 를 추가합니다. 이미지 같은 바이너리는 *.png -text 로 줄 끝 변환 대상에서 뺍니다.
이 설정은 저장소에 커밋되는 파일이라 개인 설정보다 우선합니다. 팀원이 무엇을 설정했든 결과가 같습니다.
-diff 속성을 주면 그 파일을 diff·병합 비교에서 텍스트로 다루지 않고 바이너리로 취급합니다. 자동 생성 파일처럼 늘 충돌하는 파일에는 merge=ours 속성과 git config merge.ours.driver true 를 같이 씁니다.
이렇게 하면 병합할 때 그 파일만은 항상 현재 브랜치 내용을 유지하고 상대 쪽 변경을 버립니다. 실제 코드가 아니라 로그·생성물 성격의 파일에만 씁니다.
저장소 .gitignore 는 빌드 산출물처럼 프로젝트 공통 규칙을 담아 커밋합니다. 편집기 설정 파일처럼 사람마다 다른 항목은 전역 git config --global core.excludesfile 로 로컬에만 둡니다.
이미 추적 중인 파일은 .gitignore 에 추가해도 사라지지 않습니다. git rm --cached 파일 로 추적만 해제해야 합니다.
| 설정 | 권장값 | 효과 |
|---|---|---|
pull.ff |
only |
병합 커밋 없는 pull 만 허용 |
push.default |
simple |
현재 브랜치만 안전하게 push |
init.defaultBranch |
main |
새 저장소 기본 브랜치 통일 |
core.autocrlf |
false |
줄 끝 변환은 gitattributes 에 위임 |
fetch.prune |
true |
삭제된 원격 브랜치 자동 정리 |
rerere.enabled |
true |
반복 충돌 해결 기록 재사용 |
이 값들은 팀 문서에 적어두고 신규 입사자 온보딩 스크립트로 한 번에 설정하는 것이 좋습니다.
훅(hook)은 커밋·push 같은 시점에 git 이 자동으로 실행하는 스크립트입니다. .git/hooks 폴더는 저장소 데이터가 아니라 로컬 파일이라 커밋해도 다른 사람에게 전달되지 않습니다.
그래서 훅 스크립트는 저장소 안 .githooks/ 같은 일반 폴더에 두고 커밋합니다. 각자 git config core.hooksPath .githooks 를 한 번 설정하면 git 이 그 폴더의 스크립트를 훅으로 씁니다.