큰 풀 요청 처리

현재 git 워크 플로를 사용하는 팀과 함께 프로젝트를 진행하고 있습니다. 매우 간단합니다. 마스터는 배포 가능한 상태 여야하며 지점은 기능과 핫픽스를 만드는 데 사용됩니다. 기능 또는 버그 수정이 완료되고 테스트 될 때마다 가능한 빨리 마스터로 이동합니다. 아이디어는 브랜치를 마스터로 다시 병합하기 쉽도록 브랜치를 가능한 작게 만들어야한다는 것입니다. 마스터 브랜치로 푸시 된 모든 코드는 배포 가능한 상태에 있어야하고 테스트를 통과해야한다는 정책이 있습니다.

개발자 중 한 명이 단일 지점에서 많은 작업 (몇 달간 가치있는 작업)을 수행했으며이 지점이 아직 마스터로 다시 병합되지 않은 상황이 발생했습니다. 이 브랜치에는 몇 가지 기능과 커밋이 있습니다. 본질적으로이 브랜치는 실제로 몇 번만 다시 병합되었지만 지금까지 없었습니다. 대부분의 코드는 마스터로 다시 병합 될 수있는 단위 테스트를 통해 양호한 상태이지만 가장 최근의 변경 사항은 완료되지 않았으며 테스트되지 않았으므로 확실하지 않아야합니다.

한 지점이 다른 지점과 멀리 떨어져있는 상황을 처리하는 가장 좋은 방법은 무엇입니까? 미래에 지점에서 마스터로부터 많은 수의 커밋을 얻는 것을 피할 수있는 방법은 무엇입니까?

병합하지 않고 몇 달 동안 간 개발자가 문제를 해결하도록합니다. 어쩌면 그들은 큰 코드 덩어리를 병합 할 수도 있고, 작은 덩어리를 한 번에 하나씩 병합 할 수도 있습니다. 어쨌든 그들은 문제를 일으킨 문제를 해결하기 위해 합법적 인 노력을 기울여야합니다.

한 지점이 다른 지점과 멀리 떨어져있는 상황을 처리하는 가장 좋은 방법은 무엇입니까?

일반적으로 걱정하지 마십시오. 다른 개발자의 문제입니다. 두 가지 경우 정말 병합에 너무 멀리 떨어져, 그들은 정말 같은 프로젝트의 일부가 더 이상 아니다 당신은 사실상 포크가 있습니다. 오픈 소스 프로젝트라면 문제가되지 않을 수도 있습니다.

이 개발자가 정말 훌륭하고 다른 팀이 결합한 것보다 코드가 더 똑똑하고 / 더 중요하다면, 자신의 문제 대신 문제를 만드는 것이 좋습니다. 그렇지 않으면 그렇지 않습니다.

문자적인 질문에 대답하기 위해 : 이런 상황을 다루는 가장 좋은 방법은 그런 상황에 처하지 않는 것입니다.

미래에 지점에서 마스터로부터 많은 수의 커밋을 얻는 것을 피할 수있는 방법은 무엇입니까?

병합하지 않고 몇 달 동안 간 개발자가 자신이 일으킨 문제를 해결해야한다는 것을 모든 사람이 알도록하십시오. 변화가 적을수록 갈등의 기회가 줄어들 기 때문에, 자주보다 자주 마스터하는 것이 더 쉽다는 것을 모든 사람에게 알리십시오.

사람들이 다른 사람들의 변경 사항을 최신 상태로 유지하기 위해 마스터에서 끌어낼 수 있음을 알아야합니다.

"매일 합병하면 갑자기 해결하기 어려운 큰 갈등이 생길 때까지 결코 도달 할 수 없습니다." -리누스 토발즈

이 인용문은 그가 Google에서 한 대화, 여기는 대화 내용 및 비디오는 다음 과 같습니다 .

커밋이 있고 이전의 모든 커밋이 잘 테스트되어 병합되어야하는 경우이 마지막 커밋에서 분기하고 새 분기를 마스터와 병합하십시오.

병합하려는 커밋이 있지만 프로덕션 준비가 아닌 다른 커밋과 함께 산재되어 있으면 두 가지 가능성이 있습니다.

1. 새로운 브랜치를 만들고 체리가 좋은 커밋을 선택하고 마스터와 병합하십시오.
2. 원치 않는 커밋을 맨 위로 리베이스하십시오 (안전을 위해 새 브랜치에있을 수 있음).

예방 방법에 대해서는 "일주일 내에 마스터와 병합하지 않는 규칙은 한 달 동안 피자를 주문합니다"와 같은 재미있는 팀 규칙을 정의하십시오.

먼저 @Maciej Chalpuk의 제안과 같이 병합 또는 체리 선택이 가능한 별도의 커밋이 있는지 확인하십시오. 이 경우 상황이 그렇게 나쁘지는 않으며 앞으로는 그 일에 대해 너무 걱정하지 않아도됩니다.

그러나 실제 상황이 동일한 커밋 내에서 단일 지점에서 여러 기능이 동시에 개발 된 경우 처리하기가 훨씬 더 어려워집니다. 운 좋게도 예방 방법이 내장되어 있습니다. 개발자가 각 기능에 대한 변경 사항을 별도의 브랜치로 분리하고 요청을 병합하기 전에 요청을 가져와야합니다. 원자 병합을 가져오고이 개발자가 수행하지 못하도록 설득 할 수 있습니다. 미래.

기능을 분리하는 실제 과정은 전적으로 수동입니다. 마스터에서 새 분기를 작성하고 이와 관련된 메가 분기의 변경 사항을 복사하십시오. 컴파일, 기능 테스트, 풀 요청을 푸시 및 발행하십시오. 코드 변경이 덜 섞여있을수록 더 쉬워집니다. 그가 그들 모두를 위해 하나의 방법을 해킹했다면, 재미있게 보내십시오. 그는 다시는하지 않을 것입니다.

간단한 해결책은 다음과 같습니다.

이 사람이 구현 한 기능을 추적하고 기능별로 업데이트 된 해당 분기의 각 커밋으로 이동하십시오. 이 커밋을 가져와 마스터 리포지토리와 병합하십시오.

이것을 예제의 형태로 세분화하겠습니다.

브랜치 A를 마스터 브랜치의 브랜치 A + = 브랜치 A + 새 기능 1 브랜치 A ++ = 브랜치 A + 새 기능 2 등

당신이해야 할 일은 다음으로 돌아갑니다 : 지점 A +

지점 A +를 가져 와서 마스터와 병합하십시오.

이제 Branch A ++로 이동하여 (Master + Branch A +)와 병합하십시오.

안정적인 최종 지점 A + ... +에 도달 할 때까지 반복하십시오.

이 방법은 처음에는 반 직관적으로 들릴지 모르지만, 각각의 개별 새 기능을 마스터와 자체적으로 병합하면 " 추가 된 기능 당 "마스터 분기간에 쉽게 순환 할 수 있습니다 .

미래에 지점에서 마스터로부터 많은 수의 커밋을 얻는 것을 피할 수있는 방법은 무엇입니까?

위의 해결책은 미래에 어떤 방법을 채택해야하는지 나타냅니다. 각 지사마다 기능별 또는 작업 별 방법을 사용하십시오.

나는 다음의 접근법을 사용하는 것이 좋습니다.

프리 마스터 및 마스터

마스터 : 최종 / 생산 수준. 자주 수정되지 않습니다. 항상 안정적인 것으로 간주됩니다

사전 마스터 : 기존 코드에 새로운 기능이 추가되는 영역입니다. 기존 코드 기반으로 작업하기 위해 철저히 테스트되었으며 다른 지점에서 새로운 기능 구현을 위해 갈 수있는 곳입니다.

또한 번들 기능과 버전 타겟팅을 시도해야합니다.

버전 타겟팅 : 마스터 지점의 자리 표시 자로 사용할 임의의 숫자를 지정하십시오. "V1.0.0에서는 X, Y, Z 기능을 구현하려고합니다. V1.0.0에서도 다음 기능을 모두 사용할 수 있습니다. ..."

마스터에 대해 버전을 유지함으로써 "마스터"를 항상 안정적으로 제작할 수있는 방법이 될 수 있습니다.

큰 풀 요청 문제를 해결하는 것은 한 가지 일이며 이에 관한 좋은 대답이 있습니다. 그러나 구식이 아닌 지점을 처리하는 경우 팀 작업 처리 프로세스를 다시 방문 할 수 있습니다.

Agile 또는 SCRUM 프레임 워크 내에서 작업하는 경우 팀은 왜 기능이 완료되지 않고 반복 / 스프린트의 일부로 병합되지 않은지 묻습니다. 반복에 맞지 않기에 "너무 큰"경우 작은 조각으로 나 should어야합니다.

또한 코드 소유권 문제도 제기합니다. 팀 내에서 개별 개발자가 자신의 작업을 별도로 소유하거나 전체 팀이 함께 작업하여 항목이 완료되도록합니까?

물론, 위의 내용은 귀하의 팀이 어떤 종류의 회사 구조 내에 있다고 가정합니다. 이것이 자원 봉사자들과 함께하는 오픈 소스 프로젝트라면 또 다른 이야기입니다. 일반적으로 이러한 프로젝트는 워크 플로우에 대한 제어가 느슨하지만 수용 가능한 풀 요청을 생성하는 책임은 개별 기여자에게 더 자주 발생합니다.

여러 가지면에서 이것은 프로세스 문제가됩니다. 필요한 프로세스에는 장기간 실행되고 병합되지 않은 분기에 대해 정기적으로 (매주? 매월?) 확인하는 것이 포함됩니다. 일부 도구를 사용하면 시각적으로 간단하게 확인할 수 있습니다. 예를 들어 github에서 "branches"링크를 방문하면 각 분기가 얼마나 앞 / 뒤에 있는지 보여줍니다.