
오늘 아일랜드붕붕이 1주차 1일이다~!
0930 TIL-C 확인하면 되지만. 따라란
1일:
리액트 및 타입스크립트 환경 설정
Create React App으로 타입스크립트 프로젝트 생성
필수 패키지 설치 (기존 package.json 참고)
오늘 어려웠던것!
Husky는 Git hooks를 쉽게 관리할 수 있도록 도와주는 도구. Git hooks는 Git의 특정 이벤트(예: commit, push 등) 발생 시 자동으로 실행되는 스크립트. Husky를 사용하면 이러한 Git hooks를 설정하고 관리하는 과정이 간편해지며, 코드 품질을 높이기 위한 자동화된 검사나 형식화 작업을 수행할 수 있다.
husky - can't create hook,
.husky directory doesn't exist (try running husky install)
했잖아. 근데 왜???????? 🤦🏻♀️
계속해서, error!!!! 뜨니깐, 힘들었다. 사실 Husky를 제외하고, 설치해도 될지 망설였지만, 그래도 해봐야되지않을까... 아냐, 고래 레포를 확인해서, 거기에도 있다면 해야겠다!!
일단 비슷하게 보이도록 외관은 어찌저찌 해봤는데, 뭔가 다시 하고 싶다. 사실 필요한 것 설치도 중요하지만, 왜 이걸 사용하면서 했는지,짚어가면서 하는것도 좋을 것 같다. 
현재 내가 하고 있는 이 레포는 다양한 사이트가 합쳐질것이라고 하셨다. 그래서 뭔가 지금 너무 많다. 약간 정리가 된다면 정리를 해보고 싶다. 뭔가 쾌감 있지 않을까! 훗
아냐 지금 내가, 뭘 하고말고 생각할때가 아닌데, 아냐 어떻게 그냥 넘어가니 . 일단 해. 뭐든 되겠지. 각박한 세상 그냥 하면서 밀고 나아가보렴^^
뭘 데뷔했냐구요? 네 전 프로듀스101에 나가려 합니다! ㅋㅋㅋㅋㅋ
ㄴㄴㄴ 위에 3번에 살짝 적고 지나갔다.
뭐냐면, Conventional Commits !!!!!!!!!
나 한번도 안적어봤다 흑흑흑
이런게 있는지도 몰랐다. 그냥 지난번에 고래 깃허브 초대 해주신다 해서 확인하니까 와, 뭐가 정말 많다. 커밋메시지 이건 뭐람. 그래서 그 주 첫날 여쭤봤고, 이번 기회에 한번 익혀보면 정말 좋을것 같다~ 해서! 말씀드려서 한번 도전해봤는데!!!!!
이렇게 쓰는거 맞나여(누구한테 얘기하니, 너 공간이라고)
어쨌든. Conventional Commits를 정리해볼게요.

그럼 1번 썸네일 보면 난 뭐라고적었냐면, chore: initial project setup
그렇지 코드를 수정하는게 아닌, 설정 즉 초기세팅관련한 일을했으니 뭐겠니. chore 로 선택했다.
하지만 여기서 궁금했던건 새로 설치를 하고 이런 부분이 있었으니,
feat을 작성하는게 아닌가 한다. 이게 궁금했다.
Learned
오늘 리액트 및 타입스크립트 환경 설정을 진행하면서 Conventional Commits에 대해 다시 생각해볼 기회가 생겼다. Git 커밋 메시지를 작성할 때 어떤 규칙을 따르는 것이 중요한지 이번에 깊이 느꼈다. 처음으로 Conventional Commits를 적용해보았고, 커밋 메시지의 형식을 익히려다 보니 여러 가지 궁금증이 생겼다.
특히, 내가 작성한 커밋 메시지 중 하나는 "chore: initial project setup"이었는데, 이는 설정과 초기 세팅에 대한 작업을 의미했다. 처음에는 이 메시지가 적절하다고 생각했지만, 새로운 패키지를 설치하고 프로젝트를 세팅하는 과정에서 feat (기능 추가)를 사용해야 할지 고민이 되었다.
Chore vs. Feat:
Chore는 코드의 기능을 변경하지 않는 단순한 작업, 즉 프로젝트의 구조나 환경을 설정하는 것과 같은 작업에 사용된다. 그래서 초기 세팅을 위한 커밋 메시지로 적합했다.
Feat는 새로운 기능을 추가하는 것과 관련이 있기 때문에, 예를 들어 특정 기능을 구현하거나 컴포넌트를 새로 만드는 작업에는 적합하다.
이렇게 고민하면서 Conventional Commits의 중요성을 다시 깨달았다. 팀원 간의 소통과 프로젝트 관리에 있어 커밋 메시지의 형식을 통일하는 것이 얼마나 중요한지 느꼈다. 커밋 메시지가 일관되게 작성되면 프로젝트의 이력을 쉽게 추적할 수 있고, 나중에 변경 사항을 이해하는 데 큰 도움이 된다. 앞으로도 더욱 적극적으로 Conventional Commits를 활용해 나가고 싶다.
Husky 설치 문제
Husky를 설치하는 과정에서 여러 오류가 발생했는데, 일반적으로 어떤 문제들이 있을 수 있는지, 그리고 이를 해결하기 위한 팁.
Conventional Commits 활용법
커밋 메시지를 작성할 때, 상황에 따라 chore와 feat를 구분하는 기준. 예를 들어, 패키지를 새로 설치하거나 프로젝트 구조를 변경하는 경우에는 어떤 메시지를 사용하는 것이 좋을지
프로젝트 구조 파악
현재 작업하고 있는 레포가 여러 사이트의 통합이라고 들었는데, 이처럼 복잡한 구조를 효율적으로 파악하고 정리하는 방법. 특히, 코드 베이스가 커질 경우 어떤 점에 주의해야하는지.

Today I did the first step of implementing a given screen, though not clone coding.
Why am I writing in English?
I didn't study English deeply today lol just kidding
Wouldn't everyone skip this part then?
Actually, this is my diary right now,
I registered for the gym yesterday and went to work out today.
While exercising, my hypotension got worse and I collapsed for 10 minutes. I can't remember.
I was a little sad in the morning, but I think I'm responsible for not taking care of my health.
My dad told me to go to the hospital, would something big happen? but i think i'm okay.
It's just that when I'm under a lot of stress, I get hypotension.
I'm really fine.
Maybe, my wish is that everything will be fine.
Husky 설치 관련해서는 에러 메시지들 직접 보면서 이야기하지 않으면 어려운 부분이 있을 것 같아요 ㅋㅋ
우선 제외하고 진행하셔도 큰 문제 없습니다.
커밋 컨벤션을 엄격하게 지키기 위해서는 목적에 따라서 커밋을 잘게 쪼개야 하는 경우들도 있는데요. 새로 패키지를 설치하게 되면 직접 작성하는 코드가 아닌 package 관련 파일들에 변경이 있고, 이 부분을 커밋하는 경우 chore로 작성합니다. 주로 src 디렉토리 내부 코드가 아닌 경우에는 chore을 많이 쓴다고 생각하시면 좋습니다! (본문의 경우에 chore이 적합한 게 맞습니다.)
feat, fix 등의 커밋 유형은 기준이 개발자가 아니라 사용자라고 보면 좋아요. 사용자가 느끼기에 커밋 전 후에 기능 상 변화가 있는 코드 작성이 이루어졌다면 feat, 기능 상 유의미한 변경은 아니지만 에러 등을 수정했다면 fix, 사용자가 느끼기에는 변화가 없지만 코드 구조 등을 변경(리팩토링)했다면 refactor을 이용합니다.
매번 커밋을 잘게 쪼개기는 귀찮기 때문에.. 혹시 한 커밋에 여러 유형에 해당하는 코드 변경이 함께 포함되어 있다면 feat > fix > refactor의 순서로 우선순위를 주시면 됩니다.
sumcar-frontend 레포의 경우에는 apps/sumcar 디렉토리 하위의 코드들을 중심으로 살펴보시면 효율적일 것 같습니다.
모노레포 관련해서는 이번 주에 얘기해봐요!