git은 두 명 이상의 사람이 동시에 버전 관리를 할 때에도 서로의 작업물에 의존하지 않고 내가 원할 때 코드를 올리고 수정하고 협업자의 코드와 합칠 수 있다. 즉, 병렬적으로 버전 관리를 할 수 있다.
그렇다면 어떤 원리로 작동할까? 우리는 커밋을 통해 코드의 변경사항을 하나로 덩어리로 묶을 수 있었다. 이러한 커밋들은 바로 전 커밋을 가리키며 시간순으로 쌓이게 된다.
혼자서 작업한다면 위의 그림처럼 한 줄로 계속 커밋이 쌓인다. 하지만, 협업을 통해 버전 관리를 한다면 한 줄로 커밋이 쌓일 수 없다. 커밋 3을 기준으로 두 명이서 각각 파일을 수정해 커밋을 한다고 가정하면 아래 그림과 같이 될 것이다.
이렇게 특정 기준에서 나누어 작업할 수 있는 기능을 브랜치(Branch)라고 한다. 만약 브랜치를 만들지 않고 둘 다 커밋을 하면 원격 저장소에 먼저 푸시한 커밋(커밋 4)은 정상적으로 올라가고, 뒤늦게 푸시한 다른 커밋(커밋 5)은 "너는 낡은 코드에 푸시를 하는 것이다. 최신 코드에 푸시하라"라는 오류가 난다.
git이 파일을 추적하고 스테이지에 올리는지 과정을 살펴본다. 먼저, 프로젝트 폴더에 git 초기화를 하고 README.md와 app.js를 생성한다고 가정하고 모두 한 번도 커밋되지 않은 상태이기 때문에 파일 상태는 추적 안됨(untracked)이다.
다음으로, add 명령어를 통해 두 파일 모두 스테이지에 올리면 파일 상태는 스테이지됨(staged)으로 바뀐다.
다음으로, commit 명령어를 통해 하나의 버전으로 만들면 파일 상태는 수정 없음(unmodified)으로 바뀐다. 수정 없음으로 된 파일은 다시 수정을 할 수 있다.
마지막으로, 다른 사람도 함께 협업 하기위해 push 명령어를 통해 원격 저장소에 업로드 하면 파일 상태는 그대로이다.
Git에서 관리하는 파일의 4가지 상태 (2)
위에서 했던 작업에서 더 많은 작업을 한다고 가정한다. app.js 파일을 수정해서 파일 상태를 수정 없음(unmodified)에서 수정함(modified)로 바꾸고 app.css 파일을 새로 만들어 준다. 새로 만들었기에 파일 상태는 추적 안됨(untracked) 상태이다.
변경사항이 없는 README.md 파일은 스테이지에 올릴 수 없지만 add 하지 않아도 이미 올라가 있는 상태이며 나머지 두 파일은 모두 스테이지에 올린다. 이 때, 두 파일 상태는 스테이지됨(staged)로 변경된다.
커밋을 통해 버전을 또 하나 생성한다. 이 때의 커밋은 앞서 만든 커밋인 "프로젝트 초기화"와 연결되어 있기 때문에 git은 쉽게 app.js가 수정되었고 app.css가 추가되었다는 것을 알 수 있다. 커밋을 했기 때문에 세 파일 모두 수정 없음(unmodified) 상태로 변하게 된다.
마지막으로, push 명령어를 통해 원격 저장소에 업로드 한다. 이 때, 파일 상태는 그대로이다.
정리
요약하자면 untraked(추적 없음), staged(스테이지됨), modified(수정함), unmodified(수정 없음), 총 4가지의 파일 상태가 존재하고 각각의 특징은 다음과 같다.
하지만 커밋 객체에 변경사항의 묶음이 저장되어있지 않다. 변경사항만 부분적으로 저장하는게 아니라 변경된 파일이 통째로 저장되어 있다. 바뀐 것만 저장하면 될 것 같은데 왜 용량을 더 차지하게 파일을 전부 저장할까?
Git이 등장하기 전에는 SVN(SubVersion)과 같은 버전 관리 시스템이 제일 많이 쓰였다. 이 둘의 가장 큰 차이점은 아래 그림과 같이 변경사항만 저장하는가이다.
단순하게 생각하면 전체를 저장하는 Git보다는 차이점만 저장하는 SubVersion 방식이 용량 면에서도 좋고 속도도 빠를 것 같지만 조금 더 생각해보면 SubVersion 같은 방식은 버전을 보여줄 때 파일이 만들었던 맨 처음부터 거슬러 올라가 바뀐 점을 모두 반영해야 한다는 불편함이 있다.
예를 들어, SubVersion에서는 README.txt 파일이 백 번 바뀌었다면 백 번의 계산을 모두 해야한다. 하지만 Git은 바로 앞에서 바뀐 커밋이랑 비교하는 연산 한번 만 하면 된다. 그리고 바뀌지 않은 파일은 링크만 저장하기 때문에 용량도 적고 계산하지 않아도 된다.
파일을 수정하고 소스트리를 확인해보면 다음과 같이 변하게 된다. 빨간색 부분을 자세히 보면
1. 아까와는 다르게 커밋하지 않은 변경사항이라는 텍스트가 보인다.
2. 스테이지에 올라가지 않은 파일 부분에 수정한 파일들의 목록을 확인할 수 있다.
이제 버전 관리를 위해 초록색 부분의 커밋 버튼을 누른다. 커밋을 누르면 첫 번째 사진과 같은 화면으로 바뀌게 되고 여기서 커밋을 하고자 하는 파일을 [+] 버튼을 이용해서 스테이지에 올리거나 [모두 스테이지에 올리기] 버튼을 이용해서 수정한 모든 파일을 스테이지에 올린다.
[커밋] 스테이지에 파일을 추가하기 전
[커밋] 스테이지에 파일을 추가한 후
수정한 파일을 스테이지에 올렸으면 이제 진짜 커밋을 생성해야 한다. 맨 아래에 커밋 메세지를 작성하고 커밋 작성 버튼을 누르면 커밋이 생성된다. 이것은 CLI 환경에서 git commit -m "index.js API 경로 추가"와 동일하다.
커밋 메세지 작성
커밋을 생성하면 다음과 같이 "커밋할 내용 없음"이라는 화면이 뜬다. 그리고 [히스토리]탭으로 가면 커밋 내역이 업데이트 된 것을 알 수 있다. 아직 원격 저장소에 올리는 Push 작업을 하지 않았으므로 로컬 저장소와 원격 저장소의 버전이 다른 것을 알 수 있다. 그리고 밑으로 가면 실제 커밋한 내용에 대한 정보를 확인할 수 있다. 그리고 맨 위 초록색 부분인 Push 버튼의 상태가 바뀐 것을 확인할 수 있다.
소스트리에서 커밋을 원격저장소 푸시(Push)
위에서 로컬 저장소의 버전과 원격 저장소의 버전이 다르다고 하였는데 자세히 살펴보면, 로컬 저장소 버전은 master라는 꼬리표가 붙어있고 원격 저장소 버전에는 origin/master라는 꼬리표가 붙어있다. origin은 연결한 github 원격 저장소의 별명이다.
예전에 git remote add origin github주소 라는 명령어를 수행했었다. 이것은 origin이라는 이름으로 해당 github 주소의 원격 저장소를 추가하라는 명령어이다. 만약, git remote add orange github 주소라고 입력했으면 origin 대신 orange라는 별명이 보였을 것이다. 정리하면 origin 꼬리표는 원격 저장소의 현재 버전 상태를 가리키는 커밋에 붙어있다고 할 수 있다.
master는 커밋을 올리는 줄기의 이름이다. [히스토리]탭으로 가면 커밋이 하나의 줄기로 이어져 있는 것을 볼 수 있다. 따로 줄기를 생성하지 않으면 git은 master라는 기본 줄기에 커밋을 올리게 된다.
종합해보면 맨 처음 master는 내 컴퓨터 로컬 저장소의 버전을 그 다음 origin/master는 github 원격 저장소의 버전을 가리키는 것이다. 따라서 위 사진에서는 내 컴퓨터의 로컬 저장소의 버전은 'index.js API 경로 추가'인데 원격 저장소의 버전은 하나 이전인 'index.js 경로 추가' 상태라는 것이다.
이제 새로 생성한 커밋을 초록색 부분의 Push 버튼을 눌러 원격 저장소에 업로드해보면 다음과 같은 화면이 뜬다.
위 화면에서 master에 해당하는 체크박스를 체크하고 Push 버튼을 누르면 업로드하는 과정이 나오게 되고 업로드가 완료된다. 이 동작은 git push origin master와 동일하다. [히스토리] 탭으로 가면 원격 저장소에도 최신 커밋 상태가 반영된 것을 확인 할 수 있다.
