Git(1)

이 포스트는 국민대학교X프로그래머스 주관하는 '2022학년도 여름방학 인공지능 온라인 실전 부트캠프'에서 배운 내용을 정리하는 포스트입니다.

또한 포스트를 작성하는 과정에서 전에 배웠던 Git 사용법(학교 교수님의 자료)과 Git Documentation을 참고했습니다.

https://git-scm.com/book/ko/v2/

Git - Book

---

Git은 쉽게 말해 분산 버전 관리(VCS) 시스템이기 때문에 VCS에 대해 먼저 알아야 합니다.

VCS(Version Control System)

코딩을 혼자서 하라면 할 수 있지만 우리는 대부분 팀별로 프로젝트를 진행합니다. 프로젝트를 진행하다 보면 팀원들이 작성한 코드들을 관리해야 할 일이 생깁니다.

이런 경우를 생각해봅시다. 세 팀원(A, B, C)이 하나의 코드를 작성해야 하는 경우가 있습니다. 팀원 A가 먼저 작성하고 그다음으로 팀원 B, 팀원 C 순서대로 작성하는 순서가 정해졌을 때, 앞의 팀원의 속도가 늦어지면 뒤의 팀원들은 코드를 작성하지 못하는 상황이 생깁니다. 그리고 뒤의 팀원이 코드의 오류를 발견했을 때 오류가 난 부분이 누가 작성했는지 추적하기 힘듭니다.(자신이 작성한 부분을 주석으로 표시하지 않는 한 말이죠.) 또한 수정한 코드보다 오히려 이전의 코드가 더 나았을 경우, 이전의 코드로 돌아가기 쉽지 않습니다.

이러한 상황들에서 우리는 버전 관리가 필요하다는 것을 알게됩니다. 버전 관리를 사용하면 누가, 언제 코드의 어떤 부분을 갱신했는지 파악할 수 있고, 이전의 코드로 되돌아갈 수 있으며, 분산 버전 관리를 할 경우 팀원 A, B, C 모두 각자 병렬적으로 코딩을 할 수 있습니다. Git에서는 분산 버전 관리 시스템(VCS)을 채택했으며 구조는 아래의 그림과 같습니다.

출처: Git Documentation '1.1 시작하기 - 버전 관리란?'

 

서버 측에서 원격 저장소(repository)를 가지고 있고 클라이언트마다 자신의 로컬 저장소를 가지고 있으며 원격 저장소와 로컬 저장소 간에 서로 상호 작용이 가능합니다.

Git

설치(Ubuntu)

저는 현재 우분투 환경에서 작업하고 있기 때문에 우분투를 기준으로 설치 방법을 작성합니다. 방법은 매우 간단합니다.

터미널에 아래와 같이 apt를 이용해 설치하면 됩니다.

$ sudo apt install git-all

Mac이나 Windows에서 설치를 하려는 분들은 아래 사이트를 참고하시기 바랍니다.

https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EC%84%A4%EC%B9%98

Git 사용 방법(CLI)

터미널을 통해 Git을 사용하는 방법을 알아봅시다.

환경 생성 및 초기화

우선 Git을 사용할 폴더를 생성합니다. 저는 바탕화면에 test라는 이름으로 생성했습니다. 생성한 폴더로 이동해서 아래의 명령어를 입력하면 현재 폴더 안에서 Git을 사용할 수 있게 됩니다.

user@<your_name>:~/바탕화면/test$ git init

저장소 내의 파일 상태

현재 test 폴더 안에는 아무 것도 없습니다. Git을 써보기 위해 간단한 파일을 하나 생성합니다.

user@<your_name>:~/바탕화면/test$ cat example.py
print("Hello World!")
user@<your_name>:~/바탕화면/test$ ls
example.py

지금 이 파일의 상태를 보고 싶으면 아래의 명령어를 통해 확인할 수 있습니다.

user@<your_name>:~/바탕화면/test$ git status
현재 브랜치 master

아직 커밋이 없습니다

추적하지 않는 파일:
  (커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
	example.py

커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git add"를 사용하십시오)

현재 example.py는 Git에 의해 추적되지 않는 파일입니다. 즉, 이 파일은 Git을 통해 로컬 저장소에 저장할 수도 없고, 원격 저장소에도 보낼 수 없는 상태입니다. 보통 이런 상태를 unstaged라고 합니다. example.py가 Git에 의해 관리되려면 staged 상태로 만들어줘야 합니다.

아래의 명령어를 통해 staged 상태로 바꿔줄 수 있습니다.

user@<your_name>:~/바탕화면/test$ git add example.py
user@<your_name>:~/바탕화면/test$ git status
현재 브랜치 master

아직 커밋이 없습니다

커밋할 변경 사항:
  (스테이지 해제하려면 "git rm --cached <파일>..."을 사용하십시오)
	새 파일:       example.py

혹시나 실수로 staged 상태로 바꿔버린 경우도 있을 겁니다. 이런 경우 다시 unstaged 상태로 바꿔줄 수 있습니다.

user@<your_name>:~/바탕화면/test$ git rm --cached example.py
rm 'example.py'
user@<your_name>:~/바탕화면/test$ git status
현재 브랜치 master

아직 커밋이 없습니다

추적하지 않는 파일:
  (커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
	example.py

커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git add"를 사용하십시오)

staged 상태인 파일은 commit이라는 하나의 단위로 로컬 repository에 올릴 수 있습니다. commit을 쉽게 설명하면 스냅샷이라 할 수 있습니다. commit을 보내는 순간을 스냅샷으로 찍어서 staged 상태인 파일들만 로컬 repository에 commit이 되고, unstaged 상태인 파일들은 commit 되지 않습니다. commit을 보내는 방법은 아래와 같습니다. -m 옵션을 줘서 이 commit이 어떤 commit인지 설명을 남길 수 있습니다.

user@<your_name>:~/바탕화면/test$ git commit -m "Add example.py"
[master (최상위-커밋) 64670ef] Add example.py
 1 file changed, 1 insertion(+)
 create mode 100644 example.py

그런데 commit이 진행되지 않고 아래의 그림처럼 자신이 누구인지 설정하라는 안내문이 뜨는 경우가 있습니다. 이는 Git을 처음으로 실행하는 분들에게 나타나므로 안내문대로 config를 진행한 후 다시 commit을 시도하면 commit이 될 것입니다.

16진수 64670ef는 commit ID로 SHA-1 해시 값이기 때문에 여러분들이 실행할 때에 나오는 값과 다를 것입니다. commit이 잘 되었는지 확인하는 방법은 아래와 같습니다.

user@<your_name>:~/바탕화면/test$ git log
commit 64670ef0ce2283020f4e645a276054a516b4451a (HEAD -> master)
Author: <Your User Name> <your@email>
Date:   Mon Jul 4 23:20:12 2022 +0900

    Add example.py

commit을 한 후 다시 status를 보면 텅 비어있음을 볼 수 있습니다. 이는 commit을 진행한 이후 파일이 갱신된 적도 없으니 git에서는 자신이 볼 것이 아무것도 없다고 생각합니다.

user@<your_name>:~/바탕화면/test$ git status
현재 브랜치 master
커밋할 사항 없음, 작업 폴더 깨끗함

지금까지 파일이 unstaged 상태에서 로컬 repository에 commit이 되는 과정을 보셨습니다. 이를 그림으로 나타내면 아래와 같습니다.

출처: Git Documentation '2.2 Git의 기초 수정하고 저장소에 저장하기'

근데 그림을 보면 지금까지 설명한 내용과 뭔가 많이 달라보입니다. 지금까지 unstaged, staged, commit 세 단계로 나눠 설명했다면 그림에서는 4단계로 나눠 설명합니다. 이는 세 단계를 더 세분화해서 4단계로 나눈 것입니다.

• Untracked: 주로 파일을 새로 생성할 때 가지게 되는 상태입니다. 새로 생성된 파일들이 아직 Git의 관리 대상이 되지 않았음을 나타내는 상태입니다.
• Unmodified: Git에 의해 최소 1번 관리됐었던 파일들의 상태를 나타냅니다. 이는 'git commit' 이후 아직 파일의 갱신이 이루어지지 않았음을 나타냅니다.
• Modified: Git에 의해 최소 1번 관리됐었던 파일들의 상태를 나타냅니다. 이는 'git add', 'git commit' 등으로 git에 의해 관리된 후로 파일의 갱신이 이루어졌음을 나타냅니다.
• Staged: 'git commit'을 통해 로컬 repository에 commit 될 파일들의 상태를 나타냅니다. 'git add'를 통해 staged 상태로 만들 수 있으며, staged 상태에서 파일의 수정 등의 갱신이 일어나면 다시 'git add'를 해주지 않는 한, 수정한 내용은 반영되지 않을 것입니다.

 

commit 간의 시간 이동(?)

이 글의 초반에 얘기했듯이 VCS를 이용하면 이전의 코드로 돌아갈 수 있다고 했습니다. 이전의 코드로 돌아가는 방법은 commit ID 값을 이용하는 방법이 있습니다. 이를 확인하기 위해 새 파일을 생성 후 커밋을 한 후의 상황으로 만들겠습니다.

user@<your_name>:~/바탕화면/test$ ls
example.py  second.py
user@<your_name>:~/바탕화면/test$ git log
commit 2444b6d4bdfcc00b224edc2aef54664fd21e261a (HEAD -> master)
Author: <Your User Name> <your@email>
Date:   Tue Jul 5 11:22:30 2022 +0900

    Add second.py

commit 64670ef0ce2283020f4e645a276054a516b4451a
Author: <Your User Name> <your@email>
Date:   Mon Jul 4 23:20:12 2022 +0900

    Add example.py

만일 여기서 second.py가 생성되기 전으로 돌아가고 싶다면 아래와 같이 진행하시면 됩니다. commit ID는 돌아갈 곳의 commit ID를 입력합니다.

--hard 옵션을 주면 돌아간 후 working directory, 즉 저희의 directory의 내용도 변경시킵니다. --soft 옵션을 주실 수도 있는데 이 옵션은 돌아갔지만 directory 내의 내용은 유지됩니다.

user@<your_name>:~/바탕화면/test$ git reset --hard 64670ef0ce2283020f4e645a276054a516b4451a
user@<your_name>:~/바탕화면/test$ git log
commit 64670ef0ce2283020f4e645a276054a516b4451a (HEAD -> master)
Author: <Your User Name> <your@email>
Date:   Mon Jul 4 23:20:12 2022 +0900
user@<your_name>:~/바탕화면/test$ ls
example.py

이를 이해하기 위해서는 HEAD라는 놈이 누구인지를 알아야 합니다.

HEAD는 그 동안 자신이 보낸 commit들 중에 가장 최근의 commit을 가리키는 포인터입니다. HEAD 포인터 입장에서 얘기하자면 git reset은 HEAD 포인터를 특정 커밋으로 옮겨놓는 것입니다. (HEAD -> master) 표시는 현재 HEAD 포인터가 master branch에 있음을 나타내는 것입니다. branch에 대한 설명은 다음 포스트에서 하겠습니다.

git reset 설명

다음 포스트: 2022.07.06 - [개념 정리] - Git(2)