Branch - git multi-version이 병렬로 출시되면 여러 프로젝트나 브랜치를 생성해야 합니까?

Question

Git은 단일 버전 온라인 프로젝트에 대해 매우 성숙하고 프로세스가 매우 명확합니다. 각 문제에 대한 분기를 만든 다음 이를 마스터에 병합하고 태그를 지정합니다. 예를 들어 웹 프로젝트의 경우 1.0.0이 릴리스되고 버그 수정이 포함된 1.0.1 및 1.0.2가 릴리스되고 새로운 기능인 1.1.0 및 1.2.0이 릴리스되고 주요 기능이 포함된 2.0.0이 릴리스됩니다. 오직...

为情所困 · Answer

tag:v14.04에서 브랜치를 가져와서 branch:14.04.1-dev이라고 부르고 그 안에서 개발하면 됩니다. 일단 안정되면 tag:v14.04.1만 추가하면 됩니다. "브랜치 => 개발 => 병합"을 고수할 필요가 없습니다. . Merge할 필요가 없을 때는 그냥 Merge하지 않고 해도 전혀 문제가 없습니다. 특히 여러 버전이 동시에 유지되는 경우에는 Cherry-Pick이 Merge를 대체하는 것이 일반적입니다

그러나 git master는 실제로 약간 혼란스럽습니다. 프로젝트마다 전략이 다릅니다. 일부 master는 안정적인 버전을 포함하는 stable을 의미하고, 일부는 반대로 master는 dev를 의미합니다. 안정적인 버전. 일부 마스터는 릴리스를 의미하며, 이는 "온라인 배포와 일관성을 유지하는 코드"를 의미합니다. 그래서 master를 직접 사용하는 것이 아니라 좀 더 구체적인 브랜치 이름을 사용하는 것이 더 나은 전략이 아닐까요?

我想大声告诉你 · Answer

릴리스에는 해당 릴리스 브랜치가 있습니다

为情所困 · Answer

설명하신 시나리오에서 다른 브랜치나 다른 프로젝트의 다른 버전은 기본적으로 동일하다고 생각합니다. 왜냐하면 다른 브랜치는 기본적으로 병합되지 않기 때문입니다(브랜치 이름에 대해 너무 많이 걱정할 필요가 없습니다). 그래서 다른 버전에 변경 사항을 적용해야 할 경우에는 다음과 같은 방법을 고려해 볼 수 있다고 생각합니다.

git 서브모듈 관리 모듈을 사용하여 변경 시 서브모듈에 해당하는 해시를 직접 수정할 수 있습니다.
다점 관리 이용 시
- git Cherry-Pick을 사용하여 커밋 병합
- git checkout을 사용하여 개별 파일을 직접 가져옵니다
다중 프로젝트 관리를 사용하는 경우 git archive를 사용하여 관련 파일을 가져올 수 있습니다

물론 모든 방법에는 함정이 있다는 것은 의심의 여지가 없습니다.

给我你的怀抱 · Answer

안녕하세요. 이런 복잡한 버전 시나리오는 Gitflow에 적합합니다. Gitflow로 직접 이동하여 알아볼 수 있습니다. 링크는 다음과 같습니다: http://nvie.com/posts/a-successful-git-branching-model/