GIT 정리

출처: 코드잇 git강의(강추)

git reset

• staging area에서 파일 제거하는 명령어.
• 특정 파일을 수정하고 staging area로 올렸는데(=add 했는데) 수정 내용이 잘못되서 staging area에서 내리고 싶을 때(=add 취소하고 싶을 때) 사용하는 명령어이다.
• git reset file_name
• 이렇게 하면 add가 취소된다.

예시

1. git_practice.py파일을 만들고 a = 1 을 적은뒤 add, commit한다.
2. git_practice.py파일에 b = 2 코드를 추가하고 add까지 한다.
3. 이때 갑자기 변경이 생겨, b = 2 부분을 커밋에서 제거해야 한다고 치자.
4. 이를 위해 git reset git_practice.py 명령어를 친다. 이렇게 하면 staging area에서 b = 2 부분이 사라진다.
5. working dir에는 변경 사항이 그대로 남아 있으므로 git_pracetice.py에 들어가서 b = 2부분을 지워주면 된다.

collaborator

• public repo기준으로, 누구나 내 repo를 볼 수 있고 pull 받을 수도 있다.
• push는 주인만이 할 수 있다.
• 다른 사람도 내 repo에 push할 수 있게 하려면 아래처럼 추가 설정을 해줘야 한다.
• 깃허브 레포 -> settings -> Manage access -> Invite a collaborator

git log

• git log: 깃 로그 보기
• git log --pretty=oneline: 깃 로그 간략하게 한 커밋 당 한 줄로 보기
• git show <commit id>: 해당 커밋에 어떤 변화가 있었는지 상세하게 보여줌.
  • 참고로 커밋 아이디 값은 엄청 긴데, 이걸 전부 다 쓸 필요는 없다. 앞 몇자만 써도 (중복만 없다면) 잘 인식한다.

최신 커밋 수정하기

• git commit --amend
• 어떤 파일에 a = 1 이라고 쓴 뒤 add a = 1이라는 커밋 메세지를 남겼다.
• 이 커밋을 수정하고 싶다. 파일 내용은a = 2로, 커밋 메세지는 add a = 2로.
• 파일로 가서 a = 2로 수정하고 add까지 한다음 git commit --amend명령어를 실행해서 새로운 커밋메세지를 남기면, 새로운 커밋이 가장 최신 커밋을 대체한다!
• 참고로 커밋 아이디로 바뀐다.

커밋 메세지 가이드라인

참고) 커밋메세지에 담기는 정보 3개

(1) 커밋을 한 사용자 아이디
(2) 커밋한 날짜, 시간
(3) 커밋 메시지

커밋 메세지의 제목과 상세 설명 사이에는 한 줄 띄우기

• 아래 예시 참고.

Add multiply function

caculator.py supports 3 functions now

커밋 메세지 뒤에 온점(.) 붙이지 말것

커밋 메세지의 제목은 capitalize

커밋 메세지는 명령조로 작성할 것(Fix it / Fixed it)

커밋 상세에 담기면 좋은 내용

• 커밋 이유
• 어떤 문제가 있었는지
• 적용한 해결책이 어떤 효과를 가지는지

하나의 커밋에는 하나의 수정사항, 이슈만 담기게 하기

• 회사별로 어떤걸 하나의 이슈로 볼지는 케바케. 하지만 너무 많은 내용이 담기지 않게 할것.

전체코드 실행시 에러 발생하지 않는 상태에서 커밋할 것.

alias 적용

-import numpy as np 처럼 git 커맨드도 별명을 지어줄 수 있다.

• 아래 명령어는 git log --pretty=oneline 에 git history라는 별명을 지어준다. 긴 깃 명령어를 줄이고 싶을 때 유용.
• git config alias.history 'log --pretty=oneline'

두 커밋(or 브랜치) 비교 (git diff)

• git diff <더 오래된 커밋 아이디> <더 최신 커밋 아이디>
• git diff <branch a> <branch b>

HEAD의 의미

• HEAD는 특정 커밋을 가리키며, HEAD가 가리키는 커밋에 따라 working dir이 구성된다.
• 보통 HEAD는 가장 최근에 한 커밋을 가리킴.
• 만약 HEAD가 과거 커밋을 가리키면 working dir(코드내용)도 달라진다.

git reset (HEAD변경하기, 과거 커밋으로 돌아가기)

• git reset --hard 과거 커밋 아이디
• 이렇게 하면 과거 커밋으로 돌아간다. 이를 HEAD가 변경된다고도 말할 수 있다.

git reset 옵션(soft, mixed, hard)

• git은 working dir, staging area, repository 총 세 작업영역이 있다.
  
• hard옵션을 쓰면 특정 커밋으로 돌아간 뒤 이후 내용들은 전부 사라진다. (복구 불가능).
• 따라서 신중하게 써야한다.
  

tag

• 주요 버전의 시작점이 되는 커밋에 태그를 달아 프로젝트 이력 파악에 도움이 되게할 수 있다.
• git tag [태그 이름] [커밋 아이디]: 특정 커밋에 태그 부여
• git tag: 태그 리스트 확인

Branch

브랜치 삭제

git branch -d <브랜치 명>

merge

• A 브랜치의 작업내용(커밋)을 B 브랜치에도 반영하고 싶을 때 사용
• git merge main: main브랜치의 내용은 현재 위치한 브랜치에 반영.

conflict

• merge과정에서 conflict가 났다면 아래 둘 중 하나로 해결.
  1. confilict 코드 수정 후 add, commit
  2. git merge --abort merge취소.

origin

git remote add origin https://github.com/blahblah.git

• remote레포를 등록하는 명령어.
• remote: remote 레포 관련 작업할 때 쓰는 명령어
• add: 새로운 리모트 레포지토리를 등록하겠다는 뜻.
• origin: origin뒤에 나오는 주소를 origin이라는 이름으로 등록하겠다는 뜻.
  • 이 명령어를 통해 뒤의 긴 주소를 origin으로 나타낼 수 있음
  • 꼭 origin일 필요는 없지만 관례화 되있는 표현임.
  • git remote add banana https://github.com/blahblah.git로 해도 무방.

git push -u origin master

• 로컬 레포 master 브랜치의 내용을 origin이라는 remote repo의 master로보낸다는 뜻.
• 만약 리모트에 master브랜치가 없다면 브랜치를 생성하고 푸쉬함.
• u 옵션
  • --set-upstream 옵션의 약자
  • 로컬 레포에 있는 master 브랜치가 origin에 있는 master 브랜치를 추적하는 걸로 설정됨.
  • 추적(tracking)은 로컬 레포의 한 브랜치가 리모트 레포의 한 브랜치와 연결되어 그것을 계속 바라보는 상태가 되는 것.
  • 이렇게 맺어진 연결 상태를 tracking connection이라 부름.

    로컬 레포지토리에 A라는 브랜치가 있고,
    리모트 레포지토리에 B라는 브랜치가 있을 때
    이런 tracking connection이 서로 맺어진 경우,
    B 브랜치를 A 브랜치의 upstream branch라고 합니다.
    지금은 구별하기 위해서 A와 B라고 표현했지만 보통은 같은 이름인 경우가 대부분입니다.
    이렇게 tracking connection이 한번 설정되고 나면,
    사용자가 현재 master 브랜치에 위치해있을 때,
    git push 라고만 써도 자동으로 리모트 레포지토리의 master 브랜치를 대상으로 git push가 동작하고,
    git pull 라고만 써도 리모트 레포지토리의 master 브랜치를 대상으로 git pull이 동작합니다.
    사실 --set-upstream(-u) 옵션을 주지 않아도 그 후에 git push와 git pull을 할 수 있기는 합니다. 하지만 맨 처음에 이 옵션을 주지 않으면 tracking connection이 없기 때문에 나중에 git push를 하고 싶을 때 git push origin master:master 이런 식으로 적어줘야 합니다. 여기서
    origin은 리모트 레포지토리를 나타내고,
    master:master에서 더 먼저 나오는 master는 로컬 레포지토리의 master 브랜치(~에서)/더 뒤에 나오는 master는 리모트 레포지토리의 master 브랜치(~으로)를 나타냅니다.
    그러니까 tracking connection이 없으면 매번 이런 식으로 git push를 해줘야 합니다. git pull도 마찬가지로 이런 식의 복잡한 표현이 필요하게 됩니다.
    그러니까 그냥 처음부터 tracking connection을 설정하고 그 이후부터는 git push, git pull이라고만 써서 편하게 푸시와 풀을 하는 게 좋겠죠? 이게 바로 제가 맨 처음에 로컬 레포지토리의 내용을 리모트 레포지토리로 보낼 때 -u라는 옵션을 썼던 이유입니다.
    

HEAD와 Branch의 관계

Branch

• branch는 코드를 관리하는 하나의 흐름
• 사실상 특정 커밋을 가리키는 존재이며 이를 포인터라고 명명.

HEAD

• head는 특정 커밋을 가리키는 존재이며 이를 포인터라고 명명.
• HEAD가 가리키는 커밋에 따라 working dir의 내용이 바뀜.
• 내부적으로 HEAD가 직접 특정 commit을 가리키는 것은 아니다. HEAD는 branch를 가리키고 이를 통해 특정 커밋을 가리킬 수 있게 된다.
  
  
  
  

정리

• 브랜치(branch)는 커밋을 가리키는 존재(포인터)이고,
• HEAD는 이런 브랜치를 통해 커밋을 간접적으로 가리키는 존재(포인터)

git reset의 비밀

• 과거의 커밋으로 git reset한다고 그 이후의 커밋이 사라지는 것은 아니다. 계속 남아있다.
• git reset은 과거 커밋 뿐만 아니라 현재 HEAD이후의 커밋으로도 할 수 있다.
• git reset시 HEAD가 가리키는 branch가 특정 커밋으로 이동하는 것이다.
  
  

git reset과 git checkout의 차이

reset

• 위 상태에서 git reset 9033을 하면 아래처럼 HEAD가 가리키던 브랜치가 9033커밋을 가리키게 되면서 HEAD도 간접적으로 9033커밋을 가리키게 된다.
  

checkout

• checkout은 구동 방식이 다르다. 똑같은 상황에서 git checkout 9033을 하면 HEAD가 직접 움직인다.
  
• 이렇게 브랜치를 통해서가 아닌 HEAD가 직접 커밋을 가리키는 상태를 Detached HEAD라 부른다.
• 주로 특정 커밋에서 새로운 브랜치를 만들고 싶을 때 detached HEAD를 사용한다.
• 예를 들어 위 상황에서 git branch premium명령어로 9033에서부터 새 브랜치를 만들 수 있다.(아래 그림 참고)
  
• git checkout 명령어로
  • HEAD가 커밋을 직접적으로 가리키게 할 수도 있을 뿐만 아니라
  • 브랜치를 직접 가리키게 만들 수도 있다.
• 위 상황에서 git checkout premium으로 HEAD가 premium브랜치를 가리키게 된다. detached HEAD에서 정상으로 돌아오는 것(아래 사진 참고)
  
• git checkout master의 뜻은 아래와 같다.

  = master 브랜치로 이동하라
  = HEAD가 master 브랜치를 가리키도록 하라
  = HEAD가 master 브랜치가 가리키던 커밋을 간접적으로 가리키게 됨으로써
  = working directory의 내부도 그 커밋에 맞게 변함으로써
  = master 브랜치로 이동한 것을 사용자는 실감하게 됨

fast-forward merge, 3-way merge

• 일반적으로 merge를 하면 merge commit이 생긴다.
  아래 그림처럼 master와 premium에 분기가 생겼을 때 master <- premium으로 merge하는 게 그 예다.
  
  하지만 모든 Merge가 merge commit을 만드는 것은 아닌데, fast-forward가 그 경우다.

fast-forward merge

• 아래 그림처럼 master와 premium이 분기가 나뉘지 않은 상태고,
  HEAD가 master에 있는 상태에서 git merge premium을 하면 fast-forward merge가 일어난다.
  
• 보다시피 새로운 commit이 생기지 않았다.
• 이렇게 새로운 커밋이 생기지 않고 단순히 브랜치가 이동하는 머지를 fast-forward merge라고 한다.
• fast-forward는 빨리감기라는 뜻. 위 과정이 빨리감기와 비슷하다.

3-way merge

• 초반부에 봤던 merge를 3-way merge라고 한다.
  그림처럼 1,2,3 위치를 고려해서 merge가 일어나기 때문이다
  
  (1)번 : 두 갈래로 갈라지기 전 공통 조상이 되는커밋
  (2)번 : 한 브랜치가 가리키는 커밋
  (3)번 : 다른 브랜치가 가리키는 커밋
• 아래 표는 master와 premium을 merge했을 때 상황별로 결과가 정리된 표다.
  
• 3-way merge는 base에서 변화가 발생한 것을 우선 채택한다.
• 위 표를 보면 base를 기준으로 변화가 생긴 브랜치의 결과가 채택됨을 알 수 있다.
  conflict는 두 브랜치가 모두 변했을 때 발생한다.

git 협업

git pull

• 리모트 브랜치의 모든 커밋을 가져와서 로컬에 merge
• 즉 git fetch + merge 두 가지 기능 수행.
• git pull = git fetch + git merge

git fetch

• 리모트 브랜치의 모든 커밋을 가져옴 (no merge)
• fetch 사용 이유
  • 리모트 레포에서 가져온 브랜치의 내용을 머지하기 전 점검할 때 주로 사용.
  • 리모트 레포에 있는 브랜치 내용과 내 코드를 비교해 잘못된 부분이 없는지 검토할 때 사용.
• 코드잇 설명 첨부

  그럼 언제 git fetch를 사용할까요? 업스트림 브랜치의 신규 커밋들을 현재 브랜치에 바로 머지하기보다는 일단 한번 살펴볼 필요가 있을 때 git fetch를 사용합니다.
  만약 살펴봤는데 괜찮다면 로컬 레포지토리의 브랜치에 바로 머지하면 되죠.
  괜찮지 않다면
  (1) 그 작업을 한 다른 개발자와 상의해서 리모트 레포지토리의 내용을 수정해달라고 부탁하거나
  (2) 일단은 내가 머지를 하고 제대로 수정해서 커밋한 다음에 git push를 하면 되구요.

시나리오

• 회사 신입 개발자가 리모트에 업데이트 한 내용이 잘못되어 내가 그 내용을 고쳐 다시 push해야 하는 상황.

1. git fetch로 내용 가져옴. (premium 브랜치라고 가정)
2. git diff premium origin/premium 으로 달라진 내용 비교.
3. 로컬에서 오류 수정 후 add, commit, push

git blame

• 어떤 파일의 특정 코드를 누가 작성했는지 찾아내기 위한 커맨드
• git blame <파일명>: 어떤 파일의 각부분이 어떤 커밋에서 생겼는지 확인 가능.

• git show <commit_id>로 누가 작성한 커밋인지 확인.

git revert (push한 commit 취소하기)

• 변경사항 A가 발생해 add, commit, push까지 했는데 A를 취소해야 하는 상황이 왔다면?
• git revert <변경사항 A의 커밋 아이디>명령어는 A의 변경사항을 제거한 뒤 커밋까지 해주는 명령어다. 이렇게 revert한 뒤 다시 push해주면 된다.
• 예를 들어 커밋이 순차적으로 1,2,3,4가 있는 상황에서 commit5를 만든 뒤 Push한 상황이라 치자.
  이때 5를 취소해야 한다면 로컬에서 git revert 5번 커밋 id를 한다. 이렇게 하면 5내용이 사라진 6번 커밋이 생기고, 이를 push하면 된다.
  코드 내용은 4번 커밋과 6번 커밋이 같게 되는 것이다.

git revert commit_a..commit_b (여러 커밋 취소)

• README.md파일을 초기화해야 하는 상황이라 치자.
  즉, 아래 1번 사진 기준으로 4af143과 eea5349를 revert해야 한다.
• 이럴 땐 git revert facdd05..eea5349명령어를 치면 된다.
  참고로 명령어 앞부분에 나오는 커밋 아이디는 revert에 포함되지 않는다.(2번 사진 참고)
• 명령어를 치면 각각 커밋에 대해 Revert커밋 메세지를 남기는 창이 뜬다. 여기선 커밋 2개를 revert하므로 두 개의 커밋 메세지 입력을 겪게 되고, 다 되면 3번 그림처럼 revert 커밋이 2개 생긴 것을 볼 수 있다. 이제 이걸 push하면 된다.
  1번
  
  2번
  
  3번
  

git reflog

• HEAD가 가리켰던 commit들의 id를 보여줌.
• git reset 명령어로 과거 커밋으로 돌아간 후 다시 최신 커밋으로 돌아오고 싶을 때 최신 commit id를 치면 된다. 다만 git log로 최신 커밋의 아이디를 볼 수 없는데, 이때 git reflog명령어로 커밋 아이디를 볼 수 있다.

커밋 히스토리를 보는 다양한 방법

git log

git log --pretty=oneline

• 현재 속한 브랜치의 커밋을 한 줄로 보기.

git log --pretty=oneline --all

• 모든 브랜치의 커밋을 한 줄로 보기

git log --pretty=oneline --all --graph

• 모든 브랜치의 커밋을 그래프 형태로 보기

git rebase

• 1번 그림처럼 premium브랜치와 test브랜치가 서로 다른 상태다.
• premium에서 test를 머지하면 머지 커밋이 생긴다. (2번)
• 반면, premium에서 test로 rebase하면 머지커밋 없이, 마치 premium이 test를 거쳐온 것처럼 생성된다.(3번)
• merge와 rebase의 결과는 비슷하기에, 둘 중 어떤걸 써도 상관없다.
• 다만 rebase는 커밋 히스토리를 깔끔하게 해준다.
• 두 브랜치를 합쳤다는 정보가 커밋 히스토리에 꼭 남아야 한다면 merge를 사용하자.
• git rebase <branch> ->(conflict) git add . -> git rebase --continue
  1번
  
  2번
  
  3번
  

git stash

• stash: 안전한 곳에 보관하다라는 뜻으로, 작업하던 내용을 stack구조에 넣어놓는 기능.
• 작업 와중에 다른 브랜치로 이동해야 하거나, 잘못된 브랜치에서 작업하고 있었을 때 사용.
• git stash: 작업 내용 저장. 최근 커밋 이후로 작업했던 내용은 모두 stack에 옮겨지고, work dir는 최근 커밋 상태로 초기화됨.
• git stash list: stash stack에 있는 작업 내용 조회
• git stash apply [작업 내용의 아이디]: 작업 내용 적용
  • 아이디 생략시 가장 최근의 작업 내용이 적용됨
• git stash drop [작업 내용의 아이디]: 작용 내용 삭제
  • 아이디 생략시 가장 최근의 작업 내용이 삭제됨
• git stash pop [작업 내용의 아이디]: 작업 내용 적용 + 삭제
  • 아이디 생략시 가장 최근의 작업 내용이 적용 + 삭제됨.

git cherry-pick

• 특정 커밋 내용만 가져올 수 있는 커맨드.
• git cherry-pick [커밋 아이디]

git reset 심화(여러 커밋을 하나로 만들기)

• 상황: 1,2,3번 커밋이 있다.
  커밋이 너무 많아 2,3을 합쳐 총 1,2가 있는 상태로 만들고 싶다면?
  혹은 2가 잘못되어 이를 해결하기 위해 3을 만든 상황인데,
  push할 땐 굳이 세개가 될 필요는 없으니 1,2로 만들고 싶다면?
• git reset --soft <1의 커밋 아이디>로 해주면 된다.
• soft는 work dir의 변화를 주지 않기 때문에 현재 코드 상태로 커밋만 되돌아 간다.
• 돌아간 상태에서 add, commit을 해주면 된다.

git cheet sheet (출처: 코드잇)

git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정
하고 그 안에 레포지토리(.git 디렉토리) 생성
git config user.name 'codeit' : 현재 사용자의 아이디를 'codeit'으로 설정(커밋할 때 필요한 정보)
git config user.email 'teacher@codeit.kr' : 현재 사용자의 이메일 주소를 'teacher@codeit.kr'로 설정(커밋할 때 필요한 정보)
git add [파일 이름] : 수정사항이 있는 특정 파일을 staging area에 올리기
git add [디렉토리명] : 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기 
git add . : working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
git reset [파일 이름] : staging area에 올렸던 파일 다시 내리기
git status : Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음) 
git commit -m "커밋 메시지" : 현재 staging area에 있는 것들 커밋으로 남기기
git help [커맨드 이름] : 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력
git push -u origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용합니다.(-u origin master가 무슨 뜻인지는 'Git에서 브랜치 사용하기' 챕터에서 배울 거니까 걱정마세요!)
git push : 로컬 레포지토리의 내용을 리모트 레포지토리에 보내기 
git pull : 리모트 레포지토리의 내용을 로컬 레포지토리로 가져오기
git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기
git log : 커밋 히스토리를 출력
git log --pretty=oneline : --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다. --pretty 옵션에 대해 더 자세히 알고싶으면 이 링크를 참고하세요. 
git show [커밋 아이디] : 특정 커밋에서 어떤 변경사항이 있었는지 확인
git commit --amend : 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦
git config alias.[별명] [커맨드] : 길이가 긴 커맨드에 별명을 붙여서 이후로 별명으로 해당 커맨드를 실행할 수 있도록 설정
git diff [커밋 A의 아이디] [커밋 B의 아이디] : 두 커밋 간의 차이 비교
git reset [옵션] [커밋 아이디] : 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨) 
		(1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)

		(2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행)

		(3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)

		그리고 이때 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨
git tag [태그 이름] [커밋 아이디] : 특정 커밋에 태그를 붙임
git branch [새 브랜치 이름] : 새로운 브랜치를 생성
git checkout -b [새 브랜치 이름] : 새로운 브랜치를 생성하고 그 브랜치로 바로 이동
git branch -d [기존 브랜치 이름] : 브랜치 삭제
git checkout [기존 브랜치 이름] : 그 브랜치로 이동
git merge [기존 브랜치 이름] : 현재 브랜치에 다른 브랜치를 머지
git merge --abort : 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감
git fetch : 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)
git blame : 특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력 
git revert : 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성
git reflog : HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력
git log --all --graph : 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력
git rebase [브랜치 이름] : A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, git rebase B를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여짐(git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음)
git stash : 현재 작업 내용을 스택 영역에 저장
git stash apply [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용
git stash drop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제
git stash pop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제
git cherry-pick [커밋 아이디] : 특정 커밋의 내용을 현재 커밋에 반영