티스토리 뷰

보통 회사들에서 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 사용)

PR 머지버튼
CHANGELOG.md 파일

그래서 우리팀에선 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
댓글
최근에 올라온 글
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30