이미 대상 분기에 있는 커밋을 표시하는 GitHub 풀 요청

이미 대상 분기에 있는 커밋을 표시하는 GitHub 풀 요청

GitHub에서 마스터가 아닌 지점으로 끌어오기 요청을 검토하려고 합니다.대상 브랜치가 마스터 뒤에 있고 꺼내기 요청에 마스터의 커밋이 표시되어 마스터를 병합하여 GitHub에 푸시했지만 새로 고침 후에도 꺼내기 요청에 커밋과 diff가 표시됩니다.GitHub의 지점이 마스터의 커밋을 가지고 있는지 두 번 확인했습니다.그들은 왜 아직도 끌어오기 요청에 나타나나요?

꺼내기 요청도 로컬에서 확인했는데 병합되지 않은 커밋만 표시됩니다.

여기 좋은 해결 방법이 있습니다.을 합니다.Edit볼 때 를 GitHub 입니다.master그런 다음 다시 전환합니다.master그러면 최근 커밋의 변경 내용만 올바르게 표시됩니다.

Pull Request가 대상 분기의 변경 사항을 추적하지 않는 것 같습니다(GitHub 지원팀에 연락하여 2014년 11월 18일에 이것이 설계에 의한 것이라는 답변을 받았습니다).

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

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

를 바꿉니다.githuburl,org,repo,targetbranch,그리고.currentbranch필요에 따라

또는 헥스스프라이트가 답변에서 지적했듯이 PR을 클릭하고 일시적으로 베이스를 다른 분기로 변경했다가 다시 업데이트하도록 강제할 수도 있습니다.그러면 다음과 같은 경고가 표시됩니다.

베이스를 변경하시겠습니까?

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

PR에 두 개의 로그 항목을 남깁니다.

요약하자면, GitHub은 풀 요청에서 커밋 기록을 자동으로 재배치하지 않습니다.가장 간단한 솔루션은 다음과 같습니다.

솔루션 1: 기본 재배치

다음으로 병합한다고 가정합니다.masterfeature-01:

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

포크 작업 중인 경우 교체해야 할 수 있습니다.origin에 이닌아로upstream원래 리포지토리의 원격 분기 추적에 대한 자세한 내용은 GitHub 포크된 리포지토리 업데이트 방법을 참조하십시오.

솔루션 2: 새 꺼내기 요청 만들기

인트로를 병합한다고 가정합니다.masterfeature-01:

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

이제 다음에 대한 끌어오기 요청을 엽니다.feature-01-rebased그리고 다음을 위해 하나를 닫습니다.feature-01.

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

저는 대상 분기의 병합을 포함한 기본 병합 전략으로 스쿼시 및 Github과 병합을 사용했습니다.이것은 새로운 커밋을 도입하고 GitHub는 이 찌그러진 커밋이 이미 마스터에 있는 커밋과 동일하다는 것을 인식하지 못합니다(그러나 해시는 다릅니다).Git는 적절하게 처리하지만 GitHub에서 모든 변경 사항을 다시 확인하여 검토하기가 귀찮습니다.해결책은 스쿼시와 병합 대신에 이러한 업스트림 커밋을 정기적으로 병합하는 것입니다.다른 지점에서 종속 항목으로 병합하려는 경우git merge --squash그리고 다른 분기가 실제로 마스터에 도달한 후 마스터에서 꺼내기 전에 단일 커밋을 되돌립니다.

EDIT: 다른 해결책은 기본 재배치 및 강제 푸시입니다.깨끗하지만 다시 쓴 역사

GitHub Pull Request 동작으로 인해 혼동되는 다른 사용자의 경우, 근본 원인은 PR이 소스 분기 및 대상 분기의 공통 조상에 대한 소스 분기 팁의 차이이기 때문입니다.따라서 공통 상위 항목까지 원본 분기의 모든 변경 사항을 표시하고 대상 분기에서 발생했을 수 있는 변경 사항은 고려하지 않습니다.

자세한 정보는 https://developer.atlassian.com/blog/2015/01/a-better-pull-request/ 에서 확인할 수 있습니다.

공통 조상 기반의 차이는 위험해 보입니다.깃허브가 좀 더 표준적인 3방향 병합 기반 PR을 만드는 옵션이 있었으면 좋겠습니다.

편집 - 이로 인해 발생하는 문제를 방지하기 위해 항상 사용하는 명백한 해결 방법에 대해 언급한 적이 없습니다.목표 지점을 홍보 지점에 정기적으로 병합하기만 하면 불쾌한 놀라움을 경험하지 못할 것입니다.

은 당신의 다을추합에 .~/.gitconfig파일 이름:

[rebase]
    autosquash = true

이렇게 하면 자동으로 이 답변에 표시된 것과 동일한 결과를 얻을 수 있습니다.

이거 여기서 가져왔어요.

이 문제를 해결하는 한 가지 방법은git rebase targetbranch그 홍보에서.그리고나서git push --force targetbranch그러면 Github은 올바른 커밋과 차이를 보여줄 것입니다.만약 당신이 무엇을 하고 있는지 모른다면 이것을 조심하세요.아마도 리베이스를 하기 위해 테스트 브랜치를 먼저 확인한 다음git diff targetbranch그게 당신이 원하는 것인지 확실히 하기 위해서요.

3-dot url 대신 2-dot url을 사용하여 비교합니다.

대신에

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

사용하다

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

제가 시도한 것과 왜 그런 일이 일어나는가요?

어떤 해결책도 저에게 효과가 없었습니다.두 개의 점을 사용했을 때. ..에 ...GH의 차이는 제가 바꾼 것에 훨씬 더 가까웠습니다.하지만 여전히 내 변화의 전부는 아닙니다.

이 문제는 GitHub에서 스쿼시 병합된 변경사항을 표시하는 방법에 문제가 있기 때문에 발생합니다.여기에 가장 잘 설명됨

기본적으로 다음과 같은 경우에 발생합니다.

1. 의 변경 사항 featureBranch
2. 그것을 스쿼시로 합칩니다.main
3. 사용자가 계속 켜져 있는 동안 로컬로featureBranch는 그것을 와병합다니와 합니다.main더 많은 내용을 변경하고 다시 위로 밀어 올립니다.
4. 하지만 GitHub에서는 제가 예상했던 것보다 더 많은 변화가 보입니다.

이것은 기트 문제가 아니라는 것을 주목할 필요가 있습니다.대신 GitHub 문제입니다. GitHub스퀴즈된 커밋이 비슬래시 커밋의 합계와 동일하다는 것을 알 수 없으며 추가 차이가 발생합니다.

---

해결책

로컬 메인에서 메인과 병합되지 않은 모든 변경사항을 실행 취소하고 저장합니다.그러기 위해서 저는 했습니다.예를 들어 PR에 포함되지 않은 4개의 커밋이 스쿼시에 병합된 경우 다음을 수행합니다.

• git reset HEAD~4
• git stash save "last 4 commits"

그런 다음 방금 저장한 항목으로 새 분기를 만듭니다.단계:

• git checkout main
• git checkout -b newBranch
• git stash apply
• git add --all
• git commit -m "some message"
• git push

새 변경을 시작하거나 PR을 만들기 전에 다음 작업을 시작하면 이 문제가 발생하지 않습니다.

git pull --rebase origin <target-branch>

이렇게 하면 기본적으로 로컬에서 추가되는 새 변경 사항이 원격 분기에 현재 있는 변경 사항 위에 쌓이게 됩니다.따라서 로컬 지점은 항상 현재 원격 헤드 위에 있고 PR에는 새 커밋만 있습니다.

저는 이것의 배후에 있는 이론에 대해 정확히 확신하지 못합니다.하지만 저는 이것을 여러 번 받았고 다음과 같이 함으로써 이것을 고칠 수 있었습니다.

git pull --rebase

이렇게 하면 원래 repo 마스터 분기에서 변경 사항을 가져오고 병합합니다(해당 사항이 있는 경우).

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

git push -f origin master

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

이 문제를 해결하는 게으른 방법:대상 분기의 파일에서 복사한 것과 동일한 코드를 사용하여 대상 분기에 이미 있는 파일을 수동으로 편집하고 저장합니다.커밋됩니다.이제 PR이 자동으로 업데이트되어 문제가 해결됩니다.

용사를 합니다.git cherry-pick

만약 리베이스 프로세스가 나처럼 당신을 위해 얽히게 된다면, 다른 선택은 깃체리픽을 사용하는 것입니다.단계는 다음과 같습니다.

• 을 사용하여 로컬 git pull.
• 변경한 지점을 체크아웃하고 원하는 커밋의 커밋 ID를 복사합니다. 만약 지점 이름이tangled하다, 하다, 하다, 하다, 하다, 하다, 하다, 하다, 나다git checkout tangled그리고 나서.git log키보드의 위쪽/아래쪽 화살표를 사용하여 Git log 출력을 스크롤할 수 있습니다.커밋 ID는 각 커밋에 포함된 긴 숫자입니다.
• 다음사예 대분기상여용하을예(예: )을 에서 새 에서 새 분기 생성git checkout -b new-branch-name목표 지점에 있을 때.
• 에서 새분에수행서기를 합니다.git cherry-pick commit-idcommit-id 긴다번니에서 한 긴 입니다.git log푸시할 커밋을 식별합니다.이 작업을 여러 번 수행하여 매번 ID를 변경하여 다른 커밋을 얻을 수 있습니다.
• 실행하는 경우git log새로 만든 분기에서 추가한 변경사항만 대상 분기의 머리글 뒤에 있는 것을 볼 수 있습니다.
• 마지막으로, 다음을 사용하여 변경사항을 원격으로 푸시합니다.git push origin new-branch-name끌어오기 요청을 만듭니다.

이 PR에 될 때 합니다.Squash and merge에 PR과 PR을 병합하면 .Create a merge commit선택.

• 병합 커밋 만들기
• 스쿼시 및 병합
• 기본 재배치 및 병합

참고: 이 작업이 완료되면 다음 PR은 항상 이전 커밋이 아닌 자체 커밋으로 표시됩니다. 이전 커밋은 이미 기본 브랜치에 추가되었기 때문입니다.Create a merge commit선택.

기술적 설명: 병합 --squash와 rebase의 차이점은 무엇입니까?

내가 대답하기 전에 내 문제에 대한 이야기:

마스터, 테스트, 기능 등 3가지를 고려하겠습니다.

테스트 분기에 이미 마스터 변경 사항이 있습니다.

마스터를 피쳐 분기에 병합한 다음 피쳐 분기에 작업하고 커밋할 때 문제가 발생하고 테스트에 대한 PR을 제기하면 이미 테스트 중인 변경 사항이 다시 표시됩니다.이것은 매우 답답하고 동료들은 명령 프롬프트를 사용하기 때문에 이 문제에 직면하지 않습니다.그리고 명령 프롬프트를 사용하고 싶지 않습니다.

저는 GitHub Desktop 앱을 사용하고 있는데 이런 일이 더 자주 일어나 오늘까지 아무것도 할 수 없었습니다.

피쳐 분기에 카운트 가능한 커밋(최대 4-5개)이 있는 경우에만 이 절차가 유용합니다.커밋이 많으면 헷갈릴 수 있습니다.

이제 GitHub 데스크톱 사용자를 위한 해결 방법:

1. 테스트 이름 "기능 병합 대 테스트"에서 분기 생성
2. 이러한 커밋을 "기능 병합 대 테스트"로 선택합니다.
3. 충돌을 해결합니다.
4. 이제 테스트 분기에 대한 PR을 높입니다.
5. 완료되면 "기능 병합 대 테스트" 분기를 삭제합니다.

GitHub이 데스크톱 응용 프로그램의 PR 문제를 해결할 때까지.저는 이 절차를 따라야 한다고 생각합니다. 저에게 효과가 있는 것 같습니다.주변에 효과적인 작업이 있는지 알려주세요.

그리고 베이스를 바꾸는 것(이 질문에 대한 첫 번째 대답)은 저에게 효과가 없었습니다.

올바른 행동을 할 수 있는 방법을 찾았습니다(2020년 11월 테스트).

나 뒤에git merge 충돌 은 사해야충해결을 해야 합니다.git merge --continue에 git commit ....

일을 망칠까봐 너무 걱정되면 안전한 접근을 실패합니다. 파일로 이동하여 수동으로 변경 사항을 제거한 다음 다음 다음을 사용하여 마지막 커밋으로 스쿼시합니다.

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})"

충돌은 없습니다. 가도 좋습니다!

언급URL : https://stackoverflow.com/questions/16306012/github-pull-request-showing-commits-that-are-already-in-target-branch