협업을 위한 Github 사용법

처음에는 연합동아리에 들어가서 웹 프론트엔드 개발했던 시기에는 Git Bash 이용해서 Github에 commit, push, pull하며 단체 프로젝트도 진행하고 해커톤에도 참가했던 기억이 있다. 하지만 웹 개발 이후 게임개발을 시작하고나서는 Github Desktop 위주로 사용하다보니 링크 복사해서 clone하고, 버튼 눌러서 commit하고 또 버튼 눌러서 push하는 반사적인 행동만 반복하다보니 Github 사용하는 방법에 대해 많이 잊어버렸다.

 

그래서 CS(Computer Science) Study도 시작한 김에 개발자 간 소통과 협업을 위해 Github 제대로 활용하는 방법을 잠깐 알아보려고 한다.

https://github.com/

GitHub · Change is constant. GitHub keeps you ahead.

Git : 분산 버전 관리 시스템, 내 컴퓨터(로컬 환경)에서 파일 변경 이력을 추적 관리 기록하는 프로그램
네트워크 연결 없이 로컬 저장소에서 버전 관리(commit) 가능

GitHub : 원격 저장소 호스팅 서비스, Git으로 관리하는 프로젝트를 인터넷 상에 저장하는 클라우드 서버
Git 기본기능 외에 협업 기능(Issue, Pull Request, Code Review)와 CI/CD(자동 배포) 기능을 제공

GitHub Desktop : Git GUI 클라이언트, CLI(명령어 인터페이스) 기반인 Git 명령어를 그래픽 환경으로 실행할 수 있게 해주는 보조 프로그램
내부적으로 Git 명령어를 대신 실행한다.

---

Repository Name : 저장소 이름(영어, 소문자, 하이픈(-) 권장)

Public : 공개(누구나 URL만 알면 git clone 및 열람이 가능함 : Read 권한 개방)

Private : 나와 초대된 팀원만 볼 수 있다 (소유자 및 권한을 부여받은 Collaborator만 접근 가능, 인증 필요)

Add a README file : 체크하면 README.md 파일을 생성하고 초기화(initial commit)한다. (설명서)
이 옵션을 끄면 Empty Repository 상태로 생성되어 local에서 git init 후 push하는 과정이 필요하다.

Add .gitignore (중요) : Git에 올리면 안되는, Git이 추적하지 말아야 할 파일들(OS 생성 파일, 보안 키, 임시파일, 용량 큰 빌드파일 등) 패턴을 정의할 수 있다.

Choose a license : 법적 허용범위(저작권) 설정.
*위 2개는 나중에 상황에 따라 적절히 알아보면서 선택

---

Repository(저장소) : 프로젝트의 파일들과 변경이력(metadata)이 저장된 .git 디렉토리를 포함하는 공간
[Local Repository : 내 컴퓨터에 존재하는 저장소 / Remote Repository : Github 서버에 존재하는 저장소]
Commit(커밋) : 특정 시점의 파일 상태를 기록한 snapshot
각 커밋은 고유한 해시값을 가지며, 부모 커밋(parent commit)을 가리켜 연결리스트 형태의 이력을 형성한다.
Branch(브랜치) : 특정 커밋을 가리키는 포인터
브랜치를 생성한다 = 현재 커밋을 가리키는 새로운 포인터를 하나 더 만든다 (파일 복사x)
HEAD : 현재 작업중인 브랜치(또는 커밋)을 가리키는 포인터
Main(Master) : 저장소를 생성할 때 기본적으로 만들어지는 기본 브랜치의 이름

Merge (병합) : 두 개의 브랜치(포인터)가 가리키는 변경내역을 하나로 합치는 작업

 

HEAD는 '포인터의 포인터' (2중 포인터) 

commit : 실제 데이터(스냅샷)가 저장된 객체 (고유한 해시값을 가짐) (예 a1b2c3d)

branch : 특정 commit을 가리키는 포인터 (예 main → a1b2c3d)

HEAD : 현재 내가 보고 있는 브랜치를 가리키는 포인터 (HEAD → main)

즉 연결구조는 HEAD → main (브랜치) → a1b2c3d (최신 커밋)

---

*데이터의 흐름

데이터는 Working Directory → Staging Area → Local Repo → Remote Repo 순으로 이동한다.

Working Directory (작업 디렉토리) : 컴퓨터 디스크(HDD/SDD)에 있는 실제 폴더

사용자가 텍스트 에디터로 파일 열고 수정 및 저장하면 이 공간의 파일 내용이 바뀜
→ Git이 아직 이 파일의 변경 사항을 추적하지 않는 상태거나 변경을 인지하였으나 기록할 준비는 안됨

(git status를 입력하면 빨간색으로 표시)
Stage Area (스테이징 영역) : .git 폴더 내부에 존재하는 index 파일, 다음 버전에 포함될 파일들의 리스트를 저장하는 공간

git add 명령어 실행 시 Working Directory의 파일 변경 내용이 이 index 파일에 기록된다. = commit 대기 목록에 등록됨

→ 이곳에 올라간 파일은 git status 시 초록색으로 표시됨
Local Repository (로컬 저장소) : 사용자 컴퓨터 내 .git 폴더에 있는 데이터베이스(Objects)이다. 변경 이력(History)이 영구적으로 저장된다. git commit 명령어를 실행하면, Staging Area에 있던 파일들의 상태를 스냅샷(Snapshot)으로 찍어서 하나의 커밋 객체(commit object)로 만든다. 이 객체는 고유한 해시값(ID)을 가지며 로컬 디스크에 저장된다.

Remote Repository (원격 저장소) : GitHub, GitLab 등 외부 서버에 존재하는 저장소. 협업을 위해 코드를 공유하고 백업하는 중앙 서버

→ git push 명령어를 실행하면 내 컴퓨터(Local Repository)에 새로 생성된 커밋 데이터들이 네트워크를 타고 이 서버로 전송되어 동기화된다.

---

 

Repository(저장소)를 만들고나면, 다음과 같은 명령어들을 확인할 수 있다.

이러한 명령어를 

//create a new repository on the command line
echo "# test" >> README.md
git init
git add README.md 
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/pix-lin/test.git
git push -u origin main

//push an existing repository from the command line
git remote add origin https://github.com/pix-lin/test.git
git branch -M main
git push -u origin main

우선 기능별로 구분하면 다음과 같다. (대괄호는 생략)

//초기화 및 가져오기
git init //현재 디렉토리에 .git 폴더를 생성하여 Git 저장소로 초기화
git clone [URL] //원격 저장소의 모든 데이터(커밋 이력, 브랜치 등)를 로컬로 복제하고, 자동으로 원격 주소를 origin이라는 이름으로 등록

//작업 및 저장(Staging & Committing)
git add [파일] //작업 디렉토리(Working Directory)의 변경 사항을 **스테이징 영역(Staging Area/Index)**에 등록 (커밋 대기 상태)
git commit -m "메시지" //스테이징 영역에 있는 변경 사항들을 묶어 **로컬 저장소(Local Repository)**에 영구적인 스냅샷(CommitObject)으로 저장
git push origin [브랜치명] //로컬 저장소의 커밋 내역을 **원격 저장소(Remote Repository)**로 전송하여 동기화

//동기화 및 병합
git pull origin [브랜치명] //원격 저장소의 변경 사항을 가져와서(Fetch), 현재 내 로컬 브랜치와 자동으로 병합(merge)
git checkout [브랜치명] //HEAD 포인터를 해당 브랜치로 이동시키고 작업 디렉토리의 파일들을 해당 브랜치 상태로 변경
git checkout -b [새 브랜치명] //현재 commit을 가리키는 새 브랜치 포인터를 생성하고 HEAD를 그곳으로 이동

//되돌리기(Reset)
git reset --soft [Target] //HEAD 포인터를 특정 커밋으로 되돌린다. 이후 작업했던 변경사항은 스테이징 영역(Staging Area)에 보존
git reset --hard [Target] //HEAD 포인터를 특정 커밋으로 되돌리고, 스테이징 영역과 작업 디렉토리의 변경 사항을 모두 삭제하여 해당 시점과 완전히 동일하게 만든다

//현재 HEAD 확인
cat .git/HEAD

//출력 결과
ref: refs/heads/main //현재 main 브랜치를 참고하고 있다.
//다른 브랜치 이동 후 (git checkout feature)
ref: refs/heads/feature //파일 내용이 feature로 바뀌었습니다 = HEAD 포인터가 바뀌었다

//현재 commit 상태 확인
git status //빨간색 파일(수정됐지만 Stage Area에 안 담겼음), 초록색 파일(Stage Area에 담겼지만 아직 커밋 안됨)
//"nothing to commit, working tree clean" : 모두 커밋된 상태

 

. //현재 위치
.. //상위 폴더(부모)
/ //구분선(슬래시)
~ //최초 시작 지점
cd //디렉토리로 이동
* //모든 것

 

'HEAD 포인터를 이동한다'의 의미

git checkout 명령어를 입력했을 때 컴퓨터 내부에서 일어나는 일이다.

상황A : 브랜치 변경 (git checkout feature)

HEAD가 가리키는 대상(reference)을 바꾼다.

변경 전 : HEAD가 main을 가리킴 (HEAD → main → 커밋A)

변경 후  : HEAD가 feature을 가리키도록 업데이트됨. (HEAD → feature → 커밋B)

= Git은 HEAD가 가리키는 최종 커밋(커밋B)의 내용을 읽어서, 내 Working Directory(파일 탐색기)의 파일들을 커밋B의 상태로 바꾼다.

상황B : Detached HEAD (git checkout a1b2c3d)

HEAD가 브랜치를 거치지 않고 커밋(Hash)을 직접 가리키는 상태.

구조 : HEAD → a1b2c3d(커밋)

특정 브랜치에 소속되지 않은 상태이다.

이 상태에서 작업을 하고 커밋을 하면, 어떤 브랜치에도 기록되지 않아 나중에 git checkout main으로 돌아오면 작업 내용이 사라질 수 있다. (가비지 컬렉터 대상이 됨)

---

Github가 제공하는 협업 플랫폼 기능

Issue (이슈)

프로젝트의 작업 단위, 버그 리포트, 기능 제안을 추적하는 게시글, 각 issue는 고유번호(index)를 가진다 (#1)

Pull Request (PR)

Source 브랜치의 변경사항을 Target 브랜치(주로 main)에 병합해달라고 요청하는 프로세스. 이 과정에서 코드 리뷰(Diff 확인), CI 테스트, 토론이 이루어진다. "Merge Pull Request" 버튼을 누르면 원격 저장소에서 git merge가 실행된다.

 

Actions (액션)

 

Projects (프로젝트)

 

---

그래서 Issue가 뭔데? (Issue 설명 및 Issue 활용 협업 워크플로우)

https://docs.github.com/en/issues/tracking-your-work-with-issues

Tracking your work with issues - GitHub Docs

Issue는 Github Repository 내에서 작업의 단위를 정의하고 추적하며, 이에 대한 토론을 기록할 수 있는 기능이다. 단순히 글을 쓰는 게시판이 아니라 프로젝트의 상태를 관리하는 객체(Object)이다. Issue에서는 다음과 같은 작업을 수행할 수 있다.

1. 상태 관리(State Tracking)

Open : 해결되지 않은 작업이나 버그

Closed : 해결되어 완료된 작업

2. 작업 명세(Specification)

어떤 기능을 개발할지, 어떤 버그를 수정할지 구체적인 내용을 Markdown 형식으로 기록한다.

3. 토론 (Discussion Thread)

해당 작업에 대해 팀원들이 댓글(Comment)을 통해 코드 작성 전 기술적인 논의를 수행한다.

4. 메타데이터(Metadata)

Assignees : 이 작업을 수행할 담당자를 지정한다.

Labels : 작업의 성격(bug, documentation, feature 등)을 분류한다.

Milestone : 특정 기한이나 목표(예: v0.1.0 출시)까지 완료해야할 이슈들을 그룹화한다.

: Issue는 작업 지시서, 계획서, 문서라고 할 수있다.

 

협업 워크플로우 [*Step 하단 접힌 글 참고]

개발자들은 코드를 짜기 전 Issue부터 생성한다. 이를 이슈 주도 개발(Issue Driven Developement)이라고 한다.

Step1. 작업 정의(Issue 생성)

'New issue'를 클릭한다.

제목에 수행할 작업(예: [DB] 인덱스 개념 정리)를 적고 본문에 세부 내용을 적는다.

→Issue가 생성되며 고유 번호(Index)가 부여된다. (예: #1)

1. Issue: "이거 하자!" (작업 지시서)

• 정체: Markdown으로 작성된 **'할 일 목록(To-Do)'**이자 **'작업 계획서'**입니다.
• 역할: "UI 체력바가 안 줄어드는 버그가 있어" 또는 "상점 기능을 만들자"라고 글로 적어놓는 것입니다.
• 순서/우선순위:
  • 등록한 순서대로 #1, #2 번호가 붙습니다. (주민등록번호처럼 평생 안 바뀝니다.)
  • 우선순위 조절: 번호를 바꿀 순 없지만, Label(라벨) 기능을 써서 High Priority, Low Priority 같은 딱지를 붙여서 관리합니다. 혹은 GitHub Projects(칸반 보드) 기능을 쓰면 드래그 앤 드롭으로 순서를 바꿀 수 있습니다.

Step2. 작업 브랜치 생성

로컬 터미널(Git Bash, VS Code 내장 터미널 등)에서 해당 Issue를 해결하기 위한 브랜치를 생성한다.

보통 브랜치 이름에 이슈 번호를 포함하거나 이슈 내용을 명시한다.

git checkout -b feature/db-index //'-b'는 New Branch의 약자, 브랜치 생성과 동시에 HEAD 포인터 이동
//'-b'가 없으면 이미 존재하는 브랜치로 이동하라는 의미. 해당 브랜치가 없으면 에러 발생
//-b : 만들면서(branch) 이동해라(checkout)
//featue 의미는 '이 브랜치는 '기능 추가' 목적이라고 꼬리표를 달고 폴더로 묶음
//db-index는 실제 작업할 내용의 이름

//위 명령어는 다음과 같은 두 개의 명령어를 한번에 실행한다
git branch feature/db-index //브랜치 생성
git checkout feature/db-index //생성된 브랜치로 HEAD 포인터 이동

//checkout 뒤에 올 수 있는 다른 옵션 [-f (force) / . (파일 경로) / [커밋 해시] (Detached HEAD)]
git checkout -f [브랜치명] //강제 이동, 현재 작업 디렉토리에 commit하지 않은 변경 사항이 있어도, 싹 다 무시하고(덮어쓰고) 이동한다. 변경사항은 복구할 수 없이 삭제된다.
git checkout . //변경사항 취소(restore), 브랜치를 이동하는게 아니라 작업 디렉토리의 변경된 파일들을 가장 최근 커밋(HEAD) 상태로 되돌린다. = 수정사항을 날려버릴 때 사용
git checkout a1b2c3d //특정 과거 시점으로 이동, 브랜치(최신 포인터)가 아니라 과거의 특정 commit 스냅샷을 직접 가리킨다.
//최신 Git(2.23 이후)에서는 기능이 분리됨, checkout도 여전히 작동함
git switch //브랜치 이동
git switch -c //브랜치 생성 후 이동
git restore //파일 복구

Branch Naming 전략 - 접두어(Prefix) 규칙 [협업 표준]

접두어	의미	예시
feature/	새로운 기능 개발	feature/login, feature/inventory
fix/	버그 수정	fix/typo, fix/login-error
docs/	문서 작업	docs/readme, docs/guide
refactor/	기능 변경 없는 코드 구조 개선	refactor/variable-name
hotfix/	긴급하게 수정해야하는 치명적 버그	hotfix/server-down

 

Step3. 개발 및 커밋

코드를 작성하고 commit한다.

커밋 메시지에도 이슈 번호를 포함하는 관례가 있다. (예: 인덱스 정리 문서 작성 (#1))

Step4. PR 생성 및 Issue 연결 (핵심 기능)

작업 완료 후 git push를 하고 GitHub에서 'Pull Request(PR)'를 생성한다.

자동화(Keyword Linking) : PR의 내용(Description)에 Closes #1 또는 Fixes #1이라는 키워드를 작성한다.

→이렇게 적으면 GitHub 시스템이 '이 PR이 Merge(병합)되는 순간, #1번 이슈를 자동으로 Closed 상태로 변경한다.

2. Workflow: UI 개발자가 기능을 추가하는 상황

상황: UI 개발자가 "체력바(Health Bar)"를 만들어야 합니다.

1단계: Issue 등록 (계획)

• GitHub 웹사이트에서 New Issue를 누릅니다.
• 제목: [UI] 플레이어 체력바 구현
• 내용: "붉은색 게이지로 만들고, 피격 시 줄어들어야 함."
• 결과: 이슈 번호 #10번이 생성됨. (이건 그냥 글입니다. 코드는 0줄입니다.)

2단계: 실제 코딩 (로컬 작업)

• 개발자는 VS Code(로컬)로 돌아옵니다.
• 브랜치 생성: #10번 이슈를 보고 작업을 시작하니까, 브랜치 이름을 이렇게 짓습니다.
  • git checkout -b feat/health-bar
• 코딩: C# 스크립트를 짜고 유니티 에디터를 만집니다.
• 업로드: git add, git commit, git push origin feat/health-bar

3단계: PR 생성 및 연결 (결재 서류 제출) ⭐️ 여기가 중요!

• 개발자가 GitHub 웹사이트로 갑니다.
• Compare & pull request 버튼을 누릅니다.
• PR 제목: feat: 체력바 기능 구현 완료
• PR 내용(Description): 여기에 마법의 단어를 적습니다.
  • "Closes #10"
  • (주의: 이슈를 수정하는 게 아닙니다! 새로 만드는 이슈 제목도 아닙니다! PR 작성 화면의 본문에 적는 겁니다.)
• Create pull request 버튼 클릭.

Step5. 코드 리뷰 및 Merge

GitHub 웹사이트의 Pull requests 탭에서 해당 글을 클릭합니다.

팀원이 PR을 승인하고, Merge 버튼을 누르면

1. 코드가 main 브랜치에 합쳐진다.

2. 연결된 #1 Issue가 자동으로 닫힌다. (Closed)

4단계: 리뷰 및 승인 (결재)

• 누가? 팀장(GameManager 담당자)이나 동료가 봅니다.
• 어디서? GitHub 웹사이트의 Pull requests 탭에서 해당 글을 클릭합니다.
• 무엇을? Files changed 탭을 눌러서 UI 개발자가 짠 코드가 빨간색(삭제)/초록색(추가)으로 표시된 것을 확인합니다. ("오, 로직 괜찮네.")
• 승인: 우측 상단 Review changes 버튼 -> Approve 체크 -> Submit review. (이게 승인 도장입니다.)

5단계: 병합 (Merge)

• 승인이 나면, PR 화면 하단에 있던 회색 버튼이 초록색 Merge pull request 버튼으로 활성화됩니다.
• 팀장(또는 본인)이 이 버튼을 클릭합니다.
• 결과 1: feat/health-bar 브랜치의 코드가 main 브랜치로 합쳐집니다.
• 결과 2: 아까 내용에 Closes #10이라고 적었기 때문에, #10번 이슈(계획서)가 자동으로 '완료(Closed)' 상태로 바뀝니다.

 

※ 주의할 점

사실 Github를 통한 작업에 이 정도로 깊게 이해하고 있지도 않고 익숙하지도 않은 지금 나로서는 명령어 하나 입력할 때마다 모든 내용이 주의할 점이긴 하다. (테스트 레포지토리 만들어놓고 이것저것 테스트해봐야할 것 같다)

Q1. 커밋 안 한 상태로 checkout(이동)하면?

충돌이 없으면 : Git이 수정 중이 파일들을 이동할 브랜치로 갖고간다.

= A브랜치에서 하던 작업이 B브랜치에 섞여버려 꼬여버릴 수 있다.

충돌이 있으면 : Git이 에러를 띄우고 이동을 막아버린다.

=> 따라서 브랜치를 옮길 때는 '무조건' 하던 일을 마무리(commit)하거나 임시 저장(stash)하고 깨끗한 상태로 이동한다.

---

Projects 에서는 뭘 할 수 있는데? (Projects 설명 및 Projects 활용 워크플로우)

https://docs.github.com/en/issues/planning-and-tracking-with-projects

Planning and tracking with Projects - GitHub Docs

 

GitHub Projects는 저장소(Repository)에 등록된 Issue(작업)와 Pull Request(PR)을 시각적으로 정렬하고, 진행 상황을 추적/관리하는 '프로젝트 관리 시스템(PMS)'이다.

위에서 살펴본 Issue와 PR(Pull Request)은 리스트 형태로만 나열되어 있어, 현재 전체 프로젝트의 진행도(누가 무엇을 했고, 언제 끝나는지) 파악하기 어렵다. Projects는 이 데이터들을 불러와 다음과 같은 View로 재구성해준다.

 

Projects의 핵심 기능 : 데이터의 시각화 및 상태 관리

1. Board View (보드 뷰 - 칸반)
Issue와 PR을 Status 별로 열(Column)에 배치한다.

구성 : Todo(할 일) / In Progress(진행 중) / Done(완료)

활용 : 사용자가 Issue 카드를 마우스로 드래그하여 Todo에서 In Progress로 옮기면, 실제 Issue의 상태 속성도 함께 변경된다.

2. Table View (테이블 뷰 - 스프레드 시트)

액셀처럼 행(Row)과 열(Column) 형태로 데이터를 나열한다.

많은 양의 Issue를 한눈에 보고, 우선순위(Priority), 담당자, 마감일 등 속성을 일괄적으로 수정하거나 필터링할 때 사용한다.

3. Roadmap View (로드맵 뷰 - 간트 차트)

시간 축(Time-line)을 기준으로 작업의 기간을 시각화한다.

활용 : 프로젝트의 시작일과 목표 종료일을 설정하여 일정 관리를 수행한다.

 

Issue와의 기술적 관계 (Draft vs Converted)

1. Draft Issue (초안) :

Projects 탭에서 Create new issue를 통해 바로 만든 항목이다. 단순한 텍스트 메모 상태이며, 실제 Repository의 Issue로 등록되지 않은 상태이다. 나중에 'Convert to Issue' 버튼을 눌러야 정식 Issue 번호가 부여된다.

2. Repository Issue 연결 :

이미 Repository에 만들어둔 #1, #2 Issue를 검색하여 이 프로젝트 판 위로 불러올 수 있다. 이 경우 Project에서 상태를 변경하면 실제 Issue에도 반영된다.

 

사용자 정의 필드(Custom Fields)

Issue 자체에는 제목, 내용, 라벨 정도의 정보만 있지만, Projects에서는 관리 목적의 메타데이터를 추가할 수 있다.

Priority (우선순위) : P0(긴급) / P1(높음) / P2(보통) 등으로 분류

Size (작업 크기) : S, M, L  또는 시간 단위(Story Points)로 작업량 산정

Iteration(반복 주기) : Sprint 1(1주차), SPrint 2(2주차) 등으로 작업 기간 그룹화

 

워크 플로우 자동화(Automation)

Projects는 GitHub의 이벤트와 연동되어 상태를 자동으로 변경한다.

설정 예시:

개발자가 PR을 생성하고 Issue를 연결(Closes #1)하면, 해당  Issue 카드를 자동으로 Todo에서 In Progress로 이동시켜라

PR이 Merge되어 닫히면(closed), 해당 카드를 Done으로 이동시켜라.

→관리자가 일일이 카드를 옮기지 않아도, 코드 작업(Push/Merge)에 따라 프로젝트 현황판이 실시간으로 동기화된다.

 

일단 직접 해보고 적응해야겠다.

---

이전 내용을 안전하게 가져와서 작업하기

Q. Main에 병합된 내용을 가져와서 안 꼬이게 작업하려면?

이미 Main에 합쳐진 내용은 중요한 기록, History로 남아있기 때문에, 이걸 수정하려고 조작하면 큰일난다. 살을 덧붙이는 방식으로 가야한다.

Step1. 작업하기 전 무조건 내 컴퓨터의 main을 최신 상태로 만든다.

git checkout main //1. 본진으로 이동
git pull origin main //2. 깃허브에 있는 최신 역사(병합된 내용들) 가져오기

Step2. 새 작업 공간(Branch) 만들기

: Main을 직접 건드리지 말고, 최신 Main을 복사한 새 브랜치를 만든다.

git checkout -b feature/upgrade-ui //"UI 개선"이라는 새 평행우주 생성

이제 feature/upgrade-ui 브랜치에는 방금 가져온 최신 내용이 다 들어있다. 여기서 내용을 갈아엎든 지우든 Main에는 전혀 영향을 주지 않는다.

Step3. 작업 후 병합

작업이 끝나면 add → commit → PR 과정을 거쳐서 다시 Main에 합친다.

 

1. 습관적으로 git status 치기

2. 브랜치 옮길 때는 하던거 다 저장 후 commit하고 깨끗한 상태에서 이동하기

---

이렇게 정리했어도, 한번에 알거나 외우기는 절대 쉽지 않고 오히려 여기 정리한 내용보다 Github 문서에 나와있는 정보가 훨씬 정확하고 방대하다. 따라서 기초적으로는 정리한 내용을 바탕으로 익숙해지고 추가적으로 필요한 부분들은 공식문서를 참고해야할 것 같다.

 

나중에 GitHub 협업 및 활용 능력이 정말 유연해지면, 빠른 시일 내로 개발 프로젝트에도 적용하여 YAML파일 코드를 통해 GitHub Actions도 적용해봐야겠다. CI/CD(코드 빌드, 테스트, 배포) 같은 작업 자동화?가 가능하지 않을까.