git -reset, gitflow

git에 대해 공부하다가 잘 이해가 안된 두 가지를 따로 정리해보았다.

git reset

세 개의 트리

Git을 서로 다른 세 트리를 관리하는 컨텐츠 관리자로 생각하면 reset 과 checkout 을 좀 더 쉽게 이해할 수 있다. 여기서 “트리” 란 실제로는 “파일의 묶음” 이다. 자료구조의 트리가 아니다 세 트리 중 Index는 트리도 아니지만, 이해를 쉽게 하려고 일단 트리라고 한다.

Git은 일반적으로 세 가지 트리를 관리하는 시스템이다.

HEAD
HEAD는 현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킨다. 지금의 HEAD가 가리키는 커밋은 바로 다음 커밋의 부모가 된다. 단순하게 생각하면 HEAD는 현재 브랜치 마지막 커밋의 스냅샷이다.

Index
Index는 바로 다음에 커밋할 것들이다. 이미 앞에서 우리는 이런 개념을 “Staging Area” 라고 배운 바 있다. “Staging Area” 는 사용자가 git commit 명령을 실행했을 때 Git이 처리할 것들이 있는 곳이다.

워킹 디렉토리
마지막으로 워킹 디렉토리를 살펴보자. 위의 두 트리는 파일과 그 내용을 효율적인 형태로 .git 디렉토리에 저장한다. 하지만, 사람이 알아보기 어렵다. 워킹 디렉토리는 실제 파일로 존재한다. 바로 눈에 보이기 때문에 사용자가 편집하기 수월하다. 워킹 디렉토리는 샌드박스로 생각하자. 커밋하기 전에는 Index(Staging Area)에 올려놓고 얼마든지 변경할 수 있다.

워크플로
Git의 주목적은 프로젝트의 스냅샷을 지속적으로 저장하는 것이다. 이 트리 세 개를 사용해 더 나은 상태로 관리한다.

파일이 하나 있는 디렉토리로 이동한다. 이걸 파일의 v1이라고 하고 파란색으로 표시한다. git init 명령을 실행하면 Git 저장소가 생기고 HEAD는 아직 없는 브랜치를 가리킨다(master 는 아직 없다).

이 시점에서는 워킹 디렉토리 트리에만 데이터가 있다.
이제 파일을 커밋해보자. git add 명령으로 워킹 디렉토리의 내용을 Index로 복사한다.

그리고 git commit 명령을 실행한다. 그러면 Index의 내용을 스냅샷으로 영구히 저장하고 그 스냅샷을 가리키는 커밋 객체를 만든다. 그리고는 main이 그 커밋 객체를 가리키도록 한다.

이때 git status 명령을 실행하면 아무런 변경 사항이 없다고 나온다. 세 트리 모두가 같기 때문이다.
다시 파일 내용을 바꾸고 커밋해보자. 위에서 했던 것과 과정은 비슷하다. 먼저 워킹 디렉토리의 파일을 고친다. 이를 이 파일의 v2라고 하자. 이건 빨간색으로 표시한다.

git status 명령을 바로 실행하면 “Changes not staged for commit,” 아래에 빨간색으로 된 파일을 볼 수 있다. Index와 워킹 디렉토리가 다른 내용을 담고 있기 때문에 그렇다. git add 명령을 실행해서 변경 사항을 Index에 올려주자.

git status 명령을 바로 실행하면 “Changes not staged for commit,” 아래에 빨간색으로 된 파일을 볼 수 있다. Index와 워킹 디렉토리가 다른 내용을 담고 있기 때문에 그렇다. git add 명령을 실행해서 변경 사항을 Index에 올려주자.

이제 git status 명령을 실행하면 아무것도 출력하지 않는다. 세 개의 트리의 내용이 다시 같아졌기 때문이다.
브랜치를 바꾸거나 Clone 명령도 내부에서는 비슷한 절차를 밟는다. 브랜치를 Checkout 하면, HEAD가 새로운 브랜치를 가리키도록 바뀌고, 새로운 커밋의 스냅샷을 Index에 놓는다. 그리고 Index의 내용을 워킹 디렉토리로 복사한다.

Reset 의 역할

위의 트리 세 개를 이해하면 reset 명령이 어떻게 동작하는지 쉽게 알 수 있다.

예로 들어 file.txt 파일 하나를 수정하고 커밋한다. 이것을 세 번 반복한다. 그러면 히스토리는 아래와 같이 된다.

트리를 조작하는 세 가지 단계
1. HEAD 이동 (git reset --soft HEAD~)
reset 명령이 하는 첫 번째 일은 HEAD 브랜치를 이동시킨다. checkout 명령처럼 HEAD가 가리키는 브랜치를 바꾸지는 않는다. reset과 checkout 명령어 차이는 조금 있다 다루겠다. HEAD는 계속 현재 브랜치를 가리키고 있고, 현재 브랜치가 가리키는 커밋을 바꾼다. HEAD가 main 브랜치를 가리키고 있다면(즉 main 브랜치를 Checkout 하고 작업하고 있다면) git reset 9e5e4w1 명령은 main 브랜치가 9e5e4w1 를 가리키게 한다.

2. Index 업데이트 (git reset [--mixed] HEAD~)
   먼저 mixed 옵션은 디폴트 값이라 적지 않아도 된다. reset 명령은 Index를 현재 HEAD가 가리키는 스냅샷으로 업데이트할 수 있는 것이다. 즉, 이 옵션은 Staging Area를 비울 수 있고 git commit, git add명령까지 되돌릴 수 있다.
   

3. 워킹 디렉토리 업데이트 (git reset --hard HEAD~)
   reset 명령은 세 번째로 워킹 디렉토리까지 업데이트한다. 앞서 mixed옵션에 더해 Working Directory까지 되돌리는 것이다. --hard옵션은 매우 신중하게 사용해야하는데 데이터가 삭제될 수 있는 명령어이기 때문이다.
   

정리하자면
1. HEAD가 가리키는 브랜치를 옮긴다. (--soft)

2. Index를 HEAD가 가리키는 상태로 만든다. (--mixed)

3. 워킹 디렉토리를 Index의 상태로 만든다. (--hard)

추가로 경로를 이용해 reset할 수 있다.

reset 명령을 실행할 때 경로를 지정하면 1단계를 건너뛰고 정해진 경로의 파일에만 나머지 reset 단계를 적용한다. HEAD는 포인터인데 경로에 따라 파일별로 기준이 되는 커밋을 부분적으로 적용하는 건 불가능하다. 하지만, Index나 워킹 디렉토리는 일부분만 갱신할 수 있다. 따라서 2, 3단계는 가능하다.

Checkout 명령과 Reset명령의 차이

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

2. reset 명령은 HEAD가 가리키는 브랜치를 움직이지만, checkout 명령은 HEAD 자체를 다른 브랜치로 옮긴다.

참고 : https://git-scm.com/book/en/v2

gitflow

Gitflow는 총 5가지의 브랜치를 사용해서 운영을 한다.

브랜치 설명

main(master) : 기준이 되는 브랜치로 제품을 배포하는 브랜치이다.
develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 merge한다.
feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 merge한다.
release : 배포를 위해 main 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치이다.
hotfix : main 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치이다.

쉽게 말해 main develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보면 된다.

gitflow 흐름

1. 일단 main 브랜치에서 시작을 한다.
2. 동일한 브랜치를 develop에도 생성을 한다. 개발자들은 보통 이 develop 브랜치에서 개발을 진행한다.
3. 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현한다.
4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합친다.(Merge)
5. 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만들고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스한다.
6. 모든 것이 완료되면 이제 release 브랜치를 main브랜치와 develop 브랜치로 보낸다. main 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포한다.
7. 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.

Fork, Pull requests

그러나 사이즈가 좀 더 큰 프로젝트를 하면 fork나 pull requests를 활용한다.
Fork는 브랜치와 비슷하지만 프로젝트를 통째로 외부로 복제해서 개발을 하는 방식인데 그렇게 개발을 해서 브랜치처럼 머지(Merge)를 바로 하는 것이 아니라 Pull requests로 원 프로젝트 관리자에서 머지 요청을 보내면 원 프로젝트 관리자가 Pull requests된 코드를 보고 적절하다 싶으면 그때 그 기능을 붙히는 식으로 개발을 한다.

사진 출처 및 참고 : https://ux.stories.pe.kr/183
https://git-scm.com/book/ko/v2