GIT Centralized Workflow 설명

Centralized Workflow

 분산 버전 컨트롤 시스템으로의 전환은 어려운 작업처럼 보이지만, 여러분은 이미 잘 돌아가는 workflow를 바꿀 필욘 요는 없습니다. 여러분의 팀은 subversion에서 하던 그 방법 그대로 프로젝트를 개발할 수 있습니다.

 

 그러나 개발 workflow를 위해 git를 사용하는 것은 SVN에 비해 몇몇의 장점을 갖고 있습니다.

 먼저, git는 모든 개발자의 local 에 전체 프로젝트 파일을 공통적으로 보내줍니다. 이런 환경은 각각의 개발자들이 독립적으로 일할 수 있게 합니다. 각각의 local 저장소에 commit 하고 원할 때 push 할 수 있다는 것이지요

 두번째로, 강력한 branch 기능과 merge 기능을 쓸 수 있다는 것입니다. SVN과 달리 git의 branch는 실수에도 안전한 메커니즘으로 디자인되어져있습니다. 저장소 간 코드를 합치거나 변화된 내용들을 공유하기가 훨씬 좋아진 것입니다.

<How it works>

 Centralized workflow는 Subversion 처럼 프로젝트의 모든 변화를 하나의 entry 로 보내는 중앙 저장소를 사용합니다. 단 차이점이 있다면 trunk 대신 master라고 부르는 기본 개발 branch가 있고, 모든 변화는 이 branch로 커밋된다는 것입니다. 그리고 Centralized workflow 방식은 master branch만 필요로합니다. 다른 branch는 쓰이지 않습니다.

 개발자는 중앙저장소를 clone하는 것으로부터 개발을 시작합니다. Clone하게 되면 프로젝트가 개발자의 local에도 만들어지는데, 이 안에서 SVN을 쓰는 것처럼 파일을 변경하고 커밋합니다. (그러나, 이런 새로운 commit 들은 local 에 저장되기때문에 개발자들은 철저히 중앙저장소와는 독립되어있습니다. 또한 이는 개발자가 merge 하기 좋은 시점에서 동기화할 수 있도록 전체 흐름을 지연시켜주는 역할을 하기도 합니다.)

 변경사항을 프로젝트로 내보내기위해, 개발자는 그들의 local 에 있는 master branch 를 중앙저장소로 "push" 합니다. 이는 svn commit 과 같은 의미를 갖고 있습니다. 차이점이 있다면 local에 저장된 모든 commit 까지 중앙저장소의  master branch로 보내집니다. 아래 그림을 보시면 되겠습니다.

 중앙저장소에 있는 3개의 commit들을 clone 하고 난후 master에서 2개의 commit 작업들을 했습니다. 그리고 중앙저장소로 push하게 되면 최종본만 날라가는 것이 아니라 그 이전의 새로운 commit 역시 중앙저장소로 보내집니다.

<Managing Conflicts>

 Centralized workflow에서 중앙 저장소는 곧 프로젝트 그 자체를 나타냅니다. 그렇기때문에 중앙저장소의 master 에 대한 commit history는 매우 주의를 요합니다. 만약 한 개발자의 local commit이 중앙저장소로부터 분리되어나와서 진행되었다면 git는 push 를 거부할 것입니다. 아래 그림을 보시면 됩니다.

 origin/Master 가 중앙저장소의 branch를 나타냅니다. 저 상황에서 local의 push는 conflict를 유발하게 됩니다.

 그 개발자가 본인이 개발한 기능을 push하기에 앞서, 다른사람들이 작업을 마친 최신의 central commit 를 받아와야할(fetch) 필요가 있겠죠. 이렇게 진행해나가다보면 완벽한 직선형의 workflow가 만들어지게되고 이는 전통적인 SVN의 workflow와 일치합니다.

 local의 변경사항을 push 하다가 conflict이 발생하면, git는 rebase 과정을 멈추고 conflict를 직접 해결할 기회(?)를 줍니다. commit 할 때 쓰던 git status, git add 명령어들로 conflict들을 정리할 수 있는데, 다음 블로그에서 centralized workflow 에 대한 실제 사용예를 보며 익혀보겠습니다.