폴더 구조 변경에 관한 고민

 

https://velog.io/@teo/separation-of-concerns-of-frontend

프론트엔드 개발자 관점으로 바라보는 관심사의 분리와 좋은 폴더 구조 (feat. FSD)

 

해당 게시글을 읽다가 폴더 구조에 관한 사소한 궁금증 발생

fsd(feature-sliced-designn) 구조에 관한 이야기를 많이 들어, 해당 구조는 조만간 개인 사이드프로젝트에 적용해 볼 예정

 

...

해당 구조론 보다는 팀 프로젝트를 진행할 때, 폴더 구조를 변경하려니 꽤나 부담스러웠던 기억이 있었다

대 개편까지는 아니었지만 내 파트에서 기존에 결제 버튼 컴포넌트 파일에 제작했던 결제 로직을

결제/주문 페이지가 새로 생기면서 

결제버튼은 주문 상품 관련 값을 전역 저장하고, ui와 페이지 이동 이 3가지만 남기려했고

 

작은 프로젝트였고 누군가와 같이 작업하는 파트는 아니었지만 결제 버튼을 다른 팀원분이 import해서 사용하는 부분도 있었고 병합 충돌을 최소화하고싶었던 기억이 있다

 

 

폴더 구조를 변경할 때 팀 프로젝트에서 충돌을 최소화하고 효율적으로 진행하기 위한 방법에대해 조금 찾아보았고

뻔한 내용이지만 기록 

 

 

 

 

1. 충분한 논의

 

• 폴더 구조 변경은 프로젝트의 전반적인 작업에 영향을 미치므로, 팀원들과 충분히 논의 후 변경 사항을 결정해야 합니다.
• 변경 이유, 새로운 구조의 장점, 영향을 받는 파일 등을 명확히 설명할 것

 

2. 새 브랜치 생성

 

 

• 새로운 브랜치를 생성하여 폴더 구조 변경 작업을 진행
• 브랜치 이름은 명확하게 지정 (ex. refactor-folder-structure)

 

3. 단계적 변경

 

 

• 한 번에 모든 것을 변경하기보다는 단계적으로 진행하여 변경의 범위를 줄인다
• 작업 중 commit을 작게 나누어 기록 (ex. " src/components로 컴포넌트 이동 ")

 

4. Pull Request  사용

 

 

• PR을 생성해 팀원들에게 변경 사항 설명
• PR 설명에 변경된 폴더 구조와 의도를 명확히 기재
• 팀원들의 리뷰를 받아 수정이 필요한 부분을 반영

 

 

관련 git 명령어

- 폴더 구조 변경 시에는 git mv 명령어를 사용하면

Git이 파일 이동을 추적할 수 있어 히스토리를 보존하고 충돌을 줄일 수 있다

 

git mv old_folder/ new_folder/

 

 

 

 

 

 

 

 

5. merge 이후 팀원들에게 로컬 브랜치를 최신 상태로 업데이트 해야한다고 전달