천천히 꾸준히

 이전 시간에 git reset에 대해 학습했었죠. git reset <커밋 해시>는 해당 해시로 버전을 이동하면서 해당 버전 이후에 만들어진 버전들은 모두 삭제한다는 점이 가장 큰 특징이었는데요. 추가로 --hard 옵션을 추가해야 Working Tree에 있는 파일들까지 해당 커밋 버전에 맞게 변경된다는 점을 꼭 기억하셔야 됩니다. 이번 시간에는 커밋 정보를 삭제하지 않고 이전 버전으로 돌아가는 git revert 명령어에 대해 알아보겠습니다. 

1. git revert

 git revert 명령어는 취소하려는 커밋 해시를 지정해주고 해당 커밋 해시를 취소하게 됩니다. git reset 뒤에 지정하는 커밋 해시로 돌아가는 것과는 다르죠. git revert는 취소하려는 커밋 해시를 지정하면 해당 커밋 해시를 취소하였다는 커밋을 새롭게 만들어 줍니다.(취소한 버전을 새롭게 만든다는 게 git revert의 커밋 취소 원리입니다. ) 쉽게 말해 취소한 이력을 버전을 만들어 기록하는 것이죠.

그럼 이제부터 git revert 사용 방법에 대해 예시를 통해 알려 드리도록 하겠습니다. 

먼저 git log를 통해 현재 커밋들을 확인합니다. 

 $ git log --oneline --graph

그리고, 취소하려는 커밋을 확인합니다. (저는 a 커밋을 취소하겠습니다.)

$ git revert f2e779b

 그러면 중간에 아래와 같이 해당 커밋을 취소하며 변경된 사항과 그 내용을 담은 커밋을 생성하게 됩니다. 해당 내용들을 확인하고 이상이 없으면 ":"를 누르고 "wq"를 통해 저장해주면 해당 커밋을 취소한 새로운 커밋이 생성되게 됩니다. 

남들과 협업을 하게 될 때 git을 사용하게 되는 경우가 있는데 만약 취소나 변경사항이 생길 경우 git reset을 사용하는 것보다 git revert를 사용하는 것이 훨씬 안정적이므로 꼭 까먹지 않았으면 좋겠습니다. 

*Reference

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

-

-

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

 지금까지 저희는 버전을 생성하는 방법에 대해 알아봤습니다. 생성된 버전이 잘못되었을 때 이전 버전으로 돌아가려면 어떻게 해야 할지 알아보겠습니다. 이전 버전으로 돌아가는 명령어는 git reset과 git revert가 있습니다. 그중에서 이번에는 git reset에 대해 알아보겠습니다.

1. git reset

 첫 번째로 배울 명령어는 git reset입니다. git reset <커밋 해시> 는 "해당 커밋으로 돌아가겠다" 라는 의미입니다. 단, 추후에도 말씀 드리지만 reset을 하게되면 돌아가려는 커밋 이후로 생성되었던 버전들은 사라지게 되므로 주의하셔야 됩니다. 

사용 방법은 git reset <커밋 해시>입니다. <커밋 해시> 부분에 돌아가려는 커밋 정보를 적어주시면 되는데요. 아래 예시를 참조하시면 좀 더 이해가 쉬울 거예요. 

1) 먼저 원하는 커밋 정보를 찾기 위해 git log --oneline --graph 명령어를 사용하였습니다.

2) git reset 70aa89f 명령어를 사용하여 원하는 버전으로 되돌리기

3) log 정보를 한번 더 사용해보면 head는 70aa89f 커밋으로 이동되어있고, 그 이후에 작성되었던 버전들은 없어져있는 것을 볼 수 있습니다. 

여기서 중요한 사실은 이동한 버전 이후에 생성된 버전은 모두 없어졌다는 점과 커밋은 돌아갔으나, Working Tree의 파일 내용은 변경이 되지 않았다는 것입니다.  cat명령어를 사용하여 A.txt 파일 내용을 살펴보면 파일의 내용은 그대로임을 알 수 있습니다.  

 우리는 git reset <커밋 해시>는 default로 원하는 커밋 해시로 돌아가나, 파일의 내용까지 변경하지 않는다는 것을 알 수 있는데요. 파일의 내용을 해당 커밋의 내용으로 변경하는 방법에는 두 가지가 있습니다. 첫 번째는 git reset에 옵션을 추가하는 방법 : git reset --hard <커밋 해시> 두 번째는 git restore <file name>을 통해 수정 사항을 삭제하는 방법입니다. 

 첫 번째 방법 git reset --hard <커밋 해시> 예시를 보여드리겠습니다. 

git reset --hard <커밋 해시>를 사용하면 아래 보시는 바와 같이 A.txt의 내용이 변경된 것을 볼 수 있습니다. --hard 옵션을 넣게 되면 해당 커밋으로 변경되며 파일 수정사항 또한 해당 커밋으로 변경되게 됩니다. 

추가로, git reset 옵션에 대해 적어놓으니 reset사용 시 참고하시면 좋을 것 같습니다. 

 두 번째 방법인 git restore <file name>은 현재 커밋과 Working Tree의 파일 간 변경사항이 있을 때, file의 변경 사항을 커밋에 저장되어있는 파일 내용으로 되돌려 주는 명령어입니다.

아래 예시와 같이 현재 커밋에 수정된 파일 A.txt 있을 때 git restore <file name>을 사용해주면 A.txt의 "add context"라는 내용이 현재 커밋에 저장된 A.txt의 내용으로 변경됩니다.(현재 커밋에서 A.txt 파일에는 아무 내용이 없으므로 안 읽힘)

*Reference

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

-

-

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

 지난번 git의 구조에 이어 git의 파일 상태에 대해서 알아보도록 하겠습니다. 

git의 구조에 대해 궁금하신 분들은 아래 페이지 참조 부탁드립니다.

2022.10.04 - [프로그래밍/GIT] - (1-5) git 버전 관리 - git의 원리(git의 구조)

git의 파일상태

 git에서 버전을 만들 때 가장 중요한 것이 무엇일까요? 최신 버전과 현재 버전의 차이를 아는 것이겠죠? 동일한 파일의 내용이 변경되었는지, 새로운 파일이 추가된 것은 없는지, 추가적으로 어떤 파일을 새로운 버전으로 등록할 것인지...

 이러한 내용을 파악하기 위해 git에서는 파일의 상태를 5가지로 구분하여 정의합니다.

1) Tracked 

2) Untracked

3) Modified

4) Unmodified

5) Staged

 각각의 파일 상태에 대해 정의하고 어떤 식으로 해당 상태가 생성되는지 예시를 통해 파일 상태를 설명드리겠습니다. 

1) Tracked

 Tracked는 말 그대로 파일이 추적되고 있는 상황입니다. 이전에 커밋을 통해 버전이 생성되면, git은 새로운 변경사항에 대해서 대응하기 위해 최신 버전의 파일 상태를 알고 있습니다.  따라서 추적되는 파일은 수정되었는지, 수정이 되지 않았는지 git에서 알게 되는데 수정된 상태를 modified, 수정된 내용이 없는 상태를 Untracked라고 합니다. 

 먼저 Working Tree에서 특정 버전을 생성함으로써, Unmodified 한 파일 상태에 대해 알아보겠습니다. 

(git commit -ma C.txt에서 -a 옵션은 git add을 commit 명령어에서 바로 사용하겠다는 옵션입니다. ) 

 아래 이미지와 같이 git 상태를 보게 되면(git status), 해당 브랜치에 working tree가 clean 하다고 나옵니다. 이는 git이 Working Tree에 있는 파일을 모두 보고 있는데 변경되거나 새로 생긴 파일이 없음을 뜻합니다. Tracked > Unmodified 한 파일 상태인 거죠.

git commit -ma C.txt

 다음으로는 Tracked > Modified 파일 상태에 대해 알아보겠습니다. 

Modified 한 파일 상태를 보기 위해선, 현재 Working Tree에 최신 커밋 대비 변경된 내용이 있는 파일이 있어야겠죠?
따라서 파일 C.txt에 대한 내용을 변경해보겠습니다. (아래 그림 참조) vim편집기를 사용하여 C.txt를 수정하고 git status을 보겠습니다. modified : C.txt라는 문구가 떠있습니다. git은 최신 커밋에 들어가 있는 파일들에 대해 추적을 하고, 변경 상항이 생긴 파일을 확인하여 수정된 폴더라는 것을 알려주게 됩니다. C.txt는 Tracked > modified 한 상태인 거죠

2) UnTracked

 Untracked란 뜻은 말 그대로 추적을 안 하고 있다는 것인데요. Working Tree에 새롭게 생성된 파일은 이전까지 버전에 등록된 적이 없기 때문에 내용이 변경되더라도 git에선 그 사실을 알 수가 없습니다. 이와 같은 상황이 Untracked인 거죠.

 아래와 같이 touch 명령어로 D.txt 파일을 새롭게 생성해주면 D.txt는 현재 변경사항이 추적되지 않는 파일 상태가 됩니다. (Untracked file)

3) Staged

 마지막으로 Staged에 대해 알아보겠습니다. Tracked > modified와 Untracked 한 파일 상태들은 버전이 생성되어 관리되고 있지 않습니다. 불안정안 상태죠. 따라서 해당 파일들의 변경사항이나 새롭게 생성된 파일이 앞으로 관리가 필요하고, 적용이 되어야 한다면 해당 파일들에 대해서 버전을 생성해줄 필요가 있습니다. 이때 사용되는 파일의 상태가 Staged입니다. Staged file은 "변경되거나(Modified) 새로 추가된(Untracked) 파일들을 버전으로 만들고 관리할 거야!"라는 뜻을 갖습니다.  이전 시간에 같이 학습한 바와 같이 git에서는 버전으로 관리할 파일과 그렇지 않은 파일들을 구분 짓기 위해 관리할 파일들을 먼저 Stage영역에 올린다고 한 내용 기억하시나요? 그때 git add 명령어를 사용하여 버전으로 만들기 원하는 파일들을 선택하고 stage영역에 올리는데 올려진 파일들은 Staged 한 상태가 되는 것이죠. 그리고 git commit으로 최신 버전화 하게 됩니다.

 이와 같이 git file의 상태를 살피는 것만으로도 git에서 파일들을 어떤 식으로 운영하고 버전으로 만드는지 이해할 수 있습니다. 그리고 이는 git을 사용하는데 많은 도움이 될 거라 충분히 학습하시면 좋을 것 같습니다. 

추가적인 질문이나 궁금하신 점 있으면 언제든 댓글로 남겨주세요. 

*Reference

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

-

-

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

 이전에 대략적으로 설명을 드렸습니다만, 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

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

-

-

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