👥 협업을 위한 깃허브 기능

• 팀 단위 프로젝트를 위한 깃허브의 Issues와 Projects 활용
• 저장소 협업자 등록 → 이슈 라벨 → 이슈 → 프로젝트 보드 → 이슈 & 프로젝트 보드

---

✅ 이슈 (Issues)

• 프로젝트 작업, 개선 사항, 오류 추적 기능을 제공
• 각 저장소마다 이슈 단위로 작성하고 관리
  라벨 (Labels)
  • 이슈의 성격을 구분짓는 도구
  • Label name에 원하는 라벨 이름, Description에 설명, Color에 색상을 지정
  • 깃허브에서는 이슈의 성격에 맞게 템플릿을 지정할 수 있다. (Issues & PR Templates)

    

    • Title : 이슈의 제목
    • Write : 상세 이슈를 적는 곳
    • Assigness : 이슈를 해결할 사람을 지정
    • Labels : 이슈의 종류
    • Projects : 이슈가 포함될 프로젝트를 선택
    • Milestone : 이슈가 포함될 마일스톤을 선택
    • 깃허브에서는 이슈의 성격에 맞게 템플릿을 지정할 수 있다. (Issues & PR templates)

✅ 프로젝트 (Projects)

• 작업 및 우선순위 관리를 돕는 도구다. 현재 진행중인 프로젝트의 성격에 맞게 관리할 수 있도록 다양한 유형의 프로젝트 보드가 존재한다.
• 책에는 나오지 않았으나, 깃허브에서 새로운 버전의 Projects Beta가 나왔다.
• 여기서는 일단 Projects Classic에 대해서 알아본다.

  

  • Sort tasks : 프로젝트 보드에 이슈 및 풀 리퀘스트를 추가하고 우선순위를 지정할 수 있다.
  • Plan your project : 작업 상태별로 열을 생성하고, 작업의 상태를 관리할 수 있다.
  • Automate your workflow : 이벤트를 설정하여 작업의 상태 관리를 자동으로 수행할 수 있다.
  • Track progress : 프로젝트 보드에서 일어난 모든 일을 추적하고 확인할 수 있다.
  • Share status : 프로젝트 보드의 작업 단위인 ‘카드’는 고유 URL을 가져, 다른 팀원들에게 공유하고 논의하는데 사용된다.
  • Wrap up : 특정 프로젝트 보드의 모든 작업을 마무리한 후 활성 프로젝트 목록에서 제거하여 다음 프로젝트 보드를 생성할 수 있다.

• 프로젝트 보드의 템플릿 (깃허브 제공 기본 템플릿 5가지)
  • None : 빈 템플릿 (작업 상태열 및 설정 정보를 처음부터 직접 구성)
  • Basic kanban : To do, In progress, Done 작업 상태열을 기본적으로 생성
  • Automated kanban : Basic kanban 보드와 동일하게 To do, In progress, Done 작업 상태열이 기본적으로 생성된다. 추가로 카드의 작업 상태가 프로젝트에 포함된 이슈의 상태에 따라 자동으로 변경된다.
  • Automated kanban with reviews : Automated kanban 보드와 동일하지만 작업 상태 변경 요소에 풀 리퀘스트의 상태가 추가로 반영된다.
  • Bug triage : 버그를 분류하기 위한 작업 상태열을 생성한다.

• 이슈와 프로젝트 보드
  • 프로젝트에 이슈 사용하기
    • 이슈 설정의 프로젝트에 해당 프로젝트를 지정해준다.
    • 프로젝트에 Add cards 탭에서 이슈를 각 상태에 드래그해준다.
    • 작업을 완료하면 Done 상태로 변경하고, 이슈를 Close 해준다.

👥 협업을 위한 깃 명령어

• 한 프로젝트에서 여러 명이 협업할 때 필요한 깃 명령어 사용법을 다룬다.
• 각자 맡은 기능을 개발하기 전 필요한 작업 방법과 개발 완료 후, 다른 사람이 만든 기능을 병합하는 방법을 다룬다.
• 여기서 언급되는 ‘main’ 브랜치는 현재 ‘master’ 브랜치로 rename 되었다는 것을 유의

---

✅ 브랜치 (branch)

• 프로젝트 기준 코드인 main 브랜치로부터 독립적인 작업 공간을 만들어주는 기능
• 여러 개발자가 서로 다른 버전의 코드를 만들 때, 서로의 작업에 영향을 주고받지 않기 위해 필요
• 별도의 생성 없이도 main 브랜치는 기준이 되는 브랜치로 자동 생성된다.

  

  • 커밋과 main 브랜치는 커밋3을 바라보고, 커밋 내역에는 1,2,3가 포함된다.
  • 커밋 체크섬은 커밋을 식별하는 고유 데이터이다. (아래 그림에서의 16진수)
  • 커밋과 브랜치의 상태를 도식화하면 아래 그림과 같다.

  

  • main 브랜치는 결국 가장 최근에 생성된 커밋을 바라보게 된다.
  • HEAD 포인터는 현재 작업하는 곳(브랜치)의 최종 커밋을 바라본다.
  • 현재 프로젝트의 HEAD 포인터는 main 브랜치에서 작업 중이며, main 브랜치는 가장 최근 커밋을 바라본다.

브랜치 생성하기

1. 깃허브 원격 저장소에서 생성 후, 로컬로 가져오는 방법 (원격 → 로컬)

   • 깃허브에서 test/remote-branch 를 생성한다

     

     
     

   • git remote update 명령어로 로컬 저장소에 새로운 브랜치를 가져온다.

   • git branch -a 명령어로 현재 브랜치 정보 확인이 가능하다. (*은 현재 작업중인 브랜치)

     

     branch 옵션	설명	실행 예시
     -a	지역 저장소와 원격 저장소의 브랜치 정보를 함께 보여준다.	git branch -a
     -d	브랜치 삭제	git branch -d <브랜치명>
     -l	지역 저장소의 브랜치 정보를 보여준다. 생략 가능하며 git branch 명령어만 실행해도 같은 결과가 출력된다.	git branch -l
     -r	원격 저장소 브랜치 정보를 보여준다.	git branch -r
     -v	지역 저장소 브랜치 정보를 최신 커밋 내역과 함께 보여준다.	git branch -v

   • git checkout 명령어로 원격에서 로컬의 작업 브랜치로 설정할 수 있다.

     checkout 옵션	설명	실행 예시
     	사용할 브랜치를 지정한다.	git checkout
     -b	브랜치를 생성하고 사용할 브랜치로 지정한다.	git checkout -b <브랜치명>
     -t	원격 저장소에서 생성한 브랜치를 지역 저장소에서 사용할 브랜치로 지정한다	git checkout -t <브랜치명>

2. 로컬에서 생성 후, 원격 저장소에 반영하는 방법 (로컬 → 원격)

   • git branch 명령어로 현재 작업 중인 브랜치를 확인한다. (-l 옵션 생략)

   • git checkout master 명령어로 작업 브랜치를 master(main)으로 변경한다.

   • git checkout {새로운 브랜치명} 명령어로 새로운 브랜치를 생성한다.

   • git branch -a 명령어로 브랜치를 확인한다.

     

   • git checkout 명령어로 새로운 브랜치를 작업 브랜치로 변경한다.

     

   • 로컬에서 생성한 새로운 브랜치를 원격 저장소에 반영한다. git push {origin} {branch-name}

     

     

브랜치 삭제하기

• 로컬 저장소의 브랜치를 삭제하는 방법
  git branch -d {branch-name}

• 원격 저장소의 브랜치를 삭제하는 방법
  git push {origin} -d {branch-name}

브랜치 병합하기

• 새로운 작업 브랜치의 커밋 내역을 기준 브랜치에 반영하는 작업이다.
• 기준 브랜치(main, master)로 작업 영역을 변경한 뒤에 병합할 수 있다.
• test/local-branch에서 새로운 커밋을 생성했다고 가정한다.
  
• 해당 커밋을 기준 브랜치에 반영하는 머지 커밋(merge commit)이 브랜치 병합이다.

• 병합의 두 가지 방법

  1. 빨리감기 병합 : fast forward

     • 새로운 브랜치가 생성될 때는 기준 브랜치에서 작업 브랜치가 생성된다. 이후 병합을 시도할 때, 기준 브랜치에 새로운 커밋이 없다면 패스트포워드 병합이 진행된다.
     • 작업 브랜치의 새로운 커밋이 단순히 최신 커밋으로 더해지고, 기준 브랜치가 바라보는 최신 커밋만 변경된다.
     • git merge {branch-name} Fast-forward 방식으로 병합되는 것을 확인할 수 있다.
       
     • 이제 기준 브랜치의 커밋 내역을 보면 새로운 커밋이 추가되고, 기준 브랜치와 작업 브랜치가 같은 커밋을 바라보게 된다.
       

  2. 병합커밋 생성 : merge commit

     • 위의 빨리감기 병합으로 기준 브랜치에 새로운 커밋이 추가된 상태다.
     • 이 상태에서 다른 브랜치로 가 작업을 완료한 후 커밋한다.
     • 다시 기준 브랜치로 와 git merge {branch-name} 명령어를 이용하여 병합한다.
       
       • Fast-forward가 아닌 Auto-merging 이라는 결과가 나온다.
     • 다시 커밋 내역을 살펴 본다.
       
       
       • test/fast-forward 브랜치에서 작업 후 master 브랜치에 병합된 커밋과, test/local-branch 브랜치에서 작업 후 master 브랜치에 병합된 커밋이 하나의 병합 커밋으로 묶여 생성되었다.

✅ 충돌(Conflict) 해결

• 여러 개발자가 프로젝트를 진행하다 보면 병합 시에 충돌이 발생할 수 있다.
• 충돌이란 깃이 자동으로 병합을 완료할 수 없는 상황을 말한다.
• 깃 입장에서 두 브랜치가 같은 파일의 동일 코드를 수정한다면, 어떤 변경 내용을 최종적으로 반영해야 하는 지 알 수 없다.

• 충돌이 발생한 상황 : CONFLICT
  • 
• 충돌이 발생한 파일 : index.html
  • 
• 위 그림처럼 충돌이 발생한 부분을 알려준다. (VS Code)
  • 구분 기호 (===) 윗 구간(HEAD)은 현재 브랜치의 변경 내용이다.
  • 아랫 구간(test/remote-branch)은 병합하려는 브랜치의 변경 내용이다.
  • 내용을 참고하여 최종적으로 반영할 내용만 남기고 충돌을 알려주는 구문을 제거해준다.
    
  • 커밋하고 충돌이 해결되어 병합되었는지 커밋 내역을 확인하면 된다.
  • 충돌이 해결한 후 생성한 커밋(Resolve conflicts)이 master 브랜치가 바라보는 가장 최신 커밋으로 잘 생성된다.

✅ 풀 리퀘스트(Pull Request)

• 병합을 하기 전, 작업 브랜치의 변경 내용을 동료들에게 공유하고 리뷰를 받는 과정
• 함께 작업하는 동료들에게 브랜치 병합 예정인 변경 내역 검토를 요청하는 것

• 풀 리퀘스트 요청하기
  • 실습을 위해 새로운 브랜치를 생성한 후, 작업 브랜치로 변경한다.
  • 작업을 완료하고 커밋, 푸쉬한다.
  • 깃 허브 원격 저장소의 메인 페이지에서 브랜치가 반영되었나 확인한다.
  • [Pull requests] 탭 → [New pull reqeusts] 버튼을 클릭한다.
    
  • (1)은 변경 내역을 병합할 브랜치, (2)는 변경 내역이 있는 작업 브랜치를 선택하고, Create 한다.
    
  • 풀 리퀘스트 내용을 적는 화면으로, (1)제목, (2)설명, (3)변경 내용을 검토할 Reviewers 지정
  • Reviewers로 지정된 사람은 풀 리퀘스트를 검토한 후, 피드백을 주게 된다.
    ⚠️ 굳이 Reviewers를 지정하지 않아도 병합은 가능하다.
    하지만 동료들의 피드백을 받기 위해 풀 리퀘스트를 생성하므로, 지정하여 동료들의 피드백을 받고 병합하도록 하자.

• 풀 리퀘스트 검토하기
  • Reviewers로 지정된 계정이 풀 리퀘스트를 검토할 수 있다.
  • 풀 리퀘스트 상세 페이지의 [File changed] 탭에서 변경 내역을 파일 기준으로 확인하고, [+] 버튼을 클릭하여 각 변경 내역에 대한 코멘트를 작성할 수 있다.
  • [Review changes] 버튼을 클릭 → 팝업 창에서 코멘트 작성 → [Approve] 선택 → [Submit review] 버튼을 클릭하여 해당 PR을 승인할 수 있다.
    
    리뷰어가 따로 지정되지 않아 Approve가 필요하지 않은 상태에서는 바로 merge 가능
  • [Merge pull request] 버튼을 통해 병합 작업을 할 수 있다.
  • 코멘트 등을 확인하고 [Confirm merge] 버튼을 클릭하여 병합 작업을 완료할 수 있다.
  • 병합이 완료되면 PR이 성공적으로 병합되었고, 종료(Closed)된다.

• 로컬 레포지토리에 브랜치 내역 반영하기
  • 로컬의 기준 브랜치(master)를 원격 저장소의 기준 브랜치와 동기화할 필요가 있다.
  • 방법1. git pull
    • git checkout master → git pull {@} {원격 저장소 브랜치}
  • 방법2. git fetch
    • git fetch {@} {branch} 는 변경 내역만 가져오고, 로컬에 병합 작업은 하지 않는다.
    • 즉, git fetch 후에는 직접 git merge를 수행하여 현재 작업 브랜치에 반영해야 한다.

---

새로배운 명령어 정리

명령어	기능	명령 형식
git branch	브랜치 확인	git branch -a
-	브랜치 생성	git branch {생성할 브랜치명}
-	브랜치 제거	git branch -d {삭제할 브랜치명}
git checkout	작업 브랜치 변경	git checkout {변경할 브랜치명}
git merge	브랜치 병합	git merge {병합할 브랜치명}
git pull	원격 저장소 변경 내역 가져오기	git pull {원격 저장소 식별자} {브랜치}
git fetch	원격 저장소 변경 내역 가져오기 (!merge)	git fetch {원격 저장소 식별자} {브랜치}

---

진짜 노션에서 옮기기 너무 힘들다...
다음 파트는 '실전 프로젝트를 위한 깃&깃허브'입니다.
빌드, 배포, 컴파일과 CI/CD 개념에서 나오는 자동화 개념.
깃허브 액션(Actions) 사용법과 커밋 이력 조작 방법을 정리합니다.