📚금일 학습 내용

프로젝트 12일차, 파일 구조 분리, 깃 허브 룰 추가, conflict... conflict... conflict...

📂파일 구조 분리

이제 그래도 파일 구조와 가져다 쓰는 것들이 편리해지고 있다. 특히 공용함수로 빼고, 공용 훅으로 빼고, 유틸로 빼는 과정이 슬슬 익숙해져서 기분이 좋다. 그리고 앞으로 추가적으로 내부 컴포넌트를 구현할 때 아래와 같이 구조를 정리해서 사용하려고 한다.

각각의 기능을 하는 파일을 다 분리시켜 코드를 작성하는 과정, 코드 리뷰 받는 과정에서 각 코드의 의미를 파일 구조에서부터 명확하게 분리시켜 좀 더 확실하게 해보고자 한다.

음... 슬슬 MVC패턴이나 Atomic 패턴에도 관심이 생기는데 사실 두 가지 모두 대략적으로는 인지하고 있으나 사용해 본 경험이 없어서 개인 프로젝트에 적용해보며 경험을 쌓아야겠다.

📍 깃 허브 룰 추가

프로젝트 코드 규모가 점점 커지고, 그에 따라서 PR이 단순 Feature뿐만 아닌 Fix, Refactor, Design등 다양한 부분으로 세분화되기 시작했다. 그에 따라서 PR에 대한 여러 label이나 템플릿, 이슈에 대한 필요성이 생긴다고 판단했고, 템플릿을 default 브랜치, 보통 main일 것이다. main 브랜치에 병합해두었다.

이슈와 같은 경우에는 settings를 들어가자마자 약간 스크롤을 내리면 아래 이미지와 같은 메뉴가 나오는데, 여기서 Set up templates를 눌러서 템플릿을 설정해주면 된다.

PR의 경우 최상단에 .github 폴더 내부에 PULL_REQUEST_TEMPLATE.md파일을 만들어서 템플릿 내용을 입력해두면 적용된다. 인터넷에 가장 많이 조회되는 글에서 템플릿을 가져왔다.

❗Merge Conflict...

왜!!! 대체 왜!!! 라기에는 컴퓨터는 거짓말을 참 못하는구나😥

같이 작업하는 코드가 많은 팀 프로젝트의 경우 종종 Merge Conflict가 난다. 특히 우리 팀 같은 경우에 초반에 공용 컴포넌트를 만들고 이후에 공용 컴포넌트를 같이 사용하면서, 만들어 가는 식으로 개발이 진행되고 있다. 그래서 A, B가 기능 개발을 하다가 종종 겹치는 경우가 발생하는데, 이때 conflict를 해결하는 과정이 어렵다.

일단 git rebase, fetch, pull의 차이에 대한 이해도가 명확하지 않은 문제점이 가장 크다. 다 비슷한 기능을 하는 것 같은데 제대로 정리하지 않은 채로 프로젝트를 진행하다보니, 막상 발생하는 문제를 직면하면 당황하게 되는 것 같다.

일단 그래서 오늘 해결한 방법은 다음과 같다. 팀원이 branch에 동기화를 하는 과정에서 이미 git rebase 코드가 중첩되었고 커밋들이 많이 꼬여있었다. 솔직히 풀어보려고 노력을 해봤는데, 이미 많은 시간이 소요된 상태라서... 아쉽게도 더 풀어보기 보다는, 해당 브랜치를 내려 받아서 발생한 충돌 요소를 다시 해결하고 push하는 방식으로 진행했다.

다만 진행방식의 차이가 있다면, 한번에 conflict를 해결하느냐 아니냐의 차이인데, 한번에 해결하고 push하니 다행히 문제없이 동작했다.

📖소회

아프지 맙시다..ㅠㅠ

내가 아픈 것은 아니지만 팀원이 아파서 힘들어하는 모습이 안타까웠다. 일정 걱정 없이 푹 쉬고 오길.. 우리가 엄청 빠르게 진행되고 있다는 사실을 알려줬어야했는데ㅠㅠ

음...그래도 집중력이 올라가고 컨디션도 좋아지는데, 그래서 다 마음에 드는데, 딱 하나 마음에 안든다. 바로 프로젝트에서의 내 작업 속도이다. 자만심일까? 아니면 그냥 나태함일까.. 내일은 목숨이 경각에 달린 기분으로 모든 것을 다 해내야겠다🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥 가자!!!!!🔥🔥🔥🔥🔥 익준님 발표 잘하세용ㅎㅎ
TIL 작성 소요시간 약 36분