Peep

우린 Git-flow를 사용하고 있어요

배민에서 github으로 소스를 이전하면서 github-flow를 사용하기 시작했다.

하지만 곧 다시 git-flow로 브랜치 전략을 변경하였다.

작업 정책

JIRA 티켓 생성

하나의 티켓은 되도록 하나의 커밋

커밋 그래프는 단순하게

공유 브랜치의 커밋 그래프를 함부로 변경하지말 것

리뷰어에게 리뷰

본인의 pull request는 스스로 merge

git-flow

master 제품으로 출시될 수 있는 브랜치

develop 다음 출시 버전을 개발하는 브랜치

feature 기능 개발 브랜치

release 이번 출시 버전 준비 브랜치

hotfix 출시 버전에서 발생한 버그 수정 브랜치

브랜치가 많아졌기에 작업 시 해당 브랜치에서 작업하도록 주의한다.

정책에서 그래프를 단순하게 가져간다고하고 하나의 티켓에 하나의 커밋을 하기로 했기 때문에 squash와 rebase를 해서 그래프를 단순하게 한다.

squash, rebase 작업 전 후 비교 그래프

작업 브랜치의 수명을 짧게 가져가는 것이 좋다.

항상 git-flow로 흘러간 것은 아니지만 시행착오를 겪으며 브랜츠 전략을 더더욱 견고히했다고 한다.

예전에 읽게된 글을 다시 읽게되었다.
회사에서 flow를 재 정의하게 되었는데, 글을 읽으며 재 정의된 회사 정책과 비교할 수 있는 기회였던 것 같다.
안쓰는 기능들도 있어서 반성을 하기도 하고..
뱅크샐러드의 포스팅 '하루 1000번 배포하는 조직되기' 글과는 플로우 추구 방식이 반대이기도 하는 글이기도 해서 뱅샐의 글이 생각나면서 재미있었다. 브랜치 관리가 관건..
혹시나 2017년 글이기때문에 배민에서 플로우를 변경하지는 않았을까해서 찾아봤는데, 이후의 포스팅 콘텐츠가 없는 것으로봐서 git-flow 정착 후의 변화는 없는것 같다. 좋은 결과가 이어지고있기 때문이겠지?

원본

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

*주의 : push한 후 사용하지 말고 커밋에서 사용하셔야 충돌 및 꼬이는것을 방지한답니다.

1.커밋이 많이 쌓였을 경우

2.적용하려는 브랜치(origin/master, origin/HEAD)에 마우스 우클릭 > 자식커밋을 쌍방향 재배치(Rebase children of ..... interactively....) 

3.합칠 커밋 선택 후 이전 커밋과합치기 클릭

아래와 같아진다.

4.메세지 편집 클릭

5.커밋 텍스트 수정 후 확인 > 확인

6.합쳐진커밋확인 후 push

push 후 합쳐진 것 확인

pull 받기 전 충돌날 것 같으면 사용합니다.

1.커밋하지 않은채로 스태시 버튼 클릭

2.스태시 이름을 정해주고 확인클릭

3.스태시 하위에 내가 저장한 목록확인, 커밋해야하는 파일들 사라진것을 확인

4.Pull 받아서 최신으로 업데이트

5.스태시에서 마우스 우클릭 > 스태시 적용 클릭

6.적용 후 내가 수정했던 소스 적용된 것 확인하기.

이후 commit, push 진행 (정상적인지 파일 확인은 필수)

7.스태시 삭제

git bash에서 작업시 

1.Stash 생성
git stash 또는 git stash save

2.Stash 리스트확인
git stash list

3.Stash 적용
git stash apply 또는 git stash apply [stash이름] 또는 git stash apply --index 
// --index를 추가해야 staged상태까지 복원