@ Mark Longair는 여기에 그의 대답에 못을 박았 지만 통찰력을 더하고 싶습니다.
특히 커밋을 스쿼시하는 것이 하나 이상의 master를 feature_branch로 병합하여 실효 적이 지 않은 경우 큰 PR (Pull Request)을 분리하는 방법에 대한 질문에 응답
내 상황 :
나는 feature_branch30 개의 커밋 으로 크게 만들고 GitHub에서 PR (Pull Request)을 열어서 합병했다 master. 지점 master은 저의 톤을 바꾸었고 저 feature_branch에게는 없었던 200 개의 커밋을 받았습니다 . 갈등을 해결 git checkout feature_branch하고 변경 사항을 내 git merge master것으로 병합했습니다 . 나는에 선택 이 아닌 내가 해결 충돌 대신 잠재적으로 30 배의 하나의 시간이 것 때문에 최신 마스터에 (내 커밋 각각에 대해 한 번). 30 커밋을 1로 먼저 스쿼시하고 최신 정보를 다시 사용하고 싶지 않았습니다.masterfeature_branchmergerebasemasterPR에서 GitHub 리뷰 댓글 기록을 지울 수 있기 때문입니다. 그래서 마스터를 기능 지점으로 병합하고 충돌을 한 번만 해결했습니다. 모든게 괜찮 았어. 그러나 내 PR은 동료들이 검토하기에는 너무 컸습니다. 나는 그것을 나누어야했다. 나는 30 번의 커밋과 OH NO! 그들은 어디에 있습니까? 그들은 master내가 최근에 합병했기 때문에 200 개의 최근 커밋 과 상호 작용 master하고 있습니다 feature_branch! 어떻게해야합니까?
git cherrygit cherry-pick개별 커밋 을 시도하려는 경우 사용법 :
git cherry 구조에 (다양한)!
안에 feature_branch있지만 안에 있지 않은 모든 커밋을 보려면 다음을 master수행하십시오.
git checkout feature_branch
git cherry master
또는 다음 과 같이 feature_branch먼저 수행 하여 모든 지점에서 커밋을 확인할 수 있습니다 git cherry [upstream_branch] [feature_branch]. 다시 말하지만 어떤 커밋이 있는지 확인 feature_branch하지만 upstream_branch( master이 경우)에 있지 않은 커밋이 있는지 확인합니다 .
git cherry master feature_branch
추가 -v하면 커밋 메시지 제목 줄이 표시됩니다.
git cherry -v master
"word count" "-lines"( wc -l)로 파이프하면 커밋 수를 계산합니다.
git cherry master | wc -l
이 수를 GithHub PR에 표시된 커밋 수와 비교하여 git cherry실제로 작동하고 있음을 더 잘 알 수 있습니다. 또한 git 해시를 하나씩 비교하여 git cherryGitHub와 일치하는지 확인할 수 있습니다. 주 git cherry당신이 합병 어떤 병합 커밋 계산하지 않습니다 master에를 feature_branch하지만, GitHub의 것입니다. 따라서 카운트에 약간의 불일치가 있으면 GitHub PR 커밋 페이지에서 "병합"이라는 단어를 검색하면에 표시되지 않는 범인 일 수 있습니다 git cherry. 예 : "지사 '마스터'를 feature_branch로 병합" 이라는 커밋 이 GitHub PR에 표시되지만 실행할 때는 표시되지 않습니다 git cherry master feature_branch. 이것은 괜찮고 기대됩니다.
이제 새로운 diff 브랜치를 선택하여이 diff를 분할하려는 diff를 git cherry master feature_branch찾을 수 있습니다. 로컬로 사용 하거나 GitHub PR에서 커밋을 볼 수 있습니다 .
스쿼시가 어떻게 도움이 될 수 있습니까?
그러나 내 큰 차이를 분할하는 대안 은 내 커밋 30 개를 모두 하나로 스쿼시하고 새 기능 분기에 패치하고 패치 커밋을 부드럽게 재설정 한 다음 git gui파일별로 조각을 추가하거나 조각으로 조각을 추가 하는 데 사용 합니다. 한 줄씩. 하나의 하위 기능을 얻으면 내가 추가 한 것을 커밋 한 다음 새 분기를 확인하고, 더 많은 것을 추가하고, 커밋하고, 새로운 분기를 체크 아웃하는 등 내 큰 기능이 여러 하위 기능으로 나눌 때까지 . 문제는 내 내 30 개 커밋으로 인해 다른 사람에서 다른 200 개 커밋과 혼합되어 있다는 것입니다 git merge master내에 feature_branch리베이스 따라서 비현실적이다, 그래서 다시 주문 (230 개) 커밋을 통해 선별해야 내 30 개 커밋 스쿼시 것 같이.
스쿼시를 대체하기 위해 패치 파일을 사용하는 방법 :
해결 방법은 커밋 30 개 중 "스쿼시 등가"가 포함 된 패치 파일 을 가져 와서 새 포크 master(새 하위 기능 지점)에 패치 한 후 다음과 같이 작업하는 것입니다.
git checkout feature_branch
# ensure I have the latest changes from master merged into feature_branch
git merge master
# Obtain a patch file, which is the equivalent of a squash of my 30 commits into 1 commit:
git diff master..feature_branch > ~/mypatch.patch
git checkout master
# Create a new, sub-feature branch
git checkout -b feature_branch2
# Patch the 30 commit patch file onto it:
git apply ~/mypatch.patch
이제 30 커밋 패치가 모두 로컬에 적용되었지만 준비되지 않고 커밋되지 않았습니다.
이제 git gui파일, 청크 및 / 또는 라인을 추가하고 큰 PR 또는 "diff"를 분리하는 데 사용하십시오.
이 없으면을 git gui사용하여 Ubuntu에 쉽게 설치할 수 있습니다 sudo apt install git-gui.
이제 git gui파일, 청크 및 / 또는 라인 추가 (git GUI 프로그램에서 마우스 오른쪽 버튼 클릭)를 시작하고 위에서 설명한 것처럼 커밋 기능 분기 30 개를 하위 분기로 나누고 반복적으로 추가, 커밋 및 포크 할 수 있습니다 새 기능 분기 및 모든 변경 사항이 하위 기능 지점에 추가되고 30 커밋 기능이 3 또는 4 하위 기능으로 성공적으로 분할 될 때까지이주기를 반복합니다. 각 하위 기능에 대해 별도의 PR을 열 수 있으며 팀에서 더 쉽게 검토 할 수 있습니다.
참고 문헌 :
- 자식 저장소에서 패치 또는 diff 파일을 만들어 다른 다른 자식 저장소에 적용하십시오.