DevOps : 소스코드관리 : Git 기능 개념

Pull Request 원리

 

Pull Request

일반적으로 기업의 프로젝트나 오픈소스 프로젝트의 경우 원격 저장소의 쓰기 권한을 일반 개발자가 가지고 있지 않고 읽기 권한만 가지고 있는 경우가 많습니다.

저장소를 클론했을 때 나의 로컬에서 작업은 가능하지만, 내용을 수정해서 반영하고 싶은 경우에는 쓰기 권한이 없기 때문에 Push를 할 수가 없습니다. 이때 해당 원격 저장소의 쓰기 권한을 직접적으로 받아내기는 어렵기 때문에 해당 레파지토리를 나의 원격 저장소로 포즈한 다음에 이것을 클론하여 작업하고 Push해서 Pool Request를 요청하여 변경사항에 대한 반영을 요청할 수 있습니다.

 

Fork

요청받은 소스코드 저장소 관리자는 해당 내용을 검토해서 반영 여부를 적용할 수 있습니다. 포크가 완료되면 나의 계정에 저장소가 생성된 것을 확인할 수가 있습니다. 원격 저장소에 저장된 프로젝트를 로컬로 복제해 올 수 있습니다.

해당 프로젝트를 Maven Project로 Import 해보겠습니다. 메뉴에서 Import Maven Project를 선택하고 Finish를 하게 되면 메이븐으로 작성된 프로젝트가 Import됩니다. 

 

Branch

팀 메뉴에서 히스토리 정보를 보게 되면, 지금까지 소스코드를 관리했던 내역들을 확인할 수 있습니다. 매우 많은 사람들이 오래 전부터 작업을 해온 것을 확인할 수 있습니다. 애플리케이션을 개발하다 보면 소스코드를 공유하면서 여러 버전의 소스코드가 생성이 됩니다.

어떤 개발자는 신규 기능을 추가하게 되고 어떤 개발자는 버그를 수정하기도 하는데, 이때 여러 버전의 코드를 각각 독립적으로 유지/관리하면서도 통합하는 것이 중요합니다. 이를 효과적으로 관리하기 위한 기능이 브랜치입니다. 여러 개발자들이 동시에 다양한 작업을 진행할 수 있게 해줍니다.

독립되고 분리된 상태에서 작업하고 나중에 원래 버전과 비교하며 새로운 버전으로 통합할 수도 있습니다. 브랜치를 사용하여 동시에 New Feature 작업과 Bug Fix 작업을 진행하고 있습니다. 보통 여러 명이서 동시에 작업을 진행하기 때문에 다른 사람의 작업에 영향을 주지 않게 하기 위해서 신규로 브랜치를 만들게 되고, 작업이 완료된 후에 마스터 브랜치에 통합하게 됩니다.

의미 있는 작업 단위로 분류하여 관리할 수 있기 때문에 관리하기가 편리합니다. 마스터 브랜치는 Git이 기본적으로 생성하는 브랜치 이름입니다. 새로운 브랜치를 만들지 않으면 모든 작업들은 마스터 브랜치에서 이루어집니다. 팀원들과 혼동을 피하기 위해서 브랜치 종류 및 규칙은 사전에 약속해야 합니다.

일반적으로 공통적으로 쓰이는 브랜치 개념이 통합 브랜치와 토픽 브랜치입니다. 통합 브랜치는 항상 배포할 수 있는 버전을 유지하는 브랜치입니다. 따라서 항상 모든 기능이 정상적으로 작동되어야 합니다.

그런데 작업 시 마스터 브랜치에서 바로 작업하게 되면 항상 정상적으로 작동된다는 보장을 하기 어렵기 때문에 기능 추가나 버그 수정 등의 변경작업이 생기면 작업별로 브랜치를 생성해서 진행해야 합니다. 이를 토픽 브랜치라고 합니다. 토픽 브랜치는 통합 브랜치로부터 생성하여 토픽 브랜치의 작업이 완료되면 다시 통합 브랜치에 병합하는 방식을 사용합니다. 개발자가 작업할 브랜치를 미리 선택하기 위해서 브랜치 전환을 할 수 있습니다.

 

Checkout

다른 브랜치로 전환하는 것을 체크아웃이라고 합니다. 체크아웃을 실행하면 브랜치가 전환되었기 때문에 Commit을 실행하는 경우에 전환된 브랜치에 적용이 됩니다.

 

Head

헤드란 현재 사용 중인 브랜치를 가리킵니다. 기본적으로는 마스터의 선두를 나타냅니다.