Git, 분산식 버젼관리시스템(DVCS)

IT Xcite/개발 환경 2013.02.04 19:08

 

 

  Git 에 익숙해지기..

  회사에서 인턴하는 동안 회사에서 기존에 사용하던 SVN을 버리고 Git으로 넘어갔다. 이렇게밖에 할 수 없었던 가장 큰 이유는, Atlassian에서 제공하는 이슈 트래커인 JIRA에서 작년말부터 SVN과의 연동을 중단하겠다고 선언하였기 때문이다. SVN을 버리고 Git을 밀어준다는 Atlassian의 발표에 우리 회사도 이 추세를 따라가기로 했다.

  그럼, 이제부터 간략하게 Git에 대해 알아보도록 하자. 다음 자료는 젤코에서 인턴으로 일하면서 Mac Microsoft Powerpoint로 본인이 직접 작업한 내용이다.

  본 글은 슬라이드를 중심으로 보기 바라며, Atlassian에서 제공한 SVN -> Git에 관한 내용도 참고하면 좋다.

 


 가장 먼저, 버젼 관리 시스템에 대해 모르는 사람들을 위해 다음 그림의 생활코딩 블로그 링크(http://115.28.24.88/course/303/2283)를 추천한다. 강의 중 처음 강의만 들으면 버젼관리가 어떤것인지, 감이 바로 올 것이다. 


  간단히 설명하자면, 학교 보고서 작성하다가 내가 두 번째 문단이 필요없다 느껴서 지웠다가 후회한 경험.. 모두 한번씩은 있을 것이다. 이 때, 버젼관리시스템을 이용하면, 당신이 이전에 어떤 문단과 문장과 단어를 지웠는지, 나란히 비교가 가능하며 각 버젼별로 관리가 가능하기 때문에, 설령 엄청난 실수를 했다 하더라도 언제든지 복구가 가능하며, 백업용으로도 아주 유용하다.


  다음 슬라이드는 두 가지 종류의 버젼관리시스템을 보여준다.

 1. CVCS - ex) 중앙 서버에 있는 코드를 A와 B가 변경하면 곧바로 서버에 올라가여 적용됨.

 2. DVCS - ex) 중앙 서버에 있는 코드를 개발자 각자의 로컬 컴퓨터에 복사한 후, 복사된 프로젝트를 가지고 작업하고 서버에 업로드한다.

  즉, 본 글에서 소개하는 DVCS의 방법은 오프라인에서의 작업이 가능하다는 장점뿐만 아니라, branching을 통하여 효과적인 버젼관리가 가능한 반면, 처음 보는 이에게는 너무 복잡하게 느껴질 수 있기 때문에 적응하는 데에 다소 시간이 걸릴 수 있다.


  Git의 작업 흐름을 이해하기 위한 용어 정리가 필요하다. 먼저, 프로젝트 및 그 안에 담긴 코드가 저장되는 곳이 'Repository', 그리고 서버의 'repository'와 로컬 내 컴퓨터의 'repository'는 다르다는 점을 잊지 말자.


  다음으로는 'master'에 관해, 로컬에서는 두 개의 master가 각각 존재한다는 점만 일단 짚고 넘어가도록 한다.


  자, 이제 본격적인 커밋 프로세스를 살펴보자.

서버에 작업하던 프로젝트를 올리거나, 새로 생성하여 업로드한다. 로컬에는 아무것도 없다.


- ‘tracking branch’ : 어디까지 작업했는지 알려주는 branch
- 로컬에서 ‘origin/master’remote-tracking branch로서, 가장 최근에 서버와 sync.할 당시, 서버의 master의 상태와 같다. 따라서 ‘origin/master’는 로컬에서 읽기(read-only)만 가능하다.

- 로컬에서의 다른 ‘master’tracking branch로서, ‘master’는 유저가 자신의 로컬 환경에서 개발 작업을 할 때 사용되는 branch이다


 - 파일이 수정되거나 새 파일을 추가할 때 버젼 관리를 위해 commit을 한다

 - ‘origin/master’는 여전히 c2를 가리키며, central repo.에도 변화가 없다.


  'commit'을 하는 것은 위의 두 단계를 거쳐 일어난다.

(1) 서버에 변경된 사항이 업데이트된다.

(2) 로컬의 origin/master(서버와 가장 최근에 sync.했을 때, central repo.의 master상태)가 서버의 것으로 업데이트 된다.


  다른 유저도 2, 3의 과정으로 자신의 commit을 업로드한다.(충돌은 없다고 가정.) 


  어떤 일을 하기 이전에, 또는 자신의 commit을 업로드하기 전에 가장 먼저 변경된 사항을 가져온다. 


  변경된 사항을 자신이 작업한 코드와 합친다. 이 때 변경된 사항과 자신이 변경한 코드가 같은 부분일 경우 충돌이 일어날 수 있다. 


 5, 6 과정 대신에 한번에 pull을 이용할 수 있다. 하지만 작업하는 도중에 pull을 이용할 경우, 작업이 손상될 수 있으므로, 가급적 fetch와 merge를 분리해서 진행하는 것을 추천한다.

  이것으로 두 명 간의 commit 프로세스가 완료되었다. 이제 간단히 Git의 작업 흐름을 다시 정리해보자.

 

  Github 문서를 참고하면, working directory에서 코드를 수정 후, commit을 하기 위해 반드시 stage로 올린 후, commit을 하는 과정을 지금까지 살펴보았다. 


  즉, untracked의 파일을 track하면 비로소 Git을 이용하여 파일에 대한 버젼관리가 가능해진다. 또, unmodified된 파일을 변경하면 modified, 이를 commit하기 위해 stage하고 나면 다시 unmodified 상태가 되는 것이 파일의 흐름이다. 


- Checkout vs Branch

  둘 다 branch를 생성하지만, checkout은 branch 생성 후에 작업할 공간이 생성된 branch로 넘어가며, branch는 새 branch 생성 후에 현재 branch에 머문다.

- Fetch vs Pull

  Fetch는 단순히 central repo.에서 변경된 사항을 가져오기 때문에 작업의 손상이 없지만, pull은 fetch + merge를 하므로, 작업이 손상될 여지가 있다.

- Clone vs Fork

  Central repo.를 clone했을 때, 로컬에서 변경된 코드를 서버에 올릴 수 있지만, fork는 repository를 단순히 복사만 할 수 있고, 서버에 write할 수 있는 권한은 없다.

-  Rebase vs Merge

1) Merge : 예를 들어, develop branch에서 뻗어나온 feature branch로 새로운 기능을 구현했다고 하자. 구현이 완료된 후에, develop branch에서 이 기능을 추가할 때 merge를 하면 feature branch에서의 수정사항이 develop branch에도 적용된다. 즉, merge는 한번의 commit으로 하나의 branch에서 다른 branch으로 수정사항이 적용된다.

2) Rebase : 예를 들어, 나의 코드와 무관한 부분을 다른 개발자가 작업했다고 하자. 여기서 그 개발자가 작업한 내역을 그대로 나의 코드에 덮어쓰고 싶을 때 rebase를 사용한 후에 merge를 한다. 즉, rebase를 이용하면, 특정 branch B에 내 작업 branch A가 통합될 때, 어떤 결과가 나오는지 알 수 있으며, 통합된 결과가 적용되기 위해서는 merge 를 이용한다.

  위는 Atlassian에서 제시한 Git workflow의 예이며, 다음 슬라이드의 용어를 통해, 작업흐름을 추측해 볼 수 있다.

 

- Master :  프로젝트의 흐름으로, 공식적인 release를 가지는 branch

- Develop : 다른 feature들을 통합한 branch로, 실제 feature branch들이 이 branch로 merge된다.

- Feature : 각각의 분화된 기능을 담당하며, 절대 master branch와 연결 되어서는 안된다.

- Release : 제품 release를 위한 branch로, 이 branch 생성 후에는 새로운 feature를 추가할 수 없다. 새 feature는 다음 release를 준비하는 branch에 추가한다. Release 준비가 완료되면, master와 develop으로 각각 merge한다.

- Hotfix : 유지/보수와 같은 특정 목적을 위한 branch로, 주로 제품에 대한 패치를 신속하게 처리하기 위해 사용되며, 패치 완료 후 master와 현 release로 각각 merge한다.


- 출처 -


'IT Xcite > 개발 환경' 카테고리의 다른 글

JIRA - Admin.계정편  (0) 2013.02.22
번역 :: 'Release Cycle Workflow'  (0) 2013.02.04
번역 :: 'Feature Branch Workflow'  (0) 2013.02.04
번역 :: 'The Git Subversion Workflow'  (0) 2013.02.04
Git, 분산식 버젼관리시스템(DVCS)  (0) 2013.02.04

설정

트랙백

댓글