Git 핵심 명령어 강의록

Git, Github 사용 워크플로우

2026년 4월 6일•

#Git#Github

git-commands-flow

1. 저장소 초기화 — git init / git remote add

git init은 현재 디렉토리를 Git 저장소로 만드는 첫 번째 명령이다. 이 시점에 .git 폴더가 생성되고 버전 관리가 시작된다.

git init
git remote add origin https://github.com/user/repo.git

remote add는 로컬 저장소에 "이 원격 저장소를 origin이라고 부르겠다"고 별명을 등록하는 것이다. origin은 관례적 이름일 뿐, 다른 이름을 써도 무방하다.

Git은 변경 사항을 바로 저장하지 않는다. 반드시 2단계를 거친다.

git add .              # 또는 git add 특정파일.java
git commit -m "메시지"

add와 commit을 분리한 이유는 하나의 커밋에 담을 내용을 선별할 수 있게 하기 위해서다. 10개 파일을 수정했어도 3개만 골라서 커밋하는 것이 가능하다.

브랜치는 커밋 히스토리의 포인터다. 독립적인 작업 공간을 만들어 메인 코드를 건드리지 않고 개발할 수 있다.

git switch -c feature/login    # 새 브랜치 생성 + 이동 (권장)
git checkout -b feature/login  # 구버전 방식, 동일한 효과

switch는 Git 2.23+부터 추가된 명령으로, 브랜치 전환만 담당하는 명확한 역할로 나뉜다. checkout은 파일 복구, 브랜치 전환 등 여러 기능이 섞여 있어 혼란스러울 수 있다. 최신 프로젝트라면 switch를 쓰는 것이 관례다.

git push origin main      # 로컬 → 원격
git pull origin main      # 원격 → 로컬 (fetch + merge 자동)
git fetch origin          # 원격 정보만 가져오기 (merge 안 함)

pull과 fetch의 차이가 자주 헷갈린다.

혼자 작업할 땐 pull로 충분하지만, 팀 협업에서 충돌을 미리 확인하고 싶을 때는 fetch 후 직접 merge를 결정하는 패턴을 쓴다.

git switch main
git merge feature/login

feature/login 브랜치의 커밋들을 main으로 합친다. 같은 파일의 같은 줄을 수정했다면 충돌(conflict) 이 발생하고, 이를 수동으로 해결한 뒤 다시 커밋해야 한다.

이 둘의 차이는 히스토리를 지우는가, 남기는가에 있다.

git reset --hard HEAD~1    # 마지막 커밋 자체를 삭제 (위험)
git revert HEAD            # 마지막 커밋을 되돌리는 새 커밋 생성 (안전)

이미 push한 커밋은 reset 하지 않는다. 팀원의 히스토리와 충돌해 큰 혼란이 생긴다.

PR은 Git 명령이 아니라 GitHub/GitLab 같은 플랫폼의 기능이다. 브랜치를 push한 뒤, 플랫폼 UI에서 "이 브랜치를 main에 합쳐도 괜찮은지 리뷰 요청"을 하는 것이다.

feature 브랜치 push → GitHub에서 PR 생성 → 팀원 코드 리뷰 → Approve → Merge

회사에서는 직접 main에 push하지 않고 반드시 PR을 통해 합치는 것이 기본 협업 규칙이다.