위급한 상황에서 사용할 수 있는 git 도구

[youngkyo0504]

---

title: 위급한 상황에서 사용할 수 있는 git 도구
full_path: src/pages/.md

SHA-1 줄여쓰기

• git commit hash는 충돌이 나지 않는다면 4자만으로 나타낼 수 있다

git show

• 해당 브랜치의 최신 커밋을 가져올 수 있다
  git reflog
• 로컬에서 브랜치와 HEAD가 지난 몇 달 동안에 가리켰었던 커밋을 모두 기록하고 이를 볼 수 있는 - 명령어
  git log -g 명령어를 사용하면 git reflog의 결과를 git log 형태로 볼 수 있음
  reflog는 모두 로컬의 일이다! 내 동료의 저장소와는 다를 수 있다.
  git show master@{yesterday} 처럼 시간으로 확인할 수도 있다.

계통 관계 표현
확실하게 설명된 링크 : https://stackoverflow.com/questions/2221658/whats-the-difference-between-head-and-head-in-git
HEAD^ 나 HEAD~로 가리키는 것을 말한다. 이 둘은 차이가 있다.

• HEAD~2: 첫번째 부모의 첫 번째 부모 -> 조부모
• HEAD^로 사용하려면 HEAD^^

범위로 커밋 가리키기

• Double Dot
  • git log master..experiment
    • master에는 없지만 experiment 브랜치에 있는 커밋을 의미
      세 개 이상의 refs
• 아래 명령어는 같은 명령어로 refA 나 refB 에는 있지만 refC 에는 없는 커밋을 볼 때 사용
• git log refA..refB
• git log ^refA refB
• git log refB --not refA

Triple Dot

• git log master...experiment
• master 와 experiment 의 공통부분은 빼고 다른 커밋만 보고 싶으면 아래와 같이 하면 된다.
  이를 이용하면 이번 브랜치 배포내역을 자동화할 수 있다

interactive 옵션
git add -i를 이용해서 대화형으로 파일을 add 할 수 있다

• 파일의 일부분만 staging area에 올릴 때는 5. patch를 선택

• 커밋을 쪼갤 때 patch를 많이 사용한다

• 하던 일을 stash 하기

  • git stash
  • git stash apply
    • stash를 다시 적용할 수 있다
  • git stash --index
    • 원래 staging area에 있던 파일은 그 area에 둔다
  • git stash -u
    • untracked 파일까지 stash할 수 있다
    • 다들 유용하게 사용하는 명령어
  • git stash branch <브랜치>
    • 새로운 브랜치를 만들고 여기에 stash를 적용

• 워킹 디렉토리 청소하기

  • git clean
    • 외부 도구가 만들어낸 파일을 지우거나 이전 빌드 작업으로 생성된 각종 파일을 지우는데 필요
  • git clean
    • -f : 강제의 의미이며 진짜로 지우라는 뜻
    • -d : 하위디렉토리까지 적용
    • -n : “가상으로 실행해보고 어떤 파일들이 지워질지 알려달라” 라는 뜻

검색

git grep

• git grep -n <search_word> : 문자열이 위치한 라인 번호도 같이 출력해준다.
• git grep --count <search_word> : 몇개나 찾았는지만 알려준다.
• git grep -p <search_word> : 매칭되는 라인이 있는 함수나 메서드를 찾고 싶을 때 사용

복잡한 예시

git grep --break --heading \ -n -e '#define' --and \( -e LINK -e BUF_MAX \) v1.8.0

• --break: 각 파일에서 일치하는 패턴이 여러 번 나타날 때 파일 간에 구분자를 출력합니다.
• --heading: 각 파일에서 일치하는 패턴이 나타날 때 파일 이름을 출력합니다.
• : 다음에 오는 문자를 이스케이프(escape)합니다. 여기서는 공백 문자를 이스케이프하고 있습니다.
• -n: 각 일치 항목이 파일의 몇 번째 줄에서 발생했는지 출력합니다.
• -e '#define': '#define'이라는 문자열을 포함하는 모든 라인을 찾습니다.
• --and: 이 부분에서는 다음에 오는 조건들을 AND 연산자로 결합합니다.
  ( -e LINK -e BUF_MAX ): 'LINK' 또는 'BUF_MAX'라는 문자열을 포함하는 모든 라인을 찾습니다.
• v1.8.0: 검색 대상 버전이 v1.8.0인 Git 저장소에서 검색을 수행합니다.

이 명령어는 Git 저장소에서 '#define'이라는 문자열을 포함하고 있고, 'LINK' 또는 'BUF_MAX' 문자열도 포함된 모든 라인을 파일 이름과 함께 출력하며, 이를 Git 버전 v1.8.0에서 수행합니다.

Git 로그 검색

ZLIB_BUF_MAX라는 변수가 가장 처음 나타난 때를 찾는 문제 -S 옵션을 이용해 해당 문자열이 추가된 커밋과 없어진 커밋을 볼 수 있다.
git log -SZLIB_BUF_MAX --oneline

미친듯이 좋은 로그 검색 도구 : 라인 로그 검색
git log 를 쓸 때 -L을 붙여서 쓰면 어떤 함수나 한 라인의 히스토리를 볼 수 있다.

git log -L :git_deflate_bound:zlib.c : zlib.c파일에 있는 git_deflate_bound함수의 모든 변경사항을 볼 수 있다.

Git branch 여러개 삭제하기

git branch | grep chore | xargs git branch -D
chore가 들어간 브랜치를 모두 삭제한다.

히스토리 변경하기 Git Rebase, Git commit --amend

마지막 커밋 수정하기

git commit --amend : 커밋과 커밋메시지를 수정 , SHA-1 값이 변경됨

커밋 메시지를 여러 개 수정하기

예전 커밋을 수정하려면 git rebase -i가 제격임
참고 : https://docs.github.com/en/get-started/using-git/about-git-rebase

git rebase -i other-branch-name
#혹은 
git rebase -i HEAD~7

git rebase -i 를 실행하면 다음과 같이 터미널 창이 변한다.

pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick fa39187 something to add to patch A
pick 4ca2acc i cant' typ goods
pick 7b36971 something to move before patch B

# Rebase 41a72e6..7b36971 onto 41a72e6
#
# Commands:
#  p, pick = 해당 커밋을 그대로 사용한다. 
#  r, reword = 커밋을 그대로 사용하지만 메세지만 변경한다. 
#  e, edit =  커밋을 변경할 수 있다. :wq를 입력했을 떄 해당 커밋으로 이동해서 소스 코드를 변경하고 커밋을 변경하게된다. 
#  s, squash = 이전 커밋과 합친다. 
#  f, fixup = squash와 비슷하지만 커밋메시지는 버린다. 
#  x, exec = 임의의 shell command를 실행한다. 
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

해당 창을 벗어나면 입력한 Commands에 따라서 커밋들을 수정할 수 있다.

사례를 통해 알아보자

커밋 메시지 여러개를 수정하는 경우

pick 1fc6c95 Patch A
edit 6b2481b Patch B
edit dd1475d something I want to split
pick c619268 A fix for Patch B
edit fa39187 something to add to patch A
pick 4ca2acc i cant' typ goods
pick 7b36971 something to move before patch B

:wq로 깃 에디터 창을 벗어나면 edit을 쓴 커밋들로 돌아가게된다.

소스코드를 수정하고 git commit --amend를 실행해서 커밋 메시지를 변경한다.
그 후 다음 커밋으로 넘어가기 위해서 git rebase --continue를 사용한다.

커밋 순서 바꾸기

커밋 순서를 변경하는 것도 간단하다. git rebase -i HEAD~4 로 깃 에디터 창을 열고
커밋 라인의 순서를 변경한다.

# 변경전
pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B

# 변경후
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick 1fc6c95 Patch A
pick 6b2481b Patch B

커밋 합치기

s를 사용한다.

pick 1fc6c95 Patch A
squash 6b2481b Patch B
squash dd1475d something I want to split

이전 커밋과 합쳐진다. 위 Command대로라면 하나의 커밋으로 변경된다.

커밋 분리하기

커밋을 분리한다는 것은 기존의 커밋을 해제하고 stage를 여러개로 분리하고 나서 그것을 원하는 횟수만큼 다시 커밋하는 것이다.

우선 git rebase HEAD~2 를 실행하고 edit을 이용해 특정 커밋으로 이동하자

pick 1fc6c95 Patch A
edit 6b2481b Patch B

그 다음에 git reset HEAD^를 통해서 커밋을 해제한다.
수정했던 파일은 Unstaged 상태가 된다.

그 다음에 파일을 Stage한 후 커밋하는 일을 원하는 만큼 반복하고 나서 git rebase --continue라는 명령어를 실행하면 끝난다.

filter-branch

수정해야하는 커밋이 너무 많을 때 사용한다.
모든 커밋에서 파일을 제거하기

모든 passwords.txt를 제거한다.

git filter-branch --tree-filter 'rm -f passwords.txt' HEAD

모든 커밋의 이메일 주소를 수정하는 방법도 있다.

git filter-branch --commit-filter '
    if [ "$GIT_AUTHOR_EMAIL" = "schacon@loacalhost"];
    then 
              GIT_AUTHOR_NAME="Scott Chacon";
              GIT_AUTHOR_EMAIL="schacon@example.com"
              git commit-tree "$@"
     else
             git commit-tree "$@"
    fi' HEAD

Git Reset 이해하기

Git을 서로 다른 세 트리를 관리하는 콘텐츠 관리자로 생각해보자. (트리는 간단하게 파일의 묶음이다)

트리	역할
HEAD	마지막 커밋 스냅샷, 현재 브랜치를 가리키는 포인터, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킴
Index	다음에 커밋할 스냅샷 , Staging Area에 있는 것들
워킹 디렉토리	샌드박스 (맘대로 가지고 놀 수 있는 놀이터 흙바닥 느낌)

결국 Git은 프로젝트의 스냅샷을 지속적으로 저장하는 것이다.

git status는 트리들의 차이점을 설명하는 명령어이다.

reset의 역할

1. HEAD 이동 : checkout 명령처럼 HEAD가 가리키는 브랜치를 바꾸지는 않는다. HEAD는 현재 브랜치를 가리키고 현재 브랜치가 가리키는 커밋을 바꾸는 것이다! reset --soft 옵션을 사용하면 딱 여기까지만 수행한다. Index나 워킹 디렉토리는 그대로 두고 브랜치가 가리키는 커밋만 이전으로 되돌린다.
2. Index 업데이트 : Index를 현재 HEAD가 가리키는 스냅샷으로 업데이트 할 수 있다. 즉 stageArea를 비울 수 있다는 것이다. git reset --mixed옵션을 사용하면 여기까지만 수행한다.
3. 워킹 디렉토리 업데이트: reset 명령은 세 번째 워킹 디렉토리까지 업데이트한다. --hard옵션을 사용하면 reset 명령은 이 단계까지 수행한다.

경로를 주고 Reset 하기

reset 명령을 실행할 때 경로를 지정하면 1단계를 건너뛰고 정해진 경로의 파일에만 나머지 reset 단계를 적용한다. (HEAD의 이동이 없다.) 하지만 2,3단계는 가능하다.

ex) git reset file.txt명령을 실행한다고 가정하자. (git reset --mixed HEAD file.txt와 같다.)
다음과 같은 일이 발생한다.

1. HEAD의 브랜치를 옮긴다. (건너뜀)
2. index를 HEAD가 가리키는 상태로 만든다. (여기서 멈춤)

본질적으로 file.txt 파일을 HEAD에서 Index로 복사하는 것뿐이다.
(만약 file.txt가 Staging-Area에 있다면 staging area에서 워킹디렉토리로 옮기는 것과 비슷하다 )

reset을 이용해서 합치기

git reset --soft HEAD~2로 이전으로 되돌아가서 커밋을 다시하면 된다.

Checkout

checkout은 reset과 비슷하지만 좀 다르다. (파일 경로를 쓰지 않았을 때)

• checkout은 워킹디렉토리를 안전하게 다룬다. 워킹디렉토리에서 Merge작업을 한번 시도해보고 변경하지 않은 파일만 업데이트한다.
• 반면 reset --hard 명령은 확인하지 않고 단순히 모든 것을 바꿔버린다. reset은 HEAD를 움직이지 않고 checkout은 HEAD를 움직여버린다.

checkout 명령을 실행할 때도 파일 경로를 줄 수 있다.
이때 HEAD는 옮겨지지 않는다. 동작은 git reset [branch] file과 비슷하다.
Index의 내용이 해당 커밋버전으로 변경되고 워킹 디렉토리의 파일도 해당 커밋 버전으로 변경된다. git reset --hard [branch] file과 같다. (워킹디렉토리 불안전 , HEAD가 움직이지도 않음)

wd는 워킹디렉토리를 말한다.

HEAD	Index	Workdir	WD Safe?
Commit Level
reset --soft [commit]	REF	NO	NO
reset [commit]	REF	YES	NO
reset --hard [commit]	REF	YES	YES
checkout	HEAD	YES	YES
File Level
reset [commit]	NO	YES	NO
checkout [commit]	NO	YES	YES