티스토리 뷰

IT 일반

깃(Git) 시스템 구조 이해

야라바 2015. 8. 31. 22:53


분산 버전 관리 시스템(DVCS)인 깃(git)을 사용하는데 있어 시스템 구조를 이해하는 것은 매우 중요합니다. 전통적인 중앙 집중식의 VCS와는 시스템 구조 자체가 다르기 때문입니다.

개발자가 버전 관리시스템의 실체를 만날 수 있는 것은 일반적인 디렉토리 구조에서 파일이 존재하는 사용자 공간과 깃(git)이 관리하는 깃 공간, 그리고 외부의 원격 저장소로 나눌 수 있습니다. 윈도우 탐색기에서 확인해 보면 아래의 그림처럼 숨김폴더로 존재하는 .git 디렉토리와 통상적인 파일 디렉토리로 구분할 수 있고 다양한 깃 관리 정보는 깃 공간인 .git에 저장됩니다. 실제로 .git 디렉토리를 삭제해 버리면 깃 공간이 없어져서 더이상 파일 디렉토리는 깃의 관리 대상이 아닌 일반 파일로 남게 됩니다.


버전 관리 시스템의 관리 대상(Tracked)인가 비관리대상(Untracked) 인지는 매우 중요해서 버전 관리 폴더에 있다하더라도 아직 관리 대상으로 등록하지 않은 파일이라면 그 파일의 변경 기록도 추적할 수 없을 뿐더러 버전 관리 시스템에서 제공하는 다양한 기능도 사용할 수 없습니다. 깃이 파일을 바라보는 관점에서 파일의 상태 변화를 그림으로 나타내면 아래와 같습니다.


새롭게 저장소를 만들거나(init) 외부 저장소를 가져온(clone) 경우에는 관리대상의 원본(Unmodified) 상태가 됩니다. 사용자의 작업 영역(Working Area)에서 파일을 변경하면 버전 관리 시스템은 자동적으로 파일의 변경 여부를 인식하고 수정본(Modified) 상태로 추적합니다. 깃과 서브버전(Subversion)과 같은 중앙집중식 버전관리시스템의 명확한 차이를 보이는 상태가 바로 수정 후보로 관리하는 "Staged" 상태입니다. 서브버전이나 CVS와 같은 시스템에서는 "Staged" 상태 없이 Modified 상태에서 바로 커밋(commit)하지만 깃(Git)에서는 명시적으로 수정 후보임을 알려주어야(Stage) 합니다. 몰론 커밋을 수행하면 "Unmodified" 상태가 되는 것은 모든 도구가 마찬가지입니다.

"git init"로 새롭게 로컬 저장소를 만들었거나, "git clone"으로 원격 또는 외부 저장소로부터 복제를 통해 저장소를 생성한 다음에는 현재의 로컬 저장소를 또다른 저장소가 참조할 수 있는 원격 또는 외부 저장소로 사용할 수 있습니다. 내 PC에 깃허브등에 올려져 있는 프로젝트를 clone 해 놓고 네트워크를 통해 서비스할 수 있는 서버만 설치하면 다른 팀원들이 복제(clone)해서 사용 할 수 있는 깃의 서비스 서버 역할을 자연스럽게 할 수 있습니다. 아래의 그림은 깃허브의 프로젝트를 clone 했던 로컬 저장소를 외부 저장소로 하여 또다른 폴더에 복제(clone)하는 과정입니다.



아래의 그림은 원본 저장소로 깃허브를 바라보고 있는 OpenRA를 Git Gui>Remote>Fetch from>origin 메뉴로 가져오는 예제입니다. 원본 주소로 깃허브 웹주소를 확인할 수 있습니다.



아래의 그림은 원본 저장소로 로컬의 파일 저장소를 보고있는 OpenRA2를 Git Gui>Remote>Fetch from>origin 메뉴로 가져오는 예제입니다. 원본 주소로 로컬 폴더를 확인할 수 있습니다.


위와 같이 깃은 좀더 세밀한 파일 관리와 저장소의 자유로운 확장이라는 유익을 얻을 수 있습니다.


댓글
댓글쓰기 폼