이전에 대략적으로 설명을 드렸습니다만, git의 원리(=버전을 만드는 구조)를 알고 사용하는 것이 추가적인 기능들을 사용하고 이해하는데 큰 도움이 됩니다. 따라서 이번 시간에는 git의 원리 중에서도 git의 구조에 대해 설명하는 시간을 갖도록 하겠습니다.

※ git의 원리에는 두가지가 있습니다.  1) git의 구조, 2) git의 파일 상태 

 

 

1. GIT의 구조


 git이 버전을 만드는 데에는 크게 3개의 구조가 필요합니다.

첫번째는 Working Tree, 두 번째는 Stage, 세 번째는 Repository입니다.

 먼저 각각의 구조에 대해 설명드리고 어떤 식으로 파일들이 운영되는지 알려드리겠습니다. 

① Working Tree : 작업공간을 뜻하는 공간으로, git init명령어를 통해 생성된 공간을 말합니다. 파일의 수정과 저장하는 곳입니다. 우리가 흔히 생각하는 폴더라고 보시면 됩니다. 작업물은 파일이고요. 

 

② Stage : 무대를 뜻하는 공간으로, Working Tree처럼 보이는 공간이 아닌, 가상의 공간입니다. Working Tree에 있는 파일을 Stage에 등록함으로써 등록한 파일을 버전으로 만들기 전 대기하는 공간입니다. Stage가 필요한 궁극적인 이유는 여러개의 파일들이 Working Tree에서 수정되었어도 Stage를 통해서 원하는 파일의 변경사항을 버전으로 등록 가능해지기 때문입니다. 

 

③ Repository : 저장소를 뜻하는 공간으로, Stage에 대기하고 있던 파일들을 버전으로 저장해주게 됩니다. Repository에 등록이 되면 버전(commit)이 완성되게 됩니다. 

 

2. GIT의 구조 (운영방식)


 

 그럼 다음 예시를 통해 변경된 파일들을 어떻게 각각의 공간으로 등록하고 운영하는지 보여드리도록 하겠습니다. 

CASE) Working Tree에 있는 3개의 파일(A, B, C)을 모두 변경하고, 그중 A, B파일만 버전으로 등록하는 상황

 

위의 상황이면 다음과 같이 진행됩니다. 

1) A,B,C파일에 내용 변경 후, 상태 확인 git status

2) git add로 A, B파일을 Stage에 등록

3) Stage에 있는 A,B파일을 git commit으로 version 등록 

 

 

1) A,B,C파일에 내용 변경 후, 상태 확인 git status

   vim 편집기를 사용해 A, B, C파일의 내용을 변경한 뒤, git status 명령어를 사용하게 되면 다음과 같이 A,B,CA, B, C 파일들이 수정되어있다고, git에서 인식하게 됩니다. (이는 사전에 A, B, C파일을 별도 버전(커밋)으로 등록하였기 때문에 수정됨을 알 수 있습니다.) 여기서 수정한 A,B,C 파일은 모두 Working Tree에 있는 상태입니다. 

 

2) git add로 A, B파일을 Stage에 등록

  git add 명령어를 통해 A.txt와 B.txt만 Stage에 올렸습니다. C.txt파일은 이전 버전과 비교하여 수정은 되었지만 이번 버전에는 필요가 없어 등록하지 않을 예정입니다. 따라서 아래 초록 글씨로 A, B 파일은 stage에 올라갔다고 표기되고, C.txt 파일은 1)에서와 같이 빨간 글씨로 스테이지에 올라가지 않았다고 표기가 됩니다. 

 

3) Stage에 있는 A,B파일을 git commit으로 version 등록 

   git commit을 사용하여 Stage에 있는 A.txt와 B.txt를 Repository에 등록해주면 버전은 생성이 되고 git show를 통해 방금 생성된 버전에 대한 정보(어떤 부분이 변경되었는지?)를 알 수 있게 됩니다. 이후 git status를 통해 git의 상황을 보게 되면, A, B는 이미 수정된 사항이 버전으로 등록되었기 때문에 Working Tree와 Stage에서 없어지고 Repository에 저장됩니다.(여기서 없어진다는 표현은 파일의 삭제가 아니라 내용이 버전 안에 포함되어 생성된 버전과 비교하여 변경사항이 없음을 말합니다.) 버전으로 커밋하지 않은 C.txt만 Working Tree에 남아있게 됩니다. 

 

 

이로써 git의 구조와 구조 안에서 버전이 어떤식으로 생성되는 원리에 대해 설명하였습니다.

혹시 추가적으로 궁금하신 사항이 있으면 언제든지 댓글 부탁드립니다. :)

 

 

 

 

*Reference

- "지옥에서 온 문서 관리자 깃&깃허브 입문" 이지스버블리싱 - 이고요, 고경희 지음

-

-

 

부족한 글이지만 읽어주셔서 감사합니다. 

 이번에는 지난 시간 동안 git add, git commit 명령어를 사용하여 만들었던 버전들의 내용을 확인하는 방법에 대해 알아보겠습니다. 

 

 

git log


① git log 내용

 그동안 만든 버전들의 내용을 보기 위해선 git log라는 명령어를 사용합니다.

git log

git log 명령어를 사용하면 다음과 같은 정보가 출력됩니다. 

① commit 해시 : 숫자와 영어의 조합으로 구성된 커밋 해시 값이 나오게 됩니다.
                             커밋 해시는 버전을 명명하는 아이디라고 생각하시면 됩니다. 

② Head 정보 : 현재 우리의 버전이 어디에 있는지 (= HEAD가 가리키고 있는 최신 버전) 브랜치를
                          알려줍니다.

③ commit 메세지 : 커밋을 생성하면서 적었던 메시지가 나옵니다. 

 

이외에도 작성한 작성자 정보( ← 해당 내용은 협업시 도움됩니다), 작성 시점이 나오게 됩니다. 

이와 같은 버전에 대한 정보를 나열해놓은 것을 commit log라고 합니다.  

 

 

② git log 옵션(--graph, --oneline)

 git log의 옵션은 매우 많습니다. 하지만 버전을 관리하고 협업하는 User입장에서는 2개의 옵션 정도만 알고 있으면 git을 사용하는데 무리가 없으리라 생각합니다. 

 

첫 번째는 --graph 옵션입니다. 

git log --graph

 git log --help의 매뉴얼을 참조해보면, --graph 옵션은 커밋 사이에 선을 그어주어 커밋 간에 관계에 대해서 알려주게 됩니다. 어떤 버전으로부터 이전 버전이 나오게 되었는지, 이후 버전이 나오게 되었는지 표기해주고 알 수 있게 해 줍니다. 아래 그림처럼요. 이후에 배울 branch라는 개념이 도입되면 버전이 점점 복잡해지기 때문에 가시화해서 버전 정보를 파악하는 것은 매우 중요해지게 됩니다. 

 


 두번째는 --oneline 옵션입니다.

git log --oneline

--oneline옵션은 말 그대로 commit log의 정보를 한 줄로 표기해주게 됩니다.  3개의 내용을 표기해줍니다. 커밋 해시 7자리와 HEAD정보, 커밋 메시지 정보를 알려주죠

 

일반적으로는 위의 두 개 옵션을 함께 사용해서 가시성을 높여 사용합니다. ㅎㅎ 

git log --graph --oneline

 

 

 

 

*Reference

- file:///C:/Program%20Files/Git/mingw64/share/doc/git-doc/git-log.html (git log --help)

- "지옥에서 온 문서 관리자 깃&깃허브 입문" 이지스버블리싱 - 이고요, 고경희 지음

-

 

부족한 글이지만 읽어주셔서 감사합니다. 

 

 지난 시간에 git을 활용하여 첫 번째 버전을 만들어 보았습니다. 이번 시간에는 n번째 버전을 만드는 방법에 대해 설명하는 시간을 갖도록 하겠습니다. 

 

 이에 앞서 지난번 내용을 복기 해보면 git을 통해 첫 번째 버전을 만드는 방법은 다음과 같습니다.

1) 버전을 관리할 폴더에 가서 git init

2) 원하는 파일을 만들고 (예. A.txt) 해당 파일을 git add <파일 이름>을 통해 stage영역에 등록

3) git commit -m "<버전 이름>"을 사용하여 버전을 등록한다. 

 

 이제 n번째 버전 만드는 방법에 대해 알아볼게요. 

 

 

1. 기존에 있던 파일 내용 변경하고 버전 등록


 현재 git은 첫번째 버전이 완성된 상태입니다. 현 상태에서 관리하고 있는 파일 A.txt의 내용을 변경하고 버전을 등록해보도록 하겠습니다. 

 

① 기존 파일 내용 변경하기

  A.txt 파일 내용은 첫번째 버전에서 아무것도 적힌 내용이 없기 때문에 vi편집기를 이용해, "2 version"이라는 내용을 추가하였습니다. 

 

② 기존 파일 변경내용 버전 등록하기

  A.txt 파일의 내용을 변경한 지금 git에서는 어떤 상황일까요? 

 위를 보다시피 이전 버전에 포함된 파일의 경우 git에서는 지속적으로 traking을 진행합니다. 따라서 A.txt 파일이 첫 번째 버전 대비해서 수정(modifed)되었다고 표기해 주는 것이죠. 이와 같이 A.txt의 변경된 내용에 대해서 버전을 만들려면 git add를 통해 해당 파일을 stage영역에 보내주고 git commit 명령어를 사용해 주면 됩니다. 쉽죠? :) 

  

 

 

2. 신규 파일을 추가하고 버전 등록


 이번에는 신규 파일을 생성하고 버전을 등록해보도록 하겠습니다. 구동하는 프로그램에 추가적인 파일이 필요하여 생성했다는 가정을 하고 따라 하시면 이해하기 좋으실 거예요. 

 

① 신규 파일 생성

 먼저 신규 파일을 생성해 보도록 하겠습니다. 간단하게 touch B.txt 명령어를 사용하여 만들겠습니다. ll 명령어를 사용해서 B.txt 파일이 생성된 것을 확인할 수 있습니다. 

 

② 신규 파일 버전 등록하기

 버전을 생성할 때는 항상 이전 버전과 다른 점이 있어야겠죠? 이번 case는 새로운 파일이 생성되었다는 것이고요. 이를 확인하기 위해 git status 명령어를 사용해보겠습니다. 

 새로 추가된 파일 B.txt는 untracked 파일입니다. 이전 버전에 포함되지 않았기 때문에 별도로 tracking이 진행되지 않았고 변경된 내용이 있는지 모르는 상태죠. 

 이제 B.txt를 기존 버전 생성하는 방법과 동일하게 git add, git commit을 활용하여 버전을 만들어 보겠습니다. 

 git log를 보면 B.txt add라고 comment 달아놓은 커밋(version)이 보이시죠? 이로써 기존 버전의 파일이 변경되었을 경우와 신규 파일이 추가되었을 경우 버전 만드는 방법에 대해 알아보았습니다. 

 

 혹시 모르시거나 궁금하신 부분이 있으시면 언제든 댓글 남겨주세요. 

 

 

 

 

*Reference

- "지옥에서 온 문서 관리자 깃&깃허브 입문" 이지스버블리싱 - 이고요, 고경희 지음

-

-

 

부족한 글이지만 읽어주셔서 감사합니다. 

 

배경

첫 번째 버전을 만들어 가면서 git이 버전을 어떻게 운용하고 관리하는지 알아보고자 한다. 

 

 

 

1. git init


처음 git을 사용하기 위해선 버전을 만들고 관리하기 위한 폴더를 하나 선정해야 한다. 그리고 해당 폴더에 git init 명령어를 사용하여 버전 관리를 하겠다고 설정해주어야 한다. 

본인은 바탕화면에 tmp_git_1이라는 폴더를 만들고 해당 폴더 안에 파일들을 버전으로 관리하고자 한다.

아래 명령어를 따라하면 git 초기 설정을 할 수 있다. 

$ mkdir tmp_git_1  // tmp_git_1 폴더 생성

$ cd tmp_git_1  // tmp_git_1 폴더로 이동

$ git init  // 해당 폴더 git repository 설정
Initialized empty Git repository in C:/Users/kkc28/tmp_git_1/.git/

$ ll -a  // 폴더 전체를 보면 .git폴더 생성
total 24
drwxr-xr-x 1 kkc28 197609 0 Sep 26 23:55 ./
drwxr-xr-x 1 kkc28 197609 0 Sep 26 23:55 ../
drwxr-xr-x 1 kkc28 197609 0 Sep 26 23:55 .git/

 

 

2. touch A.txt


git repository 설정이 완료되었으면, 버전 관리할 파일을 생성한다. 샘플로 touch 명령어를 사용하여 A.txt파일을 만들도록 하겠다. 독자들은 vi편집기든 여러 편집기를 사용해서 폴더를 작성해도 된다.

 

$ touch A.txt // A.txt 파일 생성

$ ll  // A.txt생성 확인
total 0
-rw-r--r-- 1 kkc28 197609 0 Sep 27 00:04 A.txt


 

 

 

3. git status


버전을 관리할 파일을 생성 완료하였으면, git status 명령어를 통해 상태를 확인한다. 파일들의 상태는 Untracked / Tracked -( modified / Unmodified ) / Staged 이렇게 나눌 수 있다. 각각의 상태는 다음과 같이 설명할 수 있다.


- Untracked : 해당 파일이 추적되지 않는 상태고, 버전 관리가 되지 않고 있는 상태
- Tracked > modified : 해당 파일이 추적되는 상태이고, 이전 버전과 현재 파일이 수정된 상태
- Tracked > unmodified : 해당 파일이 추적되는 상태이고, 이전 버전과 현재 파일의 내용이 같은 상태
- Staged : 해당 파일이 추적되어 있는 상태이고, 해당 파일을 최신 버전으로 업로드 하기 직전 상태

 

 

$ git status
No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
bash: $: command not found
        A.txt

nothing added to commit but untracked files present (use "git add" to track)


위에 상태를 보면 새로 만든 A.txt는 Untracked인 상태이다. 해당 폴더 및 파일은 별도로 버전을 생성한 적이 없기 때문이다. 

 

4. git add, git commit


우리는 A.txt를 신규 버전에 포함된 파일로 등록하려고 한다. 이를 위해선 해당 파일을 stage에 올리고, commit을 해야 한다. 여기서 stage란 가상의 장소로 변경점이 있거나 새롭게 버전에 포함시키려 하는 폴더들을 올리려는 무대라고 생각하면 된다.  

파일을 stage에 올리는 방법은 1) git add <filename> 명령어를 사용한다. stage에 버전으로 등록하려는 파일이 올라가면, 이후 2) git commit -m "<버전을 설명할 수 있는 정보>"로 버전을 생성한다. 

 

*commit은 완료한다는 뜻으로 "어떤 버전으로 이름을 등록하고 버전을 완료한다" 이정도로 이해하면 된다. 

 

$ git add A.txt  // stage에 A.txt올리기


$ git status  // git 상태 확인 -> untracked에서 staged되었다. 아래 changes to commited가 staged의 뜻
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   A.txt


$ git commit -m "first version upload A.txt"  // git commit을 통해 버전 등록
[master (root-commit) 39c17eb] first version upload A.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 A.txt

$ git log  // git 버전 등록 완료 
commit 39c17ebc124b5e5171878dbe1d1293f39fa65132 (HEAD -> master)
Author: 
Date:   Tue Sep 27 00:26:53 2022 +0900

    first version upload A.txt

이상으로 git을 이용해 첫번째 버전을 만들어 보았다. 

 

 

*Reference

- "지옥에서 온 문서 관리자 깃&깃허브 입문" 이지스버블리싱 - 이고요, 고경희 지음

 

부족한 글이지만 읽어주셔서 감사합니다. 

+ Recent posts