git stash
아직 마무리 하지 않은 작업을 스택에 잠시 저장하는 명령어이다.
완료하지 않은 일을 commit 하지 않고 다시 꺼내와 마무리할 수 있다.
일종의 임시저장!
(^^ 구글링해서 제일 맘에 드는 사진을 찾았는데 detertory라고 써있었다ㅋ.. 옆에서 정준호가 포토샵으로 directory로 바꿔줬다! 정현지가 자기가 부러워했다고 써달라했다 ^^ 써드렷슴)
stash란 아래에 해당하는 파일을 보관하는 장소이다.
1) Modified 면서 tracked 상태의 파일
- 여기서 modified란?
파일에 수정사항이 있는 경우를 의미한다.
- 여기서 tracked란?
깃은 한 번이라도 커밋을 한 파일의 수정 여부를 계속해서 추적하게되는데 이처럼 깃이 추적하고 있는 파일을 tracked 파일이라고 한다.
- 그렇다면 untracked는?
예를 들어 파일을 새로 만들었을 때 Untracked files 라는 표시가 뜬다. 이 파일은 한 번도 깃에서 버전 관리를 하지 않았기 때문에 수정 내역을 추적하지 않았다.이럴 경우 untracked 파일이라고 한다.
2) Staging area 에 있는 파일
1. Git Stash
git stash
위의 명령어를 통해 새로운 stash를 스택에 만들어 변경사항을 임시로 저장한다.
2. Stash 확인하기
git stash list
여러번 stash 했을 때 위의 명령어를 통해 저장한 stash 목록을 확인 가능하다.
3. Stash 했던 작업을 다시 가져오기
git stash apply
위의 명령어를 통해 했던 작업을 다시 가져온다.
//가장 최근의 stash를 가져와 적용
git stash apply
//원하는 stash를 불러와 적용
git stash apply [stash 이름]git stash drop
apply 옵션을 통해 stash를 적용했다면 적용한 stash는 여전히 스택에 남아있다.
스택에 남아있는 stash를 제거하기 위해서는 drop 명령어를 사용한다.
방법은 stash와 같다!
git stash pop
(apply + drop의 형태이다!)
이렇게 저장한 임시 변경사항을 꺼내오는 명령어
스택처럼 동작함. 가장 최근에 저장한 변경 사항을 꺼냄
git cherry-pick
git cherry-pick
두 개의 브랜치가 있다고 가정할 때, 현재 개발하고 있는 브랜치에서 다른 브랜치에 적용되어 있는 3개의 커밋을 가져와 반영시키고 싶은 상황이다. 이럴 때 사용하는 명령어이다.
git cherry-pick <commit hash>
이런식으로 cherry-pick 명령 뒤에 커밋 해시 값을 명시해줘야한당 한번에 여러개 하고 싶으면 여러개 연달아서 뒤쪽에 입력해도 된당.
git cherry-pick <commit hash>..<commit hash>
이런식으로 가져오고 싶은 범위의 첫번째와 마지막 해시값을 ..로 이어 표현해도 된다. 이러면 이 사이에 있는 모든 커밋들을 가져와 현재 브랜치에 반영할 수 있다. ( 첫번째 값은 반영이 안됨, 그 다음부터 마지막 커밋까지 반영)
다른 브랜치의 커밋사항을 가져오는 명령어이기 때문에 수정사항이 현재 브랜치의 코드에 맞지 않는 경우가 있다.
이 경우 충돌이 발생하게 되는데 cherry-pick 을 포기하거나 해결하고 다시 진행할 수도 있다.
vi $file_path # 파일 수정
git add $file_path
git cherry-pick -continue 충돌이 발생한 코드를 에디터로 열어 수정하는 명령어이다.
git add 로 수정된 코드를 추가 후 cherry-pick -continue 명령을 실행하면 충돌을 수정한 코드를 반영, 재개 한다.
git cherry-pick -abort만약 cherry-pick 을 중단하고 싶으면 -abort 옵션을 이용하여 중단할 수 있다.
cherry-pick 실행하기전 상황으로 코드가 돌아간다.
git fetch
원격 저장소에 있는 변경사항들을 로컬 저장소에 가져오기 전에 변경 내용을 확인하고 싶은 경우 사용하는 명령어이다.
이해하기 좋은 예시가 있어 참고하자면...
만약 내가 작업한 파일을 깃허브에 올리고 퇴근했다. 근데 다음날 누군가 내 파일에 다른 변경사항을 남겼는지 확인하고 싶을 때!
로컬 디렉토리로 변경한 내용을 가져오지 않고 변경한 내역들만 확인할 때 사용한다.
pull 과의 차이점
pull은 원격 저장소의 내용을 가져와 자동으로 병합작업을 실행한다. 하지만 내용을 확인만 하고 로컬 데이터와의 병합을 원치 않는 경우 fetch를 사용하면 된다.
fetch + merge => pull
그렇다면 merge 란?
git merge
git merge 란 브랜치를 다른 브랜치로 합치는 과정을 의미한다.
예를 들어 coding-test 라는 브랜치에서 문제풀이를 업데이트했고, 문제 사항이 없는 경우 메인 브랜치에 업데이트를 하는 방식으로 과제를 저장하고 있다. 이 경우, 이 둘을 병합시키는 과정이 merge인 것이다.
git rebase
git rebase 도 역시 브랜치를 다른 브랜치로 합치는 과정을 의미한다.
그렇다면 merge와의 차이점이 무엇인가?
git merge 와 git rebase의 차이점
git 에서 merge와 rebase 의 실행결과는 같다, 하지만 커밋 스토리가 달라진다.
Merge의 경우 합쳐진 브랜치의 커밋 메세지가 중복으로 쌓이며 커밋 순서를 바꾸지 않는다.
이 이미지의 경우 main 브랜치에 feature 브랜치를 병합하는 과정을 나타냈으며 커밋의 순서는 변경 되지 않고 기존의 것들은 유지되고 있는 모습이다.
git rebase를 이용한 feature 브랜치를 main 브랜치에 병합하는 이미지이다.
feature 브랜치의 커밋은 Main 브랜치가 가지고 있던 기존의 커밋뒤에 위치하게 된다.
병합을 하면 브랜치의 커밋메세지가 시간 순서대로 합쳐져 히스토리를 깔끔하게 유지하고 싶을 때 사용하면 된다. 즉, master 브랜치의 기존의 마지막 커밋 뒤에 병합할 브랜치의 커밋들을 합쳐지게 하여 master 브랜치에 재배치(rebase)를 하는 것을 의미한다.
커밋 메세지를 입력하는 과정에서 오타가 생겨 커밋 메세지를 수정하고 싶었는데 그 때 rebase 명령어를 처음 사용해봤당. 그 때 필요했던 명령어들을 간단하게 정리해보고자 한담.
pick
-커밋을 사용하겠다는 의미, 이를 이용해 커밋의 순서를 바꿀 수 있고, 커밋의 해시값을 이용해 특정 커밋을 가져올 수 있습니다.
-
rebase 명령어를 실행하면 기본적으로 pick으로 설정돼있기 때문에 아무것도 변경하지 않고 종료한다면, 커밋에 대하여 어떠한 변경도 일어나지 않게 됩니다.
-
위 코드에서 commit2와 commit3의 순서를 바꾼다면, 커밋 순서와 커밋 해시값까지 변경됩니다.
reword
-
커밋 메시지를 변경하는 명령어
-
커밋 메시지를 변경할 커밋 앞에 reword 명령으로 수정하고, 저장하면 해당 커밋의 메시지를 다시 작성하는 에디터 창이 열리게 됩니다.
-
커밋 메시지와 커밋의 해시값 또한 변경됩니다.
edit
-
reword 명령어는 커밋 메시지만 변경하는 명령이라면, edit 명령어는 커밋 메시지뿐만 아니라 커밋의 작업 내용까지 변경할 수 있습니다.
-
commit4라는 커밋을 edit으로 바꾸고 저장 후 종료하면, 변경할 커밋으로 checkout됨, 그 상태에서 변경 작업을 수행하면 됩니다.
-
그 후 변경사항을 저장하기 위해 아래와 같은 명령어 입력
squash
- squash 명령어는 해당 커밋을 이전 커밋과 합치는 명령어입니다.
- 주의 사항
그렇기에 이전의 커밋 히스토리를 시간 순서대로 배열하는 과정에서 변경사항들이 생기기 때문에 주의를 요한다.
만약, 이미 원격 저장소에 푸시한 커밋이라면, 변경한 커밋들은 원격 저장소에 푸시 되지 않을 것이다. 명령어를 사용하여 ( git push --force , git push -f )
강제로 히스토리를 덮어쓸 수 있지만 커밋 히스토리 불일치가 발생하면 깃이 꼬일 것...
