-
이 글은 충북대학교 SW중심사업단의 "Git/GitHub 기초/고급 특강" 강의를 바탕으로 작성되었습니다.
-
썸네일 이미지 출처 : www.freecodecamp.org - https://www.freecodecamp.org/news/an-introduction-to-git-for-absolute-beginners-86fa1d32ff71/
2021년 3월 3일 새벽
이번에는 코드가 아닌 Git에 대해 공부한 내용을 새로운 시리즈로 작성해보려고 합니다.✍️
부끄러운 말이지만 저는 지금까지 GitHub를 마치 구글 클라우드처럼 사용하고 있었습니다. 그저 기계적으로 commit과 push를 하다가 가끔 clone 정도 하는 편이었으니까요.
새로운 것을 배우고 만드는 것도 좋지만, 기본기가 빠지지 않는 개발자가 되기 위해 Git에 대해 처음부터 다시 공부하려고 합니다. 대학의 SW 사업단에서 진행하는 Git 특강을 들으며 배운 내용을 요약하고 정리하는 포스팅이 될 것 같습니다.
Git, GitHub?
저는 강의를 듣기 전까지 이 주제로 글을 쓰게 될 것이라고는 생각도 못 했습니다. 지금까지 Git이 GitHub를 줄여서 부르는 말인줄 알았기 때문입니다...🙃
- Git : 기반 기술, 버전 관리 시스템
- GitHub : Git을 기반으로 만든 서비스(플랫폼)
강의에서 들은 내용을 정리하면 다음과 같습니다. Git은 버전 관리 시스템의 하나이고, GitHub는 Git을 활용하여 만든 서비스라는 것입니다. 둘의 차이가 어떤 느낌인지는 알겠으나 설명이 그리 와닿지는 않았는데요, 구글링 결과 조금 더 직관적인 설명을 찾을 수 있었습니다.🔎
- Git : 로컬에서 사용하는 버전 관리 시스템
- GitHub : 클라우드 방식으로 관리되는 버전 관리 시스템
컴퓨터에 저장되어 있는 문서와 클라우드 문서를 비교하면 더 쉽게 이해할 수 있을 것 같습니다. 하드디스크 안의 문서를 편집하고 저장하는 등의 일은 내 컴퓨터 상에서만 일어나는 일이지만 클라우드 문서는 여러 사람이 편집하고 열람할 수 있습니다.
마찬가지로 Git의 버전 관리 시스템을 여러 사람이 작업할 수 있도록 만들어 놓은 것이 GitHub라고 이해하면 될 것 같습니다.
기본기 닦기
커밋 메시지 작성법
GitHub를 처음 배웠을 때만 하더라도 commit을 왜 써야하는지, commit 단위는 어떻게 되는지에 대한 개념이 없었습니다. 그러나 지금은 commit 명령어에 빈 따옴표를 넣어두고 한참을 고민하게 되는 것 같습니다.(물론 아직도 뒤죽박죽이지만😓)
지금까지는 commit 메시지를 작성할 때마다 구글링을 하며 적당한 단어를 찾아 다녔는데요, Git을 다시 배우는 기회에 포스팅으로 정리해볼까 합니다!
Commit 규칙
- 제목과 본문을 빈 행으로 구분한다.
- 제목을 50글자 내로 제한.
- 제목 첫글자는 대문자로 작성.
- 제목 끝에 마침표 넣지 않기.
- 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
- 본문의 각 행은 72글자 내로 제한.
- 어떻게 보다는 무엇과 왜를 설명한다.
"Commit 규칙"이라고 구글에 검색하면 거의 모든 블로그에서 강조하는 규칙 7가지입니다. 사실 Commit 규칙이라고 적어놓았지만 어떻게 보면 당연한 글쓰기 규칙입니다. 편하게 읽히는 글이 될 수 있게끔 형식을 지켜 정리하는 일은 어떤 글쓰기를 하던 중요한 것이니까요.
7번 규칙의 경우도 사실 생각해보면 당연한 것입니다. commit 메시지는 무엇을 만드는(혹은 수정하는) 방법을 알리는 글이 아니라 "어떤 문제 때문에 어떤 부분을 다듬었는지"를 밝히는 글에 가깝습니다. 어차피 "어떻게"에 해당하는 부분은 소스파일에 전부 나와 있습니다.
Commit 유형
| 유형 | 뜻 | 설명 |
|---|---|---|
| Feat | Features | 새로운 기능 추가 |
| Fix | Bug Fix | 버그 수정 |
| Docs | Documentation | 문서 수정 |
| Style | Styles | 코드 스타일 수정(포맷, 세미콜론 누락 등) |
| Refactor | Code Refactoring | 코드 리펙토링 |
| Perf | Performance Improvements | 성능 개선 |
| Test | Tests | 테스트 코드 추가 |
| Build | Builds | 빌드 관련 파일 수정 |
| CI | Continuous Integrations | CI 관련 수정 |
| Chore | Chores | 중요하지 않은 자잘한 수정 |
| Revent | Revents | 이전 commit을 Revent할 때 |
commit 유형 역시 많은 블로그와 기타 자료에 나와있는 표를 간추려 작성해보았습니다. 제법 체계가 잡힌 프로젝트의 commit 내역을 보면 거의 대부분이 "Type: 내용" 형식으로 작성되어 있습니다. 이렇게 commit 제목 앞에 유형을 달아주면,
-
변경 사항들을 쭉 훑어볼 때 어떤 변경이 일어났는지 한눈에 파악하기 쉽습니다.
-
또한 commit 유형을 사용하여 commit을 하는 습관을 들이다보면 저절로 commit 단위와 내용이 잡힐 것 같다는 생각이 듭니다!💡
지금까지는 명령문을 사용하여 commit 하는 게 고작이었다면 앞으로는 commit 규칙과 유형을 사용해서 commit하는 습관을 길러야겠습니다.
README 파일 작성법
README 파일은 소스코드 배포 시 소스코드에 관한 설명을 제공하는 마크다운 문서입니다.📄 특히 GitHub에 코드와 함께 배포하는 경우 레퍼지토리에 들어가면 바로 보이는 문서이기도 합니다.
README 파일에 들어가야 할 내용은 위키에서 가져왔는데요,
- 컴퓨터 구성 안내
- 설치 안내
- 사용법
- 파일 메니페스트 (파일 목록 포함)
- 저작권 및 사용권 정보
- 배포자 및 프로그래머의 연락처 정보
- 알려진 버그
- 장해 추구(트러블슈팅)
- 크레딧
- 체인지로그 (대개 프로그래머용)
- 새 소식 단락 (대개 사용자용)
일반적으로는 GitHub에 올라와 있는 README 파일에 이 모든 내용이 포함되어 있지는 않습니다. README 파일에 주로 작성하는 내용은 다음과 같습니다.
- 프로젝트명
- 설치 방법
- 사용 방법
(오픈소스 프로젝트의 경우)
- 기여 방법
- 라이센스
(프로젝트의 규모가 커진다면)
- 버그
- FAQ 등
내가 올린 코드를 모든 사람들이 일일히 실행해 볼 수는 없으므로 데모 스크린샷이나📷 gif 파일을 첨부하는 것도 좋습니다.
다만, README 파일은 프로젝트와 소스코드에 관한 요약 설명인 만큼 꼭 필요한 내용만 간결히 작성해야 합니다.
Git, Git Bash 최초 설정
Git Bash는 윈도우에서 bash 명령어를 쓸 수 있게 해주는 프로그램입니다. https://gitforwindows.org/ 에서 다운받을 수 있습니다. Git Bash를 처음 사용하시는 분들을 위해, 혹은 나중에 새로 설치할 일이 생겼을 때 볼 수 있도록 Git 및 Bash 최초 설정 방법을 적어보려고 합니다.✍️
최초 설정 공식 문서 : https://han.gl/N5gDc
사용자 정보 설정
우선 자신의 사용자 정보를 설정해주어야 합니다. GitHub 상의 이름, 이메일과 동일하게 설정해주는 것이 좋습니다. 아래의 명령어를 통해 사용자 정보를 설정합니다.
$ git config --global user.name "your_name"
$ git config --global user.email your_email@example.com
이렇게 설정하면 사용자명과 사용자 이메일이 세팅됩니다. 한 번 커밋한 이후에는 변경할 수 없습니다.
윈도우 개행문자 처리 설정
우리가 글을 작성하며 엔터키를 누르면 화면상에서 줄이 바뀝니다. 이 줄바꿈은 실제로는 개행문자의 삽입을 통해 이루어지게 됩니다. 이 설정에서 알아야 할 개행문자는 다음과 같습니다.
| 의미 | 개행문자 | |
|---|---|---|
| CR | Carriage return(커서를 맨 앞으로) | \r |
| LF | Line feed(다음 줄로 변경) | \n |
윈도우는 CR과 LF를 둘 다 사용한 CRLF방식으로, 리눅스는 LF방식으로 개행합니다. 이 개행방식의 차이 때문에 개행문자 처리를 해주지 않고 다른 OS 간 협업을 하게 되면 똑같은 코드라고 하더라도 Git에서 다르게 인식해 충돌이 발생할 수 있습니다.
협업자 간 OS를 통일하지 않아도 Git 명령어를 통해 이러한 문제를 예방할 수 있습니다. Git의 core.autocrlf 변수에는 세 가지 값을 줄 수 있습니다.
-
false일 경우 Git은 아무런 개행문자 처리를 하지 않습니다. -
true일 경우 commit할 때는 CRLF를 LF로 변환하고, 체크아웃 할 때는 LF를 CRLF로 변환합니다. -
마지막으로
input일 경우 LF만 사용하여 개행합니다.
윈도우 사용자의 경우 true로, 리눅스 사용자의 경우 input으로 맞춰놓는 것이 좋습니다. 저는 윈도우 사용자이므로 $ git config --global core.autocrlf true 명령어를 통해 true로 세팅했습니다.
| 변수 | 결과 |
|---|---|
| core.autocrlf = false | 변환 안 함 |
| core.autocrlf = true | CRLF <=> LF |
| core.autocrlf = input | LF만 사용 |
리눅스 커맨드 라인 기본
리눅스 커맨드 라인을 다룰 줄 아는 능력은 개발자들의 기본 소양이라고 말할 정도로 중요하다고 합니다.🧐 평소에 Git Bash를 사용하면서 리눅스 커맨드를 어느정도 알고 있었지만 이번 기회에 다시 복습해봅시다!
| 명령어 | 사용 |
|---|---|
| $ pwd | 현재 디랙토리 표시 |
| $ mkdir 파일명 | 새폴더 만들기 |
| $ cd 경로 | 디랙토리 변경 |
| $ ls | 현재 디랙토리 파일 리스트 |
| $ touch 파일명 | 새파일 생성 |
| $ history | 지금까지 입력한 명령어 목록 |
pwd
$ pwd 명령어는 Present Working Directory의 약자로 말 그대로 현재 작업하고 있는 경로를 보여줍니다.
mkdir
$ mkdir 파일명 명령어는 듣기에 뭔가 거창해보이는데요, 사실 Make Directory의 약자입니다. 마우스 우클릭 후에 나오는 메뉴에서 "새 폴더"를 선택하는 것과 정확히 동일한 기능을 합니다.
단, 파일명은 공백 없이, 영문으로 작성하는 것이 안전합니다. 꼭 공백이 필요하다면 _로 대신해주세요.
cd
$ cd 경로 명령어는 Change Directory의 약자입니다. 현재 작업하고 있는 경로를 바꾸고 싶을 때 사용합니다. 경로를 적는 방법은 절대경로와 상대경로로 나뉩니다.
현재 작업 디렉토리가
/c/Users/choi일 때 동일한 디렉토리에 위치한target이라는 폴더로 이동하는 방법은
- 절대경로:
$ cd /c/Users/choi/target - 상대경로:
$ cd ./target
이렇게 됩니다. 상대경로에서는 ./으로 현재 디렉토리부터 시작한다는 것을 알려줍니다. 현재 디렉토리보다 상위에 있는 디렉토리부터 시작할 수도 있는데요,
현재 작업 디렉토리가
/c/Users/choi일 때/c/Users에 위치한target이라는 폴더로 이동하는 방법은
- 상대경로:
$ cd ../target
다음과 같습니다. 절대경로의 경우 동일한 방법으로 작성하시면 되고, 상대경로의 경우 ../와 같이 점을 하나 더 찍어서 현재 디렉토리의 상위 디렉토리부터 시작한다는 것을 알려줄 수 있습니다.
ls
$ ls 명령어는 List의 약자로써 현재 작업중인 디렉토리의 파일 및 폴더 리스트를 보여줍니다. cd 명령어로 디렉토리를 이동할 때 ls 명령어로 이동할 디렉토리를 미리 탐색할 수 있습니다.
touch
$ touch 파일명 명령어로 새 파일을 만들 수 있습니다. 파일명에 확장자까지 적어주는 것도 잊지 마세요.
❌ $ touch text
✔️ $ touch text.txt
history
$ history 명령어는 말 그대로 현재까지 사용한 명령어 목록을 볼 수 있는 명령어입니다. 긴 명령어를 다시 입력해야 할 때나 방금 전 입력한 명령어가 기억나지 않을 때 유용하게 쓸 수 있습니다.
history 명령어를 사용하면 다음과 같은 화면이 나오게 되는데요, 다시 실행하고 싶은 명령어 번호 앞에 !를 붙여 입력하면 그 명령어를 다시 실행할 수 있습니다.
예를 들어 30번 명령어를 다시 실행하고 싶다면 $ !30이라고 입력하면 됩니다.
사소한 팁
-
명령어 입력 도중 tab 키를 누르면 자동완성됩니다.
-
키보드의 위쪽 화살표를 누르면 바로 전에 실행했던 명령어가 자동완성됩니다.
Vim 에디터 사용법
$ vi 파일명 으로 에디터로 파일을 열 수 있음.
| 키 | 역할 |
|---|---|
| i | 입력모드 변경 |
| esc | 명령모드 돌아가기 |
| :wq | 저장 후 종료 |
| :w | 저장 |
| :q | 종료 |
| :q! | 강제 종료 |
핵심) 명령모드와 입력모드 간 자유로운 전환, 저장 및 종료가 익숙해져야함!
Vim 에디터 사용법
$ vi 파일명 명령어로 Vim 에디터를 사용해 파일을 열고 수정할 수 있습니다. 물론 현재 작업 디렉토리 상에 있는 파일만 열 수 있습니다!
문제는 Vim으로 파일을 열어놓고 파일을 편집하거나 에디터를 종료하는 방법을 모르는 경우가 많은데요, 저도 처음 Vim을 알았을 때 나가는 법을 몰라 강제로 터미널을 종료했던 기억이 납니다.😅
이러한 상황이 생기지 않도록 이번에는 Vim 에디터 기본 사용법을 알아보겠습니다.
| 키 | 역할 |
|---|---|
| i | 입력모드 변경 |
| esc | 명령모드 돌아가기 |
| :wq | 저장 후 종료 |
| :w | 저장 |
| :q | 종료 |
| :q! | 강제 종료 |
Vim 에디터로 파일을 열면 명령모드가 기본 상태입니다. 이 상태에서는 맨 밑의 입력 공간에다가 명령어를 입력할 수 있습니다.
이 상태에서 i 키를 누르면 입력모드로 전환할 수 있는데요, 이 상태에서는 다른 에디터처럼 텍스트를 작성하거나 수정할 수 있습니다.
입력을 마친다음에는 esc 키를 눌러 다시 명령모드로 돌아갈 수 있습니다. 여기서 위의 표에 나와있는 커맨드를 참고해여 원하는 작업을 수행할 수 있습니다.
Vim을 주력 에디터로 쓰지 않더라도 명령모드와 입력모드 간 자유로운 전환, 저장 및 종료 정도는 익숙해져야 합니다.😉
Vim 오류 대처
Vim을 처음 사용해서 익숙하지 않거나 예기치 않은 사고로 인해 오류가 발생할 수 있습니다. 중요한 파일을 다룰 때 오류가 생겨 허둥대기 전에, 미리 오류 상황에 대처하는 법을 연습해봅시다.
만약 Vim으로 파일을 수정하던 중 명령 모드를 통하지 않고 터미널이 강제로 종료되었을 경우,
제가 오류 상황을 만들어 실습하는 과정에서 알게 된 대처법은 다음과 같습니다.
$ vi 파일명으로 파일 열기- 에러창에서
R키를 눌러서 Recover하기 - 명령 모드에서
:wq로 저장하기 - 파일을 다시 열고 에러창에서
D키를 눌러서 .swp 파일 삭제하기
이 과정을 저장하지 못했던 부분이 복구되고 파일도 정상적으로 열리게 됩니다!
이번 강의 내용을 여기까지 정리해보았는데요, 다음 포스팅에서 이어서 적겠습니다.
<참고문서>
👍