소규모 개발 팀을 위한 Git 브랜치 전략
우리는 거의 매일 업데이트하고 출시하는 웹 앱을 가지고 있습니다.우리는 Git를 VCS로 사용하고 있으며, 현재 분기 전략은 매우 단순하고 중단되었습니다. 마스터 분기가 있고 마스터 분기에 대한 변경 사항을 확인합니다.이것은 작동하지만, 우리가 변경 사항을 확인하기 전까지는 가능합니다.
다음 요구 사항을 충족하는 소규모 팀을 위해 선호하는 깃브랜치 전략을 가진 사람이 있습니까?
- 2~3명의 개발자로 구성된 팀에서 잘 작동합니다.
- 가볍고 공정이 과도하지 않음
- 개발자들이 버그 수정 및 더 큰 기능에 대한 작업을 쉽게 분리할 수 있습니다.
- 안정적인 지점을 유지할 수 있습니다(운영 서버를 작동시켜야 하는 '아뿔싸' 순간을 위해).
이상적으로, 새로운 버그를 개발하기 위한 단계별 프로세스를 보고 싶습니다.
Scott Chacon이 Pro Git에서 설명하는 워크플로우의 이점을 얻을 수 있습니다.이 워크플로우에는 마스터 및 개발이라는 두 개의 분기가 항상 존재합니다.
마스터는 프로젝트의 가장 안정적인 버전을 나타내며 이 분기에서만 프로덕션에 배포할 수 있습니다.
develop에는 진행 중인 변경 사항이 포함되어 있으며 반드시 생산 준비가 되어 있지는 않을 수 있습니다.
개발 분기에서 주제 분기를 생성하여 개별 기능 및 수정 작업을 수행할 수 있습니다.기능/수정 프로그램을 실행할 준비가 되면 해당 기능/수정 프로그램을 개발로 병합하고, 이 때 동료가 병합한 다른 항목 분기와 상호 작용하는 방식을 테스트할 수 있습니다.개발이 안정적인 상태가 되면 마스터로 병합합니다.마스터에서 프로덕션으로 배포하는 것은 항상 안전해야 합니다.
Scott는 이러한 장기간 실행되는 분기를 코드의 "사일로"라고 설명하며, 여기서 덜 안정적인 분기의 코드는 테스트 및 팀의 일반적인 승인을 거쳐 최종적으로 더 안정적인 것으로 간주되는 분기로 "졸업"됩니다.
단계별로 이 모델의 워크플로우는 다음과 같습니다.
- 당신은 버그를 고쳐야 합니다.
- develop 브랜치를 기반으로 myfix라는 브랜치를 만듭니다.
- 버그가 수정될 때까지 이 항목 분기에서 버그를 수정합니다.
- 내 수정사항을 개발에 병합합니다.테스트를 실행합니다.
- 수정 작업을 하는 동안 동료가 개발에 병합한 수정 사항을 다른 항목과 분기하여 수정 사항이 충돌하는 것을 발견할 수 있습니다.
- 이러한 충돌을 처리하기 위해 myfix 분기를 더 변경합니다.
- 내 수정사항을 개발에 병합하고 테스트를 다시 실행합니다.
- 모든 것이 잘 작동합니다.병합이 마스터로 발전합니다.
- 마스터에서 프로덕션으로 언제든지 배포할 수 있습니다. 안정적이기 때문입니다.
이 워크플로우에 대한 자세한 내용은 Pro Git의 Branching Workflow 장을 참조하십시오.
초보자로 들어와 소스 제어를 사용해 본 적이 없는 다른 개발자들에게 가르칠 간단한 전략을 찾고 있습니다.이것이 http://nvie.com/posts/a-successful-git-branching-model/ 에 맞는 것입니다. 저는 man 페이지에 있는 표준 GIT 워크플로우를 사용하려고 했지만 그것은 저와 청중을 완전히 혼란스럽게 했습니다.
지난 6개월 동안 저는 갈등을 두 번만 고치면 되었습니다.병합 후 항상 테스트하고 기능을 개발하는 동안 'fetch and merge' 또는 'pull --rebase'를 많이(오전과 오후에 한 번) 수행하는 단계를 추가했습니다.우리는 또한 github.com 을 최신 코드를 끌어내는 중심 장소로 사용했습니다.
(처음에 제가 했어야 했던 것처럼, 제 의견을 자체 답변 위에 작성했습니다.)
Github의 Scott Chacon으로부터:
GitHub Flow란 무엇입니까?
- 마스터 분기의 모든 항목을 배포할 수 있습니다.
- 새로운 작업을 수행하려면 마스터에서 설명적으로 이름이 지정된 분기(즉, new-oauth2-scopes)를 만듭니다.
- 로컬에서 해당 분기에 커밋하고 정기적으로 서버의 동일한 명명된 분기에 작업을 푸시합니다.
- 피드백이나 도움이 필요하거나 분기를 병합할 준비가 되었다고 생각되는 경우 끌어오기 요청을 엽니다.
- 다른 사용자가 피쳐를 검토하고 종료한 후 마스터로 병합할 수 있습니다.
- 병합되고 '마스터'로 푸시되면 즉시 배포할 수 있으며 배포해야 합니다.
자세한 내용은 전체 기사를 참조하십시오. http://scottchacon.com/2011/08/31/github-flow.html
"구매 요청"은 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
VCS에서 "마스터" 분기만 있으면 한 분기에서 모든 개발 작업을 동시에 수행할 수 없기 때문에 한계가 빠르게 나타납니다.
이는 언제 지점을 설치해야 하는지 알아야 한다는 것입니다.
그러나 DVCS("분산형" VCS에서처럼)에서는 저장소에 로컬로 유지하는 분기와 푸시하거나 풀링하는 분기가 있는 게시 문제도 있습니다.
이러한 맥락에서, 동시 개발 노력을 파악하는 것으로 시작하여 게시(푸시/풀) 프로세스를 결정합니다.예를 들어, 이것이 유일한 방법은 아닙니다.
- 는 운영입니다.모든 사용자가 다음과 같은 작업을 수행할 수 있습니다.
- 그 위에 현재 개발된 것을 다시 기반으로 함(로컬 테스트 또는 prod 브랜치의 prodrepo에서 수행된 핫픽스를 로컬 개발자에게 통합하기 위해)
- (알려진 안정적인 코드에서) 새 기능을 수행하기 위한 분기
- 다음 릴리스 분기(운영 중인 분기)를 시작하는 분기
아무도 직접 밀어 prod(읽기 전용)를 실행해서는 안 됩니다.
- 이며, 릴리스의 .release는 "-"-", ""라는 이름으로 표시됩니다.
모든 사용자가 릴리스를 푸시하여 다음 릴리스를 업데이트할 수 있습니다.
모든 사용자는 로컬 통합 프로세스를 업데이트하기 위해 해당 릴리스에서 사용할 수 있습니다. - featureX는 (중앙 prorepo로 푸시할 필요가 없다는 점에서) 개인 읽기-쓰기 분기이며, dev repos 간에 푸시/풀링할 수 있습니다.일상적인 개발과는 다른 중장기적인 노력을 나타냅니다.
- master는 현재 dev를 나타내며 dev 저장소 간에 푸시/슬립됩니다.
이 SO 질문에서 알 수 있듯이 다른 릴리스 관리 프로세스가 있습니다.
Agile 팀을 위한 ReinH의 Git Workflow를 읽어 보십시오. http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
이것은 소규모 팀에게 매우 효과적입니다.여기서의 목표는 잠재적으로 불안정할 수 있는 모든 것들이 어떤 종류의 분기에 들어가도록 하는 것입니다.기능 분기 외부에서 작업하는 모든 사용자가 마스터를 사용할 준비가 되었을 때만 마스터에 다시 병합하십시오.
참고: 이 전략은 구체적이지 않지만 Git을 사용하면 이 전략을 구현하기가 매우 쉽습니다.
언급URL : https://stackoverflow.com/questions/2428722/git-branch-strategy-for-small-dev-team
'programing' 카테고리의 다른 글
| SpringBootTest의 @DataJpaTest에서 구성 클래스를 가져오려면 어떻게 해야 합니까? (0) | 2023.07.09 |
|---|---|
| 각도 오류: '구성 요소 'X'가 모듈에 포함되어 있지 않습니다.하위 모듈에 선언된 경우 (0) | 2023.07.09 |
| 탁월한 전자 메일 검증 공식 (0) | 2023.07.09 |
| Ruby Regexp 그룹 일치, 한 줄에 변수 할당 (0) | 2023.07.09 |
| Firestore: 부등식/비등식 쿼리를 수행하는 방법 (0) | 2023.07.09 |