여러 git 워크플로를 살펴본 결과 그 중 어느 것도 내 현재 프로세스와 일치하지 않는다는 느낌이 들었습니다. 현재 프로덕션 환경, 테스트 환경, 로컬 환경의 세 가지 환경이 있습니다. 개발자는 로컬에서 개발하고 테스트 환경으로 푸시하며 테스터는 테스트 환경에서 테스트하고 승인합니다.
현재는 12명 이상의 소규모 팀만 보유하고 있기 때문에 구체적인 버전 출시 프로세스가 없기 때문에 특정 날짜에 출시할 특정 버전이나 완료해야 할 작업이 없습니다. 모든 사람의 작업은 Hotfix를 수행하는 것과 비슷하며, 작은 기능을 완료하거나 작은 버그를 수정한 후 직접 개발 브랜치로 푸시하여 문제가 없으면 테스트 환경을 테스트합니다. 개발을 마스터에 직접 병합하고 릴리스하세요! 이 과정은 사람이 적을 때 괜찮습니다. 사람이 조금 더 있으면 온라인으로 진행되는 기능이 있고 아직 테스트 단계인 다른 기능이 포함되어 병합할 수 없습니다. 테스트가 끝날 때까지 기다리세요...
함수 브랜치 모델을 기반으로 하면 위의 문제는 함수를 수행하거나 버그를 수정하기 위해 브랜치를 잘라서 테스트용으로 병합하고 테스트를 통과한 후 마스터에 병합할 수 있을 것으로 보입니다. 마스터는 언제든지 프로덕션 환경으로 푸시될 수 있습니다. 하지만 또 다른 문제는 팀 구성원의 수준이 균일하지 않다는 점입니다. 마스터로 병합하는 권한은 모든 사람에게 부여될 수 없습니다. 즉, 마스터로 병합하는 작업은 한 사람 또는 한 사람만 수행할 수 있습니다. 전부는 아니지만 매일 많은 브랜치가 생성될 수 있습니다. 텍스트 한 줄을 수정하는 것조차 브랜치일 수 있습니다. 이러한 작은 브랜치를 수동으로 병합하는 것은 PR을 제출하는 방식과 다소 유사합니다. 효율성이 부족해요...
테스터가 테스트 시간에 맞춰 언제 어디서나 수정 사항을 확인할 수 있는 방법이 있습니까? 선별적으로 행동하세요! 코드를 프로덕션 환경에 병합하시겠습니까?
仅有的幸福2017-05-02 09:39:28
저희 워크플로와 매우 유사하지만 버전 출시를 위한 특정 시간을 명시했습니다. 버전이 출시된 후 개발자는 자체 브랜치에서 개발한 다음 병합할 때 병합 요청을 보냅니다. 감독관에게 동의하면 브랜치를 개발하고 테스트도 진행한 후 문제가 없으면 메인 브랜치로 이동합니다.
世界只因有你2017-05-02 09:39:28
예를 들어 A가 함수를 만들면 직접 테스트해야 하며 개발 브랜치를 푸시한 다음 누가 릴리스하든 전체 기능이 완료되었는지 테스트하기 전에 문제가 없습니다. 이번 버전에서는 이 과정을 거쳐야 합니다. 개발 시 테스트 중인 코드가 있는데 푸시해야 할 긴급한 버그 수정이 있는 경우 일반적으로 두 가지 방법이 있습니다. 하나는 개발 시 테스트 중인 코드를 선별하는 것이고, 다른 하나는 비상 브랜치를 사용하는 것입니다.
阿神2017-05-02 09:39:28
git Cherry-pick
이 명령은 선택적으로 커밋을 병합할 수 있습니다. 알림 테스트의 경우 병합 후 지정된 이메일 주소로 자동으로 이메일을 보내도록 GitHub를 구성할 수 있습니다.
git 체리픽
