Important

  • 전역 설정 파일

 

Nice To Have

  • 커스텀 명령어 작성

 

깃 저장소는 각각의 로컬 설정 파일(config)이 존재하고 한 사용자가 생성한 저장소에 모두 적용되는 전역 설정 파일(.gitconfig)이 존재한다.

 

# .gitconfig
[alias]
    s = status
    
# ...... #

$ git s

 

전역 설정 파일이나 터미널에서 명령어를 임의로 설정하여 사용할 수 있다.

 

$ git config --global alias.<별칭> <명령어>

 

commit -m "메시지" 와 같이 인자가 있는 경우도 똑같이 작성하면 된다.

 

 

Important

  • reflog 파일 탐색
  • reflog 명령어
  • 잃어버린 커밋 복구
  • 리베이스 되돌리기

 

Nice To Have

  • 시간 기반 reflog 수식자

 

reference log의 약어이다.

커밋을 잃어버리거나 rebase를 하지 말아야 할 때 rebase를 하는 등 문제를 되돌리고 싶을 때 사용한다.

깃을 실수 없이 올바르게 사용한다면 다룰일이 없는 명령어이기도 하다.

 

그리고 지역적이다. 내 컴퓨터의 참조목록에 대한 변경사항만을 저장하고 기록한다.

또한 로그가 영구적으로 남지 않고 기본 설정으로는 90일 정도 지나면 삭제된다.

 

 

git reflog

show, expire, delete, exists 총 4가지의 하위 명령어와 같이 사용하지만 show 말고는 별로 사용되지 않는다.

git reflog show <ref> : ref의 이력을 모두 확인한다.

 

HEAD~2와 HEAD@{2}는 다르다. HEAD~2는 커밋의 조부모로 거슬러 올라가는 것이고 HEAD@{2}는 HEAD의 2항목 이전의 움직임이다. 커밋이 아니라 단순히 switch일수도 있는 것이다.

 

 

$ git reflog main@{2}
$ git reflog show main@{2.days.ago}
$ git reflog show main@{one.week.ago}
$ git reflog show main@{yesterday}

 

reflog의 모든 항목에는 타임 스탬프가 존재하기 때문에 항목 지정 뿐만 아니라 날짜를 지정할 수도 있다.

 

 

사라진 커밋 복구

reset으로 커밋이 사라지더라도 로그에는 남아있게 된다.

 

로그의 참조값으로 다시 reset을 하면 사라졌던 커밋이 복구된다.

 

리베이스 취소

위와 같이 interactive rebase로 커밋을 정리했는데 실수였다는게 판단되면 reflog로 되돌리면 된다.

 

flowers@{2} 또는 해당 해시로 돌아가면 그대로 복구된다

 

복구 완료

reflog와 reset을 이용해서 삭제된 커밋이나 잘못된 리베이스를 되돌릴 수 있다.

 

명령어로 커밋들을 삭제한다고 해서 실제로 삭제되는것이 아니라 댕글링 커밋이 된다.

reflog는 모든 로그가 남기때문에 댕글링 커밋들을 되살릴 수 있는것이다.

 

앞서 언급했듯이 reflog는 지역적이고 영구적이지 않다는 것을 명심해야 한다.

Important

  • 로컬 설정 파일

 

Nice To Have

  • refs 디렉토리
  • HEAD 파일
  • 해싱 함수의 기초
  • 깃 오브젝트

 

이번 섹션은 깃을 사용하는데에 있어서 크게 중요하지는 않다.

 

 

.git 폴더의 구성요소들

config 파일을 직접 수정하거나 명령어를 통해서 깃의 설정을 로컬 또는 글로벌로 바꿀 수 있다.

 

refs/

브랜치 포인터, 태그 포인터 등 커밋을 가리키는 참조값이 저장된다.

 

HEAD

커밋 해시(분리된 상태) 또는 브랜치/태그 포인터를 가리키는 참조값이 저장된다.

 

object/

저장소의 모든 데이터를 저장한다. 커밋, 트리, 블롭, 주석 태그 4종류의 깃 객체가 저장된다.

 

 

깃은 SHA-1이라는 해시 함수를 사용한다.

key(해시)-value(파일) 형식으로 작동한다. 사용자가 해시를 제시하면 파일을 반환해주는 구조이다.

깃의 해시는 반드시 깃 오브젝트와 연결되어있다.

 

깃은 해시값의 변경 여부를 확인해서 파일의 변경여부를 체크하게 된다.

오브젝트 폴더에는 해싱된 파일들이 저장되고 브랜치나 커밋 변경 시 해시 값으로 파일들을 참조하게 되는것으로 보인다.

 

$ git cat-file -p <hash>

 

위의 명령어로 해시값을 건네서 값을 돌려받을 수 있다.

 

블롭(Blob, Binary Large Object)

파일 내용을 저장하는 객체. 파일이 담고 있는 내용 그 자체이다. 파일명을 제외하고 오직 내용만 저장한다.

 

트리

디렉토리 내용을 저장한다. 블롭을 가리키는 포인터와 트리를 가리키는 포인터 둘 다 가지고 있다.

블롭의 파일명은 트리가 저장한다.

 

커밋

커밋을 하게되면 트리, 부모 등이 저장된다. 체크아웃이나 브랜치를 생성하면 해당 커밋의 트리를 토대로 작업 영역을 구성하게 된다.

 

$ git cat-file -t <hash> # 객체의 종류를 알려준다. tree/blob/commit

Important

  • git tag 이해하기
  • 태그 보기
  • 태그 생성 및 푸시

 

Nice To Have

  • Semantic versioning
  • 태그 비교/삭제/옮기기

 

깃 태그는 특정 커밋에 추가하는 일종의 라벨이다. 주로 릴리즈 버전을 표시하는 용도로 사용된다.

커밋이 추가되면 같이 이동하는 브랜치 참조와 다르게 처음 지정된 커밋을 계속 참조한다.

 

 

*태그의 두 종류*

일반 태그(lightweight) : 특정 순간에 이름을 붙인다.

주석 태그(annotated) : 태그 메시지, 생성자 이름, 이메일, 날짜 등을 포함한다.

 

큰 프로젝트에서는 주석 태그를 선호하는 편이다.

 

 

시맨틱 버저닝(Semantic versioning)

버전 번호를 매기는 일종의 규칙이다.

버전명은 숫자 세개와 숫자 사이 점으로 구성된다. 2.4.1 같은 형태이다.

순서대로 메이저 릴리즈, 마이너 릴리즈, 패치 릴리즈이다.

 

패치 : 신규 기능이나 의미 있는 변경사항을 수반하지 않는다. 단순한 버그 수정이나 아주 미미한 수정사항만 포함된다.

마이너 : 신기능이 추가됐을 때 배포되며 하위 호환성이 유지된다. 반드시 신기능이 추가되는것은 아니지만 추가된 것으로 인해 사용자의 이용 경험이 바뀌지 않으면 마이너 릴리즈로 배포된다.

메이저 : 하위 호환성이 보장되지 않을 때, 기능 삭제 또는 큰 변화가 있을 때 배포된다. 사용자의 이용 경험이 달라질 수 있다.

 

 

git tag

현재 저장소의 모든 태그를 조회한다.

git tag <tagname> : HEAD가 가리키는 커밋에 일반 태그를 생성한다.

git tag -a <tagname> : HEAD가 가리키는 커밋에 주석 태그를 생성한다.

git tag <tagname> <commit-hash> : commit-hash가 가리키는 커밋에 태그를 생성한다.

git tag -l "*beta*" : beta라는 글자가 포함된 태그를 모두 조회한다. 만약 "beta*" 인 경우에는 beta로 시작하는 태그를 검색한다. "*beta" 는 beta로 끝나는 태그를 검색한다.

git tag -f <tagname> <commit-hash> : 태그를 이동시킨다.

git tag -d : 태그를 삭제한다.

 

 

git checkout <tag>

태그를 체크아웃한다. 브랜치 체크아웃과 다른점은 브랜치가 아닌 특정 커밋을 가리킨다는 점이다.

 

 

git diff <tag1>..<tag2>

두 태그를 비교한다. 예전에 두 커밋을 비교했던 것과 완전히 동일하다.

 

 

git show <tagname>

태그 정보를 조회한다.

 

태그는 고유한 값이어야만 하기 때문에 중복 부여가 불가능하다.

 

 

커밋을 원격 저장소로 푸시한다고 해서 태그도 같이 푸시되는 것은 아니다.

태그는 별도로 푸시 해주어야 한다.

 

$ git push --tags # 모든 태그 푸시
$ git push origin <tagname> # 특정 태그만 푸시

Nice To Have

  • 커밋 재작성
  • 커밋 수정 및 스쿼싱(결합)
  • 커밋 삭제

 

rebase -i 명령어를 통해서 이미 존재하는 커밋 이력을 편집, 조작할 수 있다.

 

파란글씨의 명령어를 수정해주면 된다

reword, edit 등 수정사항이 여러개라면 각 커밋마다 작업을 하나씩 순차적으로 해주어야 한다.

변경 작업이 완료되면 커밋 해시가 바뀌게 된다. 즉, 작업 대상의 커밋들이 모두 재생성 되었다는 얘기이다.

추가로 특정 브랜치를 지정하지 않고 현재 HEAD가 위치한 브랜치를 기점으로 리베이스를 하게된다.

 

git rebase -i [commit-hash]

 

pick : 커밋 유지

reword : 커밋 유지. 단, 커밋 메시지만 재작성

edit : 작업과 커밋 메시지 모두 재작성

fixup : 이전 커밋과 병합. 단, 커밋 메시지는 병합하지 않는다. (squash와 기능적으로 동일)

위(이전)커밋과 병합, 메시지는 삭제
이 경우는 순차적으로 적용된다

drop : 커밋 삭제

 

squash는 fetch/pull의 미묘한 차이처럼 fixup 이후 reword를 실행한 것과 같다고 보면 된다.

 

보통 작업중인 피처 브랜치를 공유하기 전에 interactive rebase를 통해서 커밋 이력들을 정리한다.

바로 직전 커밋 하나만을 수정하는 경우라면 amend를 사용하는 것이 간편하다.

+ Recent posts