GIT 작업 흐름

GIT 작업 흐름

2015. 11. 13. 09:11ㆍ99. 정리전 - IT/11. Java

GIT 작업 흐름
Posted by: dalinaum-kr on 9 1월 2012출처를 밝혀요
http://nvie.com/posts/a-successful-git-branching-model/ (문제시 삭제합니다. 내용의 그림이 안보여 수정함)이 글은 nvie의 A successful Git branching model을 기반으로 하였습니다.GIT을 쓰는데 몇가지 작업흐름을 생각해 볼 수 있습니다.
개발 브랜치
먼저 개발 브랜치로 development를 쓰는 것입니다.
마스터 master브랜치 : 안정 버전으로 릴리즈 예정인 코드
필요에 따라 릴리즈 브랜치와 개발 브랜치가 구별이 없을 경우에는 (웹 서비스 등에서 릴리즈 시간이 의미가 없는 경우) development 브랜치 단계를 생략할 수도 있습니다.
또 다른 작업흐름 중 하나는, 별도의 릴리즈 리포지토리가 있는 경우입니다. 이 경우 master에서 머지된 것을 일정 릴리즈 주기로 다른 리포지토리에 푸쉬하면 됩니다.
기능 브랜치
Feature(기능)브랜치는 development에서 떼어와서 development에 머지되는 형태를 보이고 있습니다.
만약 master 브랜치가 없는 경우에는 master에서 떼어와서 master에 머지하는 형태가 되어도 되겠습니다.
중요한 것은 여러 사람의 작업이 별도로 떨어진 브랜치에서 이루어진다는 것입니다.
기능 브랜치에 대해서 컨벤션을 정하는 것도 좋습니다. 예를 들면 feature- 접두어가 들어간 브랜치를 만드는 것입니다. 아래와 같이 브랜치를 만들 수 있습니다.
```
git checkout -b feature-https development
```
development 브랜치로 부터 feature-https 브랜치를 만들어 https 대응 버전을 작업하는 것이지요.
기능 브랜치에 대해 명확한 정책이 있다면 저장소로 푸쉬하셔도 좋습니다. 저는 이 방법을 추천합니다. 서로의 작업 상황을 외부에서 웹 인터페이스로 확인할 수 있고, 로컬로도 받아서 볼 수 있고 여러 번 서로 피드백을 나눌 수 있을 겁니다.
그렇지 못해 로컬 브랜치로 만들더라도 의의가 있습니다. 개발 중에 저장소를 여러번 fetch나 pull하게 될 때 그 과정이 훨씬 편안해 질겁니다.
merge를 할때 no-ff를 붙여 주시면 조금 더 명시적인 히스토리를 남길 수 있습니다.
릴리즈 브랜치
릴리즈 브랜치를 별도로 만들 수도 있습니다. 특정 버전의 릴리즈를 준비하는 브랜치입니다. 접두어로 release-를 쓰면 아래와 같이 됩니다.
```
git checkout -b release-0.90 development
```
이렇게 development 브랜치로 부터 분리시켜 릴리즈를 준비하는 것이지요.
```
git checkout master
git merge --no-ff release-0.90
git tag -a 0.90
```
이렇게 릴리즈 브랜치를 분리시키면 개발 브랜치를 작업할 팀과 릴리즈 브랜치를 작업할 팀을 나누어서 안정 버전 릴리즈와 개발을 함께 준비할 수 있습니다.
핫 픽스 브랜치
릴리즈 된 버전의 문제를 해결하기 위한 브랜치입니다.
패치를 같이 development에 머지할 수도 있고 릴리즈 브랜치가 있다면 릴리즈 브랜치에 머지한 후에 해당 릴리즈 브랜치의 작업이 끝났을 때 master와 development에 같이 머지하는 방법도 있습니다. 보통은 릴리즈 브랜치가 진행되는 동안에 잡은 버그가 있어 development에 머지할 필요가 생기기 때문입니다.
전체 그림
작업 흐름의 전체는 아래와 같습니다.
도구와 응용
이 작업을 도와주기 위한 도구, git-flow가 있습니다.
GitHub는 development나 release- 브랜치를 별도로 두지 않습니다. 명시적인 릴리즈가 없고 최종 결과물은 다른 리포지토리(프로덕션)에서 서비스하기 때문입니다.
GitHub 팀은 흥미롭게도 pull request 기능을 이용하여 코드 리뷰 도구로 활용합니다. pull request는 자기 자신(같은 리포지토리)에 적용할 수 있습니다. GitHub팀은 master 작업의 결과를 반드시 pull request를 통해서 하도록 하고 있습니다.
같이 읽기