회사에서 지점을 병합하는 것이 잘못 되었습니까?

28

최근에 분기 및 병합 및 SCM : 분기 및 병합 입문서-Chris Birmele에 대한 MSDN 기사를 접했습니다 .

이 기사에서 그들은 '빅뱅 병합'이 합병하는 반 패턴이라고 말합니다.

Big Bang Merge — 개발 노력이 끝날 때까지 지점 병합을 연기하고 모든 지점을 동시에 병합하려고합니다.

나는 이것이 회사가 생산하는 모든 개발 부서에서하고있는 것과 매우 유사하다는 것을 깨달았습니다.

나는 한 사람이 최종 검토 + 트렁크 병합 권한을 가진 매우 작은 회사에서 일합니다. 우리는 5 명 (나를 포함하여)을 가지고 있으며, 우리 각자에게는 별도의 작업 / 버그 / 프로젝트가 할당되고 각 분기는 현재 트렁크 (subversion)에서 분기 된 다음 분기에서 개발 작업을 수행하고 결과를 테스트하고 문서를 작성합니다. 필요한 경우 다른 개발자와 동료 검토 및 피드백 루프를 수행 한 다음 프로젝트 관리 소프트웨어에서 검토 + 병합을 위해 지점을 제출하십시오.

트렁크 저장소의 유일한 권한 인 내 상사는 실제로 가능한 한 많은 시간 동안 검토를 수행 할 단일 시점까지 지점의 모든 검토를 연기합니다. 일부 지점은 개선 / 수정을 위해 되돌려집니다. 지점은 트렁크에 바로 병합되고 일부 지점은 충돌 등으로 인해 다시 발생합니다.

최종 검토 대기열에 10-20 개의 활성 지점이 트렁크에 병합되도록하는 것은 드문 일이 아닙니다.

또한 두 개의 분기가 동일한 트렁크에서 생성되었지만 동일한 코드 조각을 수정했기 때문에 최종 검토 및 병합 단계에서 충돌을 자주 해결해야합니다. 일반적으로 우리는 트렁크를 다시 브랜치하고 변경 사항을 다시 적용하고 충돌을 해결 한 다음 검토를 위해 새 브랜치를 제출하여 (이난 한 사람들의 리베이스)이를 방지합니다.

내가 가진 몇 가지 직접적인 질문은 다음과 같습니다.

우리는 '빅뱅 머지 (big bang merge)'로 묘사 된 매우 반 패턴을 전시하고 있습니까?
이 병합 프로세스의 결과로 발생하는 일부 문제가 있습니까?
상사의 병목 현상을 증가시키지 않고이 병합 프로세스를 어떻게 개선 할 수 있습니까?

편집 : 내 상사가 트렁크 저장소에 대한 그립을 느슨하게하거나 다른 개발자가 트렁크에 병합 할 수 있는지 의심합니다. 그의 이유가 무엇인지 확실하지 않지만 실제로 주제가 제기되기 전에 계획을 세우지 않을 것입니다. 나는 그들이 우리를 믿지 않는다고 생각합니다. 어쨌든 모든 것이 추적되기 때문에 의미가 없습니다.

이 상황에 대한 다른 통찰력이 있으면 감사하겠습니다.

— 사용자
소스

2

병합이 왜 지연됩니까? 일반적으로 즉시 수행하지 않는 이유가 있습니다. 한 사람이 과로했고 백 로그가 너무 커지는가? 합병이 적시에 수행되지 않는 다른 이유가 있습니까?

— Polygnome

1

나는 여러 번 당신과 비슷한 입장에있었습니다. 개인 경험을 통해 많은 회사에서 버전 제어, 특히 분기, 끔찍하게 잘못된 것을 알 수 있습니다.

— MechMK1

3

상사가 휴가를 가면 어떻게 되나요?

— Liath

리눅스 커널 브랜칭 / 병합 전략을 어떻게 정의 하시겠습니까?

— Braiam

충돌로 인해 되돌려 지지만 다른 결함이 아닌 변경은 충돌이 해결되거나 "잠정적으로 승인 된"것으로 간주되면 승인 프로세스를 다시 수행해야합니까?

— Gregory Nisbet

60

몇 가지 제안 :

각 브랜치에서 수행 된 변경 사항이 충분히 작아서 결과적으로 병합 충돌을 효과적으로 처리 할 수있는 한 많은 기능 또는 버그 수정 브랜치를 갖는 데에는 아무런 문제가 없습니다. MSDN 기사가 아닌 작업 방식이 괜찮다면 이것이 기준이되어야합니다.
분기가 트렁크로 병합 될 때마다 트렁크는 모든 열린 개발 분기로 최대한 빨리 병합되어야합니다. 이를 통해 팀의 모든 사람들은 자신의 지점에서 병합 충돌을 병렬로 해결할 수 있으므로 트렁크의 게이트 키퍼로부터 약간의 부담을지게됩니다.
게이트 키퍼가 10 개의 브랜치가 "트렁크에 병합 할 준비가 될 때까지"기다리지 않으면 더 잘 작동 할 것입니다. 마지막 트렁크 통합에서 병합 충돌을 해결하려면 항상 팀에 시간이 필요하므로, 짜여진 시간 간격으로 작업하는 것이 더 좋습니다 -게이트 키퍼에 의한 하나의 통합, 팀에 의한 하나의 다시 병합, 게이트 키퍼에 의한 다음 통합, 팀에 의한 다음 다시 병합 등.
브랜치를 작게 유지하려면 더 큰 기능을 여러 개의 작은 작업으로 나누고 각 작업을 자체 브랜치에서 개발하는 것이 도움이 될 수 있습니다. 모든 서브 태스크가 구현 될 때까지 기능이 프로덕션 준비되지 않은 경우 모든 서브 태스크가 완료 될 때까지 기능 토글 뒤의 프로덕션에서 해당 기능을 숨기십시오 .
조만간 코드베이스의 많은 파일에 영향을 미치는 리팩토링 작업이 발생합니다. 이는 많은 브랜치와 많은 병합 충돌을 일으킬 위험이 높습니다. 그것들은 팀에서 명확하게 의사 소통하여 가장 잘 처리 할 수 있으며 위에서 언급 한대로 정확하게 처리해야합니다. 재 통합 전에 모든 개발 부서에 먼저 통합하고 작은 하위 리팩터링으로 나눕니다.
현재 팀 규모의 경우 단일 게이트 키퍼를 보유해도 여전히 작동 할 수 있습니다. 그러나 팀 규모가 커지면 두 번째 게이트 키퍼 (또는 그 이상)를 가질 방법이 없습니다. 참고 나는 모든 사람이 트렁크에 합류 할 것을 제안하지는 않지만, 상사 만이 이것을 할 수있는 것은 아닙니다. 게이트 키퍼의 직무를 수행 할 후보가 될 수있는 한두 명의 수석 개발자가있을 수 있습니다. 또한 현재 팀 규모에 관계없이 두 번째 게이트 키퍼를 사용하면 팀이 트렁크를 더 자주 또는 더 일찍 통합하거나 보스를 사용할 수 없을 때 더 쉽게 트렁크에 통합 할 수 있습니다.

— 닥 브라운
소스

2

우리는 단순히 모든 사람에게 트렁크를 열 수 없으며 분기 스택이 항상 문제가되지 않는다는 것을 인정하면서 여기에 가장 좋은 의견이 있다고 생각합니다 (충돌이있을 때만). 충돌을 줄이고 병합주기가 원활하게 진행될 수있는 방법을 지적하면서도 좋은 일을했다고 생각합니다. 다른 게이트 키퍼가 필요하다고 말할 때 완전히 정확하다고 생각합니다. 이 통찰력에 감사드립니다!

— user6567423

@ user6567423 고려해야 할 또 다른 사항은 각 개발 버전 (예 : 5.2.3 또는 기타)에 대한 브랜치를 만드는 것입니다. 각 개발자는 기능 작업을 위해 분기 한 다음 병합하여 다시 메인으로 병합 할 수 있습니다. 개발이 완료되면 보스가 분기를 해제합니다.

— nick012000

@ nick012000 : 게이트 키퍼가 트렁크에 통합하기 위해 개별 기능 분기를 수락하거나 거부하는 것이 그 제안을 어렵게하지 않을까요? 여러 기능이 하나의 개발 브랜치에 혼합되어 있으면 이러한 변경 사항 을 트렁크에 부분적 으로 다시 통합하는 것이 매우 어려워 질 것입니다. 아니면 뭔가 빠졌습니까?

— Doc Brown

10

" 자체 지점에서 병합 충돌을 병렬로 해결하므로 트렁크의 게이트 키퍼로부터 약간의 부담을 덜어 야합니다. "-이 부분이 부수적으로 줄어든 것 같습니다. 상사에게 이것을 제안 할 때 "그것은 회사를 위해 더 낫다 그러나 당신을 위해 또한 더 쉽다 "는 주요 판매 지점 같이 보인다. 그것은 SE에 관한 것이 아닌 사무 정치의 방향에 더 가깝습니다. 그러나이 상황에서 상사로부터의 인수가 없다면이 기술적으로 탁월한 답변의 다른 모든 것은 일어나지 않을 것입니다.

— R. Schmitz

@DocBrown 예, 그렇습니다. 그러나 개발자 브랜치 사이의 충돌이 훨씬 적고 메인 브랜치에 직접 병합하지 않아도 안전성을 제공합니다. 작업을 완료로 수락하지 않고 코드 전체에 만족할 때까지 병합을 수행하십시오.

— nick012000

18

우리는 '빅뱅 머지 (big bang merge)'로 묘사 된 매우 반 패턴을 전시하고 있습니까?

그 것처럼 들립니다.

이 병합 프로세스의 결과로 발생하는 일부 문제가 있습니까?

명확히

상사의 병목 현상을 증가시키지 않고이 병합 프로세스를 어떻게 개선 할 수 있습니까?

우리 회사에서는 모든 개발자가 병합 할 수 있습니다. 우리는 다른 개발자에게 병합 요청을 할당하고 양 당사자가 만족할 때까지 검토 / 피드백 / 업데이트주기를 진행합니다. 그런 다음 검토자가 코드를 병합합니다.

병합 대기중인 10-20 개의 지점은 프로세스에 결함이 있음을 나타냅니다. 우리가 그 많은 것을 가졌다면 모든 개발 작업은 정리 될 때까지 중단 될 것입니다.

— 매튜
소스

1

상사가 트렁크 저장소에 대한 그립을 느슨하게 할 것 같지 않기 때문에 내가 찾던 대답은 아닙니다. 그러나 그럼에도 불구하고 매우 유용한 답변은 통찰력에 감사드립니다!

— user6567423

5

@ user6567423 : 보스가 병목 현상이 발생하여 현재 설명에 따라 병목 현상이 발생하면 접근 방식을 변경하거나 지연의 원인이된다는 사실을 인정해야합니다. 접근 방식 변경을 거부하고, 생성중인 문제를 무시하고 다른 사람에게 책임을 돌리는 것은 비즈니스를 운영하는 방법이 아닙니다.

— Flater

1

그는 병목 현상에 동의하고 다른 사람들을 비난하지 않을 것입니다. 그러나 그렇습니다. 병목 현상을 줄일 수있는 명확하지 않은 팁을 찾고있었습니다. 통찰력에 감사드립니다

— user6567423

1

왜 그가 트렁크에 합류 할 수있는 유일한 사람인지 설명해 본 적이 있는지 궁금합니다.

— 마태 복음

13

이것은 기본적으로 Linux 커널을 포함하여 많은 오픈 소스 프로젝트가 작동하는 방식입니다. Linux 커널은 주어진 시간보다 훨씬 많은 지점을 가지고 있습니다. 이러한 프로젝트에서 빅뱅 병합을 피하는 일반적인 방법은 지속적인 통합을 위해 다른 지점 (또는 여러 지점)을 만드는 것입니다. 변경 사항이 동료와 함께 작동하도록하기 위해 사용하는 지점이며 게이트 키퍼가 검토를 수행 할 때 주기적으로 트렁크에 기반을 둡니다.

선택적으로이 분기를 사용하여 몇 가지 자체 풀 요청을 하나의 큰 응집력 요청으로 결합하여 상사가 검토 할 수 있습니다. Linus Torvalds는 일반적으로 두 개 이상의 수준으로 통합 된 풀 요청을 받고 완전한 새 파일 시스템 드라이버와 같은 크기를 가질 수 있습니다.

— 칼 빌레펠트
소스

감사합니다. 브랜치 결합 및 충돌 방지에 대한 팁이 아마도 최선의 조치가 될 것입니다.

— user6567423

8

나는 Doc Brown과 동의하지만 또 다른 반 패턴을 본다 :

트렁크 리포지토리 의 유일한 권한 인 내 상사 는 실제로 가능한 한 많은 시간 동안 리뷰를 수행 할 지점까지 모든 지점 에 대한 모든 검토 를 연기합니다. 분기는 트렁크로 바로 병합되고 일부 분기는 충돌 등 으로 인해 다시 발생합니다 .

내 겸손에는 몇 가지 관리 반 패턴이 있습니다.

팀의 속도를 제한하는 단일 초크 포인트입니다. 귀하의 버스 요인은 1입니다 제약의 이론 당신이 체인의 가장 느린 부분을 개선에 노력을해야한다고 말한다.
관리자가 피드백주기를 느리게하고 팀의 민첩성을 줄입니다. 매주 풀릴 수 있습니까?
코드 양에 따라 복잡성이 기하 급수적으로 증가합니다. 1000 개 라인 중 1 개보다 100 개 라인을 10 개 병합하는 것이 좋습니다. 그것이 당신이 최대한 빨리해야하는 이유 중 하나입니다.
트렁크에서 장애를 감지하면 나중에 장애 조치를 수행합니다. 여러 가지 중 어느 것이 문제가있는 것인지
결정은 더 많은 지식을 가진 사람들이해야합니다. 이 경우 누가 더 알고 있습니까? 코드를 만든 개발자가 내기했습니다.
관리자가 성일 인 경우 프로덕션 버그를 수정할 수 없습니다.
작업을 다시 수행하고 분기를 되돌리고 있습니다. 이것은 시간 낭비 입니다. 생산에 도달하기를 기다리는 시간도 낭비입니다.

추천 :

관리자는 책임을 팀에 위임해야합니다. 팀이 성숙하고 전문적임을 보여 주어야합니다. 그들이 팀을 신뢰할 수 있는지 확인하십시오
몇 가지 검토 방법을 구현하십시오. 다른 두 팀원의 승인이 필요할 수 있습니다.
SVN을 사용하면 어려워 질 수 있습니다. 힘내 시도해보고 그것이 도움이되는지 확인하십시오. 더 나아가. GitHub를 사용하는 경우 풀 요청 메커니즘을 사용하여 병합에 특정 투표가 필요합니다.
민첩한 사례, 지속적인 통합 및 DevOps에 대한 정보를 읽고 공유하십시오.

— 보르 ja
소스

7

SVN과 git에서 전문적으로 작업했으며 SVN이 분명히 문제의 일부라고 말합니다 .git에없는 분기에 대해 단일 병합 백 커밋 정책을 강제합니다. git에서는 모든 병합이 동일하고 SVN에서는 일부 병합이 다른 병합보다 동일합니다. 또한 로컬 커밋이 없으면 git보다 SVN을 실험하기가 훨씬 어려워지고 준비 영역이 없으면 SVN의 유연성이 없어집니다. 토발즈가 자식을 개발하는 대신 SVN을 사용하지 않은 이유가 있습니다.

— cmaster

Git은 @cmaster가 배치 한 이유와 그 이상으로 인해 내 의견으로는 svn보다 훨씬 낫습니다.

— reggaeguitar

나는 git이 아마도 우리의 병합 문제 중 일부를 해결할 것이라는 데 동의하며, 사랑하는 신은 내가 rebase를 사용할 수 있기를 바랍니다. 그러나 나는 우리가 언제

— 라도

1

@ user6567423, 작년에 svn에서 Git으로의 소규모 팀 전환을 지원하고 Git에 대한 교육 및 코드 검토 및 협업을 위해 GitLab Community Edition (오픈 소스)으로 설정하는 등 워크 플로우를 변경하는 데 도움이되는 상담을했습니다. . 그들은 그것에 대해 매우 열성적이었습니다. 밤낮의 차이였습니다. (또한 3 일밖에 걸리지

— 와일드 카드

2

별도의 분기에서 기능 작업을 수행하는 경우 분기 중 하나가 트렁크에 병합되어 다른 기능 분기로 끌어 오기 전까지는 통합 테스트를 쉽게 수행 할 수 없습니다. 내 경험상, 이것은 빅뱅 병합 안티 패턴의 주요 문제입니다. 이상적으로는 기능 작업을 수행하고, 기능 분기에서 기능을 테스트하고, 트렁크로 병합 한 다음 기능을 수행 한 시점에 수행합니다. 병합되지 않은 경우 다른 항목이 트렁크에 병합 될 때마다 다시 방문해야합니다. 이 안티 패턴의 어려움은 개발주기가 끝날 때 많은 통합 유형 버그가 나타나는 것입니다.

— bmm6o
소스

1

20 개의 지점이 있습니다. 지점 1이 합병되었습니다. 그런 다음 브랜치 2의 개발자는 브랜치 1을 브랜치로 병합하여 충돌없이 메인으로 병합 할 수 있습니다. 그런 다음 브랜치 3의 개발자는 브랜치 1과 브랜치 2를 브랜치로 병합하여 충돌없이 메인으로 병합 할 수 있습니다.

독자를위한 연습 : 내 완전한 게시물을 인쇄하는 프로그램을 작성하십시오 :-)

이건 광기 야 당신은 병합하는 데 엄청난 시간을 할애 할 것입니다.

— gnasher729
소스

가지가 충돌하지 않는 한 반드시 모든 것을 트렁크에 완벽하게 병합 할 수있는 것은 아닙니다. 검토를 위해 지점을 제출하기 전에 테스트 병합을 수행하여 충돌을 방지하려고 노력하지만 대기열의 지점 수가 증가함에 따라 충돌이 불가피하게 발생합니다. 나는 그것이 광기처럼 들린다는 것에 동의합니다.

— user6567423

2

내가 알 수있는 한 정상적인 SVN 병합 동작 ...

— cmaster

0

당신이 일하는 방식과 상사가 책임감있는 제어 괴물이라는 점을 감안할 때 분기 자체가 문제인 것 같습니다. 모든 기능에 대한 분기를 만드는 대신 각 개발자가 자신의 기능을 부분적으로 트렁크에 직접 커밋하도록합니다. 이로 인해 개발자는 여러 작은 단계 (win-win)로 통합해야합니다. 게이트 키퍼는 개발주기 초기에 더 작은 변화를 추적하면서 마스터 리뷰어가 될 수 있습니다.

분기 자체는 그럴만한 이유가 없거나 다른 옵션이없는 한 원하지 않는 일입니다. 사물을 더 단단히 동기화 할 수있을 정도로 작아서 더 쉽고 안전합니다.

— 마틴 마트
소스

1

이러한 기능 중 하나에 버그가 있거나 제 시간에 완료되지 않은 경우 릴리스를 어떻게 처리 할 예정입니까? "정말 좋은 이유가없는 한 브랜칭 자체는 원하지 않는 일입니다."-여러 기능에 대해 5 명씩 작업 한 후에는 매우 좋은 이유가없는 한 분기를 사용해야합니다.

— Ivo van der Veeken

그것은 두 가지에 관한 것이 었습니다. 보스는 오직 하나의 게이트 키퍼로 남아 있기를 원하고 너무 많이 분기되지 않아야합니다. 그렇습니다. 상사가 아직 조사하지 않은 무언가가 밀려나는 순간이있을 것입니다. 그는 신속하게 그렇게 할 수 있어야하며, 드물게는 즉시 전달해야 최신 커밋을 되돌릴 수 있습니다. 이것은 동기화 상태를 유지하고 무엇이든 실패하면 확실히 실패합니다. 현재 상황에 대해 나에게 좋은 타협처럼 보입니다.

— 마틴 마트

1

나는 이것을 최후의 수단으로 생각할 것입니다

— 레게 귀 타르