GitHub 로 스터디 운영하기 (Git Flow, Fork, Convention)

 

Keyword

---

Git , Github , Study , Git Flow , Pull Request , Issue , Milestone

 

http://jobfactory.or.kr/job/47/view?SEQ=1&page=3

 

 

Overview

---

Git 은 여러 개발자들이 협업을 할 수 있도록 도와주는 형상관리도구입니다. 우리는 개발을 처음 배우면서 깃허브에 레파지토리를 파고, 1인 개발자의 코드만 형상관리를 합니다.

그러나 우리는 작은 프로젝트부터, 특히 현업에서는 혼자가 아닌 팀 단위로 개발을 진행하기 때문에 Git 으로 어떻게 협업하는 지에 대해 간단하게 알아볼 것이다.

 

 

 

 

Git Flow

---

https://mishka.kr/18

 

Git Flow 라 함은 쉽게 말해 Git Branch 를 어떻게 관리할 것인가에 대한 전략을 의미합니다. 현업에서는 개발을 진행할 때, Develop → Stage → Product 으로 배포가 진행됩니다. 각각 로컬환경에서 개발을 진행한 후 Develop 으로 배포를 진행하여 개발환경에서 간단한 테스트와 실행환경을 확인할 수 있습니다. 이후 Stage 에서는 개발자 뿐만 아닌 기획자, 운영자, QA 등 여러 관계자들이 해당 기능을 테스트하고, 비즈니스적 관점에서도 잘 동작하는지 확인하는 절차를 거칩니다. 그 후 Product 으로 배포되면 실제 사용자들에게 기능을 제공하는 것입니다.

 

크게 Develop, Stage, Product 으로 구분되는데, 해당 Git Branch 에 접속하는 것만으로도 각 환경에 맞게 버전관리, 형상관리를 진행할 수 있다는 장점이 있습니다.

 

 

 

 

 

Git Flow 는 위에서 말씀드렸던 Develop, Stage, Product 이외에도 다른 브런치도 소개하고 있습니다.

알기 쉽게 파일 업로드 기능 구현의 상황 시나리오로 설명해드리면 아래와 같이 진행될 수 있습니다.

 

1. (Feature) : 개발자가 로컬에서 해당 Feature (파일업로드기능구현) 을 생성하고, 브런치에서 개발 진행
2. (Develop) : Develop 브런치에 Merge 후 개발 환경에서 테스트 진행
3. (Stage) : QA 담당자, 기획자 등과 같이 QA 진행 (이상유무, 비즈니스 로직 체크)
4. (Master) : 모든 테스트가 끝난 상태로 바로 배포 가능
5. (Release) : 운영환경에 배포를 준비하는 브런치 (버전관리)
   1. (HotFix) : 예기치 못한 오류로, 급하게 수정이 필요한 경우 해당 버전에서 수정 후 배포, 반영
   2. (Master) : HotFix 에서 최종 반영 및 배포된 소스를 Master 로 반영

 

 

 

 

Git Commit Message Convention

---

우리는 commit 을 입력할 때 어떤 내용인지 메시지를 입력합니다. 이때 항상 메시지 모두를 읽는 것보다 어떤 목표로 만들어진 기능인지 간략하게 알 수 있으면 커밋 메시지를 보기 더 쉬워질 수 있습니다.

이부분은 규칙일 뿐이므로 해당 팀에 알맞게 조율해보자.

 

 

• feat : 새로운 기능
• fix : 버그 수정
• docs : 문서 변경
• style : 포맷팅, 코드 변경 없음
• refactor : Refactoring code
• test : 테스트 수정/추가
• chore : 빌드 작업, 패키지 관리자 구성 등 업데이트, Production Code 변경

 

 

 

Fork

---

개발 스터디를 운영할 때, Fork 의 개념을 활용하는 방법도 추천한다. 보통 Repository 에서 Contributor 로 스터디 팀원들을 초대하여 진행하는 방법도 있지만, 특정 팀원의 레파지토리를 Fork 를 따서 자신의 레파지토리로 옮기는 방법도 있다. 이는 흔히 오픈소스에서 많이 활용되는데, 우리가 오픈 소스에 기여하고 싶을 때, 해당 레파지토리를 Fork 로 자신의 깃허브로 가져와 수정한 후 Pull Request 를 원격레파지토리로 날리면, 원격 레파지토리의 주인이 승낙할 시 우리의 소스가 반영되는 구조이다.

 

 

• 우측 상단에 Fork 라는 버튼이 있으며, 이 버튼을 누르면 해당 레파지토리를 자신의 깃허브로 가져올 수 있다.

 

 

• 원격 레파지토리에서 자신의 레파지토리로 Fork 한 레파지토리

 

 

• 위의 Pull Request 에서 알 수 있듯이, 개인 저장소 kjuiop/main 에서 원격 저장소 calm-and-calm-study:main 으로 Pull-Request 를 날린 상태이다.
• 관리자가 이를 승인하면 소스가 Merge 되어 병합이 완료된다.

 

 

이는 북스터디, 오픈소스 등의 스터디에서 유용하게 쓸 수 있는 방법이다.

 

 

 

Github Issue 와 Project, Milestone

---

GitHub Issue 와 Project, Milestone 을 활용하면 간단하게 프로젝트 관리를 깃허브로 관리할 수 있다. 사이드 프로젝트 소스 따로, 일정 관련 문서 따로 분리되어 있으면 찾기 어렵겠지만, 위의 기능을 활용하면 깃허브만으로도 충분히 일정관리를 팀원들과 진행할 수 있다.

해당 내용은 밑의 글에서 소개하도록 하겠다.

 

https://catchdream.tistory.com/216

[비사이드 #3] Github Issue 를 활용한 팀프로젝트 환경 셋팅

 

 

 

 

 

Reference

---

• https://www.lainyzine.com/ko/article/how-to-rename-local-github-branch/