<2> 생활코딩 - GIT

git stage area

cp f1.txt f2.txt : f1.txt와 똑같은 파일 f2.txt 만드는 명령어

 

과제 : f2.txt 파일을 만들고 커밋해라.

 

1. 나는 vim f2.txt를 하였지만 생활코딩님은 cp f1.txt f2.txt를 이용해 f1.txt과 똑같은 파일인데 이름은 f2.txt인 파일을 바로 생성하였다.

2. git status를 하면 f2.txt는 아직 버전 관리 되고 있지 않다 라고 나온다.

3. git add f2.txt를 통해 버전관리 시작

4. git commit 하여 commit message 적음

5. git log를 통해 지금까지의 commit 역사 확인.

 

f1.txt f2.txt 두개의 파일의 텍스트 모두 수정 해보자!

 

f1.txt는 기존 souce : 2 에서 f1.txt : 4로 변경하고

f2.txt는 f2.txt : 2 로 변경해보자.

=> 각각 vim 파일이름 하여 내용 수정 하고 저장하고 나오면 된다.

 

git status 하면 두개의 파일이 수정되었다고 나온다. 이제 add를 해야하는데 

여기서 잠시.

왜 Git이 add라는 과정을 포함하고 있는가? 그냥 commit하면 되지 왜 commit하기 전에 꼭 add를 해야하는가?

지금 우리가 갖고 있는 이 소스 코드는 굉장히 빈약한 코드이지만 상상력을 발휘해서 상황을 한 번 생각해보자.

우리가 프로젝트를 하다보면 여러 소스코드를 수정한다. 소스코드를 쭉 수정하다 보면은 우리가 commit하는 시기를 놓칠 때가 있다.

이렇게 되면 어떤일이 생길까? 우리가 commit할 때 commit 하나는 하나의 작업을 담고 있는 것이 가장 이상적이다.

그런데 여러개 10개 20개..등.. 이렇게 많은 작업들을 담은 거대한 버전 하나를 만들어야 되는 경우도 있게 된다. (commit의 시기를 놓쳤을 때) 그럼 이때 git은 add라는 과정을 통해서 우리가 commit하고자 하는 파일만 commit을 하게 할 수 있게 해준다.

 

다시 돌아가 git add f1.txt를 하고 git status를 하면 f1.txt는 초록색으로 변하고 위에 Changes to be commited라고 되어있다.

( 즉, 이 파일의 변경사항은 커밋이 될 것이다.라는 뜻)

우리가 add하지 않은 f2.txt는 빨간색으로 표현되어 있고 Changes mot staged for commit( commit이 되지 않을 것이다.라는 뜻)

 

add를 한 파일만이 commit이 되기 때문에 지금 상태에서 git commit을 하면 f1.txt는 새로운 버전에 포함되지만 f2.txt는 포함되지 않게 되는 것이다. (즉, 선택적으로 파일을 commit할 수 있다는 것이다.)

git commit 하고 네번째 commit이라는 의미로 4를 입력하고 git log를 해보면 밑의 사진의 결과를 확인할 수 있다.

그리고 git status를 해보면 add를 하지 않은 f2.txt 는 그냥 modifed 상태로 남아있다.

 

add를 한  f1.txt => commit 대기 상태에 들어감.

add를 하지 않은 f2.txt => commit 대기 상태 들어가있지 않음.

이 상태에서 git commit 하면 git은 commit 대기 상태에 있는 파일들만을 그 버전에 포함시킨다.

 

그래서 git에서는 commit 대기 상태를 stage area라고 부른다.

git은 기본적으로 stage(commit 대기 하고 있는 파일들이 가는 곳) 라고 하는 개념과 repository(commit이 된 결과가 저장되는 곳)라는 개념을 갖고 있다.

 

 

변경 사항 확인하기 (log & diff)

우리가 버전을 만들었을 때 버전을 만든 것의 효용을 가져와야 할 것이다. 그 효용에 대해 살펴보자.

첫번째는, 차이점을 알 수 있고 또는 과거의 어느 시점의 내용을 알 수 있다.

두번째는 과거로 돌아갈 수가 있다.

 

1. 차이점 확인

 

git log -p

git log를 하게 되면 지금까지 역사가 보인다. 여기서의 중요한 정보는 commit 메세지이다. 

git log 뒤에 옵션을 줘서 git log가 동작하는 방법을 바꿀 수 있다.

git log -p : 각각의 commit과 commit 사이에 소스 상의 차이점을 확인할 수 있다.  

가장 최신 커밋 메시지가 4와 그 이전 커밋인 3 사이의 차이점이 무엇인가 라는 것을 보여주는 정보가 바로 이것이다.

 위의 사진 중 +++로 표시되어 있는 파일이 버전 4의 파일이고 밑에 +는 내용을 가리키고 위쪽에 ---로 되어있는 것이 버전 3의 파일을 가르키고 밑에 -는 내용이다.

버전 4에서는 f1.txt의 내용이 f1.txt :4 이고 버전 3의 f1.txt의 내용은 souse : 2이다.

 

위에 ---는 버전 2의 파일이고 +++는 버전 3의 파일인데 버전2에는 null이라고 되어있다. 이 말은 버전 2일때는 f2.txt가 없었고 버전 3일때 f2.txt 파일이 추가되었다는 뜻. 밑에 +souce의 내용은 f2.txt의 초기내용이었다. 즉 이것은 버전 3이 만들어지면서 f2.txt파일이 생성되었고 그 내용은 souce : 2였다라는 뜻.

 

 

diff

git log를 해서 커밋을 확인하면 각각의 커밋은 각작 고유한 자신의 아이디가 있다.

따라서 내가 만약 커밋 메세지가 2인 id를 복사해서 git log [커밋메세지2id]를 하면 이 커밋 이전의 메세지만&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;보이게 된다. 따라서 커밋 id라고 하는 것은 굉장히 중요한 정보이니깐 잘 이해해두기.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 커밋 id = 커밋 메세지가 가리키는 버전의 고유한 주소

 

 커밋메세지 4인 커밋과 커밋메세지 2인 커밋의 차이점을 알고 싶다면 어떻게 해야할까?

 

git diff [커밋 4 id]..[커밋 2 id]  => 각각의 소스 상에 차이점을 보여준다.

 

 

--- f1.txt는 - f1.txt : 2 였고, +++f1.txt는 +souce : 2 였다는 거의 차이점을 보여주고

 

f2.txt는 아까 diff명령에서 앞쪽에서 언급했던 commit 메세지가 4인 id 였다. 뒤쪽에서 언급한&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;commit 메세지가 2인 이곳에서는 null로 존재하지 않는다라고 되어있고&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ---로 되어있는 새로 생성된 f2.txt의 내용은 밑의 빨간글씨 souce : 2 이다 라는 것을 보여주는 것이다.

 

 

따라서 git log -p와 git diff를 통해 소스와 소스 사이, 버전과 버전 사이의 소스 코드 상의 차이점을 확인할 수가 있다.

 

그리고 f1.txt에 내가 내용을 수정하고 git diff를 하면 방금 내가 어떠한 작업을 했는지를 확인할 수 있다. 

이것은 내가 작업을 할 때 커밋을 하기 전 자기가 작업한 내용이 문제가 있는지 없는지를 마지막으로 리뷰할 수 있는 기회를 제공한다.

 

git add f1.txt를 하고 git diff라 입력하면 아무것도 보이지 않는다.

diff라고 하면 내가 작성한 코드가 commit하기 전에 이전 commit과의 차이점을 보여주는 것이다.

 

정리

git log -p : 차이점을 commit 별로 보고 싶다면