GitHub란 무엇일까? GitHub에 대해 알아보기 전에 Git에 대해 먼저 설명하고 넘어가는 것이 좋을 것 같다.

Git은 분산형 버전 관리 시스템(VCS)으로, 소스 코드의 변경 사항을 관리하는 프로그램이다.
- 소스 코드의 변경점을 기록
- 그 변경점을 확인하고 이후 코드 수정을 원활히 하기 위함
- 기록된 변경사항을 롤백하기에도 용이

GitHub는 Git 저장소 호스팅 서비스이다. 개발에 대해 배우면서 당연히 GitHub에 대해 얼핏 들어본 적이 있었고, 중요하다는 것도 인지하고 있었다. 사실 대학교 1학년 동아리 시간에 GitHub 사용 방법을 배운 적이 있다.
그러나 처음 접하는 내가 완전히 이해하기엔 설명이 너무 빠르게 지나갔고, 이후로 실제 사용할 일은 거의 없었어서 잊혀져 갔다. 제대로 써보지도 못했고 익숙해지질 않았으니 어렵게 느껴졌고, 익숙해질만큼 써보겠다는 의지도 없었다.
하지만 시간이 흐르면서 포트폴리오용 GitHub의 중요성을 체감했고, 지금부터라도 예제 코드를 꾸준히 올리기로 결심했다. 그리고 조금만 열심히 해보니 생각보다 별거 없었고, 예상보다도 정말 유용하고 재미있었다.
혹시 예전의 나처럼 GitHub가 어렵게 느껴진다면, 이 글을 보고 한번 따라 해보면 좋겠다.
이제부터 아무것도 없다고 생각하고, VS Code에서 작업하는 내용을 GitHub에 올릴 수 있도록 세팅을 하는 과정을 알아보자.
우선 가장 먼저 PC에 Git을 설치해야 한다.
위 링크에서 운영체제에 맞는걸로 다운을 한 후, exe 파일을 실행해보자.
설치를 진행하다 보면 컴포넌트 옵션이 뜬다.

저 Add a Git Bash Profile to Windows Terminal이 체크가 안되어있는것이 디폴트인데, 체크해주는 것이 좋다고 한다.
이 옵션을 체크하면 윈도우 터미널 앱(파워쉘, CMD, WSL 등을 탭으로 열 수 있는 프로그램)에 Git Bash를 기본 탭 목록에 추가해준다.
Git Bash는 윈도우 환경에서 Git을 리눅스/유닉스 스타일로 쓸 수 있게 해주는 쉘인데, 이 옵션으로 따로 Git Bash를 따로 실행하지 않고도 윈도우 터미널에서 바로 실행할 수 있다. Git 명령어는 CMD 등에서 Git Bash랑 똑같이 쓸 수 있고, 개인적으로 git bash보다 CMD에서 쓰는게 편하다고 생각해서 추천한다.

다음에는 Git의 디폴트 에디터를 선택하라고 하는데, 나는 VS Code를 사용할 것이므로 "Use Visual Studio Code as Git's default editor"를 선택하겠다.

다음으로 이니셜 브랜치 선택이 나온다. 브랜치(Branch)는 말 그대로 나뭇가지처럼, 코드의 작업 흐름(가지)을 나눠 관리하는 기능이다.
처음 Git 저장소를 만들면 처음에 기준 브랜치 하나를 자동으로 만든다. 과거엔 master 브랜치를 기본으로 사용했지만 현재는 main이 표준 브랜치명으로 권장된다고 한다.
이후 계속 넘어가면서 Git 설치를 마무리해주면 된다.
이후 터미널 앱에서 아래 명령을 입력하면 된다.
// 나중에 커밋 작성자 정보로 사용됨
git config --global user.name "(사용자이름)"
git config --global user.email (이메일 주소)
(이름에는 큰따옴표가 있지만 이메일에는 없으니 주의하자.)
사용 전에 이름과 이메일을 정해두는 이유는 뭘까?
Git이 커밋을 기록할 때 누가 변경을 했는지 남기기 위해서이다.
Git을 기록하기 위한 준비를 마쳤으니 이제 GitHub를 사용해보자
GitHub 홈페이지
우선 GitHub에 가서 계정이 없다면 만들고, 로그인한다.

초록색 New 버튼을 눌러 새로운 프로젝트를 위한 리포를 만들 수 있다.

여기에서 리포 이름, 필요하다면 설명, 공개여부 등을 정하고 "Create repository"를 누르자. 우선 나는 설명을 위해 테스트용 리포를 비공개로 만들었다.

여기서 복사 버튼을 누르거나 브라우저에서 리포의 주소를 그냥 복사한다.
파일 탐색기에서 작업 폴더를 만들고 싶은곳으로 가서 우클릭을 한 후 "터미널에서 열기"를 누른다.
git clone (복사한 링크)
이 명령만 치면, 해당 위치에 GitHub 웹에서 만든 리포와 같은 이름의 폴더가 생성된 것을 볼 수 있을것이다.
이제 모든 준비가 끝났다. VS Code를 열어 해당 폴더를 열고, 작업을 해보겠다.

test.py라는 파일을 만들어서 "Hello World!"를 출력하는 코드를 작성하였다. 그러면 Source Control에 Changes라며 변경된 파일이 뜰 것이다. 처음 생성된 파일이라 지금은 U(Untracked)라고 표시되어있다. 한번 추적이 된 파일은 변경될때마다 U 대신 M(Modified)라고 뜰 것이다.
변경사항을 올리는건 세가지 스텝이 필요하다.
변경된 파일들이 Changes에 모두 뜰것이고, 이 중에서 커밋하고 싶은 파일들만 + 버튼을 눌러 staging할 수 있다.

Changes에 있던 test.py가 Staged Changes로 이동한 것을 볼 수 있다.
이제 이 변경사항을 내 로컬 저장소에 기록을 남기는 과정이 필요하다. commit이 그것이다.
commit 버튼 위를 보면 변경사항에 대해 코멘트를 달 수 있도록 메시지 창이 있는 것을 볼 수 있다. 강제적으로 형식이 정해져있진 않지만, 변경 내역을 쉽게 추적하고 자동화 도구 등에 활용할 수 있게 하는 컨벤셔널 커밋(Conventional Commits)이라는 규칙이 있다고 한다.
<type>(<scope>): <subject>
type: 어떤 종류의 변경인지 나타냄
feat(login): add remember-me optionfix(api): correct null pointer issuedocs(readme): update installation guidestyle: format code with prettierrefactor(user-service): simplify validation logictest(auth): add unit tests for loginchore: update dependenciesscope: (선택사항) 변경된 코드 범위(모듈, 파일, 기능명 등)
subject: 간단한 설명
사실 이 컨벤셔널 커밋 작성하는게 아직도 어렵다. 규칙이 있는데 익숙하지가 않다보니 어떤 식으로 작성하는지 아직 감이 별로 없어서 그렇다. 쓰면 쓸수록 나아질거라고 생각한다.
일단 아까 test.py를 작성한것에 대해 코멘트를 작성해보겠다.

코멘트를 작성하고 commit을 누르면 아래 Graph에 아까 user.name으로 설정한 이름과 함께 작성한 코멘트를 확인할 수 있다.
하지만 여기까지의 과정은 단지 로컬 저장소에만 영향이 있는 작업이다. 이제 이 커밋을 GitHub에 올리려면, push를 해줘야한다.

저 push 버튼만 누르면 된다.
이제 GitHub에서 github-test 리포에 가보면 푸시된 커밋을 확인할 수 있다.

이제 소스 코드의 변경사항은 클라우드에 저장되었고, 이제 다른 사람들과 함께 프로젝트를 작업하거나, 개인 작업을 하더라도 다양한 기기에서 git clone을 해서 간편하게 변경사항을 공유할 수 있다. 다른 기기에서 푸시한 커밋을 가져오려면 push 버튼 옆에 있는 pull 버튼을 누르면 된다.
이렇게 GitHub를 사용하기 위한 사전 준비와 커밋 방법을 모두 알아보았다. 처음 세팅할때는 귀찮을 수 있다. 그러나 한번 세팅을 끝마치면 진짜 무지하게 편하게 작업을 할 수 있다. 나도 놀랐다.
GitHub에 관한 글을 작성한 김에 내 GitHub 링크를 공유하겠다.
아직도 개발을 배우는 단계라서 모르는 내용도 많고, 좋은 코드를 작성하는 방법도 모르고, 보기 좋게 커밋하는 방법도 잘 모른다. 작업하는 프로젝트들도 새로이 배우는 내용들을 테스트하기 위한 간단한 예제 프로젝트가 대부분이다.
아직 배워야 할 것이 많고 부족한 점도 많지만, 배운 내용을 프로젝트와 함께 기록하며 꾸준히 성장해 나가고자 한다. 앞으로도 계속 업데이트할 예정이니 지켜봐 주시면 감사하겠다.