코드 검토 후 풀 요청을 업데이트하기위한 기본 Github 워크 플로우

Github의 오픈 소스 프로젝트에 변경 사항을 제출했으며 핵심 팀 구성원 중 한 사람으로부터 코드 검토 의견을 받았습니다.

검토 의견을 고려하여 코드를 업데이트하고 다시 제출하고 싶습니다. 이 작업을 수행하는 가장 좋은 워크 플로는 무엇입니까? git / github에 대한 제한된 지식으로 다음 중 하나를 수행 할 수 있습니다.

1. 코드를 새로운 커밋으로 업데이트하고 초기 커밋과 업데이트 된 커밋을 모두 내 풀 요청에 추가하십시오.

2. 어떻게 든 (??) 내 저장소에서 이전 커밋을 롤백하고 모든 것을 포함하는 하나의 새 커밋을 만든 다음 풀 요청을 제기합니까?

3. git commit수정 기능이 있지만 로컬 저장소 외부로 커밋을 푸시 한 후에는 사용하지 않아야한다고 들었습니다. 이 경우 로컬 PC를 변경하고 프로젝트의 github 분기로 푸시했습니다. '수정'을 사용해도 되겠습니까?

4. 다른 것?

오픈 소스 프로젝트는 역사상 모든 것을 구현하는 커밋이 하나뿐이기 때문에 옵션 2/3이 좋을 것 같습니다. 그러나 어떻게 해야할지 모르겠습니다.

참고 : 이것이 답변에 영향을 미치는지 여부는 알 수 없지만 별도의 지점에서 변경하지 않았으며 방금 마스터 위에서 커밋을했습니다.

풀 요청에 사용 된 브랜치에 새로운 커밋을 추가하고 브랜치를 GitHub로 푸시하십시오. 풀 요청은 추가 커밋으로 자동 업데이트됩니다.

# 2와 # 3은 불필요합니다. 분기가 병합 된 위치 만 (추가 커밋이 아닌)보고자하는 경우 git log --first-parent로그에서 병합 커밋 만 보는 데 사용할 수 있습니다 .

풀 요청을 업데이트하려면

풀 요청 (포인트 # 1)을 업데이트하려면 풀 요청과 동일한 브랜치를 체크 아웃하고 다시 푸시해야합니다.

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

선택 사항-커미트 히스토리 정리

저장소 히스토리가 정리되도록 커밋을 모두 스쿼시하라는 요청을 받거나 풀 요청의 "메시지"에서 산만 한 중간 커밋을 제거하려고합니다 (포인트 # 2). 예를 들어 커밋 기록이 다음과 같은 경우

$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

하나의 커밋으로 보이도록 함께 스쿼시하는 것이 좋습니다.

$ git rebase -i parent/master 

그러면 풀 요청 기록을 다시 쓰는 방법을 선택하라는 메시지가 표시되며 편집기에 다음이 표시됩니다.

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

커밋의 경우 이전 커밋에 참여하고 싶습니다-pick을 squash로 변경하십시오.

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

편집기를 닫습니다. Git은 히스토리를 다시 작성하고 하나의 결합 된 커밋에 대한 커밋 메시지를 제공하라는 메시지를 표시합니다. 이에 따라 수정하면 커밋 기록이 간결 해집니다.

$ git log --oneline parent/master..master
9de3202 fixing actual problem

포크로 밀어 넣으십시오.

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

풀 요청에는 단일 커밋이 포함되며 이전에 여러 커밋으로 분할 된 모든 변경 사항이 통합됩니다.

공개 리포지토리의 역사를 바꾸는 것은 나쁜 일입니다

히스토리를 다시 작성하고 git push -f잠재적으로 다른 누군가가 이미 복제 한 브랜치에서 사용 하는 것은 나쁜 일입니다. 리포지토리 히스토리와 체크 아웃 히스토리가 분기됩니다.

그러나 저장소에 통합 할 것을 제안 하는 변경 사항을 수정하기 위해 포크 기록을 수정 하는 것이 좋습니다. 따라서 풀 요청에서 "노이즈"를 찌그러 뜨리는 예약이 없습니다.

나뭇 가지에 대한 메모

위의 내용에서 master포크 요청이 포크 분기 에서 온 것으로 표시 하지만 반드시 잘못된 것은 아니지만 표준 기술인 경우 저장소 당 하나의 PR 만 열 수있는 것과 같은 특정 제한을 만듭니다. . 제안하려는 각 개별 변경에 대해 분기를 작성하는 것이 좋습니다.

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets