AZ-400 시험에서 소스 제어 파트는 '팀이 코드를 어떻게 나누고 합치고 보호하는가'를 묻습니다. 분기 전략 선택 기준, PR 정책 설정, 저장소 플랫폼 비교까지 포괄하는 영역입니다. 잘못된 분기 전략 하나가 배포 충돌로 이어지고, PR 정책 한 줄이 보안 취약점을 main 브랜치에서 걸러냅니다.
분기 전략: 팀의 협업 방식을 정하는 설계도
도서관에서 책 한 권을 동시에 두 사람이 빌리려 할 때처럼, 여러 개발자가 같은 파일을 동시에 수정하면 반드시 충돌이 납니다. 분기(Branch) 전략은 이 충돌을 어떻게 최소화하고 안전하게 통합할지 팀이 정하는 규칙입니다.
는 , , , , 다섯 종류 브랜치를 씁니다. 릴리스 주기가 정해져 있고 여러 버전을 동시 유지해야 하는 모바일 앱 팀에 어울립니다. 브랜치 수가 많아 CI/CD와 연동이 복잡한 게 단점입니다.
는 과 단기 브랜치만 씁니다. PR을 통해 main에 병합하는 단순한 구조로, 배포가 잦고 팀 규모가 작은 서비스에 적합합니다.
는 모든 개발자가 에 하루에도 여러 번 짧은 커밋을 직접 올립니다. Feature Flag로 미완성 기능을 숨긴 채 배포하는 방식이 핵심입니다. AZ-400 시험에서 '빠른 배포 주기'나 'CI와 깊은 통합'이 나오면 TBD를 고릅니다.
는 Microsoft 내부 전략으로, main에서 브랜치를 잘라내어 배포합니다. 핫픽스는 main에 먼저 적용 후 cherry-pick 합니다.
| 전략 | 브랜치 수 | 릴리스 주기 | 적합 규모 | |------|-----------|-------------|----------| | GitFlow | 많음 | 주기적 | 중·대형 | | GitHub Flow | 적음 | 연속 배포 | 소·중형 | | Trunk-Based | 최소 | 지속 통합 | 모든 규모 | | Release Flow | 중간 | 스프린트 기반 | 대형 |
분기 보호: main이 실수로 무너지지 않도록
은행 금고에 자물쇠 하나만 달지 않는 것처럼, 브랜치도 아무나 직접 push할 수 있으면 위험합니다. 분기 보호는 PR 병합 전에 반드시 충족해야 할 조건들을 강제하는 장치입니다.
Azure Repos의 에서 설정하는 주요 옵션은 다음과 같습니다.
: PR에 최소 N명 승인 필수 : 빌드 파이프라인 통과 전까지 병합 차단 : Azure Boards 작업 항목 연결 강제 : Squash·Rebase 등 병합 방식 제한
GitHub의 은 동일한 역할을 합니다.
: 리뷰 필수 : CI 상태 체크 통과 강제 : 직접 push 허용 계정 제한 : GPG 서명된 커밋만 허용
두 플랫폼 모두 차단과 브랜치 삭제 보호를 기본 제공합니다.
PR 정책과 CODEOWNERS
영화 촬영 현장에서 감독 한 명이 모든 부서를 책임지지 않듯이, 코드도 경로별 담당자가 필요합니다. 파일은 '이 경로의 변경은 누가 리뷰 책임자인지'를 선언합니다.
위처럼 설정하면 해당 경로에 변경이 생길 때 지정된 팀이 자동으로 PR 리뷰어로 추가됩니다. Branch Protection Rule에서 를 켜면 소유자 승인 없이는 병합이 불가합니다.
PR 병합 전략도 정책으로 제어합니다.
: 히스토리 전체 보존 : feature 브랜치 커밋을 하나로 압축 — 히스토리를 깔끔하게 유지할 때 선택 : 선형 히스토리 유지
AZ-400 시험에서 'PR 히스토리가 지저분하다', '하나의 커밋으로 정리하고 싶다' 조건이 나오면 Squash merge를 고릅니다.
저장소 구조와 Git 파일 관리
대형 마트처럼 모든 걸 한 건물에 모아두면 편리하지만 관리가 복잡해집니다. 소스 코드 저장소도 마찬가지입니다.
는 여러 서비스와 라이브러리를 하나의 저장소에 담습니다. 코드 공유가 쉽고 전체 빌드를 한 번에 돌릴 수 있는 대신, 저장소 크기가 커지고 CI 시간이 늘어납니다. Git LFS, Scalar, sparse-checkout 같은 도구가 대형 모노레포에서 필수입니다.
는 서비스마다 독립 저장소를 씁니다. 팀 간 독립성과 권한 분리가 명확하지만, 공통 라이브러리 업데이트 시 모든 리포를 개별 수정해야 합니다.
는 빌드 산출물·의존성 폴더·환경 파일을 Git 추적에서 제외합니다. 는 파일 유형별 처리 방식(줄바꿈 변환 , Git LFS 포인터 연결 )을 정의합니다. 시험에서 '바이너리 파일로 저장소 크기가 늘어난다'는 조건이 나오면 Git LFS와 를 떠올리면 됩니다.
Azure Repos vs GitHub: 생태계 선택
iOS를 쓰면 Apple 기기들과 자연스럽게 연결되듯, 저장소 플랫폼 선택도 기존 생태계에 달려 있습니다.
| 항목 | Azure Repos | GitHub | |------|-------------|--------| | 네이티브 CI/CD | Azure Pipelines | GitHub Actions | | ID 관리 | Azure AD, 조직 정책 | GitHub Org, SAML SSO | | 온프레미스 | Azure DevOps Server | GitHub Enterprise Server | | 이슈 트래킹 | Azure Boards | GitHub Issues |
Azure Pipelines·Azure Boards·Azure Artifacts를 이미 쓰는 팀은 Azure Repos가 자연스럽습니다. 오픈소스 기여, GitHub Copilot, GitHub Actions Marketplace 활용이 목적이라면 GitHub가 강점입니다. 시험에서 '기존 Azure DevOps 환경 유지' 조건이 나오면 Azure Repos, '오픈소스 기여·GitHub Actions 활용'이 나오면 GitHub를 선택합니다.
!Azure Repos vs GitHub
시험 핵심 정리
"빠른 CI, 단일 브랜치, 단기 커밋" -- Trunk-Based Development "릴리스 버전 관리, 다중 환경 동시 지원" -- GitFlow "PR 병합 전 빌드 파이프라인 통과 강제" -- Build Validation (Branch Policy) "경로별 변경 시 지정 팀 자동 리뷰어 추가" -- CODEOWNERS "PR 커밋 히스토리 하나로 압축" -- Squash merge "Azure Repos에서 main 직접 push 차단" -- Branch Policy 최소 리뷰어 수 "GitHub에서 force push 방지" -- Branch Protection Rule "모노레포 대용량 바이너리 파일 처리" -- Git LFS + .gitattributes "빌드 산출물·환경 파일 추적 제외" -- .gitignore "Azure 생태계 전체 통합 저장소" -- Azure Repos "오픈소스·GitHub Actions Marketplace 활용" -- GitHub "커밋 GPG 서명 강제" -- Require signed commits
GitFlow = 주기적 릴리스 다중 버전, Trunk-Based = 지속 통합 단일 브랜치, CODEOWNERS = 경로별 필수 리뷰어 자동 배정.