거의 매일 업데이트하고 릴리스하는 웹 앱이 있습니다. 우리는 git을 VCS로 사용하며 현재의 브랜칭 전략은 매우 간단하고 깨졌습니다. 마스터 브랜치가 있고 우리가 '좋아하는'변화를 확인합니다. 이것은 변경 사항을 확인할 때까지만 작동합니다.
누구든지 다음 요구 사항을 충족하는 소규모 팀 을 위해 좋아하는 git branch 전략을 가지고 있습니까?
이상적으로는 새로운 버그를 연구하는 개발자를위한 단계별 프로세스를보고 싶습니다.
답변:
Scott Chacon이 Pro Git 에서 설명하는 워크 플로우의 이점을 활용할 수 있습니다 . 이 워크 플로우에는 항상 존재하는 두 가지 분기, 마스터 및 개발이 있습니다.
master 는 프로젝트의 가장 안정적인 버전을 나타내며이 지점의 프로덕션에만 배포 할 수 있습니다.
develop 에는 진행중인 변경 사항이 포함되어 있으며 프로덕션 준비가되어 있지 않을 수도 있습니다.
로부터 개발 지점, 개별 기능과 수정 작업 할 주제 지점을 만들 수 있습니다. 기능 / 수정이 준비되면 해당 기능을 develop에 병합하면 동료가 병합 한 다른 주제 분기와 상호 작용하는 방법을 테스트 할 수 있습니다. 일단 개발 이 안정적인 상태가 되면 master에 병합하십시오 . master 에서 프로덕션으로 배포하는 것이 항상 안전해야합니다 .
Scott은 이러한 장기 실행 브랜치를 코드의 "사일로"라고 설명합니다. 안정성이 낮은 브랜치의 코드는 팀의 테스트 및 일반 승인 후보다 안정적인 것으로 간주되는 것으로 결정됩니다.
단계별로이 모델의 워크 플로는 다음과 같습니다.
이 워크 플로에 대한 자세한 내용 은 Pro Git 의 Branching Workflows 장을 확인하십시오 .
develop자식이없는 것을 문제에 대한 불필요한 '솔루션'이다. 내가 말할 수있는 한 의견이없는 잘못된 안내 기사가 있으면 잘 쓰여져 있기 때문입니다. 다음은 반품 barro.github.io/2016/02/…입니다.
소스 컨트롤을 사용해 본 적이없는 다른 개발자들에게 가르치는 간단한 전략을 찾으려고 초보자로 들어온 후. 이것은 http://nvie.com/posts/a-successful-git-branching-model/ 에 맞는 것 입니다. 맨 페이지의 표준 GIT 워크 플로를 사용해 보았지만 약간 혼란스럽고 청중이 완전히 혼란 스럽습니다.
지난 6 개월 동안 나는 갈등을 두 번만 고 치곤했다. 병합 후 항상 테스트하고 기능을 개발하는 동안 아침과 오후에 한 번 많은 '가져 오기 및 병합'또는 '풀-리베이스'단계를 추가했습니다. 또한 최신 코드를 가져 오기 위해 github.com을 중앙 위치로 사용했습니다.
default master branch에 가장 자주 개발자가 사용되지 않을 때 그것이 옳지 않다고 느낀다A successful Git branching model
( 처음에 있어야했던 것처럼 위의 의견 은 자체 답변입니다.)
Github의 Scott Chacon에서 :
그렇게하는 방법 GitHub Flow 란 무엇입니까?
- 마스터 브랜치의 모든 것은 배포 가능
- 새로운 작업을하려면 설명 적으로 이름이 지정된 브랜치에서 브랜치를 생성하십시오 (예 : new-oauth2-scopes)
- 해당 지사에 로컬로 커밋하고 정기적으로 서버의 동일한 지사에 작업을 푸시하십시오.
- 피드백이나 도움이 필요하거나 지점을 병합 할 준비가되었다고 생각되면 풀 요청을여십시오.
- 다른 사람이 기능을 검토하고 사인 오프 한 후이를 마스터로 병합 할 수 있습니다.
- 병합 된 후 '마스터'로 푸시되면 즉시 배포 할 수 있으며 배포해야합니다
자세한 내용은 전체 기사를 참조하십시오. http://scottchacon.com/2011/08/31/github-flow.html
"풀 요청 (pull requests)"은 Github 발명품이며 Git 자체가 아닌 웹 사이트에 구운 것입니다. https://help.github.com/articles/using-pull-requests/
master지점을 개발 지점으로 사용하고 버그 수정을 수행하기위한 릴리스 지점을 만듭니다.
새로운 기능은 master개발 기간 동안 계속 진행됩니다 (직접 커밋 또는 풀 리퀘스트가있는 토픽 브랜치로 그래픽에 표시되지 않음). 계획된 모든 기능이 구현되면 기능 정지를 입력하고 테스트를 수행하십시오. 마음에 master들면 릴리스에 로 태그를 지정하십시오 v1.0.
시간이 지남에 따라 사용자는 버그를 발견하게 v1.0되므로 해당 태그에서 분기를 작성하고 (예 : 릴리스 이름을 지정) 분기에서 1.0해당 버그를 수정해야합니다. 버그가 충분히 수정되면 새 릴리스가 필요하다고 생각한 다음에 태그를 지정 v1.0.1하고에 다시 병합합니다 master.
한편 master지점 에 새로운 개발 창이 진행될 수 있으며, 결국에는 태그가 붙습니다 v1.1.
헹구고 반복하십시오.
이것은 시맨틱 버전 넘버링 로직을 따른다 .
---------(v1.0)--------------------------------(v1.1)-----------------------------> master
\ \
---(v1.0.1)---(v1.0.2)---> 1.0 ---(v1.1.1)---(v1.1.2)---> 1.1
1.0.1변경 사항을 다시 병합하는 것을 잊지 마십시오master
1.1병합 후에 는 항상 마스터 에 기반을 두어야합니다 1.0.1. 이는 신뢰를 최소화하는 데 도움이됩니다.
1.1릴리스 브랜치이며 하나 이상의 릴리스의 정확한 상태를 나타내는 태그가 있습니다. 해당 지점을 리베이스하면 해당 표현이 손실됩니다. 이를 방지하기 위해 강제 푸시를 거부하도록 릴리스 브랜치를 설정하는 것이 좋습니다.
VCS에서 "마스터"브랜치 만 있으면 한 브랜치에서 동시에 모든 개발 노력을 추구 할 수 없으므로 한계를 빠르게 보여줍니다.
즉, 언제 분기 해야하는지 알아야 합니다.
그러나 DVCS ( "분산 형"VCS에서와 같이)에서는 저장소에 로컬로 유지되는 분기 및 푸시하거나 가져 오는 분기와 함께 발행 문제 가 있습니다.
이와 관련하여, 동시 개발 노력을 식별하여 시작하고 공개 (푸시 / 풀) 프로세스를 결정하십시오. 예를 들어 (그리고 이것이 유일한 방법은 아닙니다) :
이 SO 질문이 증명하는 것처럼 다른 릴리스 관리 프로세스가 존재 합니다 .
애자일 팀을위한 ReinH의 Git Workflow를 읽으십시오 : http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
소규모 팀에게는 매우 효과적입니다. 여기서의 목표는 잠재적으로 불안정 할 수있는 모든 것이 어떤 종류의 지점으로 들어가도록하는 것입니다. 기능 분기 외부에서 작업하는 모든 사용자가이를 사용할 준비가되면 마스터로 다시 병합하십시오.
참고 :이 전략은 git에 한정되는 것은 아니지만 git을 사용하면이 전략을 쉽게 구현할 수 있습니다.