이슈 습관적으로 git add . 를 해서 원하는 파일이 아닌 모든 파일이 커밋이 되었다 그리고 reset(git reset --hard HEAD~1)을 하니 전부 날아갔다 복구하기 https://88240.tistory.com/284 이전에 작업했던 git 이력을 확인 할 수 있다 나는 reset 하기 직전으로 되돌아 가기 위해 아래와 같이 입력했다 커밋 취소하기 https://www.freecodecamp.org/korean/news/giteseo-keomis-doedolrigi-majimag-keomiseul-cwisohaneun-bangbeob/ reset 할 때 soft 옵션을 추가하면 변경사항이 손실되지 않는다 git add . 로 모든 파일을 커밋했던 것을 커밋 직전으로 되돌렸다 원하는 파일만 커밋하기 마지막으로 원래 내가 하려고 했던 특정 파일만 커밋을 했다 vscode에서 추가하고 싶은 파일만 선택해서 추가 후 커밋을 하면

reset과 달리 revert는 커밋로그는 유지하면서 커밋하기 전으로 되돌릴 수 있다 마지막 커밋만 되돌리는 경우 마지막에서 +n개를 되돌리는 경우(n+1개의 커밋을 되돌림 - HEAD를 포함하기 때문) git revert 취소하기 특정 커밋만 되돌리기 이 경우 같은 파일 내에서 같은 특정 커밋이전 상태로 돌리기 때문에 그 이후에 반연된 커밋이 있다면 그것까지 같이 되돌려진다 그러나 특정 커밋 이후에 다른 파일에 커밋된 내용은 보존된다 -n 옵션을 주면 커밋이 바로 되지 않고 충돌이 되는 부분을 부분적으로 채택할 수 있는 화면이 나온다 이 상태에서 git revert --abort를 하면 revert를 취소시킬 수 있다 참고 https://git-scm.com/docs/git-revert https://codechacha.com/ko/git-delete-commit/ https://github.com/TaehwanGo/pl

1. squash merge origin/main에서 새로 만든 후 로컬에 있는 지저분한 브랜치를 squash merge git checkout -b aNewBranch origin/main git merge --squash aBranchWithMultiCommit 2. rebase rebase 옵션 중 f(fixup) 을 선택해서 하면 된다. git rebase -i HEAD~3 // 3개의 커밋을 하나로 합치려는 경우 남길 commit만 f 로 바꾸고 나머진 pick을 유지 rebase로 만약 하려다 실패했다면 git reset --hard ORIG_HEAD 로 rebase 전으로 되돌릴 수 있다 참고 [rebase 되돌리기](https://www.delftstack.com/ko/howto/git/undo-rebase-in-git/#:~:text=rebase%20%EB%A5%BC%20%EC%8B%A4%ED%96%89%20%EC%B7%A8%

PR을 올리고 보니 git commit message에 이슈번호를 누락해서 수정해야 될 일이 있었다. 로컬에서 수정을 하고 force push로 현재 올라간 PR에 덮어쓰기해서 변경된 커밋메세지가 적용되도록 했다. 하나의 커밋 메세지 수정 git commit --amend 이후 커밋메세지 수정(vi 에디터 문법) i => 편집모드 (편집을 종료하고 싶다면 esc) :wq => 저장 후 종료 git push --force origin [PR올린 브랜치] 여러개 일땐 rebase git rebase -i HEAD~변경할 커밋의 갯수(숫자) rebase 모드에서 수정할 커밋들을 pick에서 edit으로 변경 (i눌러서 편집모드) esc로 편집 모드를 빠져나온 후 저장(:wq) 각각의 커밋에서 멈추게 되는데 이때 git commit --amend -m "수정할 메세지" 로 수정 git rebase --continu

상황 github PR(Pull Request)을 올렸는데 리뷰과정에서 작은 수정이 생긴 경우 리뷰과정에서 생긴 커밋 - 한두줄 수정된 것을 커밋 - 을 깔끔하게 하나의 커밋으로 합치고 싶은 상황 git rebase git rebase -i HEAD~[합칠 커밋 개수] 합치기 수정 후 :wq 명령어로 저장 git log로 잘 수정되었는지 확인 기존 PR에 덮어쓰기 git push -f origin [브랜치명] 참고 https://cjh5414.github.io/git-rebase/ https://madplay.github.io/post/squash-git-commits-with-rebase

husky node.js 환경에서 git hook을 손쉽게 제어하도록 도와주는 매니저 https://www.npmjs.com/package/husky pre-commit : 커밋이 만들어지기 전에 호출 git hooks Git 과 관련한 어떤 이벤트가 발생했을 때 특정 스크립트를 실행할 수 있도록 하는 기능 참고 https://www.huskyhoochu.com/npm-husky-the-git-hook-manager/ https://library.gabia.com/contents/8492/

TL;DR 새로운 브랜치를 만드는 경우엔 원격(github)을 기반으로한 브랜치로 만들자 git checkout -b [새로 만들 브랜치 이름] [원격에서 가져올 브랜치 이름] git checkout -b newFeature origin/main 원격의 브랜치를 가져올 땐 origin/을 붙여줘야 한다. PR할 때 마다 과거의 커밋들이 계속 붙는 문제가 있었다 로컬의 main 브랜치를 원격에서 받아와 최신화 시켜놓은 상태에서 로컬 main 브랜치 기반으로 새로운 브랜치를 만들었는데 예전에 main 브랜치에 실수로 커밋을 하고 그것을 기반으로 만든 브랜치들로 계속 작업하고 있었다. 오늘 팀원들한테 물어보니 원격의 main에서 브랜치를 생성해야된다는 것을 알게 되었다.

종종 다른 브랜치에 작성한 코드를 보기 위해 현재까지 작성한 코드를 임시로 커밋 후 브랜치를 바꾸곤 했다. 오늘 git stash라는 것을 알게 되었고 다음에 그럴 상황이 생기면 git stash를 이용해서 의미없는 커밋을 하는 것을 지양해야겠다. stash : 숨기는 장소, 몰래 챙겨두다 상황 가정 갑자기 작업하던 브랜치에 작업이 완료되지 않았는데 급하게 브랜치를 바꿔야 되는 상황 git stash 사용하기 git stash 커밋을 하지 않아도 git stash만으로 워킹 트리가 깨끗해짐(브랜치 변경 가능) 임시 저장하면서 현재 작업한 내용들이 임시로 사라짐 급하게 브랜치 변경 후 급한일 처리 다시 git stash를 사용한 브랜치로 돌아와서 git stash pop 임시로 사라졌던 작업한 내용들이 복구 됨 참고 [git stash 사용법: 커밋하지 않고 변경사항 저장하는 방법](https:

많이 사용하는 git cli는 암기해서 사용하고 있었다. git push origin [브랜치 이름] git pull origin [브랜치 이름] 잘 못된 이해 origin이 항상 들어가서 local에서 현재 내가 위치한 브랜치로 생각했었다. git push origin [브랜치 이름]: 내가 현재 위치한 브랜치를 [(원격에) 브랜치 이름]으로 올린다 git pull origin [브랜치 이름]: 내가 현재 위치한 브랜치로 [(원격에 있는) 브랜치 이름]을 가져온다 올바른 이해 git의 origin이 의미하는 것은? remote repository의 URL short name "origin [브랜치 이름]"은 복합명사(명사+명사) 이다. git push origin [브랜치 이름] : git이 push (현재브랜치를:생략됨) 원격(origin)의 [브랜치 이름]으로 `git push origin [브랜치 이름]

github의 pull request가 아니더라도 로컬에서 테스트용으로 branch를 만들고 git checkout -b (A new branch name) 브랜치를 새로만들고 그 브랜치로 스위칭 자유롭게 수정 후 merge 할 수 있다. git checkout (merge할 main branch) git merge (merge될 test branch) git branch -d (삭제할 test branch)