즐겁게, 코드

오늘 아침에는 프로젝트에 기능을 하나 추가하다가 커밋 메시지를 잘못 남긴 일이 있었습니다. 인터렉티브 리베이스를 하긴 뭔가 귀찮아서 git reset --hard HEAD^ 커맨드를 사용했는데요, 아뿔싸! 커밋과 스테이징은 물론 코드 수정사항까지 모두 이전 버전으로 되돌아가 코드를 다시 작성해야 했던 일이 있었습니다. 이런 일이 또 반복되지 않도록 git reset 커맨드의 내용을 정리해보려 합니다. 스테이징 취소하기 git add 커맨드로 파일을 스테이징 영역에 올릴 수 있다는 것을 알고 계실 텐데요, 저는 파일명을 명시하는게 번거로워 git add . 로 변경사항을 한꺼번에 스테이징하곤 합니다. 다만 이러다 보니 원치 않는 파일까지 한번에 스테이징된다는 문제가 종종 생겨, 스테이징을 취소할 방법이 필..

저희 산학프로젝트 팀은 깃과 깃허브를 통해 프로젝트 기록을 관리하고 있습니다. 그런데 어느 날 커밋 로그를 확인해 보니... 아뿔싸! 뭔가 엄청난 일이 일어났음을 직감했습니다. 아무래도 팀원이 작업을 하면서 수정사항이 생길 때마다 커밋을 남겼고, 이걸 그대로 푸시해 머지한 듯 했습니다. 저도 커밋 템플릿을 완벽하게 지키고 있지는 않아 평소에는 별 생각없이 넘기곤 했지만, 이번에는 약 15건의 커밋 메시지가 의미없이 중복되고 있어 개선이 필요하다고 생각했습니다. 커밋의 은탄환, 리베이스 그래서 이번 기회에 커밋도 정리할겸, 평소에 잘 활용할 기회가 없던 인터렉티브 리베이스를 연습해보기로 했습니다. 인터렉티브 리베이스 커맨드 git rebase -i HEAD~(헤드 포인터로부터의 거리) // Ex. 최근 5..

깃과 커밋은 뗄래야 뗄 수 없는 관계인데, 가슴에 손을 얹고 제 깃허브를 되돌아보면 커밋 메시지가 제대로 적힌 내용이 드뭅니다. 😅 물론 갈수록 의식하고는 있지만 아직도 정확한 기준을 잡지 못하고 있었는데 이번 기회에 커밋 메시지에 대해 정리해보기로 했습니다. 🤔 왜 좋은 커밋 메시지를 남겨야 하는가? 거창하게 소제목을 뽑았지만 사실 좋은 질문은 아닌 것 같습니다. 깃이 뭔지 모르는 사람이라도 '좋은' 무언가를 남겨야 한다는 데에는 동의할 것이기 때문인데요, 그렇다면 질문을 조금 바꿔서 왜 우리는 좋은 커밋 메시지를 남기지 못하는 걸까요? 아마 가장 솔직한 대답은 "귀찮아서" 또는 "어차피 혼자 진행할 프로젝트니까" 정도가 될 것 같네요. 하지만 한편으로는 "제대로 남기고 싶어도 어떻게 남겨야 할지 몰라..