Git의 기초
깃이란 오픈소스 버전 컨트롤(version control) 시스템이다. 여기서 버전 컨트롤이란 하나의 파일을 생성, 수정했을 때 업데이트의 전 후를 version으로 분류하여 관리하는 것을 칭한다.
linux의 소스코드를 효율적으로 관리하게 위해 만들어진 프로그램이다.
Git vs GitHub
Git
- 소프트웨어이다.
- system에 설치하여 사용한다. PC 단위로 사용한다고 보면 좋다.
- version control을 위해 사용한다.
- 명령어로 동작한다.
GitHub
- web service이다.
- Git의 repository를 위해 사용된다. 협업을 위한 repository라고 보면 좋다.
- 시각적 인터페이스를 지원한다.
Git과 GitHub의 관계
version control
Git은 주된 목적: version control, Backup, and Collaboration
version control을 알아볼 것이다.
위에서 말했듯이 버전 컨트롤이란 수많은 파일을 수정하는 과정마다 수정본(version)을 저장하여 관리하는 것을 칭한다.
많은 파일을 수정할 때, 수정 이전의 내용이 필요하거나, 수정된 내용을 모를 때도 있을 것이다. 버전 컨트롤은 이러한 문제점에 직면했을 때 굉장히 유용한 기능을 제공한다.
주요기능
- 수정본(version)을 수정시점(change point)에 저장하여 관리한다.
- 각각 버전의 내용을 모두 확인할 수 있다.
- 특정 버전으로 되돌아 갈 수 있다.
Stage & Commit
Git repo에는 세 가지 저장공간이 존재한다. Working tree, stage, and repository
- Working tree: Git repo가 존재하는 곳이다. 소스코드와 같은 원본 파일들이 저장되는 곳이다.
- Stage: 수정한(edited) 파일에 version을 생성하기 위해 기다리는 곳이다.
- Repository: 수정본들(versions)이 저장되어 있는 공간이다.
버전이 형성되는 절차는 어느정도 알아차리기가 수월할 것이다.
- 1. Working tree의 파일을 수정/생성한다.()
- 2. 수정/생성된 파일의 version을 만들기 위해 Stage에 보낸다.(Add)
- 3. 수정/생성된 파일을 Stage에서 Repository로 옮겨 저장한다.(Commit)
2번과 3번은 이제부터 add, commit이라 칭하겠다.
Before using Git
- $ mkdir [directory name]
- $ cd [directory name]
- $ ls –la
- $ git init //깃 레포 생성
- $ ls -la //git repo 확인
위의 명령어를 사용하여 directory안에 Git repo를 생성하여 Git을 사용해보자.
Making new file(생성)
git status
git status 명령어를 통해 확인할 수 있는 주 정보들은 두 가지이다.
- No commits yet: 아직 commit이 일어나지 않았다는 것이다.
- nothing to commit: 수정/생성이 일어나지 않았다는 것이다.
vim 파일을 하나 생성해보자.(cal.py)
생성 이후 달라진 점은 "untracked files" 부분일 것이다.
untracked file은 version이 존재하지 않는다는 뜻이다. 즉, 생성된 파일을 칭한다.
git add [filename]
git add cal.py 명령어를 작성한다면 파일은 add 단계가 된다. 즉, working directory에서 stage로 옮겨져 하나의 version이 되기를 기다리고 있는 것이다.
add 이후 git status
이전 "untracked files" 문장이 "Changes to be commited" 문장으로 바뀌었다. 이는 새로운 version이 생성될 파일이 stage에서 기다리고 있다는 뜻이다.
git commit -m "message"
git commit –m "create cal.py"// ""안의 문장은 commit message이다.
이 commit은 특정 파일만 commit 하는게 아니라, stage에 대기하는 모든 파일을 commit한다.
그렇다면 stage에서 repository로 이동했다는 것이다.
commit message와 추가된 라인의 개수를 확인할 수 있다.
git log
git log 명령어를 통해 commit된 version 모두를 볼 수 있다.
이는 각각 커밋 해쉬, 작성자, 커밋 시간, 커밋 메시지를 볼 수 있다.
--stat 옵션을 추가한다면 추가된 라인의 수를 확인할 수 있다.
add+commit
git commit -am "modified" 명령어를 통해 add와 commit을 동시에 할 수 있다.
그럼 stage 과정을 거치지 않고 바로 repo로 이동한다.
Editing file(수정)
이전에 생성된 cal.py를 이번엔 수정해보자.(아래의 이미지는 수정 이후 git status)
이젠 두 가지가 바뀌었다.
"Changes not staged for commit"
"no changes added to commit"
둘 다 수정된 파일이 staged 되지 않았음을 뜻 한다.
git diff
수정시 수정 내용을 보여준다. 빨간 글씨 라인이 삭제된 라인이고 초록 글씨 라인이 새로 추가된 라인이다.
Tracked vs Untracked
Tracked: 이는 수정된 파일을 뜻 하며, 이는 한 번 이상의 수정이 있던 파일이다.
Untracked: 수정 내역이 한 번도 없는 파일이며 새로 생성된 파일이다.
Unmodified, Modified, and Staged(Tracked file)
Tracked file의 status이다.
working tree에서 수정된 내역이 존재한다면 modified 상태이다.
add 명령어로 staged 상태가 된다. 수정된 파일이 working tree에서 stage로 이동한다.
commit 명령어로 version이 생성된다. stage에서 repository로 이동한다.
이후 "nothing to commit, working tree clean"는 수정된 파일이 없다는 의미로 unmodified status를 뜻 한다.
File status
Reset & Revert
Discarding changes in working directory
working tree에서 수정된 파일을 그 이전으로 되돌리는 명령어 modified -> unmodified
$ git checkout -- [filename] (= $ git restore -- [filename])
Unstaing a file
staged(added)된 파일을 되돌리는 명령어 staged -> modified
$ git reset HEAD [filename] (= $ git restore --staged [filename])
Resetting to the latest commit
가장 최근에 commit된 파일의 commit과 staging 단계를 모두 되돌려주는 명령어 commited -> modified
$ git reset HEAD^
Resetting to the specific commit
다양한 verions 중 특정(specific) 버전으로 돌아가는 명령어
latest version(Let's say is a 7th one) -> 5th version
$ git reset --hard [the commit hash of 5th version]
issues with using Resetting to the specific commit
이 명령어를 사용한다면 5th version으로 돌아가며 그 이후의 커밋들은 모두 삭제가 된다.
그 이후의 버전들이 삭제되지 않으면서 5th version으로 돌아가는 방법은 Reverting이다.
Resetting 이전의 log
Restting to print2
print2 이후 version이 모두 삭제되어 있음.
Reverting without deleting a commit
reset과 다르게 5th version의 version으로 그 이후의 version을 삭제하지 않고 되돌아간다.
이 말은 되돌아 가는 version의 복사본 version을 하나 더 만드는 것이다.
git revert [the commit hash of 5th version]
