본문 바로가기
Management/GIT

[GIT] 깃(Git) 버전 관리 기본 명령어 (ft. git init / status / add / commit / log / diff)

by 썸머워즈 2022. 10. 6.
반응형

git init

깃 저장소를 초기화하는 명령어이다.

git init 명령어를 실행하기 이전에는 git과 연결된 폴더가 아니기 때문에 npm init처럼 git init을 통해 초기화를 시켜줘야 한다.

git init

이 명령어를 실행하게되면, 해당 폴더에 숨겨진 파일로 .git 이라는 폴더가 하나 생성되는 것을 확인해 볼 수 있을 것이다.

.git이란 폴더는, 파일의 history가 저장되는 폴더이므로 특별한 사유가 있지 않다면 삭제하지 않는 걸 추천한다.

이런 식으로 git init 명령어를 사용하면 .git 폴더 생성과 함께 "master"라는 키워드가 터미널에 표시된다.

git status

저장소의 상태를 체크하는 명령어이다.

git에서 말하는 상태란 untracked, tracked, staged 같은 상태를 말하며, 만약 잘 모르겠다면 git의 컨셉(?)을 먼저 알아두면 이해하기 좋다.

그냥 쉽게 설명하자면 특정 파일이 add 대상자인지, commit 대상자인지 그런 것들을 확인한다고 생각하면 된다.

git status

명령어를 하나하나 체크하기 위해 git init을 한 폴더에 파일을 임의로 추가해준 다음.

git status를 입력하면 다음과 같이 출력된다.

git의 좋은 점은 위 그림처럼 명령어를 안내해 준다는 점에 있다고 생각된다.

친절하게도 commit을 할 파일이 있다면 git add <file>을 입력해서 staged area에 추가하라고 안내해 주고 있다.

git status -s

git status의 옵션 중에 하나인데, 저장소의 상태를 간단하게 체크하는 명령어이다.

git status -s

git status -s 명령어를 입력하면 아래와 같이 출력된다.

그 외에 다른 옵션들도 사용하는지는 모르겠으나 만약 무슨 옵션이 있는지 궁금하다면,

git stats -h 명령어를 입력하거나 공식문서를 확인하는 걸 추천한다.

https://git-scm.com/docs/git-status

 

Git - git-status Documentation

By default, git status will automatically refresh the index, updating the cached stat information from the working tree and writing out the result. Writing out the updated index is an optimization that isn’t strictly necessary (status computes the values

git-scm.com

git add

상태가 변경된 파일들을 대상으로 staged area로 옮기는 명령어이다.

쉽게 말하면, commit 대상자를 선별하는 명령어라고 생각하면 된다.

git add <file>

이 명령어는 위에서 git status를 통해 어떻게 사용하는지 안내를 받았을 것이다.

파일명을 입력하라고 나와있기는 하지만, 하나하나 입력하면 매우 귀찮기 때문에 우리는 다른 방식으로 git add 명령어를 입력해 주도록 하자.

git add .
git add *

이런 식의 명령어를 사용하게 되면 디렉터리에 있는 모든 파일들을 add 할 수 있다.

staged area 파일 수정 및 삭제

만약 저렇게 add를 한 상태의 파일이 수정하게 된다면 어떻게 될까?

a.txt를 수정하고 나서 다시 git status 명령어를 입력해보면 아래와 같이 출력된다.

신기하게도 staged area에는 수정되기 이전의 상태만 저장되어 있기 때문에 이 수정된 상태의 파일 역시 추가해주기 위해서는 다시 한번 git add 명령어를 통해 추가해 줘야 한다.

 

만약 수정하기 이전의 상태만 commit 하고자 한다면 상관은 없지만 수정한 내용도 commit을 하고자 한다면 git add 명령어를 통해 추가해주면 별 문제없다.

 

파일 삭제 역시 동일하다

처음으로 돌아가서 만약 저렇게 add를 한 상태의 파일이 삭제하게 된다면 어떻게 될까?

a.txt를 삭제하고 나서 다시 git status 명령어를 입력해보면 아래와 같이 출력된다.

이 역시 안내해주는 대로 따르기만 하면 별 문제가 없다.

git add . VS git add * (ft. git add -A)

이 두 명령에는 차이가 존재한다고 하는데, 많은 블로그에서 아래와 같이 설명한다.

  • git add * 는 .gitignore파일에 있는 파일들도 staged area에 올린다.
  • git add . 는 .gitignore파일에 있는 파일을 제외하고 staged area에 올린다.

이게 사실일까? 하는 생각에 직접 테스트를 해봤더니 그냥 둘 다 똑같이 잘된다... 뭘까? 다들 어디서 가져온 걸까 출처가 어딜까 궁금하지만 어디서든 출처가 적혀있지 않아서 나도 잘 모르겠다 그냥 둘이 똑같다 뭐가 다른지 모르겠다.

이들이 정리했을 때는 안된 걸까? 지금은 되는 걸까? 둘 다 .gitignore파일에 명시되어 있는 파일들을 제외하고 staged area에 올리는 것을 직접 확인해봤는데 좀 더 다른 점을 설명해 주었으면 좋았을 텐데 관련 내용을 찾기가 어렵다.

(아 이 옵션은 알아냈는데, .gitignore을 무시하려면 -f 옵션을 사용하면 된다.)

 

관련 내용들을 찾아보면서 git add. / git add * VS git add -A의 차이점에 대해 알아냈는데,

git add. / git add * 의 경우 현재 디렉터리에 영향을 받지만, git add -A의 경우에는 stage가 변한 것들을 대상으로 전부 추가해주는 신기한 현상이 발생하였다.

즉, 하위 디렉터리로 들어가서 만약 상위 디렉토리에 변경사항이 있어도 git add. / git add * 는 하위 디렉토리의 변경사항만 staged area에 추가하지만 git add -A의 경우에는 상위 디렉토리 상관없이 그냥 전부 변경된 사항에 있어 추가한다.

 

참고: https://gist.github.com/dsernst/ee240ae8cac2c98e7d5d

 

Compare `git add .` vs `git add -A`

Compare `git add .` vs `git add -A`. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

git commit

드디어 git add를 통해 staged area에 있는 파일들을 commit 하는 시간이다.

이는 작업이 끝났으니 해당 버전으로 commit을 하겠다 라는 명령어이다.

git commit
git commit -m "message"
git commit -am "message"

명령어를 3개나 설명한 이유는 git commit을 그냥 사용하는 경우는 많이 없고, 보통 git commit -m "message" 형식으로 많이 사용한다.

자 이런 식으로 git commit을 하고 나서 git status를 입력하게 되면 commit이 끝났기 때문에 모든 상태가 저장되어 있는 것을 확인할 수 있다.

git commit -am

이 옵션은 git add와 commit을 동시에 하겠다는 옵션이다.

이 -a 옵션을 사용하게 되면 (-a -m을 합친 게 -am 옵션이다.) 주의할 점은 새로 생성된 파일에는 적용이 안된다는 점이다.

새로 생성된 파일의 경우 git add를 통해 선 작업이 필요하고 그 이후에는 git commit -am 옵션을 통해 바로 커밋이 가능하다.

git log

커밋 내역을 확인하는 명령어이다.

git log

이런 식으로 명령어를 간단하게 사용할 경우 아래와 같이 출력된다.

commit의 주체와 시간, 그리고 commit message까지 확인이 가능하다.

git log --online

online 옵션을 사용하면 그냥 사용했을 때보다 더 간략하게 로그를 확인할 수 있다.

git log -p

-p 옵션을 사용하면 이는 git diff와 비슷한 기능을 하는데, git log --online이 간단하게 보여주는 거라면 -p 옵션은 diff와 마찬가지로 매우 상세하게 보여준다.

git log는 좀 중요한 기능이며, 사용자 입맛대로 포맷을 결정해서 사용할 수도 있다.

--graph, --decorate 등의 다양한 옵션이 있으니 아래 공식문서를 통해 익혀보는 것을 추천한다.

또는 옵션을 지정해 놓은 것을 따로 명령어를 지정해 놓고 사용하는 경우도 많다.

(많은 블로거들이 설정 만들어놓은 게 있을 테니 찾아보는 것도 좋을 것 같다.)

https://git-scm.com/docs/git-log

 

Git - git-log Documentation

If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is inserted before the Author: line. This line begins with "Merge: " and the hashes of ancestral commits are printed, separated by spaces. Note that the lis

git-scm.com

git diff

커밋된 최근 버전과 작업 폴더의 수정 파일 사이의 차이를 출력하는 명령어이다.

그냥 쉽게 말하면 어떤 식으로 변경되어 왔는지 상세하게 체크하는 명령어라고 생각하면 된다.

물론 커밋된 게 없으면 당연히 아무것도 출력되지 않는다.

git diff

위에서 commit 한 a.txt를 수정하고 git diff 명령어를 입력하면 아래와 같이 출력된다.

diff 즉, a(이전) 버전의 a.txt 와 b(현재) 버전의 a.txt를 비교한다는 의미이고,

"mine-it-blog"가 추가되었다는 것을 상세하게 알려준다.

 

좀 더 상세하게 파고들자면 head나 hash를 통해 두 commit 사이를 비교할 수도 있다.

https://git-scm.com/docs/git-diff

 

Git - git-diff Documentation

Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes resulting from a merge, changes between two blob objects, or changes between two files on disk. git diff [ ] [--] [ …

git-scm.com

반응형


댓글

TOP