프로젝트에 대한 풀 요청을 열었습니다. 관리자가 수락하기로 결정했지만 내용을 수정하라고 말했습니다.

내가 어떻게 해? 커밋 해시를 변경하지 않고 유지해야한다면 어떻게해야합니까?

요청이있는 지점에 더 많은 커밋을 푸시하십시오. 풀 요청은 이것을 픽업하고

예:

b를 마스터로 병합하려면

1. c1, c2, c3을 b로 밉니다
2. 그런 다음 b에 대한 새로운 요청을합니다
3. 검토를 받고 커밋이 더 필요합니다.
4. c11, c21, c31을 b로 밉니다
5. 풀 요청에 이제 6 개의 6 개의 커밋이 모두 표시됩니다.

풀 요청에 커밋이 하나 있었으며 git commit --amend업데이트에 사용했습니다. 그런 다음 git push -f수정 된 커밋이 원래 커밋을 대체하도록 강제로 푸시했습니다 . 풀 요청이 자동으로 새 커밋을 선택했습니다. (실제로 커밋이 모두 표시되었지만 페이지를 다시로드하면 이전 커밋이 사라졌습니다.)

따라서 일반적으로 강제 푸시는 권장되지 않지만 풀 요청에 유용 할 수 있습니다. 누군가 내 커밋을 기반으로 한 경우 변경 후 리베이스를 수행해야하기 때문에 권장하지 않습니다. 그러나 아무도 검토중인 풀 요청에 기반을 두어서는 안되므로이 상황에서는 매우 안전해야합니다.

계속 변경하고 동일한 브랜치로 계속 푸시하면 상세 커밋이 동일한 풀 요청에 추가됩니다 (풀 요청이 병합되지 않은 경우). 이것은 역사를 매우 어수선하게 만들 수 있습니다.

대체 솔루션과 사용하는 기술은 다음과 같습니다.

1. 다음을 수행하여 풀 요청을 보내려는 저장소 (업스트림) 및 분기 (개발)에서 새 분기 (수정)를 작성하십시오.

   자식 분기 수정 업스트림 / 개발

2. 정제 된 커밋을 새로 작성된이 분기에 직접 추가하십시오.

   git commit -m "당신의 메시지"

3. 이 분기를 자신의 분기 된 리모컨 (원점으로 지정할 수 있음)으로 밉니다.

4. 깨끗한 커밋 히스토리로 새로운 풀 요청을 비교하고 보냅니다.
5. 또한 풀 요청이 병합 된 후 분기를 삭제하는 것이 좋습니다.
6. 또한 이전 풀 요청에 주석을 달고 닫을 수 있습니다.

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