2021/01/16 - [분류 전체보기] - Do it! 공부단
2021/02/19 - [프로그래밍/깃&깃허브] - [깃&깃허브] 01. 깃 시작하기 (~p.37)
02 깃으로 버전 관리하기
깃
- 버전 : 문서를 수정할 때마다 간단한 메모와 함께 수정 내용을 스냅숏으로 찍어서 저장
-> 이것을 관리하는 것 : 깃의 가장 중요한 기능
이번 장에서 다룰 내용
- 문서를 수정 -> 수정 내용을 버전으로 저장하는 방법
- 저장한 버전을 사용해 이전 내용을 되돌리는 방법
02-1 깃 저장소 만들기
<본격적으로 깃 사용하기>
사용자 컴퓨터에 저장소 만들기
- 저장소를 만들고 싶은 디렉터리로 이동 --> 깃 초기화 --> 해당 디렉터리에 있는 파일들을 버전관리할 수 있음
깃 초기화하기 - git init
1. 깃 저장소를 만들 디렉터리(hello-git) 생성 -> 해당 디렉터리로 이동
mkdir hello-git
cd hello-git
2. hello-git 안의 내용 살펴보기
ls -la (== al)
. : 현재 디렉터리
.. : 상위 디렉터리
3. 이 디렉터리에 저장소 만들기
git init
--> init : initialize, 깃을 사용할 수 있도록 디렉터리 초기화
4. 다시 한번 디렉터리 안의 내용 확인
--> .git : 이 디렉터리가 깃을 사용하면서 버전이 저장될 '저장소(repository)'
[한 걸음 더!] git 디렉터리는 감춰져 있다
탐색기에서 나타나지 않을 경우 [보기] > '숨긴 항목' 체크
02-2 버전 만들기
버전 : 프로그램 개발에서는 수정 내용이 쌓이면 새로 번호를 붙여서 이전 상태와 구별
깃에서 버전이란
- 문서를 수정, 저장할 때마다 생기는 것
ex) 과제 보고서 낼 때 최종, 최최종, 최최최종, 진짜최최최최최최종 이렇게 이름 붙이는 것처럼
-> 깃과 같은 버전 관리 시스템 : 훨씬 쉽게 버전을 만들고 만든 시간, 수정 내용까지 기록할 수 있는 것
- 원래 파일 이름은 그대로 유지하면서 파일에서 무엇을 변경했는지를 변경 시점마다 저장할 수 있고, 각 버전마다 작업했던 내용을 확인할 수 있고, 그 버전으로 되돌아갈 수도 있음
스테이지와 커밋 이해하기
<깃에서 버전을 만드는 단계>
- 작업트리(working tree), 작업 디렉터리(working directory) -> 파일 수정, 저장 등의 작업을 하는 디렉터리, 즉 우리 눈에 보이는 디렉터리(hello-git)
- 스테이지(stage), 스테이징 영역(staging area) : 버전으로 만들 파일이 대기하는 곳
- .git/index 파일에 저장됨
- ex) 작업 트리(hello-git)에서 10개의 파일을 수정 -> 4개의 파일만 버전으로 만들려면 4개의 파일만 스테이지로 넘겨주면 됨
- 저장소(repository, 리포지토리) : 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳
- .git/HEAD 파일에 저장됨
--> 스테이지, 저장소는 눈에 보이지 않으며, 깃을 초기화했을 때 만들어지는 .git 디렉터리 안에 숨은 파일 형태로 존재
1. 작업 트리에서 여러 문서 수정
2. 수정한 파일 중 버전으로 만들고 싶은 것을 스테이징 영역(스테이지)에 저장
3. 커밋 명령 -> 새로운 버전이 생성되면서 스테이지에 대기하던 파일이 모두 저장소에 저장
작업 트리에서 빔으로 문서 수정하기
1. hello-git 디렉터리 상태 확인
git status
2. 현재 상태를 나타내는 메세지의 의미 살펴보기
On branch master : 현재 master 브랜치에 있다.
No commits yet : 아직 커밋한 파일이 없다.
nothing to commit : 현재 커밋할 파일이 없다.
3. hello-git 디렉터리에 새로운 파일 hello.txt 만들기
vim hello.txt
4. 1 입력하고 저장, 종료
[i] 또는 [a] -> 입력 모드 -> 1 입력 -> [esc] -> 편집기 종료 :wq
5. 터미널 창으로 돌아와서 목록 확인
hello.txt 파일이 생성된 것이 보임
6. 깃 상태 다시 확인
Untracked files : 아직 한번도 버전 관리를 하지 않은 파일
==> 여기까지의 작업 : 작업 트리에 문서 파일을 만든 것
수정한 파일을 스테이징하기 - git add
1. git add : 스테이징할 때 사용하는 명령어
git add hello.txt
2. 깃 상태 확인 : git status
3. 출력되는 메시지 의미 알기
untracked files: -> changes to be committed:
hello.txt -> new file: hello.txt
--> '새 파일 hello.txt를 (앞으로) 커밋할 것이다' 라는 의미
==> 수정한 파일 hello.txt가 스테이지에 추가되었으며 이제 버전을 만들 준비가 끝났다!
[한 걸음 더!] 스테이지에 올릴 때 경고 메시지가 나타나는 이유
깃 명령어는 리눅스 기반 : 윈도우 --깃 배시--> 깃 명령 사용
※ 윈도우에서 깃을 사용할 때 주의해야 할 점
<윈도우와 리눅스의 줄바꿈 문자가 서로 다르다>
줄바꿈 문자 = 개행 문자 = eol(end of line) : 텍스트 문서에서 [Enter]를 눌렀을 때 그 위치에 삽입되는 문자
- 윈도우 : 문서 저장 시 개행 시 줄이 바뀌는 자리에 CR 문자, LF 문자가 삽입됨(CRLF 문자)
- 리눅스, 맥 : 문서 저장 시 LF 문자 삽입
- 윈도우에서 텍스트 문서를 스테이지에 올릴 때, 깃에서 자동으로 텍스트 문서의 CRLF 문자를 LF문자로 변환해서 커밋할 것이라는 의미 => 사용자가 따로 어떤 조치를 해야 하는 것은 아님
스테이지에 올라온 파일 커밋하기 - git commit
파일이 스테이지에 있다 -> 버전을 만들 수 있다 -> 버전을 만드는 것 : '커밋(commit)한다'
- 커밋을 할 때는 그 버전에 어떤 변경 사항이 있었는지 확인하기 위해 메시지를 함께 기록해 두어야 함
1. 깃에서 파일을 커밋하는 명령 : git commit
-m 옵션 : 커밋과 함께 저장할 메시지를 적을 수 있음 = '커밋 메시지'
git commit -m "message1"
- 커밋 메시지는 한글로 적어도 되지만 터미널 창에서는 한/영 전환도 번거롭고, 나중에 외국인 개발자와 공유할 수도 있으므로 주로 영어로 작성
- 파일 1개가 변경되었고, 파일에 1개의 내용이 추가되었다고 나타남 --> 스테이지에 있던 hello.txt 파일이 저장소에 추가된 것
2. 현재 깃 상태 보기
nothing to commit : 버전으로 만들 파일이 없고
working tree clean : 작업 트리도 수정사항 없이 깨끗하다
3. 버전이 제대로 만들어졌는지 확인하기 : git log
- 저장소에 저장된 버전 확인
- 방금 커밋한 버전에 대한 설명이 나타남 : 커밋을 만든 사람, 만든 시간, 커밋 메세지
==> 스테이지에 있던 hello.txt 파일의 버전이 저장소에 만들어짐
스테이징과 커밋 한꺼번에 처리하기 - git commit -am
commit 명령에 -am 옵션 사용 : 스테이지에 올리고 커밋하는 과정을 한꺼번에 처리 가능
단, 이 방법은 한 번이라도 커밋한 적이 있는 파일을 다시 커밋할 때만 사용 가능
1. 빔에서 hello.txt 파일 열기 : vim hello.txt
2. 입력 모드로 바꾸고 숫자 2를 추가한 뒤 저장, 편집기 종료 : [i] -> 2 입력 -> [ESC] -> :wq
3. 한 번 커밋한 파일이므로 스테이징과 커밋 한꺼번에 처리하기 : git commit -am "message2"
(git commit -a -m "message2" 라고 입력해도 됨)
4. 방금 커밋한 버전에 어떤 정보가 들어있는지 확인해보기 : git log
- 수정한 hello.txt를 저장한 두 번째 버전의 정보가 message2라는 메시지와 함께 나타남
02-3 커밋 내용 확인하기
버전을 관리하기 위해서는 지금까지 어떤 버전을 만들었는지 알 수 있어야 하고, 각 버전마다 어떤 차이가 있는지 파악할 수 있어야 함
커밋 기록 자세히 살펴보기 - git log
git log : 지금까지 만든 버전이 화면에 나타나고, 각 버전마다 설명도 함께 나타남
commit hash == git hash : commit ~~문자열(영문, 숫자)~~ -> 커밋을 구별하는 아이디
(HEAD -> master) : 이 버전이 가장 최신이라는 표시
Author : 버전을 누가 만들었는지
Date : 버전이 언제 만들어졌는지
아래에는 작성가가 기록한 커밋 메시지
-> '커밋 로그' : git log 명령을 입력 시 나오는 정보
변경 사항 확인하기 - git diff
- 구체적으로 어디가 어떻게 수정되었는지 파악
- 작업 트리에 있는 파일과 스테이지에 있는 파일을 비교하거나, 스테이지에 있는 파일과 저장소에 있는 최신 커밋을 비교 -> 수정한 파일을 커밋하기 전에 최종적으로 컴토할 수 있음
1. vim에서 hello.txt 파일을 열고, 기존의 내용 중에서 '2'를 지우고 'two'를 추가한 후 저장
2. 깃의 상태 확인
3. 1에서 수정한 hello.txt 파일이 저장소에 있는 최신 버전의 hello.txt와 어떻게 다른지 확인 : git diff
- 최신 버전과 비교할 때 '2'가 삭제되고, 'two'가 추가되었다
-> 작업 트리에서 수정한 파일과 최신 버전을 비교한 다음,
수정한 내용으로 다시 버전을 만드려면 스테이지에 올린 후 커밋
수정한 내용을 버리려면 git checkout 명령을 사용해 수정 내용을 취소
4. 마지막 실습을 위해 hello.txt 원래대로 되돌리기 -> 빔에서 hello.txt를 열고 'two'를 다시 '2'로 수정한 후 저장
02-4 버전 만드는 단계마다 파일 상태 알아보기
- 버전을 만드는 각 단계마다 파일 상태를 다르게 표시 -> 파일의 상태를 이해하면 이 파일이 버전 관리의 여러 단계 중 어디에 있는지, 그 상태에서 어떤 일을 할 수 있는지 알 수 있음
tracked 파일과 untracked 파일
git status : 화면에 파일 상태와 관련된 여러 메시지가 나타나는데, 작업 트리에 있는 파일은 크게 다음과 같이 나뉜다.
- tracked 상태
- untracked 상태
1. 빔에서 hello.txt를 열고 숫자 '3'을 추가, 저장
2. 빔에 새로운 파일 'hello2.txt' 만들기
3. a, b, c, d를 한 줄에 한 글자씩 입력하고 저장, 종료
4. hello.txt 파일, hello2.txt 파일 모두 작업 트리에 있으니 상태를 확인해보기 : git status
hello.txt
- Changes not staged for commit: -> 변경된 파일이 아직 스테이지에 올라가지 않았다.
- modified: -> 수정되었다
==> 한 번이라도 커밋을 한 파일의 수정 여부를 계속 추적 : tracked 파일
hello2.txt
- Untracked files: ==> 한 번도 깃에서 버전 관리를 하지 않았음 -> 수정 내용을 추적하지 않음
5. 두 파일 모두 스테이지에 올리기
※ git add .
git add 명령 뒤에 파일 이름 대신 마침표(.)를 붙이면 작업 트리에서 수정한 파일들을 한꺼번에 스테이지에 올릴 수 있음
6. 상태 확인 : git status
- 마지막 버전 이후 수정된 hello.txt는 modified:
- 한 번도 버전 관리하지 않았던 hello2.txt는 new file:
- tracked 파일이나 untracked 파일 모두 스테이지에 올라온 것을 확인할 수 있음
7. 커밋하기
- hello.txt를 수정한 내용과 새로 만든 hello2.txt 내용이 다 포함됨
- 커밋 메시지는 "message3"
- 커밋 후 로그 확인
- 그러나 각 커밋에 어떤 파일들이 관련된 것인지 알 수 없음
8. 커밋에 관련된 파일까지 함께 살펴보는 옵션 --stat
git log --stat
- 가장 최근의 커밋부터 순서대로 커밋 메시지와 관련 파일이 나열됨
- message3 : hello.txt, hello2.txt와 관련
- message2 : hello.txt와 관련
- 로그 메시지가 너무 많을 경우 한 화면씩 나누어 보여줌 : [Enter]를 누르면 다음 로그 화면을 볼 수 있고, [Q]를 누르면 로그 화면을 빠져 나와 다시 깃 명령을 입력할 수 있음
[한 걸음 더!] .gitignore 파일로 버전 관리에서 제외하기
- 버전 관리 중인 디렉터리 안에 버전 관리를 하지 않을 특정 파일 또는 디렉터리가 있다면 .gitignore 파일을 만들어 목록을 지정할 수 있음
- 빔을 사용해 .gitignore 파일을 만들어 그 안에 버전 관리하지 않을 파일 또는 디렉터리 이름이나 파일 확장자를 입력하면 됨
- 주로 개인적으로 메모해 놓은 파일이나 프로그램 사용 중에 자동으로 생성된 swp 파일, 백업 파일 등
ex) 다음과 같이 .gitignore 파일의 내용을 작성하면 mynote.txt 파일, temp 디렉터리, 확장자가 .swp인 파일을 버전 관리에서 제외시킬 수 있음
~3/1 학습
3/9
unmodified, modified, staged 상태
tracked 상태 : 한 번이라도 버전을 만들었던 파일
-> 이 'tracked' 상태의 파일 : 더 구체적인 상태를 알 수 있다
-> 깃 명령으로 파일 상태 확인 : 현재 작업 트리에 있는지, 스테이지에 있는지 등
<깃의 커밋 과정 중에서 tracked 파일의 상태가 어떻게 바뀌는지 확인해보자>
1. hello-git 디렉터리 살펴보기 : ls
- hello.txt, hello2.txt 파일이 존재 > hello2.txt의 파일 상태를 따라가보자
2. 깃의 상태와 파일의 상태 살펴보기 : git status
- unmodified : working tree clean이면, 현재 작업 트리에 있는 모든 파일의 상태는 수정되지 않은 상태
3. hello2.txt 파일 수정 : vim hello2.txt
- a만 남기고 나머지 내용 삭제(i로 편집모드 진입) > 저장 > 편집기 종료(ESC 키로 명령 모드로 빠져나와 :wq)
4. 다시 상태 확인
- Changes not staged for commit : hello2.txt 파일이 수정되었고 아직 스테이지에 올라가지 않았다.
- modified : Changes not stage for commit: 이면, 파일이 수정만 된 상태
5. hello2.txt를 스테이지에 올리고 다시 한 번 상태 확인 : git add hello2.txt, git status
- staged : Changes to be committed:, 커밋 직전 단계
6. 스테이지에 있는 hello2.txt 파일을 커밋하고 다시 상태 확인 : git commit -m "delete b, c, d", git status
- 커밋을 끝내고 난 후 hello2.txt의 상태는 수정이 없던 unmodified 상태로 돌아감
<깃에서 버전을 만드는 과정에서 단계별로 달라지는 파일 상태를 그림으로 표현> p.65
[한 걸음 더!] 방금 커밋한 메시지 수정하기
커밋 메시지를 잘못 입력했다 -> 커밋을 만든 즉시 커밋 메시지 수정 가능
가장 최근의 커밋 메시지 수정 : git commit --amend
vim 편집기에서 원래의 커밋 메시지 'delete b, c, d'가 뜸 -> [i]키로 입력 모드로 전환해서 메시지 수정 'message3' -> ex모드로 돌아가 저장, 빔 종료 -> 커밋 메시지가 수정되면서 이전 커밋에 더해짐
커밋 메시지가 'delete b, c, d'에서 'message3'으로 변경되었고,
1개의 파일이 수정되었고, 지워졌다 이런게 표시된 듯!
02-5 작업 되돌리기
- 스테이지에 올렸던 파일을 내리거나 / 커밋을 취소하는 등 -> 각 단계로 돌아가는 방법 알아볼 것
작업 트리에서 수정한 파일 되돌리기 - git checkout
ex) 파일을 수정 -> 저장 했는데 소스가 정상적으로 동작하지 않는 등의 이유로 수정한 내용을 취소하고 가장 최신 버전의 상태로 되돌려야 할 때가 있다 -> 이 때, 일일이 수정한 수천 줄이 넘는 소스를 찾아 수정해야 한다?........ 이런 경우 git checkout 사용해서 쉽게 수정한 내용 취소 가능
※ checkout으로 되돌린 내용은 다시 복구할 수 없음
<파일 수정 취소>
1. vim을 통해 hello.txt 파일 수정
- 숫자 3 -> 영문 three로 수정, 저장
2. 현재 파일의 상태 확인
- modified 상태지만, 스테이지에 올라가 있지 않은 상태
- 작업 트리(디렉터리)의 변경 사항을 취소하려면 'restore'를 사용하라고 되어있음
(책에는 checkout이라고 나와있고, 이걸 사용하라고 되어있음...@@@@ 버전이 달라진건가..)
3. git checkout -- hello.txt 입력해보고 cat 명령어로 hello.txt 파일의 내용 확인하기
- restore, checkout 모두 같은 기능을 하는듯?
스테이징 되돌리기 - git reset HEAD 파일 이름
수정된 파일을 스테이징했을 때, 스테이징을 취소하는 방법
<스테이징 취소>
1. vim을 사용해 hello2.txt 수정 : 기존 내용 삭제 -> 대문자 A, B, C, D 입력 후 저장, 빔 종료
2. hello2.txt 파일을 스테이지에 올린 후 파일 상태 확인하기
3. 상태 메시지 자세히 살펴보기
- 스테이지에서 내리려면(to unstage) git restore 명령을 사용하라고 되어있음
- 안되나봄!!
- 스테이지에서 내리려면(to unstage) git reset HEAD 명령을 사용하라
※ git reset HEAD 뒤에 파일 이름을 지정하지 않으면 스테이지에 있는 모든 파일을 되돌림
4. 스테이지에서 hello2.txt를 내려보기 : git reset HEAD hello2.txt
- unstaged changes after reset: 수정된 hello2.txt가 스테이지에서 내려졌다는(unstaged) 메시지
- Changes not staged for commit: 파일이 아직 스테이지에 올라가기 전(not staged)으로 돌아온 것 확인 가능
최신 커밋 되돌리기 - git reset HEAD^
<가장 마지막에 한 커밋을 취소하는 방법>
- 수정된 파일을 스테이징하고 커밋까지 했을 때
1. vim에서 hello2.txt 문서 수정 : 대문다 'E'를 끝에 추가한 후 저장
2. 스테이징과 커밋 함께 실행하기, 커밋 메시지는 message4 : git commit -am message4
※ git commit -a -m 이렇게 -a 옵션, -m 옵션 따로 사용 가능
3. git log 명령 사용 -> 커밋 메시지가 message4인 커밋 확인 가능
4. 최신 커밋을 되돌리기 : git reset HEAD^
--> HEAD^ : 현재 HEAD가 가리키는 브랜치의 최신 커밋을 가리킴 -> git log 명령 실행 시 가장 최신 커밋에 (HEAD -> master) 표지가 있었는데, 이렇게 되돌리면 커밋도 취소되고 스테이지에서도 내려짐 -> 취소한 파일이 작업 트리에만 남게 됨
※ 최근 3개의 커밋을 취소하려면 git reset HEAD~3
- git log에 message4가 없어지고, 스테이지에서도 내려졌다는 메시지(unstaged changes after reset:) 나옴
[한 걸음 더!] git reset 명령의 옵션 살펴보기
- reset 명령 : 사용하는 옵션에 따라 되돌릴 수 있는 단계가 다름
명령 | 설명 |
--soft HEAD^ | 최근 커밋을 하기 전 상태로 작업 트리 되돌림 |
--mixed HEAD^ | 최근 커밋 + 스테이징을 하기 전 상태로 작업 트리 되돌림 옵션 없이 git reset 명령 사용 시 이 옵션이 기본으로 작동 |
--hard HEAD^ | 최근 커밋 + 스테이징 전 + 파일 수정 전 상태로 작업 트리 되돌림 --> 이렇게 되돌린 내용은 복구 불가능 |
특정 커밋으로 되돌리기 - git reset 커밋 해시
- 깃 -> 파일을 수정, 커밋할 때마다 저장된 버전들이 쌓여있음 -> git reset HEAD^ 명령으로 최신 커밋을 되돌릴 수도 있지만, 특정 버전으로 되돌린 다음 그 이후 버전을 삭제할 수도 있음 : git reset 커밋 해시
1. git reset 명령 연습을 위해 커밋 몇개 만들어 보기
- vim으로 hello-git 디렉터리에 rev.txt 만들고 a 입력한 후 저장
2. rev.txt를 스테이지에 올린 후 'R1' 메시지와 함께 커밋
3. rev.txt를 수정 : 영문자 'b' 추가 후 'R2' 메시지와 함께 커밋
4. 또 수정 : c 추가 후 메시지 'R3' 커밋 -> 또 수정 : d 추가 후 메시지 'R4' 커밋
--> 총 4번의 커밋을 함
5. 지금까지 만든 커밋 확인 : git log
-> R2 메시지가 붙은 커밋으로 되돌리기(즉, R2 메시지가 있는 커밋을 최신 커밋으로 만들 것)
6. reset에서 커밋 해시를 사용해 되돌릴 때 주의할 점
ex) reset A 입력 시 -> A 커밋을 리셋하는 것이 아니라, 최근 커밋을 A로 리셋, 즉 A 커밋을 삭제하는 것이 아니라 A 커밋 이후에 만들었던 커밋을 삭제하고 A 커밋으로 이동하겠다는 으미
--> R2 커밋으로 이동하기 위해 git log 명령의 결과 화면에서 R2 커밋의 커밋 해시를 선택, 마우스 우클릭 > Copy(또는 그냥 Ctrl + C)
※ 커밋 해시 == 커밋 ID
※ 커밋 목록이 너무 길어서 한 화면에 볼 수 없다면 [Enter]를 눌러 다음 화면을 볼 수 있음
7. git reset --hard 복사한 커밋 해시
- HEAD가 방금 복사해서 붙인 커밋 해시 위치로 옮겨졌다고 나타남! 즉, 방금 복사해서 붙인 커밋(R2)이 가장 최신 커밋이 된 것
8. log 목록 살펴보기
-- R2가 최신 커밋이 되었고, R2 이후에 커밋된 R3, R4는 삭제됨!
9. cat 명령을 사용해서 R2 까지의 내용인 'a' 'b'만 있는지 확인
커밋 삭제하지 않고 되돌리기 - git revert
커밋으로 되돌릴 때 수정했던 것을 삭제해도 된다면 git reset 명령 사용
But, 나중에 사용할 것을 대비해서 커밋을 되돌리더라도 취소한 커밋을 남겨두어야 할 때 : git revert 명령 사용
1. rev.txt 파일에 'e' 추가 후 R5라는 메시지와 함께 커밋하고 로그 확인해서 버전 보기
2. 가장 최근 커밋한 R5 버전을 취소하고, R5의 직전 커밋인 R2로 되돌아가려고 한다.
- 이전과 동일한 점 : R2 버전으로 가려고 한다는 것
- 다른 점 : R2 버전 이후의 버전은 다 삭제하고 R2로 갔다는 것(reset) vs R5 버전만 취소하고 R2로 가고자 한다는 것(revert)
※ reset : 되돌아갈 커밋 해시 지정(우리는 R2의 커밋 해시)
※ revert : 취소할 커밋 해시 지정(우리는 R2로 가고자하고 R5를 취소하고자 하니까, R5의 커밋 해시)
3. git revert R5커밋해시붙여넣기
(로그 화면이 너무 길면 [Q] 눌러서 프롬프트($) 표시)
4. revert 명령 실행
- 깃 설치시 지정했던 기본 편집기가 자동으로 나타나면서 커밋 메시지 입력 가능하니 revert 하면서 추가로 남겨둘 내용이 있다면 입력하고 저장하기
- R5 버전이 revert 되었다는 간단한 메시지 나타남
5. 실제로 버전이 어떻게 바뀌었는지 로그 확인
- 로그에 R5를 revert한 새로운 커밋이 생성됨
- 기존의 R5도 역시 사라지지 않음 -> R5 버전을 지우는 대신, R5에서 변경했던 이력을 취소한 새 커밋을 만든 것
아 그러면 내용은 R2 버전(a, b)으로 돌아갔는데 버전 이름(커밋 메시지)은 revert "R5" 이렇게 한건가?
6. 방금 취소한 R5 커밋은 a b에 e가 추가된 것 -> rev.txt 확인해보기
- R5 버전에서 추가했던 'e'가 없어짐 -> revert 명령 사용 시 버전에 있던 이력을 취소할 수 있음
02장에서 꼭 기억해야 할 명령
git config user.name 'aSpring' | 깃 환경에서 이름을 'aSpring'로 지정 |
git config user.email 'aSpring@hahaha.co.kr' | 깃 환경에서 메일을 'aSpring@hahaha.co.kr'로 지정 |
git init | 현재 위치에 지역 저장소 만듦 |
git status | 깃 상태 확인 |
git add ch01.txt | ch01.txt 파일을 스테이지에 올리기 |
git commit -m 'ch01' | 커밋 메시지 'ch01'을 붙여 커밋 |
git commit -am 'ch02' git commit -a -m 'ch02' |
메시지 'ch02'를 붙여 스테이징 + 커밋 동시 |
git log | 커밋 정보 확인 |
git diff | 최근 버전과 작업 폴더의 수정 파일 사이 차이 보여줌 |
git checkout 커밋 해시 | 지정한 커밋 해시로 이동 |
git reset HEAD^ | 가장 최근 커밋 취소 |
git reset 커밋 해시 | 지정한 커밋 해시로 이동하고 이후 커밋 취소 |
git revert 커밋 해시 | 지정한 커밋 해시의 변경 이력 취소 |
'프로그래밍 > 깃&깃허브' 카테고리의 다른 글
[깃&깃허브] 06. 깃허브에서 개발자와 소통하기 (p.202~220) (0) | 2021.03.21 |
---|---|
[깃&깃허브] 05. 깃허브로 협업하기 (p.166~201) (1) | 2021.03.20 |
[깃&깃허브] 04. 깃허브로 백업하기 (p.131~165) (0) | 2021.03.16 |
[깃&깃허브] 03. 깃과 브랜치 (p.84~130) (0) | 2021.03.13 |
[깃&깃허브] 01. 깃 시작하기 (~p.37) (0) | 2021.02.19 |