형상관리 전략

Git Flow

팀 프로젝트를 진행하는데 용이한 브랜치 관리 전략중 하나다.

다섯개의 브랜치를 기준으로 나눠서 프로젝트를 관리한다. 각 브랜치가 하는 역할을 알아야지 이 전략을 이해할 수 있다.

아래 사진은  이 전략을 사용해서 형상관리를 했을때 flow 의 모습이다. 이해를 하기 위해서는 각 브랜치의 의미를 알아야 한다.

3.relase 브랜치

-develop 브랜치 다음으로 넘어가게 되는 브랜치다. QA팀 및 개발자들이 마지막으로 문제가 되는건 없는지 판단하는 곳이다. 작업에 만약 문제가 생겼다면 수정후 develop과 main 브랜치에 병합시켜줘야 한다.

 

4.develop 브랜치

-여기서는 발견된 버그를 고치는 작업을 하거나 신규기능을 만들어야 하는 경우 feature 브랜치에서 따로 작업한뒤 develop브랜치에 병합시켜준다. main 브랜치와 마찬가지로 이 형상관리 전략에서 가장 중요한 브랜치중 하나다.

 

5.feature 브랜치

-신규 기능을 작업하는 브랜치다. feature/기능의 이름 으로 브랜치 이름을 작명한뒤 develop브랜치에 병합시킨다.

 

Git Flow 의 장점

1. 기능별로 개발을 안전하게 분리할 수 있다.
   - feature 브랜치를 사용해서 기능별로 코드를 분리하기 때문에 유지보수할때 편하다. 다른 기능과 엮여서 코드를 수정해야 할 필요가 없다. 원하는 기능 딱 하나만 집중해서 수정 하는게 가능하다.
    
2. 코드 안정성을 유지한 상태로 릴리스를 준비할 수 있다.
   - 기능 개발이 끝난 뒤에도 마지막으로 release 브랜치에서 최종 점검을 할 수 있다. 버그를 확인할 수 있는 과정이 release브랜치를 통해 한번 더 있기 때문에 안정적이다.
    
3. 긴급하게 수정해야 할 필요가 있어도 대응 가능
   - 실제 서비스를 배포하는 main브랜치에서 만약 문제가 발생한다면 hotfix브랜치를 사용해서 버그를 바로 대응하는게 가능하다.
    
4. 개발과 배포를 따로 나눴기 때문에 버그 대응과 신규기능 개발에 용이하다.
   - develop(개발) 브랜치와 main(배포)브랜치를 따로 나눴기 때문에 만약 신규기능을 만들어야 한다면 feature브랜치에서 작업을 다 마치고 병합을 하기만 하면 된다.
    
5. 협업을 할때 각 브랜치가 하는 역할이 명확하게 정해져 있기 때문에 코드를 합칠때 효율이 좋다.

 

Git Flow 의 단점

1. 너무 복잡하다
   - 다섯개의 브랜치를 관리하다보니 아무래도 복잡할 수 밖에 없다. 빠르게 일을 쳐내야 할때 형상관리 한다고 시간을 다 쏟아버릴 수도 있다.

 

1. PR을 생성해서 관리할때 더더욱 복잡해진다.
   - 기능을 하나 개발하고 develop에 병합시킬때 보통 pr을 생성하고 코드 리뷰를 진행하는데 만약 여러 브랜치를 거치면서 합치면 복잡하다.
    
2. 빠르게, 자주 배포를 해야 하는 상황에서 비효율적이다.
   -  말 그대로다. 버그를 수정을 확인하거나 최종 점검을 하기 위해서 release 브랜치를 거치게 되는데 업무 일정이 바빠지면 이 과정을 거친다고 시간을 할애해야한다. 정작 중요한 일 말고 다른 일에 시간과 노력을 쏟아야 하는셈.

GitHub Flow

위의 Git Flow 보다는 훨씬 보기 편하다. 보기 편한 것처럼 훨씬 단순하다.

Scott Chacon 이라는 사람이 실제로 Git Flow전략이 너무 복잡해 보여서 만든 방법이라고 한다. 기본적으로 배포용 브랜치에 대한 규칙만 명확하게 정해져 있기 때문에 병합을 하기전에 브랜치의 이름을 직관적으로 잘 작명해야 한다.

Git Flow 처럼 따로 develop 이나 main 브랜치를 두지 않는다. 그냥 전체 큰 흐름의 배포용 main 브랜치가 처음이지 끝이다. 유지보수가 잦거나 배포를 자주 해야해서 형상관리에 크게 쏟을 여력이 없다면 이 전략이 좋다.

이 전략을 취하면 아래와 같은 모습으로 브랜치가 흐른다.

(위의 사진에서는 브랜치 이름을 codingTest 라는 식으로 작명했는데, 실제로 협업을 할때는 이래선 안된다. 작성자가 개인적으로 혼자 다루는 작업 공간이라 저렇게 한거다.)

Git Flow에 비하면 훨씬 더 직관적인 것을 알 수 있다. 이 방법을 쓰면 신규 기능을 만들던 버그를 고치던 뭐가 됐든 새로운 브랜치를 생성해서 작업물을 커밋하고 main브랜치에 병합시켜야 한다. (바로 병합시키지 말고 PR을 생성해서 코드리뷰를 하도록 하자. 아무생각없이 합쳤다가는 큰일난다.)

생성한 브랜치가 어떤 역할을 하는지 매우 직관적으로 잘 이해할 수 있어야 한다. 보통 작업 내용 이름 앞에 접두사를 붙힌다. 버그면 bugfix, 기능 구현이면 featrue 등으로 이름을 붙혀야 한다.

예를 들면 아래와 같은 방식으로 브랜치 이름을 작명하면 된다.

feature/userListUpdate -> 이름만 봐도 사용자 목록의 업데이트 기능을 새로 만든 것을 알 수 있다.

feature/login -> 로그인 기능을 구현

bugfix/baseURL -> 베이스 URL을 잘못 설정 했기에 이를 수정했다는 사실을 짐작할 수 있다.

 

작명을 한뒤 커밋 메세지에 어떤 일을 했는지 최대한 자세히 적어야 한다.

 

Git Lab Flow

이 전략은 복잡한 Git Flow와 간단한 Git Hub Flow의 중간쯤에 있는 전략이다. Git Flow가 5개의 브랜치로 전략을 나눈다면 이 전략은 4개로 나눈다.

1. production : 실서비스를 위한 브랜치다. Git Flow로 치면 main브랜치에 해당한다.
2. pre-production(Staging) : 실서비스를 진행하기전에 문제가 있는지 확인하기 위한 역할의 브랜치다. 여기서 문제가 없으면 실서비스인 production 에 병합시킨다.
3. main(master) : 개발을 관리하기 위한 브랜치다. 여기서 feature 브랜치를 만들어서 작업을 하고 병합시켜준다.
4. feature : 새로운 기능을 개발하는 브랜치. 작업후 master에 병합시켜준다.

 

장점

1. production, staging, main 상황별로 브랜치를 나눴기 때문에 코드를 배포하고 나서 문제가 생기면 상황을 분리해서 문제를 해결할 수 있다.
2. CI/CD와 쉽게 통합할 수 있다.
   - 이 배 전략은 CI/CD와 쉽게 통합할 수 있다. 보통 Git Flow와 Git Hub Flow 이 두가지 전략에 CI/CD를 많이 적용한다.
3. 복잡한 작업과 간단한 작업의 상황에 맞게 브랜치를 사용하면 된다.
   - 복잡하고 해야할 작업이 많으면 위에서 언급한 4개의 브랜치를 다 활용하면된다. 하지만 간단한 작업이면 그냥 featrue와 main브랜치만 쓰면된다. 상황에 맞게 내 입맛대로 할 수 있는 셈이다.
4. 해야할 일을 정확하게 명시할 수있다.
   - 개발자는 feature 브랜치에서 개발을 진행하고 QA는 Staging에서 문제가 없는지 확인하면 된다. 그리고 마지막에 안정된 작업물만 production에 배포하면 되니까 해야할 일이 직관적이다.