다음은 설정입니다. 나는 team/repo라고 부르는 메인 github 저장소와 그것의 포크 (me/repo)를 가지고있다. me/repo에서 feature 브랜치 (일부 master 브랜치)를 변경하고 develop 분기에 대한 풀 요청을 team/repo에 작성합니다. team/repo에있는 develop 분기의 모든 변경 사항을 가져 오는 적절한 방법은 me/repo의 master 분기로 되돌려 보내시겠습니까?여러 리모컨을 동기화 상태로 유지하는 적절한 방법은 무엇입니까?
실제로 "적절한 방법"이 없으며 다른 팀이 채택하는 전략/흐름 만 다릅니다.
Gitflow 지점 관리 모델을 따르는 것 같습니다. Gitflow 아래에는 master 브랜치가 있습니다.이 브랜치는 반 누름 식 코드 세트로, 릴리스 된 코드의 영구 복사본을 나타냅니다. 활성화 된 develop 분기 (가능하면 둘 이상), release 분기 및 feature 분기가 있습니다. 당신이 REPO의 포크를 가지고 있기 때문에 포크
동기화
는origin이라는 리모컨으로 설정하고 원래 team/repo을 upstream이라는 리모컨으로 설정합니다. 포크를 업데이트하려면 upstream에서 풀다운 다음 변경 사항을 origin까지 푸시합니다. 이 부분에 문제가 있으면 This Answer on "Syncing A Fork"을 참조하십시오.이미이 모든 설정이있을 수 있지만 100 % 명확하지는 않습니다. 이 방법으로 설정하지 않으면 다음 대상을 벗어날 수 있습니다.
답변의 핵심은 로컬/포크에서 변경 사항을 team/repo (또는 원래 팀 중앙 저장소 인 upstream)으로 변경하는 방법입니다.
먼저 포크가 필요한지 고려하십시오. 가능성은 높지만 신뢰 문제가 있거나 큰 분산 (가능성이있는 다중 팀) 프로젝트 또는 오픈 소스가 아니면 포크가 필요하지 않을 수 있습니다. 가능한 경우, 기능 분기에서 직접 team/repo으로 직접 작업하고 포크의 복잡성을 피하십시오.
분기가 필요하다고 가정하면 feature 분기를 사용하고 develop 분기에서 team/repo으로 끌어 오기 요청을 수행합니다. 이것은 괜찮지 만 일련의 커밋에서 리베이스로 또는 단일 커밋을 결합하여 개발 분기로 변경 사항을 가져올 수 있습니다.
여기에서 변경 사항이 master으로 변경되는 방법과시기는 팀의 워크 플로에 따라 다릅니다. 개발이 Gitflow를 따르는 경우 즉시 master으로 갈 필요가 없습니다. feature 분기를 develop에서 분기해야하며 master을 벗어나지 않아야합니다. 홍보가 develop으로 변경된 후 새로운 develop을 로컬 저장소로 가져온 다음 포크로 밀어 넣고 feature 분기를 develop에서 만들거나 다음 feature 분기에서 계속 작업하여 다음 PR을 만듭니다. 필요합니다.
결국 팀은 develop을 master에 커밋하며 그 중 일부는 release 가지로 끝납니다. 그렇다면,이 대신 develop의 master 또는 release 지점을 분기해야하는 시간이 될 수도 있지만, 새로운 기능이 develop 떨어져 분기한다,하지 master (develop는에 병합 것 다시 master의 물적 분할).
팀이이 방법을 다르게 처리 할 수도 있지만, 이것이 어떻게 작동하는지, 올바른 질문을 할 수있는 느낌을 줄 것입니다. 요점은 여기에 반드시 문제가있는 것은 아니며 변경 사항이 즉시 master에 들어가야한다는 것입니다. 그들은 master에 넣으면 여전히 upstream에서 내려 놓습니다. 로컬 master을 체크 아웃하고 upstream/master에 병합하여 빨리 감기 한 다음 포크로 밀어 넣어야합니다.