자주 사용하는 Git의 다양한 명령어 A to Z

 

파일 목록을 볼 때 숨겨진 파일을 표시하는 -a와 옵션과 파일의 상세 정보를 표시하는 -l 옵션을 함께 사용

$ ls -al

 

add와 commit 메시지 남기기를 동시에 할 수 있는 명령어

단, -a 명령어를 사용하기 전에 주의해야 할 점은
이전에 한 번도 add가 되지 않아 한 번도 버전 관리 하에 들어가지 않았던 파일에게는 먹히지 않는 명령어다!

$ git commit -am "commit message"

 

방금 commit 한 내용을 수정하고 싶을 때 (push 하기 전)

$ git commit --amend

 

로컬 저장소에서 작업한 내용을 원격 저장소로 업로드할 수 있는 명령어.

$ git push

 

원격 저장소의 내용을 로컬로 가져올 수 있는 명령어.

$ git pull

 

어떤 동작을 하기 이전으로 돌아갈 수 있다.

예를 들어 merge를 수행하였을 때 conflict가 난다면 merge를 하기 전 상태로 돌아갈 수 있다.

$ git merge --abort

 

---

원격 저장소의 내용을 로컬 저장소로 가져오기

 

pull VS fetch

결론부터 말하자면 웬만하면 pull 쓰면 된다. fetch 쓸 일 거의 없다!

 

 

fetch를 사용하여 원격 저장소의 내용을 로컬로 받았을 때

로컬 저장소는 마지막으로 작업한 commit에 여전히 HEAD가 존재한다. 즉, 아무런 변화도 존재하지 않는다.

반면, 원격 저장소는 최신 commit을 가지고 있다.

 

따라서 fetch를 사용하면 원격 저장소의 내용을 로컬에 병합하지 않고 가져오기만 한다.

이로 인해 원격 저장소의 내용과 로컬 저장소의 내용상 차이점을 아래 명령어를 통해 비교해볼 수 있다.

$ git diff master origin/master

 

만약 비교 후 이상이 없다면 merge 명령어를 통해 병합해준다.

병합해주면 로컬 저장소와 원격 저장소가 같은 commit을 가리키게 되며,

이때의 상태가 git pull 해주었을 때와의 상태와 동일한 것이다.

$ git merge origin/master

 

---

내용 변경 사항 확인하기

 

log & diff

log

git의 log를 보여준다. commit 내역!

$ git log

 

[참고] git log를 사용하여 commit내역 체크 후, 해당 commit 내역으로 checkout 할 수 있다.

commit 3의 고유주소를 복사하여 checkout 해보자.

HEAD가 해당 고유 주소로 checkout된 모습을 decorate을 통해 볼 수 있다.

 

git의 log를 알 수 있음과 동시에 가까운 두 commit의 소스 상의 차이를 알 수 있다.

$ git log -p

 

log내역을 Gistory에서 열어보는 것과 비슷하게 커맨드 창에서 실행할 수 있다.

$ git reflog

 

 

master에는 없고 exp는 있는 내용을 보고 싶다면 아래의 명령어를 사용.

가정: 두 개의 브랜치 master와 exp가 다른 commit 내역을 가지고 있을 때

만약, exp에는 없고 master에는 있는 내용 보고싶다면 반대로 작성하면 됨

$ git log master..exp

 

좀 더 상세히 알고 싶다면 아래의 명령어 사용.

$ git log -p master..exp
혹은
$ git diff master..exp

 

 

diff

특정 두  commit의 내용상 차이점을 알고 싶을 때 사용.

# 알고 싶은 두 개의 commit 고유 주소를 가져온다.
$ git log

# $ git diff {차이를 알고 싶은 commit 고유주소}..{차이를 알고 싶은 다른 commit 고유 주소}
$ git diff d75994027b0d3225559d115e390fe0caed777c0d..b2a70610b4146aeab959d4336c1f6d07f051d44e

 

[참고] commit의 고유한 주소란 아래의 빨간 박스를 가리킨다.

 

 

추가적으로..

현재 각 브랜치들의 commit상황을 시각적으로 보고 싶을 때.

--all : 모든 브랜치들을 (혹은 --branches)
--decorate : 브랜치가 어느 commit에 위치해있는지
--graph : 그래프로 보여준다.

$ git log --all--decorate --graph

 

위 내용을 좀 더 간단히 보고 싶다면 --oneline을 뒤에 추가해준다.

$ git log --all --decorate --graph --oneline

혹은

$ git log --branches --decorate --graph --oneline

 

---

과거 commit으로 돌아가기

 

reset VS revert

 

reset

commit 5와 commit 4를 log내역에서 삭제하고 commit 3을 최신 상태로 하고 싶을 때

 

우선 commit 3의 commit 고유 주소를 복사하자.

그다음 아래 명령어를 실행.

# $ git reset {commit 고유 주소} --hard
$ git reset d75994027b0d3225559d115e390fe0caed777c0d --hard

 

추가적으로..

만약 reset을 되돌리고 싶다면 아래 명령어를 사용하자.

$ git reset --hard ORIG_HEAD

[참고] ORIG_HEAD
 - reset을 하기 전의 commit내용이 적혀있는 곳.
 - HEAD의 위치를 변경하는 위험한 명령(예를 들면 reset)을 수행할 때, 쉽게 이전 HEAD상태(이전 commit 고유 주소)로 돌아오게 하기 위해 이전 commit 고유 주소를 저장해둔 곳.
 - 만약 옵션을 따로 지정하지 않고 git reset ORIG_HEAD만 하게 된다면 default로 --mixed가 실행된다.

 

🔽 reset 참고

Git reset의 옵션(soft/mixed/hard)

 

revert

reset과 다르게 commit내역을 log상에서 날려버리지 않고 새로운 내역으로 생성하는 명령어.

 

---

병합하기

 

merge VS rebase

보통 merge가 더 쉽고 간단하며 안전한 방식의 병합이다.
하지만 상황에 따라 rebase를 써야 하는 상황이 존재한다.

 

 

merge를 사용하던 rebase를 사용하던 성공적으로 병합한 뒤 얻는 결과에 대해서는 둘 다 같다.

단, merge의 경우에는 히스토리가 병렬로 가지를 치며 나아가기 때문에 복잡하게 보인다.

반면에 rebase는 가지 하나 없이 일렬로 히스토리가 나아가기 때문에 히스토리를 파악하기가 좋다.

 

merge

feature와 master는 3-way-merge 방식으로 자동으로 병합된다.

이때 커밋 로그는 feature와 master 모두를 공통의 조상으로 하는 새로운 커밋 로그로서 만들어진다.

 

rebase

우선 feature입장에서의 base는 feature 브랜치가 파생된 위치다.

즉, master와 feature가 공통으로 가지고 있는 commit 위치.

이때 rebase를 실행시키면 feature의 base가 master 브랜치의 최신 커밋으로 위치가 바뀐다.

 

추가적으로 rebase는 다른 사람에게 공유하지 않은 commit에 대해서만 사용해야 한다.

예를 들어 git pull을 받아 작업을 내 로컬에서 하던 도중 필요에 의해 rebase를 사용한 뒤 원격 저장소에 push 하는 것은 ok.

그러나 push 했던 commit을 rebase 하면 안 된다.

 

---

[참고] pull request? merge request?
사실 같은 기능을 가리키는 말이다.
Gitlab에서는 merge request, Github에서는 pull request라 칭한다.