[git] 깃 (기본)

1) 시작하기

 

소스코드 파일의 버전 백업

코드작성을 하다가 망하게 되면 우린 어찌하는가? 가장 단순하고 확실한 방법은 수정을 시작하기 전에 소스코드 파일들을 따로 백업해 두는 것이다. 수정하다 망해버린 파일들을 삭제하고, 백업해둔 파일을 다시 꺼내면 간단하게 수정 전 상태로 되돌아 갈 수 있다. 그런데 이 방법의 문제는, 소스코드 파일을 편집할 때마다 매번 백업하는 일이 번거롭다는 점이다. 그래서 가끔 백업을 깜빡했다가 낭패를 보곤 한다. 또 백업이 너무 많아지면, 백업의 구체적인 내용이 기억나지 않아서 혼란스럽기도 하다.

프로젝트 공동 작업

친구들이랑 같이 프로젝트를 할 때, 내가 애써서 구현한 코드를 다른 팀원이 실수로 망쳐버린 경우.. 팀원들이 각자 구현한 버전들을 전부 취합할 때 어려움..

 

버전 관리 시스템

위와 같은 문제들을 해결하기 위해 만들어진 것이 git과 같은 버전 관리 시스템이다. git에서는 소스 코드가 변경된 이력을 쉽게 확인할 수 있고 특정 시점에 저장된 버전과 비교하거나 특정 시점의 버전으로 되돌아갈 수도 있다. 또, 내가 팀 공동 저장소에 올리려는 파일이 팀원 누군가 편집한 내용과 충돌한다면, 공동 Repository에 올릴 때 경고 메시지가 발생하고 업로드는 취소된다. 그래서 누군가 애써 편집한 내용을 날려버리는 실수를 이제 걱정하지 않아도 된다.

 

 

 

2) git repository

git repository에는 소스코드 파일의 수정 과정에서 만들어졌던 전체 버전들이 전부 저장된다.

 

remote repository와 local repository

git repository는 local repository와 remote repository가 있다.

 

remote repository

팀원들이 공유하기 위한 repository다. 팀원들 모두 접근할 수 있는 remote 서버에 만들어진다.

무료로 이용할 수 있는 대표적인 git remote repository 서버는 github 이다.

 

local repository

개발자 개인의 PC에 생성되는 개인 전용 repository이다. 평소에는 팀원 각자 개인 PC의 local repository에 버전을 저장하며 작업하다가 그 동한 작업한 내용을 팀원들에게 공개하고 싶을 때 local repository에 저장된 내용을 remote repository에 업로드 한다. 누군가 remote repository에 작업한 내용을 업로드하면, 다른 팀원들은 그 내용을 각자의 개인 PC의 local repository에 다운로드할 수 있다.

 

local repository 만들기

개인 PC에 local repository를 만드는 방법은 두 가지가 있다.

(1) 비어있는 local repository를 새로 만든다

(2) 이미 만들어져 있는 remote repository를 다운로드해서 local repository를 새로 만든다.

 

 

 

3) 변경을 기록하는 commit

local repository에 새 버전을 등록하는 작업을 commit이라고 한다. commit을 할 때에만 local repository에 버전이 등록된다. 어느정도 의미있는 소스 코드 수정 작업을 마쳤을 때마다, 그 작업을 마친 버전을 local repository에 commit하는 것이 바람직하다.

 

예를 들어, 어떤 기능 구현을 완료했다거나, 어떤 버그를 해결했다면 그 작업 결과 버전을 local repository에 commit하자. commit은 소스코드 변경 이력을 저장소에 기록하는 중요한 작업이다.

 

안좋은 예시로는, 물 한잔 마시기 전에 커밋! 퇴근 전 커밋! 밥 먹기 전 커밋! 이런 건 안된다.

 

commit 메시지

local repository에 commit을 등록할 때, commit 메시지를 필수로 입력해야 한다. 작업 내용을 commit 메시지에 요약해서 입력하자. 작업 내용을 팀원들이 쉽게 이해할 수 있도록 입력해야 한다.

 

commit 메시지가 여러 줄인 경우에는 다음과 같은 형식을 따르자.

첫째 줄에 commit 메시지 제목을 적고

둘째 줄은 비워두고

셋째 줄부터 commit 메시지 분몬을 적는다.

 

commit hash

각 commit에는 알파벳과 숫자로 이루어진 40자리의 hash가 자동으로 부여된다.

commit hash는 그 commit을 식별하기 위한 기본키(primary key)에 해당한다.

 

 

 

4) working tree와 staging area

git 버전 관리 대상인 소스코드 폴더를 working tree라고 부른다. (working directory)

commit을 실행하기 전 local repository와 working tree 사이에 staging area 라고 불리는 가상의 공간이 있다. git의 commit 작업은 working tree에 있는 변경 내용을 전부 repository에 바로 기록하는 것이 아니라 staging area에 등록된 파일들의 변경 내용만 repository에 기록한다.

따라서 어떤 파일의 변경 사항을 repository에 기록하기 위해서는, commit하기 전에 먼저 그 파일을 staging area에 등록해야 한다. staging area에 등록된 파일만 다음 번 commit에서 기록된다.

 

예를 들어, 10개의 파일을 수정했지만 그 중에 7개 파일의 변경 사항만 repository에 기록하고 싶다면 그 7개 파일을 staging area에 등록한 후 commit 해야 한다. 이렇게 staging area에 등록된 파일의 변경 사항만 repopsitory에 기록되기 때문에,

working tree에 있는 파일들 중 내가 원하는 변경 사항만 repository에 commit할 수 있다.

 

working tree 스냅샷(snapshot)

commit을 하면, working tree의 현재 상태가 local repository에 기록된다.

그래서 나중에 그 스냅샷 상태로 working tree를 되돌리는 것이 가능하다.

단 staing area에 등록된 파일들만 local repository에 기록된다.

 

 

 

5) working tree 내부의 파일의 상태

working tree 내부의 파일의 상태는 다음 상태 중 하나이다.

 

untracked

한 번도 commit 되지 않았고, 아직 staging area에 등록되지도 않은 새 파일의 상태는 untracked 이다.

 

modified

변경 내용이 commit된 이후 수정되었지만, staging area에 다시 등록되지 않아서,

다음 commit 대상이 아닌 파일의 상태는 dirty / modifed 이다.

 

staged

(1) 아직 한 번도 commit되지 않은 새 파일이고, 처음으로 commit되기 위해,

staging area에 등록된 파일의 상태는 staged 이다. (untracked => staged) new file

 

(2) 변경 내용이 commit된 이후 수정되었고, 그 수정 내용이 다시 commit 되기 위해,

staging area에 등록된 파일의 상태는 staged 이다. (modified => staged)

 

unmodified

변경 내용이 commit된 이후로 수정되지 않은 파일들의 상태는 unmodifed 이다.

 

 

 

6) working tree 내부의 파일의 상태 변화

 

상태 변화

working tree에 새 파일을 생성하면 그 파일은 untracked 상태이다.

untracked 파일을 staging area에 등록하면 staged 상태가 된다.

staged 파일을 commit 하면 unmodified 상태가 된다.

unmodified 파일을 수정하면 modified 상태가 된다.

modified 파일을 staing area에 등록하면 staged 상태가 된다.

staged 파일을 commit 하면 unmodified 상태가 된다.

 

staing area 등록 대상 파일

untracked 파일

modified 파일