지금 진행하고 있는 솔루션에서 갑작스럽게 git을 적용하다보니 branch를 어떻게 운영해야 할지에 대해서 막막했는데, 여러 자료들을 보면서 나름의 branch 전략을 세우려고 한다.
당연히 누군가는 이런 고민을 했겠지라는 생각으로 구글링을 시작.
1.
A successful Git branching model 번역 이게 제일 유명한 포스팅인 듯 하다. 특별한 이름은 없고 대부분 "성공적인 모델"이라고 지칭하는 듯. 길지 않은 글이지만, 한글로 짧게 요약한 글도 있다. 이게 더 잘 요약한 것 같다. 이 전략을 기반으로 gitflow라는 것도 누가 만들었다. 그리고 적용후기 (한글)
2.
branch 전략은 아니지만 분산 저장소들을 어떻게 관리할지에 대해서 그림으로 설명한 글도 있다. 같은 블로그에서 비공개 소규모 팀 운영을 위한 예제 시나리오도 읽어볼 만 하다.
이제 회사업무에 적용할 생각을 해보면...
3.
사내 ALM시스템을 사용하면 자연스럽게 1번에서 언급한 "성공적인 모델"을 사용하게 된다. master, develpoment, release-*, feature-* 까지는 그대로 사용하고, hotfix-*만 bugfix-*라는 prefix를 사용하게 된다. 아마도 master에서만 가져오는게 아니라 development나 release-*에서도 가져올 수 있는 구조이므로 일부러 이름을 다르게 잡은 것 같다.
4.
우리 솔루션만의 문제가 더 있다. 솔루션이 고객사 시스템에 설치되는 구축형이다 보니 고객사마다 릴리즈된 버전을 관리할 필요가 있다. 아직 버전에 대한 경험이 없어서 특정 시점의 소스형상으로 설치가 된다. 그 시점의 소스형상을 "고객사A" branch로 만든다. 고객사가늘어날 때마다 만들어지는 branch인데, 고객사가 많아지기 전에 고객사에 "특정 시점의 소스형상"이 아니라 "특정 버전의 소스형상"을 릴리즈하는 형태가 만들어져야 할 것 같다.
5.
팀내의 퍼블리셔가 만드는 이미지 파일과 HTML소스는 "publish" branch에서 관리된다. 언듯 생각하면 퍼블리셔에게 퍼블리싱하는 대상 기능에 맞는 feature-*에 commit하라고 하면 될 것 같지만, 그렇게 하지 못 하는 이유가 있다. 이미지 파일의 경우 여러 이미지를 합쳐서 하나의 이미지로 만들고 잘라서 쓰는 경우가 있고, css 파일도 하나의 파일에서 모든 css를 관리하고 있기 때문이다. 즉, branch를 나눠서 얻는 이점보다 merge할때 생기는 conflict를 해결하는 게 더 힘들어질 것으로 예상했다. 게다가 퍼블리셔 입장에서도 여기 저기 feature-*를 변경하면서 개발하는 것은 너무 번거롭다.
6.
결국 지속적으로 관리되어야 하는 branch가 4개가 된다. master, "고객사A", developement, publish.
2.
branch 전략은 아니지만 분산 저장소들을 어떻게 관리할지에 대해서 그림으로 설명한 글도 있다. 같은 블로그에서 비공개 소규모 팀 운영을 위한 예제 시나리오도 읽어볼 만 하다.
이제 회사업무에 적용할 생각을 해보면...
3.
사내 ALM시스템을 사용하면 자연스럽게 1번에서 언급한 "성공적인 모델"을 사용하게 된다. master, develpoment, release-*, feature-* 까지는 그대로 사용하고, hotfix-*만 bugfix-*라는 prefix를 사용하게 된다. 아마도 master에서만 가져오는게 아니라 development나 release-*에서도 가져올 수 있는 구조이므로 일부러 이름을 다르게 잡은 것 같다.
4.
우리 솔루션만의 문제가 더 있다. 솔루션이 고객사 시스템에 설치되는 구축형이다 보니 고객사마다 릴리즈된 버전을 관리할 필요가 있다. 아직 버전에 대한 경험이 없어서 특정 시점의 소스형상으로 설치가 된다. 그 시점의 소스형상을 "고객사A" branch로 만든다. 고객사가늘어날 때마다 만들어지는 branch인데, 고객사가 많아지기 전에 고객사에 "특정 시점의 소스형상"이 아니라 "특정 버전의 소스형상"을 릴리즈하는 형태가 만들어져야 할 것 같다.
5.
팀내의 퍼블리셔가 만드는 이미지 파일과 HTML소스는 "publish" branch에서 관리된다. 언듯 생각하면 퍼블리셔에게 퍼블리싱하는 대상 기능에 맞는 feature-*에 commit하라고 하면 될 것 같지만, 그렇게 하지 못 하는 이유가 있다. 이미지 파일의 경우 여러 이미지를 합쳐서 하나의 이미지로 만들고 잘라서 쓰는 경우가 있고, css 파일도 하나의 파일에서 모든 css를 관리하고 있기 때문이다. 즉, branch를 나눠서 얻는 이점보다 merge할때 생기는 conflict를 해결하는 게 더 힘들어질 것으로 예상했다. 게다가 퍼블리셔 입장에서도 여기 저기 feature-*를 변경하면서 개발하는 것은 너무 번거롭다.
6.
결국 지속적으로 관리되어야 하는 branch가 4개가 된다. master, "고객사A", developement, publish.
"고객사A" branch는 버전관리를 잘 해서 특정 버전 branch가 되도록 유도하여 결국에는 branch자체를 없에야 겠다. publish는 그냥 두고 진행한다. 퍼블리싱 대상 소스만를 위한 devleopment처럼 개념을 잡고 수시로 development쪽으로 merge를 수행하도록 해야 겠다.
7.
ALM에 bug가 등록되면 hotfix인지 여부를 제품책임자와 개발리더가 판단하여 branch를 hotfix면 master에서, 그렇지 않으면 development에서 가져오도록 해야 겠다. hotfix인 경우, 사내 ALM시스템에서 새로운 patch version을 생성해서 릴리즈 절차를 진행할 수 있도록 해야겠다. (그런 의도의 기능이라면) patch version의 bug에서 branch를 생성할 때 기본적으로 master에서 가져오는지 확인해야 한다. [TODO]
7.
ALM에 bug가 등록되면 hotfix인지 여부를 제품책임자와 개발리더가 판단하여 branch를 hotfix면 master에서, 그렇지 않으면 development에서 가져오도록 해야 겠다. hotfix인 경우, 사내 ALM시스템에서 새로운 patch version을 생성해서 릴리즈 절차를 진행할 수 있도록 해야겠다. (그런 의도의 기능이라면) patch version의 bug에서 branch를 생성할 때 기본적으로 master에서 가져오는지 확인해야 한다. [TODO]
8.
6번과 7번처럼 정리가 되면 한번 사용한 branch들은 "성공적인 모델"에서 언급한 것 처럼 merge된 직후에 삭제되어도 된다. merge request를 개발리더가 accept한 직후에 삭제해버리면 될 듯. git remote repo에서 삭제한 branch를 이클립스 eGit에서 pull할때 자동으로 삭제되도록 개발자로컬환경 셋팅이 필요하다. 그래야 없어진 branch에서 개발하는 실수를 막을 수 있을 듯 하다. 이렇게 eGit의 버전을 올리고 prune 옵션을 설정해서 해결하면 된다.
3줄정리
- branch 전략은 "성공적인 모델"을 따른다.
- "고객사A" branch는 특정 version의 branch로 대체한다.
- publish는 상시 유지하고 수시로 development에 merge한다.
6번과 7번처럼 정리가 되면 한번 사용한 branch들은 "성공적인 모델"에서 언급한 것 처럼 merge된 직후에 삭제되어도 된다. merge request를 개발리더가 accept한 직후에 삭제해버리면 될 듯. git remote repo에서 삭제한 branch를 이클립스 eGit에서 pull할때 자동으로 삭제되도록 개발자로컬환경 셋팅이 필요하다. 그래야 없어진 branch에서 개발하는 실수를 막을 수 있을 듯 하다. 이렇게 eGit의 버전을 올리고 prune 옵션을 설정해서 해결하면 된다.
3줄정리
- branch 전략은 "성공적인 모델"을 따른다.
- "고객사A" branch는 특정 version의 branch로 대체한다.
- publish는 상시 유지하고 수시로 development에 merge한다.
댓글 없음:
댓글 쓰기