1
나는 두 개의 활성 개발 나뭇 가지와 자식의 Redis Sentinel library for Laravel을 유지하고있어 : 위의 예시 된 바와 같이병합하지 않는 두 개 이상의 분기 분기를 유지하는 방법은 무엇입니까?
1.x ... o ———— o —————— o — o — o — o — o ...
↘ ↑ ↑ ↖
2.x (breaking change) — o — o — o — o — o ...
, 나는이 라이브러리와 통합 프레임 워크의 최신 버전에서 깨는 변화를 수용하기 위해 1.x에서 갈래 그러나 나는 자신이 두 가지 분기에서 공통 기능을 업데이트하는 분기간에 코드를 복사하거나 수동으로 코드를 복사한다고 생각한다.
다른 브랜치와 호환되지 않는 코드를 포함하고 있기 때문에이 브랜치를 병합 할 수없는 것처럼 보입니다. 브랜치 간의 일반적인 변경 사항을 병합하는 데 필요한 노력을 줄이기 위해 더 나은 워크 플로우를 수행 할 수 있습니까?
소리를내어 주셔서 감사합니다. 이것은 내가 두려워했던 것입니다. * 1.x * 지점은 연말에 대한 지원이 중단되었지만 미래를위한 트릭이나 워크 플로우를 배우기를 희망했습니다. 분기마다 변경된 외부 코드 (각 분기를 이러한 버전으로 제한하는 패키지 관리자 메타 데이터)에 의존하므로 분기를 병합 할 수 없습니다. 이것을 조금 더 오랫동안 열어 두겠습니다.하지만이 상황에 대해 가능한 한 최선의 대답이라고 생각합니다. –
외부 종속성의 차이가 나는 경우 인터페이스를 구현하거나 컴파일 타임이나 런타임에 외부 라이브러리의 버전을 선택하도록 다른 방법을 사용할 수 있습니까? 이는 실제로 다시 함께 병합하는 수단이 될 것이며, 각 버전의 코드를 업데이트를 쉽게하는 방식으로 분리 할 것입니다. 그러나 2017 년 말에 1.x를 사용하지 않을 경우 특히 그럴만 한 가치가 없을 수도 있습니다. – LightCC
프로젝트를 지원해야하는 프레임 워크 버전 간의 사소한 비 호환성으로이 방법을 사용할 수는 있지만, 이 경우에는 그 차이가 상당하므로 필자는 그렇게 할 때 가치를 보지 못했다. 너무 많은 런타임 조건 (결국 PHP)은 코드를 하나의 브랜치로 강요하는 것을 정당화 할 수 있다고 생각하지 않는 복잡성과 오버 헤드를 초래합니다. 다시 한 번 시간을내어 주셔서 감사합니다. 제안을 읽은 후 포크하는 결정에 대해 더 기분이 좋습니다. 나는 그 마법 총알을 찾고 있었다고 생각한다! 미래 프로젝트에 대해 생각해 볼 일을 몇 가지 주셨습니다. –