git이란 무엇인가?
소스코드 파일의 버전 백업.
스코드를 수정하다 망해버려서 수정 전으로 되돌리고 싶을 때 어떻게 하는가?
가장 단순하고 확실한 방법은 수정을 시작 전에 소스코드 파일들을 따로 백업해 두는 것이다.
그런데 이 방법의 문제는 소스코드 파일을 편집할 때마다 매번 백업하는 일이 번거롭다는 점이다. 또 백업이 너무 많아지면 내가 뭘 백업했었는지 기억나지 않을수도...
프로젝트 공동 작업
친구들이랑 같이 프로젝트를 할 때 내 코드를 다른 팀원이 실수로 망쳐버린 경우는 없었나?
팀원들이 각자 구현한 버전들을 전부 취합할 때 어려움을 격은 적은 없나?
버전 관리 시스템
위와 같은 문제들을 해결하기 위해 만들어진 것이 git과 같은 버전 관리 시스템이다.
git에서는 소스 코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나 특정 시점의 버전으로 되돌아갈 수도 있다.
또 내가 팀 공동 repository에 올리려는 파일이 팀원 누군가 편집한 내용과 충돌한다면, 공동 repository에 올릴 때 경고 메시지가 발생하고 업로드는 취소된다.
그래서 누군가 애써 편집한 내용을 날려버리는 실수를 걱정하지 않아도 된다.
git repository
git repository에는 소스코드 파일의 수정 과정에서 만들어졌던 전체 버전들이 전부 저장된다.
remote repository
팀원들이 공유하기 위한 repository다. 팀원들 모두 접근할 수 있는 remote 서버에 만들어진다. (대표적인 git remote repository 서버= github)
local repository
개발자 개인의 PC에 생성되는 개인 전용 repository
평소에는 팀원 각자 개인 PC의 local repository에 버전을 저장하며 작업하다가
그동한 작업한 내용을 팀원들에게 공개하고 싶을 때,
local repository에 저장된 내용을 remote repository에 업로드 한다.
누군가 remote repository에 작업한 내용을 업로드하면, 다른 팀원들은 그 내용을 각자의 개인 PC의 local repository에 다운로드할 수 있다.
local repository 만들기
개인 PC에 local repository를 만드는 방법
- 비어있는 local repository를 새로 만든다
- 이미 만들어져 있는 remote repository를 다운로드해서 local repository를 새로 만든다.
변경을 기록하는 commit
commit은 소스코드 변경 이력을 저장소에 기록하는 중요한 작업!
(어떤 기능 구현을 완료했다거나 어떤 버그를 해결했다면, 결과 버전을 local repository에 commit하자.)
commit 메시지
작업 내용을 commit 메시지에 입력
commit hash
각 commit에는 알파벳과 숫자로 이루어진 40자리의 hash 자동 부여
commit hash는 그 commit을 식별하기 위한 commit ID
working tree와 staging area
git 버전 관리 대상인 소스코드 폴더를 working tree라고 부른다. (working directory)
commit을 실행하기 전 local repository와 working tree 사이에 staging area 라고 불리는 가상의 공간이 있다.
git의 commit 작업은 working tree에 있는 변경 내용을 전부 repository에 바로 기록하는 것이 아니라,
staging area에 등록된 파일들의 변경 내용만 repository에 기록한다.
따라서 어떤 파일의 변경 사항을 repository에 기록하기 위해서는, commit하기 전에 먼저 그 파일을 staging area에 등록해야 한다. staging area에 등록된 파일만 다음 번 commit에서 기록된다.
예를 들어, 10개의 파일을 수정했지만 그 중에 7개 파일의 변경 사항만 repository에 기록하고 싶다면,
그 7개 파일을 staging area에 등록한 후 commit 해야 한다.
이렇게 staging area에 등록된 파일의 변경 사항만 repopsitory에 기록되기 때문에,
working tree에 있는 파일들 중 내가 원하는 변경 사항만 repository에 commit할 수 있다.
staging area를 index 라고 부르기도 한다.
working tree 스냅샷(snapshot)
commit을 하면, working tree의 현재 상태가 local repository에 기록된다.
그래서 나중에 그 스냅샷 상태로 working tree를 되돌리는 것이 가능하다.
단 staing area에 등록된 파일들만 local repository에 기록된다.
working tree 내부의 파일의 상태
untracked
한 번도 commit 되지 않았고, 아직 staging area에 등록되지도 않은 새 파일의 상태는 untracked 이다.
staged
staged 상태의 파일은 다음 두 경우 중 하나이다.
-
아직 한 번도 commit되지 않은 새 파일이고, 처음으로 commit되기 위해
staging area에 등록된 파일의 상태는 staged 이다.
(untracked => staged) new file -
변경 내용이 commit된 이후 수정되었고, 그 수정 내용이 다시 commit 되기 위해staging area에 등록된 파일의 상태는 staged 이다.
(modified => staged)
unmodified
변경 내용이 commit된 이후로 수정되지 않은 파일들의 상태는 unmodified
modified
변경 내용이 commit된 이후 수정되었지만, staging area에 다시 등록되지 않아서
다음 commit 대상이 아닌 파일의 상태는 dirty / modifed 이다.
working tree 내부의 파일의 상태 변화
상태 변화
-
working tree에 새 파일을 생성하면 그 파일은 untracked 상태이다.
-
untracked 파일을 staging area에 등록하면 staged 상태가 된다.
-
staged 파일을 commit 하면 unmodified 상태가 된다.
-
unmodified 파일을 수정하면 modified 상태가 된다.
-
modified 파일을 staing area에 등록하면 staged 상태가 된다.
-
staged 파일을 commit 하면 unmodified 상태가 된다.
+staged 되지 않은 파일은 commit 되지 않는다.
[staging area 등록 대상 파일]
- untracked 파일
새로 만든 파일은, staged 되고 commit 되어야 한다.
- modified 파일
수정된 파일은, staged 되고 commit 되어야 한다.
Lify cycle
(새 파일 만들기)
untracked
(버전 기록 대상으로 선택)
staged
(commit)
unmodified
(소스코드 수정)
modified
(버전 기록 대상으로 선택)
staged
(commit)
unmodified
(소스코드 수정)
modified
(버전 기록 대상으로 선택)
staged
(commit)
unmodified
