작업을 하다가 잠깐 작업을 중단해야하는 상황이 생겼는데, 커밋 내역을 만들기에는 애매할 때 쓰는 기능입니다. 지금 커밋이 아니라 이전 커밋에 반영해야 하는 사항등이 생각났을 때 써먹을 수도 있습니다. git stash 기본 동작으로는 git add 를 통해 staged 되지 않은 것은 stash 로 저장되지 않는다. 그런 것까지 전부 포함하고 싶다면 git stash -u(untracked) 를 쓰도록 한다. git stash list 스태시의 번호를 알아내서 불러오는데 활용한다. git stash apply 번호 스태시 안의 내용을 보고 싶다면 git stash show 번호 스태시가 저장한 변경 내역을 자세히 보고 싶다면 git stash show -p 번호 스태시를 저장할 때 그 스태시가 무엇인지 ..

이 글은 아래 영상 내용을 기반으로 작성되었습니다. www.youtube.com/watch?v=OJqUWvmf4gg 전체 형식 [(선택)scope]: [(선택) body] [(선택) footer(s)] type 이 커밋으로 인한 변경이 대략적으로 어떠한 유형의 변경인지를 명시합니다. 가장 대표적인 type의 예시로는 fix : 버그를 고쳤을 때 feat 혹은 feature : 기능과 관련된 변경 그 외 : build, style, chore, refactor, ci, test, docs Scope type 에 추가해서 넣을 수 있는 정보를 명시하고 싶을 때 사용합니다. 괄호 () 안에 명사만을 넣어야 합니다. 만일 엄청 중요한 커밋이라는 것을 명시하고 싶을 때는 ! 느낌표를 : 콜론 앞에 넣습니다. 딱히..

브랜치 종류는 크게 아래와 같다. master develop feature release 실제 개발은 develop 브랜치에서 진행된다. 그리고 develop 자체에서 커밋 내역을 만드는 것이 아니라 feature 브랜치에서 커밋을 만들고 이를 develop 에서 병합하는 식으로 커밋이 이루어진다. 별거 아닌 버그 픽스나 기능 추가는 그냥 develop에서 빠르게 반영한 후 커밋한다. 즉, develop 에서 왠만하면 커밋이 발생하지 않지만 발생할 수 있으므로 feature 브랜치에서 작업을 할 때는 항상 develop 브랜치의 변경 사항을 pull 해와야 한다. 개발이 어느 정도 완료되고 이를 배포하는 시점에서는 Release 라는 이름으로 시작하는 브랜치를 만든다. 해당 릴리즈에서 발생하는 버그나 수..

git reset 리셋 작업은 크게 3가지로 나눌 수 있다. 하나는 add 가 끝난 시점으로 돌아가는 soft, 둘째는 staged 파일들(추적 중)과 untracked 파일들이 섞인 시점으로 돌아가는 mixed, 아예 그냥 이전 커밋 상태로 돌아가는 hard 가 있다. reset을 할 때 플래그로 이 옵션을 넣어주면 적용된다. (--soft, --mixed, --hard) Tip: 되도록이면 hard는 주지 않는 것이 좋다. 기존에 작업했던게 임시로라도 남아있지 않고 그냥 다 날아가 버리기 때문이다. 아니면 git stash 를 통해 임시 저장을 수행한 다음 해주는 것이 좋다. git stash 작업을 하다가 잠깐 작업을 중단해야하는 상황이 생겼는데, 커밋 내역을 만들기에는 애매할 때 쓴다. 해당 브랜..