즐겁게, 코드

오늘은 커밋을 수정하는 방법을 소개해보려 합니다. 이렇게 잘못 남긴 커밋 메시지가 있을때, 여러분들은 어떻게 메시지를 수정하시나요? 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..

오늘은 진행중인 프로젝트에 라이센스 라벨을 부여하고 싶어 저장소를 온통 뒤져봤는데요, 아무리 찾아봐도 라이센스 관련 항목은 찾을 수 없었습니다... 😡 결국 구글링을 통해 찾아낸 방법을 소개해드리려 하는데요, 생각보다 훨씬 짧고 간단하니 가볍게 읽어주세요! 📋 깃허브 저장소별 라이센스 부여하기 첫 번째 방법은 저장소를 생성할 때 라이센스를 함께 부여하는 방식입니다. 이렇게 [Choose a license] 항목을 체크하고, 적용할 라이센스를 선택하기만 하면 끝입니다! 다만 이미 생성된 프로젝트에는 어떻게 라이센스를 부여할 수 있을까요? 저장소 메뉴 중 [Add file]을 누른 후, [Create new file]을 선택합니다. 그리고 License(확장자와 대소문자는 상관없습니다!) 라고 입력하면 [C..

{ "message": "API rate limit exceeded for 110.14.126.182. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)", "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting" } 깃허브 클론 프로젝트를 진행하던 중, 깃허브 api는 시간당 60회 호출 제한이 걸려있어 프로젝트 진행에 어려움을 겪고 있었습니다. 컴포넌트가 재렌더링될때마다 함수에서 데이터를 요청하기 때문에 불과 몇 ..

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

짧은 내용이지만 꿀팁이 될 것 같아 남겨봅니다. conwnet/github1s One second to read GitHub code with VS Code. Contribute to conwnet/github1s development by creating an account on GitHub. github.com github1s 라는 프로젝트가 있는데, 깃허브 저장소에 담긴 코드를 클론할 필요 없이 온라인 VSCode 환경에서 즉시 확인할 수 있게 합니다. 예를 들어 github.com/C17AN/vue-todo 저장소의 코드가 궁금한데 클론까지 해가면서 내용물을 들여다보기는 귀찮다 싶을 때, 도메인을 gitbhub 에서 github1s 로 고쳐 보세요. (github.com/C17AN/vue-todo..