Git 고수가 되기 위한 실전 팁 10가지
Git은 현대 소프트웨어 개발에서 필수적인 버전 관리 도구입니다. 프로젝트가 복잡해지고 협업이 많아질수록 Git을 제대로 활용하는 능력이 중요해집니다. 이 글에서는 Git의 기본 개념과 add, commit, push 등 기본 명령어를 알고 있다는 가정 하에, Git 히스토리를 더 깔끔하게 관리하고 실수를 방지할 수 있는 팁을 소개하겠습니다.
목차
- 1.
git graph를 확인하는 습관 들이기 - 2.
git fetch: 원격 저장소 변경사항 확인하기 - 3.
git stash: 작업 중인 코드 임시 저장하기 - 4.
git commit --amend: 마지막 커밋 수정하기 - 5.
git reset: 커밋 취소하기 - 6.
git revert: push한 커밋 취소하기 - 7.
git reflog: 히스토리 조회하기 - 8.
git cherry-pick: 특정 커밋 가져오기 - 9. 병합 완료된 브랜치 삭제하기
- 10.
git push는 신중하게 하기
1. git graph를 확인하는 습관 들이기
길을 찾을 때 지도를 보는 것처럼, 프로젝트 히스토리에서 위치를 파악할 때는 git graph를 보면 됩니다. git graph를 보면 브랜치, 커밋, 머지 등의 히스토리를 한 눈에 확인할 수 있습니다. 그리고 현재 작업 중인 브랜치가 어디에 있는지, 다른 브랜치에서는 어떤 작업이 진행되고 있는지 쉽게 파악할 수 있습니다. Git 명령어를 실행하기 전에 git graph를 확인하는 습관을 들이면, 프로젝트의 전체적인 흐름을 이해하고 실수를 방지하는 데 도움이 됩니다.
git graph를 보는 방법은 여러 가지가 있습니다.
git log --oneline --graph --all명령어 사용하기- VS Code 사이드바의
Source Control탭 하단의Source Control Graph보기 - VS Code의
Git GraphExtension 사용하기
이 중에서 Git Graph 익스텐션을 가장 추천하고 싶습니다. 전체 그래프를 큰 화면에서 볼 수 있어 가독성이 좋기 때문입니다.
2. git fetch: 원격 저장소 변경사항 확인하기
일반적으로 로컬 코드베이스를 최신 상태로 업데이트할 때 git pull 명령어로 원격 저장소의 변경사항을 내려받습니다. 하지만 실수로 git pull을 잘못 실행하면, 로컬 변경사항과 충돌이 발생할 수 있습니다. 이러한 충돌을 방지하려면 git pull 명령어를 실행하기 전에 git fetch 명령어로 원격 저장소의 변경사항을 확인하는 습관을 들이는 것이 좋습니다. git fetch 명령어는 로컬 코드에 전혀 영향을 주지 않고, 원격 저장소의 변경사항만 가져와줍니다.
git fetch를 실행하면 git graph가 최신 상태로 업데이트됩니다. 지도를 최신 버전으로 업데이트해야 올바른 길을 볼 수 있듯이, git graph도 최신 상태로 업데이트하는 것을 잊어서는 안 됩니다. git fetch로 안전하게 변경사항부터 확인한 후 이상이 없다면, git pull로 코드를 업데이트하면 됩니다.
git fetch
git pull3. git stash: 작업 중인 코드 임시 저장하기
개발을 하다보면, 브랜치를 변경해야 하는 상황이 종종 발생합니다. 하지만 현재 작업 중인 브랜치에 커밋되지 않은 변경사항이 있는 경우 다른 브랜치로 이동할 수 없습니다. 그렇다고 완성되지 않은 코드로 커밋을 남기는 것은 좋지 않습니다.
이럴 땐 git stash 명령어를 사용하여 변경사항을 임시로 저장할 수 있습니다. 브랜치를 전환하여 다른 작업을 진행한 후, 다시 원래 브랜치로 돌아와서 git stash pop으로 임시저장된 변경사항을 불러올 수 있습니다. 이렇게 하면 불필요한 커밋을 남기지 않고도 브랜치를 자유롭게 전환할 수 있습니다.
git stash
git checkout <other-branch>
git checkout <original-branch>
git stash pop4. git commit --amend: 마지막 커밋 수정하기
방금 전에 커밋을 했는데 커밋 메시지를 수정하고 싶거나, 코드를 수정하고 싶거나, 빠뜨린 파일을 추가하고 싶다면 어떻게 해야 할까요? 이럴 때 불필요한 커밋을 추가하지 않고도 git commit --amend 명령어로 마지막 커밋을 수정할 수 있습니다.
커밋 메시지만 수정할 땐 -m 옵션을 사용하면 됩니다.
git commit --amend -m "새로운 커밋 메시지"변경사항을 추가하려면 파일을 add한 후 --no-edit 옵션을 사용하면 됩니다. 그러면 현재 변경 내역을 마지막 커밋에 추가할 수 있어 이미 커밋한 후에 빠뜨린 부분이 생각났을 때 유용합니다.
git add <file-name>
git commit --amend --no-edit5. git reset: 커밋 취소하기
커밋을 취소하고 특정 시점으로 되돌아가고 싶을 때 git reset 명령어를 사용합니다. 히스토리를 변경하는 명령어이므로 주로 로컬 작업 시에 사용하며, 협업할 때는 주의해서 사용해야 합니다. git reset에는 다음과 같이 세 가지 옵션이 있으며, 옵션을 생략하면 기본값으로 --mixed가 적용됩니다.
--soft: 커밋만 취소하고, 변경사항이 stage에 그대로 남아 있습니다.--mixed(기본 옵션): 커밋을 취소하고 스테이징 영역을 초기화하지만, 작업 디렉토리에는 변경사항이 유지됩니다.--hard: 커밋 이전 상태로 모든 것이 복구되며, 변경사항이 완전히 삭제되므로 매우 신중하게 사용해야 합니다.
돌아갈 커밋을 지정할 때는 커밋 해시값이나 HEAD와 같은 상대 참조를 사용할 수 있습니다.
# 특정 커밋으로 돌아가기
git reset <commit-hash>
# 마지막 커밋 취소하기
git reset HEAD^
# n개의 커밋 취소하기
git reset HEAD~n6. git revert: push한 커밋 취소하기
원격 저장소에 이미 push까지 해버린 커밋을 취소해야 한다면 git revert를 사용하는 것이 좋습니다. git reset과 달리 기존 히스토리를 변경하지 않고 이전 커밋을 취소하는 새로운 커밋을 추가하는 방식으로 동작합니다. 따라서 팀 프로젝트에서 이미 GitHub에 push한 커밋을 되돌릴 때는 git revert를 사용하는 것이 안전합니다.
git revert <commit-hash>7. git reflog: 히스토리 조회하기
만약 git reset으로 커밋을 잘못 삭제했다면 복구할 수 있을까요? 특히나 git reset --hard로 커밋을 완전히 날려버렸다가 실수라는 걸 깨달았다면... 정녕 돌이킬 방법이 없을까요?
다행히도 복구가 가능합니다! Git은 로컬에서 작업한 모든 HEAD와 브랜치 포인터를 기록해두는데, 이것을 reference log라고 합니다. git reflog 명령어로 이것을 조회할 수 있으며, reset이나 rebase 등으로 변경된 HEAD의 위치까지 모두 조회가 가능합니다. 기록이 영구적으로 보존되지는 않고, 90일 후에 삭제되도록 기본 설정이 되어 있습니다.
git reflog를 실행하면 위와 같은 화면이 나옵니다. 여기서 돌아가고 싶은 커밋의 해시값을 확인한 후, git reset --hard로 복구하면 됩니다.
git reflog
git reset --hard <commit-hash>
# 또는
git reset --hard HEAD@{n}8. git cherry-pick: 특정 커밋 가져오기
git cherry-pick은 브랜치를 merge하지 않고도 특정 커밋만 현재 브랜치로 가져올 수 있는 명령어입니다. 다른 브랜치에서 버그 수정이나 설정 변경 등이 이루어져 작업 중인 브랜치에 변경사항을 빠르게 적용하고 싶을 때 유용합니다. 또는 실수로 다른 브랜치에 커밋한 것을 가져와야 할 때도 사용할 수 있습니다.
git cherry-pick <commit-hash>9. 병합 완료된 브랜치 삭제하기
브랜치가 성공적으로 merge되었거나 더 이상 필요하지 않은 경우 삭제하는 것이 좋습니다. 브랜치가 많이 쌓이면 히스토리가 복잡해지고 관리가 어려워지기 때문입니다. GitHub에서 PR을 제대로 merge했다면 브랜치를 삭제하고, 로컬 브랜치는 git branch -D 명령어를 통해 수동으로 삭제해야 합니다.
git branch -D <branch-name>그런데 다른 사람이 작업한 브랜치가 원격 저장소에서 삭제된 후에도 내 로컬에서는 여전히 추적되는 경우가 있습니다. 이럴 땐 git remote prune origin 명령어로 로컬에서 추적 중인 원격 브랜치의 잔재를 한꺼번에 삭제할 수 있습니다. 로컬과 원격 저장소의 상태를 동기화하여 불필요한 브랜치들이 제거되기 때문에, 히스토리가 복잡한 대규모 프로젝트에서 로컬의 git graph를 깔끔하게 유지하는 데 도움이 됩니다. 원격 저장소에서 삭제된 브랜치만 로컬에서 제거하는 것이므로, 로컬에서 작업 중인 브랜치는 영향을 받지 않습니다.
git remote prune origin10. git push는 신중하게 하기
마지막으로, git push를 하기 전에 한 번 더 확인하는 습관을 들이는 것이 중요합니다. 내 로컬에만 존재하는 커밋은 얼마든지 수정하거나 삭제해도 되지만, 원격 저장소에 push한 순간부터는 다른 팀원들에게 영향을 줄 수도 있으므로 함부로 바꾸지 않는 것이 좋습니다. 그러므로 이 코드를 팀원들과 공유해도 괜찮은지 변경사항을 다시 한 번 확인한 후, git push를 실행하는 것이 좋습니다.