저번에 만든 f2.txt파일을 cp(copy) 명령어를 통해
f1.txt파일을 새로 만들어 보겠습니다.
현재 f1.txt파일은 '버전관리되고있지않다' 라고 뜹니다.
새로만든 f1.txt 파일을 add 해주면
git 저장소에서 정상적으로 new file 이라고 인식을 합니다.
f1.txt를 commit 해서 커밋 메세지를 f1.txt_1로 작성한다음
저장해보겠습니다.
git commit가 정삭적으로 처리된것을 확인할 수 있습니다.
git log 에서도 정상적으로 반영된것을 확인할 수 있습니다. 이후 q 키를 눌러줍니다.
이제 f1.txt와 f2.txt는 모두 같은 상태입니다.
이번에는 두 파일을 모두 수정해보겠습니다.
먼저 f1.txt의 내용을 'f1.txt_change'로 수정해보겠습니다.
f2.txt도 똑같은 작업을 해줍니다
cat 명령어를 통해 각 텍스트 파일의 내용을 확인하고
git status 명렁어를 통해 두 파일 모두 modified 된 상태임을 확인할 수 있습니다.
하지만 이러한 과정을 반복하다 보면 한가지 의문점이 생깁니다.
"Git은 왜 commit을 하기 전에 꼭 add를 해야하는가?" 라는 생각입니다.
비록 복잡할지라도 이것은 대형 프로젝트를 만들때 의미가 생깁니다.
실제로 프로젝트를 만들다 보면 여러 소스코드를 수정하게 됩니다.
하지만 이때 commit을 해야할 시점을 놓칠때가 종종 생깁니다.
commit을 할때는 하나의 작업만을 담고있는게 이상적이지만
대규모 패치와 같이 수십개의 작업들을 담은 거대한 버전 하나를 만들어야 할 때가 있습니다.
이때 git은 add라는 과정을 통해서 commit 하고자 하는 파일만을 골라서 commit 할 수있습니다.
git add f1.txt를 통해 f1.txt만 git에 add 해줍니다.
이때 f1.txt 파일은 'Changes to be committed' - 이 파일의 변경사항은 commit이 될것이다. 라는 문구가 나오고
f2.txt 파일은 'Changes not staged for commit' - 이 파일은 commit이 되지 않을 것이다. 라는 문구가 나옵니다.
이때 git commit 명령어를 쓰면 f1.txt는 새로운 버전에 포함되지만 f2.txt 파일은 새로운 버전에 포함되지 않습니다.
즉 선택적으로 파일을 커밋할수있습니다.
git commit을 하고 커밋메세지를 4로 해보겠습니다.
다시 git status 명령어를 쓰면
f2.txt 파일은 commit이 안된 상태임을 확인 할 수 있습니다.
예전에는 서버관리에서 변경사항이 여러가지가 있으면 한번에 모든 수정사항을 커밋을 해야만 했습니다.
하지만 git은 add라는 절차가 있기 때문에 임의적으로 작업한 절차중에 커밋을 할 것들만 골라서 선택적으로 커밋을 할 수 있습니다.
이것이 바로 git의 혁신적인 부분입니다.
다시 되돌아와서 처음에 했던 git add f1.txt라는 작업은
stage에 올라가 됩니다. 즉 커밋을 할 상태가 됩니다.
이후 커밋이 된 파일들은 저장소(repsotitory)에 저장됩니다.
