GitHub에서 끌어오기 요청을 만드는 방법
소개
Git은 협업 소프트웨어 프로젝트를 보다 쉽게 관리할 수 있게 해주는 오픈 소스 분산 버전 제어 시스템입니다. 많은 프로젝트가 Git 리포지토리에 파일을 유지 관리하고 GitHub와 같은 플랫폼을 통해 코드를 액세스 가능하고 유용하며 효과적으로 공유하고 기여할 수 있습니다.
공개 리포지토리에서 호스팅되는 오픈 소스 프로젝트는 프로젝트가 코드 리포지토리에 대한 변경 사항을 수락하도록 요청하는 풀 요청을 통해 더 광범위한 개발자 커뮤니티에서 기여하는 이점을 얻습니다.
이 자습서는 오픈 소스 소프트웨어 프로젝트에 기여할 수 있도록 명령줄을 통해 Git 리포지토리에 풀 요청을 만드는 과정을 안내합니다.
전제 조건
로컬 컴퓨터에 Git이 설치되어 있어야 합니다. 이 가이드를 따라 컴퓨터에 Git이 설치되어 있는지 확인하고 운영 체제에 대한 설치 프로세스를 진행할 수 있습니다.
또한 GitHub 계정이 있거나 생성해야 합니다. GitHub 웹 사이트인 github.com을 통해 그렇게 할 수 있으며 로그인하거나 계정을 만들 수 있습니다.
2020년 11월부터 GitHub는 암호 기반 인증을 제거했습니다. 이러한 이유로 명령줄을 통해 GitHub 리포지토리에 액세스하려면 SSH 공개 키 정보를 생성해야 합니다.
마지막으로 기여할 오픈 소스 소프트웨어 프로젝트를 식별해야 합니다. 이 소개를 읽으면 오픈 소스 프로젝트에 더 익숙해질 수 있습니다.
리포지토리 복사본 만들기
리포지토리 또는 줄여서 리포지토리는 기본적으로 프로젝트의 기본 폴더입니다. 저장소에는 문서를 포함한 모든 관련 프로젝트 파일이 포함되어 있으며 각 파일의 개정 내역도 저장됩니다. GitHub에서 리포지토리는 여러 공동 작업자를 가질 수 있으며 공개 또는 비공개일 수 있습니다.
오픈 소스 프로젝트에서 작업하려면 먼저 자체 리포지토리 복사본을 만들어야 합니다. 이렇게 하려면 리포지토리를 포크한 다음 복제하여 로컬 작업 복사본을 만들어야 합니다.
저장소 포크
기여하려는 오픈 소스 프로젝트의 GitHub URL로 브라우저를 이동하여 GitHub에서 리포지토리를 분기할 수 있습니다.
GitHub 리포지토리 URL은 리포지토리 소유자와 연결된 사용자 이름과 리포지토리 이름을 모두 참조합니다. 예를 들어 DigitalOcean Community(사용자 이름: do-community)는 cloud_haiku 프로젝트 리포지토리의 소유자이므로 해당 프로젝트의 GitHub URL은 다음과 같습니다.
https://github.com/do-community/cloud_haiku
위의 예에서 do-community는 사용자 이름이고 cloud_haiku는 리포지토리 이름입니다.
기여할 프로젝트를 식별했으면 다음과 같은 형식의 URL로 이동할 수 있습니다.
https://github.com/username/repository
또는 GitHub 검색 표시줄을 사용하여 프로젝트를 검색할 수 있습니다.
저장소의 기본 페이지에 있을 때 페이지 오른쪽 상단의 사용자 아이콘 아래에 포크 버튼이 표시됩니다.
포크 버튼을 클릭하여 포크 프로세스를 시작합니다. 브라우저 창에서 포크하려는 리포지토리가 처리 중이라는 알림을 받게 됩니다.
프로세스가 완료되면 브라우저는 이전 리포지토리 화면과 유사한 화면으로 이동합니다. 단, 상단에는 리포지토리 이름 앞에 사용자 이름이 표시되고 URL에는 리포지토리 이름 앞에 사용자 이름이 표시됩니다.
따라서 위의 예에서 페이지 상단의 do-community/cloud_haiku 대신 your-username/cloud_haiku가 표시되고 새 URL은 다음과 유사하게 표시됩니다.
https://github.com/your-username/cloud_haiku
리포지토리가 분기되면 코드 베이스의 로컬 작업 복사본을 갖도록 복제할 준비가 된 것입니다.
리포지토리 복제
기여하고 싶은 리포지토리의 로컬 복사본을 만들려면 먼저 터미널 창을 엽니다.
저장소의 포크를 가리키는 URL과 함께 git clone 명령을 사용합니다.
이 URL은 위의 URL과 유사하지만 지금은 .git로 끝납니다. 위의 cloud_haiku 예에서 URL은 다음과 유사하게 표시되며 실제 사용자 이름은 사용자 이름을 대체합니다.
https://github.com/your-username/cloud_haiku.git
또는 원래 리포지토리 페이지에서 포크한 리포지토리 페이지의 녹색 "⤓ 코드\ 버튼을 사용하여 URL을 복사할 수 있습니다. 버튼을 클릭하면 다음 클립보드 버튼을 클릭하여 URL을 복사할 수 있습니다. URL:
URL이 있으면 저장소를 복제할 준비가 된 것입니다. 이를 위해 git clone 명령을 터미널 창의 명령줄에서 리포지토리 URL과 결합합니다.
git clone https://github.com/your-username/repository.git
이제 코드의 로컬 복사본이 있으므로 코드로 작업할 새 분기를 생성할 수 있습니다.
새 분기 만들기
협업 프로젝트에서 작업할 때마다 귀하와 저장소에 기여하는 다른 프로그래머는 새로운 기능이나 수정 사항에 대해 한 번에 다른 아이디어를 갖게 됩니다. 이러한 새로운 기능 중 일부는 구현하는 데 상당한 시간이 걸리지 않지만 일부는 계속 진행될 것입니다. 이 때문에 워크플로를 관리하고, 코드를 격리하고, 프로젝트 저장소의 기본 분기로 돌아가도록 만드는 기능을 제어할 수 있도록 저장소를 분기하는 것이 중요합니다.
프로젝트 리포지토리의 기본 분기를 일반적으로 기본 분기라고 합니다. 다른 사람이 언제든지 사용할 수 있도록 기본 분기의 모든 것을 배포할 수 있는 것으로 간주하는 것이 좋습니다.
참고: 2020년 6월 GitHub는 기본 소스 코드 분기를 master 분기 대신 main 분기로 참조하도록 용어를 업데이트했습니다. 기본 분기가 여전히 master로 표시되는 경우 기본 분기 설정을 변경하여 main으로 업데이트할 수 있습니다.
기존 프로젝트를 기반으로 분기를 만들 때 기본 분기에서 새 분기를 만드는 것이 매우 중요합니다. 또한 브랜치 이름이 설명이 포함된 이름인지 확인해야 합니다. my-branch라고 부르는 대신 frontend-hook-migration 또는 fix-documentation-typos와 같은 이름을 사용해야 합니다.
터미널 창에서 분기를 생성하려면 저장소의 디렉토리에서 작업하도록 디렉토리를 변경해 보겠습니다. 해당 디렉터리로 변경하려면 리포지토리의 실제 이름(예: cloud_haiku)을 사용해야 합니다.
cd repository
이제 git branch 명령을 사용하여 새 브랜치를 생성합니다. 프로젝트에서 작업하는 다른 사람들이 작업 중인 내용을 이해할 수 있도록 설명이 포함된 이름을 지정해야 합니다.
git branch new-branch
이제 새 분기가 생성되었으므로 git checkout 명령을 사용하여 해당 분기에서 작업 중인지 확인하도록 전환할 수 있습니다.
git checkout new-branch
git checkout 명령을 입력하면 다음과 같은 결과가 표시됩니다.
OutputSwitched to branch 'new-branch'
또는 다음 명령과 -b 플래그를 사용하여 위의 두 명령을 압축하여 새 분기를 만들고 전환할 수 있습니다.
git checkout -b new-branch
main으로 다시 전환하려면 메인 브랜치의 이름과 함께 checkout 명령을 사용합니다.
git checkout main
checkout 명령을 사용하면 여러 분기 간에 전환할 수 있으므로 한 번에 여러 기능을 작업할 수 있습니다.
이 시점에서 이제 기존 파일을 수정하거나 자체 분기의 프로젝트에 새 파일을 추가할 수 있습니다.
로컬에서 변경
풀 리퀘스트 만들기를 시연하기 위해 예제 cloud_haiku 리포지토리를 사용하고 로컬 복사본에 새 파일을 생성해 보겠습니다. 제공 지침에 설명된 대로 새 하이쿠 시를 추가할 수 있도록 원하는 텍스트 편집기를 사용하여 새 파일을 만듭니다. 예를 들어 nano를 사용하고 예제 파일 filename.md를 호출할 수 있습니다. Markdown용 .md 확장자를 사용하여 파일 이름을 원래 이름으로 지정해야 합니다.
nano filename.md
다음으로 기여 지침에 따라 새 파일에 일부 텍스트를 추가합니다. Jekyll 형식을 사용하고 줄 바꿈이 있는 하이쿠를 추가해야 합니다. 다음 파일은 원본 하이쿠를 제공해야 하므로 예제 파일입니다.
---
layout: haiku
title: Octopus Cloud
author: Sammy
---
Distributed cloud <br>
Like the octopuses' minds <br>
Across the network <br>
텍스트를 포함했으면 파일을 저장하고 닫습니다. nano를 사용한 경우 CTRL + X, Y, ENTER를 차례로 눌러 수행합니다.
기존 파일을 수정하거나 선택한 프로젝트에 새 파일을 추가하면 git add 명령을 사용하여 로컬 리포지토리에 스테이징할 수 있습니다. 이 예제 filename.md에서는 다음 명령을 입력합니다.
git add filename.md
생성한 파일의 이름을 이 명령에 전달하여 로컬 리포지토리에 준비했습니다. 이렇게 하면 파일을 추가할 준비가 된 것입니다.
수정한 모든 파일을 특정 디렉토리에 추가하려는 경우 다음 명령을 사용하여 모두 준비할 수 있습니다.
git add .
여기에서 마침표 또는 마침표는 모든 관련 파일을 추가합니다.
하위 디렉토리의 변경 사항을 포함하여 모든 변경 사항을 재귀적으로 추가하려는 경우 다음을 입력할 수 있습니다.
git add -A
또는 준비할 모든 새 파일에 대해 git add -all을 입력할 수도 있습니다.
파일이 준비되면 git commit 명령을 사용하여 리포지토리에 대한 변경 사항을 기록하려고 합니다.
변경 사항 커밋
커밋 메시지는 코드 기여의 중요한 측면입니다. 유지 관리자 및 기타 기여자가 변경 내용, 변경 이유 및 중요도를 완전히 이해하는 데 도움이 됩니다. 또한 커밋 메시지는 전체 프로젝트의 변경 사항에 대한 기록 기록을 제공하여 향후 기여자를 돕습니다.
매우 짧은 메시지가 있는 경우 -m 플래그와 따옴표 안에 메시지를 기록할 수 있습니다. 하이쿠를 추가하는 예에서 git commit은 다음과 유사할 수 있습니다.
git commit -m "Added a new haiku in filename.md file"
사소하거나 예상되는 변경이 아닌 한, 공동 작업자가 기여에 완전히 적응할 수 있도록 더 긴 커밋 메시지를 포함할 수 있습니다. 이 더 큰 메시지를 기록하기 위해 기본 텍스트 편집기를 여는 git commit 명령을 실행합니다.
git commit
이 명령을 실행할 때 vim 편집기에 있음을 알 수 있으며 :q를 입력하여 종료할 수 있습니다. 기본 텍스트 편집기를 구성하려면 git config 명령을 사용하여 구성하고 nano를 기본 편집기로 설정할 수 있습니다. 예를 들면 다음과 같습니다.
git config --global core.editor "nano"
또는 vim:
git config --global core.editor "vim"
git commit 명령을 실행한 후 사용 중인 기본 텍스트 편집기에 따라 터미널 창에 다음과 같이 편집할 수 있는 문서가 표시되어야 합니다.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch new-branch
# Your branch is up-to-date with 'origin/new-branch'.
#
# Changes to be committed:
# modified: new-feature.py
#
소개 주석 아래에 커밋 메시지를 텍스트 파일에 추가해야 합니다.
유용한 커밋 메시지를 작성하려면 약 50자 길이의 요약을 첫 번째 줄에 포함해야 합니다. 이 아래에는 이해하기 쉬운 섹션으로 구분되어 변경 이유, 코드 작동 방식, 병합 시 다른 사람이 작업을 검토할 수 있도록 컨텍스트화하고 명확히 하는 추가 정보를 설명하는 설명을 포함해야 합니다. 프로젝트를 유지 관리하는 사람들이 귀하의 기여를 완전히 이해할 수 있도록 가능한 한 도움이 되고 적극적으로 노력하십시오.
푸시 변경
커밋 메시지 텍스트 파일을 저장하고 종료하면 다음 명령을 사용하여 커밋할 Git을 확인할 수 있습니다.
git status
변경 사항에 따라 다음과 유사한 출력이 표시됩니다.
OutputOn branch new-branch
nothing to commit, working tree clean
이 시점에서 git push 명령을 사용하여 포크된 저장소의 현재 분기에 변경 사항을 푸시할 수 있습니다.
git push --set-upstream origin new-branch
이 명령은 진행 상황을 알려주는 출력을 제공하며 다음과 유사합니다.
OutputCounting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 336 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/your-username/repository.git
a1f29a6..79c0e80 new-branch -> new-branch
Branch new-branch set up to track remote branch new-branch from origin.
이제 GitHub 웹 페이지에서 분기된 리포지토리로 이동하고 푸시한 분기로 전환하여 브라우저에서 변경한 사항을 볼 수 있습니다.
이 시점에서 원래 리포지토리에 풀 요청을 할 수 있지만 아직 수행하지 않은 경우 로컬 리포지토리가 업스트림 리포지토리로 최신 상태인지 확인해야 합니다.
로컬 리포지토리 업데이트
다른 기여자와 함께 프로젝트에서 작업하는 동안 자동으로 충돌을 일으키는 코드에 대한 풀 요청을 원하지 않기 때문에 로컬 리포지토리를 프로젝트와 함께 최신 상태로 유지하는 것이 중요합니다. 공동 코드 프로젝트, 충돌이 발생할 수밖에 없습니다). 코드 베이스의 로컬 복사본을 최신 상태로 유지하려면 변경 사항을 동기화해야 합니다.
먼저 포크용 리모컨을 구성한 다음 포크를 동기화합니다.
포크에 대한 원격 구성
원격 리포지토리를 사용하면 Git 프로젝트에서 다른 사람과 협업할 수 있습니다. 각 원격 리포지토리는 인터넷 또는 액세스 권한이 있는 네트워크에서 호스팅되는 프로젝트 버전입니다. 각 원격 저장소는 사용자 권한에 따라 읽기 전용 또는 읽기-쓰기로 액세스할 수 있어야 합니다.
포크에서 변경한 내용을 작업 중인 원래 리포지토리와 동기화하려면 업스트림 리포지토리를 참조하는 원격을 구성해야 합니다. 원격을 업스트림 리포지토리에 한 번만 설정해야 합니다.
먼저 구성한 원격 서버를 확인하겠습니다. git remote 명령은 이미 지정한 모든 원격 리포지토리를 나열하므로 위에서 수행한 대로 리포지토리를 복제한 경우 최소한 기본 이름인 원본 리포지토리에 대한 출력을 받게 됩니다. 복제된 디렉토리에 대한 Git에 의해.
터미널 창의 저장소 디렉토리에서 -v 플래그와 함께 git remote 명령을 사용하여 관련 원격과 함께 Git이 저장한 URL을 표시합니다. 짧은 이름(\원본에서와 같이):
git remote -v
리포지토리를 복제했으므로 출력은 다음과 유사해야 합니다.
Outputorigin https://github.com/your-username/forked-repository.git (fetch)
origin https://github.com/your-username/forked-repository.git (push)
이전에 둘 이상의 원격을 설정한 경우 git remote -v 명령은 모든 원격 목록을 제공합니다.
다음으로 포크와 동기화할 새 원격 업스트림 리포지토리를 지정합니다. 이것은 우리가 포크한 원래 저장소가 될 것입니다. git remote add 명령으로 이 작업을 수행합니다.
git remote add upstream https://github.com/original-owner-username/original-repository.git
cloud_haiku 예의 경우 이 명령은 다음과 같습니다.
git remote add upstream https://github.com/do-community/cloud_haiku.git
이 예에서 upstream은 Git의 관점에서 "upstream\이 우리가 복제한 저장소를 나타내기 때문에 원격 저장소에 제공한 짧은 이름입니다. 원격 포인터를 추가하려는 경우 공동 작업자의 저장소인 경우 해당 공동 작업자의 사용자 이름 또는 짧은 이름에 대한 단축 닉네임을 제공할 수 있습니다.
리포지토리 디렉터리에서 git remote -v 명령을 다시 사용하여 업스트림 리포지토리에 대한 원격 포인터가 제대로 추가되었는지 확인할 수 있습니다.
git remote -v
Outputorigin https://github.com/your-username/forked-repository.git (fetch)
origin https://github.com/your-username/forked-repository.git (push)
upstream https://github.com/original-owner-username/original-repository.git (fetch)
upstream https://github.com/original-owner-username/original-repository.git (push)
이제 전체 URL을 작성하는 대신 명령줄에서 업스트림을 참조할 수 있으며 포크를 원래 리포지토리와 동기화할 준비가 되었습니다.
포크 동기화
GitHub에서 업스트림 및 원본 리포지토리를 참조하는 원격을 구성하고 나면 리포지토리의 포크를 동기화하여 최신 상태로 유지할 준비가 된 것입니다.
포크를 동기화하기 위해 터미널 창의 로컬 리포지토리 디렉터리에서 git fetch 명령을 사용하여 업스트림 리포지토리에서 각각의 커밋과 함께 분기를 가져옵니다. 업스트림 리포지토리를 참조하기 위해 짧은 이름 "upstream\을 사용했으므로 이를 명령에 전달합니다.
git fetch upstream
리포지토리를 포크한 이후 변경된 사항에 따라 출력이 다를 수 있으며 개체 수 계산, 압축 및 압축 해제에 대한 몇 줄을 포함할 수 있습니다. 출력은 다음 줄과 유사하게 종료되지만 프로젝트에 포함된 분기 수에 따라 달라질 수 있습니다.
OutputFrom https://github.com/original-owner-username/original-repository
* [new branch] main -> upstream/main
이제 메인 브랜치에 대한 커밋은 upstream/main이라는 로컬 브랜치에 저장됩니다.
리포지토리의 로컬 기본 분기로 전환해 보겠습니다.
git checkout main
OutputSwitched to branch 'main'
이제 로컬 upstream/main 분기를 통해 액세스할 원래 리포지토리의 기본 분기에서 변경된 사항을 로컬 기본 분기와 병합합니다.
git merge upstream/main
여기서 출력은 다양하지만 변경 사항이 있는 경우 업데이트 중 또는 이미 최신으로 시작됩니다. 저장소를 포크한 이후 변경된 사항이 없는 경우.
포크의 기본 브랜치는 이제 업스트림 리포지토리와 동기화되며 로컬 변경 사항은 손실되지 않습니다.
자신의 작업 흐름과 변경에 소요되는 시간에 따라 원하는 만큼 포크를 원래 리포지토리의 업스트림 코드와 동기화할 수 있습니다. 그러나 충돌하는 코드를 자동으로 제공하지 않도록 풀 요청을 하기 직전에 포크를 확실히 동기화해야 합니다.
풀 리퀘스트 생성
이제 원본 리포지토리에 풀 요청을 할 준비가 되었습니다.
포크된 저장소로 이동하여 페이지 왼쪽에 있는 New pull request 버튼을 눌러야 합니다.
다음 화면에서 분기를 수정할 수 있습니다. 양쪽에서 드롭다운 메뉴와 해당 브랜치에서 적절한 리포지토리를 선택할 수 있습니다.
예를 들어 왼쪽에 있는 원래 리포지토리의 기본 분기와 오른쪽에 있는 분기된 리포지토리의 new-branch를 선택하면 화면이 표시됩니다. 경쟁 코드가 없는 경우 분기를 병합할 수 있음을 나타냅니다.
적절한 필드에 제목과 설명을 추가한 다음 풀 요청 만들기 버튼을 눌러야 합니다.
이 시점에서 원래 리포지토리의 관리자가 풀 요청을 수락할지 여부를 결정합니다. 코드 검토 제출을 통해 풀 요청을 수락하기 전에 코드를 편집하거나 수정하도록 요청할 수 있습니다.
결론
이 시점에서 풀 요청을 오픈 소스 소프트웨어 리포지토리로 성공적으로 보냈습니다. 그런 다음 검토를 기다리는 동안 코드를 업데이트하고 리베이스해야 합니다. 프로젝트 관리자가 코드 재작업을 요청할 수 있으므로 그렇게 할 준비가 되어 있어야 합니다.
오픈 소스 프로젝트에 기여하고 적극적인 오픈 소스 개발자가 되는 것은 보람 있는 경험이 될 수 있습니다. 자주 사용하는 소프트웨어에 정기적으로 기여하면 해당 소프트웨어가 다른 최종 사용자에게 최대한 가치가 있는지 확인할 수 있습니다.
Git에 대해 자세히 알아보고 오픈 소스 소프트웨어에서 공동 작업하는 데 관심이 있다면 How To Use Git: A Reference Guide라는 제목의 자습서 시리즈를 읽을 수 있습니다.”