Git - Branch 관리

 

서사

 

코드 관리에 있어서 제일 중요한건 형상관리 인거 같다..

 

우리 회사는 지금 git을 사용하고 있고 Naver Cloud Platform 에서 제공하는 SourceCommit 을 이용하여 remote 관리를 하고 있다.

 

내가 처음 이 회사에 왔을 때 git을 사용할 수 있는 사람들이 많이 없었고, git이라는 걸 처음 듣는 사람들도 있었다.. 

( 처음에 체계를 잘 잡았어야 했는데.. 연차가 너무 낮아서 ㅠ  )

 

우리의 현재 git branch 구조는 

 

- master : 운영 배포 용

- dev : 개발용

- 그외 :  사이드 개발 + 버그 픽스 

 

운영 되고 있다.

 

그렇다 보니 그외 <-가 너무 제멋대로 네이밍이 되고, 사용이 끝나서 dev와 merge를 진행해도 아직 쓰레기 파일 처럼 남아있는 branch가 너무 많다.

 

나중에 가면 네이밍 때문에 어떤 기능개발을 위해 이 branch 를 생성 하였는지도 모르겠더라.. ( 내가 만들었는데도 .. )

 

그래서 이번에 체계를 잡아보려 공부를 좀 해보았다

본론

위 그림을 보면 크게 5가지로 구분 할 수 있다

 

• feature : 기능 개발
• develop : 개발 merge
• release : 운영 배포 전버전
• hotfix : 심각한 버그에 대한 처리 
• master : 운영 버전

 

Feature

Feature는 기능 개발 브랜치다

login 기능을 개발한다면 feature/login 으로 branch를 만들어 관리할 수 있다.

develop 브랜치에서 생성되며 개발이 끝나면 해당 브랜치는 develop 브랜치에 merge 된다. 

merge된 이후 해당 branch는 삭제한다.

 

 

Develop

 

 

Develop 개발 중심의 브랜치다

하나하나의 Feature가 합쳐져서 Develop 이 살이 붙는다.

Develop 브랜치가 배포할 수준의 기능을 갖추면 realease 브랜치로 merge된다 .

 

 

 

Release

 

Release는 개발된 내용을 배포하기 위한 브랜치다 

첫번째 릴리즈는 release-1, release-2 형태로 배포하는 것이 보편적인 관리법이다.

이 브랜치는 develop에서 생성되고 배포직전의 테스트 용이고, 테스트 와 여러가직 버그 검사를 진행한다.

버그가 발생하면 수정하고, 해당 버그수정 내역을 develop에도 추가 적용해준다. 

배포 준비가 되었다고 판단되면 master와 merge 한다.

 

 

Hotfix

 

Hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치로

브랜치명은 hotfix-1로 지정된다.

release브랜치를 거쳐서 검사를 했지만 배포된 후 예상하지 못한 버그가 발생했을 때 빠르게 픽스하기 위해 사용된다.

master 브랜치에서 생성되며 수정이 완료되면 develop, release, master 브랜치에 수정사항을 반영한다.

 

 

 

Master

Master는 최종적으로 배포되는 브랜치다.

 

 

결론

 

우선 Git Flow를 통해서 보편적인? git 패턴을 공부하고 공유하였는데,

현업에서 나와보니 제일 중요한건 같은 팀원이 얼마나 우리가 정한 체계를 따르고, 통일성을 가져가느냐가 정말 중요하다. 백날 저렇게 정리해봐야 누군가가 규칙 모르겠고! 난 Master에 작업할거야! 하는 순간 다 끝이다. ( 물론 이런적은 없음.. ) 

 

사실 이 Flow를 우리 회사에 적용하고 싶은데, 잘 따라오지 못할 거 같고 나 또한 잘 관리하지 못할 것 같은 느낌이 든다.. 자신이 없어 .. 이런 체계를 잡아가는 과정들을 한두번 겪다 보니 혼자서 할 수 있는 일이 아니라는 걸 느끼고 있다 ..