git 1

 일단 git이란 분산되는 코드의 버전, 로그, 브랜치 등 개발과정에서 필요한 코드관리를 가능하게 해주는 유틸리티이다. 리눅스 커널 개발에 사용되던 유료유틸(이지만 스폰받아쓰던) 회사와 관계가 틀어지면서 리누즈씨가 빡쳐서 만들었다고 한다.

 git은 초기 설계목표대로 장점을 가진다. 설계목표는 거대한 프로젝트에 대해 빠르고 단순하며 비선형적인 개발이 가능한 완전분산형 버전관리시스템이며 이대로 제작되었고, 장점이 되었다.

 Tortoise SVN 을 사용해본 사람이 있다면 어렵지 않게 적응할 수 있고, Tortoise SVN보다 십만배는 좋은것 같다. 한가지 git은 윈도우에서 이용하기엔 조금 불편한 감이 있다는게 아쉬운점이다.

- git 설정

 git을 사용하기 앞서서 몇가지 설정을 해줘야 한다. (+ 유용한 설정들이 있다) 설정되는 내용의 시야는 현재 작업중인 저장소, 현재 작업중인 사용자, 모든 사용자 에 대한 설정을 다르게 할 수 있다. 동일한 항목에 대한 설정내용이 있다면 가장 앞(현재 작업중인 저장소 부터)의 내용이 반영된다. git은 config명령을 통해 여러 항목들의 설정기능을 제공한다.

* 사용자 정보 설정

$git config --global user.name "name"

$git config --global user.email "email"

 우선 사용자의 정보를 설정한다. 여기서 설정된 정보는 커밋할 때, 로그를 남길 때 사용되며 저장소 사용 전 꼭 해줘야 하는 일이다. (아래의 설정들은 필요에 따라서 선택사항)

* 컬러 설정

$git config --global color.ui auto

혹은 $git config --global color.ui true

 git 명령어로 출력되는 결과에 대해서 컬러를 적용한다. auto 혹은 true를 주는것 만으로 알아서 이쁘게 나와주고 세부적으로 컬러를 지정해주고 싶다면 man페이지를 살펴보면 자세하게 나와있다.

* 편집기 설정

$git config --global core.editor vim

 git에 사용되는 에디트페이지에 어떤 편집기를 사용할지 설정한다. 기본설정은 리눅스 기본편집기인것으로 알고있다.

 이렇게 설정한 내용들은 언제든지 바꿀 수 있고, config man페이지에서 더 자세한 설정에 대한 방법을 볼 수 있다 (지만 위에 세개만 하면 사용하는데 별 무리없다.)

- git 저장소 복사하기

 git을 사용한다면, 대부분 하나의 프로젝트에 많은 개발자가 동시작업을 해야하며 여기저기 동시다발적으로 난잡하게 일어나는 코드의 변경이력을 관리해야 할 필요가 있기 때문일 것이다.

 만약 누군가 먼저 생성한 프로젝트에 참여하려고 한다면 우선 그 저장소를 내 로컬상에 복사해와야 한다.

$git clone [url]

[url]은 코드와 변경이력이 저장된 서버이며 대체로 git://~~.~~.~~ 의 형태이다.

 이렇게 복사를 해오면 .git이라는 핵심적인 폴더 내에 버전별, 브랜치별 파일이 모드 다르게 관리되고 있는것을 볼 수 있다 (그러니 절대 지우면 안된다.) 단순히 $ls 의 명령에 나오는 목록은 앞에 '.'이 붙은 파일을 제외한 항목이된다.

- 새 저장소 생성

 누군가의 프로젝트에 참여할 수도 있지만, 내가 프로젝트의 창시자가 될 수도 있다. git 저장소에 관리되는 프로젝트는 누군가가 clone해가 공동작업을 하기 위한것일 수 도 있지만, 단순 솔플에도 탁월한 버전관리가 가능하다.

$mkdir [dirname]

$cd [dirname]

$git init

 위 세줄로 git저장소를 만들었다. init되는 디렉토리는 비어있는 상태가 좋으며(꼭 비어있어야 하는지는 모르겠다.) 이 후 추가되는 파일 삭제되는 파일 변경되는 파일  모두모두 git에서 관리대상이 된다.

- 커밋

 코드저장소를 사용하다보면 중요하고 자주쓰이는 개념으로 커밋이라는게 있다. 내가 변경한 파일에 대해서 저장소에 '이만큼 적용해줘' 라고 알려주는 동작이며 가장 빈번하게 접하게된다.

 커밋을 사용하기는 엄청 쉽다. 명령어 몇줄만 치면(심지어 길지도않은) 변경된 파일이 저장소에 반영이 된다. 하지만 제대로 커밋하기란 그리 쉬운일은 아니다.

 우선 커밋을 하는 이유는 내가 변경한 정보에 대해서 기록을 하는 목적을 가지고, 이 때의 상태로 복원하기 위한 백업의 목적을 가진다. 그렇기 때문에 커밋은 세부적으로 할 필요가 있고, 복원했을 때 최소한 컴파일 가능한 상태인 코드만 커밋할 필요가 있다. 물론 솔플이고 대충 복원용이다 라고 하면 단순히 그날그날 작업한거 몽땅 다 커밋할 수도 있다. 하지만 이렇게 될 경우 git의 많은 강점을 거의 사용하지 못한다.

$git add [filename]

$git commit

 커밋의 위의 두줄로 끝낼 수 있다. [filename]은 변경된 파일이며, add 할 경우 이를 워킹 디렉토리에 우선 반영하게 된다. 그 다음 commit을 하게되면 워킹디렉토리의 내용을 저장소에 반영하며 이 때 로그메세지를 남겨야한다.

 커밋로그는 커밋한 이력에 대해서 설명하는 내용이므로 최대한 상세하고 알아보기 쉽게 작성해주는게 중요하다. 로그작성 페이지의 처음줄은 로그의 제목이 되며 그 아래줄부터 작성되는 로그가 커밋로그의 내용이된다.

- 로그

 git의 커밋관리가 중요하듯 커밋과 함께일어나는 로그관리또한 중요하다. 개발만도 바빠죽겠는데 뭐이리 할게 많냐는 생각도 들지만, 이렇게 관리된 코드는 나중에 문서작성에도 사용되고 프로젝트 분할, 버그수정 등 엄청나게 다양한 이득을 볼 수 있다. (물론 난 아직까지 제목 + 10줄이내만 쓴다 ㅜ)

$git log

 저장소에 커밋된 로그는 위 명령으로 쉽게 볼 수 있다. 이렇게 할 경우 제목과 내용, 변경날자 등 모든 세부정보를 다 뿌리게되며 한눈에 보기 힘들다. git은 로그를 보는데 필터(제한?)를 주는 여러 옵션을 제공하고 잘 이용하면 훨씬 보기 편하다.

--oneline             제목만 조회

-(n)                    최근 n개의 커밋 조회

--since, --after    명시한 날짜 이후의 커밋 조회

--until, --before   명시하 날짜 이전의 커밋 조회

--author              입력한 저자의 커밋 조회

--committer          입력한 커미터의 커밋 조회

 사실 자주쓰는건 --oneline옵션이다. 또 HEAD(제일 최근 커밋의 태그) 를 이용한 상대위치로 접근도 가능하다.

일단은 사용가능한 정도로 소개하였고, 

- 브랜치

- 코드관리

- 리모트 저장소

에 대한 내용은 다음에 써야겠다.

배고파 쓰러지겠네...