[2주 프로젝트][회고]기록 남기기 #4

브랜치의 늪

회고글 쓸 때마다 이야기하는 것 같다. 하루하루가 어떻게 가는지.

이런 생각할 때마다 기록이란게 이럴 때 빛을 발하는 것 같다. 

 

오늘은 어제부터 깃 브랜치(Git Branch) 이슈가 발목을 잡았다. 

이슈 내용은 2가지다. 

 

첫째, Gitflow를 어떻게 구성할지 잘 모르겠다.

페이지 별 브랜치를 생성해서 각 페이지 브랜치에서 각 feature 브랜치를 생성해야 할지(ex1)

아니면 dev 브랜치에서 feature 브랜치를 생성해야 할지(ex2)

(ex1) master -> dev -> mainPage -> featureN

(ex2) master -> dev -> mainPage

 

=> 팀원과의 깊은 토의 끝에 ex2 깃 플로우로 하기로 선택하였다. 

그 이유는 2가지가 있다.

먼저, 필자는 클라이언트 파트를 맡았다. 클라이언트 각 팀원(2명)이 각 페이지를 맡기로 하였고 페이지마다 겹치는 부분(ex. layout, button...)은 협업을 통해 풀어나가는 방법은 선택하였다.

 

1) 위 같은 협업 방법에서 ex1과 ex2 방식 어느 것으로 하던 merge를 하게 되면 conflict가 당연히 날 거라고 생각을 했다. 왜냐하면 페이지마다 겹치는 기능 혹은 컴포넌트들이 존재하기에 conflict는 필연적이라고 생각했고 그때마다 resolve를 해주면 큰 문제는 없다고 판단하였다.   

 

2) ex1과 ex2 두 가지 방식으로 깃 플로우 구성했다고 가정해보자. 이 두 방식 어느 방식이 브랜치 개수가 더 많을까? 

아마 ex1이라고 생각한다. 그 이유는 ex1이 각 페이지마다 존재하는 기능 개수만큼 브랜치를 생성해야 하기 때문이다. 브랜치가 많으면 많을수록 관리도 힘들어 질뿐더러 나(혹은 우리 팀)같이 terminal로 깃을 사용하는 사람들은 이동할 때마다 그 많은 브랜치를 이동하려면 이동하다가 진이 빠질 것이다. 

 

이런 이유로 ex1 방식으로 깃 플로우를 짜게 되었다!

 

둘째, 브랜치 계층 구조에 구축 방법을 잘 모르겠다.

특정 브랜치로 이동해서 또다른 브랜치를 생성하는 동작이 브랜치 계층 구조(hierarchy)가 아닐까 했다. 

하지만, 헬프데스크 질문에 답변을 보고 그게 아니구나 라고 알게 되었다.

 

답변#1

안녕하세요. @JuicyJerry 님!
git branch들이 레벨로 나뉘어 있다고 보시기보다는 flow로 보심이 좋습니다. git show-branch는 트리를 볼 수 있는 명령어가 아니라 브랜치에 연결된 커밋을 볼 수 있는 명령어입니다 :)
위 명령어에 대한 부분은 공식문서를 참조하시면 더 좋습니다!
만약 git branch의 flow를 보시고자한다면 레포로 가신 후, insights로 들어가셔서 Network를 보시면 좀 더 이해가 쉬우실 것 같습니다.

 

답변#2

@JuicyJerry 님 안녕하세요!
깃은 프로젝트의 버전을 한 줄기로 시작해서 여러 가지들(branch가 되겠죠?)의 코드를 이어 받아서 더 발전된 버전으로 만들어주는 도구라고 생각하시면 좋을 것 같아요! 그래서 단순한 흐름이라기보다는 버전업을 위한 branch로의 계층 구분을 진행하고 한 버전에 merge 한다는 개념으로 생각하시면 좋을 것 같습니다!

 

=> 브랜치로 분기하는 것은 level별이 아닌 전략적으로 디자인된 git work flow 모델이다. 라고 이해를 했다.

 

 

 

 

세상에 첫 포를 쏴올렸다.

: 첫 배포 성공

 

우리 팀 백엔드 담당 팀원께서 어제 배포 때문에 고생하고 배포 관련 이슈도 해결하더니 첫 배포를 시원하게 쏴주셨다! 

우리 팀은 기념으로 다 같이 박수를 쳤다. 짝짝짝!!! 

 

 

 

내일 업무

팀원 1
1. mypage 레이아웃 구현
2. 토글, 각종 버튼 구현


팀원 2
1. 로컬상에서 DB 각 테이블에 seed file 추가 후 조회 테스트
2. 각 api의 역할 수도 코드 작성 (rds에서 무엇을 가져오고)
3. userInfo table 관련 이슈 해결 및 이슈 카드 발급, api 수정
4. 로그인 방식 구현 공부(헬프데스크, 수도 코드 작성)
5. config.json : env - test로 export로 진행

팀원 3
1. 내일 스탠드업 미팅 안건 준비 및 전달 
2. 전날 회고 진행하기 
3. 프로젝트 상황 보고 
4. 위키 내용 추가하기 (클라이언트 레포지토리)
5. mainpage 레이아웃 구현
6, 브랜치 이슈 해결하기 
7. 팀원 1과 레이아웃 설계 및 기능 설계(css) 
8. schema 수정(userInfo 테이블 삭제)