수정하고 저장소에 저장하기 + 브랜치

참조 : https://git-scm.com/book/ko/v2, https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=zxy826&logNo=220488261345

 

이전 게시물 (2021.12.29 - [개발/풀스택 스터디 공부 정리] - Git - git 저장소 만들기)에서 git 저장소를 만들었고, 

working directory(작업자의 현재 시점->작업자의 작업 트리)에 checkout(작업자의 작업트리를 저장소의 특정 시점과 일치하도록 하는 작업)을 하였다.

 

 

이번 게시물에서는 파일을 수정하고, 스냅샷을 커밋할 것이다. 파일을 수정하다가 저장하고 싶으면 스냅샷을 커밋한다.

 

워킹 디렉토리의 모든 파일들은 tracked(관리대상o) / untracked(관리대상x)으로 나눈다.

- tracked 파일 : 이미 스냅샷에 포함되어 있던 파일 -> git이 알고 있는 파일

                      unmodified(수정x) / modified(수정o) / staged(커밋으로 저장소에 기록할) 상태 중 하나

- untracked 파일 : 나머지 파일

 

최초로 저장소를 clone하면 -> 모든 파일은 tracked이면서 unmodified상태이다. 파일을 checkout하고 나서 아무것도 수정x 때문이다.

마지막 커밋 이후 아무것도 수정x 상태에서 파일을 수정하면 -> git은 그 파일을 modified상태로 인식한다. 

실제로 커밋을 하기 위해서는 이 수정한 파일을 staged상태로 만들고, staged상태의 파일을 커밋한다.

=> 이러한 라이프사이클 계속 반복

파일의 라이프 사이클

 

· 파일 상태 확인

파일의 상태 확인하기 위해서는 git status 명령이다.

clone한 후 바로 이 명령을 실행하면 위의 메시지가 뜬다.

 

파일을 하나도 수정하지 않은 상태임을 나타내고 있다.

tracked 파일은 하나도 수정되지 않았다는 의미이다. untracked 파일은 아직 없어서 목록에 나타나지 않는다.

 

현재 작업 중인 브랜치를 알려주며, 서버의 같은 브랜치로부터 진행된 작업이 없는 것을 나타낸다.

기본 브랜치가 master이기 때문에 현재 브랜치 이름이 'master'로 나온다.

 

· 파일 추가

프로젝트에 README 파일을 만들기 위해 gitbash에 아래와 같은 명령어를 입력한다.

README 파일은 새로 만든 파일이기 때문에 status를 실행하면 위와 같은 문구가 출력된다.

- README 파일은 Untracked 상태라는 것을 나타내고 있다. git은 untracked 파일을 아직 스냅샷(커밋)에 넣어지지 않은 파일로 인식한다 (파일이 tracked 상태가 되기 전까지 git은 절대 그 파일을 커밋하지 않는다)

 

 

README 파일을 직접 tracked 상태로 만들기 위해

- git add 명령으로 README 파일을 추적한다. 

- git status 명령을 다시 실행하면 README 파일이 tracked 상태이면서 커밋에 추가될 staged 상태임(<-changes to be committed)을 확인할 수 있다. 커밋하면 git add를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다.

 

2) modified 상태의 파일을 stage 하기

- README 파일을 수정하고 다시 git status 명령을 실행하였다.

- README 파일은 tracked한 상태이지만 아직 staged가 안된 상태임(<-changes not staged for commit)을 확인할 수 있다.

-> staged 상태로 만들려면 git add 명령을 실행해야 한다

 ▷ git add : 파일을 새로 추적할 때 & 수정한 파일을 staged 상태로 만들 때 사용

     + merge할 때 충돌난 상태의 파일을 resolve할 때도 사용

 

git add 명령을 실행해 README파일을 staged 상태로 만들었다.

git status 명령으로 파일이 staged 상태임을 확인할 수 있다.

 

 

staged 상태가 된 파일을 커밋하기 위해 git commit을 실행한다.

이 때 'Aborting commit due to empty commit message' 라는 오류가 떴다.

vscode로 파일이 열려있어서 생긴 오류인 것으로 예상했다. 그래서 vscode를 종료하고 다시 -m 옵션을 사용하여 메시지를 첨부하였더니 커밋이 되었다.

 

관련 참고 자료 : https://docs.github.com/en/get-started/getting-started-with-git/associating-text-editors-with-git

Associating text editors with Git - GitHub Docs

 

커밋을 통해 확인할 수 있는 정보

-> master 브랜치에 커밋했고, 체크섬은 f8518ff 이다. 

그리고 수정한 파일은 1개이고, 추가된 라인은 1개이다.

 

· staging area 생략

위와 같이 git add 명령을 실행하여 파일이 staged 상태가 되게 한 후, git commit 명령을 통해 커밋을 해야 되는 과정이 귀찮을 수 있다.

git commit 명령을 실행할 때 -a 옵션을 추가하면 git은 tracked상태의 파일을 자동으로 staging area로 넣기 때문에,

git add 명령을 실행할 필요가 없다.

 

· 파일 삭제

git rm 명령으로 tracked 상태의 파일을 삭제한 후(staging area에서 삭제하는 것) 커밋하면 실제 파일을 제거할 수 있다. 

 

git 명령을 사용하지 않고 단순히 워킹 디렉토리에서 README 파일을 삭제하고 git status 명령으로 상태를 확인하면 아래와 같다.

Changes not staged for commit (->unstaged) 상태라고 표시를 하고 있다.

 

git rm 명령을 실행하면 삭제된 파일은 staged 상태가 된다.

 

git status로 상태를 확인해보면 아래와 같다.

  

앞으로 git은 이 파일을 더 추적하지 않는다.

---

· 브랜치 : 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이다. 모든 버전 관리 시스템이 지원한다.

 

· Git이 데이터를 저장하는 방법 : git은 데이터를 change set이나 변경사항(diff)으로 기록하지 않고, 일련의 스냅샷으로 기록한다. 
커밋하면 git은 커밋 개체(object)를 저장한다 (-> 현 staging area에 있는 데이터의 스냅샷에 대한 포인터 등) 

최초 커밋을 제외한 나머지 커밋은 이전 커밋 포인터가 적어도 하나씩 있고, 브랜치를 합친 merge커밋 같은 경우에는 이전 커밋 포인터가 여러 개 있다.

 

ex) 파일 3개 있는 디렉토리 하나가 있고, 이 파일을 staging area에 저장하고 커밋

 1) staging area에 저장

  파일을 stage하면 git 저장소에 파일을 저장하고(Blob), staging area에 해당 파일의 체크섬을 저장한다 (SHA-1 사용)

 2) 커밋

$ git add README LICENSE test.rb
$ git commit -m 'The initial commit of my project'

  git commit 으로 커밋 -> 루트 디렉토리와 각 하위 디렉토리의 트리 개체를 체크섬과 함께 저장소에 저장

  -> 커밋 개체 생성 (<- 메타데이터, 루트 디렉토리 트리 개체를 가리키는 포인터 정보 넣음)

 

Git 저장소에는 5개의 데이터 객체가 생긴다.

각 파일에 대한 Blob 3개, 파일과 디렉토리 구조가 들어 있는 트리 개체 1개, 커밋 개체 1개이다.

커밋&amp;amp;트리데이터(5개의 데이터 객체)

 

다시 파일을 수정하고 커밋하면 밑의 그림처럼 이전 커밋이 무엇인지도 함께 저장한다.

커밋&amp;amp;이전 커밋

=> 브랜치는 커밋과 커밋 사이를 이동할 수 있는 포인터 같은 것이라고 볼 수 있다.

기본적으로 git은 master 브랜치를 만든다. 처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다.

이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.

master 브랜치 &amp;amp; 커밋 히스토리 -&amp;gt; master 브랜치는 가장 최신 커밋을 가리킴

· 새 브랜치 생성

~/Documents/asdf1파일에 testing 브랜치를 만들었다.

새로 만든 브랜치도 마지막 커밋을 가리킨다.

git branch명령어는 브랜치를 새로 만들기만 하기 때문에, git은 아직 maser 브랜치를 가리키고 있다.

 

이를 확인하는 방법은 git의 HEAD포인터를 이용하면 된다. 이 포인터는 지금 작업하고 있는 로컬 브랜치를 가리킨다. 

git log 명령에 --decorate 옵션을 사용하면 브랜치가 어떤 커밋을 가리키는지 알 수 있다.

master 브랜치를 가리키고 있는 것을 확인할 수 있다.

 

· 브랜치 이동하기 

git checkout 명령으로 다른 브랜치로 이동할 수 있다.

testing 브랜치로 바꾸었다. 이렇게 하면 HEAD는 testing 브랜치를 가리킨다.

 

다시 git log 명령어를 이용하여 HEAD가 가리키는 브랜치를 확인하였다.

testing 브랜치로 변경된 것을 확인할 수 있다.

 

∴ git은 브랜치가 필요할 때 프로젝트를 전체 복사하지 않기 때문에, 복사하는 작업이 순식간이다. 

또한 커밋할 때마다 이전 커밋의 정보를 저장하기 때문에 merge할 때 어디서부터(merge base) 합쳐야 하는지 안다.

그렇기 때문에 개발자들이 수시로 브랜치를 만들어 사용한다.