2012-04-04 2 views
7

대규모 프로젝트에 Gerrit를 사용할 것을 고려하고 있습니다. 이 시점에서 사람들이 승인 된 변경 사항의 병합 충돌을 처리하는 방법을 아는 것은 흥미로울 것입니다.Gerrit 개정 워크 플로우 : 충돌 및 재 승인 합치기

크기가 다른 많은 변경 사항이 동시에 보류중인 개정판이며, 검토 중이며 점진적으로 확인되고 있다고 상상해보십시오. 그들 중 일부는 동일한 코드를 수정하고 있기 때문에 충돌은 불가피합니다. "통합 자"가 간단한 작업 흐름에서 수동으로 패치를 받아들이면 작은 충돌이 해결 될 수 있지만 Gerrit의 경우에는 문제가 없습니다. 변경 사항을 검토하고 승인 한 경우 병합이 충돌 할 경우 이해할 수 있도록 작성자가 리베이스해야하고 개정을 위해 다시 푸시해야합니다.이 경우 개정 프로세스가 다시 시작됩니다. 상대적으로 활동적인 프로젝트의 경우 주당 50 건 이상의 외부 제공자 기부가 이루어지기 때문에 각 승인 및 제출 후 병합 거부로 인해 동일한 패치를 여러 번 수정해야하는 경우 악몽으로 변할 수 있습니다. 효율적이지 않다.

질문 : 나는 리트는 방법은 병합 충돌의 많은 수의 예상되는 크고 활성화 된 물건 앞으로 아니라고 정정

  1. 건가요?

  2. 일부 병합 충돌은 사소할 수 있습니다. 변경을 다시 시도하기 위해 작성자를 괴롭히지 않고도이를 해결할 수있는 방법이 있습니까?

  3. 변경 사항을 안정 분기로 백 포트해야하는 경우 체리 피크가 깨끗한 경우에도 각 분기에 대한 별도의 변경 사항을 개정을 위해 푸시해야합니다.

Gerrit 워크 플로우 경험에 대한 일반적인 의견도 환영합니다.

답변

7
  1. Gerrit는 Android 및 관련 bsp, 커널 등의 대규모 저장소 프로젝트에서 사용됩니다. 이 프로젝트는 주당 50 건 이상의 외부 커밋을 처리합니다. 저는 Qualcomm이 그 정도의 시간 동안 수천 개의 커밋을 할 것이라고 생각합니다.

  2. Gerrit에는 사소한 충돌을 자동으로 병합하는 설정이 있습니다. 저장소별로 설정할 수 있습니다. 이 옵션을 설정하면 변경 사항을 검토 및 확인하고 사용자가 제출 버튼을 누르면 제출 전략 (체리 - 선택, 필요한 경우 병합)에 따라 변경 사항이 병합됩니다. 여기에서 찾을 수있는 최고의 설명서는 --use-content-merge 옵션 아래 http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options입니다.

  3. 예 일반적으로 우리가하는 일입니다. 리뷰를 건너 뛰고, 분기를 합치는 등의 다른 옵션이 있지만 필요한 분기를 체리 채집하고 검토하는 것이 좋습니다. 우리는 우리의 회사, 개발자 rebases에서 병합 문제를 쳐서 리트을 밀어

+0

--use-content-merge, thanks에 대해 몰랐습니다. –

2

. 병합이 미미한 경우 관습에 따라 LGTM에 리베이스를 제출하고 제출하십시오.

패치 세트를 업데이트 할 때 개발자가 리베이스해야하는지 여부는 아직 논의 중입니다. 부모가 변경 될 때 패치 세트를 비교할 때 UI가 혼란스러워집니다.

+1

리베이스에 다른 변경 사항이 포함되지 않도록하기 위해 실제 업데이트와 리버스 노이즈를 분리하는 것이 더 쉽습니다. –

4

우리는 역사를 깨끗하고 이해하기 쉬우므로 합리적으로 선형으로 유지하기를 원합니다. 그래서 우리는 빠른 전진 병합만을 사용하도록 Gerrit를 구성했습니다.보이는 머지 (merge)는 릴리스와 지원 브랜치 (우리는 git-flow를 사용하고 있습니다)를위한 것이므로 훨씬 더 쉽게 이해할 수 있습니다.

그러나 이전 검토 상태가 리베이스 된 변경 사항에 자동으로 적용되도록 사소한 리베이스 플러그인이 설치되었습니다. 이는 리베이스가 Gerrit (Rebase 버튼 사용)에서 수행되었는지 개발자가 로컬 리베이스 (rebase)하고 변경 사항을 다시 푸시하는지에 관계없이 발생합니다.

우리의 경험에 따르면, 병합 충돌은 많은 수의 소스 파일이 관련되어 있기 때문에 큰 프로젝트에서 실제로 덜 일반적입니다. Repo에는 약 16,000 개의 파일이 있고 30 명의 전체 또는 시간제 개발자가 있으므로 동일한 파일을 편집 할 확률은 매우 낮습니다.

두 경우 모두 동일한 파일의 동일한 부분을 변경하면 실제로 서로 이야기해야합니다. 프로젝트 아키텍처가 동일한 파일 (예 : 등록 테이블)을 자주 변경해야하는 경우 아키텍처를 다시 설계하거나 종속성 주입과 같은 것을 사용하거나 빌드의 일부로 조각에서 자동으로 소스 파일을 생성해야합니다.

+1

Neil, gerrit + git-flow 워크 플로우에 대해 더 많이 듣고 싶습니다. 어디에서나 문서화 해 봤습니까? 감사. – spazm

+1

@spazm https://github.com/sillsdev/FwDocumentation/wiki는 우리가 지금 당장 가지고있는 전부이며 내부 개발자를 대상으로합니다. 그러나, 알고 싶은 것이 있으면 직접 저에게 연락하십시오. 우리는 여전히 프로세스를 수정하여 동일한 경로를 따르는 다른 사용자와의 상호 작용이 도움이됩니다. –

0

2 년 동안 수은을 사용한 후 몇 주 동안 사용했는데 지형지 물이 기본 모드로 병합되었으므로 나는 gerrit를 싫어합니다. 나는 더 많은 오버 헤드로 사소한 충돌을 해결할 수 있는데, 이는 비 gerrit 모드의 mercurial 또는 git에서 병합하여 자동으로 해결됩니다. 그런 다음 모두가 인수를 사용합니다. 안드로이드는 gerrit erger gerrit를 사용하며 모두에게 도움이되어야합니다.