Skip to content
Kendrick's Website Kendrick's GitHub Kendrick's Youtube Kendrick's Travel blog

알아두면 좋은 GIT 명령어들

7 min read
Cover

최근 자주 사용하는 GIT 명령어들

간헐적으로 사용하지만 바로바로 떠오르지 않아서 한번씩 찾아보는 명령어들을 제가 찾기 쉽게 그리고 다른 엔지니어에게 소개하고 싶어서 정리해 보았습니다.

1. --force 대신 --force-with-lease를 사용하자

많은 사람들이 Git에서 특정 Branch에 변경 사항을 푸시할 때 git push --force 명령어를 사용합니다. 하지만 이 방법은 다른 사람의 작업을 실수로 덮어쓸 위험이 있습니다.

상황을 예로 들어보겠습니다:

  • A라는 개발자가 main branch에서 긴급한 문제를 발견하고 수정 작업을 시작합니다.
  • A는 수정이 끝나고, 로컬에서 main branch를 업데이트하려 하지만, 그 사이 B라는 다른 개발자가 새로운 작업을 메인 Branch에 병합합니다.
  • A는 이 사실을 모른 채, 자신의 수정 사항을 푸시하기 위해 git push --force를 사용합니다.

이 경우, B의 작업 내용이 A의 푸시로 인해 사라지게 됩니다. 경고 메시지가 없기 때문에 A는 문제를 인지하지 못한 채로 작업을 마무리하게 됩니다.

이런 문제를 방지하기 위해서는 git push --force 대신 git push --force-with-lease를 사용하는 것이 좋습니다. force-with-lease는 로컬 Branch가 원격 Branch와 동일한 상태일 때만 푸시를 허용하므로, 다른 사람의 작업을 보호할 수 있습니다.

개인 Branch에서 -f 를 사용할 때도 동일한 위험이 발생할 수 있습니다. 따라서 저는 개인적인 작업에서도 --force를 사용하지 않는 습관을 기르고 있으며, 보통 함께 일하는 개발자가 --force를 사용하는 것을 볼 때마다 모든 상황에서 --force-with-lease를 사용할 것을 권장하고 있습니다.

References: https://www.atlassian.com/blog/it-teams/force-with-lease

2. git bisect로 문제 원인 추적하기

버그가 발생한 시점을 정확히 파악하는 것은 쉽지 않은 일입니다. 특히, 많은 커밋이 쌓여있을 때는 더더욱 그렇습니다. 이럴 때 유용하게 사용할 수 있는 Git 명령어가 git bisect입니다.

git bisect는 이진 검색(Binary Search) 알고리즘을 활용해, 특정 버그가 언제 발생했는지 빠르게 찾아낼 수 있는 도구입니다. 이를 통해 코드 베이스에서 문제를 일으킨 커밋을 효과적으로 추적할 수 있습니다.

git bisect 사용 방법

  1. git bisect start: 먼저, git bisect start 명령어로 bisect 세션을 시작합니다. 이 명령어는 Git에게 현재 작업이 bisect 모드에 진입했음을 알려줍니다.

  2. 좋은 커밋과 나쁜 커밋 지정: 버그가 발생하지 않았던 마지막 정상적인 커밋을 good으로, 버그가 처음 발견된 커밋을 bad로 지정합니다.

git bisect good <good_commit>
git bisect bad <bad_commit>
  1. 이진 검색 수행: Git은 지정된 두 커밋 사이에서 이진 검색을 수행하여, 중간 지점의 커밋으로 이동합니다. 이 상태에서 코드를 빌드하고 테스트하여 버그가 있는지 확인합니다.

  2. 결과 입력: 테스트 결과에 따라 해당 커밋이 여전히 문제가 없는 경우 git bisect good, 문제가 있는 경우 git bisect bad를 입력합니다. 이 과정을 반복하면 Git은 점점 더 범위를 좁혀나가며 문제를 일으킨 커밋을 찾아냅니다.

  3. git bisect reset: 문제의 커밋을 찾으면 git bisect reset 명령어로 bisect 세션을 종료하고, 원래 작업 중이던 브랜치로 돌아갑니다.

실제 개발 과정에서 git bisect는 다음과 같은 상황에 유용합니다:

  • 버그가 특정 시점 이후 발생했으나, 어느 커밋에서 발생했는지 알 수 없을 때
  • 긴급한 상황에서 빠르게 문제의 원인을 찾아야 할 때

이 과정을 통해 문제의 원인을 정확하게 파악하고, 이를 해결할 수 있습니다. 특히 팀 단위로 작업하는 경우, 버그의 원인을 빠르게 확인할 수 있어 큰 도움이 됩니다

3. gitignore 적용이 안되는 경우

분명 gitignore를 맞게 작성해도 적용이 안될때가 있습니다.

git rm -r -cached .

일반적으로 캐시파일에 문제가 생겨서 안되는 경우이므로 위 명령어를 통해 문제를 해결 할 수 있습니다.

4. 깃헙 작업한 브런치 순서대로 보기

2개정도의 Branch를 작업하는 경우 git chekcout - 명령어로 쉽게 이전 branch로 왔다 갔다할 수 있습니다.

하지만 3개 혹은 그보다 많은 Branch를 동시에 작업하는 경우 Branch name잘 안떠오를때가 있습니다. 이럴때는 아래 명령어를 통해 최근에 작업한 branch 이름을 날짜와 함께 순서대로 볼 수 있습니다.

git for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short)' refs/heads/
2024-09-09 feature/F
2024-09-06 feature/E
2024-09-05 feature/D
2024-09-05 bugfix/C
2024-08-30 main
2024-08-28 bugfix/B
2024-08-27 feautre/A