Dictionary

[GitHubFlow] 형상관리 전략 GitHubFlow

ride-dev 2024. 1. 16. 01:17

개발을 진행할 때 협업은 상당히 중요합니다.

OilNow 프로젝트를 시작하기 앞서,

GitHub를 활용한 GitHubFlow를 진행할 것이며,

왜 이 방법을 채택하였고, 어떻게 진행할 것인지에 대해 작성해보려고 합니다.

왜 GitHubFlow인가?

GitHubFlow는 간단하기 때문에 소규모 프로젝트에 적합합니다.

각각의 기능이나 작업이 하위 브랜치를 통해 병합되기 때문에, 동시 다발적인 개발이 가능합니다.

Pull Request를 통해 손쉽게 코드리뷰할 수 있습니다.

Issue와 Pull Request, Project를 통해 프로젝트의 작업에 대한 추적이 쉽습니다.

하위 브랜치 작업, 병합, 배포의 과정이 빠릅니다.

Network Graph

이제 여러 단계를 나눠서 세부적으로 설명해보겠습니다

0.1. (선택) Organizations을 생성합니다

Your organizations를 클릭하여 organizations페이지로 진입합니다.

New organization 버튼을 클릭하여, 새로운 organizations을 생성합니다.

생성한 organization에 다른 GitHub 사용자를 초대할 수 있습니다.

 

생성된 페이지에서 여러 작업을 할 수 있습니다.

상단 탭에 여러 메뉴가 있으며,

Organization용 Repository, Projects, Team 을 생성할 수 있습니다.

People 탭에서 구성원초대 및 세부 권한을 관리할 수 있습니다.

0.2. (선택) Projects을 생성합니다

Projects 탭에서 새로운 프로젝트를 만들 수 있습니다.

Template을 선택하여 생성할 Project의 틀을 결정합니다.

이렇게 만들어진 프로젝트는 이후 Issue나 Pull Request를 작성할 때, 매치할 수 있으며,

매치된 Issue나 Pull Repuest는 Project에서 추적 및 관리할 수 있습니다.

 

아래는 Pull Request또는 Isuue에서 확인할 수 있는 창입니다.

(후술할)라벨을 붙여서 이 게시글의 목적이나 목표를 확인할 수 있고,

Projects를 선택하여 Projects페이지에서 추적하도록 할 수 있습니다.

(Milestone도 마찬가지입니다)

 

1. Issue 생성

프로젝트의 시작은 GitHub의 Issue에서부터입니다.

각각의 기능 또는 작업에 대한 Issue를 생성하고 세부 내용을 서술합니다.

issue를 사용하면 작업에 대한 추적이 용이합니다.

버그, 문서 작성, 스타일 변경 등에 대해 작성할 수 있습니다.

Issue에 적합한 라벨을 붙입니다.

(필요에 따라 Edit Labels에서 라벨을 편집할 수 있습니다)

좌: 라벨목록을 확인하고, 하단의 Edis labels에서, 중앙: 라벨을 편집한뒤, 우:라벨을 붙일 수 있습니다.

또한, Milestones를 생성하여 Issue를 포함한 Project의 각 항목에 대해 포괄적으로 추적할 수 있습니다.

(v1.0.0과 같은 제목을 사용할 수 있으나, 프로젝트 규모를 고려하여 도메인 별로 나누고 추적이 용이하도록 했습니다)

이렇게 하면 프로젝트의 작업 항목들을 체계적으로 관리할 수 있습니다.

2. Project 보드 활용

Todo, In Progress, Done 등의 섹션으로 이루어진 Project 보드를 사용하면,

각 이슈의 상태를 효과적으로 관리할 수 있습니다.

Issue를 Project 보드로 이동시켜 팀이 작업의 진행 상황을 한눈에 확인할 수 있습니다.

3. Branch 생성 및 Commit

각 Issue에 대한 작업을 시작하기 전에 새로운 브랜치를 생성하고 해당 브랜치에서 작업을 수행합니다.

하위 브랜치에서 작업하면 여러 팀원이 동시에 작업할 때 충돌을 최소화할 수 있습니다.

 

commit message를 남길 때, commit과 관련된 이슈 번호를 붙이면,

이슈에서 commit 내역을 볼 수 있습니다.

아래와 같이 코멘트를 남길 수도 있습니다.

4. Pull Request 및 Review

작업이 완료되면 해당 브랜치에서 Pull Request를 생성합니다.

Pull Request는 변경 사항을 메인 브랜치와 병합하기 위해 검토되는 곳입니다.

팀원들은 여기에서 코드 리뷰를 하고 토론할 수 있습니다.

라벨이나 제목, 프로젝트에 대해 잊지 않도록 체크리스트를 만들 수 있습니다.

 - [x] 제목 및 이슈 표기

5. Merge 및 Project 업데이트

코드 리뷰가 완료되면 Pull Request를 메인 브랜치로 병합(Merge)합니다.

병합되면, Poject의 해당 사항은 Done 섹션으로 이동됩니다.

 

issue 또한 진행 상황에 따라 섹션을 변경합니다.

 

GitHubFlow는 간단하면서도 효과적으로 프로젝트를 관리하고 협업할 수 있는 방법입니다.

이러한 방법을 사용하는 것은 개인에게 번거로운 일일 수 있으나,

협업하는 관점에서 본다면 꼭 필요한 과정입니다.

728x90

'Dictionary' 카테고리의 다른 글

[Kafka] 개요; Message Broker & Kafka  (0) 2024.06.22
[Dictionary] Computer Network, 컴퓨터 네트워크  (1) 2024.06.20
Shebang #!  (0) 2024.01.11
Session vs Request Scopes  (0) 2024.01.06
[Dictionary] Bootstrap  (1) 2023.12.29