다음으로는 브랜치를 관리하는 방법에 대해 작성해보자.
이 포스팅은 작업을 하는 동안에 commit하는 방법등도 작업에 순서에 맞춰 작성되고 있으니 찬찬히 읽어보시길.
또 혹시 이것을 보는 사람은 develop브랜치의 역할, main 브랜치의 역할, 등등 아주 기초적인 설계가 모르는 사람이 읽을경우가 있을 수 있으니 먼저 간단하게 거기서 부터 정리하면서 이어나가겠다.
처음에 프로젝트를 생성하면 main(master)라는 브랜치가 만들어진다. (참고로 master라는 이름은 주인과 노예를 연상케 해서 만약 master라고 자동 생성이 되었다면 main으로 바꾸도록 하자)
이 브랜치는 우리가 구글 플레이스토어나 앱 스토어 등에 출시가 되었을때 이 곳에 최종으로 모인 후 이 코드로 출시를 하는것이기 때문에 마지막에 마지막에 마지막에 마지막인 원기옥 같은 것이니 개발중일때는 전혀 이곳으로 모이지 않는다!!
이제 main브랜치에서 develop 브랜치를 생성한다. 이 브랜치는 우리가 작업하여 나오는 결과물이 모이는 곳이다. 사실 이곳이 우리의 정수이자 액기스이다.
이제 우리는 이슈에 따라서 브랜치를 만들어 개발한다. 이런 브랜치를 합쳐서 feature브랜치라 부른다.
그럴때 브랜치의 이름을 어떻게 지을까? 이름은 main,develop이런 이름만 제외한다면 무엇이든 될 수 있다. 하지만 내가 배웠던 규칙은 다음과 같다.
이슈번호/이슈이름/(세부기능)
예시로 들자면 아래와 같다. 참고로 이슈번호는 이슈를 만들고 나면 자동으로 번호를 발급받게 된다. 브랜치 이름은 이슈의 이름과 동일시 가면된다.그러니 이슈번호는 너무 포괄적이지 않고 적당히 큰 범위로 하면 된는데 이슈는 대부분 기능어느정도 하나의 기능으로 잡아준다.(ex 카카오 로그인)
자 이제 브랜치 이름까지 획일화 하여 만들었다. 이제 우리는 코드를 작성하며 작업을 하면 된다. 수정도 좋고, 버그잡는것도 좋고, 등등...
대신 알아야 할것은 우리의 작업에도 약간의 약속을 해야 한다.
그것은 커밋을 잘게 쪼개 주어야 하는 것이다.
이게 무슨 말이냐면....
만약 우리는 이슈를 '구글 로그인 기능 개발'이란 것으로 설계했다.(예를 들어 이슈번호를 #6을 부여받았다)
그렇다면 우리의 브랜치를 '#6 googlelogin_logic' 이란 브랜치가 생성한다.
이후 우리는 구글 로그인 기능을 개발하기 위해 다양한 작업을 수행할 것이다.
구글 로그인 UI 추가
퍼미션 추가
구글 Auth신청후 secret 추가
로그인 로직 만들기
UI와 기능 연결....등등
위와 같이 다양한 작업을 수행하는데 위의 작업도 더 잘게 쪼갤 수 있다. 예를들면 '로그인 로직 만들기'에서 버튼을 눌렀을때 리소스 서버에 연결하기, 자동로그인기능만들기 등등 이러한 작업을 commit에 잘게잘게 추가해주는 것이 좋다.이러한 이유는 나중에 우리가 깃허브에서 PR(Pull/Request = 다음부터 PR이라 부르겠다. 다들 그렇게 부르니까)를 볼때나 이전작업을 보고 싶을때 등 협업하는 사람들이 보는데 편하다. 커밋메세지를 보내는 방법도 정하기 나름이지만 우리는 아래와 같이 정했다.
중요한 것은 앞에 #이슈번호 를 작성하면 아래 오른쪽 사진과 같이 숫자가 활성화되며 해당 이슈로 바로 넘어간다.
또 커밋메세지에서 한칸 가리고 싶을때는 한칸 띄면 아래 오른쪽 사진과 같이 (...)으로 가려져 한눈에 보기 쉽다.
#이슈번호 이슈이름/세부기능 : 하위내용 포괄 이름(~=세부기능)
- 로그인 API 개발
자 여기까지 왔다면 당신은 깃허브 커밋에서 욕먹지는 않을거다.
이제 마지막 한단계
push - PR - merge 이다.
먼저 push는 깃허브에 올리는 단계이고 나의 이슈에서 잘게나눈 모든 커밋을 깃허브에 올리는 작업을 한다.
우리는 푸쉬를 한게 된다면 우리가 나왔던 줄기에게 push를 보내게 된다.
우리가 push를 했다면 아래와 같이 노란바가 생기면 PR(Pull/Request)가 생길 것 이다. 이제 PR단계로 진입한 것이다.
여기서 Compare/pull request를 누르게 된다면 아래와 같은 모습이 되는데 본문에 작성하는 것은 회의를 통해 템플릿을 설정해 놓는다면 또 협업할때 깨끗하게 정리할 수 있다....!! 나는 Reviewers와 Assigggnees만 채운다.
이렇게 올리면 사람들은 코멘트를 달아주는데 코멘트 후 멀지를 하면 아래 그림과 같은 형태로 나오게 된다.
추가로 중요한 한가지가 있다.
그것은 아래 그림과 같이 우리가 하나의 브랜치에서 또하나의 브랜치가 생겨 작업하는 상황이 생긴다.
그럴때 두개의 브랜치가 merge를 하게 되면 두개의 코드가 달라 충돌이 일어날 수 있다..!!(그렇게 되면 코드 한줄한줄 보며 바꿔줘야 하는 아주 귀찮은 상황이 연출 된다.)
이럴때 우리는 먼저 develop에 merge를 한 것을 땡겨와 우리의 것에서 충돌 나는 부분을 고친 후 push를 하면 비교전 전 상황 보다 덜 귀찮은 상황이 연출 될 수 있다.
그러니 우리는 push전 바뀐 develop이 있다면 반드시 pull로 땡겨 바꾼후 push를 하도록 하자!!
이렇게 브랜치를 따서 팀원들과 협업하는 과정을 작성해보았다.
이 글을 보는 사람들은 칭구들과 잘 협업하는 개발자가 되어 칭구들을 잘 사귀는 개발자가 되길 바란다.
'잡다한 글들.... > 협업 스킬' 카테고리의 다른 글
| 플러그인 GitToolBox (0) | 2023.04.19 |
|---|---|
| 깃허브를 200% 사용해보자~(1. 이슈관리를 해보자) (0) | 2022.09.09 |
| 코딩 컨벤션을 맞춰보자~ (0) | 2022.09.08 |
