모노레포란?

모노레포(Monorepo)를 간단히 말하면, 서버와 클라이언트 코드가 한 저장소(Repository)에 같이 있는 것을 뜻한다

각각의 코드베이스를 별도의 저장소로 관리하는 멀티레포(Multirepo)와는 달리, 하나의 저장소에서 모든 관련 프로젝트를 통합적으로 관리하는 방식이다

모노레포의 장점

• 코드 공유: 서버와 클라이언트가 같은 저장소에 있으므로, 공통된 코드를 쉽게 재사용
• 일관된 버전 관리: 한 저장소에서 관리되므로 의존성 버전 충돌을 줄임
• 일관된 개발 환경: 서버와 클라이언트 간의 개발 환경을 동일하게 유지
• 간편한 CI/CD: 한 저장소에서 빌드와 테스트 파이프라인 설정 과정 단순화

모노레포의 단점

• 저장소 크기 증가: 대규모 프로젝트에서 저장소 크기가 커지고 클론, 빌드, 테스트 시간이 증가
• 의존성 관리 복잡성: 하나의 프로젝트에서 특정 의존성을 업데이트시 다른 프로젝트에 영향을 미칠 수 있음
• 권한 관리 어려움: 모든 프로젝트가 한 저장소에 있으므로 프로젝트별 접근 권한 관리가 어려움

해결 방안

• Monorepo 도구 사용: Nx, Bazel 같은 도구를 사용해 필요한 부분만 빌드, 테스트
• 의존성 관리: Lerna, Yarn Workspaces 등을 통해 독립적인 의존성 관리 구현
• 권한 분리: GitHub CODEOWNERS 파일로 디렉토리별 권한 설정

멀티레포란?

멀티레포(Multirepo)는 각 프로젝트를 독립적으로 별도의 저장소에서 관리하는 방식을 뜻한다

서버와 클라이언트 코드, 공통 라이브러리 등이 각기 다른 저장소에 저장되며, 필요할 때만 의존성을 가져와 사용하는 형태이다

멀티레포의 장점

• 독립적인 배포 및 개발: 특정 프로젝트만 선택적으로 업데이트하거나 배포하기 쉬움 (각 팀이 다른 팀의 코드베이스에 의존하지 않고 빠르게 개발 및 배포 가능)
• 프로젝트 분리: 각 코드베이스가 독립적으로 관리되므로 프로젝트 간 영향도 낮아짐 하나의 저장소에서 발생한 문제가 다른 프로젝트에 영향을 주지 않음
• 다양한 기술 스택 관리: 서로 다른 언어나 빌드 도구를 사용하는 프로젝트 간 충돌을 방지

멀티레포의 단점

• 공통 코드 관리 어려움: 공통 라이브러리나 설정을 동기화하기 까다로움
• 의존성 관리 복잡: 공통으로 사용하는 라이브러리나 설정 파일을 여러 저장소에 중복 관리해야 할 때 버전 충돌 가능성 있음 (A와 B 프로젝트가 동일한 공통 라이브러리를 사용하는데, A는 라이브러리의 최신 버전을 요구하고 B는 이전 버전을 유지해야 할때)

해결방안

• 공통 코드 관리: 각 저장소에서 사용하는 공통 코드를 별도의 라이브러리로 추출하고, NPM 패키지나 PyPI 같은 패키지 관리 시스템에 배포하여 버전 관리를 체계적으로 수행
• 의존성 관리 자동화: Dependabot이나 Renovate 같은 도구를 사용해 각 저장소의 의존성을 자동으로 업데이트하고 충돌을 최소화

모노레포 vs 멀티레포

모노레포를 사용하는 회사

• Google: 대규모 코드를 모노레포 방식으로 관리하며, Bazel 같은 빌드 도구를 사용
• Facebook: 모든 프로젝트를 모노레포 방식으로 관리하여 일관된 코드베이스 유지
• Uber: 여러 플랫폼에서 공통 코드를 효율적으로 관리하기 위해 모노레포를 채택

멀티레포를 사용하는 회사

• Amazon: 서비스가 분리된 독립적인 팀 구조(소위 "Two Pizza Team")를 기반으로 멀티레포를 사용
• Netflix: 독립된 마이크로서비스 아키텍처를 채택하여 각 서비스가 별도의 저장소에서 관리됨
• Microsoft: Windows, Office 등 여러 제품군을 개별적으로 관리하기 위해 멀티레포를 활용

모노레포와 멀티레포의 선택 기준

• 모노레포: 프로젝트 간 강한 연관성이 있거나, 공통 코드를 많이 공유해야 하는 경우
• 멀티레포: 각 프로젝트가 독립적이며, 팀별로 자유로운 기술 선택과 관리가 필요한 경우

장단점이 명확하기 때문에, 회사의 팀 구조와 프로젝트 요구 사항에 따라 선택하는것이 좋겠다!

(상세한 내용은 참고 자료 링크 모던 프론트엔드 프로젝트 구성 기법 - 모노레포 개념 편에 더 자세히 나와있다)

참고자료, 이미지 출처

https://d2.naver.com/helloworld/0923884

협업 프로젝트를 하면서 각자 기능에 따른 새로운 브랜치를 파서 작업한다

이때 주의해야할 점을 경험으로 깨달아 적어둔다

git pull 에서 오류가 나지 않게 하려면

1. develop branch 에서 먼저 git pull 로 데이터를 받아온다
2. 내가 작업할 새로운 브랜치를 판다
3. 새 브랜치에서 git merge develop 해서 데이터를 병합한다
4. 작업한다

참고로 여기서 develop은 필자가 작업하기로 한 메인 브랜치(default branch)다

만약 default branch의 이름이 main 이라면 똑같이 이름만 바꿔 진행하면 된다!

프로젝트를 해보니 생각보다 깃에서 꼬이고 삽질하는 리소스가 많이 소모된다

사용법을 잘 익혀야겠다

Mac 을 새로 급하게 산 뒤 초기 세팅 중 우여곡절 끝에 힘겹게 홈브루를 설치하고..

맥은 깃이 자동으로 깔려있다고?!

git --version

깃버전도 확인했다

git clone URI

깃 클론도 완료!

자이제 해볼까

?!

아 이것은 현재 폴더에 깃에 대한 정보를 담은 파일 .git 이 없었기 때문이었다

깃이 바로 우리 파일에 대한 로그를 저장하는건데 그게 없으니까!

해결법은 간단하다 깃을 설정해주면 된다

$git init

완료!

결론부터 말하면 푸시를 되돌리는 법은 없다

당신이 푸시를 한순간 부터 커밋메세지는 영원(?)하다. 희망을 버려라 (깃허브에 메일보내면 해줄지도?!)

푸시는 되돌릴수 없지만 잘 못 올라간 파일을 삭제할 수는 있다!

(밑에는 Tmi, 좀 하단으로 가면 명령어 나옵니다)

React 프로젝트를 처음 하면서 먼저 HTML, CSS 부터 마크업을 시작했는데,

초반에 커밋메세지를 잘못 입력해 수정(덮어쓰기)해보기도 하고

마침내 파일을 푸시하게 되는데... 어라?

분명 git add 파일명 으로 한 파일만 추가후

git status 로 확인까지 했건만, 전에 커밋했었던 HTML까지 같이 올라간게 아닌가?!

일단 이 상황을 팀원분들께 공유했다

해결해달라는 의미는 아니고 이런 이슈가 있었다는 공유 목적에서 말이다

그리고 만약 다른사람이 나와 같은 실수를 할 수도 있고,

해결방법을 다른 사람이 알면 더 빠르게 해결도 가능하다

여담으로 이런 사소한 부분이라고 생각되는 것들도 팀원들끼리 공유해서 나쁠게 없다고 생각한다

직장 생활과 인생을 통틀어 사단은, 꼭 그런 사소하다고 생각하는 점을

공유하지 않거나 하는 실수로부터 일어났기 때문이다

아무튼, 이슈 상황 공유하고 찾아보는데

강제로 덮어씌우는 명령어들이 주로 나와 팀원과 상의해야한다는 글을 보고 그것 또한 공유했다

다행히도 팀원분들이 적절한 해결책을 빠르게 찾아 주셔서 이 명령어로 잘못 올린 파일은 삭제할 수 있었다!

잘 못 push 푸시한 파일 삭제

git rm 삭제 할 파일명
git commit -m'잘못 올라간 파일 삭제'
git push

커밋 내역은 남았지만 파일은 삭제할 수 있었다

이래저래 확실히 프로젝트를 하면서 협업을 통해 얻게 되는 경험은 매우 중요한 것 같다!!!

 

본격적인 프로젝트 시작

깃 클론부터 삽질아닌 삽질하다가

드디어 HTML 부터 마크업을 하고 커밋을 무심코 해버리는데...

아, 커밋 컨벤션이 있었지;

커밋을 취소하는 방법도 구글링하면 나오지만 나는 덮어쓰기를 해보고 싶었다

git commit --amend -m "변경할 커밋 메세지"

초간단

커밋메세지가 잘 변경되었는지

git log

를 입력해 확인할 수 있다

커밋메세지를 막상 쓰려니 은근 고민하는데 시간이 걸렸다

협업하는 동료들이 한눈에 알아 볼 수 있게 상세하고 간결한 메세지를 작성하도록 하자

커밋 메세지 참고글

• https://www.atlassian.com/ko/git/tutorials/rewriting-historyhttps://meetup.toast.com/posts/106
• https://meetup.toast.com/posts/106https://github.com/nurimeansworld/strawberry_market/issues/3
• https://github.com/nurimeansworld/strawberry_market/issues/3
• https://velog.io/@ninto_2/%EC%BB%A4%EB%B0%8B-%EC%BB%A8%EB%B2%A4%EC%85%98

깃과 깃허브를 언젠간 잡아야지 하다 마침내 때가 된것 같다

어떻게? 공부하는 방법으론

1. 시중에 있는 좋은 영상들
   (더구나 깃&깃허브는 요약강좌도 많다)
2. 책으로 공부

이렇게 크게 두가지가 아닐까?

여기, 영상도 보고 책으로도 자세히 공부하는 방법이 있다

타입스크립트 공부할 때 많이 도움받았던 두잇 시리즈!!

목차를 보면 완전 처음 설치하는 시작 단계부터 협업과 소통을 위한 응용 단계까지 있는 걸 알 수 있다

또, 혼자하기 쉽게 진도 계획표까지 짜여져있어 공부하기 편하다

Main 브랜치의 어원과 같은 '한걸음 더!' 섹션의 내용들이 흥미롭고 재밌었다

README 파일을 위한 마크다운까지 알려준다

공부하기 너무 좋다고 느낀점이 이렇게 장마다 퀴즈가 있어서 개념을 꾹꾹 담아주고

Do it! 스터디룸 카페를 운영해 스터디를 열어주고 질답도 가능한게 큰 이점이라고 느껴졌다

게다가 이번 깃허브 책은 이고잉님의 강의를 기반으로 만들어져

혼자하다 이해가 안가는 내용이 있다면 그 부분만 영상강의로 보아도 좋다 (물론, 다 보아도 좋다. 갓활코딩!갓고잉!)

*이지스퍼블리싱의 깃&깃허브 입문 서평단에 선정되어 책을 제공받았습니다 :)