풀 리퀘스트 리베이스 및 업데이트 방법

소개

오픈 소스 프로젝트에 기여하는 것은 자신과 같은 최종 사용자를 위해 더 나은 소프트웨어를 만들기 위해 노력하는 보람 있는 경험입니다. 풀 리퀘스트를 제출하면 프로젝트에 기여하는 과정에서 승인 전에 코드의 기초를 재조정하고 다시 작업한 다음 분기를 전반적으로 정리해야 할 수 있습니다.

이 자습서는 오픈 소스 소프트웨어 프로젝트에 끌어오기 요청을 제출한 후 수행해야 할 수 있는 다음 단계 중 일부를 안내합니다.

전제 조건

이 튜토리얼은 풀 요청을 한 후 수행할 단계를 안내하므로 Git이 이미 설치되어 있고 풀 요청을 만들었거나 만들 생각이 있어야 합니다.

2020년 11월부터 GitHub는 암호 기반 인증을 제거했습니다. 이러한 이유로 명령줄을 통해 GitHub 리포지토리에 액세스하려면 SSH 공개 키 정보를 생성해야 합니다.

오픈 소스 프로젝트에 기여하는 방법에 대해 자세히 알아보려면 GitHub에서 끌어오기 요청을 만드는 방법을 읽어보세요.”

코드 리베이스 및 주석 정리

오픈 소스에 기여하는 동안 분기 또는 풀 요청과 업스트림 코드 간에 충돌이 있음을 알 수 있습니다. 쉘에서 다음과 같은 오류가 발생할 수 있습니다.

Output
CONFLICT (content): Merge conflict in your-file.py
Automatic merge failed; fix conflicts and then commit the result.

또는 GitHub 웹사이트를 통한 풀 리퀘스트에서 다음과 같이 할 수 있습니다.

관리자가 풀 리퀘스트에 한동안 응답하지 않거나 많은 사람들이 한 번에 프로젝트에 기여하는 경우 이런 일이 발생할 수 있습니다. 이런 일이 발생하고 풀 요청을 병합하려는 경우 충돌을 해결하고 코드를 리베이스해야 합니다.

리베이스를 사용하면 기반이 되는 커밋을 변경하여 분기를 이동할 수 있습니다. 이렇게 하면 메인 브랜치의 최근 커밋을 기반으로 코드를 리베이스할 수 있습니다. 리베이스는 신중하게 수행해야 하며 프로세스 전반에 걸쳐 올바른 커밋과 올바른 분기에서 작업하고 있는지 확인해야 합니다. 또한 오류가 발생할 경우를 대비하여 아래의 git reflog 명령을 사용하여 살펴보겠습니다.

풀 리퀘스트 튜토리얼에서 했던 것처럼 코드 디렉토리로 이동할 것입니다.

cd repository

다음으로 git checkout 명령으로 이동하여 올바른 분기에 있는지 확인하려고 합니다.

git checkout new-branch

그런 다음 코드의 최신 업스트림 버전에 대해 git fetch를 실행합니다.

git fetch origin

프로젝트의 업스트림 버전을 가져오면 커밋 메시지를 스쿼시하거나 다른 말로 바꾸어 프로젝트 관리자가 더 잘 이해할 수 있도록 주석을 정리할 수 있습니다. 작은 커밋을 많이 하지 않은 경우에는 필요하지 않을 수 있습니다.

이 프로세스를 시작하려면 대화식 리베이스를 수행합니다. 대화식 리베이스를 사용하여 이전 커밋 메시지를 편집하거나, 여러 커밋을 하나로 결합하거나, 더 이상 필요하지 않은 커밋을 삭제하거나 되돌릴 수 있습니다. 이렇게 하려면 우리가 만든 커밋을 번호나 브랜치의 베이스를 참조하는 문자열로 참조할 수 있어야 합니다.

우리가 만든 커밋 수를 확인하려면 다음 명령을 사용하여 프로젝트에 대한 총 커밋 수를 검사할 수 있습니다.

git log

그러면 다음과 유사한 출력이 제공됩니다.

Output
commit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 <email-2>
Date:   Mon Dec 14 07:32:45 2015 -0400

    Commit details

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 <email-1>
Date:   Fri Nov 27 20:24:45 2015 -0500

    Commit details

로그에는 해당 프로젝트의 리포지토리에 대한 모든 커밋이 표시되므로 다른 커밋과 함께 커밋이 나열됩니다. 여러 작성자의 광범위한 커밋 기록이 있는 프로젝트의 경우 명령에서 자신을 작성자로 지정하는 것이 좋습니다.

git log --author=your-username

이 매개변수를 지정하면 커밋한 횟수를 셀 수 있어야 합니다. 여러 브랜치에서 작업하는 경우 명령 끝에 --branches[=<branch>]를 추가하여 브랜치별로 제한할 수 있습니다.

이제 리베이스하려는 브랜치에서 수행한 커밋 수를 알고 있으면 다음과 같이 git rebase 명령을 실행할 수 있습니다.

git rebase -i HEAD~x

여기서 -i는 대화형 rebase를 나타내고 HEAD는 기본 분기의 최신 커밋을 나타냅니다. x는 브랜치를 처음 가져온 이후 브랜치에 대한 커밋 수입니다.

그러나 브랜치에서 수행한 커밋 수를 모르는 경우 다음 명령을 실행하여 브랜치의 기반이 되는 커밋을 찾아야 합니다.

git merge-base new-branch main

이 명령은 커밋 해시라고 하는 다음과 같은 긴 문자열을 반환합니다.

Output
66e506853b0366c87f4834bb6b39d341cd094fe9

이 커밋 해시를 사용하여 git rebase 명령에 전달합니다.

git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

위의 명령 중 하나에 대해 명령줄 텍스트 편집기는 브랜치의 모든 커밋 목록이 포함된 파일과 함께 열리며 이제 커밋을 스쿼시할지 아니면 단어를 바꿀지 선택할 수 있습니다.

스쿼시 커밋

커밋 메시지를 스쿼시할 때 여러 개의 작은 커밋을 하나의 큰 커밋으로 스쿼시하거나 결합합니다.

각 커밋 앞에 "pick\이라는 단어가 표시되므로 커밋이 두 개 있는 경우 파일이 다음과 같이 표시됩니다.

pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

이제 첫 번째 줄을 제외한 파일의 각 줄에 대해 "pick\이라는 단어를 "squash\라는 단어로 바꾸어 커밋을 결합해야 합니다.

pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new feature

이 시점에서 파일을 저장하고 닫으면 모든 커밋의 모든 커밋 메시지를 결합한 새 파일이 열립니다. 적합하다고 생각되는 대로 커밋 메시지의 단어를 바꾼 다음 파일을 저장하고 닫을 수 있습니다.

파일을 닫으면 피드백을 받게 됩니다.

Output
Successfully rebased and updated refs/heads/new-branch.

이제 모든 커밋을 스쿼시하여 하나로 결합했습니다.

Reword 커밋

커밋 메시지를 다시 작성하는 것은 오타를 발견하거나 각 커밋에 대해 병렬 언어를 사용하지 않았다는 것을 깨달았을 때 유용합니다.

git rebase -i 명령으로 위에서 설명한 대로 대화식 리베이스를 수행하면 다음과 같은 파일이 열립니다.

pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

이제 단어를 바꾸려는 각 커밋에 대해 "pick\이라는 단어를 "reword\로 바꿉니다.

pick a1f29a6 Adding a new feature
reword 79c0e80 Adding a second new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

파일을 저장하고 닫으면 커밋 메시지의 수정된 문구를 보여주는 새 텍스트 파일이 터미널 편집기에 나타납니다. 파일을 다시 편집하려면 파일을 저장하고 닫기 전에 편집할 수 있습니다. 이렇게 하면 커밋 메시지가 유용하고 균일해집니다.

리베이스 완료

만들고 있는 커밋 수와 관련 커밋 메시지에 만족하면 최신 버전의 프로젝트 업스트림 코드 위에 브랜치 리베이스를 완료해야 합니다. 이렇게 하려면 리포지토리의 디렉터리에서 다음 명령을 실행해야 합니다.

git rebase origin/main

이 시점에서 Git은 커밋을 최신 버전의 메인으로 재생하기 시작합니다. 이런 일이 발생하는 동안 충돌이 발생하면 Git은 계속 진행하기 전에 충돌을 해결하라는 메시지를 표시하기 위해 일시 중지합니다. 해결할 항목이 없으면 출력에 다음 내용이 표시됩니다.

Output
Current branch new-branch is up to date.

충돌을 수정하면 다음을 실행합니다.

git rebase --continue 

이 명령은 이제 커밋을 계속 재생할 수 있음을 Git에 알립니다.

이전에 squash 명령을 사용하여 커밋을 결합한 경우 충돌을 한 번만 해결하면 됩니다.

Force-Push로 풀 요청 업데이트

rebase를 수행하면 분기의 히스토리가 변경되고 직접 경로가 수정되었기 때문에 더 이상 git push 명령을 사용할 수 없습니다.

대신 --force 또는 -f 플래그를 사용하여 변경 사항을 강제 푸시하여 Git에 푸시하는 내용을 완전히 알고 있음을 알려야 합니다.

먼저 push.default가 Git 2.0+의 기본값인 simple인지 다음과 같이 구성하여 확인합니다.

git config --global push.default simple

이 시점에서 작업 중인 브랜치를 확인하여 올바른 브랜치에 있는지 확인해야 합니다.

git checkout new-branch

Output
Already on 'new-branch'
. . .

이제 강제 푸시를 수행할 수 있습니다.

git push -f

이제 이것이 강제 업데이트라는 메시지와 함께 업데이트에 대한 피드백을 받아야 합니다. 풀 요청이 이제 업데이트되었습니다.

잃어버린 커밋 복구하기

어느 시점에서 더 큰 프로젝트에 통합하고 싶었던 커밋을 버린 경우 Git을 사용하여 실수로 버렸을 수 있는 커밋을 복원할 수 있어야 합니다.

git reflog 명령을 사용하여 누락된 커밋을 찾은 다음 해당 커밋에서 새 분기를 만듭니다.

Reflog는 분기 및 기타 참조의 팁이 로컬 저장소 내에서 마지막으로 업데이트된 시기를 기록하는 참조 로그의 약어입니다.

작업 중인 코드 리포지토리의 로컬 디렉터리에서 다음 명령을 실행합니다.

git reflog

이 명령을 실행하면 다음과 같은 출력이 표시됩니다.

Output
46f1962 HEAD@{0}: checkout: moving from branch-1 to new-branch
9370d03 HEAD@{1}: commit: code cleanups
a1f29a6 HEAD@{2}: commit: brand new feature 
38f2fc2 HEAD@{3}: commit: remove testing methods 
. . .

당신의 커밋 메시지는 당신이 남긴 커밋이 무엇인지 알려줄 것이고 관련 문자열은 왼쪽의 HEAD@{x} 정보 앞에 있을 것입니다. - 터미널 창의 한 쪽.

이제 해당 정보를 가져오고 관련 커밋에서 새 분기를 만들 수 있습니다.

git checkout -b new-new-branch a1f29a6

위의 예에서 a1f29a6 문자열로 표시되는 "완전히 새로운 기능\을 출시한 위에 표시된 세 번째 커밋에서 새 분기를 만들었습니다.

여기에서 수행해야 하는 작업에 따라 현재 자습서 상단에 있는 분기 설정 단계에 따라 새 분기를 리베이스하는 작업을 수행할 수 있습니다.

참고: 최근 git gc 명령을 실행하여 불필요한 파일을 정리하고 로컬 리포지토리를 최적화한 경우 손실된 커밋을 복원하지 못할 수 있습니다.

코드 리뷰에서 기대할 사항

풀 요청을 제출하면 더 큰 프로젝트와 대화하는 것입니다. 풀 리퀘스트를 제출하는 것은 당신이 더 큰 프로젝트에 대해 이야기하고 참여하는 것처럼 다른 사람들을 초대하여 당신의 작업에 대해 이야기하는 것입니다. 성공적인 대화를 위해서는 커밋 메시지를 통해 풀 요청을 하는 이유를 전달할 수 있는 것이 중요하므로 가능한 한 정확하고 명확하게 하는 것이 가장 좋습니다.

풀 리퀘스트 검토는 프로젝트에 따라 길고 상세할 수 있습니다. 프로세스를 학습 경험으로 생각하고 코드를 개선하고 풀 리퀘스트를 소프트웨어 프로젝트의 요구 사항에 맞게 개선하는 좋은 방법으로 생각하는 것이 가장 좋습니다. 검토를 통해 유지 관리자의 조언과 지시를 통해 직접 변경할 수 있어야 합니다.

풀 리퀘스트는 검토자의 메모 로그와 함께 진행한 모든 업데이트 및 토론을 보관합니다. 풀 요청이 수락되기 전에 이 프로세스 전반에 걸쳐 몇 가지 추가 커밋이 필요할 수 있습니다. 이것은 완전히 정상적인 현상이며 팀의 일원으로 수정 작업을 할 수 있는 좋은 기회를 제공합니다.

풀 리퀘스트는 Git을 통해 계속 유지되며 동일한 브랜치에 커밋을 계속 추가하고 이를 포크로 푸시하는 한 프로세스 전체에서 자동 업데이트됩니다.

동료의 검토를 위해 더 큰 세상에 코드를 공개하고 있지만 검토가 개인적인 것처럼 느껴져서는 안 되므로 관련 CONTRIBUTION.md 파일을 읽거나 행동 강령. 커밋이 프로젝트에서 지정한 지침과 일치하는지 확인하는 것이 중요하지만 불편함을 느끼기 시작하면 작업 중인 프로젝트가 기여할 가치가 없을 수 있습니다. 오픈 소스 커뮤니티에는 환영하는 공간이 많이 있으며 코드를 비판적인 시각으로 검토할 것을 기대할 수 있지만 받는 모든 피드백은 전문적이고 정중해야 합니다.

풀 리퀘스트 수락 및 브랜치 삭제

풀 요청이 수락되면 오픈 소스 소프트웨어 프로젝트에 성공적으로 기여한 것입니다!

이 시점에서 변경 사항을 로컬 리포지토리를 통해 포크로 다시 가져와야 합니다. 포크를 동기화하는 프로세스를 진행할 때 이미 수행한 작업입니다. 터미널 창에서 다음 명령을 사용하여 이 작업을 수행할 수 있습니다.

git checkout main
git pull --rebase origin main
git push -f origin main

이제 더 이상 필요하지 않은 두 위치에서 만든 분기를 제거하여 로컬 및 원격 분기를 모두 정리해야 합니다. 먼저 로컬 브랜치를 제거해 보겠습니다.

git branch -d new-branch

git branch 명령에 추가된 -d 플래그는 명령에 전달한 분기를 삭제합니다. 위의 예에서는 new-branch라고 합니다.

다음으로 원격 분기를 제거합니다.

git push origin --delete new-branch

브랜치가 삭제되면 리포지토리가 정리되고 이제 변경 사항이 기본 리포지토리에 저장됩니다. 풀 리퀘스트를 통해 변경한 사항이 이제 기본 리포지토리의 일부이기 때문에 공개 릴리스를 다운로드하는 일반 최종 사용자가 사용하지 못할 수도 있음을 명심해야 합니다. 일반적으로 소프트웨어 관리자는 몇 가지 새로운 기능과 수정 사항을 단일 공개 릴리스로 묶습니다.

결론

이 자습서에서는 오픈 소스 소프트웨어 리포지토리에 끌어오기 요청을 제출한 후 완료해야 할 수 있는 다음 단계 중 일부를 안내했습니다.

오픈 소스 프로젝트에 기여하고 적극적인 오픈 소스 개발자가 되는 것은 종종 보람 있는 경험입니다. 자주 사용하는 소프트웨어에 정기적으로 기여하면 해당 소프트웨어가 사용자 커뮤니티에 가치 있고 유용한지 확인하는 데 도움이 됩니다.