Git에 대한 간단한 정리

 현재는 VCS로 SVN을 사용하고 있는데, 다음 프로젝트에서는 git을 사용할 수도 있다고 해서 평소 사뒀던 git 관련 책을 읽었다. 개인적으로는 git을 자주 사용하고 있기 때문에 이해하기는 그렇게 어렵지 않았고, 깃의 내부 구조가 어떻게 되고 어떻게 돌아가는지 알게 되어 좋았다.

 내가 참고한 책은 토미의 Git with 소스트리로, 이곳을 통해 PDF파일로 구매했다. 책은 git의 각 기능에 대해 설명하고 이를 소스트리로 어떻게 동작시키는지로 구성되어 있는데, 나의 경우 소스트리를 사용하지 않고 거의 CLI(아니면 깃크라켄)로 사용하기 때문에 소스트리 사용법은 과감하게 패스했다.

 본 포스팅은 위에 말한대로 어느 정도 깃을 사용한 경험을 바탕으로 내가 모르거나 정리가 필요한 부분만 집중적으로 책의 내용을 너무 깊게 드러내지 않는 한에서 정리한 것이므로 더 자세한 정보를 원한다면 저 책을 사서 보는 걸 추천한다.

---

중앙집중형 버전 관리와 분산형 버전 관리

 SVN과 같은 중앙집중형 버전 관리는 중앙에 버전 관리 서버가 있고 클라이언트가 작업해서 서버에 반영하는 방식으로, 같은 파일을 여러 사람이 수정하면 충돌이 생김. 이 충돌을 해결하기 전까지는 다른 사람이 작업을 진행할 수 없음.

 반면 분산형 버전 관리는 원격처럼 로컬에도 저장소가 존재하여 이 두 저장소로 작업을 진행.

---

 델타 모델과 스냅샷 모델

 쉽게 말하자면 델타 모델은 이전 버전과 비교해서 달라진 부분만 저장하는 것이고, 스냅샷 모델은 그때 그때의 버전을 저장하는 것. 델타 모델은 특정 모델을 체크아웃하려고 하면 처음부터 끝까지의 달라진 부분을 전부 살펴봐야 하므로 버전이 많아질수록 체크아웃 성능이 저하.

 스냅샷모델인 git은 특정 조건이 되면 현재 버전 중 유사한 내용을 가진 버전을 통합해 하나의 압축된 Pack 파일로 변환. 이때 Pack 파일은 델타 모델을 사용.

---

SHA-1

 SHA-1은 입력값을 40자리 16진수로 출력. git에서는 객체 내용으로 만든 SHA-1를 id로 사용. id는 객체 타입 + 객체 크기 + 객체 내용 + \0 으로 구성.

---

영역

작업 디렉토리, 인덱스(=스테이징 영역), 객체 데이터베이스 세 가지 영역. .git 내부의 objects가 객체 데이터베이스, .git 내부의 index가 인덱스.

---

객체

 블랍(Binary large object), 트리, 커밋, 태그 네 가지 객체.

• 블랍: 커밋한 파일의 내용(git cat-file -p). 인덱스에 내용이 추가될 때 생성.
• 트리: 블랍을 참조. 디렉토리.
• 커밋: 트리를 참조. 작성자, 커미터, 메시지, 부모 커밋 포함.(부모 커밋이 두 개 이상이면 머지된 커밋)
• 태그: 특정 커밋을 사람이 기억하기 쉽게 표시.(git tag) lightweight과 annotated 태그 두 가지.

---

.Git

 git은 .git 디렉토리를 저장소로 사용. 블랍, 트리, 커밋, 태그 모두 이 디렉토리에 존재.

---

HEAD

 현재 활성화된 브랜치의 가장 최근 커밋을 가리킴.

---

변경사항 되돌리기 - reset과 revert

• reset: 커밋 이력 자체를 삭제. 원격에 푸시한 커밋을 reset하는 것은 비추.
  • soft: 스테이징 유지
  • mixed: 변경됨 유지
  • hard: 완전 제거
• revert: 커밋 이력 유지한 채 이전 커밋을 무효화시키는 커밋 생성(코드 삭제한 커밋이면 다시 코드가 존재하거나, 코드가 추가된 커밋이면 다시 삭제하는 식으로). 원격에 푸시되었던 커밋일 때 사용 가능.

---

 

합치기 - fast forward merge와 three way merge, rebase

• fast forward merge: 머지시킬 브랜치에서만 변경사항이 생겼을 때.
• three way merge: 양 브랜치에서 변경사항이 생겨 두 브랜치의 변경사항을 반영하기 위한 새로운 커밋을 생성해야 할 때.
• rebase: (three way merge와 같은 상황)브랜치의 base를 변경해서 머지. 기존 커밋이 버려지므로 개인저장소에서 수행해야 함. 예전 커밋으로 돌아가기 어려움. (merge되는 브랜치로 checkout 후 rebase [merge할 브랜치] 실행. 이후 merge할 브랜치로 checkout 후 merge [merge될 브랜치] 실행.)
  • main 브랜치로부터 feature 브랜치 땀
  • feature 브랜치에서 기능 개발해서 커밋(이때까지는 fast forward merge 가능)
  • main 브랜치에 다른 사람이 새로운 개발내용 반영(이때부터 three way merge나 rebase로 merge 가능)
  • feature 브랜치에서 main 브랜치로 rebase
  • main브랜치에서 feature 브랜치 merge
• 머지시 충돌은 같은 파일의 같은 부분을 변경했을 때 발생.

---

REMOTE(원격저장소)

 로컬저장소는 원격저장소의 브랜치 상태를 저장하고 있는데, 이를 구분하기 위하여 로컬은 master, 원격은 origin/master와 같이 표시.

---

다른 사람이 원격저장소에 푸시한 내용 로컬에 반영하기 - fetch와 pull

• fetch: 다른 사람이 원격저장소에 푸시한 내용을 로컬에 반영하기 위한 명령어. fetch를 하면 원격저장소의 추적 브랜치가 변경되고, 로컬저장소의 브랜치는 변경되지 않음. 그렇기 때문에 로컬저장소의 브랜치도 원격저장소의 추적 브랜치를 따라 변경하려면 머지 필요.
• pull: fetch + merge.

---

커밋 복원 - reflog

모든 참조를 보여줌. 참조이력은 일반적으로 90일간 보관.

---

커밋은 하고 싶지 않지만 작업내용을 옮겨서 다른 곳에서 작업하고 싶을 때 - patch

패치 파일 생성하여 작업하고 싶은 곳에 적용.

---

커밋 골라서 적용 - cherry pick

특정 커밋만 골라서 적용하고 싶을 때 사용.

---

 이 책을 읽으면서 기계적으로 사용했던 깃 명령어들과 기계적으로 해결했던 문제들이 왜 발생했는지 알게 되었다. 내가 정리한 내용은 온통 줄글이지만 책에 보면 그림으로 아주 이해하기 쉽게 표현되어 있으므로 꼭 책을 사서 보고 이해하는 걸 추천한다. 그리고 이렇게 정리한 내용을 딱 보면 다 알 것 같지만 실전에서는 막상 생각 안 날 때도 많으니까 실전에서 잘 써먹을 수 있도록 실습을 많이 해봐야겠다.