branch - git 多版本并行发布时，该创建多个项目还是多个分支

Question

git 做单版本在线的项目是很成熟的，流程很清晰，每个issue创建一个branch，然后合并到master，打tag即可。 比如web项目，发布了1.0.0，然后修bug发布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/