프로젝트에 대한 풀 요청을 열었습니다. 관리자가 수락하기로 결정했지만 내용을 수정하라고 말했습니다.
내가 어떻게 해? 커밋 해시를 변경하지 않고 유지해야한다면 어떻게해야합니까?
답변
요청이있는 지점에 더 많은 커밋을 푸시하십시오. 풀 요청은 이것을 픽업하고
예:
b를 마스터로 병합하려면
- c1, c2, c3을 b로 밉니다
- 그런 다음 b에 대한 새로운 요청을합니다
- 검토를 받고 커밋이 더 필요합니다.
- c11, c21, c31을 b로 밉니다
- 풀 요청에 이제 6 개의 6 개의 커밋이 모두 표시됩니다.
답변
풀 요청에 커밋이 하나 있었으며 git commit --amend
업데이트에 사용했습니다. 그런 다음 git push -f
수정 된 커밋이 원래 커밋을 대체하도록 강제로 푸시했습니다 . 풀 요청이 자동으로 새 커밋을 선택했습니다. (실제로 커밋이 모두 표시되었지만 페이지를 다시로드하면 이전 커밋이 사라졌습니다.)
따라서 일반적으로 강제 푸시는 권장되지 않지만 풀 요청에 유용 할 수 있습니다. 누군가 내 커밋을 기반으로 한 경우 변경 후 리베이스를 수행해야하기 때문에 권장하지 않습니다. 그러나 아무도 검토중인 풀 요청에 기반을 두어서는 안되므로이 상황에서는 매우 안전해야합니다.
답변
계속 변경하고 동일한 브랜치로 계속 푸시하면 상세 커밋이 동일한 풀 요청에 추가됩니다 (풀 요청이 병합되지 않은 경우). 이것은 역사를 매우 어수선하게 만들 수 있습니다.
대체 솔루션과 사용하는 기술은 다음과 같습니다.
-
다음을 수행하여 풀 요청을 보내려는 저장소 (업스트림) 및 분기 (개발)에서 새 분기 (수정)를 작성하십시오.
자식 분기 수정 업스트림 / 개발
-
정제 된 커밋을 새로 작성된이 분기에 직접 추가하십시오.
git commit -m “당신의 메시지”
-
이 분기를 자신의 분기 된 리모컨 (원점으로 지정할 수 있음)으로 밉니다.
- 깨끗한 커밋 히스토리로 새로운 풀 요청을 비교하고 보냅니다.
- 또한 풀 요청이 병합 된 후 분기를 삭제하는 것이 좋습니다.
- 또한 이전 풀 요청에 주석을 달고 닫을 수 있습니다.
답변
github api 도 사용할 수 있습니다 .
컬이있는 예
curl --user "your_github_username" \
--request PATCH \
--data '{"title":"newtitle","body":"newbody",...}' \
https://api.github.com/repos/:owner/:repo/pulls/:number
github developer doc 에서 자세한 데이터 목록을 찾을 수 있습니다
예 : 풀 요청 이름 변경
curl --user "jeremyclement" \
--request PATCH \
--data '{"title":"allows the control of files and folders permissions."}' \
https://api.github.com/repos/Gregwar/Cache/pulls/9