우선 이 개발 과정이 문제가 있다는 점을 말씀드리고 싶습니다.

ABC가 독립적인 기능을 별도로 개발한다면 자체 브랜치를 사용해야 합니다. 이런 방식으로 관리 및 유지 관리가 매우 편리하며 이러한 이상한 문제도 발생하지 않습니다.

그런 다음 이상한 요구 사항을 충족하는 방법:

1. 커밋 번호를 알아내려면 git log --author=... --format='%H' 커밋 범위를 사용하세요

2. 그런 다음 rev 명령을 역순으로 파이프한 다음 이를 반복하고 git 체리 선택을 통해 마스터 브랜치에 대한 커밋을 하나씩 선택합니다

보상도 없고, 특정 주문을 쓰기에는 너무 게으릅니다. 결국 전체 명령은 스스로 테스트하고 실행 가능해야 합니다. 테스트 환경은 설정하기가 너무 까다롭습니다. 문서를 확인하고 직접 시도해 보세요.

개발 브랜치에 공동으로 제출되기 때문에 A는 필연적으로 B와 C의 코드를 가져오게 되는데, 병합을 하면 물병으로 변한 후 어떻게 분리할 수 있을까요?
유일한 방법은 로그와 차이점을 보고 수동으로 분리하는 것입니다.

ABC가 제출되어 Development에 병합되었으니 ABC를 구별할 방법은 없겠죠? A의 코드에 문제가 없다고 판단되면 A브랜치에서 Merge해야 하는 코드를 마스터에 직접 제출해도 되나요?

1. 원격 창고에서 프로젝트를 복제하여 로컬 창고에 넣습니다.
2. 원격 웨어하우스의 A 브랜치와 동일한 이름으로 이 파일의 마스터 브랜치에 새 브랜치를 생성합니다. Git을 사용하는 경우 checkout -b '브랜치 이름'을 사용하는 것이 좋습니다. 이 브랜치를 생성하고 직접 입력합니다.
3. 이 새 지점에서는 원격 창고에서 지점 A를 가져와 로컬 창고에 제출합니다.
4. 마스터 브랜치로 전환하고 새로 생성된 브랜치를 병합한 후 제출하세요.

두 가지 구체적인 구현이 있을 수 있습니다.

1. 즉, 개발을 위해 로컬에서 브랜치를 가져온 다음 개발 브랜치를 거치지 않고 로컬에서 마스터로 직접 병합합니다(그러나 이 방법을 사용하면 안 됩니다). 개발한 것과 일치합니다

2. 다른 옵션은 B와 C가 자신의 코드 줄만 제거한 다음 병합할 수 있다는 것입니다

마지막으로 이러한 종류의 git 작업은 비즈니스 및 개발 모델을 기반으로 분석해야 할 수도 있으므로 위에서 얻은 답변이 개발 사양과 반드시 일치하지 않을 수도 있다고 생각합니다.

1. A가cut 브랜치이고 개발 후 dev에 병합된 경우 마스터의 개발 브랜치에 있는 코드를 병합할 수 있습니다. (개발에서 BC 코드를 원하지 않는 경우 원래 커밋되지 않은 버전 번호를 롤백하고 A 코드를 병합할 수 있습니다. , 그리고 마스터 병합)
2. A가로컬 개발개발자에게 직접 제출하는 경우 제출한 항목이 많지 않은 경우 로그를 보고 A가 제출한 항목을 마스터에서 직접 선택할 수도 있습니다