초보자를 위한 깃허브 사용법 및 커밋 관리 방법

개발자가 되면 깃(Git)을 많이 사용하게 됩니다. 깃은 버전 관리를 도와주는 툴인데요, 업데이트된 내용들을 기록하고 언제든지 과거 버전으로 되돌릴 수 있도록 하는 기능을 제공합니다. 버전 관리를 사용하게 되면 개발을 하다 코드가 꼬이게 되는 상황이 생기더라도 정상 작동하던 과거 버전으로 돌아갈 수 있죠. 또한 팀원들과 함께 프로젝트를 진행할 때도 큰 도움이 됩니다. 각자 맡은 파트를 개인 컴퓨터에서 작업하고, 추후에 하나로 합치는 것이 용이하기 때문이죠. 만약 깃을 사용하지 않는다면 코드를 일일이 대조해 가며 업데이트해야 하는데, 이러면 시간도 시간이지만 실수가 생길 확률이 올라갑니다. 깃은 이런 점들을 손쉽게 관리해 주기 때문에 개발자에게 떼려야 뗄 수가 없는 존재가 되었습니다.

---

Homebrew를 사용한 맥북 플러터 설치하기

GitHub: Let’s build from here

---

깃허브(Github) 레포지토리 생성하기

깃은 개인 컴퓨터(로컬 저장소)와 서버(원격 저장소)로 분리되어 버전을 관리합니다. 개발자 개인이 로컬 저장소에서 개발과 버전 관리를 진행한 후 원격 저장소에 업데이트하여 프로젝트에 참여하는 모든 인원들이 동일한 버전을 가져올 수 있도록 하는 거죠. 깃허브(Github)는 원격 저장소를 제공해 주는 서비스입니다. 깃허브를 통해서 프로젝트를 손쉽게 만들고, 관리, 공유할 수 있기 때문에 많은 개발자들이 사용하고 있습니다. 

우선은 깃허브에서 레포지토리를 생성해 주도록 하겠습니다. 레포지토리 이름은 프로젝트명을 그대로 입력하거나 알기 쉽도록 정해주면 됩니다. 프로젝트 설명이나 공개 설정은 상황에 맞게 설정해 주면 되고요. 다음으로는 README와 gitignore인데요, 저는 개인적으로 항상 포함시키는 편입니다. README 파일은 레포지토리에 대한 상세한 설명을 적는 파일이지만, 저는 커밋 컨벤션 가이드를 작성해서 사용합니다. 이렇게 하면 매번 구글링을 하지 않아도 금방 찾을 수 있어 편리하더라고요. 물론 개발이 끝난 후에는 원래의 용도대로 상세 설명을 적어두어야겠지요. gitignore 파일은 깃 버전 관리에 포함시키지 않을 파일 또는 폴더를 지정하는 파일입니다. 빌드 파일이나 환경 변수, 패키지 등 버전 관리에 포함되지 않아도 되는 파일들은 가지고 있을 필요가 없겠죠? 마지막으로 상황에 맞게 라이선스도 선택하셨다면 Create repository 버튼을 클릭해서 레포지토리를 생성할 수 있습니다.

로컬 저장소에 깃 내려받기

그럼 위 사진처럼 레포지토리가 생성된 것을 확인할 수 있습니다. 참고로 README 파일을 수정하면 이 페이지에 반영이 됩니다. 지금은 막 생성됐기 때문에 제목만 나오고 있는 상태네요. 아무튼, 우측 상단에 있는 Code 버튼을 클릭하면 레포지토리 주소가 나오는데요, 이 주소를 복사해 주겠습니다.

이제 컴퓨터에서 터미널을 실행시킨 후 cd 명령어를 사용해서 프로젝트를 저장할 위치로 이동해 줍시다. 그다음 방금 복사한 주소와 함께 아래 명령어를 입력하면 레포지토리가 다운로드됩니다. 이제 깃허브를 통해 프로젝트를 관리할 준비가 끝났습니다.

git clone [복사한 레포지토리 주소]

README, gitignore 수정하기

깃 클론을 마친 후 저는 가장 먼저 README와 gitignore 파일을 수정합니다. 아래 코드는 제가 사용하는 README 템플릿 파일입니다. 이렇게 README 파일에 저장해 두면 매번 찾아보지 않아도 프로젝트 내에서 바로 확인이 가능해서 간편하게 사용하고 있습니다. VS Code를 사용하신다면 cmd + shift + v 키를 눌러서 위 사진과 같은 프리뷰 창을 열어 더욱 편하게 볼 수도 있습니다. README 파일은 마크다운 형식으로 되어 있다는 점을 참고해서 개인 스타일에 맞게 조금씩 수정하셔도 좋을 것 같네요.

## 커밋 메시지 컨벤션

### 1. 커밋 유형 지정

커밋 유형은 영어로 작성한 후, `:` 로 제목과 분리
| 커밋 유형 | 의미 |
| ---------------- | ------------------------------------------------------------ |
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| mod | 코드 구조 개선 & 크지 않은 수정 |
| style | 코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우 |
| design | CSS 등 사용자 UI 디자인 변경 |
| comment | 필요한 주석 추가 및 변경 |
| docs | 문서 수정 |
| refactor | 코드 리팩토링 |
| chore | 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore |
| test | 테스트 코드, 리팩토링 테스트 코드 추가 |
| rename | 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우 |
| remove | 파일을 삭제하는 작업만 수행한 경우 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야 하는 경우 |

### 2. 본문 작성

커밋 유형 이후 제목과 본문은 한글로 작성하여 내용이 잘 전달될 수 있도록 할 것  
본문에는 변경한 내용과 이유 설명 (어떻게보다는 무엇 & 왜를 설명)

### 3. 마침표는 사용하지 않음

### 4. 제목은 50자 이내로 작성

### 5. 한 커밋에는 한 가지 문제만

추적 가능하게 유지해주기  
너무 많은 문제를 한 커밋에 담으면 추적하기 어려움

### 6. 여러가지 항목이 있다면 글머리 기호를 통해 가독성 높이기

```
- 변경 내용 1
- 변경 내용 2
- 변경 내용 3
```

### 7. 자신의 코드가 직관적으로 바로 파악할 수 있다고 생각하지 않기

### 바람직한 커밋

```
feat: 프로필에 모국어 설정 기능 추가
- lang 클릭 시 언어 목록 모달 띄워줌

design: 시간표 레이아웃 수정
- 요일 별 행 너비가 안 맞는 문제 해결
```

플러터 공식 gitignore

gitignore은 깃허브에서 많은 언어들에 대해 기본적으로 제공해주기는 하지만, 완벽하지는 않은 것 같더라고요. 그래서 저는 개발 스택 레포지토리에 공식적으로 배포돼 있는 gitignore을 검색해서 받아옵니다. 구글에 사용 중인 스택 gitignore(flutter gitignore 등)을 검색하면 웬만해서는 찾을 수 있습니다. 추가적으로 맥에서 사용되는 메타 파일인 .DS_Store도 gitignore에 추가해주고 있습니다. 이제 정말 초기 설정이 완료되었습니다. 다음 단계로 넘어가 보도록 하죠.

깃 커밋 유형

본격적인 깃 사용법에 앞서 깃 커밋 유형에 대해서 한 번 짚고 넘어가도록 하겠습니다. 프로젝트를 진행하다 보면 새로운 기능 개발, 디자인 수정, 코드 리팩토링, 주석 추가 등 다양한 작업을 하게 됩니다. 커밋 유형은 어떤 작업을 했는지 한눈에 알아볼 수 있도록 사전에 정의해 둔 카테고리입니다. 회사나 개인마다 조금씩의 차이는 있을 수 있지만, feat, fix, mod, style, design, comment, docs, refactor, chore, test, rename, remove, !BREAKING CHANGE, !HOTFIX 이렇게 14개의 커밋 유형을 많이 사용합니다. 저는 그중에서도 feat, fix, mod, design, chore, !HOTFIX 이렇게 6개를 가장 많이 사용합니다. 각 커밋 유형이 어떤 의미로 사용되는지는 앞서 제공해 드린 README 파일을 참조하면 좋을 것 같습니다.

커밋 유형을 잘 사용하면 한눈에 작업 내용 파악이 가능하다

커밋 유형은 커밋 제목과 함께 사용합니다. 커밋 유형을 입력한 후 세미콜론 :으로 분리해서 조금 더 상세한 제목을 달아주는 거죠. 아래와 같은 형식으로 작성하게 되면 커밋 로그를 확인할 때 한눈에 내용을 파악할 수 있습니다. 여러 사람들이 함께 작업하게 되면 더욱 정리가 잘 되겠죠?

fix: 홈 화면에서 버튼이 눌러지지 않던 오류 해결

깃 사용 방법

이제 본격적으로 깃을 사용하는 방법에 대해서 알아보도록 하겠습니다. 깃 사용은 크게 7가지 단계로 진행됩니다.

1. 메인 브랜치(원격 저장소)에서 개인 브랜치로 분기 생성
2. 코드 수정 등 작업 진행
3. 스테이징 영역에 추가
4. 로컬 저장소에 커밋
5. 원격 저장소로 푸시
6. 메인 브랜치에 병합
7. 작업한 브랜치 삭제 및 메인 브랜치 내려받기

첫 단계에서는 메인 브랜치에서 새로운 분기점을 생성해야 합니다. 메인 브랜치는 일종의 원본 파일이라고 보시면 됩니다. 그렇기 때문에 메인 브랜치에서 분기를 생성한다는 것은 복사본을 만들어서 작업하는 것이라 할 수 있죠. 아래 코드를 입력하면 새로운 브랜치가 생겨나게 됩니다. 이때 브랜치명은 주로 개발자@작업명 형식으로 많이 생성합니다. 그래야 누가 어떤 작업을 하기 위해서 생성한 브랜치인지 알 수 있기 때문이죠.

git checkout -b [브랜치명]

checkout은 사실 다른 브랜치 이동하는 명령어입니다. 방금은 -b 옵션을 붙여서 브랜치를 생성하는 명령어가 됐지만, 옵션 없이 브랜치명만 입력한다면 해당 브랜치로 분기를 이동하게 되죠. 예를 들어 메인 브랜치로 이동하고 싶다면 아래 명령어를 입력하면 됩니다.

git checkout main

개인 작업 브랜치를 생성했다면 이제 작업을 진행하시면 됩니다. 코드를 마음껏 수정하셨다면 작업한 내용을 메인 브랜치로 합쳐야겠죠. 그러기 위해서는 먼저 스테이징 영역에 저장하는 과정을 거쳐야 합니다. 스테이징 영역은 커밋에 포함될 파일들을 임시로 저장하는 영역이라 생각하면 편리합니다. 예를 들어 A 파일과 B 파일을 수정했지만, A 파일의 수정 내용만 커밋하고 싶다면 A 파일만 스테이징 영역에 추가한 후 커밋을 진행하면 됩니다. 스테이징 영역에 파일을 추가하기 위해서는 아래 명령어를 입력하면 됩니다. 

git add [파일명 혹은 폴더명]

보통의 경우에는 수정한 모든 파일들을 커밋하기 때문에 아래 명령어로 모든 파일을 추가하면 됩니다.

git add .

네 번째 단계는 로컬 저장소에 저장, 즉 커밋을 진행하는 단계입니다. 앞서 스테이징 영역에 파일을 추가했다면 아래 명령어를 통해서 커밋을 진행할 수 있습니다. 커밋을 할 때는 앞서 알려드린 커밋 유형을 활용해서 커밋 메시지를 작성하시면 좋습니다. 

git commit -m '[커밋 메시지]'

만약 작업 내용이 많다면 부연 설명을 추가로 달아주면 나중에 이 커밋이 어떤 작업을 한 커밋인지 알아보기가 편리합니다. 작은따옴표를 닫지 않은 상태에서 엔터를 치면 다음 줄로 넘어가는데요, 여기에 부연 설명을 달아주고 따옴표를 닫으면 됩니다. 아래 예시를 보시면 조금 더 이해가 잘 되실 겁니다.

git commit -m 'fix: 홈 화면에서 버튼이 눌러지지 않던 오류 해결
- 버튼 클릭시 클릭 애니메이션 실행
- 버튼 클릭시 사용자 페이지로 이동'

커밋이 완료되었다면 원격 저장소에 푸시하는 작업을 진행해야 합니다. 그래야 다른 팀원들이 수정한 내용을 받아 볼 수 있기 때문이죠. 푸시하는 방법은 간단합니다. 아래 명령어를 입력하면 됩니다. 

git push

브랜치를 생성하고 처음 푸시를 하면 위 사진처럼 upstream branch 설정이 되어있지 않다고 오류가 납니다. 그럴 때는 오류와 함께 제공되는 명령어를 복사해서 실행하면 문제가 해결됩니다. 이 오류가 생기지 않게 설정하는 방법도 있기는 하지만 저는 번거롭더라도 그냥 복사해서 실행하는 편입니다. 

git push --set-upstream origin toroto@init

푸시까지 완료했다면 깃허브에서 메인 브랜치로 머지(merge)하는 작업만 남았습니다. 깃허브는 pull request라는 기능을 통해서 머지하기 전 팀원들이 다 함께 코드를 리뷰하는 과정을 가지도록 도와줍니다. 이 과정을 통해서 조금 더 안전하게 원본 파일을 유지할 수 있는 거죠. 

방금 커밋을 푸시했기 때문에 깃허브 레포지토리에 들어가 보면 pull request를 생성하라는 메시지가 있습니다. Compare & pull request 버튼을 클릭해 주겠습니다.

팀원들이 변경 사항을 파악하기 쉽게 작업 내용을 적어준 후 Create pull request 버튼을 클릭하면 pull request가 열리게 됩니다. 작업 내용을 적을 때는 사진을 첨부하거나 어떤 파일을 어떻게 수정했는지 상세하게 작성하는 것이 좋습니다.

Pull request가 열리면 위 사진과 같이 팀원들이 변경 내용을 확인할 수 있습니다. 깃허브를 조금 더 활용한다면 n명의 팀원이 확인하는 등의 조건을 더 추가할 수도 있지만, 이건 다른 포스트에서 다뤄보도록 하겠습니다. 확인을 마쳤다면 Merge pull request 버튼을 클릭해서 머지를 진행해 줍니다.

커멧 메시지를 한 번 더 확인하고 Confirm merge 버튼을 클릭하면 머지가 완료됩니다. 브랜치가 머지되면 더 이상 pull request를 열 수 없기 때문에 저는 머지를 한 후 브랜치를 삭제하는 편입니다. 하지만 브랜치를 남겨두고 싶다면 굳이 삭제하지 않아도 문제는 없습니다.

레포지토리를 확인해 보면 커밋이 정상적으로 메인 브랜치에 머지된 것을 확인할 수 있습니다. 이제 다시 프로젝트로 돌아가서 방금 머지한 내용을 받아오겠습니다. 우선 메인 브랜치로 이동해 주도록 하겠습니다.

git checkout main

그다음 pull 명령어를 사용하면 최신 내역을 받아올 수 있습니다. 참고로 새로운 브랜치를 생성하기 전에는 항상 최신 내역을 받아온 후 진행하는 것을 추천드립니다.

git pull

마지막으로 이전에 작업한 브랜치를 삭제하면 깃을 사용한 버전 관리의 한 사이클이 완료됩니다. 이제 새로운 브랜치를 생성해서 다음 작업을 이어나가면 됩니다.

git branch -d [브랜치명]

깃 사용 팁

마지막으로 몇 가지 팁을 알려드리도록 하겠습니다. 

1. 하나의 커밋에는 하나의 작업만 포함하기. 한 커밋에 너무 많은 작업이 포함되면 작업 내용 추적과 버전 관리가 어려워집니다. 커밋을 많이 할수록 버전 관리가 용이해집니다.
2. 푸시는 메인 작업이 끝난 시점에만 하기. 브랜치를 생성할 때 작업명을 명시하라고 했었는데요, 이 메인 작업이 끝나는 시점에 한 번만 푸시를 하는 것이 좋습니다. 그 과정에서 생기는 여러 소작업들은 1번에서도 얘기했듯이 커밋을 여러 번 하면서 관리하시는 게 좋습니다. 
3. Pull request는 최대한 상세하기 작성하기. Pull request를 열면 팀원들이 내가 작업한 내용을 확인하게 됩니다. 팀원들도 물론 코딩을 잘하겠지만, 자신이 작업한 것이 아니기 때문에 어떤 문맥에서 코드를 수정했는지 파악하려면 시간이 걸립니다. 그렇기 때문에 상세하게 작업 내용을 적어두면 팀원들이 조금 더 편하고 빠르게 코드를 리뷰할 수 있습니다. 

깃과 깃허브에 익숙해질수록 이걸 처음 생각한 사람은 어떤 사람일지 놀랍습니다. 깃허브가 없었다면 팀 프로젝트를 진행하기가 얼마나 어려웠을지.. 상상만 해도 끔찍하네요. 깃이 처음에는 조금 생소하고 어렵지만, 알게 될수록 사용하기도 편리하고 특히 버전 관리의 도움을 많이 받게 되는 것 같습니다. 언제든지 되돌릴 수 있으니 오류가 생길 걱정 없이 개발에만 집중할 수 있어 좋은 것 같네요.

---