정신을 잃지 않고 브랜치에서 리팩토링하는 방법은 무엇입니까?

Question

나와 다른 사람의 코드를 리팩토링합니다. 항상.Trunk가 아닌 브랜치에서 작업할 때 때로는 매우 고통스러운 병합이 발생합니다. 특히 정기적으로 Trunk로 다시 병합하지 않는 경우(브랜치의 코드가 Trunc에서 천천히 이동하고 사람들이 Trunk I을 수정하면) 더욱 그렇습니다. 이것을 지점에 적용하는 방법을 수동으로 알아내야 합니다).

내가 아는 해결책은 다음 중 하나입니다.

1. 트렁크에서 지속적으로 병합 - 고통스러운 병합을 줄입니다. 그런데 왜 브랜치에서 작업합니까?
2. 무언가를 리팩토링해야 할 때마다 트렁크로 전환하고 거기에서 리팩토링을 수행한 다음 브랜치에 병합하세요. 모든 리팩토링에 대해 환경을 전환하는 데 드는 실제 비용이 엄청나기 때문에 이것이 매우 실용적이지 않다고 생각합니다.

너 뭐하니?

Answer 1

대규모 리팩토링은 개발 일정에 맞춰 적절한 시기에 수행되어야 합니다.릴리스 시점에 엄청난 양의 리팩토링을 수행하면 변경 사항이 최소화되어야 하는 시점에 고통스러운 병합을 도입하게 되므로 결국 손해를 보게 될 것입니다.리팩토링이 더 파괴적일수록 개발 주기 초기에 발생해야 합니다(그리고 이를 위한 더 특별한 프로세스가 있어야 합니다.일정 기간 동안 영향을 받는 파일에 대한 편집을 최대한 중지하십시오.

트렁크에서 지속적으로 병합하는 것은 일반적으로 좋은 습관입니다.

그렇다면 왜 지점에서 일합니까?더 많은 제어권이 있기 때문입니다(예를 들어 개발 브랜치에 대한 체크인을 중지하지 않고 릴리스를 위해 트렁크 병합을 중지하여 안정화할 수 있습니다).개발 분기에 대한 체크인 속도에 큰 영향을 주지 않고 트렁크와의 병합에 대해 높은 수준의 검증을 수행할 수 있기 때문입니다.

Answer 2

나는 1을 사용하고 가능하면 작은 변경을 하고 자주 체크인하지 않으면 병합이 어려워집니다.동시에 다른 작업을 수행해야 하거나 리팩토링에 원래 생각했던 것보다 더 많은 시간이 걸리는 경우 별도의 분기를 사용하면 작업이 더 쉬워질 수 있습니다.또 다른 보너스는 여러 사람이 리팩토링에 더 쉽게 참여할 수 있고 원하는 만큼 자주 브랜치에 체크인할 수 있다는 것입니다.

Answer 3

릴리스 간 기간이 최소 2개월인 시나리오에는 다음 전략을 제안합니다.

릴리스가 가까워지기 시작하면 릴리스 브랜치를 만듭니다.릴리스 분기는 다음과 같이 처리되어야 합니다. 리팩토링은 하지 마세요. 그리고 나는 (거의) 기능이 완성되었습니다 나뭇가지.이 시점에서 릴리스 안정화에 노력을 집중해야 합니다. 릴리스 지점에서.필요에 따라 릴리스 분기의 결함 수정 사항을 트렁크에 다시 병합합니다.한편 트렁크는 다음과 같이 취급됩니다. 리팩토링을 위해 영구적으로 열려 있음.또한 가능하다면 주요 릴리스에 가까워짐에 따라 리팩토링을 줄이고 출시 직후 며칠 동안 속도를 높이십시오.

지속적인 릴리스 전략을 따르는 경우(예:1~2주마다 릴리스), 대대적인 외과적 개선을 수행하지 않는 한 별도의 분기에서 리팩토링과 코딩을 분리해서는 안 됩니다.그러한 외과적 강화 상황(각각 3개월 이상 간격을 두어야 함)에서는 병합을 수행할 때마다 미리 일정에서 릴리스를 삭제하고 릴리스 병합 및 테스트 증가를 위한 주기 중 하나를 사용하고 손가락을 교차시킨 후 놓습니다.

Answer 4

변경 사항은 다음 중 하나여야 합니다. 빠른 (그래서 당신 아래에는 너무 많은 변화가 없습니다) 또는 그렇지 않으면 현지의 (따라서 소수의 장소에서의 변경에만 관심이 있습니다).

그렇지 않으면 병합 작업이 리팩터링 작업만큼 필요할 수 있습니다.알고리즘으로서 낙관적 잠금은 너무 많은 트랜잭션이 실패하여 다시 시작해야 할 경우 작동하지 않습니다.

근본적으로 회사 내 프로그래머 20명이 코드베이스에 있는 메소드 중 50%의 이름을 매일 바꾸는 상황을 허용할 수 없습니다.그리고 그 문제에 있어서, 여러 사람이 항상 동시에 같은 장소에서 리팩토링을 하고 있다면 어쨌든 그들은 서로의 작업을 취소하는 것일 뿐입니다.

프로그래머가 병합을 수동으로 감독하는 데 많은 시간을 소비하는 경우 관리자에게 작업 정의 및 할당 방식을 변경하여 생산성을 높일 수 있는 기회를 제시하십시오.

또한 "모든 곳에서 팩토리를 사용할 수 있도록 전체 시스템을 리팩터링"하는 것도 작업이 아닙니다."이 하나의 인터페이스와 그 구현을 팩토리를 사용하도록 리팩토링하는 것"이 ​​작업입니다.

Answer 5

이것이 바로 우수한 분산 VCS가 탁월한 부분입니다.하지만 나는 당신이 이미 SVN에 전념하고 있다고 추측합니다.

개인적으로 저는 충돌 지옥을 피하기 위해 리팩터링을 한 다음 가능한 한 빨리 병합합니다.가장 생산적인 방법은 아니지만 오류 발생 가능성이 가장 낮습니다.

한때 기능이 '보류'되어 병합이 불가능했기 때문에 약 3주 동안 휴면 상태였던 브랜치가 있었습니다.방금 특정 부분에 대한 참조로 이전 기능을 사용하여 새 분기에서 기능을 다시 시작했습니다.

Answer 6

명백해질 위험이 있으므로 분기를 완전히 피하는 것이 좋습니다.이로 인해 발생하는 오버헤드의 양을 과소평가해서는 안 됩니다.더 이상 지체할 수 없다고 생각하더라도(프로덕션 중인 시스템 중 하나를 릴리스하고, 릴리스 2를 구축 중이지만 하나를 릴리스하도록 요청을 변경하는 경우) 여전히 다른 방법을 찾으십시오.분기하지 않고 기능을 분리할 수 있는 방법이 정말 없나요(예:"공통" 프로젝트와 일부 하위 프로젝트를 분리합니까?헤드에 모든 코드를 통합할 수 있는 방법이 정말 없나요(예:차이점을 통합하는 전략 클래스를 만들거나 새로운 기능을 켜거나 끄는 스위치를 만들까요?

반드시 분기해야 한다면 옵션 1을 선택하겠습니다.가능한 한 작은 변경 사항을 병합하고 자주 수행하십시오.

Answer 7

일찍 커밋하고 자주 커밋하세요.

아니면 이 경우에는...일찍 병합하고 자주 병합하십시오.

Answer 8

지속적인 통합이 핵심입니다.한 번에 1개의 작은 배치 변경...