Advanced Git

[simoniful]

Merge Conflicts

• GItUp - 브랜치 및 커밋 시각화
• 충돌 발생 시 보여지는 메시지 스타일 변경
  • git config merge.conflictstyle diff3
  • 참고
• Git diff tool 설정
  • apple 내장형 Diff / VSCode 등 여러 Diff 툴을 선택적으로 적용 가능
  • git config merge.tool open diff
  • 참고

Stashes

아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어
이를 통해 아직 완료하지 않은 일을 commit하지 않고 나중에 다시 꺼내와 마무리할 수 있다.
stash란 아래에 해당하는 파일들을 보관해두는 장소가 된다

• Modified이면서 Tracked 상태인 파일
  • Tracked 상태인 파일을 수정한 경우
  • Tracked: 과거에 이미 commit하여 스냅샷에 넣어진 관리 대상 상태의 파일
• Staging Area에 있는 파일(Staged 상태의 파일)
  • git add 명령을 실행한 경우
  • Staged 상태로 만들려면 git add 명령을 실행해야 한다.
  • git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다.

1. 하던 작업 임시로 보관

git stash

위의 명령어를 통해 새로운 stash를 스택에 만들어 하던 작업을 임시로 저장한다.
예를 들어, 파일 2개를 수정하고 그 중 하나는 Staging Area에 추가한다.
아직 작업 중인 2개의 파일은 commit할 게 아니기 때문에 모두 stash에 넣는다

// working directory에 있는 파일의 상태 확인
// index.html: Staging Area에 있는 파일(Staged 상태의 파일)
// lib/simplegit.rb: Modified이면서 Tracked 상태인 파일

$ git status
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified:   index.html
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified:   lib/simplegit.rb

// git stash 나 git stash save 를 실행하면 스택에 새로운 stash가 만들어진다. 
// 이 과정을 통해 working directory는 깨끗해진다.
$ git stash

이제 새로운 작업을 위한 다른 브랜치로 변경할 수 있다.

2. stash 목록 확인하기

git stash list

여러 번 stash를 했다면 위의 명령어를 통해 저장한 stash 목록을 확인할 수 있다.

$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log

3. stash 적용하기(했던 작업을 다시 가져오기)

git stash apply

위의 명령어를 통해 했던 작업을 다시 가져온다.

// 가장 최근의 stash를 가져와 적용한다.
$ git stash apply
// stash 이름(ex. stash@{2})에 해당하는 stash를 적용한다.
$ git stash apply [stash 이름]

위의 명령어로는 Staged 상태였던 파일을 자동으로 다시 Staged 상태로 만들어 주지 않는다.
–index 옵션을 주어야 Staged 상태까지 복원한다.
이를 통해 원래 작업하던 파일의 상태로 돌아올 수 있다.

• git stash apply
  
• git stash apply –index
  

수정했던 파일들을 복원할 때 반드시 stash했을 때와 같은 브랜치일 필요는 없다.
만약 다른 작업 중이던 브랜치에 이전의 작업들을 추가했을 때 충돌이 있으면 알려준다.

4. stash 제거하기

git stash drop

apply 옵션은 단순히 stash를 적용하는 것으로, 해당 stash는 스택에 여전히 남아있다.
스택에 남아 있는 stash는 위의 명령어을 사용하여 제거할 수 있다.

// 가장 최근의 stash를 제거한다.
$ git stash drop
// stash 이름(ex. stash@{2})에 해당하는 stash를 제거한다.
$ git stash drop [stash 이름]

git stash pop
만약 적용과 동시에 스택에서 해당 stash를 제거하고 싶으면 git stash pop 명령을 사용하면 된다.

// apply + drop의 형태
$ git stash pop

5. stash 되돌리기

git stash show -p | git apply -R

실수로 잘못 stash 적용한 것을 되돌리고 싶으면 위의 명령어를 이용한다.

// 가장 최근의 stash를 사용하여 패치를 만들고 그것을 거꾸로 적용한다.
$ git stash show -p | git apply -R
// stash 이름(ex. stash@{2})에 해당하는 stash를 이용하여 거꾸로 적용한다.
$ git stash show -p [stash 이름] | git apply -R

Aliases

// alias로 등록한 stash 되돌리기 명령어
$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
$ git stash apply
$ #... work work work
$ git stash-unapply

// alias로 등록한 상세 log 보기 명령어
$ git config --global alias.gl 'log --oneline --decorate --graph --all'
$ git gl

// 글로벌 변수가 아닌 프로젝트 국한하여 git 관련 config 커스텀 확인
$ cat .git/config

// 글로벌 변수로 설정한 git 관련 config 커스텀 확인
$ cat ~/.gitconfig

---

리눅스 echo 명령어

printf에 해당하는 출력 명령어
화면이나 파일로 상황을 알리는 문자열을 출력할 때 사용

// 콘솔창에 "My name is Simon" 출력 
$ echo My name is Simon

리눅스 >와 »의 차이

• >: 명령어 뒤에 나오는 파일에 쓸 때 사용(= write or overwrite)
• >>: 명령어 뒤에 나오는 파일에 추가할 때 사용(= append)

// 다음 아래 같이 echo와 사용하면 test.txt라는 파일이 없을 때는 생성하며 있다면 내용을 덮어쓰게 된다
$ echo abcde > test.txt
// 다음 아래 같이 echo와 사용하면 test.txt라는 파일이 없을 때는 생성하며 있다면 test.txt 파일에 내용을 추가하게 된다
$ echo abcde >> test.txt

리눅스 cat 명령어

cat [확인하고자 하는 파일]
파일 또는 텍스트의 내용을 콜솔 화면에 출력하는 명령어

---

Git Tracking 관리

1. 특정 파일에 대해서는 커밋을 하지 않게 만들도록 지시

// 특정 파일을 변경하지만 변경 상태를 무시하고자 할 때
$ git update-index --assume-unchanged [추적하지 않고자 하는 파일 이름]

// 변경 상태를 무시한 파일을 다시 돌리는 명령어
$ git update-index --no-assume-unchanged [추적을 다시 하고자 하는 파일 이름]

// 깃으로 관리되는 파일의 목록을 나타내는 명령어
$ git ls-files -v

// 무시한 파일들의 목록을 나타내는 명령어
$ git ls-files -v | grep '^[[:lower:]]'

2. 특정 파일 트래킹 캐시 삭제

git rm --cached [추척하지 않고자하는 파일 이름]

// 원격 저장소와 로컬 저장소 파일을 삭제
$ git rm [파일명]
 
// 원격 저장소에 있는 파일만 삭제하고, 로컬 저장소에 있는 파일은 삭제하지 않음
$ git rm --cached [파일명]

// 폴더 하위의 모든 파일을 삭제
$ git rm -r --cached [폴더명]

git rm --cached 한다고 원격 저장소에서 파일이 삭제되는 것이 아니라
add - commit - push 의 과정을 거쳐야 비로소 삭제가 된다

CherryPick

원하는 커밋을 어느 브랜치 건 간에 커밋을 추가할 수 있다

git cherry-pick [추가하고자 하는 커밋 해시]

---

FIlter Branch

참고

한 두개의 커밋이 아닌 수 백개 이상의 이미 공유된 커밋을 일정한 규칙에 따라 히스토리를 전부 변경하고 싶을 때 사용
만약 API Key와 같은 중요한 보안적 사항이 포함된 파일이 이미 리모트 레포에 push 되었을 때
이미 올라 간 것에 대한 트레킹을 모두 지우고 해당 파일을 관리하고 싶을 경우 사용 가능하다
각각의 커밋에 필터를 적용시키는 것이 가능하다

1. Tree Filter

git filter-branch --tree-filter 'rm -f [제거하고자 하는 추적 파일]' HEAD

하나씩 스테이징을 검사하면서 해당 필터 적용
시스템 리소스 소요가 많은 편

2. Index Filter

스테이징 부분이 아닌 index로 접근하여 원하는 필터 적용
그냥 적용시 해당하는 부분을 필터링 후에 비어있는 커밋이 남아있는 경우 발생

git filter-branch --index-filter 'git rm --cached --ignore-unmatch -- SECRETS' HEAD

Index Filter + Prune Empty 옵션

필터링 후에 비어있는 커밋을 정리

git filter-branch --index-filter 'git rm --cached --ignore-unmatch -- SECRETS' --prune-empty -f HEAD

3. End Filter / Environment Filter

커밋한 사람, 이메일 주소 등 환경 변수를 일괄적으로 관리하고 싶은 경우 사용

git filter-branch -f --commit-filter '
quote> if [ "$GIT_AUTHOR_NAME" = "sammyd" ];
quote> then
quote> GIT_AUTHOR_NAME="Yasmin";
quote> GIT_AUTHOR_EMAIL="[email protected]";
quote> git commit-tree "$@";
quote> else
quote> git commit-tree "$@";
quote> fi' HEAD

---

Git 취소하고 되돌리기

1. git reset

Detached HEAD란 ?

HEAD가 특정 branch가 아닌 특정 commit을 직접 참조하고 있는 상태를 말한다
Detached HEAD 상태에서도 모든 Git 조작을 수행할 수 있다
Detached HEAD 상태에서 새롭게 생성된 commit은 참조하는 branch가 없기 때문에
다른 branch로 checkout 하게 되면 해당 commit은 가비지 콜렉터에 의해 삭제된다
Detached HEAD 상태에서 아직 벗어나지 않았을 때 선언한 commit을 유지하고 싶다면,
새로운 branch나 tag를 만들어 해당 commit을 참조하게 하면 된다

Detached HEAD 상태에서 선언한 commit을 두고 다른 branch로 이동한 경우
삭제되기 전에 해당 commit에 대한 객체 이름(Commit ID)을 복구해
해당 commit을 참조하는 branch나 tag를 만들면 된다
보통 해당 repo에서 기록을 남기지 않고 시뮬레이션을 해보고 싶을 때
detached 상태를 이용하지만, Git에서 지양하는 상태로
test branch를 만들어 사용하는 것이 좋다

Reset

reset의 경우 원하는 커밋으로 HEAD를 전환하고
브랜치 또한 해당 커밋의 브랜치의 가지에 맞게 연결시킨다
만약 아래와 같이 노란색 브랜치에서 5번 커밋으로 이동하면서 reset을 실행한 경우
노란색 브랜치는 참조를 잃게 되어 가비지 컬렉터에 의해서 정리된다
reset은 커밋을 취소할 때 가장 적합하며 3가지 유형의 옵션 방식이 있다

git reset --hard HEAD

HEAD를 쓰면 바로 이전의 커밋에 대한 reset을 실행하게 되고
원하는 hash나 브랜치 이름도 사용 가능하다
origin에 올리지 않고 로컬에 커밋이 머물렀다면,
올라갔어도 나만 해당 브랜치를 사용한다면 reset를 써도 된다
origin에 올린 상태에서 reset하고 push 한다면
위처럼 다른 사람간 코드가 공유될 때,
reset를 사용하면 상상치도 못하는 헬게이트가 열린다
그러므로 reset를 사용하는 경우는

• 혼자만 사용하는 브랜치인 경우
• origin에 있지만 아무도 이 브랜치를 사용하지 않는다는 확신을 가지는 경우

1. Soft Reset

--soft 옵션을 쓰면 HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리키게 된다
대신 현재 작업 중인 working directory와 staging area는 아무런 영향을 받지 않�는다

2. Mixed Reset

--mixed 옵션을 쓰면 HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리키게 된다
그리고 staging area도 해당 커밋의 모습과 동일하게 변한다
하지만 현재 작업 중인 working directory는 아무런 영향을 받지 않는다

3. Hard Reset

--hard 옵션을 쓰면 HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리키게 된다
그리고 staging area와 현재 작업 중인 working directory도 해당 커밋의 모습과 동일하게 변한다

2. git reflog

git rebase 또는 git reset 등으로 커밋이 삭제될 수 있다
하지만, git 이력은 보관되고 있는데 이러한 이력을 볼 수 있는 명령어가 git reflog

• commit 복구하기
  • git reflog 명령어로 삭제된 commit id 확인 후
  • git reset --hard [커밋해시id]
• branch 복구하기
  • git reflog 또는 git reflog |grep 브랜치명 으로 log확인
  • git checkout -b [삭제한 브랜치명] [커밋해시id]

3. git revert

github 같은 온라인 저장소에 올라가 다른 사람간 코드 공유가 있는 경우 사용
revert는 reset과 다르게 커밋을 삭제하는 것이 아닌 커밋을 추가한다
그러나 이전 커밋과 정반대의 데이터를 추가하는 방식으로 코드를 되돌린다
만약 revert한 결과를 stage 상태만 유지하고, commit 하지 않으려면 --no-commit 옵션을 사용한다
revert는 되돌리는 커밋이 중간에 있을때 커밋 해쉬를 넣어서 중간 커밋만 삭제할 수 있고,
어떤 커밋이 왜 revert 됬는지 commit message를 통해 관찰 가능함으로 더욱 유용하다
또는 revert는 커밋은 삭제되는 것보다 이전으로 되돌리는 이력마저 남기는 것이 history 유지 차원에서 더 좋다