[Git & GitHub] Git 명령어

이번시간에는 git 명령어에 대해서 알아보도록 하겠습니다.

 

깃 명령어를 알아야 하는 이유

1.  빠르고 편리하다

GUI 방식인 Sourcetree로 버전을 관리하는 방법을 알았는데 굳이 명령어까지 알아야하는건가요? Sourcetree가 더 직관적이고 편리하니까 깃 명령어보다 많이 쓰지 않나요? 라고 생각할 수 있습니다. 물론 깃 명령어보다 Sourcetree를 선호하는 사람들도 있을것입니다. 하지만 대다수의 개발자는 깃 명령어를 사용할 것 입니다. 왜냐하면 깃 명령어를 사용하는것이 훨씬 더 빠르고 편리하기 때문입니다. 깃 명령어를 익혀두면 일일이 소스트리를 열고 마우스로 버튼을 클릭해서 버전을 관리하는것이 아니라 명령어 한두줄로 간단하게 버전을 관리할 수 있기때문에 훨씬 더 간편합니다.

 

2. 제한된 개발 환경

모든 개발 환경에서 소스트리를 설치할 수 있는 것은 아닙니다. 모든 개발이 그래픽 환경에서만 이루어지는 것은 아니기때문에 가령 CLI 방식에서 개발이 이루어진다고 한다면 Sourcetree를 이용할 수 없기때문에 깃명령어를 이용하여 버전을 관리할 수 밖에 없습니다.

---

본격적인 git 명령어를 다뤄보도록 하겠습니다. 먼저 앞장에서 가볍게 설명하고 넘어갔던 버전을 생성하는 과정의 명령어 먼저 다뤄보도록 하겠습니다.

 

1. git init : 로컬 저장소 만들기

git init은 깃 저장소를 만드는 명령입니다. 저장소를 만드려는 폴더에서 깃 배시를 열어준 후 명령어를 입력해주면 

init

이렇게 메시지가 뜨면서 저장소가 만들어집니다. 해당 폴더의 숨김파일을 확인해보면 .git이라는 폴더가 만들어진 것을 볼 수 있습니다. ( .git 폴더에는 버전관리에 필요한 기본 파일들이 존재 )

 

2. git status : 작업 디렉터리 상태 확인하기

git status 현재 작업 디렉터리의 상태를 알려주는 명령입니다. 깃 배시에서 git status를 입력하면 다음과 같이 나옵니다.

status

메시지를 보면 commit할 파일이 없고 working tree가 깨끗하다고 말해주고있습니다. 이제 디렉터리에 "git_test"라는 텍스트 파일을 만들어준 뒤 다시 명령어를 실행하면

위와 다른 메시지가 나오게됩니다. untracked files:는 깃이 기존에 변경 사항을 추적하지 않은 대상을 나타냅니다. 기존 버전에 관리하지 않던  git_test.txt라는 새로운 파일이 생성되었음을 의미합니다.

 

3. git add : 스테이지 올리기

새로 생성된 파일이 포함된 새로운 버전을 만들기 위해서는 스테이지로 올리는 과정을 먼저 거쳐야 합니다. 그러기 위한 명령어가 git add 입니다. git add [파일명] 형식으로 사용하면 해당 명령어 입력 후 다시 상태를 확인해보면

add

Changes to be committed : 라는 항목으로 파일의 위치가 바뀐것을 볼 수 있습니다. Changes to be committed는 해당 파일이 스테이지에 위치하고 있다는 것을 의미합니다.

 

4. git commit : 커밋하기

스테이지로 올라온 파일로 새로운 버전을 만들기 위해서는 커밋을 해야합니다. 보통 git commit -m "커밋 메시지" 형식으로 명령어를 많이 사용합니다. "first commit "이라는 커밋 메시지로 새로운 버전을 만들어 보겠습니다.

commit

이렇게 출력이 됐다면 새로운 버전이 성공적으로 만들어진 것 입니다. 앞에서 말했던 add와 commit 과정을 한번에 처리해주는 명령어가 존재합니다. git commit -am "커밋 메시지"형식으로 사용하면 됩니다. 대신 조건이 있는데, 깃이 변경 사항을 추적하는 파일에만 사용이 가능합니다. 다시말하면 스테이지에 이미 올라와 있거나 한번이라도 커밋한적이 있는 파일에만 사용할 수 있습니다. 가령 위의 git_test 파일 같은경우 처음 생성 되었을때 untracked files: 의 추적하지 않은 파일로 분류 되었기때문에 git commit -am "커밋 메시지" 명령이 사용이 불가합니다. 하지만 이미 추적하는 파일인데 파일이 수정돼서 modified 상태로 분류 될 경우 해당 명령어 사용이 가능합니다. 제대로 커밋이 됐는지 확인해보고 싶다면 git log 라는 명령어를 사용하면 됩니다.

 

5. git log : 저장소의 커밋 목록을 조회하는 명령어

해당 명령어를 사용하면 커밋 해시, 만든 사람, 커밋이 만들어진 날짜, 커밋 메시지가 출력됩니다.

git log

커밋 해시 우측의 HEAD -> master는 현재 HEAD가 master 브랜치에 있음을 나타냅니다. git log 명령은 여러 유용한 옵션을 제공하는 대표적인 몇개만 알아보도록 하겠습니다.

 

git log --oneline

짧은 커밋해시와 커밋 메시지 제목만을 출력하기 때문에 커밋이 복잡하고 많이 쌓여 있는 상황에서 요긴하게 사용합니다.

git log --patch (-p)

해당 커밋으로 어떤 파일이 어떻게 수정됐는지를 출력합니다.

git log --graph

각 커밋을 그래프의 형태로 출력하는 방법입니다. 

출력 결과 왼쪽에 빨간색 그래프가 생긴것을 볼 수 있습니다. 브랜치가 여러개로 나뉘어지고 합쳐지는 환경에서 --grpah 옵션을 이용하면 브랜치별 커밋의 가독성을 높일 수 있습니다.

 

6. git tag : 태그 추가하기

git tag <태그> 형식으로 사용되며 HEAD가 가리키는 커밋에 태그를 붙이는 명령입니다.

HEAD가 가리키는 커밋이 아닌 특정 커밋에 태그를 붙이려면 git tag <태그> <커밋> 형식으로 명령을 입력하면 됩니다. git log 나 git log --oneline 명령으로 다른 커밋의 해시를 확인해 본후 <커밋>위치에 작성해 주면 됩니다.

 

 

 

참고자료

모두의 깃&깃허브 - 강민철 지음