주니어 개발자를 위한 Git 사용법 정리 노트

이 문서는 나 같은 주니어 개발자를 위한 정리 문서다. 프로젝트 진행 시 코드의 버전 관리와 협업을 위해 실무에서 사용하는 Git 핵심 기능을 정리한다.

1. Git 사용의 목적

Git은 단순한 명령어 묶음이 아니다. 코드를 보호하는 세이브 포인트이자 협업의 효율을 높이는 핵심 도구이다. 그 목적은 다음 세 가지로 정의할 수 있다.

• 버전 관리: 코드의 특정 상태를 ‘커밋(Commit)’ 단위로 기록한다. 이를 통해 특정 시점의 코드로 돌아가거나 변경 이력을 추적할 수 있다.
• 안전한 개발 환경: ‘브랜치(Branch)’를 통해 기존 코드에 영향을 주지 않는 독립적인 작업 공간을 확보한다. 새로운 기능 개발이나 테스트를 안전하게 진행하고, 완료 시점에만 본래 코드에 통합(Merge)한다.
• 협업 지원: 다수의 개발자가 동일한 프로젝트를 작업할 때, 각자의 변경 사항을 체계적으로 추적하고 병합할 수 있도록 지원한다. 코드 충돌(Conflict) 발생 시점을 명확히 하고 해결을 돕는다.

2. Git 기본 작업 흐름

Git은 Working Directory, Staging Area, Repository라는 3개의 논리적 공간을 통해 버전을 관리한다.

1. Working Directory (작업 디렉토리): 실제 파일들이 위치하며, 코드 수정이 이루어지는 공간.
2. Staging Area (스테이징 영역): 버전으로 기록할 파일, 즉 커밋 대상 파일들을 선별하여 등록하는 대기 공간.
3. Repository (저장소): 스테이징 영역에 있던 파일들의 최종 버전(스냅샷)이 영구적으로 보관되는 곳.

명령어	설명
git init	현재 디렉토리를 Git 저장소로 초기화한다. (.git 폴더 생성)
git add <파일명>	작업 디렉토리의 변경 사항을 스테이징 영역에 추가한다.
git commit -m "메시지"	스테이징 영역의 변경 사항을 하나의 버전으로 묶어 저장소에 기록한다.
git push	로컬 저장소의 변경 내용을 원격 저장소(GitHub 등)에 업로드한다.

용어 구분: clone과 pull

• git clone: 원격 저장소의 내용을 최초에 한 번 로컬 컴퓨터로 복제하는 작업이다.
• git pull: 이미 clone된 로컬 저장소에, 원격 저장소의 최신 변경 내용을 가져와 병합하는 작업이다.

3. 브랜치를 활용한 실무 개발

브랜치는 실무 개발의 핵심이다. 주 작업 흐름인 main 브랜치를 깨끗하게 유지하며, 기능 단위로 작업을 분리할 수 있다.

브랜치 기본 명령어

# 'feature/login' 이름의 새 브랜치를 생성한다.
$ git branch feature/login

# 생성된 'feature/login' 브랜치로 작업 환경을 전환한다.
$ git checkout feature/login

# 브랜치 생성과 동시에 해당 브랜치로 즉시 전환한다. (위 두 명령어를 합친 것)
$ git checkout -b feature/login

생성된 브랜치에서의 모든 작업(commit)은 다른 브랜치에 영향을 미치지 않는다. 기능 개발이 완료되면 main 브랜치에 병합하여 변경 사항을 반영한다.

브랜치 전략

프로젝트의 특성에 따라 브랜치 관리 전략을 선택한다.

1. Github-flow:

   • 개념: main 브랜치는 항상 배포 가능한 상태를 유지하고, 모든 작업은 feature 브랜치에서 진행한 뒤 main으로 병합(Pull Request)한다.
   • 적용: 구조가 단순하여 개인 프로젝트나 빠른 배포 주기를 가진 웹 서비스에 적합하다.

2. Git-flow:

   • 개념: main, develop, feature, release, hotfix 등 명확한 역할 구분을 가진 브랜치들을 운영한다.
   • 적용: 체계적인 버전 관리가 필요한 대규모 프로젝트나 모바일 애플리케이션 등 정식 릴리즈가 중요한 경우에 사용한다.

4. 실수 발생 시 대처 방법

실수 시 되돌리는 방법을 명확히 숙지하여 위험을 관리한다.

시나리오 1: 커밋 되돌리기

주의: 원격 저장소에 push한 커밋은 reset으로 되돌리면 안 된다. 공유된 작업 이력을 훼손하여 협업 시 심각한 문제를 유발할 수 있다.

• git revert (안전한 방법):

  • 특정 커밋의 변경 사항을 취소하는 새로운 커밋을 생성한다. 기존 이력을 삭제하지 않고 변경 사실을 기록으로 남기므로 공유된 저장소에서 사용하기에 안전하다.
  • 사용법: $ git revert <되돌릴_커밋_ID>

• git reset (강력하지만 위험한 방법):

  • 저장소의 이력을 특정 커밋 시점으로 되돌린다. 그 이후의 커밋 기록은 실제로 삭제된다. 원격 저장소에 push하기 전, 로컬 저장소의 커밋을 정리할 때 제한적으로 사용한다.
  • 사용법: $ git reset HEAD~1 (가장 최근 커밋 1개를 취소)

시나리오 2: 추적하지 않는 파일 삭제

주의: git clean 명령어는 추적하지 않는(untracked) 파일을 영구적으로 삭제한다. 휴지통에 보관되지 않으므로 실행에 신중해야 한다.

반드시 삭제될 파일을 미리 확인하는 습관이 필요하다.

# 어떤 파일이 삭제될지 미리 확인만 한다. (Dry Run)
$ git clean -n

# 미리보기 후, 실제로 삭제를 진행한다.
$ git clean -f

5. 커밋 메시지 작성 규칙

커밋 메시지는 미래의 자신과 동료를 위한 중요한 문서이다. Conventional Commits 규칙을 따라 작성하면 변경 이력을 명확하게 관리할 수 있다.

기본 형식: <타입>(<스코프>): <제목>

타입	설명
feat	새로운 기능 추가
fix	버그 수정
docs	문서 수정
style	코드 포맷팅 등 기능 변경 없는 스타일 수정
refactor	성능 개선이나 구조 변경 등 코드 리팩토링
test	테스트 코드 추가 및 수정
chore	빌드 관련 파일 수정 등 기타 자잘한 작업

좋은 예시: feat(auth): JWT 기반의 사용자 인증 기능 구현
나쁜 예시: 코드 수정, 버그 해결