기초와 동작과정은 사용하면서 필요없다고 느낄 수 있지만, 그것을 효과적으로 사용할 수 있게 해준다.

🌟 작성 계기

혼자 프로젝트를 진행하며, 깃의 이해에 대한 필요성을 느끼게 되었습니다.

깃을 혼자서 여러 번 공부했는데, 사용한 적은 많이 없습니다.

이제서야 깃에 커밋도 하고, 깃허브에 푸쉬/클론 하면서
' 아무튼 깃을 쓰고 있다 ' 생각하며 사용하고 있습니다.

' 아무튼 깃을 사용 '하는 지금, 지나친 개념과 앞으로 사용할 기능을 정리하고자 작성합니다.

부디, 가장 유명한 버전 관리 도구를 자유자재로 사용하는데 도움이 되도록,
간결하고 이해하기 쉬운 시리즈가 되었으면 좋겠습니다.

📁 GIT

버전 관리

git은 버전 관리 도구입니다. 버전 관리는 무엇일까요?

버전 관리 도구는 파일의 변화를 지켜봅니다.
변화란 누가, 언제, 무엇을 바꿨는지 등 모든 변화의 내용을 지켜봅니다.

버전 관리는 이러한 파일의 변화를 기록하고, 기록된 특정 버전을 다시 꺼내올 수 있는 시스템입니다.

분산 버전 관리 시스템

버전을 저장하고 관리하기 위해서, 버전들이 저장되는 저장소가 필요할 것입니다.

그 저장소를 다른 사람과 함께 사용하려면, 저장소 서버를 두고,
필요한 버전의 파일을 받아와서 사용할 것 입니다.
이러한 방식을 사용하는 중앙 집중식 버전 관리는 수년간 사랑 받아왔습니다.
다만, 중앙 저장소 서버에 문제가 발생하면 히스토리에 접근할 수 없다는 문제가 생깁니다.

git이 사용하는 분산 버전 관리는 필요한 버전의 파일만 받아 사용하지 않습니다.
저장소 전체를 히스토리와 함께 복제합니다.
git의 clone은 모든 데이터를 가진 완전한 백업이라고 할 수 있습니다.

GIT 설치

git을 사용하려면 우선 설치해야합니다. 이미 설치했다면, 최신 버전으로 받는 것이 좋습니다.

GIT for Windows 설치

git --version으로 이미 설치된 git의 버전을 확인할 수 있습니다.

GIT 최초 설정

git은 파일의 변화를 지켜봅니다. 누가, 언제, 무엇을 변경했는지 지켜봅니다.

그것을 위해서 설치 후에 한 컴퓨터에서 git 설정을 해주어야 합니다.
git config를 통해 설정할 수 있습니다.

$ git config --global user.name 'name'
$ git config --global user.email 'yuno@xxx.com'

편집기 설정

사용할 텍스트 편집기를 설정할 수 있습니다.

$ git config --global core.editor vim

git config --list를 통해 설정한 모든 것을 확인할 수 있습니다.

GIT 저장소 만들기

Git의 기능을 활용하기 위해서, Git 저장소를 만들어야 합니다.
두가지 방법으로 Git 저장소를 만들 수 있습니다.

기존 디렉토리를 Git 저장소로

버전관리를 하지 않던 기존 디렉토리를 Git으로 관리하고 싶을 수 있습니다.
프로젝트의 디렉토리로 이동하여, git init 명령을 실행합니다.

$ git init

이 명령은 .git이라는 하위 디렉토리를 만듭니다. 저장소에 필요한 데이터가 저장되어 있습니다.

숨김 폴더로, 윈도우에서는 탐색기 설정을 통해 확인할 수 있습니다.

즉, .git 디렉토리가 없다면(삭제한다면) GIT 저장소가 아닙니다.

기존 저장소 Clone 하기

기존 저장소를 복제하고 싶을 때 사용합니다.
git clone 명령어를 통해, 프로젝트의 모든 History를 받아옵니다.

$ git clone https://github.com/yunoJang/timer.git

당연히 .git폴더도 포함하고 있습니다.

📦 세가지 영역

저장소로 설정한 Git 프로젝트 디렉토리에는, .git 폴더를 포함하여,
프로젝트를 구성하는 실제 작업 파일들로 이루어져 있습니다.

GIT 디렉토리(.git 폴더)는 Repository라고 부르며, Git 프로젝트에서 작업한 정보와,
여러 버전들에 대한 데이터를 저장하는 데이터베이스입니다.

Git 디렉토리 외의 파일들(위 사진에서 선택된 파일들)은 Git 디렉토리에서 특정 버전(특정 시점)을 Checkout한 것입니다.
이렇게 Checkout한 파일들이 존재하는 곳을 워킹트리, 워킹 디렉토리라고 합니다.
우리는 여기에서 가져온 버전의 파일들로 실제 작업을 수행하며, 파일을 수정 및 추가합니다.

Staging Area는 Index로도 불리며, 워킹 디렉토리에서 작업한 내용을
Git 디렉토리에 저장하기 위해 담아두는 공간입니다.

📃 파일의 상태 사이클

git은 파일을 Commited, Modified, Staged 세 가지 상태로 관리합니다.
위에 설명한 세가지 영역과 함께 보면 이해가 쉽습니다.

Commited : 데이터가 Repository에 저장되었음을 의미합니다.
Modified : 워킹 디렉토리에서 수정한 파일을 의미합니다.
Staged : 수정한 파일을 곧 커밋하기 위해 표시한 상태입니다.

하지만, 이는 관리하는 파일에 한합니다. Git 프로젝트 디렉토리에서 파일을 생성하면,
처음엔 Untracked(추적하지 않는) 상태입니다.

파일의 상태 확인

git status는 파일들의 상태를 확인할 수 있습니다.
-s 옵션으로 짧게 확인할 수 있습니다.

$ git status

파일을 하나 생성하고 git status를 하면 'Untracked files’인 것을 확인할 수 있습니다.

추적하지 않기 때문에, 파일을 변경해도 상태의 변화가 없습니다.

add (새로 추적하기)

파일을 git의 관리 대상으로 포함하고 싶다면, add를 통해 Tracked 상태로 만듭니다.
add는 Untracked 상태의 파일을 새로 추적하도록 등록할 수 있습니다

git add <file>

$ git add first.txt

UnTracked 상태의 파일을 add 하면,
git의 관리 대상으로 추가되고, Staged가 됩니다.

Commit

git commit으로 Staging Area의 파일을 Repository에 저장합니다.
-m 옵션으로 메세지를 함게 명령할 수 있습니다.

$ git commit -m 'Add first.txt'

Repository에 저장하면, 워킹트리는 그 커밋(가장 최근 커밋)을 체크아웃합니다.
git log를 통해 히스토리를 조회할 수 있는데, HEAD가 현재 체크아웃 중인 버전을 가르킵니다.

$ git log

커밋을 해도 해당 파일은 여전히 Tracked 입니다.

추가로, -a 옵션으로 Staging Area를 생략하고 모든 파일을 커밋할 수 있습니다.

vsCode에서 커밋할 때, add하지 않아도 수정한 모든 파일이 커밋되는 이유가 이 때문입니다.

파일 수정

이제 파일은 관리 대상이기 때문에, git은 파일의 변화를 지켜봅니다.
Untracked와는 다르게, 파일을 수정하면 Modified 상태를 확인할 수 있습니다.

파일 삭제

주의할 점은, 파일의 삭제 역시, 파일의 수정이라는 것입니다.
Tracked(관리 대상)인 파일이 삭제되면, 변경사항이 '삭제'로 기록됩니다.

워킹 디렉토리에서 삭제하면, 위 처럼 Unstaged 상태입니다.

Git이 권장하는 삭제 방법은 따로 있습니다.

워킹 디렉토리에서 단순히 삭제하는 것이 아닌, git rm을 이용하는 것입니다.
git rm 명령을 사용하면, Staged 상태가 됩니다.

커밋하면 파일은 삭제되고, 더이상 추적하지 않습니다.

add (스테이지)

파일을 수정하면, Modifed 상태가 되고 add로 변경한 파일을 스테이지 할 수 있습니다.

$ git add first.txt

Staged가 되어, 다시 커밋할 수 있는 상태가 되었습니다.
Git이 관리하는 파일은 이러한 라이프 사이클을 반복합니다.

다만, add 하고 커밋 전에, 변경할 코드가 생겨 다시 파일을 수정했다고 해봅시다.
파일은 어떤 상태일까요?
add 하였으니 Staged일까요? 다시 수정했으니 Modifed 일까요?

파일의 상태가 Staged이면서 동시에, Modified입니다.

git add명령은 파일을 바로 Staged로 만듭니다.

파일이 변경하여,Staged이면서 Modifed일 때 커밋을 하면,
파일의 현재 상태가 아닌 git add 명령을 했던 시점이 커밋됩니다.
( 커밋할 것이라고 표시한 영역은 Staging Area이기 때문에 당연합니다 )

이처럼 파일을 수정, 저장하고 끝이 아니라, Staging한 시점에 대한 이해가 필요합니다.
git add후에 변경한 내용을 커밋하고 싶다면, 다시 add 해야 합니다.

변경 내용 보기

앞선 예시들에서 git status를 통해, 파일의 상태를 확인할 수 있었습니다.

단순히, 파일이 변경되었다는 내용 뿐 아니라,
어떤 내용이 변경됐는지 살펴보려면 git diff명령을 해야합니다.

명령을 통해 어떤 라인을 추가했고, 삭제했는지 알 수 있습니다.

git diff는 Unstaged된 수정사항만 확인합니다.

Staging Area에 넣은 이 후에는, git diff --staged를 통해
커밋한 것과, Staging Area에 있는 것을 비교할 수 있습니다.

git diff HEAD : 워킹 디렉토리와 HEAD 비교
git diff <commit hash> <commit hash> : 커밋 간 비교

무시하기 (ignore)

관리하려는 파일이 있는 반면, 관리할 필요가 없는 파일이 있습니다.
로그 파일이나, 빌드 시스템이 자동으로 생성한 파일이 그에 해당합니다.

.gitignore 파일을 만들고, 그 안에 무시할 파일의 패턴을 적습니다.