[Git] 소스트리로 Git-flow 브랜치 전략 사용하기 실전편 (feat. Bitbucket pr 방법)

Git 브랜치를 관리하는 방법 중 가장 보편적으로 쓰이는 Git-flow 전략!

[참고] Git-flow 브랜치 전략

[Git] Git-flow 브랜치 전략 초간단 설명 요약!

소스트리를 이용하면 Git-flow를 커맨드가 아닌 GUI로 편리하게 사용할 수 있다

 

1. 소스트리 메뉴 -> 저장소 -> Git flow / Hg flow -> 저장소 초기화 클릭

2. 각 브랜치의 이름과 접두어를 확인하고 확인 클릭

제품 브랜치 이름을 master가 아닌 main으로 사용할 경우 초기값에서 변경을 해줘야한다

초기에는 master로 되어있는데, 현재 테스트 저장소의 제품 브랜치를 main으로 만들어둬서 main브랜치로 이름을 변경해줬다

개발 브랜치는 제품 브랜치를 기반으로 따와서 생성이 된다

기능,릴리즈,핫픽스 브랜치는 여러개가 만들어지기 때문에 접두어를 두고 그 하위에서 계속 생성해서 쓰는 것이 편리하다

(폴더 구조 처럼 feature/function1, feature/function2 이런식..)

3. 로컬에 생성된 개발 브랜치를 원격 저장소에 푸시

develop 브랜치가 생성된 것을 확인 -> 오른쪽 상단 풀 버튼 클릭 -> develop 브랜치 체크 -> 확인 클릭

4. 새 기능을 개발할 feature 브랜치 생성

1) 소스트리 상단 메뉴 -> 저장소 -> Git flow / Hg flow -> 새 기능 시작 클릭

2) 기능 이름 작성 -> 확인 클릭

3) 로컬에 기능 브랜치가 생성된 것을 확인할 수 있다

5. 기능 개발이 완료됐을 때

1) feature 브랜치 개발 완료 후 원격 저장소에 푸시

변경사항 스테이지에 올리기 -> 커밋 메시지 작성 후 커밋 (원격 저장소에 바로 푸시하려면 좌측 즉시 푸시 체크박스 선택)

2) 좌측 메뉴 -> Branches -> push 한 feature 브랜치 Pull request에 Create 버튼 클릭

3) merge 할 branch 선택 , Reviewers 선택, Delete branch 옵션 선택 후 Create pull request 버튼 클릭

Create a pull request 하단 좌측에 feature 브랜치 확인

우측에 merger 하고 싶은 branch 선택 => 기능 개발이 완료 됐으므로 git flow에 따라 "develop" 브랜치에 병합해야함~!

Reviewers는 여러명 선택 가능

feature 브랜치는 원격 저장소에 남겨두지 않고 삭제하는 것이 깔끔하다 (원하는 방식 또는 소속된 팀의 정책을 따르면 됨)

4) PR 받은 사람 입장 :: 코드 확인 및 코멘트 작성, Approve 해주기

좌측 메뉴 -> Pull requests -> pr 확인 가능

하단에 변경된 파일 목록이 나오고 diff를 확인해볼 수 있다

말풍선 버튼을 누를 경우 코멘트를 달아줄 수도 있다

개선사항 등에 대해 코멘트를 달아주고 다시 수정하고 pr을 달라고 할 수도 있다

코드를 승인해주려면 Approve 버튼을 클릭!

(자세한 내용은 추후 별도 포스팅을 해보겠어요 일단은 진행을 해야하니까요!)

5) PR 받은 사람 입장 ::  Approve 클릭 시 우측 리뷰어에 초록불이 들어오는 것 확인 가능

6) PR 요청한 사람 입장 :: 리뷰어들이 승인을 해주면 Merge 버튼을 눌러 병합 진행

좌측 메뉴 -> Pull requests -> Merge 버튼 클릭 -> Merge pull request 창이 열리면 Commit message 확인 후 merge 클릭

7) Commits 메뉴에 들어가보면 브랜치 그래프가 합쳐진 것 확인 가능

8) 소스트리에서 develop 브랜치로 체크아웃 한 후 풀 버튼 클릭

feature 브랜치가 merge 된 것을 확인 할 수 있다

이제 새로운 기능 개발을 하려면 병합된 최신 develop 브랜치에서 따와서 기능을 개발한다

9) 로컬에 있는 feature 브랜치는 삭제를 해도 좋고 보존을 해도 좋다

 

# feature 에서 develop으로 갈 때 PR을 이용하기로 했다면 git flow -> 기능 마무리 기능은 사용하기 어렵다

기능 마무리를 사용했을 때 승인없이 바로 develop 브랜치에 병합되기 떄문이다

개인적으로 PR을 이용해서 승인을 받은 후 병합 작업을 진행하고, 원격 develop을 pull 하는 것을 선호한다

6. 모든 기능 개발 완료 후 릴리즈 브랜치 생성(최종 테스트와 그에 따른 버그 fix 만을 목적으로 함)

1) 저장소 -> Git flow / Hg flow -> 새 릴리즈 시작

2) 릴리즈 버전 작성 후 확인 클릭

[Major].[Minor].[Patch]

앞부분은 MAJOR 버전을 의미 : 이전 버전과 호환되지 않는 변경, 삭제 건

가운데는 MINOR 버전을 의미 : 이전 버전과 호환이 되는 추가,변경 건

끝은 PATCH 버전을 의미 : 버그 수정

7. 릴리즈 브랜치 마무리 (develop, main에 병합 및 태그 생성)

1) 저장소 -> Git flow / Hg flow -> 릴리즈 마무리 클릭 (이제는 캡쳐가 없어도 외우셨을 듯 합니다)

2) 태그 내용을 작성 하고 확인 클릭

3) 로컬에서 병합, 태그 생성 확인 후 원격저장소에 푸시

정책적으로 release에서 테스트 완료 후 운영서버에 반영 전에도 PR을 이용하여 develop과 main에 merge 하기로 결정했다면 이때도 릴리즈 마무리 기능을 이용하기는 어려운 것으로 보인다

릴리즈 완료 후 한 명의 담당자가 릴리즈 마무리 책임을 가지고 작업을 하면 해당 기능으로 편리하게 작업을 할 수도 있고, 한 땀 한 땀 소중하게 작업을 할 수도 있으므로 정책을 잘 정하고 따르면 된다고 생각한다!

 

핫픽스 브랜치를 시작하는 것도 다른 브랜치를 만드는 것과 동일하므로 설명은 생략한다

브랜치 전략을 사용할때는 각 브랜치의 용도와 목적을 항상 염두에 두고 사용하면 성공적으로 관리할 수 있을 것이다

핫픽스는 상용 서비스에서 긴급하게 수정되야하는 이슈가 있을 경우 main 브랜치에서 따와서 수정건을 반영한다

핫픽스 브랜치 또한 태그를 따는 것이 좋다

 

어쩌다보니 장황한 포스팅이 되어버렸...지만! 이정도만 숙지하고 있어도 실제 업무에서 깃 브랜치를 사용하는 것에는 무리가 없을 것으로 생각한다!!

 

모두모두 즐거운 개발하시고 복 많이 받으십시오!