GIT이란
git은 형상 관리 또는 버전 관리를 위해 사용하는 시스템이다. 어떤 파일 또는 시스템을 개발할 때, 해당 파일 또는 시스템에 대한 개발 상황을 버전별로 기록할 때 사용한다. git을 통해 버전을 관리하면서 필요할 때 과거의 버전으로 돌아가 코드를 수정하거나 가져올 수 있다.
git을 통한 버전 관리를 하는 이유를 정리하면 다음과 같다.
- 버전별로 파일을 손쉽게 관리할 수 있다.
- 파일들의 수정 기록들을 손쉽게 관리할 수 있다.
- 과거 버전의 파일이 필요할 때 과거 버전의 파일을 가져와서 손쉽게 복구할 수 있다.
- 협업을 할 때 git을 이용하면 덮어 씌여지거나, 섞이는 등의 문제를 예방할 수 있다.
깃은 크게 3가지 workflow가 있다.
- 우리가 프로젝트에 파일들을 수정하고 작업하는 working directory
- 버전 히스토리에 저장할 준비가 되어있는 파일들을 옮겨놓는 staging area
- git버전 히스토리에 저장하는 .git directory
working directory
working directory는 untraked와 traked 두가지로 구분 가능하다.
untracked : 새로 만들어진 파일, 기존에 존재하던 프로젝트에서 깃을 초기화하여 아직 트래킹 하지 않은 파일
traked : 깃이 이미 알고있고, 트래킹 하고 있는 파일
traked에서도 두가지 구분이 가능하다
트래킹 하고 있는 시점에서 수정(이전 버전과 비교)이 되었는지 안되었는지에 따라
unmodified , modified 라고 한다. 이 중에서 수정이 된 modified에 속한 파일만 staging area로 이동이 가능하다.
정리하자면 working directory에서 staging area로 넘겨준 파일을 다시 한번 수정하였을 때
수정한 파일은 working directoty 중 tracked, 그 중에서도 modified 파일이다.
위 사진처럼 a파일에서 추가한 seojin은 staging area에 추가된것이 아니기 때문에 동일한 파일이여도 staging이 된 이후에 수정된 내용은 다시 working directory에 올라온다.
비유가 적절치 못할 수 도 있지만 예를 들어보자면 블로그에 글을 게시한 상태라고 가정 하자.
그 글을 수정하는동안 글이 사라지지 않고 블로그에 게시가 그대로 되어 있는것처럼 staging area에 남아있는 것이다. 이 글을 임시저장을 한다면 working directory에 남아 있는것이고 글을 다시 게시하면 staging area에 업데이트된 버전의 글이 적용되어 올라가는것이다.
위와 같은 workflow는 내 컴퓨터에서만 즉 local에서만 저장되기에 (local)컴퓨터에 이상이 생기면 작업에 문제가 생길 수 있다.
그렇기에 깃허브와 같은 분산서버 시스템에 나의 디렉토리를 저장할 필요가 있다.
commit? push?
깃허브나 깃을 사용할 때 사용하는 명령어들을 아무 생각없이 사용했던 경험이 있다.
간단하게나마 요약해보자
add : working directory -> staging area로 넘겨줄 때 사용
add * : -> 모든 파일을 staging area로 넘겨줌
commit : staging area -> .git directory로 넘겨줄 때 사용
checkout : .git directory -> working directory로 넘겨줄 때 사용
push : github와 같은 서버에 나의 .git directory를 업로드 할 때 사용
pull : 서버에서 다시 로컬로 다운 받을 때 사용
rm --cached * : 모든 파일을 staging area에서 제거 -> untracked 상태가 된다.
참고
https://www.youtube.com/watch?v=Z9dvM7qgN9s&feature