Summary
개요
프로젝트를 진행하며 서브모듈의 정보를 수정할 일이 꽤 자주 발생했다.
당시에는 서브모듈 수정 방법이 익숙하지 않았기 때문에 서브모듈을 수정하려다 커밋이 꼬여버리고 말았고, 인터넷 서치를 통해 꼬여버린 서브모듈 커밋을 해결하는 방법을 찾아봤지만 그와 관련된 게시글은 찾지 못했다.
결국 스스로의 지능을 사용해 해결했기 때문에 또 다시 헤매는 일이 없도록 기록해두려 한다.
서브모듈 사용 이유
외부에 공개해선 안되는 민감 정보들을 처리하는 방법은 여러가지가 있다. 프로젝트 초기, 이런 민감 정보들을 처리하기 위한 제시된 방안들은 아래와 같다.
- dev.yml 파일을 gitignore 처리한 후 변경사항이 생길 때마다 덮어쓰기한다.
- Github Secret에 민감 정보 데이터를 저장한다.
- dev.yml 파일을 jasypt을 사용해 암호화 한 후 public하게 공개한다.
- 서브모듈로 관리한다.
결과적으로는 4번 서브모듈을 사용하는 것으로 결론이 났다. 나머지 방안이 반려된 이유는 아래와 같다.
1 민감 정보를 gitignore 처리한다.
이전 프로젝트에서 사용한 적이 있는 방식었다. 경험상 yml 파일을 git으로 관리하지 않기 때문에 변경이 발생하는 경우 따로 모든 팀원에게 공유해야했고, 이런식으로 파일이 동기화 되지 않아 에러가 발생하는 일이 빈번했다. 번거로운 방식이라 생각했기에 채택되지 못했다.
2 Github Secret에 민감 정보 데이터를 저장한다.
Secret으로 관리하는 경우 한번 저장한 데이터를 다시 확인하지 못하기 때문에 어차피 다른 곳에 따로 백업해두어야 한다. 1번 방법과 다르게 변경 사항이 발생해도 오류가 나진 않지만 팀원들이 백업한 yml 정보를 수정하려면 또 따로 보내줘야 한다는 점이 1번과 다를 바 없었다.
(단, cicd 스크립트 같은 경우 Secret에 저장된 데이터를 사용하고 있다. 어차피 관리하는 인원이 나 혼자라서…)
3 jasypt을 사용한 암호화
이 방식은 다른 프로젝트인 ‘세차새차’에서 사용하고 있는 방식이다. key값을 알고있지 않으면 decode할 수 없으니 private로 관리할 필요가 없다는 장점이 있다.
그러나 yml 파일에서 문제가 발생할 경우 원본 값을 알아보기 위해서는 디코딩하는 과정을 거쳐야 한다는 번거로움이 있었다. 또한 yml 파일을 바로 이해할 수 없다는 점도 답답했다.
이러한 이유 때문에 민감정보 처리 방식으로 서브모듈이 채택되었다. 다른 방식과 다르게 서브모듈은 yml파일이 수정될때마다 따로 공유해줄 필요가 없고, 외부에 공개되지 않으며, 암호화 되지 않아 개발자가 바로 보고 이해할 수 있다는 장점이 있다.
다만 정보를 업데이트 하는 방법이 다소 번거롭다는 단점이 있는데, 이 부분은 그 방법만 제대로 숙지하면 그닥 어려운 내용이 아니다.
아래로는 서브모듈의 정보를 수정하는 방법과 커밋이 꼬였을 때의 해결 방법을 작성할 예정이다. 서브모듈 연결 방법은 인터넷에 널렸으니 따로 찾아보자…
서브모듈 정보 업데이트
처음부터 완벽하게 서브모듈을 작성하면 좋겠지만! 프로젝트를 진행하며 민감정보를 수정할 상황은 무조건 생긴다. redis나 rabbitMq와 같은 기술을 새로 도입할 수도 있으며, 설정 등에 문제가 생겨 기존값을 수정해야할 상황이 발생하게된다.
doore 같은 경우는 cors 설정, oauth 설정 등의 변경 등을 위해 서브모듈을 수정해야 하는 경우가 많았다. (구글 소셜 로그인 오류 해결 참고…^^;)
서브모듈 레포 수정
위는 doore의 개발서버에서 사용하는 서브모듈 yml 파일이다.
구글 소셜 로그인 오류 해결을 진행하며 서브모듈의 redirect-uri을 올바른 uri로 수정해야 하는 상황이 생겼다.
가장 추천하는 방법은
왜냐면 로컬에서 직접 서브모듈을 수정하게 되면, 수정 후 푸시하는 과정에서 서브모듈의 커밋 연결이 잘못되는 경우가 많았기 때문에… (물론 이것도 제대로 연결하면 되는 일이지만, 레포에서 직접 수정하고 동기화 하는 편이 훨씬 쉽고 편하다.) 혹시나 이런 문제가 발생한 경우에는 3. 서브모듈 연결 수정을 참고하자.
위와 같이 레포에서의 직접 수정이 불가능하다는 메세지가 뜰 수가 있는데, 이 경우 현재 브랜치가 main 브랜치가 아닌 특정 commit hash 에 위치해있는 경우일 수 있다. main 브랜치로 이동 후 수정해주자.
서브모듈 레포에서 수정 후 커밋했다. 00c0의 새로운 커밋이 생성된 것을 확인할 수 있다.
서브모듈 최신 커밋 반영
그러나 수퍼레포에 연결된 commit hash은 여전히 과거 커밋인 1436을 향하고 있다. 수퍼레포에서도 서브모듈 레포의 변경사항을 반영해주기 위해서 최신 commit hash로 연결해야 한다.
git submodule update --remote 명령을 통해 최신 서브모듈로 업데이트가 가능하다.
메세지를 확인해보면 00c0 커밋의 변경사항을 가져온 것을 확인할 수 있다.
이제 평범하게 add,commit,push 해주자.
서브모듈로 연결된 commit hash가 수정되었다.
서브 모듈 켜밋이 꼬여버린 경우
그러나 git submodule update --remote으로도 최신 서브모듈의 커밋을 가져오지 못하는 경우가 발생할 수 있다.
예를 들어 위에서 언급했듯 레포가 아닌 코드상에서 서브모듈을 수정했다가 서브모듈과 수퍼모듈의 커밋이 꼬여버린 경우라던가… 그게 아니라도 커밋이 꼬이면 서브모듈 업데이트로는 해결이 어렵다.
이때는 직접 서브모듈의 commit hash를 바꿔주는 걸로 해결할 수 있다.
서브모듈 폴더로 이동
doore의 경우 서브모듈은 resources/config폴더로 연결되어 있다. 서브모듈이 연결돼있는 폴더로 이동하자.
브랜치 확인
git branch를 통해 현재 브랜치가 무엇인지 확인하자.
한참 과거의 커밋에 연결되어 커밋이 꼬여버린 것을 확인할 수 있었다. 가장 최신 커밋은 0fa4이다.
브랜치 변경
git checkout <branch명>을 통해 최신 커밋으로 이동하자.
이것으로 꼬여버린 커밋이 해결되었다. 이후 다시 기존 폴더로 이동한 후 add. commit, push하면 서브모듈의 변경사항이 반영된다.