[git] 팀 프로젝트를 하기 위한 git 사용 전략

개요
- Branch 전략을 정하자 (Git Flow vs Github Flow)
- Github를 이용한 칸반보드
- 코드리뷰 방법
- 문서 관리 with Wiki

 

팀 프로젝트를 진행하면서 Github를 단순히 Repo만 공유하는 느낌으로 사용한단 느낌을 받았다. 프로젝트의 Tab만 봐도 Issues를 비롯해 여러가지 기능이 많고 우측의 Nav만 봐도 여러가지 할 수 있을 것 같다는 생각이 들었기에 어떻게 활용을 잘 할 수 있을까를 고민하다 한번 정리를 해보았다.

 

✅ Branch 전략

---

Github를 올바르게 사용하기에 앞서 Branch 전략를 어떻게 가져갈지에 대해서 정해야 한다. 

이름에서 알 수 있듯이 branch의 네이밍은 어떻게 하고 각각의 branch를 어떤식으로 사용하고 merge를 어떻게 할지를 정하는 것이라고 생각하면 된다.

많이 알려진 2가지 전략 Git-Flow, GithHub-Flow를 비교하려 하고 선정하려 한다.

 

📦 Git-Flow 전략

대규모 프로젝트에서 사용할 때 큰 장점을 보이는 Flow로 feature, develop, release, main(master), hotfix 브랜치로 이루어진 전략이다.

• feature: develop 브랜치에서 생성(파생)되는 브랜치로 기능을 구현할 때 생성하는 기능 단위의 브랜치
  일반적으로 " feature/기능이름 "과 같은 이름을 붙인다.
• develop: feature 브랜치에서 구현된 기능이 모이는 기둥 역할의 브랜치
• release: 배포 전 테스트 or 버그 확인을 하기 위한 브랜치로 기능 구현이 완료된 후 생성하는 브랜치
  일반적으로 " release-1 "과 같은 이름을 붙인다.
• mian: 실제 배포되는 소스의 브랜치
• hotfix: main 브랜치를 통해 배포가 진행 된 이후 발생한 문제에 대해 해결하기 위한 브랜치로 main과 develop으로 merge를 진행한다. 일반적으로 " hotfix-1 "과 같은 이름을 붙인다. 

git-flow

 

📦 GitHub-Flow 전략

대규모 프로젝트에 유리했던 git-flow는 그만큼 많은 브랜치를 관리해 복잡하다는 특징이 있습니다. 그에 비해 간단하게 main, (branch) 브랜치로 이루어진 github-flow는 브랜치 이름을 통하여 기능구현, 버그 수정 등의 목적을 명시합니다.
git-flow에 비해 브랜치 구조가 간단하기에 규모가 작은 프로젝트나 기한이 짧은 경우에 적합하다.

• main(master): 배포를 위한 브랜치
• (branch): main 브랜치에서 생성(파생)되는 브랜치로 목적을 이름에 명시하여 브랜치를 생성합니다.

github-flow

 

기본적으로 한달 이상의 팀 프로젝트와 여러 사람들과의 교류가 필요한 경우에 + 나중에 취업할 때 좀 더 보기 좋은 Github를 위해서 git-flow 전략을 사용해도 좋다고 생각이 되었으며, 짧은 미니프로젝트의 경우에는 github-flow 전략을 사용해도 좋을 것 같다.

 

---

✅ 칸반보드 생성

---

앞서 branch 전략을 선정하였다면 github를 통해서 프로젝트 세팅을 해볼 것이다. 프로젝트 설계 단계에서 중요한 부분들에 대해 알아보고 어떻게 Github를 활용할 수 있을 지 알아볼 것이다.

 

📦 Organization 이용하기

일반 repogitory를 이용해서 팀 프로젝트를 구성하게 된다면, 소유주의 이탈 및 private 설정을 통해서 예기치 못한 문제가 발생할 수 있다. 이런 경우를 방지하기 위해서 oranization을 이용해서 팀 프로젝트를 구성하는 것이 좋다고 생각한다. 또한 FE와 BE의 분리를 해도 가시적으로 쉽게 볼 수 있기에 organization은 이러한 면에서 장점이 크다.

1. GitHub  organization 만들기
2. 동료 초대하기

 

📦 Project 생성하기

project를 생성하여 칸반보드를 만들어서 issue와 함께 연동을 해볼 것이다.

project 생성

• issue 만들기

issue를 만들게 되어 project와 연동해서 칸반보드에 반영될 수 있게끔 만들 수 있습니다.

이 때 Assignees와 Labels를 설정하여 책임자와 어떤 유형인지를 정한다면 더 좋을 것 같다. 

이렇게 만들어진 issue를 통해서 branch를 만들면 나중에 브랜치를 merge하고 delete하면 칸반보드에 자동적으로 종료처리가 된다.

(closes라는 edit 과정에서 추가적으로 명시해도 된다.)

 

• issue 작성 시 권장사항

아래의 이미지와 같이 issue를 통해서 구현할 기능에 대해 상세 이미지(Figma를 통해 구현한 UI)를 넣고 구현할 방향성을 적어 놓는다면 좋을 것이다. description이 자세히 적혀 있을수록 리뷰어 입장에서는 개발자의 생각 및 코드를 좀 더 이해하기 쉬울 것이라고 생각된다.

 

 

---

✅ 코드리뷰

---

많은 자료를 통해서 github를 이용한 코드리뷰는 굉장히 간단하고 보기 쉽게 되어있다는 생각이 많이 들었다 게다가 현업에서 이러한 느낌으로 사용할 것 같다는 생각에 이러한 방식으로 코드리뷰를 해보는 것은 도움이 많이 될 것 같다고 생각되었다. 코드리뷰의 절차는 대게 아래와 같다 저자가 코드를 작성하여 pull request를 하게 되면 상급자 또는 리뷰어의 피드백 및 승인을 받게 되고 이후 저자는 수정이 완료 된 코드를 머지하는 방식으로 사이클이 돌아간다.

 

📦 pull request 생성하기

pull request 생성 시에 브랜치의 생성을 issue를 통해서 생성하지 않았다면 이와 같은 방법을 통해서 project의 칸반보드의 내용과 연동시킬 수 있다. 이후 커밋된 상세내역을 통해서 변경 사항에 대해서 코드 리뷰를 작성할 수 있다. 피드백 사항이 없다면 approve를 통해서 pull request를 할 수 있게끔 설정하면 된다.

description의 내용은 상세하게 작성하여 리뷰어의 이해를 돕도록 하면 좋을 것이다.

 

---

✅ 문서 관리 팁

---

wiki를 통해서 프로젝트에 대한 설명, 상세 내역을 설명하면 좋으며 markdown형태로 생성이 되기 때문에 README.md에도 적어도 되지만 코드 컨벤션 및 문서화하기 좋은 내용들을 작성하면 좋다. (취향에 따라서 정하면 된다)

이번에 알게 된 내용을 중점으로 적용하면 좋을 내용을 적어보았다.

(🔗 참고 레포 )

📦 깃모지 적용하기

- ✨ (sparkles): 새로운 기능 추가
- 🐛 (bug): 버그 수정
- 📝 (memo): 문서 수정
- 🎨 (art): 코드 스타일 개선
- ⚡️ (zap): 성능 개선
- 🔧 (wrench): 설정 파일 수정
- 🚚 (truck): 파일 혹은 경로 이동/이름 변경
- 🔥 (fire): 코드 혹은 파일 제거
- ✅ (white_check_mark): 테스트 추가/수정

이런식으로 깃모지를 통해서 이미지를 보며 간단하게 어떤 주제의 내용인지 파악하기 쉬운 것 같다.

 

📦 WBS(개발 일정)는 노션으로

머메이드라는 것을 통해서 markdown에 표현할 수도 있지만 노션을 통해서 좀 더 작성 및 보기 편한 구조를 만들 수 있으니 노션을 이용하는 것을 권장하는 편이다.

notion에서 WBS

데이터 베이스를 생성해서 타임라인으로 보기를 통해서 보기와 같은 WBS를 만들 수 있다. 세부사항에 대해서는 추가적으로 조정하고 이렇게 만든 WBS를 캡쳐하거나 링크로 README에 올리는 것이 더 좋을 것 같다.

 

 

 

 

 

 

📌 참고 레퍼런스

• 라매개발자  
• 제주코딩베이스캠프