이미 대상 브랜치에있는 커밋을 보여주는 GitHub 풀 요청

이미 대상 브랜치에있는 커밋을 보여주는 GitHub 풀 요청

---

GitHub에서 마스터가 아닌 브랜치에 대한 풀 요청을 검토하려고합니다. 대상 브랜치는 마스터 뒤에 있었고 풀 요청은 마스터의 커밋을 보여 주었으므로 마스터를 병합하고 GitHub에 푸시했지만 새로 고침 후에도 여전히 풀 요청에 커밋 및 차이가 나타납니다. GitHub의 분기에 마스터의 커밋이 있는지 두 번 확인했습니다. 여전히 pull 요청에 나타나는 이유는 무엇입니까?

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

---

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는 pull 요청에서 커밋 기록을 자동으로 리베이스하지 않습니다. 가장 간단한 솔루션은 다음과 같습니다.

솔루션 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.

---

이 문제를 해결하는 한 가지 방법 git rebase targetbranch은 해당 PR을 사용하는 것입니다. 그런 git push --force targetbranch다음 Github에서 올바른 커밋과 diff를 표시합니다. 당신이 무엇을하고 있는지 모른다면 이것에주의하십시오. 리베이스를 수행 git diff targetbranch하기 위해 먼저 테스트 브랜치를 체크 아웃 한 다음 원하는 것이 여전히 있는지 확인하십시오.

---

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

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

Common ancestor based diffs seem dangerous. I wish GitHub had an option to make a more standard 3-way merge-based PR.

---

You need to add the following to your ~/.gitconfig file:

[rebase]
    autosquash = true

This will automatically achieve the same as what this answer shows.

I got this from here.

---

This happens with GitHub when you squash commits merged in from the target branch.

I had been using squash and merge with Github as the default merge strategy, including merges from the target branch. This introduces a new commit and GitHub doesn't recognize that this squashed commit is the same as the ones already in master (but with different hashes). Git handles it properly but you see all the changes again in GitHub, making it annoying to review. The solution is to do a regular merge of these pulled in upstream commits instead of a squash and merge. When you want to merge in another branch into yours as a dependency, git merge --squash and revert that single commit before pulling from master once that other branch has actually made it to master.

---

I'm not exactly sure about the theory behind this. But I got this several times and able to fix this by doing the following.

git pull --rebase

이것은 원래 repo 마스터 브랜치에서 변경 사항을 가져오고 병합합니다 (포인트가있는 경우)

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

git push -f origin master

이렇게하면 github 클론과 부모 저장소가 동일한 github 커밋 수준에 있고 분기간에 불필요한 변경 사항이 표시되지 않습니다.

---

일을 엉망으로 만드는 것이 너무 걱정된다면 Fail safe 접근 방식 : 파일로 이동하여 수동으로 변경 사항을 제거한 다음 다음을 사용하여 마지막 커밋으로 스쿼시하십시오.

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