0원으로 현업 환경을 설정해보자! Git Flow(Sourcetree)

 

이 포스트는 Sourcetree 를 기준으로 설명하고 있습니다. 

 

이 포스팅은 "실제 현업의 환경을 설정해보자!"의 Series  중 일부입니다.

 

1.  0원으로 현업 환경을 설정해보자! Git

2  0원으로 현업환경을 설정해보자! Sourcetree

3. 0원으로 현업환경을 설정해보자! Beyond Compare

4. 0원으로 현업환경을 설정해보자! Git Flow(Sourcetree)

5. 0원으로 현업 환경을 설정해보자! Github Pull Request(코드 리뷰)

6. 0원으로 현업환경을 설정해보자! [번외편] 히스토리 꾸미기

 

 

Git Flow?

전체 소스는 여기에서 확인할 수 있습니다.

우아한 형제들에서 git flow 포스트를 참고하시면 도움이 됩니다.

 

https://camo.githubusercontent.com/e1dae4f1f5868a9d043d39824761cff9dabe764f/687474703a2f2f646f67666565742e6769746875622e696f2f61727469636c65732f323031312f612d7375636365737366756c2d6769742d6272616e6368696e672d6d6f64656c2f6769742d6272616e6368696e672d6d6f64656c2e706e67

 

위에 그림이 어떻게 흘러가는지 한번 파헤쳐보도록 하겠습니다. 

 

저장소 초기화

git flow 를 초기화 하기 위해선 아래 기능을 실행시켜야 합니다. 

 

자세한 Git flow 명령어를 확인하실려면 여기를 참조해 주세요.

// Command
git flow init


// 메뉴 
저장소 -> Git flow / Hg flow -> 저장소 초기화

 

 

 

 

저장소 초기화를 실행하면 아래와 같이 develop 브랜치가 생성됩니다.

 

 

Feature Branch

 

저장소 -> Git flow / Hg flow -> 새 기능 시작

 

 

새 기능 시작을 하면 Develop 으로부터 Feature branch 를 생성합니다. 

 

Feature 를 마무리할려면 기능 마무리를 실행하면 됩니다. 

 

저장소 -> Git flow / Hg flow -> 기능 마무리

 

 

feature/network 브랜치는 삭제되며 develop 에 merge 됩니다.

 

 

Release Branch

 

Release 브랜치를 생성하기 위해선 아래 기능을 실행하면 됩니다. 

 

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

 

 

 

 

현재 Develop 위치에서 Release 브랜치를 생성합니다 .

 

 

 

Release 브랜치를 마무리하기 위해선 아래 기능을 실행하면 됩니다.

 

저장소 -> Git flow / Hg flow -> 릴리즈 마무리

 

 

 

결과적으로 release/v1.1 브랜치가 삭제되며 develop 브랜치로 merge 되며 develop 으로 다시 돌려줍니다. 

 

Hoxfix

v1.1 버전에서 긴급 이슈 가 발생하면 hoxfix 를 생성합니다.

 

저장소 -> Git flow / Hg flow -> 새 핫픽스 시작

 

 

 

master 브랜치를 기준으로 hoxfix/v1.2 브랜치가 생성되었습니다.

 

 

 

진행하면서 develop 브랜치가 수정되었다고 가정해봅시다. 

 

 

 

QA 테스트가 끝나고 핫픽스를 마무리하려고 합니다.

 

저장소 -> Git flow / Hg flow -> 핫픽스 마무리

 

 

핫픽스 마무리를 클릭하면 hoxfix 의 수정사항이 master, develop 에 모두 적용됩니다.

 

 

 

그러나 이 예제는 정말 교과서와 같이 정상인 환경에서 설명을 한 것이며

 

실제 업무를 보시다보면 복잡하게 꼬인 그래프를 만나게 됩니다 .

 

가장 큰 문제가 되는 것은 파일 충돌이 발생하는 현상입니다.

충돌을 회피하기 위해서 몇 가지 스킬이 필요합니다. 

 

커밋단위, 파일 단위 섹션을 이어서 보기로 하죠.

 

커밋 단위

우아한 형제들 포스트에서도 설정하고 있는 "작업을 할 때 지켜야할 서로 간의 약속" 에서도

개인적으로 가장 중요하다고 생각이 되는 것은 Commit 단위를 최소로 하는 것입니다.

 

그 이유는 히스토리를 관리할 수 있기 때문입니다. 

 

복합적인 변경의 사유로 커밋되어 있다면, 

이전에는 발생하지 않았는데 현재 발생한 이유에 대해서 Tracking 하며 찾아갈 때 상당히 버겁겠죠.. ^^;

또, 협업하는 환경에서는 다른 사람이 Context 를 파악하기 어렵습니다. 

 

파일 단위

다른 사람이 같은 파일을 수정하게 되면 충돌이 나게됩니다. 

 

이부분은 설계의 관점으로 해소할 수 있는 부분들이 있습니다. 

 

OCP

SOLID 원칙 중 OCP 는 파일이 충돌나는 것을 해소합니다.

 

추상화된 전략 객체를 의존성 주입받으므로 실행코드는 변경되지 않도록 하며

Type 확장으로 구현 코드를 다른 파일에 배치할 수 있습니다. 

 

아래 그림은 백명석님 유튜브 강의 중 OCP 내용입니다.

 

 

 

SRP

SRP 는 변경의 이유를 하나로 해야한다고 설명합니다.

 

변화율이 높은 책임 객체는 별도의 파일로 분리하고 의존성을 추가하도록 비용을 사용하는 것이 좋습니다.

 

즉, 의존성의 추가라는 비용이 추가되지만 그만큼 얻는 장점도 많습니다. 

설계는 트레이드 오프이며, 균형을 잡는 것이 중요합니다. 

 

하지만 이 스킬은 쉽게 달성할 수 있는 것이 아니므로 무조건 원칙대로 분리하면 팀원들에게 질타를 받을 수 있습니다. 😇

 

아래 그림은 백명석님 유튜브 강의 중 SRP 내용입니다.

 

 

 

 

참조: 

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

https://www.youtube.com/watch?v=dqa-IdafeIE&list=PL7pUrjEGbG8ZMPQ-XukPJsFyMeyvtGcnV&index=16

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