Skip to main content

GitHub 워크플로 작업하기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

  • GitHub 워크플로에 단계를 나열할 수 있습니다.
  • 원격 근무 환경과 현지 근무 환경의 차이점을 설명할 수 있습니다.
  • 단계를 완료하여 새 파일을 만들고 기존 파일을 변경할 수 있습니다.

코드, 공동 작업, 전송을 순서대로 나타내는 플로 차트.

GitHub 워크플로 개요

GitHub 플로는 프로젝트를 손상시킬 염려 없이 새로운 아이디어를 안전하게 테스트할 수 있는 간단한 워크플로입니다. 주요 단계는 다음과 같습니다.

  1. 메인에서 벗어난 브랜치 만들기
  2. 커밋 만들기
  3. 풀 요청 열기
  4. 협업하기
    • 더 많은 커밋 만들기
    • 팀 구성원과 코드에 대해 논의하고 검토하기
  5. 최종 테스트를 위해 배포하기
  6. 메인 브랜치로 브랜치 병합하기

분기 만들기 

브랜칭은 Git의 핵심 개념입니다. Git의 모든 것은 브랜칭을 통해 이루어집니다. 기본적으로 프로젝트의 프로덕션 버전은 메인 브랜치에 있습니다. 

새 기능을 실험하거나 문제를 해결할 준비가 되면 프로젝트의 새 브랜치를 만듭니다. 브랜치는 처음에는 기본값과 동일하게 표시되지만 변경한 내용은 브랜치에만 반영됩니다. 

커밋 만들기 

프로젝트 내의 파일을 변경하는 동안 기능 분기로 커밋합니다.

가져오기 요청을 열고 협업하기 

가져오기 요청을 열어 변경 사항에 대해 논의하세요. 풀 요청은 코드 개선의 시작점이 될 수 있기 때문에 코드가 완벽할 필요는 없습니다.

참고

가장 좋은 방법은 가능한 한 빨리 풀 요청을 여는 것입니다. 이를 통해 프로세스 과정에서 팀 구성원과 공동 작업자에게 가시성을 부여하고 변경 사항이 다른 방향으로 진행될 경우 불필요한 작업량을 줄일 수 있습니다.

메인 분기에 병합하기 

팀이 변경 내용을 승인하면 기능 분기에서 메인 분기로 풀 요청을 배포하고 병합합니다. 

이론적으로는 멋져 보입니다. 이제 실행에 옮겨 보겠습니다.

Git 설치하기

이 유닛의 나머지 부분에서 Git 예를 살펴보기 전에 먼저 컴퓨터에 Git을 설치해야 합니다. 이렇게 하면 로컬에서 저장소 작업을 수행할 수 있습니다. Git 웹 사이트를 방문하여 Git 공식 버전을 설치하는 방법을 따르세요. 설치 시 기본 설정을 모두 수락합니다.

GitHub 계정 가입 및 저장소 만들기

가장 먼저 해야 할 일은 GitHub 개인 계정에 가입하는 것입니다. 이 버전은 GitHub의 무료 버전이며 이를 통해 다음 단계를 따를 수 있습니다.

다음으로는 작업할 저장소를 만듭니다.

  1. 머리글에서 추가 아이콘 이미지를 클릭하고 New repository(새 저장소)를 선택합니다. 
  2. 다음 저장소 이름을 입력합니다. best-repo-ever
  3. 프로젝트가 공개인지 비공개인지 선택합니다.
  4. Initialize this repository with(저장소 초기화)에서 Add a README file(README 파일 추가)을 선택합니다.
  5. 그런 다음 Create repository(저장소 만들기)를 클릭합니다.

위에서 설명한 대로 저장소 이름 초기화가 설정되어 있는 새 저장소 만들기 화면

GitHub에서의 작업과 로컬에서의 작업 비교하기

GitHub에서 직접 프로젝트를 변경할 수 있지만 대부분의 사람들은 로컬 컴퓨터에서 작업하는 것을 선호합니다. 익숙한 IDE 또는 텍스트 편집기로 변경할 수 있기 때문입니다. 몇 가지 중요한 용어를 살펴보겠습니다.

  1. 원격 저장소는 GitHub에 있는 저장소 사본입니다. 모든 공동 작업자는 변경 사항을 원격 저장소와 동기화하여 변경 사항을 그룹 내 신뢰할 수 있는 소스로 만듭니다.
  2. 로컬 저장소는 사용자의 컴퓨터에 저장된 git 저장소입니다. 로컬 디렉터리가 원격 저장소에 연결된 경우 로컬 저장소는 모든 파일, 브랜치 및 내역을 포함하여 원격 저장소에 있는 모든 것이 있는 전체 복사본이 됩니다.

로컬 및 원격 저장소는 Git에서 git clone, git fetch, git pullgit push의 네 가지 네트워크 명령 중 하나를 실행할 때만 상호 작용합니다.

저장소에서 로컬로 작업하려면 먼저 컴퓨터에서 복제본을 만들어야 합니다. 저장소를 복제하려면 다음 단계를 따르세요.

  1. GitHub에서 방금 만든 저장소의 Code(코드) 탭을 클릭합니다.
  2. Code(코드) 버튼을 클릭합니다.
  3. 복제 URL을 클립보드에 복사합니다.
  4. 명령 행 애플리케이션을 엽니다. Mac 또는 Linux를 사용하는 경우 터미널을 사용할 수 있습니다. Windows의 경우 Git Bash를 사용하는 것이 좋습니다. Git Bash는 Git과 함께 설치됩니다.
  5. GitHub: git clone에서 저장소 전체 복사본을 가져옵니다. 위에서 복사한 복제 URL로 바꿉니다. 그러면 다음과 같은 코드를 확인할 수 있습니다.

Cloning into 'best-repo-ever'...remote: Counting objects: 3, done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.

  1. 복제가 완료되면 복제 작업에 의해 생성된 새 디렉터리 cd best-repo- ever로 이동합니다.
참고

GitHub Desktop과 같은 데스크톱 애플리케이션을 사용하여 Git 및 GitHub와 상호 작용할 수도 있습니다. 저장소와 더 시각적인 상호 작용을 제공하며 매우 유용합니다.

로컬 환경 설정하기

코드를 변경하려면 몇 가지 기본 구성을 설정해야 합니다. 일반적으로 이러한 구성은 한 번만 설정하면 됩니다. Git을 사용하면 세 가지 수준에서 구성 옵션을 설정할 수 있습니다. 다음 구성 명령 옵션을 확인해보세요.

명령 옵션

설명

git config --system 

시스템 전체를 설정하는 것으로 컴퓨터의 모든 사용자에게 적용됩니다.

git config --global 

사용자 수준의 설정으로 사용자 계정에만 적용됩니다.

git config --local 

저장소 수준의 설정입니다. 해당 구성이 설정된 특정 저장소에만 적용됩니다. Git 구성의의 기본값은 --local입니다.

Git에서 자동으로 설정되는 것이 몇 가지 있습니다. git config --list를 입력하면 세 가지 수준의 환경 설정을 모두 볼 수 있습니다.

Git는 사용자 이름 및 이메일 주소에 대한 환경 설정을 사용하여 사용자가 만든 각 커밋에 대해 고유한 지문을 생성합니다. 

이러한 설정 없이는 커밋을 만들 수 없으므로 명령줄 애플리케이션을 사용하여 다음과 같이 직접 설정합니다.

git config --global user.name "First Last" 

그런 다음 다음을 입력합니다.

git config --global user.email "you@email.com" 

참고

설정이 완료되었다는 확인 메시지는 표시되지 않지만 오류 메시지가 표시되지 않는 한 설정은 완료됩니다.

autocrlf 설정 

다음으로 core.autocrlf를 설정합니다(autocrlf는 자동 캐리지 리턴 라인 피드의 약자). 서로 다른 시스템은 행의 끝 부분과 줄 바꿈을 다르게 처리합니다. 다른 운영 체제에서 생성된 파일을 열 때 이 환경 설정 옵션이 설정되어 있지 않은 경우 Git은 운영 체제가 행 끝 부분을 처리하는 방식에 따라 파일을 변경한 것으로 간주합니다.

Windows 사용자의 경우 다음을 입력합니다.

git config --global core.autocrlf true 

Mac 또는 Linux 사용자의 경우 다음을 입력합니다.

git config --global core.autocrlf input 

GitHub로 파일 추적하기

저장소의 로컬 복사본이 있고 Git을 설정했습니다. 이제 GitHub 워크플로를 사용하여 프로젝트를 변경할 준비가 되었습니다. 먼저 README.md 파일을 간단하게 변경해 보겠습니다. 

1단계: 브랜치 만들기

로컬 브랜치 목록을 보려면 git branch를 입력합니다. 지금은 메인 브랜치 1개만 표시될 것입니다. 

작업을 위한 새 브랜치(myfeaturebranch)를 만들어 보겠습니다.

  1. git branch myfeaturebranch를 입력합니다.
  2. 다음을 입력하여 해당 브랜치로 체크아웃합니다. git checkout myfeaturebranch

그러면 다음과 같은 코드를 확인할 수 있습니다.

kjameson-ltm:best-repo-ever kjameson git branch

* main

kjameson-ltm:best-repo-ever kjameson git branch myfeaturebranch

kjameson-ltm:best-repo-ever kjameson git checkout myfeaturebranch

Switched to branch 'myfeaturebranch'

참고

다른 VCS에서 Checkout에 대해 들어본 적이 있다면 Git에서와는 다른 의미일 수 있습니다. Git에서의 체크아웃은 HEAD라는 중요한 포인터를 이동하는 것이며 이 경우 작업자는 다른 브랜치로 이동하게 됩니다. HEAD는 브랜치의 첫 부분을 가리킵니다. HEAD에 대해서는 마지막 유닛에서 더 많이 다뤄보도록 하겠습니다. 

2단계: README.md 파일을 변경하고 로컬 저장소에 변경 사항 적용하기

이제 새 브랜치를 확인했으니 몇 가지 변경 사항을 적용하고 Git이 실제로 어떻게 동작하는지 확인합니다.

  1. 저장소에서 README.md를 엽니다.
  2. 익숙한 텍스트 편집기를 사용하여 일부 컨텐츠를 추가합니다.
  3. 완료되면 변경 사항을 저장합니다.

파일을 일부 변경했다면 첫 번째 스냅샷을 만들 차례입니다. 명령 행에서 작업할 경우 2단계 커밋이라는 개념을 이해해야 합니다.

로컬에서 작업할 때 Git은 파일과 변경 사항을 트리 3개에 정리하여 내역을 추적합니다. 이 3개의 트리는 작업, 스테이징(인덱스라고도 함) 및 이력을 의미합니다. 파일의 추가, 삭제 및 변경은 작업 트리에서 수행합니다.

Git의 3개 트리인 작업, 스테이징 및 내역을 나타내는 다이어그램.

버전 관리에 변경 사항을 추가하려면 작업의 개별 단위를 나타내는 파일 모음을 만듭니다. 해당 단위는 스테이징 영역에 만듭니다.

취합한 작업 단위에 문제가 없는 경우 스테이징 영역의 모든 것을 스냅샷으로 찍습니다. 이를 커밋이라고 합니다.

git addgit commit 명령을 사용하여 프로세스를 완료합니다. 

  1. 다음을 입력하여 작업 트리의 상태를 확인합니다.

    git status
    kjameson-ltm:best-repo-ever kjameson git status
    On branch myfeaturebranch
    Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
    modified:README.md
    no changes added to commit (use "git add" and/or "git commit -a")
  2. 다음을 입력하여 작업 트리에서 스테이징 영역으로 파일을 이동합니다. git add README.md
  3. git status를 입력하여 작업 상황을 파악합니다.

    kjameson-ltm:best-repo-ever kjameson git status
    On branch myfeaturebranch
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
    modified:README.md 
  4. 다음을 입력하여 첫 번째 스냅샷을 찍습니다. git commit -m "My first commit"
  5. 다음을 입력하여 저장소 상태를 다시 확인합니다.

    git status
    kjameson-ltm:best-repo-ever kjameson git status
    On branch myfeaturebranch
    nothing to commit, working tree clean

3단계: 원격 저장소에 변경 사항 보내기

현재 이 커밋은 로컬에서만 실행됩니다. 원격 저장소를 확인하면 브랜치 또는 방금 변경한 내용이 표시되지 않습니다. 원격에서 변경 사항을 보려면 먼저 변경 사항을 원격 저장소로 푸시해야 합니다. 

로컬로 이 브랜치를 만들었으므로 먼저 로컬 브랜치에 대응하는 원격 브랜치를 만들도록 하겠습니다. 동일한 명령으로 두 브랜치 간의 추적 관계도 설정할 수 있습니다.

  1. git push -u origin myfeaturebranch를 입력합니다.
  2. 메시지가 표시되면 GitHub 사용자 이름과 암호를 입력합니다.

    kjameson-ltm:best-repo-ever kjameson git push -u origin myfeaturebranch
    Username for 'https://github.com':kierenjameson
    Password for 'https://kierenjameson@github.com':
    Counting objects:6, done.
    Delta compression using up to 4 threads.
    Compressing objects:100% (4/4), done.
    Writing objects:100% (6/6), 551 bytes | 0 bytes/s, done.
    Total 6 (delta 1), reused 0 (delta 0)
    remote:Resolving deltas:100% (1/1), done.
    To https://github.com/kierenjameson/best-repo-ever.git
    * [new branch] myfeaturebranch -> myfeaturebranch
    Branch myfeaturebranch set up to track remote branch myfeaturebranch from origin.
참고

새 분기를 처음 푸시할 경우에만 이 긴 명령이 필요합니다. 이후에는 간단하게 git push라고 입력하면 됩니다.

4단계: 풀 요청 만들기

변경 사항을 원격 저장소로 푸시했으므로 이제 GitHub에서 풀 요청을 열어 보겠습니다. 

  1. 웹에서 GitHub 계정으로 이동합니다.
  2. Pull Request(풀 요청) 탭을 클릭합니다.
  3. New Pull Request(새로운 풀 요청)를 클릭합니다. 
  4. Base(베이스) 드롭다운에서 main(메인)을 선택합니다. 
  5. Compare(비교) 드롭다운에서 myfeaturebranch를 선택합니다. 그러면 다음과 같은 코드를 확인할 수 있습니다. 마스터 브랜치와 myfeaturebranch 간의 변경 사항의 차이를 보여주는 GitHub의 스크린샷.
  6. Create Pull Request(풀 요청 만들기)를 클릭합니다. 
  7. Subject(제목) 행과 Comment(코멘트)를 입력합니다.
  8. Create Pull Request(풀 요청 만들기)를 클릭합니다. 

코드 검토를 통한 코드의 품질 관리하기

풀 요청의 기능은 단순히 브랜치를 비교하는 것만이 아닙니다. 수동 또는 자동으로 코드를 검토하고 품질을 보증하는 수단이기도 합니다.

일반 대화 

Conversation(대화) 탭을 사용하여 풀 요청에 대한 일반적인 코멘트를 추가할 수 있습니다.

라인 댓글 

Files Changed(파일 변경됨) 탭(A)에서 행 위로 마우스를 가져가면 파란색 + 아이콘(B)을 볼 수 있습니다. 이 아이콘을 클릭하면 특정 행에 코멘트(C)를 입력할 수 있습니다. 이러한 행 수준의 코멘트는 권장하는 변경 사항을 추가적으로 설명하는 좋은 방법입니다. 대화 보기에도 코멘트가 표시됩니다.

행 코멘트를 추가하는 방법을 보여주는 스크린샷.

검토 

행 코멘트를 작성할 때 Start a Review(검토 시작)(D)를 선택할 수도 있습니다. 리뷰를 작성할 때 다수의 행 코멘트를 요약 메시지로 그룹화할 수 있습니다. 검토를 제출할 경우 코멘트, 승인 또는 변경 요청 여부를 표시할 수 있습니다. GitHub에서 풀 요청 검토와 브런치 보호를 함께 사용하면 풀 요청에 검토가 없는 경우의 통합을 방지할 수 있습니다.

자동화된 테스트 

CI/CD를 프로젝트와 통합한 경우, 풀 요청에 바로 보고된 테스트 상태를 볼 수 있습니다. 이러한 테스트는 손쉽게 맞춤화할 수 있습니다.

배포하기

팀 구성원이 풀 요청을 검토하고 승인하고 필요한 테스트가 통과되면 브랜치를 배포하고 프로덕션 변경 사항을 확인할 수 있습니다. 변경 사항에 문제가 있는 경우, 기존 메인 모듈을 다시 프로덕션에 배포하여 롤백할 수 있습니다.

변경 사항 병합하기

브랜치를 병합할 때 기능 브랜치에서 컨텐츠 및 내역을 가져와서 메인 브랜치의 컨텐츠 및 기록에 추가합니다.

병합은 빠르고 쉽게 Merge pull request(병합 풀 요청)를 클릭하고 병합 코멘트를 추가한 다음 Confirm merge(병합 확인)를 클릭합니다.

팀은 누가 풀 요청을 병합해야 하는지에 대한 규칙을 수립해야 합니다. 규칙에는 다음이 포함될 수 있습니다.

  • 병합으로 인해 발생하는 문제를 해결해야 하므로 풀 요청을 만든 사람이 병합해야 합니다.
  • 프로젝트 팀 내에 한 사람을 배정합니다. 일관성이 보장되지만 작업 속도가 느릴 수 있습니다.
  • 풀 요청을 생성한 사람 이외의 모든 사용자가 병합할 수 있습니다. 이렇게 하면 한 건 이상의 검토가 실시됩니다.

모두 동기화 상태로 유지하기

풀 요청을 병합한 후 GitHub에서 브랜치를 삭제합니다. 삭제하려면 풀 요청 화면의 하단에 있는 Delete branch(브랜치 삭제)를 클릭합니다.

그러나 GitHub에서 병합 및 삭제를 하더라도 저장소 로컬 복사본이 자동으로 업데이트되지는 않습니다. 명령 행 애플리케이션으로 돌아가서 모든 것을 동기화합니다.

먼저 GitHub에서 변경한 내용을 저장소 로컬 복사본으로 가져와야 합니다.

  1. 다음을 입력하여 기본 브랜치로 다시 전환합니다. git checkout main
  2. 다음을 입력하여 GitHub에서 모든 변경 사항을 검색합니다.

    git pull
    kjameson-ltm:best-repo-ever kjameson git checkout main
    Switched to branch 'main'
    Your branch is up-to-date with 'origin/main'.
    kjameson-ltm:best-repo-ever kjameson git pull
    remote:Counting objects:1, done.
    remote:Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects:100% (1/1), done.
    From https://github.com/kierenjameson/best-repo-ever
    f464053..599f35f main -> origin/main
    Updating f464053..599f35f
    Fast-forward
    README.md | 4 +++- 1
    file changed, 3 insertions(+), 1 deletion(-)
참고

git pull은 GitHub에서 모든 변경 사항을 검색한 다음 현재 사용 중인 분기를 업데이트하여 원격에서 변경 사항을 포함하는 복합 명령입니다. 실행 중인 두 개의 별개의 명령은 git fetchgit merge입니다.

계속해서 무료로 학습하세요!
계속 진행하려면 계정을 가입하세요.
얻을 수 있는 이점
  • 커리어 목표에 대한 개인화된 권장 사항 제공받기
  • 실습 과제 및 퀴즈를 통해 스킬 연습
  • 진행 상황을 추적하고 고용주에게 공유
  • 멘토십과 커리어 기회에 연결