아래 예제에 따라 연습해보자.
1) Visual Studio Code 를 열어서 기본 폴더 위치를 D:\Temp로 잡는다.
2) 새로운 Terminal 을 열어서 Terminal을 Git Bash로 잡는다.
3) Working Directory의 위치를 D:\Temp로 잡는다.
4) index.html 파일을 만들어서 <html></html> 을 저장한다.
5) index.html 옆에 U 표시는 한번도 커밋된적이 없는 Untracked File이라는 의미를 나타낸다.
6) git add index.html을 입력하고 저장한다.
7) Working Directory에서 Staging Area에 파일을 올리면 파일 옆에 U표시에서 A표시로 바뀐다.
8) git commit -m "First Commit"을 입력한다.
9) index.html 파일의 내용에 <body></body> 태그를 추가한다.
10) 커밋된 index.html 파일이 수정되었기때문에 파일명 옆에 Modified의 약자인 M 표시가 생기고 Staged 되기전인 Working Directory로 내려가게된다.
git diff
커밋한 파일과 Working Directory 에서 작업한 파일의 차이를 보여주는 명령어
11) git diff 명령어를 입력하면 먼저 커밋된 파일과 not Staged File의 차이를 보여준다.
commit message update
12) 한번 커밋했던 파일을 내용 수정 이후 다시 커밋한다.
13) git commit --amend 명령어를 입력하면 기존에 설정한 편집기가 열리고 편집기 안에서 커밋 메세지를 수정하면 된다.(필자는 기본 편집기인 vi편집기로 열리게된다.)
14) vi편집기에서 수정을 하려면 append의 약자인 영문자 a를 누른다.
15) Second Commit이라는 커밋 메세지에 again.을 추가한다.
16) 전부 수정하였다면 ESC를 누르고 :(세미콜론) + w(저장)q(빠져나오기)을 입력하고 Enter를 친다.
17) git log 명령어를 통해 Second Commit 메세지가 +again.으로 바뀐것을 확인할 수 있다.
git checkout
지정한 commit hash(아이디)로 이동
18) 커밋을 2번했으니 이해를 하기위해 커밋을 2번 더 하자.
19) git log로 4번의 커밋을 확인한다.
20) 버전관리의 개념인 특정시점으로 이동을 해보자.
21) 현재는 <head></head> 태그까지있지만, <body></body> 태그까지만 있던 Second Commit시점으로 가보자.
22) git log를 봐보자.
23) 그렇다면 checkout 명령어는 기존의 2번의 커밋을 잊어버린걸까?
24) 아니다! 최근 커밋의 내용을 기억하고있는 HEAD라는 포인터가 단순히 Second Commit의 해시를 가리키고 있는것일 뿐이다.
25) 그러면 다시 원래대로 fourth Commit 으로 되돌아오고 git log를 봐보자.
26) 새로운 파일인 hello.txt를 만들고 1이라는 내용을 입력 후 저장하자.
27) hello.txt 파일을 Staging Area에 올리고 상태를 확인하자.
28) 1을 저장하고 커밋, 2를 저장하고 -am 옵션으로 커밋, 마찬가지로 3도 커밋한다.
git reset --soft HEAD^
마지막 커밋만 취소한다.
29) git reset --soft HEAD^ 명령어를 입력하고 git log를 보자.
30) 커밋은 R3까지했지만 soft reset를 한 결과 가장 최근의 커밋만 취소가 된다는 사실을 알 수 있다.
31) 커밋만 취소될 뿐 Staging Area에 세번째 커밋전의 파일이 있다.
git reset --mixed HEAD^
마지막 커밋을 취소하고, Staging 되어있는 file도 취소된다.
31) 다시 R3를 커밋을 하고 git log를 보자.
32) git reset --mixed HEAD^ 명령어를 친다.
33) soft reset과 다르게 mixed reset은 가장 최근 커밋된 file도 취소하고 Staging된 file도 취소된다는 것을 알 수 있다.
git reset --hard HEAD^
가장 최근 커밋 file 취소, Staging Area 에 올라온 file도 취소, Working Directory에 있던 updated file도 취소가 된다.
34) hard reset를 해보기 위해 다시 R3를 커밋하고 git log를 확인하자.
35) git reset --hard HEAD^를 입력하고 git log와 git status를 확인하자.
36) 가장 최근 커밋된 file과 Staging Area 및 Working Directory에 저장했던 file도 취소가 된다.
git revert
37) hello.txt file에 5라는 숫자를 추가한다.
38) 수정된 hello.txt file을 Staging Area에 올리고 상태를 확인한다.
39) R5라는 커밋메세지를 입력하여 커밋하고 git log를 본다.
40) git revert R2시점 해시(ID 7자리) 명령어로 R2 시점으로 되돌아가자.
41) 아래 그림과 같이 커밋이 취소되었는데도 취소 내용까지 git log에서 확인할 수 있다.
git log --oneline과 git log --pretty=oneline의 차이점
42) git log --oneline은 해시(아이디)가 7자리까지만 표시되고 커밋된 내용의 타이틀을 보여준다.
43) git log --pretty=oneline은 해시(아이디) 전부가 표시되고 커밋된 내용의 타이틀을 보여준다.
git push를 하기 전 해야하는 원격저장소와 로컬저장소의 동기화(git clone)
44) 테스트를 위한 GitTest 원격저장소 생성
45) 이렇게 원격저장소를 생성할 때, 미리 file 을 만들게되면 바로 push를 하지못한다.
46) 그래서 이 때 git push 대신 git clone으로 먼저 원격저장소의 file을 내려받아야한다.
47) Code 버튼을 클릭해서 해당 원격저장소의 주소를 copy한다.
48) git clone 원격저장소주소 .(현재위치) 명령어로 원격저장소의 files을 먼저 내려받는다.
49) 원격저장소의 주소는 어디에서 확인할까?
50) 로컬저장소를 만들때 해당 폴더위치에서 git init 명령어를 입력하면 .git이라는 폴더가 생긴다.
51) .git 숨겨진폴더 안에 config라는 file이 있는데 이 file에 원격저장소의 주소가 저장되게된다.
52) 이제 index.html file을 새로 생성해서 원격저장소에 push 해보자.
git pull
53) 이번에는 협업 중 다른 개발자가 새로운 file을 원격저장소에 올렸다고 가정하고 index.jsp file을 만들어보자.
54) 원격저장소인 서버가 로컬저장소인 나보다 1개의 file이 더 많다.
55) 원격저장소의 새롭게 들어온 file을 git pull 명령어로 내려받자.
56) 현재 로컬저장소의 file은 4개이다.
57) git pull 이후에 서버에만 저장되어있던 index.jsp file을 로컬저장소로 내려받았다.
