GitHub에서 마스터가 아닌 지점에 대한 풀 요청을 검토하려고합니다. 대상 브랜치가 마스터 뒤에 있었고 풀 요청에 마스터의 커밋이 표시되었으므로 마스터를 병합하여 GitHub에 푸시했지만 새로 고친 후에도 커밋과 diff는 여전히 풀 요청에 나타납니다. GitHub의 브랜치가 master의 커밋을 가지고 있는지 두 배로 확인했습니다. 풀 요청에 여전히 나타나는 이유는 무엇입니까?

또한 풀 요청을 로컬에서 확인했으며 병합되지 않은 커밋 만 표시합니다.

Pull Request가 대상 브랜치에 대한 변경 사항을 추적하지 않는 것 같습니다 (GitHub 지원 팀에 문의하여 2014 년 11 월 18 일에 의도적으로 설계된 것입니다).

그러나 다음을 수행하여 업데이트 된 변경 사항을 표시 할 수 있습니다.

http://githuburl/org/repo/compare/targetbranch...currentbranch

교체 githuburl, org, repo, targetbranch,와 currentbranch같은 필요.

또는 hexsprite가 자신의 답변에서 지적했듯이 EditPR 을 클릭 하고 일시적으로베이스를 다른 지점으로 변경하고 다시 다시 변경 하여 강제로 업데이트 할 수 있습니다 . 경고가 생성됩니다.

받침대를 바꾸시겠습니까?

이전 기본 지점에서 일부 커밋이 타임 라인에서 제거 될 수 있으며 이전 검토 주석이 오래 될 수 있습니다.

그리고 PR에 두 개의 로그 항목 이 남습니다 .

다음은 좋은 해결 방법입니다. EditGitHub에서 PR을 볼 때이 버튼을 사용하여 기본 분기를 다른 것으로 변경하십시오 master. 그런 다음 다시 전환 master하면 가장 최근의 커밋의 변경 사항 만 올바르게 표시됩니다.

요약하자면, GitHub는 풀 요청에서 커밋 히스토리를 자동으로 리베이스하지 않습니다. 가장 간단한 해결책은 다음과 같습니다.

해결 방법 1 : 리베이스

당신이에 병합한다고 가정 master에서 feature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force

포크로 작업하는 경우 origin위의 로 교체해야 할 수도 있습니다 upstream. GitHub 분기 저장소를 업데이트하는 방법을 참조하십시오 . 원래 저장소의 원격 브랜치 추적에 대해 자세히 알아보십시오.

해결 방법 2 : 새 풀 요청 생성

인트로를 병합한다고 가정합니다 master 에서feature-01 .

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

에 대한 풀 요청을 열고에 대한 요청을 feature-01-rebased닫습니다 feature-01.

~/.gitconfig파일에 다음을 추가해야 합니다.

[rebase]
    autosquash = true

이것은 이 답변이 보여주는 것과 동일한 결과를 자동으로 얻습니다 .

나는 여기 에서 이것을 얻었다 .

다른 사람이 GitHub Pull Request 동작으로 혼란스러워하는 이유는 PR이 소스 브랜치와 대상 브랜치의 공통 조상에 대한 소스 브랜치 팁의 차이이기 때문입니다. 따라서 소스 브랜치의 모든 변경 사항을 공통 조상까지 표시하고 대상 브랜치에서 발생할 수있는 변경 사항은 고려하지 않습니다.

자세한 내용은 여기를 참조 하십시오 : https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

공통 조상 기반의 차이는 위험 해 보입니다. GitHub에보다 표준적인 3 방향 병합 기반 PR을 만들 수있는 옵션이 있었으면합니다.

이 문제를 해결하는 한 가지 방법 git rebase targetbranch은 해당 PR에서하는 것입니다. 그런 git push --force targetbranch다음 Github은 올바른 커밋과 차이점을 보여줍니다. 하고있는 일을 모르는 경우이 점에주의하십시오. 어쩌면 먼저 테스트 브랜치를 체크 아웃하여 rebase를 수행 한 다음 git diff targetbranch여전히 원하는 지 확인하십시오.

이는 대상 브랜치에서 병합 된 커밋을 스쿼시 할 때 GitHub에서 발생합니다.

스쿼시를 사용하고 대상 지점의 병합을 포함하여 Github와 기본 병합 전략으로 병합했습니다. 이것은 새로운 커밋을 도입하고 GitHub는이 스쿼드 된 커밋이 이미 마스터에있는 커밋과 동일하다는 것을 인식하지 못합니다 (그러나 다른 해시). 힘내가 제대로 처리하지만 GitHub에서 모든 변경 사항을 다시 볼 수 있으므로 검토가 번거 롭습니다. 해결책은 스쿼시 및 병합 대신에 업스트림 커밋에서 가져온 이들을 정기적으로 병합하는 것입니다. 종속성으로 다른 브랜치를 병합하려는 경우,git merge --squash 하고 다른 브랜치가 실제로 마스터로 만든 후 마스터에서 가져 오기 전에 해당 단일 커밋을 되돌리려면.

편집 : 또 다른 해결책은 푸시하고 rebase하고 강제하는 것입니다. 깨끗하지만 재기록 된 역사

나는 이것의 이론에 대해 정확히 확신하지 못한다. 그러나 나는 이것을 여러 번 얻었고 다음을 수행하여 해결할 수 있습니다.

git pull --rebase

원래 리포지토리 마스터 브랜치에서 변경 사항을 가져오고 병합합니다 (지시 한 경우)

그런 다음 변경 사항을 github 복제 저장소 (대상)에 강제로 푸시하십시오.

git push -f origin master

이렇게하면 github 클론과 상위 리포지토리가 동일한 github 커밋 수준에 있고 분 기간에 불필요한 변경 사항이 표시되지 않습니다.

아래 명령을 하나씩 시도하십시오.

git pull "latest

git reset --hard master

엉망이 너무 걱정되면 안전한 접근 방법을 실패하십시오 : 파일로 이동하여 수동으로 변경 사항을 제거한 다음 마지막 커밋으로 스쿼시하십시오.

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

나는 갈등이 없습니다, 당신은 갈 수 있습니다!