깃 브랜치 전략?

깃 브랜치를 운영하는 방법론

• gitflow: master, develop, feature, release,hotfix 브랜치를 설정하고 운영하는 방식
• github flow: main(master), feature 브랜치만으로 운영하는 방식

왜 이런 전략이 필요하지?

• 하나의 프로젝트 소스코드를 여러 개발자가 다루면서 발생하는 각종 부작용을 해결하기 위해

• 개발 협업을 원할하게 하기 위한 약속

• 전략을 잘못 짜면 나와야할 소스코드가 삭제되고 나오지 말아야할 소스코드가 나오는 문제가 발생할 수 있다.

• 전략을 세울 때 고려할 수 있는 요소들

  • 이 브랜치는 제품으로 내보낼 수 있는가?
  • 이 브랜치는 빌드 실패를 허용하는가?
  • 이 브랜치는 테스트 실패를 허용하는가?
  • 이 브랜치는 임시로 운영하는가? 유지하지 않고 수시로 삭제하는가?

  깃허브 프로젝트에서 backlog과 new 항목에 몇가지를 추가한다. new 항목에 자유롭게 작성하고 해야할 일 목록을 backlog에 추가하는 방식으로 사용한다.
  

그리고 업무를 진행할 준비가 되어있다면 Ready 항목으로 이동시켜서 다른 협업 개발자들이 준비된 업무를 볼수 있게 변경한다.

깃 브랜치 전략세우기 항목의 이슈를 열어서 세부적으로 해야할 일을 작성했다.

다시 프로젝트 화면으로 돌아와보면, new와 backlog의 경계가 조금 애매하다고 생각할수도 있다. 만약 new 항목을 없애도 싶다면 setting 으로 들어가서 status에서 옵션에 나타난 항목중 new를 제거하면 된다.

첫번째의 New를 제거하고 돌아가보면.

이렇게 new 가 지워진 모습을 확인할 수 있다.

다음에 해야할 일을 ready로 옮겼다.
유즈 케이스 작성, 게시판 api, 스프링부트 시작하기, 도메인 설계를 해보기로 했다

이런식으로 정리가 되어있으면, 협업 개발자들이 봤을때 어떤 업무를 하고있는지, 해야하는지, 하는중인지를 알수 있게 된다.

그럼 이제 다시 원래 주제로 돌아와서 이번 게시판 만들기 프로젝트에 적절한 깃 브랜치 전략을 선택해보자.

깃 브랜치 전략은 좀더 세밀한 파트로 나누어진 gitflow를 사용하기로 했다. 체계적으로 진행하는 프로젝트인 만큼 세밀하게 파트를 나눠서 진행하는 것이 좋은 경험일 것 같다. 그리고 여러 기업들이 정형화된 전략을 많이 사용하기 때문에 미리 눈에 익혀놓는 것이 타당하다고 생각한다.

깃 브랜치 전략은 github flow 를 사용하기로 했다. 규모가 그렇게 큰 프로젝트는 아니기 때문에 gitflow로 진행하기에는 오히려 세분화가 과분하게 되어서 진행에 혼란을 일으킬 것같다.

git kraken은 gitflow에 대한 옵션이 잘 구성되어있어서 버튼만 누르면 구성이 완료되지만 github flow는 통합되어있지 않지만 적당히 손을 보면 github flow 처럼 보이게 된다.

먼저 브랜치를 추가해서 사용하지 않는 브랜치라는 것을 알수 있게 적당히 가짜라는 뜻으로 fakeone이라고 이름을 지었다.

그리고 옵션으로 돌아가서 gitflow 옵션으로 들어가면 아래와 같은 화면을 볼 수 있다.

feature-branch 즉, feature만 개발에서 merge하는 전략은 feature가 만들어져서 develop으로 가는 구조이다. 따라서 feature가 master로 바로 가지 않는다(gitflow 도구옵션이기 때문에).
따라서 develop 자리에 main 브랜치를 놓을 것이다. 그리고 master자리에는 아까 만든 fakeone으로 지정한다. 기능적으로 봤을 때 master 자리의 fakeone은 사용하지 않고, develop만 가지고 개발을 하는데 이 develop이 main 역할을 대신하는 것이다.

gitflow 도구의 설정이지만 이와 같이 브랜치를 우회하는 방식으로 github flow전략을 구현할 수 있다.

왼쪽에 fakeone과 main이 추가된 모습이다.
또한 프로젝트와 연동된 github issues도 추가된 것도 확인 할 수 있다.

이제 gitflow 항목에서 브랜치를 추가한다. 현재 깃 브랜치 전략 세우기를 하고 있으므로 오픈된 이슈 번호와 함께 협업자가 어떤 업무때문에 만들어진 브랜치인지를 확인 할 수 있게 작성한다.

이렇게 하지 않고 위의 항목에 branch를 클릭해서 이름을 작성해도 되지만 그냥 이름만 적으면 features 디렉토리 안으로 들어가지 않는다. 디렉토리 안으로 넣어주려면 브랜치를 생성할때 이름으로 features/브랜치이름이렇게 하나하나 작성해야하는데, gitflow 도구를 사용아면 이런 작업을 생략해도 된다.

이제 어느정도 전략이 완성 되었다. feature에서 개발을 진행하고, 완성이 되면 pull request를 하고, 이를 통해 merge 되면 main으로 통합이 되어 업무는 종료된다.

feature 개발 -> pull request -> main 으로 merge -> 업무 끗!

그럼 이제 이슈에서 체크 항목을 체크 해주고 이슈를 종료해주면 끝이 난다.

다음에 할일: 유즈 케이스 작성