git submodule을 통해 yml 파일과 같은 노출되면 안 되는 정보들을 한꺼번에 관리할 수 있었다.

이제부턴 설정 정보들을 추가하거나 수정해야 할 일이 생긴다면 submodule repo에 가서 수정하고, 해당 수정 이력을 메인 프로젝트에 반영만 하면 된다.

메인 프로젝트에 반영하는 작업을 진행해 보자.

순서는 다음과 같다.

  1. submodule 코드 변경
  2. Main 프로젝트 반영
  3. 해당 이력 Main 프로젝트에서 commit 후 push
  4. copyPrivate 실행 후, 복사한 해당 이력은 gitignore 처리
  5. Main 프로젝트 run으로 확인

1. submodule 코드 변경


submodule repo에서 수정사항이 있다거나 추가할 내용이 생기면, 아래의 초록색 박스 칸을 눌러 Github에서 수정하고, 화면 맨 아래의 commit 버튼으로 commit 한다.

image

image


2. Main 프로젝트에 반영


다음으로, 메인 프로젝트에서 submodule을 갱신시켜줘야 한다. 다음과 같은 명령어를 입력한다.

git submodule update --remote $ {submodule_repository_name}

image

❌ 위의 과정이 바로 실행되지 않을 수 있다. ❌

그렇다면, 다음의 명령어를 먼저 입력한 뒤에 위의 과정을 진행해보길 바란다.

git submodule update --init

Git submodule 사용하기 를 참고하자.


3. copyPrivate 실행 후, 복사한 해당 이력은 gitignore 처리

submodule 처음 적용시켰을 때와 마찬가지로 변경사항이 Main 프로젝트에 반영된 것처럼 보이지만 실제로는 아닌 상황이다.

copyPrivate task 버튼을 눌러서 실제로 변경사항이 반영되게끔 해준다.

image

copyPrivate task 실행을 하고 나면, 다음과 같이 실제로 submodule의 변경사항이 적용되어 Main 프로젝트에서 바라보는 submodule도 최근에 변경한 이력으로 바뀐다.

image


4. 해당 이력 Main 프로젝트에서 commit후 push


submodule을 Main 프로젝트에 복사하여 갱신을 먼저 했으면, 해당 변경사항을 진짜 push 해주어야 한다.

현재 상태는 local에선 반영되었지만, main에 merge된 상태는 아니다.

git status 명령어를 입력하면, 새로 commit된 submodule이 보일 것이다.

image

해당 이력을 commit하고, push 해준다.

이제 진짜 submodule에서의 변경사항이 적용되어서 배포될 것이다.

🚨 물론, 3번 과정에서 복사한 application-dev.yml 파일은 gitignore 처리해주어 commit 이력에 포함되지 않도록 해야한다. 🚨

image

merge와 배포에 성공하면 이렇게 변경사항이 일치된 상태로 바뀐다.

image

image


5. Main 프로젝트 run으로 확인


이제 정상적으로 빌드되는지 확인만 하면 된다.

image


6. 협업 시 주의할 점

🚨 추가적으로, 혼자 작업을 하는 것이 아닌 팀 작업을 하는 경우에 누군가 위의 1~5 번 과정을 거쳐서 성공했다면, 다른 사람들도 현재 작업하는 branch에서 2,3 작업을 즉시 실행하는 것을 권한다.

그리고, 본인의 작업을 마무리하고, 4,5 과정을 거치면 문제가 되는 일은 없을 것이다. 🚨


References

Leave a comment