소규모 개발팀을 위한 Git 브랜치 전략 [닫기]

StackOverflow https://stackoverflow.com/questions/2428722

  •  19-09-2019
  •  | 
  •  

문제

우리는 거의 매일 업데이트하고 출시하는 웹 앱을 가지고 있습니다.우리는 VCS로 git을 사용하고 있으며 현재 분기 전략은 매우 간단하고 깨졌습니다.우리는 마스터 브랜치를 가지고 있고 우리가 '좋아요'라고 느끼는 변경 사항을 확인합니다.이것은 작동하지만 주요 변경 사항을 확인할 때까지만 가능합니다.

좋아하는 git 브랜치 전략을 갖고 있는 사람이 있나요? 소규모 팀 이는 다음 요구 사항을 충족합니다.

  1. 2~3명의 개발자로 구성된 팀에 적합
  2. 가볍고 프로세스가 너무 많지 않음
  3. 개발자가 버그 수정 및 더 큰 기능에 대한 작업을 쉽게 격리할 수 있습니다.
  4. 안정적인 브랜치를 유지할 수 있습니다(프로덕션 서버를 작동시켜야 하는 '아 젠장' 순간을 위해).

이상적으로는 새로운 버그를 작업하는 개발자를 위한 단계별 프로세스를 보고 싶습니다.

도움이 되었습니까?

해결책

Scott Chacon이 설명하는 워크플로의 이점을 누릴 수 있습니다. 프로 Git.이 워크플로에는 항상 존재하는 두 개의 분기가 있습니다. 주인 그리고 개발하다.

주인 프로젝트의 가장 안정적인 버전을 나타내며 이 분기에서만 프로덕션에 배포할 수 있습니다.

개발하다 진행 중인 변경 사항이 포함되어 있으며 반드시 프로덕션 준비가 되지 않았을 수도 있습니다.

로부터 개발하다 브랜치에서는 개별 기능 및 수정 사항에 대한 작업을 위해 주제 브랜치를 생성합니다.기능/수정이 준비되면 이를 다음으로 병합합니다. 개발하다, 이 시점에서 동료가 병합한 다른 주제 브랜치와 어떻게 상호 작용하는지 테스트할 수 있습니다.한 번 개발하다 안정적인 상태에 있으므로 병합하세요. 주인.프로덕션 환경에 배포하는 것은 항상 안전해야 합니다. 주인.

Scott은 이러한 장기 실행 분기를 코드의 "사일로"라고 설명합니다. 여기서 덜 안정적인 분기의 코드는 테스트 및 팀의 일반적인 승인 후에 결국 더 안정적인 것으로 간주되는 코드로 "졸업"됩니다.

단계별로 이 모델의 워크플로는 다음과 같습니다.

  1. 버그를 수정해야 합니다.
  2. 라는 지점을 만듭니다. 마이픽스 그것은에 기초한 것입니다. 개발하다 나뭇가지.
  3. 버그가 수정될 때까지 이 주제 분기의 버그에 대해 작업하세요.
  4. 병합 마이픽스 ~ 안으로 개발하다.테스트를 실행합니다.
  5. 다른 주제 브랜치와의 수정 충돌을 발견했습니다. 그의 고정 당신의 동료가 합병한 곳 개발하다 당신이 수리 작업을 하는 동안.
  6. 더 많은 변경사항을 적용하세요. 마이픽스 이러한 갈등을 처리하기 위해 분기합니다.
  7. 병합 마이픽스 ~ 안으로 개발하다 그리고 다시 테스트를 실행해 보세요.
  8. 모든 것이 잘 작동합니다.병합 개발하다 ~ 안으로 주인.
  9. 다음에서 프로덕션에 배포 주인 언제든지 안정적이라는 것을 알고 있기 때문입니다.

이 워크플로에 대한 자세한 내용은 다음을 확인하세요. 분기 작업 흐름 Pro Git의 장.

다른 팁

소스 제어를 사용해 본 적이 없는 다른 개발자에게 가르칠 수 있는 간단한 전략을 찾으려고 초보자로 들어온 후입니다.이게 딱 맞는거네 http://nvie.com/posts/a-successful-git-branching-model/ 매뉴얼 페이지에 있는 표준 GIT 작업 흐름을 사용해 보았으나 저와 청중이 완전히 혼란스러웠습니다.

지난 6개월 동안 저는 충돌 문제를 두 번만 해결해야 했습니다.기능을 개발하는 동안 병합 후 항상 테스트하고 '가져오기 및 병합' 또는 '풀-리베이스'를 많이(아침과 오후에 한 번) 수행하는 단계를 추가했습니다.우리는 또한 최신 코드를 가져오기 위한 중앙 장소로 github.com을 사용했습니다.

(내가 만든 논평 위에는 내가 처음에 했어야 했던 것처럼 자체 답변입니다.)

Github의 Scott Chacon에서:

우리가 하는 방법 그렇다면 GitHub Flow란 무엇입니까?

  • 마스터 브랜치의 모든 항목을 배포할 수 있습니다.
  • 새로운 작업을 수행하려면 master에서 설명이 포함된 이름의 분기를 만듭니다(예:새로운 oauth2-범위)
  • 해당 브랜치를 로컬로 커밋하고 정기적으로 작업을 서버의 동일한 이름의 브랜치로 푸시합니다.
  • 피드백이나 도움이 필요하거나 브랜치를 병합할 준비가 되었다고 생각되면 풀 리퀘스트
  • 다른 사람 이이 기능을 검토하고 서명 한 후에는 마스터에 병합 할 수 있습니다.
  • 병합되어 '마스터'로 푸시되면 즉시 배포할 수 있고 배포해야 합니다.

자세한 내용은 전체 기사를 참조하세요. http://scottchacon.com/2011/08/31/github-flow.html

"풀 요청"은 Github의 발명품이며 Git 자체가 아닌 Github의 웹사이트에 포함된 것입니다. 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는 프로덕션에 코드가 있는 읽기 전용 공개 브랜치입니다.누구나 다음을 위해 이를 활용할 수 있습니다.
    • 그 위에 현재 개발을 리베이스합니다(로컬 테스트를 위해 또는 로컬 개발 저장소에 prod 브랜치의 prod 저장소에서 수행된 핫픽스를 통합하기 위해).
    • 새로운 기능을 수행하기 위한 분기(알려진 안정적인 코드에서)
    • 다음 릴리스 브랜치를 시작하는 브랜치(프로덕션에 포함될 브랜치)
      누구도 prod에 직접 푸시하면 안 됩니다(따라서 읽기 전용).
  • release는 관련 커밋이 다음 릴리스의 일부로 선택되는 읽기-쓰기 통합 분기입니다.
    누구나 다음 릴리스를 업데이트하기 위해 릴리스를 추진할 수 있습니다.
    로컬 통합 프로세스를 업데이트하기 위해 누구나 해당 릴리스에서 가져올 수 있습니다.
  • featureX는 비공개 읽기-쓰기 분기이며(중앙 프로덕션 저장소로 푸시할 필요가 없음) 개발 저장소 간에 푸시/풀이 가능합니다.일상적인 개발과는 다르게 중장기적인 노력을 나타냅니다.
  • master는 현재 개발을 나타내며 개발 저장소 간에 푸시/풀됩니다.

다른 릴리스 관리 프로세스도 존재합니다. SO 질문은 증명합니다.

여기에서 ReinH의 애자일 팀을 위한 Git 워크플로를 읽어보세요. http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

이는 소규모 팀에 매우 효과적입니다.여기서 목표는 잠재적으로 불안정할 수 있는 모든 항목이 일종의 분기로 들어가도록 하는 것입니다.기능 브랜치 외부에서 작업하는 모든 사람이 사용할 준비가 된 경우에만 마스터로 다시 병합하세요.

메모:이 전략은 git에만 적용되는 전략은 아니지만 git을 사용하면 이 전략을 매우 쉽게 구현할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top