这种场景下该采用怎么样的git分支管理策略？

Question

目前开发的项目采用git作为版本管理工具，

平时开发有两个分支，develop和master

在develop上开发，

在master发布正式版本。

目前有这样一种情况：

有一个设计好的功能，由于种种原因，在develop分支上开发完成后不能正常使用，

需要使用另一个补救性的设计方案临时代替，此代替方案需要上线，发布到master里面

当原功能成熟后，再删除这个补救方法，切换回原有的功能

请问我该使用哪种git分支策略？

Answer 1

Gitlab 흐름에서 병합 요청 방법을 권장합니다
마스터 및 개발 브랜치를 직접 푸시할 수 없습니다
주인 = 제작
개발 = 다음 릴리스
새로운 요구사항이 있으면 요구사항 분기 기능/aaa를 생성하세요
개발 완료 후 병합 요청
작성 코드 검토 후 feature/aaa을 develop 브랜치
에 병합 온라인에 접속할 때 develop 분기를 master
에 병합 출시 master 브랜치

포스터 질문은 이렇게 해주세요
feature/aaa을 기반으로 새로운 브랜치feature/bbb를 생성하고 수정 작업을 완료한 후 develop, master로 병합한 후 온라인
으로 전환합니다. feature/aaa을 계속 개발하여 develop, master

으로 병합합니다.

Answer 2

git 워크플로우를 참고하시면 됩니다

은 대략 master 브랜치 checkout의 hotfixes 브랜치입니다. hotfixes에 해결방법을 적고, merge를 master, develop에 각각 적습니다. 이 시점에서 이 hotfixes 브랜치를 삭제할 수 있습니다.

그런 다음 develop 브랜치에서 기능을 개발 및 개선하고 마지막으로 develop 브랜치 merge를 master 온라인에 추가하세요.

참고용으로 더 좋은 방법이 있을 수도 있습니다

Answer 3

으아아아

Answer 4

포스터가 먼저 이 문제를 해결할 수 있도록 도와주세요.

포스터의 브랜치 전략은 특별한 처리가 필요하지 않습니다. 일반적인 프로세스를 따르고 git의 기능을 결합하면 매우 잘 처리할 수 있습니다.

• 먼저 개발 기능이 출시되어 정상적으로 사용될 수 있도록 개발 시 커밋이 완료된 후 계속해서 교정 코드를 제출하세요. 여기 포스터에서 언급된 "수정 솔루션"은 실제로 기능 개발의 일부이며 버그 수정으로 간주되지 않습니다.
• 이후 테스트를 통과한 후 출시 과정에 들어가시면 됩니다. 원본 포스터의 원래 브랜치 전략에 릴리스 브랜치가 포함된 경우 이전 단계 이후에 릴리스 브랜치를 생성할 수 있으며 개발에서는 계속해서 새로운 기능 제출을 허용합니다. 이번 릴리스에서는 설계 계획 및 임시 수정 사항에 대한 버그 수정이 이루어질 예정입니다.
• 위 내용은 실제로 정상적인 개발 및 출시 과정입니다. 후속 설계 개발 및 개선 기능 삭제는 어떻게 되나요? 실제로 후속 개발은 실제로는 개선이나 새로운 기능으로 간주될 수 있으며 단지 일반적인 개발일 뿐입니다. 필요에 따라 이 개선 프로세스 중에 모든 노드에서 원래 수정 커밋(git revert 명령)을 되돌릴 수 있습니다.
• 복귀 대책과 '원래 디자인'을 구현한 후 일반적인 출시 프로세스에 따라 출시하면 됩니다.

제가 이해한 바에 따르면, 포스터에 언급된 "원래 기능"과 "해결 방법"은 정상적인 코드 제출입니다. 게시자가 혼란스러워하는 것은 임시 해결 방법이 결국 폐기(롤백)되는 문제를 어떻게 처리할 것인지이므로 위에서 언급한 git revert 명령을 사용하면 게시자의 기대를 만족시킬 수 있을 것입니다. 이를 통해 코드 베이스의 모든 작업이 트렁크(마스터, 개발)에 기록될 수 있을 뿐만 아니라 복잡한 분기 모델과 같은 문제도 피할 수 있습니다.

---

게다가 포스터에 사용된 분기 전략이 @rsj217이 언급한 워크플로우를 따르는지는 모르겠습니다. 개발이 모든 개발자의 주요 개발 브랜치라면 개발이 미완성 기능을 수락하지 않고 직접 제출하는 것이 더 낫다고 생각합니다. 일상적인 개발 작업에서, 특히 여러 기능/분기의 병렬 개발의 경우 여러 기능 분기가 서로 간섭을 피할 수 있습니다.
원래 포스터의 질문으로 돌아가서, 이 사용할 수 없는 디자인은 계속 개발될 수 있으며 개발에 병합되어서는 안 됩니다. 이 브랜치를 기반으로 개선 기능에 대한 개발 브랜치를 체크아웃한 후 이를 개발에 병합하여 릴리스 프로세스에 들어갑니다. 다음 병합 및 되돌리기 제안은 여전히 ​​필요합니다. 필요한 경우가 아니면 프로세스를 위반하지 말고 특별한 처리를 수행하십시오. 또한 모든 코드 커밋 작업은 이러한 방식으로 유지됩니다.

Answer 5

git 워크플로 마스터 마스터 브랜치를 참조하는 것이 좋습니다. 개발은 개발에 사용됩니다. 릴리스에 사용됩니다. 새 버전을 릴리스하는 데 사용됩니다. 핫픽스는 온라인 버그 및 기타 긴급 작업을 수정하는 데 사용됩니다.

Answer 6

<… 충돌 가능성이 매우 높음) development1 부분을 삭제하면 테스트가 문제 없이 온라인 상태가 됩니다. 조금 번거롭고 조금 멍청할 수도 있지만 git이 병합될 때마다 앞으로 새로운 포인트가 생성됩니다. 개발이 안정화되기를 기다리고 마스터를 롤백하고 싶다면 중간에 다른 릴리스가 있으면 그럴 것입니다. 곧 뭔가를 잃어버릴 거야?

참고용으로 더 좋은 방법이 있을 수도 있습니다

Answer 7

성공적인 Git 분기 모델을 읽는 데 어려움이 있다면 Juven Xu의 성공적인 Git 분기 모델 번역을 읽어보세요

Answer 8

git-flow를 사용하면 간단한 명령을 사용하여 브랜치를 생성하고 완료하는 데 도움이 됩니다. 그리고 표준화된 릴리스, 핫픽스, 기능 워크플로가 있습니다