Git 기본적인 사용 방법(1)

Lee Yong Seok·2022년 7월 15일

git init

1) 현재 directory를 Git Repository로 초기화
2) Git으로 version 관리를 하려면 repository를 초기화해야 한다.
3) 실제로 directory를 생성하고 repository를 초기화하면 된다.

$ git init

4) 초기화가 성공적으로 완료되면 git init 명령어를 실행한 directory에 .git 이라는 이름 의 directory가 만들어진다.

5) .git directory에는 현재 directory와 관련한 repository 관리 정보가 저장된다.

6) Git에는 이 directory 이하의 내용을 해당 repository와 관련된 ‘working tree’라고 부른다.

git status

1) Git repository의 상태를 표시하는 명령이다.
2) Working tree 또는 repository에 대응되는 조작을 하면 상태가 차례대로 변경된다.
3) git status 명령어로 현재 상태를 확인하면서 git의 명령어를 하나 하나 입력하는 것이 기 본이다.

$ git status

4) 현재 master라는 이름을 가진 branch에 있는 것이 표시된다.
5) 또한 출력 결과를 보면 commit이 아직 없다는 것도 표시된다.
6) 간단하게 README.md file을 작성해 보자.(touch : 내용이 비어있는 파일을 만들때 사용하는 명령어)

7) README.md file이 Untracked files에 표시되는 것을 확인할 수 있다.
8) Git의 입장에서 보면, 한번도 관리된 적이 없는 파일이라는 뜻.
9) 즉 Git의 Working tree 또는 repository에 명령이나 특별한 작업을 하면, git status 명령어의 출력이 변경되는 것이다.
10) 자주 사용되는 명령이기 때문에 꼭 기억해야 한다.

git add

1) Working directory에 있는 file을 Stage Area로 추가하는 명령이다.
2) Git repository의 working tree file을 생성하는 것만으로는 Git repository의 version 관리에 등록되지 않는다.
3) 여전히 git status로 확인해 보면 위에 생성했던 README.md file은 ‘Untracked files’로 표시된다.
4) File을 Git repository에서 관리하도록 하려면 git add 명령어를 Stage Area(Index라 고 부르기도 한다)라고 불리는 장소에 등록해야 한다.
5) Stage Area이란 commit하기 전의 임시 영역이다.

$ git add README.md
$ git add .
$ git add -i

6) git status로 확인해 보면, ‘Changes to be committed’에 README.md file이 포시되 는 것을 확인할 수 있다.
7) Staging Area에 옮겨진 file을 다시 Working Directory로 옮기는 명령어는 다음과 같 다.

$ git rm --cached <file name>

아래 예제에 따라 연습해보자.

$ touch index.html
$ touch about.html
$ git status

$ git add index.html
$ git status
$ git rm --cached index.html
$ git status

$ git add . : 현재 위치에 있는 파일 등을 한꺼번에 Staging Area에 올리는 명령어

$ git rm -r --cached . : staging area에 올린 파일 모두를 다시 working directory에 내릴 때 사용하는 명령어
-r : recursive의 약자로 순회하다의 의미, 하위 디렉터리를 포함하여 모든 내용을 삭제
$ git status

$ git add -i : 유저와 숫자 또는 영문자의 첫글자로 대화를 주고 받으면서 명령을 실행한다.

What now> q
Bye.
$ git status

git commit

1) Staging Area에 있는 file을 Repository에 저장하는 명령어
2) Staging Area에 기록된 시점의 file들을 실제 repository이 변경 내역에 반영하는 것
3) 이러한 기록을 기반으로 file을 Working tree에 복원하는 것이 가능한 것이다.
4) $ git commit -m “Message”

한 줄의 commit message를 기록하는 방법
-m option을 사용하여 index.html을 commit해 보자.
$ git commit -m “First Commit”

5) $ git commit

상세한 commit message를 기록하는 방법
한 개의 File이라도 git add를 해서 Staging Area에 올려놓은 후 실행한다.
$ git add about.html
$ git commit

Git을 설치할 때 지정한 editor가 실행된다.
기본 Editor는 VIM이다.
만일 editor가 설정되어 있지 않으면 다음과 같은 오류가 발생한다.
$ git commit
error : Terminal is dumb, but EDITOR unset
Please supply the message using either -m or -F option.

vi 편집기는 아직 배우지않았기때문에 다른 편집기로 커밋 메세지를 작성해보자.
:q 명령어로 vi 편집기에서 빠져나올 수 있다.

다음의 명령어로 editor를 등록한다.
Editor로 메모장을 등록하기로 하자.
만일 다른 editor를 사용하려면 해당 editor program의 경로를 입력하면 된다.
$ git config --local core.editor notepad

$ git commit은 미리 지정한 editor를 이용하는데, 보다 상세한 commit message를 기록하기 위함이다.
기록하는 형식은 아래와 같다.
첫 번째 줄 : commit으로 인한 변경 내용을 한 줄로 요약해서 작성, title이라고 함.
두 번째 줄 : 공백
세 번째 줄 이후 : 변경과 관련된 내용을 상세하게 기록
이렇게 형식을 지켜서 작성하게 되면, log를 확인하는 명령어 혹은 tool 등에서 자세한 commit message가 출력된다.
# 기호는 comment 처리된다.
이제 about.html file을 commit 해보자.
방금전에 vim editor에서 notepad로 변경했으니, 다시 기본 편집기를 원래대로 돌려놓자.
$ git config --local core.editor VIM
$ git commit

VI 편집기는 i를 눌러서 편집 모드로 변경 후 내용을 입력할 수 있다.
편집 모드로 변경이 되면 하단에 -- INSERT -- 라고 뜬다.

간단한 title 및 message를 입력해보자.

모두 입력을 마친 상태는 아래의 그림과 같다.

첫 줄은 즉 title부분만 보이는 것을 알 수 있다.

6) $ git commit -a -m “Message”

이미 commit 처리된 file중에 내용이 수정이 된 file은 다시 Working Area로 내려오게 된다.
한번 commit했었기 때문에 이 file은 git add 명령에 의해 Staging Area에 옮길 필요 없이 바로 commit 할 수 있다.
이럴 때 사용하는 option 이다.
하지만, 한번도 Staging Area에 옮겨본 적이 없는 file은 이 option을 사용해서 바로 commit하려고 해도 commit되지 않는다.
이미 commit 된 index.html을 수정해 보자.
$ echo “<html></html>” > index.html
Index.html을 수정했더니 다시 working area에 있는 것을 알 수 있다.
먼저 git status로 현 상태를 확인한다.

이 file을 commit 해보자.
여기서 주의할 점은 한번도 Staging Area에 옮겨진 적이 없는 file은 commit이 안된다는 점이다.

commit을 한 후 상태를 확인해보자.

현재 Working tree의 상태는 commit이 된 최신 상태이다.
변경 내역이 이미 반영되었기 때문에 새로운 변경 내역이 없다는 것을 확인할 수 있다.

git log

1) Repository에 있는 commit 이력을 조회하는 명령어
2) 누가 언제 commit 또는 merge를 했는지, 어떤 변경이 발생했는지 등을 확인할 수 있다.
3) $ git log

Commit 이력 상세 조회

4) $ git log --oneline

Commit 이력 중 commit ID, Title Message만 조회

5) $ git log --oneline --decorate --graph --all

모든 Branch Commit 이력 조회
6) $ git log --
특정 file의 변경 commit 조회

7) 이제까지의 commit 이력을 확인해 보자.
$ git log

방금 전까지 commit 했던 내용들을 확인할 수 있다.
Commit 옆에 표시되는 글자들은 해당 commit 을 나타내는 hash인데, 다른 git 명령어에서 이러한 hash를 이용한다.
Author 옆에는 git에서 설정한 이름과 Email 주소가 표시된다.
Date 옆에는 commit했던 시간이 표시되고, 그 아래에는 이전에 입력했던 commit message 가 출력된다.

8) 이번에는 commit message의 첫 번째 줄만 출력해보자.
$ git log --pretty=short

9) 아직 Branch를 학습하지는 않았지만, 모든 Branch의 commit 이력을 조회하는 명령도 해 보자.
$ git log --oneline --decorate --graph --all

10) 선택한 folder 또는 file의 log를 출력하는 방법

$ git log <file name>
해당 folder나 file의 log만 표시된다.
$ git log index.html

11) File의 변경된 내용을 출력하는 방법

Commit 에서 변경된 내용을 확인하고 싶을 때는 -p option을 사용한다.
Commit message 뒤에는 변경 내용이 함께 표시된다.
$ git log -p

만일 특정 파일의 변경 내용만 출력하려면 -p option 뒤에 file 이름을 넣으면 된다.
$ git log -p <file name>

12) 이렇게 git log 명령어는 과거의 commit 내용을 파악하고자 다양한 option을 제공한다.
13) 한 번에 모든 option을 기억하는 것을 어렵기 때문에 필요할 때마다 자주 사용하도록 한다.

git reset

1) Working Directory, Staging Area, Repository에 올린 내용은 어떻게 취소할 수 있는가?
2) git reset 설명
3) Option : 어디까지 되돌릴 수 있는가?

--hard HEAD^ : 수정한 것까지 통째로 되돌리자
--mixed HEAD^ : add한 것까지(default)
--soft HEAD^ : commit 한 것만

4) HEAD : 현재 작업 중인 branch/commit 중 가장 최근 commit을 가리킨다.
5) HEAD^ : 가장 최근 버전에서(HEAD)에서 ^(하나 되돌리자)

$ git reset –hard HEAD^ : 가장 최근 commit으로부터 한 개 전으로 되돌리자.
$ git reset –hard HEAD^^ : 가장 최근 commit으로부터 두 개 전으로 되돌리자.
$ git reset –hard HEAD^^^ : 가장 최근 commit으로부터 세 개 전으로 되돌리자.

6) 실습을 위해 test.txt 파일을 만들고 “This is first commit”의 문자열을 저장한다.

7) 지금의 git 상태를 확인한다.

8) 현재 Working Directory에 있는 test.txt를 Staging Area에 올린다.

9) Repository에 Commit을 하고 log를 확인해 본다.

10) 상태도 확인해 본다. 잘 commit됐음을 확인할 수 있다.

11) test.txt 파일의 내용을 수정하고 add 한다.

12) 다음과 같이 commit도 수행하고 log로 확인한다.

13) 다시 test.txt를 다음과 같이 수정하고 add했다.

14) 이제까지 한 것을 정리하면, I’m here Staging Area 문자열을 갖고 있는 test.txt는 Staging Area에 있고, I’m here Repository 문자열이 저장되어 있는 test.txt는 Repository에 있다.
15) 마지막으로 다음과 같이 This is fourth commit 문자열을 test.txt에 수정했다.

16) 지금까지의 내용을 확인해보자.

17) 먼저 status를 보면, test.txt 파일이 수정되었고, 아직 Staging Area에 올리지 않은 내 용의 파일이 있으며, log를 보면, 2번의 commit이 있었음을 알 수 있다.
18) 다시말하면, I’m here Resository의 문자열을 갖고 있는 test.txt는 이미 commit되어 Repository에 위치하고 있고, I’m here Staging Area문자열을 갖고 있는 test.txt는 Staging Area에 있으며, I’m here Working Directory문자열을 갖고 있는 test.txt는 Working Area에 위치하고 있다.
19) 현재의 HEAD는 Repository commit을 한 곳에 맞춰져 있다.
20) 다음의 명령을 수행해 보자.

21) 현재의 HEAD가 First Commit을 가리키고 있다. 그리고 test.txt 파일의 내용을 확인해 보자.

22) 즉 모든 commit이 취소되고, add한 것도 취소된 것을 알 수 있다.

23) 현재 HEAD가 Repository commit한 것을 가리키고 있었기 때문에 Repository Commit을 취소한 것을 알 수 있다.
24) 연쇄적으로 Staging Area에 add한 것도 취소하고, 마지막으로 test.txt를 수정하고 아직 add하지 않은 내용도 취소한 것을 알 수 있다.
25) 시간을 되돌려서 reset 되기 전으로 이동해 보자.

26) 현재 상태를 확인해 보자.

27) 아직 Staging Area에 add하지 않은 파일(I’m here Working Directory)이 있고, Staging Area에 있는 파일(I’m here Staging Area)도 있다.
28) Mixed mode로 reset 해보자.

29) Log를 확인해보자.

30) 당연히 첫번째 Commit만 남겨져 있고, 두번째 Commit은 사라졌다. 상태를 확인해보자.

31) Staging Area에 있던 내용도 사라졌음을 확인할 수 있다. 그럼, 파일의 내용을 확인해보자.

32) 아직 마지막으로 수정한 파일의 내용은 변경되지 않았음을 알 수 있다. 즉, hard mode로 reset 하는 것과 mixed mode로 reset 하는 것의 차이가 여기에 있다. Mixed mode로 reset하는 것은 commit과 add는 취소하고 Working Directory에 있는 파일은 변경하지 않은 것이다.

33) 마지막으로 soft mode로 reset을 연습하기 위해 다시 reset 되지 전으로 되돌린다.