CLI 환경에서 Git 사용하기(명령어 정리) #2

CLI 환경에서 Git 사용하기(명령어 정리) #2

📝 목록

stash
merge
rebase
pull request
show
reset
cherry-pick

 

stash

- stash 뜻: (안전한 곳에) 넣어 두다.
- 작업하던 내용(commit 하기 전의 modified, staged 상태의 파일들)을 임시 저장
- 브랜치에서 작업하다가 다른 브랜치로 변경해야 하는데 커밋은 하고 싶지 않은 경우 사용
- stack처럼 작동(stash, pop)

 

stash 사용 방법

git stash

현재 작업하던 파일을 임시 저장

이 명령어를 입력한 상태에서 status로 확인해보면 변경 사항에 대해 commit을 하지 않았지만 working tree clean 메시지가 출력된다.

 

stash로 임시 저장된 목록 확인

git stash list

 

이는 다음과 같이 출력된다.

$ git stash list
stash@{0}: WIP on master: 3fb7854 cherry pick test

stash 명령어로 임시 저장할 때 마다 {}이 1씩 증가한다.

 

가장 마지막에 임시 저장한 것을 가져오기

git stash pop

 

특정 임시 저장 가져오기

git stash apply <키값>

<키값>에 stash list에 보여지는 {} 안의 정수를 입력한다.

 

stash로 임시 저장한 것 들 모두 날리기(삭제)

git stash drop

 

merge

협업의 핵심. 현재 브랜치에 다른 브랜치의 변경 사항을 합침

merge의 3가지 동작 방식
✔️ fast-forward: 기준 브랜치는 변경이 없고 merge 대상 브랜치만 변경됐을 경우. 단순히 HEAD만 옮겨짐
✔️ 3-way merge: 기준 브랜치와 merge 대상 브랜치가 둘 다 변경됐을 경우. 두 갈래로 나온 변경들을 합쳐서 새로운 커밋을 만듦. = merge 커밋
✔️ squash: 대상 브랜치의 커밋들을 하나의 커밋으로 합침

 

merge 사용 방법

git merge <브랜치 이름>

현재 브랜치에 로컬의 <브랜치 이름>의 변경 사항을 합친다.

 

git merge <리모트 저장소 이름>/<브랜치 이름>

현재 브랜치에 <리모트 저장소 이름>의 <브랜치 이름>의 변경 사항을 합친다.

 

🚨 리모트 저장소의 브랜치와 merge할 때 주의 사항
merge 기준이 되는 로컬 브랜치를 pull 또는 fetch를 통해 최신화 시킨 후 merge해야 한다.

 

📝 현재 브랜치는 git branch 명령어로 확인할 수 있으며 브랜치 변경은 git checkout <브랜치 이름>으로 할 수 있다.

 

rebase

- merge와 비슷하게 다른 브랜치와 병합하는데 사용할 수 있다.
- 커밋 여러 개를 수정하는데 사용할 수 있다.

 

1) rebase 사용 방법 - 다른 브랜치와 병합

git rebase <브랜치 이름>

• 기능적으로는 merge와 동일
• 내 브랜치의 커밋을 대상 브랜치의 위(다음)으로 생성함
• 깔끔한 로그를 유지할 수 있음

 

2) rebase 사용 방법 - 커밋 수정

 

• 🚨 주의
  • push 해서 누군가 사용하고 있는 커밋을 rebase 하면 안됨
  • 해당 커밋을 기반으로 작업을 했을 텐데 그 기반을 바꿔 버리는 것
  • push를 했더라도 아직 merge되지 않았고 다른 사람이 사용하지 않는 브랜치라면 (feature 브랜치 등) 마음대로 rebase를 해도 무방
• -i: 대화형 모드
• 커밋 목록에서의 옵션
  • p, pick = use commit
  • r, reword = use commit, but edit the commit message
  • e, edit = use commit, but stop for amending
  • s, squash = use commit, but meld into previous commit
  • f, fixup = like "squash", but discard this commit's log message
  • x, exec = run command (the rest of the line) using shell

 

 

rebase 명령어와 -i, f(fixup) 옵션을 사용해서 다음 세 개의 커밋(b6b6519, 914aae1, 9454338)을 하나의 커밋으로 합쳐보자.

$ git lg
* b6b6519 - (2초 전) commit 3 - Yoon (HEAD -> master)
* 914aae1 - (10초 전) commit 2 - Yoon
* 9454338 - (22초 전) commit 1 - Yoon

 

git rebase -i @~3

rebase 명령어를 대화형 모드(-i)로 실행하고 최근 3개 커밋을 수정한다(@~3)는 인자를 지정한다.

@는 HEAD와 동일하다.

즉 위 명령어는 git rebase -i HEAD~3과 같이 입력한 것과 동일하다.

 

위 명령어를 실행하면 다음과 같은 내용이 편집기로 열린다.

pick 9454338 commit 1
pick 914aae1 commit 2
pick b6b6519 commit 3

# Rebase 3fb7854..b6b6519 onto 3fb7854 (3 commands)
...

 

각 커밋의 맨 앞의 pick을 'f'로 변경하고 저장한다.

pick 9454338 commit 1
f 914aae1 commit 2
f b6b6519 commit 3

# Rebase 3fb7854..b6b6519 onto 3fb7854 (3 commands)

 

다시 git log를 보면 commit 1만 남고 commit 2, 3은 없어진 것을 확인할 수 있다.

$ git lg
* 8d7da7f - (5분 전) commit 1 - Yoon (HEAD -> master)

 

3) rebase 충돌 처리

rebase를 사용해서 자동 merge 중 충돌이 발생하면 다음 세 가지 옵션을 통해 처리할 수 있다.

 

• --abort : rebase를 중단. 원래 상태(rebase 명령어 입력 이전)로 돌아감
• --continue : rebase를 계속 진행. 다음 단계로 넘어감
• --skip : 대상 브랜치의 내용으로 적용

충돌난 파일을 수정하고 해당 파일을 add 후 --continue를 해야 한다.

즉, 다음 순서로 명령어를 입력한다.

git add <충돌 파일>
git rebase --continue

 

pull request

- GitHub 제공 기능
- 실무에서 코드 리뷰, 코드 정적 분석 등을 하고난 뒤 merge하기 위해 사용

 

1) pull request 사용 방법

브랜치를 새로 따서 작업 후 push까지 하고나서 GitHub 저장소에 가보면 아래와 같은 버튼이 활성화된다.

Compare & pull request를 클릭한다.

 

Create pull request를 클릭한다.

 

pull request를 생성하고 나면 저장소의 Pull requests탭의 숫자가 갱신된다.

이 화면에서 코드 리뷰 등을 진행하고 최종적으로 master 브랜치와 merge하려면 Merge pull request를 클릭한다.

 

merge 완료 화면

 

2) pull request 충돌 처리

생성된 pull request의 변경 사항이 master 브랜치와 충돌이 나서 자동 merge가 불가능한 경우 처리를 해주어야 한다.

GitHub에서 Resolve conflicts 기능을 지원하지만 사용하지 않는 것이 좋다고 한다.

따라서 이런 경우 로컬로 돌아와서 IDE로 코드를 편집한 뒤 git merge 또는 rebase를 사용해서 충돌을 처리하고 브랜치를 다시 push 한다.

 

show

커밋 정보 보기

 

HEAD 커밋 보기

git show HEAD
git show @

HEAD와 @는 같다.

 

HEAD 기준 한 커밋 이전 보기

git show HEAD~
git show HEAD^
git show @~
git show @^

네 개의 명령어는 모두 같다.

 

HEAD 기준 3 커밋 이전 보기

git show @~3

 

reset

1. 상태를 이전 커밋으로 reset 시킴
옵션에 따라서 몇 커밋 이전 / 어느 단계(Staged, Modified, Unmodified)까지 reset 할지를 결정

2. add(Staged) 명령 취소

옵션
✔️ --soft: commit만 되돌림 (Staged 상태가 됨)
✔️ --mixed(기본값): commit, add까지 되돌림 (Modified 상태가 됨)
✔️ --hard: commit, add, 워킹 디렉토리까지 되돌림 (Unmodified 상태가 됨)

--hard 옵션을 사용해서 reset하면 git 자체적으로는 복구할 수 없기 때문에 혼자 쓰는 브랜치에서만 사용하도록 한다.

 

HEAD 기준 한 커밋 되돌리기

git reset --soft @^

--soft 옵션을 사용했으므로 되돌린 커밋의 파일들은 다시 staged 상태가 된다.

 

HEAD 기준 세 커밋 되돌리기

git reset @~3

옵션을 지정하지 않았으므로 --mixed가 기본값으로 사용되어 되돌린 커밋의 파일들은 modified 상태가 된다.

 

add 명령 취소하기

git reset @ <파일명>
git reset HEAD <파일명>

git reset @ 또는 git reset HEAD 명령으로 add를 취소할 수 있다.

즉 add 명령으로 인해 staged 상태가 된 파일을 unstaged한 상태로 되돌린다.

 

cherry-pick

다른 브랜치의 커밋을 현재 브랜치로 가져옴

 

git cherry-pick <커밋 해시값>

 

cherry-pick은 잘못된 브랜치에서 작업 후 커밋까지 하였을 때, 원래 작업해야할 브랜치에서 해당 커밋을 가져오기 위해 유용하게 사용할 수 있다.

cherry-pick은 커밋을 가져오기만 할 뿐 원래 브랜치에서 커밋 reset은 하지 않는다.

 

Related

• CLI 환경에서 Git 사용하기(명령어 정리) #1

 

References

• git-scm.com/book/ko/v2/Git-브랜치-브랜치와-Merge-의-기초
• github.com/HwangNara/git-class/blob/master/beginner/README.md