메뉴 건너뛰기

프로그램언어

조회 수 2077 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부
Git

SVN과 마찬가지로 Git은 소스코드를 관리하기 위한 소프트웨어다. 소프트웨어를 개발하는 기업의 핵심 자산인 소스코드를 효과적으로 관리할 수 있게 해주는 소프트웨어다. 최근 오픈소스 커뮤니티의 발전과 함께 널리 사용되고 있으며, SVN을 사용하던 개발 조직들도 하나둘씩 Git으로 갈아타고 있는 추세다.
SVN과 다른점은 분산형 관리 시스템이라는 점으로 다양한 형태의 Workflow를 가능하게한다.

Git이 SVN과 다른 점은 분산형 관리 시스템이라는 것이다. 중앙 서버에 소스코드와 히스토리를 저장하는 SVN과 달리 Git은 소스코드를 여러 개발 PC와 저장소에 분산해서 저장하기 때문에 중앙 서버에 장애가 발생해도 로컬 저장소에 커밋을 할 수 있으며, 로컬 저장소들을 이용하여 중앙 저장소의 복원도 가능하다.

또 한, 분산형으로 코드를 관리하기 때문에 다양한 Workflow를 가능하게 한다는 점이 SVN과 비교하여 Git이 갖는 장점이라 할 수 있겠다.

초창기 Git은 리눅스를 만든 리누스 토발즈가 리눅스 커널 개발에 이용하려고 만들었다. 이후 GitHub 등에서 오픈소스 개발을 위해 사용하면서 소프트웨어 업계에 널리 사용되게 되었다.

Git은 작은 소프트웨어 개발 프로젝트에서 거대 프로젝트까지 다양한 규모의 소프트웨어 소스코드를 빠르고 효과적으로 관리할 수 있는 무료이자 공개소프트웨어이다. 

Workflow

중앙집중형(Centralized) 버전 관리 시스템인 SVN과 다르게 분산형 관리 시스템인 Git은 다양한 Workflow를 구성할 수 있다. SVN 스타일의 중앙집중형 관리 방식은 물론이고, GitHub에서 볼 수 있는 Workflow도 구성할 수 있다.

1. Centralized Workflow (SVN Style)
중앙집중형 Workflow는 SVN에서 사용하는 Workflow다. 중앙에 공유 저장소(Shared Repository)를 두고 프로젝트에 참여하는 개발자들이 Checkout 혹은 Clone을 하여 작업을 진행한다. 작업이 완료되면 공유 저장소에 Commit(Push)하는 방식으로 소스코드 공유가 이뤄진다. SVN의 코드 관리를 생각하면 편하다.

분산형 버전관리 시스템인 Git으로도 이런 형태의 Workflow를 구성할 수 있다. 중앙에 저장소를 두고 개발자들이 저장소를 Clone하여 작업한다. 이후 중앙에 있는 공유 저장소에 Push를 하는 식으로 작업하면 SVN처럼 중앙집중형으로 버전관리를 할 수 있다. 서로다른 개발자가 작업한 내용이 소스코드의 같은 부분을 수정했다면 Git의 Push 동작이 알아서 충돌(Conflict)을 발생시키고 개발자들은 적절한 처리를 하면된다.

프로젝트의 규모가 작은 경우 혹은 SVN을 사용하다가 Git을 도입한 초기단계에서 사용할 수 있는 Workflow다. Git이 가지고 있는 유연성과 강력한 기능들을 모두 사용할 수는 없지만 일단 Git을 도입할 수 있기에 많이 사용하는 Workflow라고 할 수 있다.

2. Integration-Manager Workflow (GitHub Style)
중앙집중형 Workflow이외에 깃헙(GitHub)에서 찾아볼 수 있는 'Integration-Manager' Workflow도 많이 사용된다. 오픈소스를 호스팅하는 깃헙의 특성에 맞는 Workflow이다. 'Integration-Manager' Workflow에서는 프로젝트를 대표하는 메인 저장소(Blessed Repository, Main Repository)가 존재하며 개발자들은 메인 저장소를 Clone하여 각자 작업을 진행한다.

메인 저장소는 'Integration-Manager'라고 하는 역할이 관리를 하게 되며 개발자들은 Clone해 놓은 자신의 저장소에 작업을 반영한다. 이후 개발자들은 메인 저장소에 반영을 해달라고 'Integration-Manager'에 요청을 한다. 요청을 받은 Integration-Manager는 수정사항을 리뷰하여 적절한 경우 메인 저장소에 변경사항을 반영한다.

개발자들이 Main 저장소에서 소스코드를 Clone 한다
이후 개발자들은 자신이 담당하는 이슈를 처리, 소스코드를 반영하여 자신의 Public 저장소에 Push한다.
Integration Manager에게 Pull Request를 요청한다.
Integration Manager는 개발자의 코드를 리뷰하여 Main 저장소에 반영할지 여부를 판단한다.
Main 저장소에 수정사항을 반영한다.

오픈소스 코드 관리에서 많이 찾아볼 수 있는 형태의 Workflow로 Integration-Manager에 의해 코드가 관리되는 형태다.

3. Dictator and Lieutenants Workflow (Linux Style)
깃헙 스타일의 Workflow를 약간 변경한 형태로 리눅스 커널 프로젝트가 이와같이 관리되고 있다. 프로젝트의 크기가 매우 큰 경우 소수의 Integration Manager가 모든 수정과 반영 요청을 처리하기 힘들다. 리눅스 커널 프로젝트에서는 관리자가 Dictator라고 하는 메인 저장소 관리자와 소스코드의 서브시스템을 담당하는 Lieutenants들로 나뉜다.

개발자들은 메인 저장소에서 소스코드를 Clone하고 작업을 진행한다. 완료된 작업은 해당 서브시스템을 담당하는 Lieutenant에게 먼저 리뷰를 받는다. 이후 Dictator가 메인 저장소에 작업 내용을 반영할 것인지 결정하여 메인 저장소를 관리하게 된다.

소스코드가 계층구조를 갖으며 여러개의 서브 모듈로 코드를 분리할 수 있을 때 효율적으로 동작할 수 있는 Workflow다.

본 포스트에서는 3가지 특정 예들만 살펴봤다. SVN에 비해 Git은 이렇게 다양한 Workflow에 응용하여 사용할 수 있으며, 다양한 조직에서 이런 기본적인 Workflow를 변형하여 자신의 프로젝트에 맞게 사용하고 있다.



하단 정보를 입력할 수 있습니다

© k2s0o1d4e0s2i1g5n. All Rights Reserved