Git / Github - Git ver.01

신재윤·2021년 7월 30일

Basic Git/Github

Git / Github

목록 보기

1/1

Git, Github ver.01

Git의 기초를 정리한 게시글입니다.
최대한 구체적으로 작성해서 내용이 방대합니다.
https://youtu.be/Z9dvM7qgN9s 강의를 토대로 내용을 정리했습니다.
https://www.youtube.com/watch?v=8JJ101D3knE 강의를 토대로 내용을 정리했습니다.
https://blog.naver.com/jdusans/222043705693 도움을 많이 받은 게시글입니다.
branch, stash 등 심화내용(ver.02)은 유료 강의이므로 비공개 게시글로 작성했습니다.

1.1 What is Git / Github ?

Git은 Version을 편리하게 관리하는 도구

Git은 버전을 편리하게 관리할 수 있도록 도와주는 도구이다. 우리가 작업하고 있는 파일들을 원하는 순간으로 다시 돌아갈 수 있게 해주는 마치 '타임머신'과 같은 역할을 한다. 명령어를 기반으로 한 CLI(Command-Line Interface) 프로그램이다.

CLI 환경에서 기본적인 명령어 / git 기본 명령어
https://velog.io/@grinding_hannah/Git-Git-%EC%82%AC%EC%9A%A9%EB%B2%95-%EB%B0%8F-%ED%84%B0%EB%AF%B8%EB%84%90-%EB%AA%85%EB%A0%B9%EC%96%B4-%EC%A0%95%EB%A6%AC

CLI 환경에서 vi 에디터 편집을 위한 게시글 https://jhnyang.tistory.com/54

컴퓨터에 존재하는 대부분의 파일들은 버전 관리 시스템을 이용해서 관리할 수 있다. 이것을 VCS (Version Control System)라고 한다. VCS는 크게 두 가지로 나누어진다.

CVS (Centralized Version Control)
DVCS (Distributed Version Control System)

버전 관리 시스템이 없었던 시절에는 폴더별로 이름을 version 1.0.0 , version 1.0.1과 같이 수동으로 일일이 관리하는 경우가 허다했다.

이것을 개선하기 위하여 나온 것이 바로 CVS이다. CVS는 서버에 히스토리를 관리해서 각각의 개발자들이 원하는 내용을 서버에 업데이트 하면 즉각적으로 동기화가 이루어지는 시스템이다. 예시로는 CVS, SUBVERSION, PERFORCE가 있다.

그러나, 서버에 문제가 생기거나 다운이 된다면 일을 진행하지 못하게 되고 오프라인에서 인터넷이 없는 경우 사용하지 못하는 치명적인 단점이 있다.

이 문제점을 개선한 것이 바로 DVCS이다. 서버에만 히스토리의 정보가 있는 것이 아니라,
모든 개발자들이 동일한 히스토리 정보를 가지고 있는 것을 의미한다. 서버에 문제가 생기거나 다운이 되어도 각각의 개발자들이 동일한 히스토리를 가지고 있기 때문에 서로의 정보를 이용하여 서버를 보관하고 계속해서 일을 진행할 수 있다. 인터넷이 없어도 오프라인에서 일을 진행할 수 있는 큰 장점이 있다.

DVCS는 회사에서만 이용할 수 있는 프라이빗 서버를 이용하는 경우도 있고 Github나 Bitbucket과 같은 클라우드를 이용하는 경우도 있다.

Git은 delta-based가 아니라 프로젝트의 전체적인 내용을 스냅샷 해서 가지고 있다. 프로젝트 전체적인 내용을 가지고 있어서 version들 사이, branch들 사이를 오류 없이 굉장히 빠르게 이동할 수 있다. 또, 변경 되지 않는 파일들은 예전의 파일들의 링크를 가리키고 있기 때문에 각각의 스냅샷은 무겁지가 않고 굉장히 가볍다.

1.2 Install, Settings

Install WSL2 ( Windows Subsystem for Linux 2 ) #for terminal

Linux, Mac 환경에서는 터미널을 이용하면 되지만, 나는 Windows 환경이기 때문에 따로 터미널을 설치할 필요가 있었다. Git Bash를 이용해도 되지만, 윈도우 환경에서 리눅스를 사용할 수 있게 도와주는 WSL2를 설치해서 사용하기로 했다.

WSL2 설치 및 사용 방법 https://www.44bits.io/ko/post/wsl2-install-and-basic-usage
터미널 커스터마이징 하기 https://nomadcoders.co/windows-setup-for-developers/lobby

WSL2를 설치하고 나서, 기본 환경을 Windows PowerShell이 아닌 Ubuntu로 변경하기 위하여 터미널 환경에서 Ctrl + ,를 눌러서 json 파일을 열고 설정을 해줬다. "defaultProfile"에서 PowerShell의 고유값이 기본값으로 설정되어있는데 이것을 Ubuntu의 고유값으로 바꿔주면 된다.

이전에 나는 우분투를 사용해본적이 있어서 시작 디렉토리가 어색했기에 Ubuntu로 설정값을 바꿨다. 이 명령어를 파일에 추가하면 된다.

"startingDirectory": "\\\\wsl$\\Ubuntu-20.04\\home\\jae_yun"

WSL2를 활용한 Linux 환경에서는 루트 디렉토리의 mnt를 이용해서 윈도우 세계로 들어갈 수 있다.

윈도우 파일 탐색기에서 폴더를 가시적으로 보고싶다면 폴더 검색창에 \\wsl$ 를 입력하면 볼 수 있다. Linux의 세계에서 Windows 파일을 건드는 것은 크게 문제가 되지 않지만, ~~Windows 세계에서 Linux 파일은 웬만하면 절대 건들지말자.~~

Setting Git

https://git-scm.com/book/ko/v2/Git%EB%A7%9E%EC%B6%A4-Git-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

새로운 환경에서 Git을 사용할 때 처음에 설정하면 편한 것들을 정리하겠다.

git config --global user.name "이름"
git config --global user.email "이메일"
git config --global core.autocrlf true Windows
git config --global core.autocrlf input Linux/Mac

Windows 운영체제라면 core.autocrlf true를 Linux나 Mac이라면 core.autocrlf input을 사용한다.

이는 운영체제에서 줄 바꿈을 할 때 문제를 야기하기 때문이다. 줄 바꿈 문자에는 \r라는 CRLF (Carriage-Return)과 \n라는 LF (Line Feed) 이렇게 두 가지가 있는데, Windows 에서는 CRLF와 LF 문자를 둘 다 사용하지만 Linux/Mac에서는 LF 문자만 사용하기 때문이다.

Git repository는 다양한 유저들이 다양한 운영체제로 사용하기 때문에 문제점이 발생할 수 있다. Git은 커밋할 때 자동으로 CRLF를 LF로 변환해주고 반대로 Checkout 할 때 LF를 CRLF로 변환해 주는 기능이 있는데 이것이 바로 core.autocrlf이다. 따라서, Windows 에서는 이 기능을 true로 해서 사용해야한다.

Linux/Mac에서는 CRLF를 사용하지 않기 때문에 Checkout 과정에서 LF를 CRLF로 변환해 줄 필요가 없다. 따라서 core.autocrlf값을 input으로 설정하고 커밋할 때만 CRLF를 LF로 변환하면 되는 것이다.

※주의
내 운영체제는 Windows 이지만, WSL2를 이용하여 Linux 환경을 이용하여 git을 사용해서 그런지 true로 하면 오류가 생겼고 input으로 해야 괜찮았다. 현재는 input으로 설정해서 사용 중이다.

텍스트 에디터를 이용하여 보기 쉽게 편집하려면 git config --global -e 를 이용하면 실행된다. 이때, 터미널 환경에서 에디터를 이용하여 편집하고 그를 저장하고 종료를 해야 다시 터미널을 사용할 수 있도록 하려고 설정하려면 git config --global core.editor "code --wait" 를 입력하면 된다.

code .을 입력하면 에디터가 빠르게 열린다. push와 pull은 더 편리하게 사용하려고 따로 추가한 설정값이다.

2.1 Git Workflow

Git은 크게 3가지 작업환경을 가진다.

working tree
staging area
git repository

working tree는 프로젝트의 파일들을 작업하고 있는 디렉토리를 말한다.

staging area는 버전 히스토리에 저장할 준비가 되어있는 파일들을 옮겨놓는 디렉토리를 말한다.

git repository는 버전 히스토리를 가지고 있는 디렉토리를 말한다. 한마디로 저장소이다.

working tree에서 a, b, c라는 파일들을 작업하고 있는 상황이다.

b, c파일은 저장할 준비가 됐다고 하면, working tree에서 staging area로 옮긴다. 다음으로 staging area에서 git repository로 옮길 때는 commit 명령어를 사용해서 저장한다. 나중에 a 파일도 저장할 준비가 되면 동일한 작업을 한다. git repository에 저장된 버전들은 checkout 명령어를 이용해서 언제든지 원하는 버전으로 다시 돌아갈 수 있다.

저장된 Git 히스토리는 나의 로컬 컴퓨터에만 보관되기 때문에 히스토리를 전부 날릴 수도 있다. 따라서, push 명령어를 이용해 Github와 같은 서버에 나의 git directory를 업로드 하는 것이다. 서버에서 로컬로 다시 다운받으려면 pull 명령어를 사용한다.

add : working tree -> staging area

commit : staging area -> git repository

push : git repository -> Github

pull : Github -> git repository

working tree는 세부적으로 다음과 같이 나뉜다.

untracked
tracked
- unmodified
- modified

untracked : 새로 만들어진 파일이거나 기존에 존재하던 프로젝트에서 git을 초기화 한 파일. 그렇게 되면 git은 이 파일에 대한 정보가 전혀 없어서 트래킹 하지 못하는 상태이다.

tracked : git이 이미 알고 있는, git이 이미 트래킹하고 있는 것을 뜻한다.

git이 트래킹 하고 있는 tracked 파일들 중에서도 지금 이 시점에서 수정이 되었는지 유무에 따라 unmodified / modified로 나누어진다.

unmodified : 이전 버전에 대해서 수정되지 않은 상태

modified : 이전 버전에 대해서 수정된 상태

따라서, 수정이 된 modified 파일만 working tree에서 staging area로 옮길 수 있다.

각각의 버전, commit에는 스냅샷 된 정보들을 기반으로 해서 고유한 해쉬코드가 부과가 된다. 이것을 통해서 버전 정보를 참조할 수 있는데, commit에는 아이디 말고도 어떤 버전인지 버전과 관련된 메시지, 누가 작성했는지 날짜와 시간 같은 정보들도 함께 포함되어져 있다.

2.2 Git add - add Local files

새로 파일을 생성하고 상태를 보기 위하여 git status를 하면 untracked file임을 확인할 수 있다. 따라서 working tree의 파일을 staging area로 올리기 위해 사용하는 것이 바로 git add 명령어다.

파일을 수정하고 다시 상태를 보면 기존에 add한 파일은 staging area에 있어서 commit을 할 준비가 되어있는 상태인데 추가로 working tree에 modified 파일이 생기는 것을 알 수 있다. 이때 다시 git add 하면 modified 파일이 staging area에 가면서 파일에 버전 히스토리가 생성되는 것을 확인할 수 있다.

SourceTree를 활용하여 GUI 환경에서 쉽게 볼 수도 있다.

git rm --cached <file>명령어를 입력하면 다시 staging area에서 working tree로 이동 가능하다. --cached는 --staged와 거의 동일한 표현이라고 알면 된다.

" 어라, rm 명령어는 CLI 환경에서 파일을 삭제하는 명령어가 아니었나? "

맞다. staging area에서 삭제한다는 의미인데, 삭제하고 working tree로 내리는 것이다.

파일 변경 시 유용한 TIP

working tree에서 파일을 삭제(rm)하거나 이동(mv)하면 working tree 에서만 유효하기 때문에 작업하고 add를 해서 다시 staging area에 적용하고 commit 해야한다.

그러나, git에서 제공하는 git rm / git mv를 쓰면 staging area에 바로 적용되는 것을 확인할 수 있다.

staging area -> working tree 할 때 git rm --cached <file>을 쓴다.
working tree에서 작업한 것을 바로 staging area에 적용하고 싶을 때 git rm / git mv를 쓴다.

다음으로, 만약 a.txt 파일을 삭제했다고 하자. working tree에 a.txt 파일이 없었기 때문에 staging area에 추가되지 않는 것을 확인 가능하다. 이때 git add . 명령어를 사용하면 모든 것을 포함해서 staging area에 추가하는 것을 확인할 수 있다.

2.3 Git ignore

Git과 Github에 올리고 싶지 않은, 트래킹 하고 싶지 않은 파일들은 git ignore 파일에 추가해서 트래킹을 피할 수 있다.

.gitignore 파일을 만들어서 내용을 수정하면 된다.

특정한 파일 이름
특정한 형식 모두
특정 디렉토리
특정 디렉토리 안의 파일

예를 들어서, .log 파일을 트래킹 하고싶지 않다고 해보자.

위의 네 가지 형식을 모두 나타낸 것이다.

.gitignore 형태로 트래킹되지 않는 것을 확인할 수 있다.

2.4 Git status / diff

git status를 이용해서 상태를 확인할 때 git status -s를 이용해서 간단한 형태로 확인 가능하다.

git status를 이용하면 내용이 변경된 것은 확인 가능하지만 어떤 내용이 변경되었는지는 확인이 불가능하다. 이때 git diff를 이용하여 이전 파일과 변경된 파일 간의 차이를 알아낼 수 있다.

git diff에서 기본적으로 -속성은 이전 파일이고 +속성은 변경된 파일을 뜻한다. git diff를 이용하면 working tree의 변경사항만 확인 가능하고 git diff --staged / git diff --cached를 이용하면 staging area의 변경사항을 확인할 수 있다.

-1은 이전 파일의 첫 번째 줄을 확인하라는 것이고 +1,2는 현재 파일의 첫 번째 줄에서 두 번째 줄 까지 확인하라는 의미이다.

diff를 보기 쉽게 에디터로 보고싶어요 !!

git config --global -e를 이용해서 에디터를 연 다음에 다음을 추가하자.

[diff]
	tool = vscode
[difftool "vscode"]
	cmd = code --wait --diff $LOCAL $REMOTE

그러고 나서 git difftool 혹은 git difftool --staged 를 이용하면 된다.

2.5 Git commit

드디어 version을 만들 준비가 되었어요!

staging area의 파일들을 git repository로 이동시키기 위하여 git commit을 하면 에디터가 열린다. 에디터에서 Title(제목)과 Description(상세 내용)을 입력하면 된다.

git log를 확인하면 세부적인 정보 확인이 가능하다.

전체적인 해시코드, 작성자, 날짜, 내용을 볼 수 있다.

위와 같이 git commit을 이용하면 Title과 Description을 작성해야 하기 때문에 commit에 옵션을 줘서 간단하게 커밋하는 경우가 많다.

git commit -m ""을 이용해서 커밋을 바로 해도 된다. 혹은 working tree의 파일이 너무 마음에 들어서 staging area로 올리지 않고 바로 repository로 올려버리고 싶으면 git commit -a ""으로 해도된다. 심지어 메세지까지 마음에 든다면 a(all) 옵션과 묶어서 m(message) 옵션을 같이 사용해서 git commit -am ""고 과 같이 사용하면 된다.

commit 할 때 Tip !!

git repository에 있는 commit 들은 history의 창고이다.

어플리케이션을 만드는 작업을 한다고 가정하자. 히스토리에 전체적인 어플리케이션을 만들어서 하나의 commit으로 저장하면 아무런 의미가 없다. 예를 들어, 기능별로 작은 단위로 만들어 나가는 것이 중요하다.

또, 의미 있는 이름으로 commit해서 저장해야 작업내용을 빠르게 확인 가능하고 내가 원하는 변경사항만 빠르게 찾아서 자세하게 확인 가능하고 원하지 않는 commit을 취소 할 때도 편하다.

큰 단위로 한꺼번에 히스토리에 저장하기 보다는 작은 단위로 나누어서 히스토리에 저장하자.
히스토리에 의미가 없는 이름으로 commit 하지 말고 의미 있는 이름으로 지정해서 저장하자.
commit의 메시지는 보통 현재형 그리고 동사로 만든다. init, add, fix 이런 식으로

commit 할 때 주의점 !!

내가 크래쉬를 고쳤다고 하면 정말로 그 고친 내용만 포함하는 commit을 만들어야지 이왕 하는 김에 다른 버그도 하나 고치고~ 리팩토링도 하고~ 새로운 기능도 넣어보고~ 이런식으로 commit 절대로 ❌❌ 코드 리뷰할 때 혹은 히스토리를 바라볼 때 너무너무 혼동이 옵니다.

commit 메시지에 맞게 해당하는 내용만 포함해서 commit 하자 !! 제발 !!

Summary

https://www.youtube.com/watch?v=8JJ101D3knE 유튜버 Mosh의 git 강의에서 "FREE Git cheat sheet"를 참고로 정리했습니다. https://bit.ly/33rnYLt

About WSL2 settings
- "startingDirectory": "\\wsl$\Ubuntu-20.04\home\jae_yun"
- \\wsl$
About Git settings
- git config --global user.name "이름"
- git config --global user.email "이메일"
- git config --global core.autocrlf true (Windows)
- git config --global core.autocrlf input (Linux/Mac)
Edit using Editor
- git config --global -e
- git config --global core.editor "code --wait"
- code .
Initializing a repository
- git init # initialize git
- rm -rf .git # delete .git
Staging files
- git add file # stages a single file
- git add file1 file2 # stages multiple files
- git add * # stage all files except untracked files ( delete file / new file)
- git add . # stage all
Viewing the status
- git status # Full status
- git status -s # Short status
Commiting the staged files
- git commit # opens the default editor
- git commit -m " " # commits with a one-line message
- git commit -am " " # skipping the staging area
Removing / Moving files
- git rm file
  # Removes from working tree and staging area
- git rm --cached file / git rm --staged file
  # Removes from staging area only
- git mv file1 file2
Ignoring files (
You can ignore it by writing the following in ".gitignore.txt":)
- 특정한 파일 이름
- 특정한 형식 모두
- 특정 디렉토리
- 특정 디렉토리 안의 파일
Viewing the staged / Unstaged changes
- git diff # Shows unstaged(working tree) changes
- git diff --cached / git diff -staged
  # Shows staged changes

Add this code to git config --global -e, if you want to use the editor.

[diff]
	tool = vscode
[difftool "vscode"]
	cmd = code --wait --diff $LOCAL $REMOTE

You can use git difftool / git difftool --staged

Viewing the history
- git log # Full history
- git log --oneline # Summary
- git log --reverse
  # Lists the commits from the oldest to the newest

신재윤

백엔드 데브코스 TIL (Today I Learned)