git log

git log를 통해서 뭘 commit 했고 commit 해쉬, 내용, 날짜, 사용자까지 모두 볼 수 있다.(물론 커스텀 마이징해야한다.)

1. 최근의 커밋만 보기

git log -(갯수)

#ex) 최근 3개만 보기
git log -3 --oneline

2.통계와 함께 보기

git log --stat

3.한 줄로 보기

git log --oneline

내가 자주 사용하는 옵션 ㅎㅎ
--pretty=oneline, --abbrev-commit 옵션 활용 가능.

4.변경사항 내 단어 검색

git log -S (검색어)

#ex)George로 검색 가능.
git log -S George

5.커밋 메시지로 검색

git log --grep (검색어)

6.자주 사용하는 그래프 로그 보기

git log --all --decorate --oneline --graph

--all : 모든 브랜치 보기
--graph : 그래프 표시
--decorate : 브랜치, 태그 등 모든 레퍼런스 표시

7.customizing하기

이쁜 포맷이 있다.

git log --graph --all --pretty=format:'%C(yellow) %h  %C(reset)%C(blue)%ad%C(reset) : %C(white)%s %C(bold green)-- %an%C(reset) %C(bold red)%d%C(reset)' --date=short

그런데 이는 너무~~ 길다 따라서 앞에서 배운 단축키 속성

git config --global alias.(단축키) "명령어"

이를 사용해보자
위 너무 기므로 lg로 줄여서 사용해본다고 가정해보면 이렇게 적을 수 있다.

git config --global alias.lg "log --graph --all --pretty=format:'%C(yellow) %h  %C(reset)%C(blue)%ad%C(reset) : %C(white)%s %C(bold green)-- %an%C(reset) %C(bold red)%d%C(reset)' --date=short"

그러면 이제
git lg만 해도 예쁘게 formatting한게 뜬다.

이쁩니다!!! 근데 source tree 를 더 사용할거 같은데 ㅋㅋㅋㅋ

git diff

git이어떠한 변경사항이 있는지 알고 싶을때쓰는 명령어 입니다.

1.git diff

git diff 

2.git dff --staged

git diff하면 staging된 영역은 모르기 때문에,뒤에 --staged를 넣어서 staging된 상태의 diff까지 살펴봅니다.

git diff --staged

3.커밋간의 차이 확인

git dff (커밋1) (커밋2)

4.브랜치간의 차이 확인

git diff (브랜치1) (브랜치2)

git diff는 제가 많이 쓰는 명령어입니다. 이를 알아두면 좋습니다.

누가 코딩했는지 알아내기

git blame

git blame 은 작성자가 누구인지 알아낼 수 있습니다.

git blame (파일명)

그런데 이를 다 해주는 vscode확장 프로그램이 있습니다.

gitlens

이를 설치해서 하면 따로 git blame 명령어 칠 필요없이 안에 내용에 다 뜹니다. 역시 vscode!!

어디서 오류가 났지?-git bisect

🔍 Git Bisect - 버그 찾기(이진 탐색 디버깅)

📌 Git Bisect란?

• git bisect는 이진 탐색(binary search)을 활용하여 버그가 처음 발생한 커밋을 찾아주는 도구.
• 개발 중 언제 버그가 생겼는지 모를 때, 특정 범위 내에서 점진적으로 확인하며 문제의 원인을 찾을 수 있음.

1. Git Bisect 사용법

🔹 1) Bisect 시작

git bisect start

Bisect 모드를 시작함.

🔹 2) 정상 동작하는 커밋(좋은 커밋) 지정

git bisect good (커밋 해시)

버그가 없었던 커밋을 지정.

🔹 3) 버그가 발생한 커밋(나쁜 커밋) 지정

git bisect bad (커밋 해시)

버그가 발생한 커밋을 지정.

2. Git이 자동으로 이진 탐색 진행

git bisect는 좋은 커밋과 나쁜 커밋을 기반으로 중간 커밋을 체크아웃함.
사용자는 현재 커밋에서 버그가 있는지 확인한 후 결과를 Git에 전달해야 함.

🔹 4) 현재 커밋이 정상이라면?

git bisect good

현재 커밋이 정상(버그 없음)이라면 good으로 표시.
Git은 더 최근의 커밋을 검사하도록 이동.

🔹 5) 현재 커밋이 버그가 있다면?

git bisect bad

현재 커밋이 버그가 있는 상태라면 bad로 표시.
Git은 더 오래된 커밋을 검사하도록 이동.

3. Git Bisect 종료

git bisect reset

버그를 유발한 커밋을 찾았으면 git bisect reset으로 원래 상태로 돌아가기.
📌 예제 - 버그 찾기 과정

git bisect start
git bisect good a1b2c3d   # 정상 작동했던 커밋
git bisect bad z9y8x7w    # 버그가 발생한 최신 커밋

Git이 중간 커밋으로 자동 이동.
코드 실행 후 버그가 있는지 확인.
정상(git bisect good)이면 더 최근으로 이동.
버그 있음(git bisect bad)이면 더 이전으로 이동.
반복 후 문제가 발생한 최초 커밋을 찾음.
최종적으로 문제의 원인을 발견한 후:

git bisect reset

-> 결국 bisect는 자료구조/알고리즘에서 배운 이진탐색기법을 통해서 도출해낸 것이라고 볼 수 있다.