즐겁게, 코드

오늘은 커밋을 수정하는 방법을 소개해보려 합니다. 이렇게 잘못 남긴 커밋 메시지가 있을때, 여러분들은 어떻게 메시지를 수정하시나요? 1번 유형 : 주석 등 무의미한 변경사항을 만들고, 메시지를 고쳐 새로운 커밋을 남긴다. 2번 유형 : git reset --soft 를 통해 커밋을 취소하고, 메시지를 고쳐 커밋을 다시 남긴다. 3번 유형 : 다음부터는 잘 남겨야겠다고 다짐한다. (^^;) 세 방법 모두 잘못된 방법은 아니지만 저는 지금까지 2번 유형으로 커밋 메시지를 수정하곤 했는데요, 이보다 더 쉬운 방법이 있습니다. 바로 --amend 플래그를 사용하는 방법입니다. 커밋 메시지 수정하기 git commit 커맨드에 --amend 플래그를 붙이면 직전에 남긴 커밋을 수정할 수 있게 됩니다. git co..

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

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

🏒 들어가기 전에 이 글은 Mark Longair 님의 GIT: FETCH AND MERGE, DON’T PULL 을 읽고 번역한 글입니다. ※ 매끄러운 번역을 위한 의역이 다소 있으며, 혹시 잘못된 번역이나 어색한 문장 지적은 감사히 받겠습니다. 😄 2020 오픈소스 컨트리뷰톤 당시 멘토님께서는 원격 저장소에서 커밋을 불러올 때 git fetch와 rebase를 활용했는데, 저로서는 git pull을 두고 왜 어려운 방식을 사용하는 건지 이해되지 않았던 때가 있었습니다. 이번 글을 번역하면서 git fetch와 pull의 차이를 정리해보고자 합니다. (요약 : git pull은 변경사항을 페칭한 후 곧바로 병합하지만, git fetch는 페칭과 병합 프로세스를 분리할 수 있기 때문입니다.) 제가 주변 ..

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