Polpid's Pensieve

Git 을 사용하면서 pull 을 받을때 다른 브랜치를 pull 받는 경우가 있다.

예를 들어서 나는 현재 A 브랜치에서 작업을 하고 있다. 그런데 B 브랜치의 내용을 A 브랜치로 pull 을 받아야 한다. ( 왜 이렇게 사용하냐고 묻는 다면.. 어쩌다 보니 이렇게 사용하게 됐다..)

그래서 한가지 궁금한게 생겼다. 

다른 브랜치를 pull 받는것과 merge 하는것과 차이가 있을까???

그럼 한번 실험을 해보자.

- master 브랜치, dev01 브랜치 생성

먼저 위 그림을 보자. 위 상황은 다음과 같다.

1. master 브랜치에서 test1.md 파일 생성후 커밋

2. dev01 브랜치 생성

3. dev01 브랜치에서 test2.md 파일 생성

- dev02 브랜치 추가 , test3.md 파일 추가 

그럼 위와 같은 상태가 된다.

- dev01 브랜치로 돌아가서 test2.md 파일 수정

1. dev01 브랜치로 checkout

2. test1.md, test2.md 파일 수정

3. 커밋

- dev02 브랜치로 가서 dev01 브랜치 pull

dev02 브랜치에 있는 tet1.md 파일과 test2.md 파일은 변경이 되지 않은 상태이다.

여기에서 다음가 같이 명령어를 쓴다.

git pull . dev01

리모트 저장소에 push 된 상태라면 명령어는 다음과 같이 된다. (지금 화면에서는 내가 리모트 저장소에 push 를 안한 상태로 local 만 사용중이기 때문에 . 을 사용한다.)

git pull origin dev01

음??  merge 를 한다고 나오네??

저장을 하게 되면 Git graph 는 다음과 같이 나온다.

결과적으로 서로 다른 브랜치에서 pull을 하게 되면 merge 를 하는것과 동일하게 동작을 한다.

-  Merge 확인해보기

dev03 브랜치를 만들어서 dev01 로 merge 를 해보자.

dev03 브랜치에서 test4.md 파일을 만들고 커밋을 했다.

dev02 에서 merge 를 한다는 것이 dev01 에서 merge 를 해서  dev01 도 표현이 되었다.

위와 약간 차이가 있어서 다시 해보겠다.

위 사진은 다음과 같이 실험한 결과이다.

1. dev02 브랜치에서 test5.md 생성 후 커밋

2. dev03 브랜치 checkout

3. dev03 브랜치에서 test4.md 파일 수정 후 커밋

4. dev02 브랜치로 다시 checkout

5. dev02 브랜치에서 dev03브랜치 merge

결과적으로 아래 Merge branch 'dev01' into dev02 와 동일한 그래프가 나타난다.

내가 내린 결론은 현재 브랜치에서 다른 브랜치를 pull하게 되면 merge와 동일한 동작을 하게 된다 라는 것이다.

....  혹시 글을 읽고 잘못된 점이 있으면 댓글로 알려주세요. (제가 잘못 이해한것 일수도 있어서..)

1. icarusn 모듈 설치

먼저 로컬에 있는 blog 소스가 있는 폴더 안에서 git submodule 을 추가해준다.

내가 설치하려고 하는 테마는 icarus 라는 테마인데 설치 방법은 여러가지가 있다.

Document를 보니 git submodule 을 추가하는 방법도 있고 npm 으로 설치하는방법도 있다.

git submodule add https://github.com/ppoffice/hexo-theme-icarus.git themes/icarus

이렇게 하면 blog 하위에 themes 폴더 안에 icarus 라는 항목이 생긴다.

또는

npm install -S hexo-theme-icarus

나는 submodule 을 추가 하는 방법을 사용했다.

2. 설정파일 변경

_config.yml 파일을 수정해준다.

theme: icarus

3. 반영 확인

설치 완료 후 hexo server 명령어를 통해서 로컬에서 기동 시켜보면 테마가 변경 된 것을 확인 할 수 있다.

4. 에러 발생시?

혹시라도 아래와 같이 dependencies 에러가 난다면 에러난 항목들을 설치해 주면 된다.

아래 bold 처리한 부분을 설치해 주면 된다.

INFO  === Checking package dependencies ===
ERROR Package bulma-stylus is not installed.
ERROR Package hexo-renderer-inferno is not installed.
ERROR Package hexo-component-inferno is not installed.
ERROR Package inferno is not installed.
ERROR Package inferno-create-element is not installed.
ERROR Please install the missing dependencies your Hexo site root directory:
ERROR npm install --save bulma-stylus@0.8.0 hexo-renderer-inferno@^0.1.3 hexo-component-inferno@^0.10.1 inferno@^7.3.3 inferno-create-element@^7.3.3
ERROR or:
ERROR yarn add bulma-stylus@0.8.0 hexo-renderer-inferno@^0.1.3 hexo-component-inferno@^0.10.1 inferno@^7.3.3 inferno-create-element@^7.3.3

5. git submodule 관련 사항

- 설치 잘못해서 재 설치시 나왔던 에러

git 레파지토리에 submodule을 추가했다가 제거한 후 다시 추가 하려고 하니 다음과 같은 에러가 발생했다.

A git directory for 'themes/icarus' is found locally with remote(s):

그런데 분명한것은 현재 로컬에는 저 폴더가 없는 상태이다. 하짐나  .git/modules 하위에 themes/icarus 라는 폴더가 남아있었다. 그래서 그 폴더를 삭제한 후 submodule  을 추가 하니 정상적으로 동작을 했다.

- 다른 곳에서 submodule 을 포함한 소스 내려 받기

최초 내려 받기 : git clone --recursive git_url

이미 내려받는 곳에서 submodule 만 받기 : git submodule update --init --recursive

참고 사이트 

github.com/ppoffice/hexo-theme-icarus

blog.zhangruipeng.me/hexo-theme-icarus/uncategorized/getting-started-with-icarus/

www.vogella.com/tutorials/GitSubmodules/article.html

1. github 에 레파지토리 생성

레파지토리 이름은 다음과 같이 만든다.

[ID].github.io

일단 이렇게 하면 저장소 준비는 완료된다.

2. hexo 설치 (설치전에 node 는 설치 되어있다고 가정한다.)

- hexo-cli 설치 (혹시 권한 관련 Error 가 나면 앞에 sudo 추가)

npm install hexo-cli -g

- hexo 기본 구성 하기

hexo init [폴더명]

여기에서 폴더는 기존에 있던것은 안되고 새로 생성하거나 그냥 이름을 적으면 자동으로 생성해준다.

실제 폴더에 들어가면 아래와 같이 구성이 되어있다.

- _config.yml 파일 설정 하기

간단하게 다음 두개 항목만 설정해준다.

# Site (사이트 설명 : 자신에게 맞게 설정해주면 된다.)

title: Hexo

subtitle: ''

description: ''

keywords:

author: John Doe

language: en

timezone: ''

# Deployment (배포)

## Docs: https://hexo.io/docs/one-command-deployment

deploy:

type: git

repo: 위에 생성한 git 주소를 넣어주면 된다.

branch: main (안쓰면 master로 올라가는듯..)

- 로컬 실행

hexo server

이렇게 하면 기본적으로 4000번 포트로 실행이 된다.

3. github 에 배포하기

아래 명령어로 static 파일을 생성한다.

hexo generate 

그리고 deploy 를 한다.

hexo deploy

위와 같이 에러가 나면 다음과 같이 실행해준다.

npm install hexo-deployer-git --save

혹시라도 delpoy를 완료 하고 github 주소로 접속을 했는데 404 에러가 날 경우 다음 설정을 확인해 보면 된다.

Source 항목의 Branch 가 내가 실제 배포한 Branch 와 일치 하는지 확인해 본다. github 의 default 브랜치가 기존에는 master 였는데 최근에 main 으로 변경 되면서 당연히 master 라고 착각하는 경우가 생길 수 있다. (실제로 내가 그랬다.. ㅠㅠ)

4. Blog Repository 추가

이건 해도 그만 안해도 그만이다. 본인이 관리하기 쉬운쪽으로 하면 된다.

우선 실제 Blog 가 배포된 Repository 가 존재한다. (github.io 이런 이름으로)

그런데 실제 Blog 소스를 배포를 하는 작업을 하나의 PC 가 아닌 여러 PC 에서 작업을 할 경우가 있다. 그래서 이 소스를 관리하기 위한 레파지토리가 하나 더 필요 하다. 

- ~.github.io : 실재 배포 버전이 올라가는 repository

- blog : 배포를 하기위한 소스를 관리하가 위한 repository

이렇게 나누어 놓으면 어디서든지 github 에서 내려받아서 변경을 하고 배포가 가능하다. 

참고 사이트

hexo.io/ko/index.html

로컬 브랜치 삭제

git branch -d 브랜치 명

리모트 브랜치 삭제

git push origin --delete 브랜치명

가끔 이런 경우가 있다.

1. master 브랜치에서 현재 소스 기준으로 tag 를 생성한다. 

git tag release-v1.0

2. 그리고 나서 다른 작업들이 쭉~~ 진행 된다. 그러다가 갑자기 release-v1.0 에 대한 버그가 발견되었다. 그럼 어떻게 하지?? 

master 브랜치에는 신규기능을 개발중이거나 다른 작업들이 진행중이어서 bug fix 를 반영하더래도 v1.0 하고는 소스가 다른데... 구글링을 해보니 다음과 같은 절차를 이야기 해주고 있다.

git checkout -b bugfix1 release-v1.0

이렇게 한 후 버그를 고치고 commit 을 한다. 

git tag release-v1.1

그리고 버그를 수정한 거에 대한 tag 를 다시 생성한다. 이렇게 하면 이제 release-v1.1 소스를 가지고 배포를 하면 된다. 

그리고 마지막으로 현재 수정한 bug 를 master 에도 반영한다.

git checkout master

git merge bugfix1

버전관리 하면서 알아두면 유용하게 사용할수 있을것 같다. 

참고url 

https://gist.github.com/adonaldson/1205902

Git 을 사용하다 보면 branch 를 만들어서 사용하게 된다. 그런데 어느 순간 보면 branch 가 여러개로 늘어나 있고 무엇을 하던 branch 인지 조차도 기억이 안나게 된다.

그래서 branch를 삭제를 했다. 난 분명히 branch 를 삭제를 했는데..

git branch --all 을 하면 삭제된 remote 브랜치가 여전히 나온다.. 내가 안지웠나???

그래서 직접 git 사이트에 들어가 봤더니 삭제한 브랜치는 나오지 않는다..

이때 다음과 같이 실행을 하면 된다.

git remote prune origin 

이렇게 하고 다시 git branch --all 을 하게 되면 삭제된 브랜치는 나오지 않는다.

참고

https://git-scm.com/docs/git-remote

현재 브랜치와 다른 브랜치 사이에 merge가 아닌 특정 파일만 합치고 싶을때의 방법이다. 

git -p [브랜치명] -- [파일경로]

브랜치명 : 합쳐야 하는 내용들이 있는 브랜치 명을 입력하면 된다. (현재 브랜치가 아님)

파일경로 : 파일 path 를 넣으면 된다.

파일 경로 입력할때 다음과 같이 찾아보면 편리하다.

git diff --name-status [브랜치명]

이렇게 하면 현재 브랜치와 [브랜치명]에 있는 브랜치의 다른점 목록이 나온다. 

이 경로로 입력을 하면 된다. 

gitignore 파일을 작성을 했는데 이상하게도 계속 해당 파일들이 Untracked Files 에 잡혔다.

그런데 분명히 내가 작성한 gitignore 파일에는 다음과 같이 존재하고 있었다.

.idea/

.DS_Store

그래서 구글링을 해보니 아래와 같이 해결책을 제시해줬다.

https://stackoverflow.com/questions/32384473/gitignore-not-ignoring-idea-path

첫번째 시도

git rm -rf .idea/

Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.

<출처 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0>

그랬더니 다음과 같은 메세지가 나왔다.

fatal: pathspec '.idea/' did not match any files

상황을 보아 하니 rm 명령어가 Tracked 상태의 파일을 삭제하는 명령어 인데 위 파일들은 tracked 되지 않은 파일이기 때문에 없다고 나온것 같다.

두번째 시도

git clean -f -d .idea/

일단 이렇게 하니깐 Untracked 파일들이 다 지워지긴 했다.

그럼 이 명령어가 무엇을 의미하는지 한번 살펴보자.

워킹 디렉토리 청소하기

작업하고 있던 파일을 Stash 하지 않고 단순히 그 파일들을 치워버리고 싶을 때가 있다. git clean 명령이 그 일을 한다.

<출처 : https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Stashing%EA%B3%BC-Cleaning >

결과적으로 Untracked 파일들을 모두 지운다는 의미이다.... -_-;; 좀 무서운 명령어다.  설명에도 다음과 같이 써있다.

한마디로 한번 지우면 되돌릴수 없다라는 의미이다. 

문제를 해결 하긴 했지만 위 명령어를 사용할 때에는 좀 신중할 필요는 있어보인다.