[Git] 원격 저장소 협업 명령어 정리 | push, pull, fetch, blame, revert

Git으로 혼자 작업할 때는 커밋한 내용을 push하는 정도로 끝나는 경우가 많다.

하지만 여러 사람이 같은 저장소를 사용하면 내가 작업하는 동안 원격 저장소의 내용이 달라질 수 있다. 이때는 로컬과 원격 저장소의 관계를 확인하면서 변경사항을 가져오고, 필요한 경우 커밋을 취소해야 한다.

이번에는 원격 저장소와 협업할 때 자주 사용하는 push, pull, fetch, blame, revert를 정리해봤다.

로컬 저장소와 원격 저장소

로컬 저장소는 내 컴퓨터에 있는 Git 저장소이고, 원격 저장소는 GitHub처럼 여러 사람이 공유할 수 있는 저장소다.

Local Repository
        ↓ git push
Remote Repository

Local Repository
        ↑ git pull
Remote Repository

 

로컬에서 만든 커밋은 git push로 원격 저장소에 올리고, 원격 저장소의 변경사항은 git pull이나 git fetch로 가져올 수 있다.

처음 원격 저장소에 push하기

로컬 브랜치를 처음 원격 저장소에 올릴 때는 다음 명령어를 사용한다.

 

git push -u origin main

 

origin은 원격 저장소에 붙인 기본 이름이고, main은 올릴 브랜치 이름이다.

-u 옵션으로 로컬 브랜치와 원격 브랜치의 연결을 설정하면 이후부터는 아래처럼 간단하게 사용할 수 있다.

 

git push

 

여기서 주의할 점은 push가 브랜치 단위로 동작한다는 것이다.

현재 main 브랜치에서 push했다고 해서 다른 작업 브랜치까지 자동으로 올라가는 것은 아니다.

push 전에 pull이 필요한 이유

내가 작업하는 동안 다른 사람이 먼저 원격 저장소에 새로운 커밋을 올렸을 수 있다.

원격 저장소

A --- B --- C


내 로컬 저장소

A --- B --- D

 

원격에는 C가 있고, 내 로컬에는 별도의 D가 생긴 상태다.

이때 바로 push하면 원격 저장소에 없는 기록을 덮어쓸 수 있기 때문에 Git이 push를 거절할 수 있다.

먼저 원격 변경사항을 가져와 내 작업과 합쳐야 한다.

 

git pull
git push

 

pull 과정에서 같은 부분을 서로 다르게 수정했다면 Conflict가 발생할 수 있다. 해결 방식은 일반적인 Merge Conflict와 같으며, 이 부분은 이전 글에서 따로 정리했다.

git pull의 동작

git pull은 원격 저장소의 변경사항을 가져오고 현재 브랜치에 바로 합친다.

git pull
= git fetch + git merge

 

원격 변경사항을 바로 반영해도 되는 상황이라면 편하게 사용할 수 있다.

 

git pull

 

다만 어떤 코드가 추가되었는지 확인하기 전에 merge까지 진행된다는 점은 주의해야 한다.

협업 중에는 원격 저장소에 올라온 변경사항이 내 작업과 충돌하지 않는지 먼저 확인해야 할 때도 있다.

git fetch로 먼저 확인하기

원격 변경사항을 바로 합치고 싶지 않다면 git fetch를 사용하면 된다.

 

git fetch

 

처음에는 fetch를 실행했는데 에디터의 파일이 그대로라서 제대로 가져온 것이 맞는지 헷갈렸다.

하지만 fetch는 Working Directory의 파일을 바꾸지 않는다. 원격 저장소의 최신 커밋 정보와 원격 브랜치 포인터만 가져오는 방식이다.

origin/main

A --- B --- C


main

A --- B

 

origin/main은 최신 상태가 되었지만 현재 작업 중인 main 브랜치는 그대로 남아 있다.

로컬과 원격 브랜치 비교하기

fetch 이후에는 git diff로 차이를 확인할 수 있다.

 

git diff main origin/main

 

원격 저장소에서 추가되거나 삭제된 코드를 먼저 살펴본 뒤, 문제가 없다면 merge를 진행한다.

 

git merge origin/main

 

결국 상황에 따라 다음처럼 구분하면 된다.

원격 변경사항을 바로 합쳐도 되는 경우
→ git pull

원격 변경사항을 먼저 확인해야 하는 경우
→ git fetch
→ git diff
→ git merge

 

pull 실행 시 divergent branches 오류

로컬 브랜치와 원격 브랜치가 서로 다른 커밋을 가진 상태에서 pull을 실행하면 아래 오류가 발생할 수 있다.

fatal: Need to specify how to reconcile divergent branches.

 

Git이 merge 방식으로 합칠지, rebase 방식으로 정리할지 설정되지 않았다는 의미다.

merge 방식으로 pull하려면 다음과 같이 설정할 수 있다.

 

git config pull.rebase false

 

rebase 방식으로 정리하고 싶다면 아래 설정을 사용한다.

 

git config pull.rebase true

 

설정을 저장소 전체가 아니라 현재 프로젝트에만 적용하려면 그대로 사용하면 되고, 모든 저장소에 적용하려면 --global을 추가한다.

 

git config --global pull.rebase false

 

이 코드는 누가 작성했을까?

협업 중 코드를 보다 보면 누가 작성했는지, 어떤 커밋에서 추가되었는지 확인해야 할 때가 있다.

이때 git blame을 사용할 수 있다.

 

git blame app.py

 

실행 결과에서는 각 줄의 커밋 ID, 작성자, 수정 날짜를 확인할 수 있다.

6d554eb (Kim 2026-07-08) def validate_input(value):
5904264 (Moon 2026-07-07)     return value > 0

 

문제가 있는 줄의 커밋 ID를 찾았다면 git show로 자세한 변경 내용을 확인한다.

 

git show 6d554eb

 

이렇게 보면 누가 작성했는지만 확인하는 것이 아니라, 해당 커밋에서 어떤 파일과 코드가 함께 수정되었는지도 살펴볼 수 있다.

git blame은 누군가에게 책임을 묻기 위한 기능이라기보다 코드가 만들어진 배경을 추적하는 용도로 보는 편이 맞다.

이미 push한 커밋 취소하기

아직 원격 저장소에 올리지 않은 커밋이라면 git reset으로 커밋 히스토리를 수정할 수 있다.

하지만 이미 다른 사람과 공유한 커밋을 reset하면 로컬과 원격 저장소의 기록이 달라진다.

이럴 때는 git revert를 사용하는 것이 안전하다.

 

git revert 커밋ID

 

revert는 기존 커밋을 삭제하지 않는다.

대신 해당 커밋에서 변경한 내용을 반대로 적용하는 새로운 커밋을 만든다.

A --- B --- C --- D
              ↑     ↑
        취소할 커밋  C를 취소한 커밋

 

기존 커밋과 취소 기록이 모두 남기 때문에 여러 사람이 같은 브랜치를 사용하는 상황에서도 히스토리를 따라가기 쉽다.

reset과 revert 차이

두 명령어는 모두 이전 상태로 되돌릴 때 사용하지만 처리 방식이 다르다.

git reset
- 브랜치 포인터를 이전 커밋으로 이동
- 이후 커밋이 히스토리에서 보이지 않게 됨
- 아직 공유하지 않은 로컬 커밋에 적합

git revert
- 기존 커밋을 취소하는 새 커밋 생성
- 기존 히스토리를 그대로 유지
- 이미 push한 커밋에 적합

 

정리하면 아래처럼 판단하면 된다.

아직 push하지 않은 개인 커밋
→ reset 고려

이미 push한 공유 커밋
→ revert 사용

 

여러 커밋 한 번에 revert하기

취소할 커밋이 여러 개라면 범위를 지정할 수 있다.

 

git revert 시작커밋..마지막커밋

 

예를 들어 아래와 같은 히스토리가 있다고 하자.

A --- B --- C --- D

 

다음 명령어를 실행하면 B는 제외되고 C부터 D까지가 대상이 된다.

 

git revert B..D

 

시작 커밋인 B까지 포함하려면 부모 커밋을 기준으로 지정하면 된다.

 

git revert B^..D

 

revert 도중 Conflict가 발생했다면 코드를 수정한 뒤 아래 명령어로 이어서 진행한다.

 

git add .
git revert --continue

 

작업을 취소하고 원래 상태로 돌아가고 싶다면 다음 명령어를 사용한다.

 

git revert --abort

 

원격 저장소 협업 기본 흐름

원격 저장소의 최신 변경사항을 바로 반영해도 된다면 다음 순서로 진행할 수 있다.

 

git status
git add .
git commit -m "작업 내용"
git pull
git push

 

원격 변경사항을 먼저 확인하고 싶다면 fetch를 사용한다.

 

git status
git add .
git commit -m "작업 내용"

git fetch
git diff main origin/main
git merge origin/main
git push

 

무조건 pull이나 push부터 실행하기보다 현재 브랜치와 원격 저장소의 상태를 먼저 확인하는 편이 안전하다.

 

git status
git log --oneline --all --graph

 

핵심 정리

git push는 현재 로컬 브랜치의 커밋을 연결된 원격 브랜치에 올린다.

원격 저장소에 새로운 커밋이 있다면 push 전에 변경사항을 가져와야 한다. 바로 합쳐도 된다면 git pull, 먼저 확인해야 한다면 git fetch를 사용하면 된다.

fetch는 Working Directory를 변경하지 않으며, git diff main origin/main으로 로컬과 원격 브랜치의 차이를 확인할 수 있다.

코드의 각 줄이 어떤 커밋에서 작성되었는지는 git blame으로 찾고, 해당 커밋의 자세한 내용은 git show로 확인한다.

아직 공유하지 않은 커밋은 reset으로 정리할 수 있지만, 이미 원격 저장소에 올라간 커밋은 revert로 취소 기록을 남기는 편이 안전하다.