Git Branching Model - aragorn/home GitHub Wiki

기본 정책

일반적인 Git Branching Model 로 사용되는 gitflow 를 차용한다.

• gitflow 모델에 대해서는 다음의 외부 자료를 참고하면 된다.
  • http://nvie.com/posts/a-successful-git-branching-model/
  • https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
• gitflow 를 간단히 요약하면, 다음과 같은 workflow 를 갖는다.
  • develop branch: 개발 버전의 기능들을 하나로 묶은 브랜치이다.
  • feature/* branch: 개발은 주로 기능 단위로 feature namespace 아래의 브랜치를 생성하여 진행한다. 해당 개발이 완료되면, 통합 테스트를 위해 develop 에 merge 한다.
  • release/* branch: 소프트웨어를 릴리즈, 배포하기 위한 통합 테스트, QA 테스트용 브랜치이다. develop branch 의 어느 지점을 release namespace 아래의 브랜치로 가른다. 테스트 과정의 오류 수정이 완료되면, 릴리즈 브랜치를 종료하게 되며, 종료된 릴리즈 브랜치는 master 에 merge 된다. release branch 에서 추가적으로 수정된 commit 이 있다면, release finish 과정에서 이 commit 은 develop 으로 merge 된다.
    • <!> 구매하기 개발 과정에서는 release branch 를 실질적으로 사용하지 않고 있다. develop branch 가 release branch 를 대체한다. 그러나 SourceTree http://www.sourcetreeapp.com/ 와 같은 도구의 gitflow 관리 기능을 그대로 사용하기 위해 release branch 를 생성하는 과정은 적용한다.
  • master branch: 릴리즈를 위한 안정된 버전의 브랜치이다.
  • hotfix/* branch: 이미 릴리즈된 소프트웨어의 오류 수정을 위해 사용하는 브랜치이다. hotfix branch 의 작업을 완료하면, master, develop 모두에 merge 된다.

카카오 개발/테스트 환경에 맞추어 alpha, sandbox, beta stage 에 대응하는 branch 를 사용한다.

• alpha, sandbox, beta stage 의 용도가 개발버전 테스트, QA 테스트 등 개발 프로세스 단계 또는 릴리즈 프로세스에 따른 단계와 일치하지 않는다.
  • alpha, sandbox 은 분리된 카카오톡 계정, 카카오계정 시스템을 갖고 있으며, 연계된 사내 API 도 모두 분리되어 있다.
  • 선물하기, 핀테크 등 관련 팀의 기능 테스트를 위해 alpha, sandbox, beta stage 의 구매하기를 제공해야 하는 때도 종종 발생한다.
• develop branch 외에 alpha, sandbox branch 를 두고, 각각 alpha stage, sandbox stage 의 구매하기에 배포한다.
  • alpha, sandbox 에 배포하기를 원하는 기능이 있으면, 배포서버의 브랜치를 변경하지 않고, alpha, sandbox 브랜치에 해당 기능을 merge 한 후, alpha, sandbox 브랜치를 배포한다.
• beta stage 는 필요에 따라 배포할 브랜치를 선택하여 배포하는 기존 방식을 유지한다.
  • hotfix, master, develop 브랜치를 필요에 따라 선택한 후 배포하는 것이 기존 방식이다.

develop, release, master 의 release workflow 는 gitflow 를 유지한다.

• alpha, sandbox branch 는 해당하는 테스트 stage 에서의 배포를 위해 사용한다.
• develop - release - master branch 를 사용하는 gitflow 기반의 release workflow 는 gitflow 를 그대로 유지한다.
• beta stage 는 보통 develop branch 를 배포한다.
  • 필요에 따라 hotfix branch 또는 다른 브랜치를 배포할 수 있다.
• production 에는 예외 상황이 아니면, master branch 를 배포한다.
  • rollback 이 필요한 예외 상황의 경우, master branch 가 아닌 branch, tag 를 배포할 수 있다.

주의사항과 FAQ

sandbox, alpha 브랜치에 직접 commit 한 코드는 develop 으로 넘어가지 않습니다.

• 코드를 수정, 커밋하는 브랜치는 보통 feature, hotfix 의 브랜치입니다.
• sandbox, alpha 브랜치는 테스트 환경에 작업 중인 코드를 배포하기 위한 임시적인 병합용 브랜치입니다. sandbox, alpha 브랜치에서 수정된 사항은 release workflow 에 따라 develop 으로 merge 되는 경로가 없습니다. 따라서 모든 수정사항은 결국 무시되게 됩니다.
• sandbox, alpha 브랜치에는 배포되면 곤란한 불안정한 코드가 mege 되어 있을 수 있습니다. QA 테스트를 거쳤다 하더라도, 물리 DB 모델 수정 등의 이슈가 있기에, sandbox, alpha 브랜치의 코드가 곧바로 develop, master 로 배포될 경우, 오류나 장애가 발생할 수 있습니다. 개별 feature 브랜치의 개발자와 상의하여 어느 feature 브랜치가 develop, master 로 릴리즈되어도 되는지 확인하고, feature 를 '완료'(finish) 하여 release workflow 를 따르는 것이 좋습니다.
• 간단히 요약하면, feature 브랜치가 sandbox, alpha 브랜치로 merge 되는 일은 개발 도중 자연스러운 일입니다. 그러나, sandbox 브랜치를 feature 나 develop 으로 merge 하는 경우는 발생하지 않는 것이 좋습니다.

branch 를 merge할 때 conflict 가 발생합니다. 어떻게 해결하는 것이 좋을까요?

branch merge 과정에서 conflict 가 발생한 경우, 다음과 같은 충돌 해소 방법이 있습니다.

A유형: feature X 브랜치에서 develop 브랜치를 merge 하는 도중, 충돌이 발생한 경우

• 현재 branch 가 feature 브랜치인 경우입니다. merge 중인 working copy 에서 충돌을 해소한 후, commit, push 하여 문제를 해결한 코드가 feature 에 반영됩니다.
• 이후 해당 feature 를 finish 하게 되면, 충돌이 발생하지 않게 됩니다.

B유형: feature Y 브랜치를 finish 하여 develop 으로 merge하는 도중, 충돌이 발생한 경우

• feature 개발 기간 중에, develop 브랜치에 다른 수정사항이 commit 되어 충돌이 발생하는 것입니다. merge 관점에서 본다면, develop 에서 feature Y 를 merge 하는 도중 충돌이 발생하는 것입니다.
• 이렇게 충돌이 발생하면, 먼저 현재 local PC 에 작업 중인 feature 브랜치, develop 브랜치를 모두 reset 하거나 delete 합니다. reset 이 깨끗하게 정리되지 않으면 잘못된 merge 로 조용히 코드가 유실되는 경우가 있기에 조심해야 합니다. SourceTree 에서 reset 하는 경우, 깨끗하게 reset 되지 않는 경우가 가끔 발생하는 것으로 보이니, 가능하면 작업 중이던 local branch 를 delete 하는 것이 좋습니다.
• origin 에서 feature branch, develop branch 를 다시 pull 합니다. 이 상태는 feature 브랜치를 finish 하기 직전의 상태와 동일합니다.
  • 이제 develop 브랜치를 feature 브랜치로 merge 하는 A유형 프로세스를 진행합니다. 이때 충돌을 해소한 후, 다시 feature finish 를 시도하면, 충돌 없이 merge 됩니다.
• 그러나 code 의 충돌이 없다고 하여도, semantic error 또는 logical error 가 발생할 수 있으므로, feature 를 finish 하기 전에 적절한 테스트를 진행하는 것이 좋습니다.

C유형: feature X와 feature Y가 각자 개발을 진행되는 도중, alpha 나 sandbox 브랜치에 merge 하면서 충돌이 발생한 경우

• B유형과 충돌 상황은 유사하지만, 조금 다르게 접근해야 합니다. B유형 충돌에서는 A유형으로 전환한 후, 충돌을 해소해야 합니다. 그러나 이 경우는 alpha, sandbox 브랜치와 충돌하는 것이고, alpha, sandbox 브랜치는 feature 들의 integration test 를 위해 사용하는 임시적인 브랜치입니다. alpha, sandbox 브랜치를 feature 로 merge 하는 것은 불필요한 개발/테스트용 코드가 feature 에 유입되기 때문에 적당하지 않습니다. 따라서 A유형과 비슷하게 문제를 해결할 수 없습니다.
• 이 경우에는 아래 D유형 또는 E유형의 해결 방법을 적용하는 것이 좋습니다.

D유형: 먼저 릴리즈할 feature X와 나중에 릴리즈할 feature Y를 각자 개발하는 도중, alpha 나 sandbox 브랜치에 merge 하면서 충돌이 발생한 경우

• feature X 를 먼저 릴리즈할 것이고, 거의 개발을 완료한 경우라면, feature Y 에서 feature X 를 merge 하며, 충돌을 해소합니다. conflict 를 수정한 코드는 feature Y 에 commit 됩니다.
• feature X 를 먼저 finish 하여 develop 으로 merge 할 것이고, 이후 feature Y 를 finish 할 때, 충돌이 해소된 상태로 자동 merge 될 것입니다.

E유형: 어느 것이 먼저 릴리즈될 것인지 알 수 없는 feature X, feature Y 가 각자 개발을 진행하는 도중, alpha 나 sandbox 브랜치에 merge 하면서 충돌이 발생한 경우

• D유형으로 치환하여 처리할 수 없다면, feature X, feature Y 를 각자 잘 수정 commit 하여, merge 과정에서 충돌이 발생하지 않도록 만듭니다. 보통은 A유형이나 D유형으로 문제를 전환하여 해결하였고, 병합 테스트용 local branch 를 만든 후, conflict 를 해결하고, cherry pick commit 을 만드는 방법 등이 있을 것 같은데.. 실제로 시도해 보지는 못했습니다.

conflict 를 해결할 때, 두 소스파일을 비교할 때 너무 헷갈려요.

SourceTree 에 함께 배포되는 External Merge Tool 을 이용하면 소스파일을 편리하게 비교할 수 있습니다.

1. SourceTree 에서 branch merge 를 시도할 때, Conflict 가 발생한 소스파일을 선택한 후, Actions -> Resolve Conflict -> Launch External Merge Tool 을 선택합니다.

• 

2. FileMerge 라는 외부 툴이 실행되며, 파일을 비교할 수 있습니다. 파일 비교창의 내용을 간단히 설명하면 아래와 같습니다.

• 왼쪽 상단에는 현재 작업 중인 branch 의 소스파일을 보여줍니다.
• 오른쪽 상단에는 merge 로 가져올 branch 의 소스파일을 보여줍니다.
• 아래 쪽 화면은 conflict 를 해소하도록 두 소스파일을 병합한 결과 파일을 보여줍니다.
• 오른쪽 스크롤바에서 가로줄이 그어진 부분이 병합할 코드가 위치한 곳입니다. 회색은 단순 병합이 가능한 곳이고, 빨간색은 충돌이 발생한 곳입니다.
• 

3. 파일 병합 요령은 다음과 같습니다.

• 병합 대상이 되는 코드의 블럭이 상단 좌우 사이에 서로 연결된 영역이 있습니다. 이 가운데 창 부분을 선택하면, 그 영역이 약간 굵은 선으로 구분됩니다.
• 상단의 양쪽 창 사이에 화살표가 표시되는데, 왼쪽에서 오른쪽으로 그어진 경우에는 왼쪽의 코드가 오른쪽의 모양으로 바뀔 것이라는 의미입니다. 오른쪽에서 왼쪽으로 화살표가 그어진 경우에는 왼쪽의 모양으로 바뀔 것이라는 의미입니다.
• 단순 병합이 가능한 곳들은 기본 병합 결과를 그대로 이용하면 됩니다. 창의 아래쪽 영역에서 그 결과를 확인할 수 있습니다.
• 단순 병합이 가능하지 않은 곳은 병합툴에서 제시하는 설정값을 변경하여야 합니다. 창의 오른쪽 아래에 보이는 Actions 라는 select box 에서 설정을 변경할 수 있습니다. 각 설정에 대한 자세한 설명은 생략합니다.
• 가능하면 단순 병합이 가능하도록 코드를 수정하는 것이 좋습니다. 파일이름_LOCAL_nnnnn.확장자 형식의 파일을 터미널에서 vim 으로 열여, 충돌을 없애는 쪽으로 수정한 후, FileMerge 프로그램의 File -> Recompare Files 를 실행합니다.
• 병합이 잘 마무리된 경우, File -> Save Merge 후 Quit 하면, 병합된 결과파일이 SourceTree 에 남아 commit 을 할 수 있는 상태가 됩니다.

4. 병합툴로 병합이 여의치 않은 경우, 소스코드를 IntelliJ 등 IDE 에서 수정하여 작동하도록 만들어야 합니다.

sandbox, alpha 브랜치를 따로 관리하는 장점이 무엇인가요?

• 여러 개발자가 서로 다른 릴리즈 일정으로 개발 작업을 진행할 때, feature 브랜치를 가능하면 자주 merge 하여 코드 테스트, QA 테스트를 진행하고자 합니다. 이때 코드의 충돌이 없는지 자주 머지하고 테스트 스테이지에 배포하여 테스트하기 위해 사용하는 브랜치가 sandbox, alpha 브랜치입니다.
• 서로 독립적으로 개발하는 feature 를 테스트 스테이지에서 통합 테스트를 원활히 수행하는 것이 sandbox, alpha 브랜치를 관리하는 용도입니다. 한마디로 표현하면, Continuous Integration 을 branch 이며, alpha, sandbox 에서 feature branch 들을 병합하는 과정이 Continuous Integration 그 자체입니다.

구매하기 개발 관례

feature branch 의 이름에 JIRA issue 번호를 종종 사용한다.

feature branch 의 구현 내용이 무엇인지 확인하기 편리하게 JIRA issue 번호를 브랜치 이름에 사용한다.