3-1. 기본 명령어

* Git의 Workflow

• working directory : 프로젝트의 파일을 수정, 작업하는 곳 (tracked/untracked)
  • Git이 트래킹하고 있는 파일(이미 알던 파일)이면 tracked
    • 지금 시점에서 수정함 : modified
    • => modified만 staging area로 이동
    • 이전 버전과 비교해서 수정이 되지 않았음 : unmodified
  • 새 파일이거나 기존 프로젝트에서 Git을 초기화하면 GIt이 파일에 대한 정보가 아예 없음 -> 트래킹되지 않았으므로 untracked
• staging area : 어느 정도 작업하면 버전 히스토리에 저장할 준비가 된 파일을 옮겨놓는 곳
• .git directory : staging area에서 commit을 하면 Git 버전의 히스토리를 저장하고 있는 곳 (=git repository)

- .git directory에서 저장된 버전들은 checkout이라는 명령어를 이용해 working directory로 이동할 수 있음

- 예기치 못한 상황으로 인한 데이터 손실을 대비하여 local 뿐만이 아니라 Github와 같은 서버에 push라는 명령어를 이용하면 나의 git directory를 서버에 업로드가 가능하다. 반대로 서버에서 local로 다운받을 때는 pull 명령을 이용한다.

(로컬 -> 서버 : push / 서버 -> 로컬 : pull)

- 각각의 commit에는 스냅샷 된 정보들을 기반으로 고유한 해쉬코드가 부과됨 

 

 

 

* add : 로컬 파일들을 추가 (tracking 하여 staging area로 갈 수 있게 해줌)

<tip> 터미널에서는 ↑방향키를 누르면 가장 최근에 사용한 명령문을 불러올 수 있다.

오른쪽 사진은 그 상황

 

- git status : 현재 파일의 상태를 확인함.

오른쪽 사진의 상태는 이렇다↓

지금 master branch에서 작업 중이며, 아직 commit된 것이 없고, untracked인 파일이 세 개 있다.
아직 commit하려고 추가된 건 없으나 untracked인 파일이 존재한다.
git add를 사용하면 tracking 할 수 있다.

 

git add a.txt

지금 commit된건 없지만,
commit할 수 있는 새로운 파일 a.txt가 있다. 

git add b.txt c.txt

 

위와 같이 쓰면 b.txt와 c.txt를 tracking할 수 있고,

git add *.txt 로 작성하면 txt 파일을 모두 tracking할 수 있다.

 

여기서 a파일에 내용을 추가했다. 그렇다면 a파일의 상태는 modified로 되어 있을 것이다.

즉 tracking은 되어 있지만 수정 전의 a.txt가 staging area에 있는 것이며 수정 후의 a.txt는 working directory에 tracked인 채로 남아 있다. 그렇다면 이 수정된 a.txt를 다시 tracking하여 staging area에 옮기면 된다.

그리고 왼쪽 캡쳐에서 git rm --cached <file> ...을 이용하여staging area -> working directory로 이동할 수 있음을 확인할 수 있다.

 

git rm --cached *를 입력하면 staging area에 있는 모든 파일들을 한번에 working directory로 옮길 수 있다.

 

 

위에서 다시 staging area => working directory로 돌려 보냈으므로 다시 tracking을 한다.

 

지금은 a.txt, b.txt, c.txt가 모두 있는 것을 확인할 수 있고,

git status에도 모두 staging area에 있는 것을 확인할 수 있다.

 

이 때 a.txt를 삭제하면 tracking된 파일은 어떻게 되는 걸까?

 

a.txt를 삭제하면 당연히 로컬에는 b.txt와 c.txt만 존재한다.

 

그리고 git의 상태를 확인해보면,

 

삭제된 a.txt는 디렉토리에 존재하지 않기 때문에

staging area에 추가되지 않았다. 

 

git add . 를 입력하고, git의 상태를 확인하면

 

모든 파일을 포함해 git staging area에 추가된 것을 볼 수 있다. *과 .의 차이가 뭔지 사실 감이 잘 안오지만... 아무튼 그렇구나 하면 될 것같다... 

 

 

 

 

 

* ignore : ignore 뒤에 있는 파일 빼고 tracking하기

- style.css와 log.log 파일을 새로 추가해주고, git의 상태를 확인

 

- 위에서 이미 트래킹한 b.txt와 c.txt는 commit될 준비가 되어 있음

 

- 방금 생성한 log.log와 style.css는 아직 untracked 상태

 

- 일단 모든 css파일을 tracking

 

- 이후 git의 상태를 확인하면 log.log 파일만 아직 트래킹 되지 않은 상태

 

굳이 이렇게 번거롭게 파일 형식마다 하나하나씩 트래킹하기 싫고, log 파일 빼고 나머지 파일들을 모두 tracking 하고 싶다면, ignore을 사용하면 된다.

 

그런데 ignore은 add 처럼 git add 파일 이런식으로 사용하지 않는다.

 

echo로 ignore 하고 싶은 파일을 넣어놓으면, 실제 .gitignore 파일에 해당 파일(여기선 log 파일 형식을 ..)이 들어가있는 것을 볼 수 있다. 그리고 git의 상태를 확인해보면 .gitignore 파일은 트래킹되지 않았지만 .log 파일이 아예 사라진 것을 볼 수 있다! (삭제된 것은 아니다. 그냥 무시당했을 뿐)

 

위의 예시로는 *.log을 써서 log 파일 형식만 넣었지만,

# 특정 파일
log.log
# 특정 파일 형식
*.log
# 특정 디렉토리의 파일들
build/
# 특정 디렉토리의 특정 파일 형식들
build/.log

다음과 같이 이렇게 여러 형식으로 파일들을 무시해줄 수 있다... )

create-react-app 툴을 이용하면 git ignore 파일을 자동으로 생성해주기도 한다.

 

 

 

* status : 현재 상태 확인

위에서도 많이 사용했던 git status.

이 때 -h는 help라는 뜻으로, 도움말같은 개념으로 알면 된다.

 

여기서 --long은 (default)가 표시되어있는데, 그냥 git status라고 입력하면 디폴트, 즉 기본적으로 적용이 된다는 뜻이다.

-s는 이를 간단히 확인할 수 있고, -b는 branch의 관련된 정보를 확인할 수 있다. 

 

상세한 설명은 그냥 git status / 짧은 표시는 git status -s를 붙여주자.

첫번째 사진은 디폴트값인 --long이 적용된 모습, 두번째 사진은 -s (short)를 붙였을 때 적용된 모습.

세번째 사진은 c.txt에 내용을 추가해 비교한 모습이다. 두번째 사진과 달리 c.txt에 M도 붙었다.

• A : 파일이 staging area에 추가된 정보
• M : working directory에서 파일이 수정된(Modified) 상태
• ?? : 아직 tracking되지 않았고, working directory에 있음

 

 

* diff : 정확하게 어떤 파일의 내용이 수정됐는지 비교

git diff

  git diff 뒤에 아무 옵션도 붙이지 않는다면 working directory에 있는 것만 비교해서 확인해 볼 수 있다.

 

  캡쳐의 첫줄을 보면, diff --git 커맨드를 이용했고, 여기서 a는 a.txt가 아닌 이전 버전, b는 바뀐 버전을 말한다. 이 때 이전 버전은 이전의 commit된 버전이나 staging area에 변경된 내용이 있다면 그 이전 버전을 말하는데, 지금까지 commit을 아예 안했으므로 후자의 경우이다.

index는 git 내부적으로 파일들을 참고할 때 사용하는 것이다.

 

# 이전 버전 a/c와 최신 버전(?) b/c를 비교하겠다
--- a/c.txt
+++ b/c.txt
# -1 : 이전 파일(-)의 첫번째(1) 줄, + : 현재 파일 / +1, 2 : 현재 파일의 1, 2줄을 확인해봐라
@@ -1 +1,2 @@ 
 hello world! # 첫번째 줄
+add # + add가 추가되었다
# 만약 add가 삭제되었으면 -add가 빨간색으로 나올 것이다.

 

- git diff --staged : staging area에 있는 파일들을 비교해보고 싶을 때 (staged는 cached와 동의어로 쓰이며, git diff --cached 라고 사용해도 무방하다.)

a/b.txt(이전 버전)과 b/b.txt(최신 버전)을 비교했을 때

 

이전에는 null 이었지만 최신 버전은 b/b.txt이다.

 

-0, 0 +1 : 이전 파일은 없었기에 0, 어떠한 줄도 없기에 0 이지만 새 파일에는 첫 번째 줄에 hello world!가 추가 되었다.

 

c.txt도 마찬가지.

 

style.css 파일도 마찬가지이고

첫 번째 줄에 styling이 추가 되었음을 확인할 수 있다.

 

 

터미널로 확인하는 것이 힘들 때 이를 텍스트 에디터로 열어볼 수 있다.

이를 위해 git config --global -e (git config에 global로 설정되어 있는 것들을 edit 모드로 열기) 를 실행해

 

[diff]
	tool = vscode
	# diff tool은 vscode를 이용한다.
[difftool "vscode"]
	cmd = code --wait --diff $LOCAL $REMOTE
	# vscode의 명령어는 code 다음에 터미널에서 기다리고, diff를 이용하고 LOCAL과 REMOTE를 비교한다.

 

다음과 같은 코드들을 추가한다.

 

그리고 git difftool을 입력하고 엔터를 누르면, vscode로 launch 할거냐고 물어보는 말에 y라고 답하면 오른쪽 캡쳐처럼 열어준다. 위에서 봤던 터미널은 문제 푸는 기분인데 확실히 나아진 UI로 확인하니까 눈이 트인다.

 

git difftool 중에서도 staged인 것을 확인해보고 싶을 때, git difftool --staged라고 입력하면 하나하나 친절하게 물어봐준다. y라고 답하면 열어준다.

css파일에 빨간줄이 뜬 이유는 당연히 css 파일 문법에 어긋나게 그냥 막 적었기 때문이다.

 

 

 

* commit : 버전을 등록, staging area에 있던 변경 사항들을 Git repository에 옮겨주는 역할

아무런 없이 git commit을 입력하고 엔터를 누르면 기본 템플릿이 나온다.

 

일단 Title과 Description을 적어주고(내용 없이 진짜 쟤네만 적긴 했지만...) 저장 후 다시 터미널로 돌아가면 커밋 결과를 보여준다.

master (root-commit) >> 즉 master branch에서 커밋됐으며 70385c8은 해쉬코드의 맨 앞 부분만 따서 보여준다. 그리고 Title은 타이틀이다. 3가지 파일들이 변경되었으며, 3가지가 삽입되었음을 보여준다.

히스토리를 확인하기 위해서 git log를 이용해보면

 

commit 뒤에 전체 해쉬코드가 나오는 것을 볼 수 있다. 누가 했는지 (Hayeon^^... ), 언제 했는지 (새벽 3시가 넘었네...), 그리고 제목과 설명이 나와 있다. 

지금은 처음 커밋이니 히스토리가 저거 하나 덜렁~ 있지만 처음이 아닌 파일일 때 히스토리가 어떻게 나오는지 보고싶으니까 만만한 c.txt에 'add'를 추가해보자.

 

뒤에 포스팅하는거 다 비친다 ()... 

 

git commit -m "second commit"

저 과정 속에서 commit 뒤의 -m은 message를 뜻하며, 그 뒤에는 전달할 메시지의 내용을 의미한다.

실제로 두번째 히스토리에는 commit 해쉬코드, 만든 사람, commit한 시간이 뜨지만 메시지인 second commit을 확인할 수 있다.

 

하지만 이 과정은 좀 번거롭다고 느낄 수 있다. 굳이 staged 상태로 넣어서 그 다음에 commit을 하지 않고, 지금 working directory에 있는 이 파일을 바로 commit하고 싶을 때는

 

git commit -am "third commit"

 

이렇게 작성한다.

 

commit뒤에 -a는 -add를 , -m은 message를 의미하며 내용은 "third commit".

굳이 여러 문장 쓸 필요 없이 한번에 working directory -> staged area -> .git directory로 이동하는 것이다.

 

git status로 확인해도 모두 깔끔하게 commit된 것을 확인할 수 있다.

 

 

 

 

 

- commit 시 팁

• application을 만들 때, git의 히스토리에 전체적인 application을 만들어 하나의 commit으로 저장하는 것은 의미가 없다. application을 조금 더 세분화해 기능 별로, 작은 단위로 넣는 것이 중요하다. 그렇다고 그냥 너무 작게 저장하는 것이 아니라, 알맞은 제목을 붙여 기능별로 정리한다.
• 예를 들면 프로젝트를 초기화, 로그인 서비스 모듈, 사용자 Repository(저장소), 웰컴 페이지, about 페이지, light theme,ark theme 이런식으로 나누어 commit하는 것이 효율적이고 수정하거나 commit 취소하기도 편하다.
• 보통 commit 제목은 현재형 동사로 만들어진다. init, add, fix가 주로 쓰인다.
• 주의할 점은, 예를 들어 commit을 할 때 로그인 모듈에 생긴 crash를 fix했다고 제목을 붙였을 때, 해당 내용은 정말 그 crash한 부분만 고치는 것이 좋다. 기왕 한다고 다른 버그도 고치고, 리팩토링도 하고, 새로운 기능을 넣게 되면 코드 리뷰와 히스토리 확인에도 혼동이 오기 때문이다.