마침 이슈도 생겼었으니 오늘은 브랜치 관리에 대해 정리해보고자 한다.

만약 혼자서 과제를 하는 상황이라고 가정해보자. 과제에서 요구한 구현 사항을 한번에 만들 수 없을 거라고 생각해서 여러번 시도를 해보고 커밋하며 완성해가고 있었다. 그러다 실패하면 커밋 이전으로 되돌리고 싶지만, 너무 많은 정리되지 않은 지저분한 내용의 로그들이 생길 거 같다.

다른 사람들과 함께 프로젝트를 하고 있는 상황이라고 해보자. 깃허브에 있는 코드를 각자의 로컬로 가져와 작업하고 있다. 한 파일을 둘 이상이 동시에 작업하고 commit 하고 원격에 push 해버리면? 뒤죽 박죽,,, 충돌이 날 것이다. 각각 한 작업이 서로에게 없을 것이며 깃허브 서버는 뭐가 올바른 작업 내용인지 알 수 없다.

위와 같은 상황들을 방지하기 위해 branch라는 기능을 이용할 수 있다!

브랜치 관리란

브랜치 관리 전략

어떤 사람은 버그를 수정하기도 하고, 어떤 사람은 새로운 기능을 구현하기도 한다. 동시에 여러 작업들을 할 수 있도록 브랜치를 사용하는 것이며 운영방식의 효율성을 높이기 위해 잘 정리된 브랜치 관리 전략을 짜면 좋다.

정해진 브랜치 관리 방법이 있는 건 아니지만 참고하면 좋은 브랜치 관리 전략들이 존재한다!

git flow

= git workflow

일종의 협업 개발 원칙
여러 기본 브랜치를 사용하는 대중적인 git 브랜치 모델을 의미한다.
프로젝트를 효율적으로 관리하기 위해 master, develop, feature, release, hotfix 라는 종류로 브랜치를 구분한다.

위 구조를 대충 분석해보자면,,,
feature 에서 새로운 기능을 개발하고 -> 기능 개발이 끝나면 develop 브랜치에 merge -> 배포 준비가 완료되면 develop 브랜치를 release 브랜치로 merge -> 최종 release 상태의 내용을 master로 merge 하고 버전 표시하기
가 일반적인 과정 같고 이 과정에서 중요한 버그가 발생하면 hotfix 브랜치에서 작업 후 해당하는 브랜치로 이동시켜 작업

master : 최종 배포할 서비스 내용의 브랜치, 태그로 버전을 표시
develop : 주요 개발 브랜치, 이 브랜치를 기준으로 각자 작업한 기능을 Merge
feature : 기능 개발 브랜치, 기능 개발이 완료되면 develop 브랜치에 Merge
release : 최종 배포 master 브랜치 전 QA(품질검사)를 하기위한 브랜치
hotfix : master 브랜치로 배포 후에 버그가 생겼을 떄 긴급 수정하는 브랜치

*master와 develop이 중요한 메인 브랜치

github flow

git-flow 가 깃허브에서 쓰기엔 복잡하대서 나온 브랜치 전략
hotfix, feature, develop 등 브랜치를 구분하지 않음. 수시로 배포가 일어남.
배포 자동화된 프로젝트에 유용

git flow 보다 master의 상태가 중요하다. stable, 최신의 상태를 유지해야하고 테스트를 충분히 거친 상태여야한다.
깃 플로우와 다르게 이런 저런 브랜치들이 없기 때문에 새 기능 추가, 버그 해결 등을 위한 다양한 브랜치들을 마스터 브랜치에서 만들고, 자세하게 이름을 명시해줘야한다. 또한 커밋메세지를 확실하게 써야하는 이유가 이거겠지. 왜 컨벤션이 중요한지에 대한 이유도 되겠군.

모든 과정 돌아돌아돌아 완성된 것만 브랜치에 올리는 것이 아닌 최신의 상태 유지를 위해 수시로 Push할 것.
PR 기능을 통해 리뷰와 피드백 받기를 요구할 것.
github flow 의 핵심 - master로 push, merge 했을 땐 즉시 배포될 것

브랜치 관리가 필요한 이유

초반에 들었던 상황을 해결하기 위한 방안을 들며 필요한 이유를 정리해보겠다.

팀원이 여러명 있는 경우 동시 작업을 위해 master 브랜치에서 개발을 진행하면 위와 같은 문제 발생 가능.
각각의 브랜치를 만들고 자신의 branch에 맡은 부분의 개발을 진행한다.
이후 개인이 작업한 내용을 master에 merge하거나, 브랜치끼리 merge 하여 합치면 수월하다.

또한 프로젝트를 진행할 때 master branch 에서 작업하다 문제가 발생하면 전체 프로젝트를 다시 검토하며 복구해야하기 때문에 비효율적이다. 하지만 브랜치를 나누어 수행하면 재검토할 영역을 구분하기 쉬움.

결론: 협업할 때 효율적이고 편리하게 작업을 진행할 수 있기에 용도와 역할이 적절히 나누어진 branch를 활용하는 것이 좋음!

Shoveling repo 브랜치 운영 계획

+)2022.12.08 이슈 상황 정리

전날 day3 코테 문제를 풀고 리뷰를 위해 Pr을 남겨놓았음. 그리고 그날 저녁 리뷰어가 확인하지 않은 상태로 merge 전으루 남겨져있던 나의 Pr...
다음날 아침 day4 두문제를 풀어서 미리 커밋, 푸시를 했더니 리뷰어가 approve 하면서 day3과 day4가 함께 day3의 PR 내용으로 merge 되버렸다.

이 상황에 대한 해결책을 생각하는 과정에서 브랜치 관리를 왜하는지 전략이 왜 필요한지에 대해 이해가 확실하게 되어서 질문하기 잘했다는 생각이 들었다 ㅎ 생각하다보니 왜 저런 바보 같은 질문을 했지 싶기도 했음 ㅎㅎ

저 상황들에 대해 내가 냈던 해결책은!

실제 프로젝트 상황인 경우 1번처럼 상황 해결을 위해 새 브랜치들을 생성하고 역할을 확실하게 구분하는게 좋겠다.
github flow 을 정리하면서 더더욱 그러는게 맞다는 판단이 섰음.

또한 2번같은 경우엔 내가 풀었는데 푸시하지 않고 걍 기다리고 있는거니까 작업 병목현상이 생긴다는 문제점이 생긴다. 하지만 머 간단한 코테 문제들을 풀고 있는 상황이고 지금 이것도 업로드하는 과정에서 브랜치 나누는 작업을 올리는거에 익숙해지는 연습을 하던 것이니 2번에서 약간의 베리에이션을 주어...

이번 문제같은 상황들의 해결책으로는...~

draft PR 기능을 사용해서 리뷰받고 싶은 작업을 모두 push했을 때 기본 PR로 돌리기로 했다.
끗 아름다운 마무리😀

운영 방식 정리

아직 프로젝트나 기능 구현을 공부하고 있지 않은 상황에서 만들어둔 브랜치들이다.

스터디 자료들과 관련된 공부 내용이 있으면 각 카테고리에 해당하는 브랜치에 올리고, 리뷰어에게 리뷰를 받고 업로드하는 방식으로 운영한다.

만약 프로젝트 및 구현하는 과제가 나온다면 그 때는 관련된 브랜치를 생성해서 운영해보면 좋을 거 같다. 그건 아직 해보지 않았으니... 하게 된다면 이곳에 추가하겠당 ><