Git · 협업 · 약 3분
브랜치와 원격 저장소: 작업을 나누고 다시 합치는 기준
main·develop·release를 고정 법칙으로 외우지 않고, 작은 팀에 맞는 분기·검토·공유 흐름을 설계합니다.
Wolfgadeok · 업데이트
브랜치 이름보다 역할을 합의하기
두 사람이 같은 파일을 각각 수정하면 어느 시점에는 작업을 합쳐야 합니다. 충돌을 줄이려면 누가 어느 부분을 수정하는지, 언제 합칠지 미리 공유하는 것이 좋습니다. 특히 자동 병합이 어려운 바이너리 에셋이나 대규모 구조 변경은 작업 범위를 사전에 나누는 편이 좋습니다. 브랜치는 이런 별도의 작업 흐름을 기록하는 이름이며, 폴더를 통째로 복사해 두는 것과는 다릅니다.
main, master, develop, release, hotfix는 팀이 붙이는 이름입니다. 이름만으로 안정성이나 배포 상태가 보장되지 않습니다. 작은 개인 프로젝트라면 main과 짧게 유지하는 기능 브랜치로 충분할 수 있고, 별도 출시 검증 기간이 있다면 release 브랜치가 도움이 됩니다. 여러 종류의 브랜치를 나누는 방식은 운영 선택이지 Git이 강제하는 규칙은 아닙니다.
origin은 서버 자체가 아니라 연결에 붙인 이름
저장소에는 여러 원격을 등록할 수 있습니다. origin은 흔히 쓰는 별칭이며 HTTPS나 SSH 주소를 가리킵니다. git remote -v로 실제 대상부터 확인합니다. fetch는 원격 이력을 가져오지만 현재 작업 브랜치에 자동으로 합치지는 않습니다. 반면 pull은 가져오기와 통합 단계를 묶으므로 팀의 merge/rebase 정책을 알고 사용해야 합니다.
공개 저장소라고 누구나 원본에 직접 쓸 수 있는 것은 아닙니다. 읽기 공개 여부와 쓰기 권한은 다릅니다. 반대로 비공개 저장소라도 자격 증명을 커밋해도 안전한 것은 아닙니다. 원격을 처음 연결할 때는 이미 이력이 있는 로컬과 원격을 무작정 강제로 덮어쓰지 말고, 새 프로젝트인지 기존 프로젝트를 가져오는 상황인지 먼저 구분하세요.
예제 · bash
git status
git remote -v
git branch --show-current
git switch -c feature/blog-navigation
# 파일 수정, 검토, 테스트 후 대상 파일을 커밋합니다.
git log --oneline --graph --decorate -n 12
# 원격이 등록되어 있다면 공유 전에 먼저 변경을 확인합니다.
git fetch origin
git log --oneline HEAD..origin/main충돌 해결은 삭제 버튼을 고르는 작업이 아니다
병합 충돌이 생기면 양쪽이 달성하려던 동작을 이해한 뒤 결과 코드를 만들어야 합니다. 한쪽 전체를 채택하면 문법 오류가 사라져도 다른 개발자의 기능이 없어질 수 있습니다. 코드뿐 아니라 테스트, 문서와 설정까지 같은 의도를 유지하는지 확인합니다. 자동 병합된 파일도 API의 의미가 달라졌다면 문제가 생길 수 있습니다.
처음에는 한 기능을 작게 나누고 자주 검토하는 방식이 이해하기 쉽습니다. 변경 범위와 검증 결과를 적고, 기준 브랜치에 합친 뒤 실제로 작동하는지 확인합니다. 출시한 지점을 기억하려면 브랜치 이름을 계속 바꾸기보다 태그를 사용할 수 있습니다. 브랜치는 새 커밋을 따라 움직이는 작업 흐름이고 태그는 특정 지점을 가리키는 이름이라는 차이를 기억하세요.
참고 자료
예제는 학습용이며, 모든 환경에서 실행 검증된 완성 프로젝트는 아닙니다. 적용 전 사용 중인 버전과 프로젝트 환경에서 동작을 확인하세요.