Git 개념 배우기: Overview

spearkkk·2020년 1월 4일
1

Git 개념 배우기

목록 보기
1/3
post-thumbnail

Git 개념 배우기: Overview

이 글은 git에 대해 개념을 확실히 하고자 dev.to에 올라온 글을 번역한 글이다. 최대한 원본 글을 유지하도록 했으나, git을 익히면서 나의 사고로 이해하고자 의역한 부분도 있다.


우리에게 도움이 되는 tutorial은 단순히 어떤 명령어를 실행 하는지 알려주는 것이 아니라, 어떻게 git 동작 하는지 가르쳐주는 것이다.

Git을 잘 사용하고 싶은가?
무작정 명령어를 익히는 것만이 아니라, 어떤 작업을 하고 있는지 이해하고 싶은가?

그렇다면 이 tutorial을 한번 살펴보자.


Based on the general concept from Rachel M. Carmena’s blog post on How to teach Git.While I find many git tutorials on the internet to be too focused on what to do instead of how things work, the most invaluable resource for both (and source for this tutorial!) are the git Book and Reference page.So if you’re still interested when you’re done here, go check those out! I do hope the somewhat different concept of this tutorial will aid you in understanding all the other git features detailed there.

Overview

아래 그림에서 네 개의 상자를 볼 수 있다. 그 중 하나는 혼자 있는 반면에, 나머지 세 개의 상자는 같이 모여 있다. 여기서 이 세 개의 상자를 통틀어 Development Enrionment라고 생각하고, 혼자 있는 상자를 Remote Repository라고 생각하자.
Git 안에서는 Remote RepositoryDeveleop Environment, 이 두 개의 큰 공간으로 나누어서 작업을 한다고 생각하자.

먼저 그림에서 보이는 Remote Repository(원격 저장소)는 우리가 변경한 데이터를 저장하는 곳인데, 우리는 이 저장소를 통해 변경한 데이터를 다른 사람과 공유할 수 있다. 또 이 Remote Repository에서 다른 사람이 변경한 데이터를 가져올 수 있다.
다른 version control system(버전 관리 시스템)을 사용한 경험이 있다면 이 부분에 대해서는 이미 알고 있을 것이다.

그리고 Develop Environment는 자기 자신의 local machine에 있는 것이라고 생각하자. 이 Develop EnvironmentWorking Directory, Staging Area, 그리고 Local Repository(로컬 저장소)로 이루어져 있다.

이 tutorial을 시작하기에 앞서, 먼저 자기 자신의 Develop Environment를 선택하자. 홈이나 어떤 프로젝트 폴더이어도 괜찮다. 굳이 이 Develop Environment를 위해 새로운 폴더를 생성할 필요까지는 없다.

Getting a Remote Repository

위에서 Develop Environment를 선택했다면, 이제 Remote Repository를 하나 찾아, 자기 자신의 local machine(Develop Environment)으로 가져오자.

이 tutorial에서는 이 repository를 사용하는 것을 추천한다.

To do that I can use git clone https://github.com/UnseenWizzard/git_training.git

이 tutorial에서는 Dev Environment에서 어떤 것을 수정하고 다시 Remote Repository로 옮기는 작업이 필요할 것이다. 그러나 github는 다른 사람의 repository를 권한이 없는 다른 사람이 수정하지 못하게 막아 놓았다. 그래서 github page의 오른쪽 상단에 있는 fork 버튼을 클릭하여 자신의 Remote Repository로 가져가는 작업을 하자.

위의 작업을 하여 Remote Repository를 자기 자신의 Repository로 복사(fork) 했다면, 그 복사한 데이터를 자신의 local machine으로 가져올 수 있다.

Local machine으로 가져오기 위해 git clone https://github.com/{YOUR USERNAME}/git_training.git을 Develop Environment에서 실행해보자.

위의 명령어는 아래의 그림에서 볼 수 있듯이, Remote Repository에서 데이터를 가져와 Develop EnvironmentWorking DirectoryLocal Repository인, 두 곳으로 데이터를 복사한다.
Local RepositoryRemote에 있는 것을 복사한 것이고 그 자체로 저장소 기능을 한다. Remote Repository와 다른 점은 Local Repository는 다른 사람과 공유하지 않는다는 점이다.

우리가 이 작업해서 사용한 git clone은 명령어를 실행한 곳에 새로운 폴더를 만든다. 그리고 새로 만든 폴더에 Remote Repository의 데이터를 복사한다. 따라서 현재 우리의 Develop Environment에는 git_training라는 새 폴더가 있어야한다.

Adding new things

우리가 복사한 git_training 폴더 안에는 누군가가 이미 넣은 Alice.txt라는 파일이 있다. 이 파일은 Remote Repository에서 왔다.
여기에 우리는 Bob.txt라는 파일을 추가 해보자.

우리가 방금 위에서 한 작업(파일을 생성한 작업)은 Working Directory에 파일을 추가한 것이다. 그래서 지금의 Working Directory에는 총 두 개의 파일이 있다.

  • Alice.txt: git이 이미 있는 것을 알고 트래킹하는 파일.
  • Bob.txt: git이 아직 모르고 트래킹하지 못하는 파일.

우리는 방금 새로운 파일을 추가했다.
만약 자신의 Working Directory에서 어떤 변화가 있는지 알고 싶다면, git status라는 명령어를 실행 해보자.
이 명령어를 통해 현재 자신이 작업하고 있는 브랜치(branch), Remote와 Local Repository와 다른 부분, 그리고 트래킹(tracking) 하지 않는 파일의 상태를 볼 수 있다.

실행한 결과를 보면, Bob.txt파일은 트래킹 하지 않고 있다는 것을 볼 수 있다. 또 그 파일이 어떻게 변경 되었는지도 볼 수 있다.

아래 그림에서는 git add Bob.txt라는 명령어를 실행 했을 때, 일어나는 작업을 볼 수 있다.
Repository에 변경 사항을 반영하기 전에, 모든 변경 사항을 모으는 Staging Area라는 곳이 있다. 위의 명령어는 이 Staging Area에 우리가 앞 단계에서 생성한 새 파일을 추가하는 것이다.

모든 변경 사항들을 다 추가했을 때, 우리는 마침내 Local Repository에 '우리가 무엇을 했는지'에 대한 commit을 할 준비가 된 것이다.

우리가 커밋(commit)할 변경 사항들은 '하나의 작은 의미 있는 단위'이다. 따라서 git commit라는 명령어를 실행하면 text editor가 열리고 우리가 어떤 작업을 했는지 commit message 작성할 수 있다. Message를 작성한 후 종료하면, 우리가 실행한 commit은 Local Repository에 추가될 것이다.

우리는 git commit을 하기 위해서 command line에서 git commit -m "Add Bob"라는 command를 실행하자. 우리가 작업한 부분이 이 message로 충분하다고 생각하기 때문이다. 그러나 앞으로 좋은 good commit messages를 작성하기 위해서는 editor를 사용하는 것이 좋다.

위에서 변경한 부분은 아직 우리의 Local Repository에 있다. 이 Local Repostory는 아직 Remote로 변경 내역을 공유하고 싶지 않거나, 다른 사람이 필요로 하지 않은 변경 내역을 저장하기 위해 좋은 곳이다.

우리가 작업한 변경 사항들(commits)을 공유하기 위해서는 Remote Repository에 이 변경 사항들을 push해야 한다.

한번 git push를 실행 해보자. 이 명령어를 실행하면 Local Repository에 있는 변경 사항이 Remote Repository로 보내진다. 아래 그림은 push 이후의 상태를 나타낸다.

Making changes

현재까지 우리는 파일을 새로 만들기만 했다. 그러나 version control의 더 좋은 부분은 파일 수정에 관한 것이다.

Alice.txt 파일을 보자.

이 파일에는 이미 텍스트(text)가 있다. 하지만 Bob.txt 파일에는 아무것도 없으니, 이 Bob.txt 파일에 Hi!! I'm Bob. I'm new here.이라는 새로운 텍스트를 추가 해보자.

그리고 나서 git status를 실행하면 Bob.txt 파일이 변경된 것을 확인할 수 있다. 그리고 이 변경 사항은 아직 Working Directory 안에만 있다.

Working Directory에서 어떤 것이 변경되었는지 알고 싶을 때, git diff를 실행하여 볼 수 있다.

diff --git a/Bob.txt b/Bob.txt
index e69de29..3ed0e1b 100644---
 a/Bob.txt+++
 b/Bob.txt
@@ -0,0 +1 @@+
Hi!! I'm Bob. I'm new here.

이제는 이전에 했던 것처럼 git add Bob.txt를 실행 해보자. 이 명령어는 변경 사항을 Staging Area로 옮기는 것이다.

변경 사항을 Staging Area로 보낸 후git diff 를 실행 해보자. 이전과 다른 결과를 볼 수 있는데, git diffStaging Area(staged)으로 옮긴 변경 사항에 대해 볼 수 없다. 왜냐하면 git diff 명령어는 Working Directory에 일어난 변경 사항들을 보여주기 때문이다.

이미 Staging Area(staged)으로 옮겨진 변경 사항을 보기 위해서는 git diff --staged 명령어를 실행해야 한다. 이 명령어를 실행하면 이전에 Working Directory에서 실행한 것과 같은 결과를 볼 수 있다.

이전 작업에서 Bob.txt에 새로 추가한 텍스트를 보면 'Hi' 뒤에 느낌표가 두 개 붙어 있다. 이번에는 이 텍스트를 'Hi!'처럼 한 개로 변경하자.

변경한 후 git status를 실행하면 두 가지 변경 사항이 나타날 것이다. 하나는 이미 우리가 Staging Area(staged)으로 옮긴 텍스트를 추가한 변경 사항과 나머지 하나는 아직 Working Directory에 있는 텍스트를 수정한 변경 사항이다.

여기서 git diff 명령어를 실행하면 Working Directory와 이미 우리가 옮긴 Staging Area 사이의 차이점을 볼 수 있다.

diff --git a/Bob.txt b/Bob.txt
index 8eb57c4..3ed0e1b 100644
--- a/Bob.txt
+++ b/Bob.txt
@@ -1 +1 @@
-Hi!! I'm Bob. I'm new here.
+Hi! I'm Bob. I'm new here.

여기까지가 우리가 했던 수정 사항이니, git add Bob.txt 을 실행하여 현재까지의 수정 사항을 stage로 옮기자.

이렇게 수정이 끝났다면, 이제 commit을 할 시간이다. 변경 사항이 적기 때문에 git commit -m "Add text to Bob"이라고 commit을 진행해도 괜찮을 것 같다.

이전에 말한 것처럼 변경 사항들(commits)이 Local Repository에 있는데, 이 변경 사항들 중 어떤 commit이 있고 어떤 commit에 무슨 변경이 있었는지 확인하고 싶을 수 있다.

Commit은 각각 고유의 hash 값을 가지고 있다. 그래서 우리는 이 hash 값을 통해 commit들을 비교할 수 있다.

우선 git log 명령어는 commit의 목록을 보여주는데, 이 목록 데이터에는 hash 값 뿐만이 아니라 작성자, 날짜, Local Repository의 상태, 그리고 remote bracnches와 비교하여 local의 최신 데이터도 볼 수 있다.

아래는 git log를 실행 했을 때의 결과이다.

commit 87a4ad48d55e5280aa608cd79e8bce5e13f318dc (HEAD -> master)
Author: {YOU} <{YOUR EMAIL}>
Date:   Sun Jan 27 14:02:48 2019 +0100

    Add text to Bob

commit 8af2ff2a8f7c51e2e52402ecb7332aec39ed540e (origin/master, origin/HEAD)
Author: {YOU} <{YOUR EMAIL}>
Date:   Sun Jan 27 13:35:41 2019 +0100

    Add Bob

commit 71a6a9b299b21e68f9b0c61247379432a0b6007c 
Author: UnseenWizzard <nicola.riedmann@live.de>
Date:   Fri Jan 25 20:06:57 2019 +0100

    Add Alice

commit ddb869a0c154f6798f0caae567074aecdfa58c46
Author: Nico Riedmann <UnseenWizzard@users.noreply.github.com>
Date:   Fri Jan 25 19:25:23 2019 +0100

    Add Tutorial Text

      Changes to the tutorial are all squashed into this commit on master, to keep the log free of clutter that distracts from the tutorial

      See the tutorial_wip branch for the actual commit history

여기서 우리는 몇 가지 확인할 점은:

  • 처음 두 commit은 누군가(이 글의 작성자)에 의해 이미 만들어져 있었다.
  • Bob을 추가한 우리의 첫번째 commit은 Remote Repository에 있는 master branch의 HEAD다. 추후에 branch와 remote repository에서 변경 사항을 가져오는 방법에 대해 알아볼 때, 더 자세히 살펴보자.
  • 최근 Local Repository의 commit은 우리가 방금 변경한 것이고, 그 commit의 hash 값을 볼 수 있다.

한 가지 알아두어야 할 점은 위의 예제와 자기 자신의 commit의 hash 값이 다른 것이다. git에서 Revision IDs를 부여하는 방법에 대해 알고 싶다면 interesting article를 읽어 보자.

자 이제, commit과 그 이전에 commit에 대해 다른 점을 보기 위해서는 git diff <commit>^!라는 명령어를 실행하면 된다. 여기서 ^!은 그 commit의 이전 commit을 가리킨다.

일반적으로 두 commit을 비교하는 방법으로 git diff 8af2ff2a8f7c51e2e52402ecb7332aec39ed540e 87a4ad48d55e5280aa608cd79e8bce5e13f318dc이다.
따라서 이 명령어를 실행하면 위와 같이 같은 결과를 얻는다. 주의할 점은 git diff <from commit> <to commit>형식에서 새로운 commit이 뒤에 위치한다.

아래 그림에서는 변경 사항에 대해 단계 별로 어떤 작업이 일어나는지 확인할 수 있고 어떤 commad를 적용하는지 알 수 있다.

이제는 우리가 수정 했던 사항을 Remote Repositorypush하자.

0개의 댓글