뭐.. 여러가지 SW Branch 정책들이 있을텐데... (하나의 branch에 전부 때려 잡아 넣고 개발하는 회사라면... 쩝 뭐 특별히 할 말 없다)

보통의 경우 SW branch는 아래와 같은 형태를 가진다.


+------------------------------ sub branch

/ ---------+-------------------+-------------------------------------- main branch

\

+------------------------------------ sub branch


기본적인 형태는 같지만, 정책적인 측면으로 보면 크게 두 가지로 분류할 수 있다.


1. 큰 main branch 정책

main branch가 기능 구현의 주요 작업 공간이 되는 방법.

main branch 가장 자주 update된다.

- feature이 대부분 main branch에서 개발되므로, 다른 외부 project branch의 개수가 적은 편이다.


2. 작은 main branch 정책

sub-branch가 기능 구현의 주요 작업 공간이 되는 방법.

- main branch가 가장 뜸하게 update되고 엄격하게 관리된다.

- feature들을 main branch와는 별도로, 서로 다른 project branch로 관리한다.


위의 두 가지 모두 기본적인 업무 방식은 같다.

1. 특정 시점에서 main branch에서 branch out

2. 필요한 새로운 feature들을 구현하거나, 다른 feature branch로 부터 가져오고, stability를 향상시킴

3. software release

4. 필요한 patch들을 main branch에 다시 merge함.


그렇지만, 위와 같이 서로 다른 방식의 정책을 적용하다보면, branch의 특성이 서로 달라진다.

1. 큰 main branch 정책

- main branch는 feature위주로 관리된다.

- main branch는 거의 모든 feature들을 가진다.(feature들의 super-set)

- main branch가 가장 많은 버그를 가진다.

- main branch의 코드 size가 sub branch에 비해 크다.

- 보통 branch out의 기준은 feature가 된다. 즉, 특정 feature가 available한 시점을 기준으로 main branch로 부터 branch out한다.

장점 : Integration에서 발생가능한 문제들이 main branch에서 충분히 다루어진 상태이므로, sub branch에서 이 문제에 대한 risk가 적다.

단점 : main branch의 stability관리가 어렵다. 그래서, sub branch에서 stability를 위한 비용이 크다.


2. 작은 main branch 정책

- main branch는 stability위주로 관리된다.

- main branch는 최소한의 feature만을 가진다.

- main branch의 stability가 가장 뛰어나다.

- branch out의 기준은 feature보다는 stability가 된다.

장점 : main branch의 stability가 충분히 좋으므로, sub branch에서 stability문제가 발생하더라도, main branch를 기준으로한 debugging이 가능하므로, 적은 비용으로 sub branch의 stability를 유지할 수 있다.

단점 : integration에 따른 문제들이 충분히 드러난 상황이 아니므로, sub branch에서 이것과 관련된 많은 문제들이 나올 수 있다.


branch 정책을 결정할 때는 위의 두 가지 요소를 충분히 고려할 필요가 있다.

stability에 대한 비용 vs. integration에 대한 비용

그리고 거기에 따라, branch 정책을 정할 필요가 있다.


개인적으로 봤을 때, 대부분의 경우, stability를 위한 비용이 integration비용에 비해 상당히 비싸다.

따라서, 작은 main branch정책이 더 좋은 것 같은데.... 


+ Recent posts