[GIT] commit add diff reset 실습으로 이해(1)

git을 긍정적인 답변으로 설치하고 나면 환경변수 path에 git이 잡혀있는 것을 확인할 수 있다.

 

깃 버전확인 : 잘 설치되었는지 확인

 

1. git이라고 입력 : 정상적으로 설치되면 위와 같은 메시지

> clone : 프로젝트 디렉토리에 남의 소스를 가져와 시작하는 명령어(소스를 받음)

> init : 깃 로컬저장소 만들기. 이 디렉터리가 로컬 깃 저장소가 된다. 이게 시작임

 

깃의 저장소 .git 디렉토리에 초기화했다는 메시지가 뜸

 

.git : 버전관리를 하는 여러가지 정보들이 생성됨. 저걸 날리면 버전 정보들이 싹 날라감. 소스만 남게됨.

 

소스파일을 생성했다고 생각하자.

 

Git status : 깃의 상태

> untracked files : f1.txt 파일이 추적되고 있지 않다. 깃 저장소에 있지만 버전관리를 하지 않는 파일을 의미함.

 

Git add : 이 파일을 커밋 대기상태로 바꾸고 stage area에 들어간다.

 

F1.txt 파일은 신규파일이라고 깃이 인식하게됨

 

나의 정보기입 이정보로 다른사람들이 소스를 누가 고쳤는지 알 수 있게된다.

 

git commit 입력시 위와 같은 화면이 뜸. 커밋 대기상태인 파일을 커밋하고 버전생성이됨. 그리고 local repository에 버전관리가 됨.

vi 이므로 1 첫번째 커밋이라는 메시지를 지정하고 저장 wq

 

f1.txt 파일이 새로운 버전이 되었다는 의미. 버전이 생성된거임

 

* git log

1. Author : 버전을 작성한 사람의 정보

2. Date : 언제 버전을 만들었는지

3. 맨아래 1 이라는 버전의 메시지 정보를 볼 수 있다.

 

소스수정

 

* git status : 현재 상태

> 빨간글씨 modified f1.txt 파일이 수정되었다는 의미

 

git add : 파일을 커밋대기상태로 stage area로 들어간다, 2번째부터 버전관리를 할 때도 무조건 add 부터해야함.

 

Git status를 입력하면 수정되었다는 내용이 나오고, git commit을 이용해 버전관리를 해줌. 커밋대기상태의 소스를 버전관리하며 local repository에 저장한다. git log 를 보면 2번째 커밋이 적용ㄷ된 것을 확인할 수 있다.

 

F2.txt 파일을 생성하고 git status를 확인해보면 untracked files 처럼 버전관리가 되고 있지 않다는 메시지를 확인할 수 있다.

 

Git add 커밋대기상태로 추가 stage area에 들어감

버전 생성 후 git log를 보면 버전 히스토리를 볼 수 있다.

 

 

소스수정

Git status를 통해 파일 2개가 수정된 상황임을 알 수 있다.

 

* Git add를 하는 이유

> 그때 그때 커밋하면 되지만, 깜빡해서 엄청 많은 버전의 소스를 커밋해야할 때 깃은 add라는 과정을 통해서 커밋할 파일과 커밋하지 않을 파일을 구분할 수 있다.

> add를 한 f1.txt는 Changes to be committed 커밋이 될 것이고

> changes not staged for commit : f2.txt는 커밋되지 않을 것이다.

> 즉 선택적으로 커밋 버전관리를 할 수 있다.

 

git commit -m 4 로 커밋 진행 후 git log 확인

 

 

Git status를 확인하면 f2.txt만 modified 상태로 남아있다.

이전의 형상관리들은 명령어 한방에 무조건 커밋을 해야했으나, 깃은 분할하여 커밋이 가능하다.

1. git log –p : 소스와 소스사이의 변경된 이력을 보여줌.

2. 3~4 : 커밋메시지 3부터 4 사이의 변경된 이력을 보여줌.

--- : 버전3에서의 파일

+++ : 버전4에서의 파일

-source : 버전3의 내용

+f1.txt : 버전4의 내용

--- /dev/null : 버전 2에서는 파일이 없었다.

 

git log 커밋id값 : 해당 id값의 이전 히스토리만 보여준다.(id는 노란글씨)

 

git diff 아이디값1..아이디값2

 

1. git log 로 id값 확인.

4. git diff : 2,3번의 아이디 사이의 소스변화를 보여준다.

--- a/f1.txt : 앞쪽(dc9a로 시작하는 id)의 소스

+++ b/f1.txt : 뒤쪽(1c14로 시작하는 id)의 소스

 

1. 파일 수정

2. git diff : 수정한 현재는 5고, 그 이전에는 4였다고 보여주는 명령어

> 커밋하기전 점검용

 

따라서 수정한 파일을 커밋대기상태 스테이징영역에 올려놓으면 diff 다른게 없음

 

1. git log로 프로젝트의 히스토리를 확인하고 3번으로 돌아가고 싶을 때 롤백

2. git reset 3번 아이디 –hard

> hard는 좀 위험하다. Soft 등 방식도 있지만 일단 hard로 사용하자.

3. git log를 입력하면 3번의 상태로 돌아간 것을 확인할 수 있다.

 

git reset --hard : 작업디렉토리, 스테이징, 커밋 영역까지 롤백

git reset –mixed : 커밋영역과 스테이징 영역까지만 롤백

git reset –soft : 커밋영역만 롤백

 

3번의 상태로 소스가 돌아간 것을 확인할 수 있다.

4,5번이 삭제된 것처럼 보이지만 깃은 완전삭제하지 않는다. 이를 복구하는 건 후에 배우겠다.

> reset 명령어는 hithub 저장소에 있는건 절대 하면 안된다. 개인 로컬에 있는걸 해야한다.

 

Git revert “아이디” : reset은 해당 아이디 버전 위를 싹 날리지만, revert는 4,5번은 두고 3번인 상태로 새로 커밋한다.

 

커밋 명령어에 대한 도움말을 얻는 명령어

 

커밋의 옵션의 종류에 대해 볼 수 있다.

 

옵션에 대한 정보도 확인 가능

 

파일 수정 후 매뉴얼의 옵션대로 add없이, 메시지옵션과 함께 커밋이 가능하다.