Git - 2
Stage area :
지난 포스팅에서 만들었던 v1.txt 을 카피해서 v2.txt를 만들어보자.
만들고 add, commit까지 완료한 뒤 log를 확인한다.
확인되었으면 v1.txt와 v2.txt 두 파일 모두를 수정해볼 것이다.
뒤에 파일이름을 붙여줬다.
둘 다 수정되었으므로 status를 찍어보면 modified에 올라가 있는 것을 확인할 수 있다. 이 전 과정과 같이
add v1.txt
add v2.txt
git commit
명령어를 차례로 사용하여 다시금 commit을 해주어야 할 것이다.
그럼 굳이 번거롭게 commit 한 번으로 전체를 올려버리면 되지, 왜 파일마다 일일이 add를 하는가?
이상적인 버전관리는 한 번의 작업 당 한 번의 commit이 이루어지는 것이다.
그러나 commit한 시기를 놓쳐 수정한 작업파일이 여러개가 쌓이면,
add를 통해 commit할 파일을 선택할 수 있는 용도로 사용할 수 있다.
v1.txt만 add를 실행하고 commit하면
v2.txt는 여전히 modified에 남아 있는 것을 확인할 수 있다.
즉 add 명령어는 해당 파일을 commit 대기상태로 만드는 것이다.
이 commit 대기장소를 stage area라고 한다.
(commit 결과가 저장되는 곳은 repository (저장소) 라고 칭함)
log -p :
버전관리의 가장 큰 효용은 수정된 내용을 추적해 문제해결을 하는데 이용할 수 있다는 점이다.
그 기능을 이용하기 위해 'git log -p' 명령어를 이용하면
로그에서 출력되는 버전 간 차이점을 출력할 수 있다.
--- a/v1.txt는 이전 버전
+++ a/v1.txt는 해당 버전,
붉은 -version 2 는 변경 전의 내용이며
녹색의 +version 2 (v1.txt) 변경 후의 내용을 출력하고 있다.
v2.txt를 카피했던 commit 내역을 확인해 보자.
--- /dev/null 이라는 것은 이전 버전에 해당 파일인 v2.txt가 존재하지 않았다는 뜻이다.
버전이 올라가며 v2.txt 파일이 생성되었으며 그 내용은 녹색 부분의 'version 2' 였음을 확인시켜 주는 것이다.
diff :
log 명령어로 commit 내역을 확인할 때 나오는 노란색 부분은
각 commit 내역의 고유 id값인데, 이를 이용하면 원하는 버전끼리의 차이점을 비교할 수 있다.
명령어는 git diff <버전id>..<버전id> 이다.
가장 최근 버전과 두번째 버전을 비교해 보았다.
두 버전 사이에 2번의 commit이 존재했음과, 변경사항도 확인할 수 있다.
또한 기본 git diff 명령어를 사용하면 이미 add를 거쳤던 파일의 내용과 내가 새롭게 수정한 파일의 내용을 비교해 볼 수 있다.
vim v1.txt 명령어를 이용해 v1.txt 내용을 version 3으로 변경했다.
git diff 명령어를 사용하면
아직 add-commit을 거치지 않았지만 log -p처럼 어떤 내용이 바뀌었는지를 확인할 수 있다.
이는 commit을 하기 전 작업한 내용이 문제가 없는지를 확인할 수 있는 기회를 제공하기 위함이다.
(다음 포스팅에 계속)
