어떤 기기에서든 hexo 블로그를 업데이트 하기 위해서는 hexo 프로젝트와 hexo 테마를 백업을 해야 한다.
그 이유는 hexo 프로젝트를 통해서 배포를 할 때, 올라가는 데이터들은 웹사이트을 구동시킬 때 필요한 데이터들이 USERNAME.github.io 에 올라 가는 것이기 때문이다.
즉, hexo 블로그를 만들면서 포스팅 했던 데이터들은 github에 올라가지 않는다.
따라서 별도로 hexo 프로젝트를 백업할 필요가 있다.
어디서 백업을 해야할까?
다시 한번 말하자면, hexo 프로젝트 안에 있는 데이터를 보관하기 위한 새로운 저장소를 만들어야 한다.
github 을 이용하든 gitlab을 이용하든 상관은 없다.
하지만 배포를 할 떄 github을 이용했고, github에서 현재 private도 무료로 서비스를 제공하기 때문에 github을 사용하는 것이 좋다.
저장소를 만들 때,
private를 선택하든, public를 선택하든 상관은 없다.
자신의 데이터를 공개하고 싶지 않다면, private를 선택하는 것이고, 자신의 데이터를 공개해도 좋다고 하면, public을 선택할 뿐이다.
새로운 저장소 생성
저장소는 총 2개가 필요하다. 하나는 테마를 보관할 곳, 또 다른 하나는 hexo 프로젝트를 보관할 곳이다.
저장소의 이름은 사용자가 구분하기 쉽고, 쉽게 이용할 수 있는 이름으로 정하면 된다.
나 같은 경우에는 설명하기 쉽게 hexo 프로젝트를 저장할 공간인 blog 테마를 저장할 공간인 theme 라는 이름으로 만들었다.
hexo 프로젝트 백업하기
hexo 프로젝트를 백업하는 방법은 간단하다.
다음처럼 git을 만들어 주기만 하면된다.
1 |
|
테마 백업하기
직접 만든 경우에는 상관은 없지만, 다른 사람들이 만든 테마 같은 경우에는 백업하기가 힘들다.
fork를 하든, duplicate를 하든 상관이 없다.
어차피 원래의 테마 개발자가 업데이트를 하고, 우리가 그것을 따르고 싶다면, 우리가 설정했던 것들은 날라가기 때문이다.
-> 그럴 경우에는 자신이 설정했던 파일들을 따로 백업을 하는 것이 좋음.
그렇지 않고, 그 테마를 가지고 스스로 수정하고 싶다면 fork를 하는 것이 좋을지도 모른다.
일단은 duplicate를 했을 때를 생각해보자.
원하는 테마를 고르고 duplicate를 하고, 저장소 위치를 우리가 theme를 만들고자 했던 곳으로 바꾸고,
안에 있는 데이터들을 올리기만 하면된다.
1 | # clone theme |
서브모듈 추가하기
테마 폴더를 hexo 프로젝트에 push 하기 전에 고려해야할 점이 있다. git안에 git이 있는 경우 서로의 독립성을 유지하면서 서로의 버전을 따로 관리 하기 위해서 서브모듈로 추가해서 관리하는 것이 필수이다.
서브모듈에 대한 자세한 설명은 아래의 블로그를 참고하기 바란다.
그럼 서브모듈을 hexo 프로젝트에 추가해보자.
먼저 hexo 프로젝트로 이동을하고, hexo 프로젝트 안에 있는 themes 폴더에 테마를 서브모듈로 추가한다. 그 후에 제대로 변경이 되었는지 확인을 하고 변경된 내용을 push 하면 된다.
1 |
|
마지막으로…
이러한 작업을 거치면 github에서 hexo 프로젝트와 테마를 관리해주기 때문에 데이터가 날라가도 다시 복구를 할 수가 있다.
데이터가 날라갔을 떄, 복구하는 방법은 다음과 같다.
먼저 hexo 프로젝트를 불러온다. 그 후에 서브모듈을 초기화 시키고 업데이트 시켜서 서브모듈의 데이터들을 가져온다. 서브모듈은 또 다른 git으로 이루어져 있기 때문에 그 독립성과 버전 관리를 위해서 데이터를 포함하고 있지 않기 때문이다. 마지막으로 local hexo를 다시 설치해줘야 한다.
1 | git clone https://github.com/777bareman777/blog |
진짜 마지막으로…
변경된 사항을 github에 push를 하기 전에 Slave(submodule) 먼저 push를 한후 Master(iriginal git)을 push를 해야 한다.
Master -> Slave의 순서로 commit을 하게 되면, 다시 한번 더 Master에서 변경사항이 있다는 것을 알게 된다.
이렇게 작동 하는 이유는 Slave가 Master를 바라볼 때 Abstraction되는 방식으로 관리하기 때문이다.
Slave에서 변경된 사항은 Master에서 commit 할 때, 파일들을 Tracking 하는 것이 아니라 Slave의 HEAD가 무엇으로 변경되었는지에 대한 정보만 기록하기 때문이다.