나의 깃 브랜치 전략

카카오 테크 캠프의 실시간 세션에서 Git 에 대한 강의를 듣게 되었습니다. 집중력이 안좋아서 그런지 자꾸 딴생각이 들던 중, 나는 프로젝트를 진행할때 어떤 브랜치 전략을 사용하고 있었지? 타인에게 설명할 수 없다는 것을 깨달았습니다.

이러한 부족함을 안고서 나는 어떤 브랜치 전략을 사용하는지 설명할 수 있어야 겠다 라는 생각이 들어 이 글을 씁니다. 

 

내가 생각하고 있는 전략

1. main 은 배포되는 브랜치이며, 개발은 dev 브랜치에서 이루어진다. 

2. dev 브랜치를 기준으로 각자가 맡은 이슈를 feat 브랜치에서 개발한다.

3. 개발이 완료되면 feat 브랜치에서 QA 를 진행한다.

4. 안정성이 검증되면 dev 로 pull request 를 보낸다.

5. 코드 리뷰 후 dev 에 merge한다.

6. dev 에서 main 으로 merge 한 후 release 한다.

 

* 제가 생각하는 브랜치 전략은 git flow 와 github flow 의 사이에 있는 것 같습니다. 추가로 공부한 결과 '트렁크 기반' 브랜치 전략이란 것도 찾아볼 수 있었는데, 이는 브랜치 하나에 작업을 하다보니 테스트 코드가 중요시 된다고 생각했고 이러한 테스트 코드는 여러 사람의 견해가 함께 모여 작성되어야 더 의미가 있다고 생각했기에 큰 프로젝트가 되어야 사용하기 적합하다고 생각했습니다.

 

 

팀프로젝트시에 있을 만한 상황을 만들어보자.

dev 브랜치에서 두명의 개발자가 각각의 구현기능에 대해 feat 브랜치를 만들어 개발중입니다.
feat#3 의 개발이 먼저 끝나 dev 브랜치에 머지 되었는데요. 그후 feat#4 개발이 끝나 pull request를 보내야하는 상황에서 어떻게 해야할까요?

 

 

 

이때 feat#4 를 개발하는 개발자는 dev 브랜치에서 pull 을 한다음 feat#4 branch 에서 dev 의 rebase 를 한후에 풀리퀘를 보내는 방법이 있습니다.

* merge 도 가능하지만 나는 rebase 를 사용해서 한줄로 나타내는 것을 선호한다. 물론 이는 conflict 를 고치다 커밋이 복제되기도 하지만.. merge 를 사용해서 시간대가 꼬이는 것 보다 나은 것 같다.

 

rebase 된 후 브랜치

 

위 상황을 실제로 만들어보겠습니다.

 

 

개발자 A 는 css font color 를 변경합니다. 개발자 B 는 html에 div를 2개 추가합니다.

빠른 개발자 A 는 css font color 이슈를 해결했습니다.

 

 

그럼 개발자 B 는 fork 된 local repo의 dev 를 upstream 의 dev 와 sync 를 맞춥니다.

git merge upstream/dev
git switch feat#2
git rebase dev

그 후 rebase 까지 완료한 후 pull request 를 보내는 것이죠.

 

그럼 다음과 같은 히스토리를 얻을 수 있습니다.

 

 

그럼 만약에 개발자 B가 upstream 과 sync 를 맞추지 않고 pull request 를 보내면 어떻게 될까요? 궁금하니까 해보겠습니다.

 

 

충돌이 발생할 수도 있네요. 뭐 개발자랑 협의해서 정하면되니까 그리 큰 문제는 아닐거라 생각합니다.

 

추가로 정리 할 점 

특정 브랜치에 push 못하도록 하기.

 

 

Branch protection rules 를 활용하면 특정 브랜치에 push 하지 못하게 할 수 있습니다.

다만 레포를 생성한 사람에게는 적용이 안됩니다. 만약 생성자 까지 적용하고 싶다면 Do not allow bypassing the above settings 를 선택해야합니다.

 

 

* 기존에는 husky 를 사용해서 push 를 못하도록 만들었는데, 굳이 사용할 필요가 없었다는 것을 알았다. 다만, commit 을 수행할때 lint 검사를 통과해야지 commit 이 되게끔 하고 싶을때는 husky 를 사용하면 될 것 같다.

 

Collaborators

같이 협업하는 분에게 Collaborators 를 주게 되면 리모트 레포에 바로 커밋과 push 가 가능해집니다. 또한 pull request 도 merge 가 가능해집니다.

 

 

issue 와 pull request 연결하기 , squash merge

개발자 A 는 Div 2개 작성하기 라는 issue 를 맡게 되었습니다.

 

 

풀리퀘를 등록하고 이슈를 링크 합니다.

 

 

그리고 sqaush and merge 를 선택합니다.

저는 squash merge 가 깔끔해서 더 좋아요. 작은 단위 커밋 히스토리는 pr 에서 볼 수 있고요

 

 

 

close [#이슈번호] 를 사용하면 자동으로 issue 가 닫힙니다.

 

Issue Template , PR Template 

이거는 깃허브에서 주워서 쓰려고요. ㅋㅋ 😂

 

 

 

참고자료

https://bcp0109.tistory.com/373