일을 하다보니 체계적인 git 관리의 필요성을 느껴 효율적인 관리 방법에 대해 작성했습니다. 위 사진은 효과적인 브랜치 관리 전략 중 하나인 git-flow를 가장 잘 나타낸 그림입니다. 어떤 방식으로 그림과 같이 git을 사용할 수 있는지 소개하겠습니다.
-
Fork
Repository 를 Fork 해서 개인 계정 소유의 Repository 를 생성하세요. 생성에 성공했다면 아래와 같이 본인계정의 Repository가 생성될 것입니다. 또, 원본 프로젝트가 무엇인지도 확인할 수 있습니다.
-
Clone
생성된 본인 소유의 원격 Repository 를 Clone 합니다. Git bash 를 사용해도 좋고, Source tree 를 사용해도 좋습니다. 본인에게 편안한 소프트웨어를 선택하세요. -
Remote upstream 설정
원본 Repository의 주소를upstream이름으로 Remote에 추가합니다. -
Branching
로컬 Repository 에서 작업할 때는 다음 규칙을 따라주세요. 아래는 만들어질 브랜치의 이름과 설명입니다.
master- pull
upstream/master전용 - 항상
upstream/master와 내용이 일치해야 합니다. - apk 패키징은 반드시
master브랜치에서 이루어져야 합니다.
- pull
develop- pull
upstream/develop, pushorigin/develop, mergemaster전용
- pull
feature-*- develop branch에서 기능을 추가할 때마다 생성할 브랜치
- 실질적인 코드 수정은 여기서 해주세요.
*에는 만들어질 기능을 쉽게 알 수 있는 이름을 적어주세요- 예시) feature-UpgradeUEVersion, feature-GPSTracker
-
feature-*에서 코드 변경
develop 에서 브랜치 분리 후 코드를 변경하고 원하는 만큼 Commit 하세요. origin에 feature-*브랜치가 업로드 되어도 상관은 없지만 반드시 fetch 또는 clone 이외의 목적으로 사용되어서는 안됩니다. -
develop에서feature-*브랜치 Merge
develop으로 브랜치 이동 후 5번 항목에서 진행했던 feature-* 브랜치를 Merge 해주세요. 5번과 6번 항목을 필요한 만큼 반복합니다. -
upstream/develop브랜치 Pull
다른 개발자의 작업물이upstream/develop브랜치에 push 된 것을 고려하여upstream/develop브랜치를 pull 받아 양쪽에서 수정된 파일을 확인합니다. -
develop브랜치 Push
origin/develop으로 develop 브랜치를 push 합니다. -
Pull Request (PR) 생성
Gitea 에서본인의 원격 Repository 또는 upstream repository 로 이동하면 풀 리퀘스트 탭을 확인할 수 있습니다. 새 풀 리퀘스트 버튼을 눌러 upstream에 병합을 요청하세요. 변경된 코드가 많다면 시간이 다소 걸릴 수 있습니다.
PR 생성 후부터는 합쳐질 브랜치의 커밋 내용이 변경되어도 자동으로 원격 저장소의 커밋 내용을 추적하니 PR 삭제하고 다시 만들 필요는 없습니다. -
코드 리뷰
PR에서는 어떤 파일이 어떻게 수정되었는지 확인할 수 있습니다. 변경된 줄에 line comment 를 주고 받을 수 있는데, 이 기능을 활용해서 코드 리뷰를 진행합니다. 또는 line comment 를 활용하지 않고 대화 탭에서 comment로 대화를 주고 받으며 코드 리뷰를 진행합니다.
코드 리뷰가 완료되고 n명 이상의 개발자의 동의를 얻으면 브랜치 병합을 진행할 수 있습니다.
만약 코드 리뷰를 할 필요가 없는 리소스 교체 작업이거나, 코드 리뷰를 할 시간이 없을 만큼 급한 PR 이라면 PR 요청자가 직접 병합을 진행한 다음, 코맨트에 @개발자ID 로 1명 이상의 개발자를 태그하여 긴급 merge 를 팔로우 할 수 있도록 해주세요.
