힘내-마스터에 직접 작업하면 어떤 문제가 발생합니까?

git 브랜치 모델에 대한 많은 조언을 보았으며 가장 일반적인 의견은 마스터 브랜치에서 직접 변경하는 것이 좋지 않다는 것입니다.

우리 동료 중 한 명이 마스터 지점에서 직접 변경하는 것을 매우 기쁘게 생각하며 여러 대화에도 불구하고 변경하지 않을 것으로 보입니다.

이 시점에서 나는 마스터에게 직접 일하는 것은 나쁜 습관 인 동료를 설득 할 수 없지만 그의 작업 방식과 상충되는 것을 이해하고 다시 방문해야 할 때를 알고 싶습니다. 이 문제.

커밋이 직접 마스터로 푸시 될 때 몇 가지 문제가 있습니다

• 진행중인 작업 상태를 원격으로 푸시하면 마스터가 손상되었을 수 있습니다.
• 다른 개발자가 마스터에서 새 기능에 대한 작업을 시작하면 잠재적으로 고장난 상태로 시작합니다. 이것은 개발 속도를 늦춘다
• 다양한 기능 / 버그 수정이 분리되어 있지 않으므로 진행중인 모든 개발 작업의 복잡성이 한 지점으로 결합됩니다. 이것은 모든 개발자들 사이에 필요한 커뮤니케이션의 양을 증가시킵니다
• 코드 검토를위한 매우 좋은 메커니즘 인 풀 요청을 수행 할 수 없습니다.
• 다른 개발자가 그동안 마스터 브랜치를 이미 가져 왔을 수 있으므로 일반적으로 커밋 / 변경 내역을 스쿼시 할 수 없습니다

새로운 기능에는 프로덕션 환경으로 넘어 가기 전에 테스트 환경에 배포 할 수있는 자체 개발 브랜치가 필요 하다고 설명합니다 .

그렇지 않으면 영구적으로 절반 완성 된 기능 상태입니다. 절반 완성 된 기능을 프로덕션에 배포 할 수 없으므로 마스터 지점에서 직접 작업하는 경우 다른 사람이 버그 수정을 포함하여 다른 사람의 변경 사항이 프로덕션으로 이동하기 전에 기능이 완료 될 때까지 기다려야합니다.

기능에 독립적 인 분기를 사용한다는 것은 각각의 새로운 기능이 다른 기능과 독립적으로 테스트되고 배포 될 수 있음을 의미합니다.

마스터는 잠재적으로 출시 가능해야합니다. 기간. 마스터에서 작업이 절반으로 완료되어서는 안됩니다 (기능 플래그로 비활성화되지 않은 경우)

그것으로 나는 일부 팀들이 그들의 흐름을 복잡하게하는 것을 보았다.

마스터에 통합 할 때 PR을 사용하지 않는 것은 실수입니다. 개발자는 통합이 발생할 때 선택할 힘이 없기 때문입니다.

단일 개발 지점은 가치가 거의 없습니다. 일반적으로 문제를 복잡하게 만듭니다. 많은 기능 지점이 많은 가치를 제공합니다.

각 환경 (dev, test, prod)에 대한 브랜치를 만드는 것은 실수입니다. 이것은 git의 범위를 벗어 났으며 릴리스 파이프 라인에서 처리해야합니다. 각 환경에 대한 분기가있는 경우 불가능한 모든 환경에 정확히 동일한 빌드를 배포해야합니다.

기능이 너무 크면 하루나 이틀 안에 기능을 수행 할 수 없습니다. 기능 분기에 대한 모든 작업은 별도의 분기에 있고 PR과 통합되어야합니다.

• 마스터는 작업중인 최종 버전 인 생산 지점을 반영해야합니다.
• 마스터에서 직접 작업한다는 것은 버그를 생성하면 커밋을 취소 / 삭제 / 재설정하는 것 외에 "돌아 가기"에 대한 다른 옵션이 없다는 것을 의미합니다. 이는 깔끔한 작업 방법이 아니며 괜찮 았습니다.
• 물론, 개발의 첫 단계에서 아마도 직접 마스터 작업을 시작할 수 있지만, 무언가를 제공 한 후에는 개발, 테스트 또는 실험 브랜치를 사용하여 게시 된 완전한 작업 버전을 건드리지 않아야합니다.

먼저, git에서 모든 pull것이 문자 그대로 분기 작업이며 모든 push것이 병합 임을 지적하고 싶습니다 . master개발자의 컴퓨터에이에서 완전히 분리 된 지점입니다 master기술적 인 관점에서 동일한 서, 공유 중앙의 repo에. upstream내 목적에 더 잘 맞는 경우 로컬 버전의 이름을 바꾸 거나 다른 것으로 바꾸는 경우가 있습니다.

많은 조직에서 동료보다 지점을 더 효과적으로 사용하고 있다고 생각하기 때문에 실제로 지점에 대한 추가 이름을 만드는 것보다 조금만 더 노력하면 역사에 저장되지 않습니다. 동료가 하나의 원자 적 커밋으로 기능을 커밋하는 경우 기능 브랜치의 병합 커밋만큼 쉽게 제거 할 수 있습니다. 대부분의 기능 지점은 수명이 짧고 어쨌든 자주 병합되어야합니다.

즉, 그의 작업 스타일의 주요 단점은 두 가지입니다. 첫째, 미완성 기능에 대해 협업하기가 매우 어렵습니다. 그러나 협업이 필요한 시점에 지점을 만드는 것은 어렵지 않습니다.

둘째, 병합하기 전에 검토하기가 매우 어렵습니다. 이 시점에서 실제로 그를 설득 할 필요는 없습니다. github, gerrit 또는 gitlab과 같은 도구를 채택하고 풀 요청 코드 검토가 필요하고 모든 병합에 대해 자동화 된 테스트를 통과했습니다. 이와 같은 일을하지 않으면 솔직히 git을 최대한 활용하지 않고 동료가 그 잠재력을 보지 못하는 것은 아닙니다.

다른 답변은 이미 마스터에서 작동하지 않는 다양한 이점 (절연 기능, 항상 배송 가능한 코드 등)을 언급했습니다.

나를 위해 당신은 다른 문제가있는 것 같습니다. 분명히 모든 개발자가 동의하거나 사용하는 개발 프로세스가 없습니다 (또는 문제의 개발자가 프로세스를 완전히 무시하고 있음).

피처 브랜치가 마스터로 병합되었거나 다른 릴리스 브랜치가 있거나 완전히 다른 프로세스를 사용합니까?

"마스터 브랜치를 사용하지 마십시오"는 충분하지 않습니다.

우리 동료 중 한 명이 마스터 지점에서 직접 변경하는 것을 매우 기쁘게 생각하며 여러 대화에도 불구하고 변경하지 않을 것으로 보입니다.

이것은 더 많은 문제가 있다고 믿게합니다. 마스터 여부에 대한 작업은 제품 출시 방법,시기 및시기에 대한 더 큰 철학의 일부입니다.

"마스터 작업을해서는 안됩니다"와 함께 기능을 테스트하고, 서로의 작업을 테스트하고, 서로의 코드를 검토합니까? 수락 및 통합 테스트.

위의 내용이없고 그냥 "git"을하기 위해하고 있다면, master에서 작업하는 것이 좋습니다.

지점에서 직접 일하는 것에 대한 "나쁜 실천"은 없습니다. 그러나 프로세스를 가장 잘 지원하는 것을 결정해야합니다.

질문 1 : 마스터가 소프트웨어의 현재 릴리스 상태를 나타내야합니까? 그런 다음 글로벌 개발 브랜치를 소개하고 릴리스 개발 종료시 개발을 병합해야합니다.

질문 2 : 코드 검토 프로세스를 원하십니까? 그런 다음 끌어 오기 요청을 통해 마스터에 병합되는 "기능 분기"가 있어야합니다.

질문 3 : 프로덕션 (또는 테스트)에 아직 게시하지 않아야하는 다른 개발자와 중간 코드 상태를 공유해야합니까? 둘 이상의 개발자가 기능을 개발하는 경우입니다. 그런 다음 "기능 지점"을 소개해야합니다.