브랜치를 사용하여 동일한 소프트웨어의 다른 버전을 유지 관리하는 것이 좋습니까?

우리는 몇 가지 다른 판을 가진 제품을 가지고 있습니다. 차이점은 사소합니다. 여기저기서 다른 문자열, 하나의 추가 논리는 거의없고 다른 논리는 거의 차이가 없습니다. 소프트웨어를 개발할 때 각 버전에 대부분의 변경 사항을 추가해야합니다. 그러나 그렇지 않은 몇 가지와 달라야 할 몇 가지가 있습니다. release-editionA 및 release-editionB (.. etc) 분기가있는 경우 분기를 올바르게 사용합니까? 문제가 있습니까? 좋은 습관?

업데이트 : 통찰력을 가져 주셔서 감사합니다. 여기에 좋은 답변이 많이 있습니다. 일반적인 합의는이 목적으로 분기를 사용하는 것이 좋지 않은 것 같습니다. 궁금한 점이 있으시면 문제의 최종 해결책은 문자열을 구성으로 외부화하고 다른 논리를 플러그인 또는 스크립트로 외부화하는 것입니다.

이것은 변화의 규모에 달려 있지만 설명 된 차이점에 대해서는 좋은 방법으로 생각하지 않습니다.

일반적으로 Git 브랜치는 미래에 병합되거나 참조를 위해 읽기 전용으로 저장되는 것이기를 원합니다. Git 브랜치는 무한히 공존하는 모든 사람을위한 일을 의미합니다. 변화는 전파되고 병합되고 갈등이 해결되어야합니다. 다른 것이 없다면, 모든 개발자는 변경 사항을 하나가 아닌 5 개의 저장소로 푸시해야합니다.

약간의 변경이있는 경우 문제와 비교할 때 전체 병합 및 분기 유지 노력이 과도하게 보입니다. 프리 프로세서 또는 빌드 시스템을 사용하여 버전을 구별하십시오. 간단한 #ifdef트릭을 수행합니까? 그런 다음 자식 문제를 해결하지 마십시오.

그것은 실제로 가지가 아닙니다. 브랜치는 동일한 코드의 장기 병렬 버전이 아니라 개발 라인에 대한 단기 또는 중간 측면 경로입니다.

판마다 다른 부분에 대한 하위 디렉토리를 사용하여 서로 다른 모든 버전을 동일한 브랜치에 넣고 필요에 따라 판을 출력 할 수 있도록 빌드 프로세스를 설정했습니다 (자동 빌드가 있습니까?). (또는 모두 한 번에).

결국, 당신은 "단일 진실의 근원"을 유지하기를 원합니다. 분기를 사용하면 일부 코드가 복제되지만 전부는 아니지만 일부 병합으로 인해 실제로 설정이 중단 될 수 있습니다.

사람들이 지적한 것처럼 한 가지 솔루션은 다른 버전을 지원하도록 빌드 시스템을 구성하는 것입니다.

또한 기능 토글로 구현하고 구성 파일을 사용하는 것을 고려할 것입니다. 구축해야 할 것이 적을수록 좋습니다.

이 사이트를보십시오.

코드를 많이 클러스터링하지 않고 한 지점 내에서 할 수 없다면 좋은 생각이라고 생각합니다.
특히 하나의 브랜치에 유지하고 지역화 된 파일과 구성 파일을 사용하는 것이 좋습니다.
다른 방법은 다른 빌드 일 수 있습니다. 예를 들어 빌드 파일은 고객마다 다른 파일을 압축하지만 빌드 도구가 다른 브랜치를 확인하는 것을 볼 수도 있습니다. git을 사용함에 따라 실제 문제는 없습니다. 하나의 브랜칭 전략은 다른 작업을 위해 다른 브랜치에서 개발하고, 마스터 브랜치에 체크인하여 마스터에서 editionX 및 Y로 병합하는 것입니다.

이것은 다른 빌드 구성의 작업처럼 보입니다. thiton의 대답 은이 방향으로 진행되지만 #ifdef다음 보다 훨씬 더 많이 사용합니다 .

다른 빌드 대상을 사용하여 다른 버전의 소프트웨어를 빌드하십시오. 대상에 따라 다를 수 있습니다

• 그들이 포함하는 구성
• 포함 된 객체 또는 소스 파일 또는
• 소스 코드의 전처리

이 전처리에는 분명히 고전적인 C 전처리 기가 포함될 수 있지만, 커스텀 프리 프로세서, 커스텀 뷰를 생성하기위한 템플릿 엔진을 사용하는 것도 가능합니다.

이렇게하면 모든 단일 변경 사항을 여러 분기로 적극적으로 푸시하지 않아도됩니다. 이는 DRY를 위반합니다 (물론 자동화 할 수는 있지만 이점을 보지 못합니다).

나는 중요한 변화에만 브랜치를 사용합니다. 그렇지 않으면 많은 가지에 작은 변화를 더할 수 있습니다.

다른 제품으로 모두 출시하는 경우 여러 지점을 갖는 것이 좋습니다. 그렇지 않은 경우 여전히 트렁크 또는 마스터 분기와 같은 것을 사용하는 것이 좋습니다.

또한 이것이 개발 프로세스, 특히 배포에 달려 있다고 생각합니다. 하나의 브랜치 만 프로덕션으로 롤아웃 할 수있는 프로세스가 있고 브랜치가 "증분 빌드"로 처리되는 경우 릴리스 A를 먼저 롤아웃하지 않으면 릴리스 B를 프로덕션으로 롤아웃 할 수 없습니다. A는 이미 B에 있고 여러 가지를 갖는 것이 좋습니다. 이것은 전 세계에 팀이 흩어져 있고 일반적으로 우선 순위에 따라 순서가 변경되는 경우 작동합니다.

생산, 개발 및 기능에 대한 세 가지 지점이있는 솔루션이 실제로 효과적입니다. 프로덕션 코드에서 버그를 발견했다면 패치를 적용한 다음 릴리스 할 수 있습니다. 생산 지점에 기능을 추가하거나 생산 지점을 크게 변경하지 마십시오. 귀사와 팀은 생산 지사에 주요 기능 변경 사항을 추가하지 않으려면 자체 훈련을 받아야합니다. 프로덕션 브랜치는 프로덕션 코드베이스의 주요 변경을 보증하지 않는 사소한 버그 수정을위한 것입니다.