요약
| 항목 | Git | SVN(Subversion) |
|---|---|---|
| 저장소 구조 | 분산형(로컬에 전체 이력) | 중앙집중형(서버에 이력) |
| 속도 | 커밋/브랜치/로그 조회 빠름 | 네트워크 의존, 상대적으로 느릴 수 있음 |
| 브랜치 | 가볍고 자유로운 브랜칭/머지 | 브랜치가 “디렉터리” 개념, 비교적 무거움 |
| 오프라인 작업 | 가능 (대부분 작업) | 제한적 (서버 필요) |
| 대용량 바이너리 | 기본 불리 (Git LFS로 보완) | 비교적 유리(파일 잠금 등) |
| 권한관리 | 기본은 단순(서버/호스팅별로 확장) | 경로 단위 세밀 권한 관리 용이 |
| 이력 변경 | rebase, amend 등 강력(주의 필요) | 이력 재작성 제한적, 보수적 |
| 학습곡선 | 다소 높음 | 낮음(직관적) |
| 생태계/툴 | 매우 풍부 (GitHub/GitLab 등) | 안정적이나 상대적으로 적음 |
| 대표 사용처 | 소프트웨어 개발, 협업, 오픈소스 | 문서/디자인/대기업 중앙 통제형 |
Git 추천
브랜치 기반 개발(Feature/MR/PR) 중심의 애자일 팀
오픈소스/분산 협업, 잦은 실험·리팩토링
오프라인 환경에서 커밋/리뷰가 필요한 경우
SVN 추천
중앙 통제가 중요하고 권한을 경로 단위로 나눠야 함
대용량 바이너리(CAD, 영상, 게임 어셋 등) 많이 다룸
히스토리 재작성 금지, 감사·감리 관점이 중요한 환경
핵심 개념 차이
Git(분산형): 각 개발자 PC에 전체 이력이 복제. 로컬에서 브랜치/커밋/리셋 자유롭게 → 원격에 푸시.
SVN(중앙형): 중앙 서버가 단일 진실(SSOT). 작업은 체크아웃/업데이트/커밋 중심. 파일 **잠금(lock)**로 충돌 방지 용이.
기본 워크플로우
Git (Feature Branch + MR/PR)
git clone <url>
git switch -c feature/x
작업 → git add . && git commit -m "feat: ..."
git push -u origin feature/x
Merge Request/PR로 코드리뷰 → main 병합
태깅/릴리스: git tag v1.2.0 && git push --tags
SVN (Trunk/Branches/Tags 디렉터리)
svn checkout <url>/trunk
작업 → svn add/rename/delete
svn commit -m "..." (서버 반영)
브랜치 생성: svn copy ^/trunk ^/branches/feature-x -m "branch"
병합: svn merge ^/branches/feature-x → svn commit
명령어 맵핑(자주 쓰는 것)
| 작업 | Git | SVN |
|---|---|---|
| 최초 가져오기 | git clone URL | svn checkout URL |
| 변경 가져오기 | git pull | svn update |
| 변경사항 보기 | git status | svn status |
| 커밋 | git commit (로컬) → git push | svn commit (서버) |
| 이전 이력 보기 | git log --oneline --graph | svn log |
| 브랜치 목록 | git branch -a | 디렉터리(branches/) |
| 브랜치 만들기 | git switch -c feat | svn copy ^/trunk ^/branches/feat -m "..." |
| 병합 | git merge / git rebase | svn merge |
| 되돌리기 | git revert / git reset | svn merge -c -REV / svn revert |
협업/품질 관점
코드리뷰
Git: 플랫폼(MR/PR)으로 템플릿, 파이프라인, 보호 브랜치 규칙을 쉽게 연계
SVN: 리뷰 툴 별도 연동(예: Crucible 등) 또는 정책 기반 커밋 훅
CI/CD
Git: GitLab/GitHub Actions 등과 자연스럽게 통합
SVN: Jenkins 등과 연동 가능하나 초기 세팅 손이 더 감
보안/권한
Git: “브랜치 보호 + MR 승인 규칙” 중심
SVN: 경로별 접근 제어(authz)로 세밀
대용량/바이너리 전략
Git: Git LFS 사용 권장(필터링, 스토리지 분리)
SVN: 원천적으로 바이너리에 비교적 관대 + 파일 잠금으로 충돌 예방
마이그레이션 팁(SVN → Git)
히스토리 유지 이관: svn2git(SubGit, git-svn 등)로 trunk/branches/tags를 정책적으로 매핑
폴더 권한 → 브랜치/Repo 분리로 재설계 (필요시 모노레포 → 멀티레포)
바이너리는 Git LFS로 이전하거나 아티팩트 스토리지/NAS로 분리
워크플로우 전환: commit 즉시 서버 반영 → PR 기반 병합 문화로 전환(리뷰 룰, 보호 브랜치 설정)
교육/가이드: rebase, squash, 충돌 해결, 태그/릴리스 전략 문서화
선택 체크리스트(결정 가이드)
브랜치 기반 개발/PR 문화가 핵심인가? → Git
중앙 통제·경로 권한·문서 위주인가? → SVN
오프라인 개발이 잦은가? → Git
대용량 바이너리와 파일 잠금이 중요한가? → SVN(+ 혹은 Git+LFS)
CI/CD를 강하게 붙일 계획인가? → Git 권장
robots.txt 와 meta robots 태그 비교