티스토리 뷰
보통 회사들에서 git branch전략으로 git flow를 사용하는데 자세한 정보는 많으니 git flow에 대한 얘기는 패스하고
우리 팀에선 git flow를 기반으로 좀 더 깔끔하게 브랜치 관리를 하기위해 노력하는데 거기에 대해 얘기해볼까 한다
보통 팀들의 브랜치는 요런식으로 관리될 것이다
여러 브랜치들이 여기저기 머지되어있고 커밋히스토리도
- xx이슈 수정
- 오타수정
- pr리뷰 반영
- Merge branch 'feat/~~' into develop
등등 불필요한 커밋 내역들이 그대로 남아있다
우리팀에선 rebase와 squash 머지 전략을 적절히 사용하여 브랜치를 깔끔하게 사용하고 있다
github pr에서 머지를 할 때 3개의 옵션이 있다
1. 머지커밋 만들기
2. 스쿼시 머지하기
3. 리베이스 머지하기
머지커밋을 할 경우 Merge branch 'feat/~~' into develop 등등의 커밋이 따로 남고 해당 pr의 모든 커밋 내역들이 기록된다
스쿼시 머지를 할 경우 아래와 같이 여러개의 커밋이 하나의 커밋으로 머지가 된다
또한 뒤에 pr 번호가 붙기때문에 changelog에 해당 커밋과 pr 링크가 자동으로 달리게 된다
그래서 스쿼시 머지를 사용하여 해당커밋이 어떤 피쳐를 만든 것인지/어떤 이슈를 수정한 것인지 한줄로 설명하고
그에 따른 내역들은 해당 pr에 들어가서 확인하면 된다 (커밋메세지 스타일은 commitizen 사용)
그래서 우리팀에선 feature/hotfix to develop을 할때는 squash를 사용하고
develop to master를 할때엔 rebase를 사용하여 깔끔하게 브랜치를 유지할 수 있다
이렇게만 해도 불필요한 커밋 메세지들이 많이 줄어들고
한줄로 깔끔하게 커밋 히스토리 관리가 가능하다
본인의 오타나 실수를 숨기기위해선
git commit -ammend (빠트린 내용을 직전 커밋에 같이 포함하고 싶을 때)
git rebase -i HEAD~{n} 의
fixup(현재 커밋을 직전 커밋과 합치고 직전 커밋메세지를 사용할 때)
reword(커밋메세지를 수정하고 싶을때)
squash(현재 커밋을 직전 커밋과 합치고 커밋 메세지도 수정하고 싶을 때)
등이 유용하게 쓰일테니 알아두면 유용하게 쓸 수 있다
(포스푸쉬를 해야하기 때문에 한 브랜치를 한명만 사용하는게 안전하다)
끝!
'프로그래밍 > git' 카테고리의 다른 글
[git] Cherry pick (0) | 2018.07.23 |
---|---|
[git] bisect - 버그 원인, 시점찾기 (0) | 2018.07.23 |
[git] Reset vs Revert (0) | 2018.07.23 |
[git] Stashing (0) | 2018.07.23 |
[git] Squash - 여러개의 커밋을 하나로 (0) | 2018.07.23 |