.gitmodules

• 어떤 파일을 submodule로 쓰고 있는지 정의
• 루트 디렉토리에서 git submodule init : 이 파일을 읽는다
• 루트 디렉토리에서 git submodule update : 현재 브랜치의 루트 디렉토리에서 참조하고 있는 submodule의 commit에 해당하는 파일을 가져온다

.gitmodules

[submodule 이름]
path = submodule/이름 
url = 깃헙 이름

• 해당 파일을 이 디렉토리에서 저장하고 관리하는 게 아니라 그쪽 디렉토리까지 가서 가져오는 거니까 submodule 폴더로 들어와서 접근 가능

submodules

• remote
• local

remote의 어느 커밋에서 로컬로 가져온다
로컬에서 코드를 작성한다

submodule에서 새로운 코드 작성 시

: submodule에서 관리하고 있는 외부 디렉토리에 업데이트를 해야 한다
: (지금 작성하고 있는 브랜치에서만 유효하고 싶으면) 해당 submodule 파일에 branch를 새로 만들어서 commit하고 remote에서 mr을 통해 올린다
: 루트 디렉토리로 가서 submodule에 생긴 새로운 커밋을 참조하도록 루트 디렉토리에서도 새로운 커밋을 만들어준다

유의할 점

나는 브랜치별로 독립적이라고 생각을 했는데, 로컬에서 브랜치들은 파일을 공유하고 있기 때문에 완벽하게 독립적이지는 않다. 한 브랜치에서 다른 브랜치로 switch를 할 때도 해당 브랜치에서 만든 변화들을 커밋하지 않으면 변경할 수 없는 것처럼, 기존 브랜치의 상태에서 변화만큼 +/- 되는 느낌이다

그러니까 두 브랜치가 같은 submodule을 공유하지만 submodule의 다른 commit을 각각 참조하고 있으면 해당 submodule 폴더 안 diff로 나타날 수 있다. 이때 git submodule update를 하면 이전 커밋이든 뒤에 추가된 커밋이든 상관 없이 가리키고 있는 커밋으로 옮겨준다. 로컬에 없는 커밋이라고 하더라도 remote에 있는 submodule에 있는 것을 가져와준다

순서

1. root에서 git pull
2. conflict해결하고
3. git submodule update : 루트에서 저장하고 있는 커밋으로 submodule에서 받아온다 4. node-common-module로 관리하는 파일에 변경사항이 있으면 npm install로 다시 다운받기
4. 루트에서 (1),(2)를 commit해줘야한다 (merge를 끝내기 위해서)
   cf. 커밋을 따로 하기 싫으면 이전 커밋에 합치는 방법이 있다 : squash(참고: https://cjh5414.github.io/git-rebase/)

이미 가지고 있는 커밋에 변경을 준 새 커밋 가져오기

1. head를 10개 뒤로 간 다음에 새로 pull
2. 원래 브렌치 삭제하고 checkout -b로 새로 만들어서 git checkout origin/jyoh/reaction