WhaTap Tech Blog - 와탭 기술 블로그

Git은 소스코드를 저장하는 저장소이면서 파일의 수정내용을 관리해주는 버전관리 시스템(VCS:Version Control System) 중 하나입니다. 버전관리 시스템을 사용하면 동일한 정보에 대한 여러 버전을 관리하게 되며, 시간에 따라 수정내용을 비교해 볼 수 있고, 누가 언제를 문제를 일으켰는지도 추적할 수 있으며, 누가 언제 만들어낸 이슈인지도 알 수 있습니다. 각 버전별로 관리가 가능하기 때문에 엄청난 실수를 했다 하더라도 언제든지 복구가 가능하며 백업용으로도 아주 유용하게 쓰입니다. 지금부터필수적인 형상관리요소의 하나라고 할 수 있는 버전관리 시스템 Git을 사용하는 방법에 대해 알아 봅시다.

[버전관리 시스템의 종류]

먼저 기본적인 버전관리 시스템의 종류에 대해 간단히 설명해 드릴게요.

로컬 버전관리시스템(LVCS:Local VCS) : 간단한 데이터베이스를 사용하여 파일의 변경 정보를 관리. 혼자 프로젝트를 진행할 경우 많이 사용한다. ex-rcs 등
중앙집중식 버전관리시스템(CVCS:Centralized VCS) : 프로젝트를 다른 개발자와 함께 작업해야 하는 경우 사용하는 방법으로 파일관리 서버가 별도로 있고, 클라이언트가 중앙서버에 파일을 받아 사용한다. 중앙서버에 의존적이다. ex-CVS, Sebversion, Perforce 등
분산 버전관리시스템(DVCS:Distributed VCS) : 클라이언트가 저장소를 전부 복제하여 복제물을 사용. 복제된 소스는 로컬 데이터베이스로 관리한다. ex-Git, Mercurial, Bazzar, Darcs 등

여기서 VCVS와 DVCS의 큰 차이점은, 개발자가 코드의 변경사항을 중앙서버에 바로 적용하느냐 안하느냐의 차이 인데요. CVCS의 경우 코드의 변경은 바로 중앙서버에 적용이 되나, DVCS는 저장소를 로컬 컴퓨터에 복사 한후 복사된 프로젝트를 가지고 작업하기 때문에 중앙서버로 수정된 코드가 바로 반영되지 않습니다. 클라이언트가 원하는 경우에만 서버에 업로드 할 수 있지요. 따라서 Git과 같은 DVCS는 오프라인에서 프로젝트의 복제물로 작업이 가능하기 때문에 중앙서버에 문제가 생겨 모든 자료를 잃어 버리거나 복구할 방법이 없었던 CVCS의 한계를 극복하였습니다.

참고>>

버전관리에 대한 자세한 설명 보기

[Git이란?]

본격적으로 Git에 대해 알아봅시다. Git은 소스 코드 관리를 위한 분산 버전관리 시스템으로 2005년에 Linux Torvalds가 리눅스 커널 개발에 이용하기 위하여 개발하였습니다. 빠른속도/단순한 구조/비선형적인개발/완벽한 분산/대형 프로젝트에 유용 이라는 목표를 가지고 있습니다. Git은 저장소(Repository)를 전부 복제한 복제물을 사용하기 때문에 로컬파일에 대하여 변경이 이루어지며 따라서 네트워크속도에 영향을 받지 않습니다. 히스토리를 조회하거나 변경사항을 확인할때 리모트에 있는 서버에 접근 할 필요가 없기 때문에 그 속도는 매우 빠르답니다.

참고>>

Git참고 페이지 보기 (Git을 처음 접한다면 도움이 될만한 사이트 입니다)

[Git설치하기]

Git을 사용하려면 먼저 설치부터 시작해야 겠지요?

Windows : http://msysgit.github.com/
CentOS / RedHat : $ yum install git-core
Ubuntu / Debian : $ apt-get install git

참고>>

Git설치하는 방법에 대한 상세안내

[Git사용자 정보 설정]

Git을 설치하고 나서 가장 먼저 해야 하는것은 사용자 이름과 이메일 주소를 설정하는 것입니다. git config [options] 명령어를 사용하여 사용자정보를 설정할 수 있습니다.

$ git config --global user.name "jhkim"
$ git config --global user.email jhkim@whatap.io

위와 같이 이름과 이메일 주소를 적용하고 git설정 목록을 확인 해 봅시다.

$ git config --list
user.name=jhkim
user.email=jhkim@whatap.io
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

[Git명령어 정리]

자, 지금부터 Git을 사용하여 버전관리를 시작해볼까요~?

이제부터는 실무에 Git을 활용 할 수 있는 각 명령어에 대해 알아봅시다. (해당 내용은 http://git-scm.com/book/ko/v2/을 일부 참조 하였습니다.)

참고>>

먼저 Git은 3가지 상태를 가지고 있습니다. 실무에 활용하기전 Git의 상태를 먼저 알아 두셔야 해요.

Commited : 데이터가 로컬 데이터베이스에 안전하게 저장되었다.
Modified : 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않았다.
Staged : 현재 수정한 파일들 중 commit으로 저장소에 기록 할 목록이다.

git clone <원격 저장소 주소> <복제될 디렉토리>

원격 저장소로부터 소스를 복제합니다. clone으로 복제를 실행하면 원격저장소에 대하여 origin이란 이름으로 자동 생성됩니다. 이때 생성되는 기본 브랜치명은 master입니다.

git status

현재 작업중인 브랜치 명과 복제된 파일들의 상태를 확인 할 수 있습니다.

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    modified:   benchmarks.rb

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    text.txt

nothing added to commit but untracked files present (use "git add" to track)

Changes to be committe(staged상태): 관리대상 목록이다. commit할 수 있다.
Changes not staged for commit(unstaged상태): 워킹디렉토리. 파일을 수정만 한 상태로 관리대상 목록이 아니다. commit되지 않는다.
Untracked files: 관리대상이 아닌 파일. 절대 commit할 수 없다. 처음 파일을 생성하는 경우 untracked상태에 속한다.

참고>>

unstaged상태의 파일을 commit하려면 staged상태로 만들어 주어야 하는데요. 이 때에는 파일을 추가해 주는 git add 작업이 필요합니다. 이 부분은 다음에서 자세히 살펴보도록 할게요. 반대로 staged상태의 파일을 unstaged상태로 만들어 주려면 어떻게 해야 할까요? git reset HEAD [파일명 또는 디렉토리] 명령어를 사용 해 보세요.

git add [파일명 또는 디렉토리]

관리대상이 아닌파일을 관리 대상 파일로 지정합니다. 파일을 변경 하는 경우 stage상태로 만들어 주기 위해 사용합니다. 파일을 새로 생성/삭제/이름수정을 하면 커밋을 할수 있는 상태. 즉, 파일을 git으로 추적하기 위한 첫 단계라고 할 수 있습니다.

참고>>

여기서 주의 할 점! 만약 staged상태의 파일을 수정하는 경우 수정내용을 반영하려면 수정 후 반드시꼭 add를 다시 해 주어야 합니다. add를 하지 않으면 staged상태 이후에 수정된 내용이 coomit시에 반영되지 않아요. 꼭 주의하세요.

git diff [파일명 또는 디렉토리]

unstaged상태 파일(워킹디렉토리)을 로컬 저장소에 이미 커밋되어진 마지막 파일과 비교하여 변경내용을 확인하는 경우 사용합니다. 파일들이 모두 staged상태에 있다면 git diff명령어는 아무것도 출력하지 않습니다.

참고>>

staged상태 파일의 변경사항을 확인하고 싶다면 --cached 옵션을 붙여 줍니다.

$ git diff --cached stated-file.txt

git commit [파일명 또는 디렉토리]

staged상태에 있는 수정한 파일을 로컬 데이터베이스에 저장하기 위해 사용합니다.

참고>>

자주사용하는 옵션들
-m : commit한 간략한 내용의 메세지를 남길 수 있다.
$ git commit -m "ex) fixed bug.. issue 117" stated-file.txt

-a : unstaged상태 파일들을 staged상태로 바꾸지 않고도 commit할수 있다. git add작업을 하지 않아도 됨.
$ git commit -a "ex) fixed bug.. issue 117" unstated-file.txt

-amend : 로컬 데이터베이스에 한해서만 커밋한 내용을 수정하여 다시 커밋하고 싶은 경우에 사용한다. 이때 두번째 커밋은 첫번째 커밋을 덮어쓴다. 예를들어 실수로 파일이 빠진 경우 2번 커밋할것을 1개의 커밋으로 만들 수 있음. 단, 원격저장소에 커밋 하였다면 해당 옵션은 적용되지 않음.
$ git commit "ex) fixed bug.. issue 117" file1.txt file3.txt
$ git commit --amend "ex) fixed bug.. issue 117" file2.txt

git rm [파일명 또는 디렉토리]

git에서 파일을 삭제 합니다. 삭제한 파일을 꾸준히 관리하려면 이 또한 staged상태로 만들어 준 후에 commit하여야 합니다. 따라서 삭제 후 git add는 필수입니다.

참고>>

git rm명령어를 바로 사용하면 git뿐만아닌 워킹 디렉토리에서도 삭제됩니다. 워킹 디렉토리에 있는 파일을 지우지 않고 남겨두고 싶다면 -cached 옵션을 사용합니다.

$ git rm --cached working-dir-file.txt

git log [파일명 또는 디렉토리]

git으로 관리하고 있는 파일들의 히스토리를 확인 할 수 있습니다. 누가, 언제, 어떤 파일을, 파일의 어느 부분을 변경하였는지에 대한 모든 내역을 조회할 수 있습니다. 다양한 옵션들을 적절하게 이용하면 히스토리를 한눈에 확인하기 쉽습니다.

참고>>

자주사용하는 옵션
-p : 각 커밋의 diff결과를 보여준다. 
$ git log -p

-n(number) : 최근 n개의 커밋 내역을 보여준다.
$ git log -2

--pretty : 기본으로 보여주는 형식을 바꿀 수 있다. 
$ git log --pretty=oneline
$ git log --pretty=short
$ git log --pretty=full
$ git log --pretty=format:"%h - %an, %ar : %s"

--graph : 브랜치와 머지 히스토리정보를 그래프로 보여준다.
$ git log --graph

--since/after : 지정날짜 이후에 커밋된 내역만을 보여준다.
$ git log --since=2.weeks

--until/before : 지정날짜 이전에 커밋된 내역만을 보여준다.
$ git log --before="2015-10-01"

--author : 커밋한사람을 지정하여 내역을 볼 수 있다.

git checkout [파일명 또는 디렉토리]

수정한 파일을 원상복구 하고 싶을때, 수정한 파일을 로컬 저장소에서 마지막으로 커밋된 버전으로 되돌리고 싶을 때 사용합니다. 수정한 내용은 전부 사라지게 되니 조심하세요.

참고>>

다음 2탄에 나올 내용이지만 다른 브랜치를 이동할때에도 동일한 명령어를 사용합니다. 기억해 두세요.

마치며

파일의 수정한 내용을 기록 해 두고 싶은 경우, 파일의 변화를 시간에 따라 기록했다가 특정 시점의 버전을 다시 확인하고 싶은 경우 등에 버전관리 시스템을 사용하고 그 중 하나가 Git입니다. 여러명이 동시에 작업하는 프로젝트라면 소스코드의 변경으로 인하여 모든 개발자들의 작업에 영향을 미치게 되는데 이런 문제들을 Git으로 해결 할 수 있습니다.

지금까지, Git을 실무에 활용하기 1탄에서는 Git을 처음 사용할 때 간단히 실무에 적용하여 활용할 수 있는 명령어들에 대해 알아 보았는데요. 많은 내용을 다루지 못해 아쉽지만 2탄에서는 좀 더 깊이 있는 내용을 다루어 보도록 하겠습니다. 다음에는 다른사람들과 협업시 꼭 필요한 원격저장소와 브랜치의 개념, 충돌시 대처할 수 있는 머지기능에 대하여 자세히 알아 볼거에요. 2탄을 기대해 주세요~~^^!