알잘딱깔센 GitHub - Ch 7. 그 외 명령어

이 글은 인프런의 "알잘딱깔센 GitHub" 강의를 듣고 정리한 내용입니다.

 

인프런 강의 링크

[무료] 30분 요약 강좌 시즌4 : 알잘딱깔센 GitHub - 인프런 | 강의

노션 링크

 

---

지금까지 배웠던 내용 이외에 협업할 때 자주 쓰는 명령어 5가지 (amend, stash, reset, revert, cherry-pick) 를 알아보자.

amend

기존의 커밋에 누락된 파일이나 수정된 파일을 추가할 때 사용한다.

‘한 번 더 커밋 하면 되지’라고 생각할 수도 있지만, 같은 기능을 나타내는 커밋이 2개가 생겨 버리게 되므로 커밋을 되돌릴 때 혼동이 올 수 있다.

커밋은 하나의 기능을 만들 때 변경사항을 저장해 주는 것이 좋다.
commit과 push는 날짜나 code 작성 양에 따라 하는 것이 아니라, 기능 구현 단위로 하는 것이 좋다. (유지보수와 복구 측면에서)

amend를 한 후 커밋을 보면 기존 커밋과 amend한 내용이 저장된다.

실습 순서

• 실습을 위해 새로운 깃헙 레포지토리를 생성한다.
• 로컬 폴더에서 git bash를 실행하고 클론한다.
• 새로운 파일(amend.txt)을 생성 후 git add . -> git commit -m '기능 추가'
• amend.txt 파일에 내용 추가 -> git add . -> git commit --amend 로 최신 커밋에 수정한 내용 추가

git commit --ammend : vi 에디터에서 커밋 메시지 수정

git log를 하면 기능추가 - final 하나만 있는 것을 확인할 수 있다.

깃헙 레포지토리에서도 기능추가 - final 하나만 있는 것을 확인할 수 있다.

stash

현재 브랜치에서 아직 커밋 하지 못한 파일들이 있는데, 다른 브랜치로 넘어가야 하는 경우 현재 브랜치의 변경사항을 잠시 보관할 때 stash를 사용한다. stash는 git 저장소에서 관리하고 있는 파일, 첫 커밋이 일어난 대상으로 실행하며 스테이지에 있는 내용과 들어가지 않은 변경 사항 모두를 저장한다. 추가 명령어를 이용하면 git 저장소에서 관리하지 않는 파일도 stash에 넣을 수 있다. 실무에서 회사 우선순위에 따라 작성해야 하는 code가 변경될 때 사용한다.

 

ex) 로그인 기능을 구현하고 있는데 회사에서 "로그인 기능은 우선순위에서 밀리니까 일단 결제 기능부터 만들어라"

-> 로그인 기능은 아직 완료가 되지 않았기 때문에 커밋 할 수 없음

-> 잠시 저장해두고 브랜치 이동 -> 결제 기능 구현

-> 다시 브랜치 이동해서 로그인 기능을 마저 구현

 

Tracked 파일을 stash 하는 경우와 unTracked 파일을 stash하는 두 가지 경우가 있다.

Tracked
: git 저장소에서 관리하는 파일
UnTracked
: git 저장소에서 관리하지 않는 파일

 

Tracked 파일을 stash하는 경우

amend.txt 파일에 새로운 내용 추가 -> git stash -> 파일 상태가 가장 최근 커밋 내용으로 돌아옴

이후 다른 브랜치에서 작업을 하고 돌아온 후, git stash pop 을 통해 가장 최근에 임시 저장한 내용을 가져온다. 이때, 스테이지 상태까지 그대로 복원하지는 않는다.

UnTracked 파일을 stash하는 경우

기본적으로 git은 저장소에서 관리하는 파일만 임시저장을 하지만, git stash --all 명령어를 이용해 git 저장소가 관리하지 않는 파일까지 stash에 올릴 수 있다.

stash에서 꺼내는 방법은 마찬가지로 git stash pop 을 통해 가장 최근에 임시 저장한 내용을 가져온다.

 

stash mode 소개

$ git stash # 저장하기

$ git stash save [description] # 설명 추가하면서 저장하기

$ git stash list # stash 리스트 보여주기
# stash@{0}: WIP on main: 06c4e12 test <- 이런식으로 stash의 목록을 보여줍니다.
# stash@{1}: WIP on main: 02bde12 other

$ git stash apply # 가장 최근 stash 가져와 적용 (stash에서 삭제는 안됩니다.)
$ git stash apply --index # staged된 상태까지 적용하고 싶은 경우

$ git stash drop  # 가장 최근 stash 내용 삭제
$ git stash drop stash@{숫자} # 해당하는 친구 삭제

$ git stash pop # 위에 있는 apply와 drop을 합친 키워드 -> 가장 최근 stash 내용 적용 및 삭제

$ git stash clear  # 전체 삭제

 

reset

브랜치에 여러가지 버전을 올린 후 이전 커밋으로 브랜치를 되돌릴 때 사용한다.

돌아간 커밋 내역 이후의 커밋 히스토리들을 초기화하기 때문에, 기존에 push가 된 상태에서 reset을 사용한 후, 다시 push를 하면 로컬 저장소의 최신 히스토리와 원격 저장소의 최신 히스토리가 다르기 때문에 에러가 발생한다.

강제로 push를 해야 되지만, 혼자 쓰는 브랜치에서만 사용하고 여러 명이 사용하는 브랜치에서는 사용하지 말아야 한다. 이미 push된 커밋을 돌리고 싶은 경우는 revert를 사용한다.

$ git reset [mode]

자주 사용하는 mode는 다음과 같다.

• hard : 지정한 커밋 이력 이후 변경사항을 다 버리고 지정한 커밋으로 리셋
• mixed : 지정한 커밋 이력 이후 변경 사항은 로컬에 unstaged 상태로 유지하고 커밋은 리셋
• soft : 지정한 커밋 이력 이후 변경 사항은 로컬에 stage 상태로 유지하고 커밋은 리셋

앞, 뒤에 내용을 보고 싶거나 그 상태로 단순 이동이라면 아래 명령어를 사용하면 된다. 해당 내용은 commit 내용을 바꾸는 것이 아닌 단순 시간상 이동이다.

git checkout HEAD^ : 바로 직전 commit으로 이동
git checkout HEAD^^ : 2번 전 commit으로 이동
git checkout HEAD^^^ : 3번 전 commit으로 이동
git checkout HEAD~10 : 10번 전 commit으로 이동
git checkout - : 있는 위치에서 앞으로 한 칸 이동
git switch main : 다시 원래 main의 최상위로 이동

 

hard

실습 순서

git reset --hard 커밋ID  ->  add -> commit -> push를 하면 에러가 발생한다.

돌아간 커밋 내역 이후의 커밋 히스토리들을 초기화하기 때문에, 기존에 push가 된 상태에서 reset을 사용한 후, 다시 push를 하면 로컬 저장소의 최신 히스토리와 원격 저장소의 최신 히스토리가 다르기 때문이다.

이럴 땐 강제로 push해야 한다.

$ git push -f origin main

mixed

$ git reset --mixed commit-id
$ git log
$ git status

작업 내용은 사라지지 않고 unstaged 상태인 것을 확인할 수 있으며, commit 이력만 리셋된다.

 

soft

mixed 모드로 reset한 경우 이전 작업 내용을 unstaged에 남겼다면 soft는 staged 영역에 남기게 된다.

히스토리를 살펴보면 커밋 내역은 사라지고 작업 내역은 stage에 남은 것을 볼 수 있다.

$ git reset --soft commit-id
$ git log
$ git status

 

revert

원격 저장소로 push된 후 reset을 사용하게 되면, reset 하고자 하는 커밋 이력으로 돌아간 다음 해당 커밋 이후의 커밋 히스토리들이 전부 삭제된다. 때문에 작업을 마치고 commit, push를 하게 되면, 로컬 저장소에 있는 커밋 히스토리와 원격 저장소에 있는 커밋 히스토리가 달라 Error가 발생한다.

그렇기 때문에 여러 명이 원격 저장소를 다루는 협업에서 reset 사용은 지양하는 것이 좋다. 만약 사용을 원한다면 혼자만 이용하는 브랜치에서 reset 사용을 권장한다.

위와 같은 Error를 방지하며 push된 커밋 이력을 되돌리고 싶은 경우, revert를 사용한다. revert는 특정 커밋 이력을 되돌리는 작업도 하나의 커밋으로 간주하여 기존의 히스토리는 남겨둔 상태로 새로운 커밋 히스토리를 추가하는 방식입니다.

reset과 revert의 차이점
reset :지정한 커밋으로 이동(지정 커밋 이후의 히스토리 초기화)
revert :지정한 커밋의 내용으로 새로운 커밋 생성(히스토리 보존)

 

실습 순서

파일 내용 수정 -> git add , -> git commit -m '기능추가4' -> git push -> git log

git revert 커밋id

: 에러 발생가 발생한다. 최신의 코드에서 이전 코드로 돌아가므로 바뀐 값에 대해 충돌이 일어나기 때문이다.

하나만 선택하여 파일을 수정한다.

git add . -> git commit -> git push -> git log새로운 커밋이 추가된 것을 확인할 수 있다.

 

cherry-pick

여러가지 커밋 중에 내가 원하는 커밋만 가져와서 현재 브랜치에 붙일 수 있다.

예를 들면,

1. 브랜치에 버그가 생긴 경우 버그를 고쳐서 main 브랜치에 merge
2. main에 수정 사항이 많아 당장 머지를 할 수 없는 상황이나 릴리즈 브랜치에는 버그 수정커밋이 들어가야할 때, main에서 버그 수정 커밋만 떼어서 붙임

 

실습 순서

cherry 브랜치 생성 -> cherry 브랜치로 이동 -> 파일 수정 -> git add . -> git commit -m '1' -> git push --set-upstream orgin cherry

cherry 브랜치에서 새로운 파일(hello.txt) 생성 -> git add . -> git commit -m '2' -> git push -> git log

git log를 보면 1, 2 커밋이 올라온 것을 확인할 수 있다.

main 브랜치에 커밋 1만 가져가기 위해 main 브랜치로 이동 -> git cherry-pick 커밋id

main 브랜치의 amend.txt파일이 수정된 것을 확인할 수 있다.