Git을 사용할 때 적극적인 개발을 위해 마스터 브랜치를 사용하고 있습니까?

첫째, 일부 배경, 우리는 모든 프로젝트 팀을 git 사용으로 옮기는 과정에 있으며 특정 지점을 지속적으로 통합하고 모니터링 할 수 있도록 리포지토리를 구성하는 방법에 대한 지침을 마련하는 과정에 있습니다. 테스트 서버에 자동 배포 현재 개발중인 두 가지 모델이 있습니다.

1. 가장 안정적인 코드를 나타내는 마스터 브랜치, 블리딩 에지 ​​코드를위한 개발 브랜치, QA 테스트를 위해 준비된 코드를위한 통합 브랜치로 성공적인 브랜칭 에 대한 nvie.com 기사의 영향을 크게 받았습니다 .

2. 마스터 브랜치가 최첨단 개발 코드, QA 테스트 준비가 된 코드의 통합 브랜치, 배포 준비가 된 안정적인 코드의 생산 브랜치를 나타내는 대체 모델입니다.

이 시점에서 이는 마스터 브랜치가 나타내는 것과 관련하여 부분적으로 의미론의 문제이지만 마스터 브랜치에서 실제로 개발하는 것은 실제로 좋은 습관입니까, 아니면 실제로는 관련이 없습니까?

master지점 의 유일한 실제 정의 기능은 일부 작업의 기본값이라는 것입니다. 또한 지점 이름은 특정 저장소 내에서만 의미가 있습니다. 내가 master당신을 가리킬 수 있습니다 development예를 들어,. 또한 master지점이 필요하지 않으므로 어떤 지점에 대해 혼란이 있으면 일반적으로 내 조언을 사용하지 않는 것이 좋습니다.

그러나 제 생각에, 그것을 생각하는 가장 좋은 방법은 추진의 기본입니다. 개발자가 읽는 대부분의 온라인 자습서는이를 가정합니다. 따라서 master가장 자주 추진되는 지점이 무엇인지 이해하는 것이 좋습니다 . 어떤 사람들은 그것을 엄격한 조사를 거친 후를 제외하고는 개발자가 손대지 못한 깨끗한 사본으로 생각하지만, 그런 방식으로 사용하면 git이 제공하는 많은 유용한 기본값을 제거합니다. 그런 종류의 깨끗한 지점을 원한다면 일부 사람들 만 쓸 수있는 완전히 별도의 저장소에 넣을 것입니다.

아니요, 품질 관리에 가기 전에 처음부터는 권장되지 않습니다. 모범 사례로서 개발 패턴은 처음부터 끝까지 일관되어야합니다. 마스터 브랜치는 빈 상태로 시작해야하며 개발 브랜치는 오프하고 파일을 추가하고 통합 브랜치에 병합 한 다음 마스터로 병합해야합니다.

마스터 브랜치가 구축하지 않은 개발 중에는 아무도 신경 쓰지 않지만 초기에는 나쁜 습관에 빌려줍니다. 마스터는 항상 빌드해야하며 주요 기능 릴리스의 경우 주요 빌드의 분기를 아카이브하여 필요한 경우 안정적인 릴리스 포인트를 리턴 할 수 있도록하는 것은 좋은 생각이 아닙니다.