Git에서 테스트 브랜치 사용

우리는 새로운 기능과 버그 수정을 테스트하는 누군가를 테드라고 부릅니다.

우리는 Git 과 GitHub를 사용 하고 있습니다 . master항상 배포 가능해야하며 developmentTed에서 테스트 한 후에 만 ​​새 기능 또는 버그 수정을 커밋 / 병합합니다.

이 프로젝트는 PHP로되어 있습니다.

테스트 프로세스를 다음과 같이 진행하고 싶습니다.

1. 그가 끌어 때문에 개발자는, (하자 테드 123은 이슈 트래커에 설명 된 기능 / 버그 # 말)의 새로운 기능에 대한 작업에 원하는 origin/development에 development자신의 로컬 저장소에와 (의 말을하자 새로운 지점을 생성 issue-123부터)가.
2. 작업에 만족하면 새 지점을 커밋하고 푸시합니다 origin.
3. Ted가 연결되어 test.ourproject.com/choose-branch분기 목록을보고 켜도록 origin선택합니다 issue-123(웹 페이지를 통해 가능해야 함). 그런 다음에 계속 test.ourproject.com해서 웹 애플리케이션에서 지옥을 테스트하고 (정말 불쌍한) 개발자와 이야기를 나눈 후이 기능에 만족합니다.
4. 테드는 그가 병합 할 수 있습니다 개발자 지시 issue-123에 development에를 origin.
5. 헹구고 반복하십시오.

세 번째 단계에서는 작업을 수행하는 특정 작업 (해당 페이지에서 분기 표시 및 전환)을 해킹 할 수 있지만 설명한 내용이 매우 일반적인 패턴이라고 생각합니다.

그래서 내 질문은 : 이것은 분기를위한 좋은 / 지속 가능 / 유지 관리 가능한 워크 플로우입니까? 이 워크 플로에 이어 다른 프로젝트의 예를 인용하여 답변을 백업 할 수 있습니까?

브랜치 워크 플로는 gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow 와 비슷하며 지원 도구가 있습니다. 적극 권장합니다.

테스터가 하나 뿐인 경우 테스트 워크 플로는 훌륭하지만 여러 사람이있는 경우 개발이 시작과 완료 사이에 이동할 수 있으며 물론 병합 후 테스트를 완벽하게 수행해야합니다. 여기에서 자동화 된 테스트가 실제로 도움이되거나 느린 (완전한) 테스터가 완료되지 않을 수 있습니다!

또 다른 문제는 많은 기능과 브랜치에서 기능을 혼합하여 릴리스 (또는 승인 및 병합 후 제거하도록 선택) 또는 기능이 서로 종속되어 있는지 확인하려는 유혹을받습니다. 문제는 게시 지점을 multidev 저장소로 푸시 한 지점에서 히스토리를 다시 작성 (커밋 또는 병합 리베이스 / 삭제)하려는 경향이 있다는 것입니다. 이것은 공개 역사를 다시 쓰고 있습니다. 그것은 선악을 위해 행해질 수 있으며 선을 행하여도 악의에 문제를 일으킬 수 있으며, 최선의 방법은 그것을 피하는 것이므로 질문은 결코 일어나지 않을 것입니다. 그러나 일부 통합 브랜치 워크 플로는 이러한 유혹을 매우 유혹하므로 해당 브랜치 (예 : 사용자 브랜치 별 gitolite)에 대한 강력한 보호 기능이 있고 사람들이 그러한 활동을 기대할 경우 항상 그러한 브랜치에서 코드를 리베이스하고 조심스럽게 진행하십시오!

또한 이러한 모든 문제에 대해 설명하고 많은 참고 문헌이있는 http://sethrobertson.github.com/GitBestPractices/ 를 읽는 것이 좋습니다 .

전환 페이지 자체가 일반적인 패턴인지 확실하지 않습니다. 대부분의 프로젝트는 아마도 테스터가 git 명령으로 체크 아웃하도록 할 것입니다.

일반적인 접근법은 확실히 합리적으로 들립니다.

구글은 비슷한 스타일을 지원하기 위해 Gerrit 를 썼다 . 코드 검토에 관한 것이지만 통합 승인에는 일반적으로 검토와 테스트가 모두 포함됩니다. 일반적으로 모든 제출을 먼저 빌드하는 연속 통합 서버와 상호 연결됩니다 ( Google에서 Jenkins 를 사용하는지 확실하지 않지만 어딘가에서 적절한 커넥터를 본 것으로 생각합니다).

힘내 자체는 테마에 약간의 변형을 사용합니다. 관리자는 보류중인 모든 제출을이라는 분기로 병합하는 스크립트를 가지고 있습니다 pu(아마 "제안 된 업데이트"의 경우, 보류중인 제출이 종종 기반이 될 때마다 분기가 삭제되고 다시 작성 됨). 이것은 여러 사람들에 의해 테스트 된 것보다. 괜찮 으면 완료된 것으로 간주되는 제출물이 next(와 동일)에 병합됩니다 development. 그렇지 않은 경우 누군가가 개별 제출을 테스트하여 어떤 제출이 손상되었는지 확인합니다. 테스터는 대부분 분기를 전환 할 필요가 없으므로 테스터에게는 약간 더 쉽습니다. 테스트 통합이 작동하는지 여부 만보고합니다.

테스트가 수동이 아닌 자동으로 수행되는 경우 Travis (GitHub의 CI 시스템)는 원하는 작업을 거의 수행 할 것입니다. 모든 풀 요청에 대해 자동으로 테스트를 실행합니다. ( 스크린 샷을 포함하여이 프로세스에 대한 자세한 정보 )

테스트는 브랜치가 아니라 마스터로 병합 된 후의 브랜치에서 실행됩니다. (즉, 브랜치를 마스터에 병합 한 후 얻을 수있는 것-병합 후 테스트가 여전히 성공적으로 실행된다는 보장이 있습니다.)

커밋이 분기에 추가되면 테스트가 다시 실행됩니다. (어떤 이유로 마스터에 커밋을 추가해도 테스트가 다시 실행되지 않는 것 같습니다.)