GitHub에서 프로젝트 버전을 어떻게 제어해야합니까

나는 오늘날 GitHub에서 할 수있는 한 많은 시간을 ( 실제로 팀에서 일하는 유일한 사람이라 할지라도) 실제 기업 응용 프로그램에 대한 느낌을 느끼기 위해 노력 하고 있습니다.

내가 가진 질문 중 하나는 버전 을 제어하는 ​​것 입니다. 우리가 프로젝트를 시작했다고 가정 해 봅시다. 그런 다음 팀 구성원이 일부 지점을 만들어 개발했습니다. 생산 준비가되면 모든 지점을 master지점 과 병합했습니다 . 결국, 우리는 version으로 시작 1.0합니다.

이제 해당 버전 1.0이 작동 중이며 해당 소프트웨어 버전에 대해 일부 문제가 제기되었습니다. 1.1프로젝트를 서두르면서 도입 한 문제를 해결하기 위해 버전 개발을 시작하고 싶습니다 .

이제 문제는 이것입니다.

여기서 버전 관리를 어떻게 제어해야합니까?

소프트웨어 v1.0버전 1.0을 위한 새로운 브랜치를 생성 하고 유지하고 일부 브랜치에서 개발하거나 (또는 ​​그렇지 않은 경우) 통합하고 master버전 과 합병해야 1.1합니까?

그런 상황에 대한 협약이 있습니까?

나는 다음과 같은 지점 모델 을 발견하고 채택하기 시작했다 .

^{(기사의 이미지)}

이 기사에 설명 된 많은 모범 사례와 엄격한 규칙이 있으므로 강력히 권장합니다.

가볼만한 곳:

• 마스터 브랜치는 버전을 태그하는 곳입니다. 여기서는 발전이 없습니다. 프로덕션에 배포 된 버그의 경우 핫픽스 분기의 버그를 수정하고 병합하여 새 버전에 태그를 지정합니다.
• 개발은 기능 및 기능 분기에서 발생합니다. 개인적으로, devel 브랜치에서 기능을 수정하고 기능 브랜치에서 기능을 수행합니다.
• 소프트웨어가 릴리스에 도달하기 시작하면 분기를 해제하기 위해 분기합니다. 릴리스 브랜치는 마지막으로 다루는 곳입니다. 범프 버전 번호, 메타 데이터 변경 등 사소한 버그 수정. 완료되면 마스터에 병합하고 태그를 지정하고 버전이라고 부릅니다.
• 두 가지 주요 지점 : 마스터는 "신성한 지점"입니다. HEAD는 항상 최신 생산 코드이며 개발은 야간 분기입니다. HEAD는 항상 코드에 최신 (그러나 불안정한) 추가 사항을 반영합니다.

구체적인 경우 단계는 해당 버전이 얼마나 급한 지에 따라 다릅니다. 누락 된 기능이라면 개발 릴리스로 돌아가서 모든 작업을 다시 수행합니다. 배포 된 버전의 버그 인 경우 핫픽스 브랜치로 분기하여 버그를 수정하고 병합하여 v1.1 태그를 지정합니다. 둘 다인 경우 먼저 버그를 수정 한 다음 설명대로 기능을 두 번째로 추가합니다.

내가 가장 많이 목격 한 것은 :

• 마스터는 당신을위한 제품입니다. 결국 모든 향후 버전 x.0이 마스터가 될 것입니다.
• 프로덕션에서 각 버전에 대한 태그 / 분기를 작성하여 필요한 모든 고객에 대해 해당 태그 / 분기를 계속 지원할 수 있습니다.
• 둘 중 하나에서 수정 사항을 병합하는 것은 사례별로 처리하는 것입니다.