파이썬 코드로 배우는 Git GitHub

 

p.76

-a는 --all 옵션과 동일한 기능을 하며, 수정하거나 삭제된 파일에 대한 스테이징을 자동으로 진행하는 옵션입니다. 단 untracked 파일에는 적용이 되지 않으므로 주의해야 합니다.

 

p.79

git status -s의 표시 문자 별 파일의 상태

 

?? : Untracked

M : Modified

MM : 파일이 스테이징된 후, 다시 Modified

A : 경로가 스테이징된 후, 경로 내에 Untracked 파일 발생

 

p.81~

-p 또는 --patch 옵션은 각 로그의 상세 정보를 출력합니다.

 

git log -p 

 

여기에 -1 옵션을 추가해서 가장 최근 커밋만 상세 정보를 출력해 봅니다.

 

git log -p -1

 

--pretty=oneline 옵션을 사용하면 커밋이 한 줄로 정리되어 출력됩니다. 커밋이 많을 때 유용합니다.

 

git log --pretty=oneline

 

--graph 옵션은 커밋 히스토리를 그래프 형태로 출력해줍니다.

 

git log --oneline --graph

 

p.84

Git은 커밋 아이디로 SHA1 알고리즘으로 만들어진 해시(hash)라는 값(3445087...)을 사용합니다. 이것은 암호화된 값으로 중복이 없는 임의의 문자열입니다. 단순한 아이디어가 아니라 해시를 사용하는 이유는 Git이 추구하는 분산형 버전관리를 위해 어떠한 상태에서도 (온라인, 오프라인 등) 커밋으로 형상 관리를 하기 위함입니다. 

 

p.84

git show는 특정 커밋의 상세 정보를 확인할 때 사용합니다.

 

p.89

git show HEAD: HEAD가 참조하는 커밋의 상세 정보 출력

git show HEAD^^^ : HEAD를 기준으로 3단계 이전의 커밋 정보 출력

git show HEAD~n : HEAD를 기준으로 n단계 이전의 커밋 정보 출력

 

p.94

옵션이 없는 git diff 명령은 Unstaged된 파일들의 수정 사항을 출력합니다. 전체 파일을 스테이징했기 때문에 출력할 내용이 없는 것입니다.

 

그럼 Staging Area의 파일과 최신 커밋의 파일의 비교는 어떻게 할까요? --staged 옵션을 추가하면 됩니다.

 

git diff --staged

 

p.95

두 커밋 간의 파일 내용을 비교하려면, git diff 뒤에 비교할 커밋 해시를 추가하면 됩니다.

 

git diff [변경 전 커밋 해시] [변경 후 커밋 해시]

 

p.98

Git으로 프로젝트 관리를 하다 보면 git add 명령으로 스테이징한 파일을 언스테이징해야하는 상황이 자주 발생합니다. 이 때 사용할 수 있는 명령이 git reset입니다. Staging Area에 올라간 파일 일부나 전체를 Working Directory로 이동시킵니다. 다시 말해 git add를 취소하는 명령입니다.

 

p.108

amend의 사전적 의미는 '변경하다', '개정하다' 입니다. 커밋을 수정하는 것처럼 보였지만 실제 내부에서는 최근에 작성한 커밋 위치를 대신해서 새로운 커밋을 생성하는 동작을 했습니다. 그래서 해시도 새롭게 만들어졌습니다. amend 명령이 별도로 존재하지 않고 git commit --amend 옵션임을 생각하면 이해될 것입니다. 결국 커밋 명령의 한 방식입니다. 

 

p.118

git checkout은 HEAD의 참조를 변경하는 명령입니다. 최신 커밋을 참조할 때 HEAD는 master를 간접 참조하고 있습니다. HEAD가 특정 커밋을 참조하기 위해 체크아웃되면 HEAD는 master 참조에서 떨어진 Detached 상태 또는 Detached HEAD가 됩니다.

 

p.120

우리가 취소하고 싶은 커밋은 fa713f8 뿐입니다. 여기서 눈여겨 볼 Git의 특성이 있는데, Git은 해당 브랜치의 이름으로 참조하는 커밋을 그 브랜치의 최신 커밋으로 인식한다는 점입니다. 우리가 작업 중인 브랜치의 이름은 master이므로 master가 참조하는 커밋을 84b4all으로 바꾸면 어떻게 될까요? master 브랜치가 84b4all를 최신 커밋으로 인식합니다. 이후에 작성된 커밋이 있더라도 무시합니다. 커밋 취소라고 했지만, 사실 지정되는 커밋 입장에서는 커밋 재설정(reset)이 되겠습니다.

 

p.120

여기서 짚고 넘어가야 할 것이 있습니다. git reset에 옵션을 추가할 수 있습니다. 입력한 옵션에 따라서 각 영역의 파일이 유지되는지, 재설정할 커밋의 상태로 변경되는지 차이가 발생합니다. 옵션에 따른 각 영역의 상태 변화는 다음과 같습니다.

 

	Working Directory	Staging Area	Repository
--hard	변경	변경	변경
--mixed (default)	유지	변경	변경
--soft	유지	유지	변경

 

p.126

만약 해시를 기억하지 못한다면 git reflog으로 해시를 추적할 수 있습니다. reflog는 reference(참조)와 log(로그)의 합성어로 HEAD의 참조 이력을 로그 형태로 출력합니다. 

 

p.129~130

master는 브랜치 이름이라고 했습니다. 브랜치가 커밋을 참조한다니 이해가 안 될 수도 있을 것 같은데, Git이 브랜치 이름을 일종의 포인터로 사용하기에 가능한 일입니다. Git에서는 이것을 참조 개체(References)라는 말을 줄여 Refs라고 부릅니다. 그런데 이 브랜치 이름으로 된 Refs는 반드시 브랜치 안의 최신 커밋(브랜치의 끝)을 참조(reference) 또는 가리키도록(pointing) 설정되어 있습니다. 브랜치의 참조 값을 알면 이 브랜치의 최신 커밋이 무엇인지 알 수 있도록 하기 위함입니다. 위에서는 master가 84b4all를 참조하고 있습니다. 그 이후에 커밋이 추가되어도 master가 84b4all를 참조하고 있으면 Git은 이 커밋을 최신으로 인식하고 이후에 기록된 커밋은 무시합니다. 로그를 출력해도 출력되지 않습니다.

 

HEAD도 무언가를 참조하는 개체입니다. 그런데 HEAD는 커밋 뿐만 아니라 master와 같은 Refs를 참조할 수도 있습니다. 다시 말해 특정 커밋을 master를 통해 간접 참조할 수도 있고, master처럼 커밋을 직접 참조할 수도 있습니다. Git은 저장소의 HEAD가 참조하는 커밋의 내용에 따라 Working Directory의 파일 상태를 변경합니다. 

 

p.131

git checkout 명령을 실행하면 HEAD의 참조가 지정한 커밋으로 변경됩니다. master의 참조는 그대로 있고 HEAD가 커밋을 직접 참조합니다. HEAD가 master로부터 떨어졌다고 해서 Detached HEAD라고 합니다.

 

반면 git reset 명령을 실행하면 브랜치의 참조가 변경됩니다. 우리는 지금까지 master 브랜치에서 실습했습니다. 앞에서 설명했듯이 브랜치 이름(master)은 항상 최신 커밋을 참조하는 것으로 간주됩니다. 따라서 master가 참조하는 커밋 이후의 것들은 무시됩니다. 마치 이후의 커밋들이 취소 또는 삭제된 것처럼 보입니다. 이때 HEAD는 master 브랜치를 참조하고 있으므로 HEAD의 참조도 함께 변경되고, 이 때문에 Working Directory의 내용도 변경됩니다.