DiaryProject(React) - Git

개요

• 그동안 팀원 간 코드 공유없이 local에서만 작업을 해왔다. 각자 기능구현이 마무리되고 기능과 페이지를 합치기 위해 하나의 repository에서 관리해야 할 필요성을 느꼈고, git을 통한 협업을 진행하기로 했다.

Git 협업은 처음인데...

• 개발 공부를 시작하기도 전에 git 강좌를 수강했던 적이 있다. 굉장히 다양한 기능을 배웠던 것 같은데, 막상 GIT을 통해 협업하려고 하니 구조를 어떻게 짜야할 지 막막했다.
• 그래서 참고한 것이 git flow이다.(아래 이미지 참고)

Git flow?

• Git flow는 어떤 기능이라기보다 하나의 약속에 가깝다.
• Main / develop / feature / release / hotfix 5종류의 서로 다른 기능을 하는 브랜치를 설정하고 운영하는 방식이다.
  • main : 실서비스에서 배포되고 있는 브랜치
  • develop : 회사 내에서 개발되고 있는 다양한 기능이 합쳐지는 브랜치
  • feature : 각 컴포넌트. 즉, 기능별로 개발되고 있는 브랜치이며 develop 브랜치에 합쳐질 브랜치
  • release : main에 merge 전 최종 확인을 거치는 브랜치
  • hotfix : main에서 심각한 오류나 수정사항이 발생했을 때 사용되는 브랜치
• 이러한 git flow는 sourcetree에서 git flow 기능을 통해 비교적 간편하게 사용해볼 수 있다.

Git flow of diary project

• GIT으로 협업하는 방법에 대해 관심이 많았던 내가 우리 팀만의 git flow 설계와 git에 익숙치 않은 팀원들을 위한 git manual를 제작하게 됐다.

Git flow Consideration

• 설계하기 전에 내가 몇가지 주의해야 할 부분이 있었다.
  1. 소규모 프로젝트에 맞게 git flow를 최대한 간소화시키기.
  2. GUI에 익숙하지 않은 팀원들을 위해 CLI로 하는 방법을 알려주기
  3. 하는 방법이 아니라 하는 이유에 대해 알려주기

• 나를 포함한 모두가 프론트엔드 개발이 처음이였기 때문에 예상치 못한 오류에 유연하게 대응하지 못할 가능성이 컸다. 그렇기 때문에 오류 수정과 코드 확인을 좀 더 직관적으로 할 수 있도록 '브랜치를 쌓자'는 생각이 들었고 다음과 같이 설계했다.

우리 팀만의 git flow 설계

1. develop / main 2가지 브랜치로 운영한다.

   • feature-develop-main 간의 depth를 추가할 만큼 기능(or 컴포넌트)가 많다.
   • git 관리를 처음 해보는 것이기 때문에 관리할 자신이 없었고 단순하지만 안전한 방식을 택했다.

2. main 브랜치에서 dev/(추가한 기능)이라는 브랜치를 생성한다. 수정사항을 적용하고 push한 뒤 머지 담당자(나)에게 알린다.

   • dev/기능명을 구체적으로 명시함으로서 해당 기능에서 오류가 발생했을 때 코드 내용을 빠르게 확인하고 대응할 수 있다.

3. 머지 담당자는 dev 브랜치의 push 내용을 확인하고 main브랜치로 merge한다. main branch에서 origin/main 브랜치로 push한다.

   • 비효율적일 수 있지만, 팀 회의에 merge를 한번에 진행하기로 했고 merge 전 다같이 github pullrequest를 통해 간단한 코드 리뷰를 할 예정이다.

4. 팀원은 다시 main 브랜치를 pull하고 2-4번을 반복한다.

   • 일반적으로는 merge된 브랜치는 삭제하지만, 나는 삭제하지 않기로 했다. 오류 발생 시 보다 직관적으로 그동안의 내역을 확인할 수 있게 하고 싶었기 때문이다.

결과

• 텍스트로 하는 방법을 전달했고 음성회의를 통해 각각의 기능과 과정을 이해할 수 있도록 설명했다.

• 그동안 모아볼 수 없었던 다양한 기능을 드디어 하나의 컴포넌트 파일에 묶을 수 있었다.(!)

• add commit push뿐만 아니라 git flow를 통해 협업하면 좋은 점, 각각의 커맨드를 왜 쓰는지에 대해, git 구조에 대해 연구해볼 수 있었고, 이제 자신있게 'git으로 협업해본 경험이 있다.'라고 말할 수 있지 않을까...? 생각한다. 5월 말에 있을 프로젝트 기간에도 이러한 경험을 바탕으로 git flow를 새롭게 설계하고 운영하는 주도적인 역할을 담당하고 싶다.