application.yml 파일들에는 중요한 정보가 있어서 git submodule을 이용해 관리합니다.
git submodule 설정과 설정 파일 위치는 크러쉬가 완료 했습니다.
팀원분들은 사용하는 방법에 대해 숙지하고 계시면 좋을 것 같습니다.
일단 큰 흐름을 말씀드리면
프로젝트 루트 디렉토리 밑에 config 디렉토리에 모든 설정 파일들을 관리합니다. (config 디렉토리가 git submodule로 관리되고 있는 디렉토리입니다.)
config 밑에 둔 이유는 스프링이 설정 파일을 스캔할때 resource 디렉토리와 루트 디렉토리에 있는 config 디렉토리를 기본적으로 스캔하기 때문에 config 파일 밑에 설정 파일을 관리하기로 결정했습니다. 따라서 팀원 분들은 resource 디렉토리에 설정 파일을 두었을때와 사용 방법이 동일할 것입니다.
- 참고
- git submodule을 사용하면 Jenkins에서 소스코드를 가져오는 과정에 변화가 필요해 보입니다.!
각자 프로젝트에 git submodule 도입하기
제가 생각하기로는 각자 로컬은 현재 git submodule이 도입되지 않은 상황일 것 같습니다. 하지만 clone은 되어있다고 가정하겠습니다.
// submodule 초기화 % git submodule init // 메인 레포지토리가 기억하는 submodule의 특정 커밋 시점으로 업데이트 % git submodule update
위 두 명령어를 이용하면 git submodule 설정이 완료됩니다.
만약 아직 clone 하지 않은 상황이면
% git clone --recurse-submodules {project_url}
를 사용하면 됩니다.
submodule에 변경이 있는 경우
// .gitmodules 파일에 정의되어 있는 브랜치(default는 main 또는 master)의 최신 버전으로 업데이트 % git submodule update --remote // 로컬에서 작업 중인 부분과 원격에 작업된 부분이 다른 경우 머지까지 진행 % git submodule update --remote --merge
git pull 할때 한번에 끌어오기!
% git pull --recurse-submodules
- 주의사항
- 프로젝트 submodule에 변경이 생겼다면 한 가지 주의할 사항이 있습니다.
메인 프로젝트보다 먼저 Push 또는 Pull을 해야합니다. 그렇지 않고 메인 프로젝트를 push/pull하고 submodule을 push/pull 하면 예상치 못한 오류가 발생할 수 있습니다. (왜냐하면 메인 프로젝트는 submodule을 그대로 가지지 않고 path, url, commit 정보만 저장하기 때문입니다.)
