DanStory

submodule이란 git 프로젝트 내에 하위 폴더 또한 git으로 관리하는것을 말하며,
공통모듈로 사용되는 폴더의 경우 관리의 효율성의 위해 submodule로 사용한다.

아래는 submodule의 개념을 알게된 계기 (TMI) 아래는 안읽어도 상관없다. 

알고리즘 문제풀때 사이트별로 문제 푼거를 git으로 관리했었는데,
요즘 문제푸는 사이트가 많아지면서 통합으로 관리해야겠다는 생각이들었다.

통합을 어떻게할까 고민하다가 2가지 방법이 있을거같아서 2가지를 정리해보았다.

Plan A. 기존 폴더들에서 .git을 삭제 한 뒤, 상위 폴더를 만들고 git repository를 생성 후 통합관리한다.

Plan B. 기존 git으로 관리하는건 그대로 두고, 상위 repository 생성 후 관리

위 두가지의 차이가 무엇일지 궁금증이 생김

Plan A의 경우 일반적인 Repository이기 때문에 패스 하고,

PlanB에 대한 궁금증이 생겼다.

내가 궁금한거

1. Plan B의 Root.git을 clone 할 경우 하위 폴더인 A.git, B.git. C.git이 딸려오는가?
(물론 Root.git에 A/B/C를 모두 add했다고 가정)

-> 안딸려옴

2. PlanB의 A.git에 commit 후 PlanB Root에서 다시 pull받으면?

-> 변경되는거 없음

3. PlanB에서 clone 받을때 딸려온 Root/A 폴더에 testA.txt 폴더를 생성후 commit하면?

-> pathspec 'testA' is in submodule 'A'라는 에러 메세지 발생

결과적으로 하위 디렉토리를 git으로 관리할경우 하위 디렉토리는 독립적으로 분리되며, 따로 관리해주어야 한다는 것을 알수있었다.

그러면 planA로 만들기 귀찮아서 planB처럼 하려고 하면 나중에 관리하기 더욱 귀찮아진다는 것.
따라서 현재 내 상황(데탑/노트북 왔다갔다 하기 귀찮아서 git으로 관리하려는 상황)에서는 Plan A가 적합하다.

그러면 PlanB 처럼 따로 하위프로젝트를 git으로 관리하는 경우가 있는데, 왜 이렇게 불편하게 독립적으로 관리할까?

우선 이렇게 하위 프로젝트를 git으로 따로 관리하는 것을 submodule이라고 한다.
불리는 이름과 같이 모듈을 독립적으로 관리하기 위함이다.

공통모듈은 여러 프로젝트에 동시 적용 가능하다는 범용성을 갖추어야 한다. 이런 공통 모듈의 경우 범용적으로 적용될 수 있는 코드만 수정하여 사용하도록 독립적으로 관리해야 효율적으로 공통모듈을 관리할 수 있다.

가령 공통모듈을 독립적으로 관리 안한다고 했을때를 가정해보자

프로젝트 A에서 공통모듈을 가지고 온 후 A프로젝트 환경에 적합하게 수정 후 commit을 치면 공통모듈 또한 변경이 된다. 그러면 이 공통 모듈은 더이상 공통모듈이 아닌 A프로젝트에서만 사용 가능하게 된다.
따라서 공통모듈을 독립적으로 관리한다면 A프로젝트에서 공통모듈 코드를 수정 후 A프로젝트 repository로 push해도 공통모듈에는 적용이 안되기 때문에, 안전하게 공통모듈을 관리할 수 있게 되는 것이다.

그래서 submodule을 사용하는 것이다.