[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_81일차_"Git Flow, Github Flow"

🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [81]일차

🚀81일차에는 블로그 프로젝트의 UI 와이어프레임을 완성시키고, Git Flow나 Github Flow를 통해 Github로 협업할 수 있는 세팅방법을 배울 수 있었다.

학습 목표 : Github Organization이나 Github Project를 통해 Collaborator로 팀원을 초대하여 협업 진행 방식이 익숙해져야함

학습 과정 : 회고를 통해 작성

---

Git Flow

• 협업을 하는 방법을 의미
• 크게 branch는 master(최근의 main), hot fixed, release, develop, feature 가 있음
• Flow 과정
  1) 최초에는 main브랜치에서 시작하고, develop(=개발브랜치)로 옮겨서 개발을 시작하게됨
  2) 협업을 하기 위해 기능 브랜치를 분리하여 기능 별로 협업을 하게됨 (기능은 feature 브랜치에서 담당)
  3) feature브랜치에서 기능개발이 끝났으면 develop(개발브랜치)로 병합을 하게됨
  4) feature브랜치 내용을 develop 개발브랜치로 병합했으면 release 브랜치로 옮기게됨
  5) release브랜치는 실제 사용자에게 배포하기전에 확인해보는 구역 (테스트를 하는 느낌)
  QA나 문제점이 발견되면 다시 develop 개발브랜치로 와서 다시 개발
  문제 없을경우에는 release브랜치에서 계속해서 작업을 해나갈 수 있음
• 6) 문제가 더이상 없으면 main브랜치로 병합되는 것 (배포가 가능한 상태)
  
  
• develop브랜치에서 바로 main브랜치로 갈 수 없고 무조건 release브랜치를 거쳐가야함
• 브랜치에서 브랜치로 (레이어마다) 넘어갈때 PR을 요청 (Pull Request)
  PR : Merge전에 한가지의 레이어를 두고 검증을 하는 것 (팀원들이 코드를 리뷰해주는 것)

 

Github Flow

• Git Flow보다 좀 더 간단한 Flow를 가지는것이 Github Flow
• dev, release브랜치가 없음 → 검증절차를 최소화시키고 바로 배포로 가는 것
• PR을 통해서 검증을 하게되므로 브랜치를 간소화할 수 있음
  feature 브랜치에서 main 브랜치로 가기전 PR을 대신 더 꼼꼼히 수행
  
  
• PR을 날릴때 CI / CD 로 파이프라인을 구축한 다음 봇이 돌기도함
  1차적으로 지켜야하는 컨벤션이 수행되었는지를 봇이 검사 후 알림을 보내는 그런 역할
  봇처럼 자동화된 툴을 이용해 기본적인 검증들을 수행함
  그 외로 사람들이 수행하는 검증들은 사람이 직접하는 것
  
  
• CI/CD를 통한 파이프라인 자동화를 잘 구축해놓으면 사람이 해야할일을 일부 맡기고
  실제로 사람이 해야할 코드 리뷰 등만 사람이 담당하도록 하여 불필요한 시간을 단축하는 것이 장점

---

❓애자일 방법론

• 기민한 방법론
• 고객의 수정사항이 많이 들어오더라도 유연하게 대처하고 기민하게 반응하는 것
• 애자일방법론에도 Github Flow가 적합
• 개인 사이드 프로젝트에서도 여러 branch를 나누기 보단
  github flow와 같은 브랜치로 진행하는 것이 더 효율적일것

---

🚀실습 - Github Flow

• Project로 칸반 보드 관리 및 이슈 생성

이슈 : 할 일들을 의미, 할 업무들을 의미

💡커밋메시지 컨벤션 의미
- feature: 새로운 기능
- fix: 버그수정
- refactor: 유지보수

---

🚀 다른 브랜치로 코드 변경 후 저장소 확인

• 기능 추가의 feature/1 브랜치로 코드를 변경, 추가한 후 저장소를 확인해본다.

• 다른 브랜치에서 코드 변경내역이 있고 그 브랜치에서 push를 했으면
  사용자는 pull & request (PR)을 보내겠냐는 알림을 확인 가능

• Merging is blocked와 Review Required가 있는데
  이 프로젝트에 참여중인 다른 유저가 리뷰를 진행해야 Merge 가 활성화될 것

• feature/1 브랜치가 main 으로 가도록 병합할 것이라는 것을 화살표 방향을 통해서 쉽게 파악
• #1, #2는 이슈번호를 의미하고, commit 메시지에 이슈번호를 달아
  해당 커밋에서 어떤 이슈를 처리할 수 있었는지를 효율적으로 표시할 수 있다.

---

칸반 Kanban

• 애자일 및 DevOps 소프트웨어 개발 구현에 많이 사용되는 프레임워크
• 작업 수용량에 대한 실시간 커뮤니케이션과 작업의 완전한 투명성이 요구
• 작업 항목은 칸반 보드에 시각적으로 표시되므로 팀원은 언제든지 모든 작업 상태를 볼 수 있음

출처 : https://www.atlassian.com/ko/agile/kanban/boards

• 이처럼 팀의 업무를 시각화한 프로젝트 관리의 한 형태
• 팀이 프로젝트를 시작할 때, 누가 어떤 업무를 담당하는지, 업무가 어떤 단계인지,
  업무의 마감이 잘 되는지 파악할 수 있도록 업무를 간단하게 시각화하는 방법이 필요하기 때문에
  칸반보드를 활용하면 효율적인 프로젝트 관리가 가능
• 기능 : 팀이 업무와 각 팀원이 할 수 있는 작업량 간에 밸런스를 맞추는 도구
• 보드에서 업무는 열로 구성된 프로젝트 보드에 표시되며, 각 열은 업무 단계를 나타냄
• ex. 가장 기본적인 칸반보드에는 (할일, 진행중, 완료)와 같은 열이 표시되며 해당 업무 내용은
  보드에서 비주얼 카드로 표시되고 작업이 완료될 때까지 따라서 이동

---

🚀회고 결과 :

1차 팀 프로젝트에 대한 방향성을 정하고 설계하고나니 앞으로 개발할 수 있는 협업 공간, 툴이 필요했다.

Github Project에서 제공하는 칸반 보드를 통해 시각적으로 팀원들이 해야할 일과 진행중인 일, 완료된 일을 쉽게 구분해낼 수 있었다. 회고를 통해 칸반 보드의 기능에 익숙해지기 위해 노력할 수 있었다.

향후 계획 : 

- 앞으로의 프로젝트 기초 세팅 학습