Git 설치 및 전반적인 구성

 누군가에게는 꽤나 긴 포스팅 공백일지 모르겠지만, 이에 대한 답변이라고 한다면 그렇기도 하고 아니기도 하다. 중간에 친구의 추천으로 Git에 관련된 짧은 유료 강의를 결제해서 들었는데, 이를 정리하는 시간이 오래 걸렸고, 마음도 루즈해져서 길어진 감이 있다. 하지만 비공개로 포스팅을 계속했고, 공개를 할 수 없기에 포스팅 사이에 텀이 상당히 길어졌다. 약 한 달여 기간인 것을 고려했을 때, 그 강의에 대한 공부와 정리만을 이유로 할 수 없기는 하다.

 그래도 Git에 대한 정리는 따로 공개로 해보고 싶어서 국비 과정에서 잠시 다뤘던 Git에 대한 필기를 정리해두려고 한다. 물론 필기만을 정리하는 것은 아니다. 중간중간 생각나는 것들이나, 실험했던 것들을 덧붙여서 작성할 생각이다. 물론 두 번 일이 번거로워서 비밀글대로 두고, 수업 필기만 정리할 수도 있다.

 

설치 및 정보 얻기

Git은 공식 홈페이지에서 다운로드 할 수 있다. ^[각주:1]

 

slideshare 홈페이지에서 git을 검색하면 관련된 내용들을 공부할 수 있다. ^[각주:2]

 

버전관리

 Git은 버전 관리를 위해서 사용한다. 왜 버전 관리를 해야할까?

 Application(어플리케이션)을 만들고 난 뒤에도 수정할 일이 생긴다. 그리고 만드는 중에도 많은 작업을 하게된다. 때문에 효율적으로 관리하자는 취지에서 버전 관리를 하는 것이다.

 버전 관리에 대해 생각해보자. 버전 관리는 어떻게 할 수 있을까? 파일이 변경될 때마다 보존하려고 한다면 파일이 많이 늘어날 것이다. 더하여 파일이 하나가 아니라 여럿이라면, 또 작업하는 사람이 여럿이라면 더욱 정신 소멸에 가까워질 것이다. 이들을 모아 폴더로 관리를 하는 것 또한 좋은 방법이 아니다.

 이를 위해 존재하는 software가 바로 Git이다.

 

 이 버전 관리는 파일에 대한 수정을 기준으로 한다. 이에 대해서는 다음의 세 가지 내용을 알고 넘어가면 좋겠다.

1. 수정은 어떤 단계까지 기록해야 하는 것인지 의문이 든다. 수정의 단계는 "의미"를 기준으로 한다. 여기에서 의미란 "기능 추가", "문제 해결" 등의 특별한 의미를 가지는 수정사항을 말한다. 이를 기준으로 commit을 하게 되는데, 이 기준은 사용자가 정하는 것이다. 단위가 작을수록 정밀하다.
2. 하나의 commit에는 여러 개의 파일이 존재할 수도 있다. 하나의 기능을 위해 여러 파일이 영향을 줄 경우 그렇다.
3. 수정하지 않고 새로운 실험을 하고 싶다면 그 실험을 저장하는 공간을 만들어서 작업한다.. 여기에서 실험이란 파일, 파일의 내용, commit 정보 등의 모든 변동사항을 말한다. 이런 실험의 공간을 branch라고 한다.

 

 

Git의 전반적인 구성

 Git은 크게 총 3가지의 작업 환경으로 나누어져 있다. 첫 번째는 프로젝트의 파일들을 수정하고 작업하고 있는 working directory, 두 번째는 어느정도 작업하다가 버전 history에 저장할 준비가 되어있는 파일들을 옮겨놓은 staging area, 세 번째는 버전의 history를 가지고 있는 Git repository(또는 Git directory)로 나눠져 있다.

 그 중에서도 첫 번째 working directory는 다시 untracked와 tracked 두 가지로 나눌 수 있다. Git이 이미 알고 있어서 tracking하고 있는 파일이라면 tracked 카테고리로, 새로 만들어진 파일이거나 기존에 존재하던 프로젝트의 Git을 초기화하게 되면 Git이 파일에 대한 정보가 전혀 없기 때문에 tracking 되지 않는 파일들을 untracked 카테고리로 분류된다. 그리고 tracked 카테고리로 분류된 파일들도 현시점의 수정 유무에 따라 수정되지 않았다면 unmodified, 수정되었다면 modified로 세분화된다. 이전 버전과 비교했을 때, 수정된 modified 카테고리의 파일들만 staging area로 옮겨갈 수 있다.

 

 예를 들어 프로젝트 폴더에서 파일들을 수정하고 있다가 a와 b파일은 어느 정도 준비가 되었다고 결심하게 되면 staging area로 a와 b파일을 옮기고, commit 명령어를 이용해서 이 파일들을 Git 버전 history에 저장하게 된다. c도 수정하다가 준비가 되면 같은 과정을 수행한다. 이렇게 Git directory에 저장된 버전들은 checkout 명령어를 이용해서 언제든지 원하는 버전으로 다시 돌아갈 수 있다. 이렇게 저장된 history는 작업자의 컴퓨터에만 보관되기 때문에 컴퓨터 자체에 문제가 생기면 이 history를 모두 잃어버릴 수 있는 문제가 있다. 그래서 Git directory를 작업자의 pc에만 저장해두는 것이 아니라 Github와 같은 server에 push 명령어를 이용해서 작업자의 Git directory를 server에 업로드 해둘 수 있다. 그리고 서버에서 로컬로 다운로드 받을 때에는 pull 명령어를 사용한다.

 

 각 commit에는 스냅샷된 정보들을 기반으로 고유한 hash code가 부과되는데, 이 친구들을 이용해서 버전 정보를 참조할 수 있다. 또한 commit에는 아이디 뿐만 아니라 버전과 관련된 메시지와 작성자, 날짜와 시간같은 정보들도 포함되어 있다.

1. Git (git-scm.com) [본문으로]
2. 'git' on SlideShare [본문으로]