Git & Github 사용법 정리

date

Jun 24, 2023

thumbnail

slug

git-github-guide

author

status

Public

📌 목차

초보자를 위한 깃&깃허브

팀을 위한 깃&깃허브

실전 프로젝트를 위한 깃&깃허브

1. 초보자를 위한 깃&깃허브

깃허브의 Packages

자바스크립트의 패키지 관리자인 npm처럼 깃허브를 통해 내가 만든 소스 코드를 패키지로 만들고 관리할 수 있도록 돕는 도구

깃허브의 Projects

해야하는 작업을 정의하고 우선순위를 지정 및 관리하는 도구. 전반적인 로드맵, 릴리스를 위한 체크리스트 관리 등을 수행할 수 있다.

2021년부터 깃허브 인증 방식 변경

패스워드를 통한 계정 인증 방식이 중단되고, 깃허브에서 제공하는 개인용 액세스 토큰으로 인증하도록 변경되었다. (New personal access token)

✅ 깃/깃허브 소스 관리 기본 흐름

로컬에서 원격으로

git init : 해당 프로젝트를 깃 로컬 레포지토리로 지정
git add : 수정한 파일을 스테이징 영역으로 옮김
git commit : 로컬 레포지토리로 저장
git push : 로컬의 변경 내역을 원격 레포지토리로 반영

원격에서 로컬로

git clone : 프로젝트 전체를 내려받기
git pull : 일부 변경 사항만 내려받기

ls -a : 숨김 폴더 및 파일 목록을 보여주는 명령어, 폴더명 앞에 점이 있으면 숨겨진 폴더

ls -l : .git 디렉토리로 가서 사용하여 숨겨진 폴더 및 파일 목록을 확인

git init 취소하기

rm -rf .git : 특정 프로젝트를 깃 로컬 레포지토리로 관리하고 싶지 않거나 처음부터 다시 깃 로컬 레포지토리로 지정하고 싶을 때, git init을 취소하는 방법 (.git 파일을 삭제)

사용자 등록


git config user.name "사용자 이름"
git config user.email "이메일 주소"

git config --global user.name "사용자 이름"
git config --global user.email "이메일 주소"

개인 PC에서는 —global 옵션을 사용하는 것이 편리하다.
한 PC에서 회사 프로젝트와 개인 프로젝트를 동시에 진행한다면, 프로젝트마다 지역 사용자 정보를 등록하여 사용하자.

깃 설정 파일 확인

.git/config

cat .git/config 으로 내용을 확인할 수 있다.
core와 user 섹션으로 구성되어 있다. core는 깃이 파일을 감지하는 방법, 캐싱하는 방법 등 깃의 동작을 제어하는 설정이 저장되어 있고, user 섹션에는 사용자 정보가 저장되어 있다.
core 섹션의 설정 내용들

repositoryformatversion : 현재 깃 저장소의 형식 및 버전 식별을 위한 내부 사용 변수
filemode : 깃 저장소에 포함된 파일 모드의 변경 감지 여부 설정 예로, 파일 시스템이 다른 윈도우와 리눅스에서 동시에 작업하는 깃 저장소 파일이라면 실제 코드를 변경하지 않았는데도 변경된 파일이라고 표시될 수 있다. 파일 모드의 변경을 무시하고 싶다면 'filemode = false'로 설정하자.
bare : 현재 깃 저장소가 코드를 변경하고 작업하는 용도가 아닌 현재까지 작업을 복사하는 용도라면 'bare = true'로 설정하자. 보통 원격 중앙 저장소를 만드는데 사용한다.
logallrefupdates : 깃 명령어를 통해 수행되는 작업 내용을 기록하는 reflog를 활성화한다. git reflog 명령어를 통해 기록된 작업 내역을 확인할 수 있다.
ignorecase : 대소문자 구분 여부 설정. 기본 값은 true ⇒ 대소문자를 구분하지 않음.
precomposeunicode : 맥OS로 깃 저장소를 작업할 때 사용할 수 있는 설정. 맥OS의 유니코드 정규화 방식이 달라 파일명이 한글일 때 깃에서 해당 파일을 인식하지 못하는 문제가 발생할 수 있음. 이 때 'precomposeunicode = true'로 설정하면 해결 가능

원격 저장소 설정

git remote add origin 명령어로 원격 저장소 주소를 깃 로컬 저장소에 등록이 가능
ex. git remote add origin {복사한 원격 저장소 주소}
.git/config 내에 [remote “origin”] 섹션이 추가된다.

.gitignore 파일 설정

로그 파일 혹은 빌드 결과 파일 등은 개발자가 직접 수정할 일이 없고, 프로젝트 버전 관리용으로도 필요가 없다. 따라서 깃으로 관리할 필요가 없으므로, 이런 파일들은 .gitignore 파일을 이용하여 깃이 무시하도록 할 수 있다.
프로젝트 디렉토리의 최상위에 .gitignore 파일을 만든다.
example.


# Logs
logs
*.log
npm-debug.log*

# Dependency directories
node_modules/

.gitignore 파일을 개발 환경에 맞게 자동 생성해주는 gitignore.io와 같은 도구도 유용하다!

깃의 파일 상태

git status 명령어로 현재 파일 상태를 확인할 수 있다.
Untracked 및 Tracked 상태

깃에서 관리하는 파일은 Untracked와 Tracked 상태로 나뉜다.
현재 작업 진행 중인 작업 디렉토리에 새로 생성된 파일은 Untracked 상태가 된다. 주의할 점은 한 번 Tracked 상태가 되었다가 작업 디렉토리에 수정된 파일은 Untracked 상태가 아니다.
git add “파일명 or 폴더명” 으로 파일 상태를 Tracked로 바꿀 수 있다.

Unmodified 및 Modified 상태

한 번 스테이징 영역에 추가된 파일은 수정 여부에 따라 Unmodified 또는 modified 상태로 분류된다.

✅ commit 관련

git log 명령어로 현재 작업하는 브랜치의 커밋 로그를 확인할 수 있다.

git log -p : patch의 약자, 파일 단위에서 변경 내용을 보여준다. (==git log —patch)
git log -{숫자} : 최근 몇 개의 커밋을 보여줄지를 지정한다.
git log --stat : 각 커밋의 통계(어떤 파일이 수정, 각 파일에서 몇 줄 추가/삭제) 정보
git log --pretty : 커밋 로그를 보여주는 형식을 지정할 수 있다.

git log --pretty={option}
{option} : oneline, format:”%h %an %s” 등 본인이 원하는대로 포맷을 정할 수 있다.

git log --pretty=oneline --graph : 그래프 옵션이란, 한 프로젝트를 여러 개발자가 동시에 작업할 때 보통 여러 브랜치를 생성하고 병합하는 작업을 하게 되는데, 이때 기존의 로그 명령어 결과처럼 로그를 나열만하면 흐름 파악이 어렵다. --graph 옵션을 사용하면 가시적으로 커밋 로그의 흐름을 파악할 수 있다. 이를 더 가시적으로 만들기 위해서 --pretty=oneline 옵션을 같이 사용하면 좋다.

깃에는 HEAD라는 특별한 포인터가 존재하는데, 현재 작업하는 브랜치의 최종 커밋을 가리키고 있다. HEAD → main과 같이 존재한다.

커밋 메세지 수정 방법

git commit --amend 명령어를 실행하면 마지막 커밋 에디터 화면을 보여준다. 커밋 메세지를 수정하고 다시 저장하면 마지막 커밋 메세지가 수정된다.
git commit --amend -m "수정 메세지" 한 줄로 간단하게 수정 가능하다.
git commit --amend --no-edit 커밋 메세지 수정 없이, .gitignore의 추가 변경 내용을 기존 커밋에 반영할 수 있다.

커밋 저자 수정하기

git commit --amend --author "username <email>" 저자 정보를 수정할 수 있다.

✅ push 관련

origin 서버로 푸시하기

깃 config에 원격 저장소의 url이 저장되어 있다.
git push {저장소] {브랜치} 인데, 저장소는 특정 원격 저장소를 식별하는 이름이다.
git push origin main : origin이라는 특정 원격 저장소에 지역 저장소의 main 브랜치 커밋을 등록한다는 뜻

새로운 서버로 푸시하기

새로운 이름으로 또 다른 원격 저장소를 등록해서 사용할 수 있다.
지역 저장소에서 여러 원격 저장소를 등록하고 사용할 수 있다는 뜻이다.
git remote add origin2 {url} : origin2 라는 이름을 가진 원격 저장소를 등록한다.
git push origin2 main : origin2 원격 저장소의, main 브랜치에, 커밋이 된다.

✅ 복제 관련

git clone "원격 저장소 주소" "새로운 저장소 이름"

새로운 저장소 이름을 지정하지 않으면 원격 저장소 이름과 같게 로컬에 생성된다. 지금까지 이름을 새로 지정해주지 않았었는데, 이런식으로 지정할 수 있었다는 점

1장을 마무리하며 간단한 remote repository를 생성하여 실습하였습니다.

https://github.com/khakhiD/mastering-git-github

로컬에서 커밋을 하고, 리모트로 푸시하는 과정 간단하게 실습했습니다. (3개의 커밋)

다음장(2장)에서는 협업을 위한 깃-깃허브 사용법을 학습합니다.

2. 팀을 위한 깃&깃허브

👥 협업을 위한 깃허브 기능

팀 단위 프로젝트를 위한 깃허브의 Issues와 Projects 활용

저장소 협업자 등록 → 이슈 라벨 → 이슈 → 프로젝트 보드 → 이슈 & 프로젝트 보드

✅ 이슈 (Issues)

프로젝트 작업, 개선 사항, 오류 추적 기능을 제공

각 저장소마다 이슈 단위로 작성하고 관리

라벨 (Labels)

이슈의 성격을 구분짓는 도구
Label name에 원하는 라벨 이름, Description에 설명, Color에 색상을 지정

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 : 버그를 분류하기 위한 작업 상태열을 생성한다.

템플릿 예시

Automated kanban with reviews의 작업 상태 자동 설정

이슈와 프로젝트 보드

프로젝트에 이슈 사용하기

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

👥 협업을 위한 깃 명령어

한 프로젝트에서 여러 명이 협업할 때 필요한 깃 명령어 사용법을 다룬다.

각자 맡은 기능을 개발하기 전 필요한 작업 방법과 개발 완료 후, 다른 사람이 만든 기능을 병합하는 방법을 다룬다.

여기서 언급되는 ‘main’ 브랜치는 현재 ‘master’ 브랜치로 rename 되었다는 것을 유의

✅ 브랜치 (branch)

프로젝트 기준 코드인 main 브랜치로부터 독립적인 작업 공간을 만들어주는 기능

여러 개발자가 서로 다른 버전의 코드를 만들 때, 서로의 작업에 영향을 주고받지 않기 위해 필요

별도의 생성 없이도 main 브랜치는 기준이 되는 브랜치로 자동 생성된다.

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

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

브랜치 생성하기

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

깃허브에서 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 <브랜치명>`

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

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)이 브랜치 병합이다.

병합의 두 가지 방법

빨리감기 병합 : fast forward

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

이제 기준 브랜치의 커밋 내역을 보면 새로운 커밋이 추가되고, 기준 브랜치와 작업 브랜치가 같은 커밋을 바라보게 된다.

병합커밋 생성 : merge commit

위의 빨리감기 병합으로 기준 브랜치에 새로운 커밋이 추가된 상태다.
이 상태에서 다른 브랜치로 가 작업을 완료한 후 커밋한다.
다시 기준 브랜치로 와 git merge {branch-name} 명령어를 이용하여 병합한다.

Fast-forward가 아닌 Auto-merging 이라는 결과가 나온다.

다시 커밋 내역을 살펴 본다.

test/fast-forward 브랜치에서 작업 후 master 브랜치에 병합된 커밋과, test/local-branch 브랜치에서 작업 후 master 브랜치에 병합된 커밋이 하나의 병합 커밋으로 묶여 생성되었다.

✅ 충돌(Conflict) 해결

여러 개발자가 프로젝트를 진행하다 보면 병합 시에 충돌이 발생할 수 있다.

충돌이란 깃이 자동으로 병합을 완료할 수 없는 상황을 말한다.

깃 입장에서 두 브랜치가 같은 파일의 동일 코드를 수정한다면, 어떤 변경 내용을 최종적으로 반영해야 하는 지 알 수 없다.

위 그림처럼 충돌이 발생한 부분을 알려준다. (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를 수행하여 현재 작업 브랜치에 반영해야 한다.

2장을 마무리하며 해당 장에서 새로 배운 명령어들 정리

명령어	기능	명령 형식
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 {원격 저장소 식별자} {브랜치}`

3. 실전 프로젝트를 위한 깃&깃허브

👥 깃&깃허브 고급기능

새로운 기능을 개발하는 것만이 프로젝트가 아니다. 새로운 기능을 개발하고, 테스트하고, 빌드하고, 원격 저장소에 반영, 배포하는 일련 과정이 완료되어야 작업이 마무리되었다고 할 수 있다.

이러한 일련의 작업 과정을 자동화하는 다양한 도구가 있는데, 깃허브에서는 액션(Actions)이라는 도구를 제공한다.

아래의 페이지를 읽고 액션 사용법을 익히자.

🔍

빌드, 배포, 컴파일과 CI/CD의 개념 (1)

✅ 액션 (Actions)

소프트웨어 개발의 작업 주기를 자동화하는 도구이다. (CircleCI, TravisCI, Jenkins…)

이벤트 기반으로, 특정 이벤트가 발생했을 때 특정 명령 혹은 명령 집합을 자동으로 실행한다.

이벤트란 Pull Requets, Push와 같은 변경을 의미한다.

특정 브랜치에 푸시가 발생했을 때 자동으로 실행될 명령을 지정할 수 있다.

이러한 일련의 과정을 워크플로(workflow)라고 하자.

Node.js 템플릿을 사용한 액션 설정 예시

깃허브 레포지토리의 [Actions]탭에서 [Node.js] 템플릿을 선택하여 설정을 시작한다.

깃허브에서 제공하는 파일을 수정해서 사용해도 되고, 로컬에서 해당 파일을 같은 위치(/.github/workflows/node.js.yml)에 생성한 후 원격 저장소에 반영하여 사용할 수도 있다.
Node.js 워크플로 파일 내부

name : 해당 워크플로의 이름을 명시한다.
on : 워크플로를 실행시킬 이벤트를 명시한다. master 브랜치에 푸시 이벤트가 발생했을 때, master 브랜치에 풀 리퀘스트가 생성되었을 때 해당 워크플로가 동작한다.
jobs : 같은 환경에서 실행할 작업을 정의한다. 하나의 작업 내의 명령은 같은 환경에서 실행된다. 여러 작업을 정의할 수 있고, 각 작업은 개별 환경에서 병렬로 실행된다.
runs-on : 해당 잡이 실행되는 환경을 정의한다. 예제는 ubuntu에서 잡을 실행시킨다.
steps : 특정 잡에 포함된 순차적인 명령(들)의 집합이다.
- uses : 현재 단계에서 사용할 액션을 정의한다. 예제는 actions/checkout@v2 액션을 사용하여 원격 저장소에서 소스 코드를 실행 환경으로 가져온다는 의미이다.
- name : 현재 단계의 이름을 명시할 수 있다. 이름을 지정하면 원격 저장소의 [Actions] 탭 페이지의 로그에서 해당 단계의 name을 확인할 수 있다.
- run : 해당 잡이 실행되는 환경에서 셸 명령어를 실행시킬 수 있다. 예제의 run: npm ci는 잡 실행 환경에서 npm ci를 실행시킨다는 의미이다.

✅ 코드 수정 후 작업 자동화 설정하기

깃허브 액션을 이용하여 코드 수정 후의 필요 작업 자동화를 구성해보자.

프로젝트에 테스트 파일 작성 → master 브랜치에 push하면 → 테스트 파일이 실행되도록!

협업 프로젝트에서는 코드 변경 후, 기준 브랜치에 반영하기 전 충분한 테스트로 코드의 신뢰 가능한 품질을 보장해야 한다는 점이 중요하다.

이 과정에서 Node.js 테스트 프레임워크 mocha를 설치하여 사용한다. (npm install -g mocha)

테스트 파일인 test.spec.js를 최상단 경로에 아래와 같은 코드로 생성


// 'Default Test Set' 이라는 식별자로 테스트 케이스 2개를 작성한 내용
// 깃허브 액션 자동화 실습을 위한 의미 없는 테스트 코드
describe('Default Test Set', () => {
    it('test1 should be passed', () => {
        console.log('test1 passed');
    });

    it('test2 should be passed', () => {
        console.log('test2 passed');
    });
});

mocha를 이용하여 테스트 파일을 실행

$./node_modules/.bin/mocha test.spec.js

npm scripts(package.json)에 테스트 실행 명령어 등록

깃허브 액션 설정 파일 생성

데이터 표현 포맷 (XML, JSON, YAML)

.github/workflows 디렉토리 생성 → ci.yml 파일 생성

master 브랜치에 push 명령을 해준다. 설정한 깃허브 액션이 실행되었을 것이다.

깃허브의 [Actions] 탭을 확인한다.

깃허브 액션을 활용하여 테스트 자동화를 구성했다!

협업 프로젝트의 경우, 기준 브랜치(master)의 코드는 항상 신뢰성있고 높은 품질을 보장해야 한다는 것을 명심하자!

테스트 자동화 외에도 빌드 시 수행되어야 할 다양한 장치를 기준 브랜치의 품질 유지에 깃허브 액션을 활용하여 유지할 수 있다.

✅ 배포 자동화 설정하기

깃허브 액션을 통해 배포 자동화를 설정할 수 있다.

실제로 다양한 클라우드 서비스를 위한 템플릿을 제공하기도 한다.

이 부분은 코드가 반영된 서비스가 운영되는 환경에 따라 계정 생성, 계정 권한 등과 같은 설정 내용이 달라질 수 있다.

대표적인 예로 AWS ECS 템플릿을 사용하여 배포, Azure App Service 템플릿을 사용하여 배포하는 방법들이 있다.

앞서 수행했던 테스트 자동화와 프로세스는 같다.

👥 커밋 이력 조작하기

✅ 다른 브랜치의 커밋을 작업 브랜치에 추가하기

git cherry-pick {추가하려는 커밋의 체크섬}

배포된 기능 중 치명적 결함을 발견하여 사용자가 정상적 서비스 이용을 할 수 없는 상태 → 이미 개발 완료되어 배포 전 테스트 중인 다른 커밋과 상관없이, 결함 수정한 커밋만을 서비스 운영에 사용되는 브랜치에 추가할 수 있다.

새로운 기능을 개발해 커밋을 생성 → 현재 작업 브랜치가 잘못된 것을 발견! → 의도한 브랜치로 작업 브랜치를 변경한 뒤, 잘못된 브랜치에서 생성한 커밋을 현재 작업 브랜치에 추가할 수 있다.

✅ 이전 커밋으로 작업 브랜치의 최종 커밋 변경하기

git reset {이전 커밋의 체크섬}

기능 개발을 완료했는데 갑자기 기획이 변경되어 일부 기능을 제외해야 할 때, 제외할 기능과 관련된 커밋을 취소할 수 있다.

✅ 변경 사항을 되돌리는 커밋 생성하기

git revert {되돌리려는 커밋의 체크섬}

이미 생성된 커밋을 취소하는 또 다른 방법은 git revert를 이용하는 것이다. git reset과의 차이점은 취소하고자 하는 커밋의 변경 사항을 되돌리는 새로운 커밋이 생성된다는 점이다.

✅ 브랜치 커밋 이력 재정렬하기

git rebase {재정렬을 위한 기준 브랜치}

기준 브랜치에서 여러 브랜치를 생성하여 작업한 후, 계속해서 병합하면 커밋 이력을 한눈에 알아보기 어려운 상태가 될 수 있다. 특정 브랜치의 커밋 이력을 기준으로 작업 브랜치의 커밋 이력을 재정렬할 때 깃 명령어 git rebase를 사용할 수 있다.

커밋 이력 관련 명령어 정리

명령어	기능	명령 형식
git cherry-pick	다른 브랜치의 커밋 추가	`git cherry-pick {추가하려는 커밋의 체크섬}`
git reset	이전 커밋으로 최종 커밋 변경	`git reset {이전 커밋 체크섬}`
git revert	변경 사항 되돌리는 커밋 생성	`git revert {되돌리려는 커밋 체크섬}`
git rebase	커밋 이력 재정렬	`git rebase {재정렬을 위한 기준 브랜치}`