Github repository 설계

[code]

github repository 설계 어떤식으로 하시나요?

우선 저희는 .net wpf 프로그램을 개발 중이고
exe 프로젝트가 두개 있습니다.

exe 들은 lib 프로젝트들을 참조 하고 있는데
공통으로 참조하는 것들도 있고
각각 참조하는 lib 프로젝트도 있습니다.

거의 대부분의 코드 수정은 lib에서 발생하고
exe 는 껍데기 수준이라 메뉴나 커맨드 같은 것들만 수정 됩니다.

지금 문제 되는 것이 모든 프로젝트가
하나의 솔루션에 하나의 repository에 모여 있다 보니
이슈 관리가 지저분해 지고 있습니다.

현재는 라벨로 구분 하고 있긴 한데
A exe에 있는 이슈랑 B exe 이슈를 분리 하고 싶고
lib는 한곳에서 수정 하고 싶은데

다른 분들은 어떤식으로 구성 하시나여?

[Vincent]

그 제품에 묶여있는 기능이 아니라 회사 전역에서 쓰는 기능이거나, 아무튼 현재 프로젝트와 직접적으로 “아 이 코드는 여기에 있어야만 해” 라고 생각하는게 아니라면 다른 모듈 프로젝트로 전부 쪼개서 그걸 저장소에 저장하면 되지 않을까 싶습니다.

예를 들어서 뭐…

확장메서드라던지, 도메인과 무관한 것들이라던지…저같은 경우는 게임 데이터를 다루면서 Excel을 빡쌔게 다뤄야하지만 아무리 Excel을 빡쌔게 다룬다고 하더라도 그게 메인 프로젝트 안에 있을 필요는 없어서 Excel 모듈로 빼놨습니다.

저장소를 하나씩 쪼개는 것도 좋지만 우선적으로 클래스가 RDD 기반으로 쪼개져있으면 저장소도 나누기 쉬울 것입니다.

[파란매]

브랜치 전략
GIT Flow 전략
방법론이 많습니다.
소규모일때는 브랜치 전략으로 가다가
좀 규모가 커지며 거기에 Flow 가죠
찾아보시며 강좌도 많고 개념도 어렵지 않습니다.
거기에 애자일 스프린터 같은것도 참고해보시고요

[code]

감사합니다. 한번 찾아 보겠습니다.

[활어회소주원샷우럭두개더]

공통 코드들은 따로 빼서 저장소에 넣고, 거기서 나오는 어셈블리들은 회사 내부 서버 누겟으로 관리하면 갸꿀입니다.

[HyoSeong_Lee]

lib 수정이 잦으시다면 Git SubModule 추천드립니다 ㅎㅎ
빌드된 결과물(dll)을 참조하는게 아닌 프로젝트(코드)를 직접 참조할 수 있다보니 디버깅 및 수정이 좋은 것 같아요.

[code]

감사합니다!