githubPageRepository.md

github 페이지와 리포지토리

• 깃 허브 페이지의 공식문서를 보자.

리포지토리란?

리포지토리는 일반적으로 단일 프로젝트를 구성하는 데 사용됩니다. 리포지토리에는 프로젝트에 필요한 모든 폴더와 파일, 이미지, 비디오, 스프레드시트 및 데이터 세트가 포함될 수 있습니다. 리포지토리에 README 파일, 프로젝트에 대한 정보가 포함된 파일이 있는 경우도 많습니다. ^link

github 페이지의 리포지토리 크기

리포지토리는 작게 유지되고 이상적으로는 1GB 미만이며 5GB 미만을 사용하는 것이 좋습니다. 리포지토리가 인프라에 지나치게 영향을 주는 경우 GitHub 지원에서 정정 작업을 수행하라는 메일을 받을 수 있습니다.

• 깃허브에 직접 작성한 코드만 올리는 것으로는 리포지토리를 아무리 사용해도 1GB 이상 사용하기 힘들다.
• 하지만 라이브러리, 이미지, 폰트, PDF와 같은 파일은 용량이 크기 때문에 이러한 파일을 반복적으로 git으로 추가하고 변경하고 삭제하다보면 금새 리포지토리의 용량은 1GB가 된다.

라이브러리의 관리

• 자바스크립트의 경우 라이브러리는 node_modules 폴더에 저장이 된다. 라이브러리는 용량이 상당히 큰데 라이브러리 리스트는 package.json, package-lock.json에 기록이 되기 때문에 라이브러리 폴더는 깃으로 추적하지 않고 라이브러리 리스트 파일만 깃으로 추적하도록 한다.
• 라이브러리 폴더가 깃으로 추적되지 않으므로 깃 허브와 같은 원격 리포지토리에 올릴 때 라이브러리 파일의 용량을 줄일 수 있다.
• 깃으로 프로젝트를 다운로드 받았을 때 라이브러리 파일은 없고 라이브러리 리스트 파일만 존재한다. 이 리스트 파일로 별도로 라이브러리를 설치하여 프로젝트에서 의존하는 라이브러리를 설치한다.

파일 및 이미지 관리

• 프론트앤드 디자인을 하다보면 파일이나 이미지 파일을 깃 허브에 올릴 수 밖에 없는 경우가 생긴다.
• 대표적으로 깃허브 페이지를 이용한 정적 사이트(NodeJS나 php나 ruby 등의 백앤드 시스템과 상호작용이 없는)를 만들 때 요구사항이나 디자인의 변경에 따라 파일 및 이미지를 여러 번 변경하게 될 수 있다.
• 이 때 파일 및 이미지의 변경 기록을 깃으로 추적하게 되면, 새로운 이미지가 추가 될 때마다 깃의 기록에 이미지 파일이 남게 되어 깃 기록의 용량이 커지게 된다. 깃 기록의 용량이 커지게 되면 이 기록을 저장하는 원격 저장소인 리포지토리의 용량도 커지게 된다.
• 따라서 용량이 큰 파일 및 이미지는 최종적으로 결정된 사안만 깃으로 추적하도록 설정하는 것이 좋다. 또는 프로젝트 폴더에 저장하지 않고 외부 서버에 저장하여 외부 서버의 파일 및 이미지를 방법을 쓸 수도 있다.
• 서버 프로그래밍과 파일을 저장하는 용도의 클라우드의 파일 저장 시스템(ex: AWS S3)을 이용할 수 있다면, 이미지 파일을 클라우드의 파일 저장 시스템에서 이미지 파일을 가져오는 방식으로 만들어 프로젝트 폴더에서 이미지 파일을 가져오지 않도록 만들 수도 있다.
• 또 다른 방안으로는 다운로드할 파일은 압축을 해서 저장을 하고, 이미지는 고화질의 해상도가 불필요하다면 해상도를 낮추어 용량을 최대한 줄여 사용하는 방법이 필요하다.

깃 기록에서 파일 삭제하기

• 파일이나 이미지의 추가, 변경, 삭제 기록이 늘어나면 늘어날 수록 깃은 추가, 변경, 삭제 된 모든 파일이나 이미지를 기록하고 있다. 그래서 과거의 기록으로 되돌아갈 수 있는 기능을 제공하는 것이 깃의 역할이다.
• 하지만 모든 기록을 다 가지고 있기 때문에 커밋 기록이 쌓여갈 수록 용량이 점점 늘어나는 단점이 있다. 일반 코드의 경우에는 용량이 작아서 별 문제가 되지 않지만, 이미지나 파일의 경우 용량이 크기 때문에 빠르게 깃 히스토리의 용량을 증가시키고, 이로 인해 깃 허브 리포지토리의 용량도 빠르게 잡아먹는다.
• 따라서 깃 히스토리에 기록되어 있는 더 이상 사용하지 않는 파일이나 이미지를 삭제하는 방법을 사용할 필요가 있을 때가 있다. 깃 히스토리에서 파일을 삭제하는 방법은 다음 링크를 참고 하도록 하자.
• 하지만 이러한 방법은 깃을 많이 다루지 못한 사람들에게는 실수를 유발하거나 어려울 수 있기 때문에 추천하지 않는 방법이다.

웹팩으로 빌드된 폴더 올리기

• 기본적으로 웹팩을 사용할 때 개발하는 코드들은 src 폴더에 위치한다. 웹 사이트로 서버에 배포하기 위해서는 빌드를 해야 한다. 웹팩에서 빌드를 하면 dist 폴더에 여러 웹팩 옵션이 적용된 코드와 파일이 위치하게 된다.
• 프로젝트에서 필요한 모든 코드가 git으로 관리되고 있기 때문에 어떤 시점에서 빌드된 파일을 따로 저장하지 않아도 이전 기록으로 되돌아가서 빌드를 하면 빌드된 파일이 나오기 때문에 깃으로 굳이 빌드된 파일을 기록할 필요는 없다. 따라서 빌드된 폴더는 깃으로 추적할 필요가 없다.
• 또한 빌드가 되면 파일이나 이미지가 빌드된 폴더에 복사 되거나 웹팩에 의해 변환 된 결과물이 생성된다. 이 코드에느 라이브러리의 코드, 이미지, 파일 등을 개발할 때 사용한 이미지, 파일, 라이브러리를 복사해 버리기 때문에 빌드된 결과를 깃으로 추적할 경우 깃허브에 올라가는 파일의 용량이 대략 2배가 되어 버린다.
• 하지만 빌드된 결과를 공유해야 할 때가 있다. 빌드된 결과를 깃허브 페이지에 적용할 때나 중간 결과물을 개발자가 아닌 사람이 확인할 때이다. 개발자라면 빌드하는 것이 간단하겠지만 개발자가 아니라면 깃 허브에 올려서 파일을 공유하여 빌드에 필요한 준비 없이 간단하게 결과물을 확인할 수 있도록 빌드된 결과물을 깃허브에 올리는 방식을 쓰는 편이 좋다.
• 하지만 빌드된 결과물을 올리면 리포지토리의 용량이 늘어난다. 추후 리포지토리의 용량을 줄이기 위해서 빌드된 결과물의 히스토리를 삭제할 필요성도 생기는데 리포지토리의 기록에서 원치 않는 파일을 완전히 제거를 보면 삭제할 때 실수를 하게 되면 꽤나 복잡한 설정을 해야하므로 권장하기 어려운 방법을 쓰고 있다.
• 빌드된 파일을 깃 허브와 같은 원격 저장소에 올리면서도 쉽게 삭제를 하는 방법은 새로운 브렌치를 만들어서 빌드된 파일을 올리는 것이다. 빌드된 파일이 올라간 브렌치를 빌드하기 전의 코드를 관리하는 브렌치로 머지하지 않는다면 빌드된 파일이 올라간 브렌치를 삭제하는 방식을 이용하여 효과적으로 빌드 결과물을 공유한 이후 삭제할 수 있는 방법을 쓸 수 있다.
• 더 나은 방법은 빈 브렌치를 하나 만들고 빌드 파일이 생성되는 폴더만 빈 브렌치에 올리는 방식이 있다.

빌드된 결과물을 스테이징 브렌치에 올리기

• 스테이징 브렌치란 결과물을 프로덕션에 적용하기 전에 결과물의 확인 및 검증 용도로 사용하는 브렌치이다.
• 이 브렌치에 올린 결과물을 타인의 확인 및 검토를 받고 프로덕션으로 적용한다.

1. 빌드하기

   yarn run build

   • 위 명령어를 실행하여 dist 폴더에 빌드한 결과물을 만든다.

2. 빌드 폴더의 이름을 docs로 변경하기

   mv dist docs

   • 위와 같이 명령어로 만들어도 되지만 다른 방법으로 직접 폴더 이름을 dist에서 docs으로 변경해도 된다.

3. 빈 브렌치 만들기

   • 비어있는 새로운 브렌치를 만드는 명령은 git switch --orphan 새로운_비어있는_브렌치명이다.
   • 이 명령어를 사용할 때 요구사항이 있는데 깃에 의해 추적되고 있는 파일은 커밋되지 않은 파일이 없이 모두 커밋 되어야 한다는 점이다. (이 과정을 진행할 때는 git stash 등의 명령어를 사용하여 hanges not staged for commit:에 해당하는 임시 저장하도록 하자. 아래의 작업 진행 후 다시 원래 브렌치로 돌아와서 git stash apply 명령을 실행하면 임시 저장된 대상이 복구되면서 hanges not staged for commit:에 변경 사항을 가진 파일들이 표시되게 된다.)

   git switch --orphan staging

   • staging라는 브렌치를 만들어 준다. 이 브렌치는 웹 페이지로 실제로 배포하기 이전에 빌드된 결과물을 확인하기 위한 용도의 브렌치이다. 먼저 staging라는 브렌치에 빌드된 결과물을 올리고 여러 사람 또는 담당자가 해당 코드와 그 실행 결과를 확인한 이후 최종적으로 배포해도 된다고 의견이 모아졌을 때 배포 브렌치륾 만들어준다.
   • build와 같은 브렌치명을 사용할 수도 있다. 이 브렌치는 빌드한 파일만 올릴 것이기 때문에 직접 코드를 개발하는 브렌치와는 차별된 이름을 부여하는 것이 좋다. master, main, develop 브렌치와 같은 이름은 직접 코드를 쓰는 브렌치에 어울리는 이름이므로 이런 이름은 빌드만 따로 올리는 브렌치 이름으로 사용하지는 않는다.

4. 빈 커밋 만들기

   git commit --allow-empty -m "Initial commit on orphan branch"

   • 빈 커밋을 만드는 이유는 아무것도 없는 상태의 브렌치로 만들고자 할 때의 기준 커밋을 만들기 위해서이다. 만약 어떤 파일을 커밋 했는데 실수로 되돌리고 싶다고 할 때 빈 커밋이 없다면 빈 브렌치를 만든 이후 되돌아 갈 수 있는 커밋은 가장 처음 커밋된 커밋인데 이 커밋에 이미 파일이 든 상태이기 때문에 비어 있는 상태로 되돌아갈 수 없다. 첫 커밋이 잘못 되어도 바꿀 수 없게 되어 첫 커밋을 바꾸고 싶다면 브렌치를 새로 생성해야 한다. 이런 상황을 대비하여 빈 커밋을 만들어 주도록 한다.

5. .gitignore 파일 만들기

   • staging 브렌치는 빌드된 파일 및 폴더를 저장하기 위한 용도로 사용한다. 다른 파일 및 폴더가 들어가지 않도록 미리 .gitignore 설정을 하도록 하자.

   *
   !*/
   !docs
   !docs/**
   !.gitignore

   • *는 .gitignore 하위의 모든 파일을 깃으로 추적하지 않도록 설정한다.
   • !.gitignore는 .gitignore 파일은 예외적으로 깃으로 추적하도록 하겠다는 의미이다.
   • !docs/는 docs 폴더를 예외적으로 깃으로 추적하도록 만든다는 의미이다.
   • !docs/**는 docs 폴더의 하위의 파일 및 디렉토리, 그 디렉토리의 하위 파일 및 디렉토리, 그 디렉토리의 하위 파일 및 디렉토리... 이런식으로 docs 하위의 파일 및 디렉토리를 최종 깊이(depth)까지 재귀적으로 탐색하여 깃으로 추적하도록 하는 코드이다.　만약 !docs/*라면 docs 하위의 파일만 깃의 추적 대상으로 하며 그 하위 폴더의 파일은 추적하지 않는 대상으로 본다.
   • .gitignore에 의해서 추적하지 않는 대상이 되면 git status 명령을 실행했을 때 Changes to be committed: Changes not staged for gitcommit: Untracked files: 어디에도 대상 파일이 표시되지 않는다. 물론 이미 깃으로 추적되고 있다면 표시되겠지만, 추적되고 있지 않은 상태라면 git status에 나오지 않으므로 깃에서 관리할 수 없는 대상이 된다.

6. 빈 브렌치에 docs 폴더 넣기

   git add docs

   • docs라는 명칭의 폴더는 github에서 github 페이지로 배포할 수 있도록 허용된 폴더명이다. docs를 사용하지 않는다면 프로젝트 루트 페이지를 공유하게 된다.
   • 주의 : docs 이외의 다른 파일이나 폴더는 건드리지 않도록 하자.

   git commit -m "최초 빌드 업로드"

7. 원격 저장소로 푸시하기

   git push origin staging

gh-pages 프로덕션 브렌치 만들기

• 주의 : 이 부분은 gh-pages 완전히 새로 만들고자 하는 경우에 해당하는 절차이다.
• gh-pages 브렌치는 유저명|조직명.github.io 또는 유저명|조직명.github.io/리포지도리명의 주소를 갖게 되는 깃허브 페이지의 사이트에 실제 적용되는 파일 및 폴더가 위치한 브렌치이다.
• 우선 staging 브렌치가 이미 생성되어 있다는 것을 가정한다. staging 브렌치는 결과물을 확인 및 검증을 통과한 상태이며 프로덕션의 적용만을 앞두고 있는 상태라고 하자.
• 목적은 staging의 코드 변경 사항을 gh-pages 브렌치로 전파하기 위함이다. 이렇게 하기 위해서는 staging 브렌치의 커밋 히스토리 기반으로 gh-pages 브렌치를 만들어야 한다. gh-pages 브렌치는 staging의 모든 커밋 기록을 포함하는 관계가 된다.

1. staging 브렌치로 이동하기

   git switch staging

• 이미 staging 브렌치라면 이동할 필요는 없다.

2. 기존의 gh-pages 브렌치 삭제하기

   git branch -D gh-pages

• gh-pages 브렌치를 staging 브렌치를 기반으로 처음으로 만들기 위한 과정으로 기존의 브렌치를 삭제하는 과정이다. 만약 gh-pages 브렌치가 staging 브렌치를 기반으로 만들어져 있다면 브렌치를 삭제할 필요는 없다.
• git branch 명령을 입력 했을 때 gh-pages 브렌치가 존재하지 않는다면 삭제 명령어를 입력하지 않아도 된다.

3. staging 브렌치 기반의 gh-pages 브렌치 만들기

   git switch -c gh-pages

• staging 브렌치 기반의 gh-pages 브렌치를 만든다는 의미는 staging 브렌치의 모든 커밋 히스토리를 가진 새로운 브렌치 gh-pages를 만든다는 의미이다.
• 만약 staging 브렌치의 커밋 히스토리를 포함하는 gh-pages 브렌치가 있다면 옵션을 붙여 생성하지 않고 기존의 브렌치를 쓰면 된다.

4. gh-pages 브렌치에 staging 브렌치를 기반으로 한 커밋 히스토리를 푸시하기

   git push origin gh-pages -f

• 리모트 저장소에 gh-pages 브렌치가 있다면 덮어쓰기 위해서 -f 옵션을 붙이도록 한다. 하지만 처음 만들었거나 gh-pages 브렌치가 존재하지 않는다면 -f 옵션을 추가할 필요는 없다.
• 어떤 브렌치 기반의 새로운 브렌치를 만들기 위해서는 빈 브렌치로 만들어서는 안된다. 이는 staging에 갱신된 빌드 정보를 gh-pages 브렌치로 이동하기 위해서 써야 하는 것이다. 어떤 커밋이라도 있는 staging 브렌치를 기반으로 gh-pages 브렌치를 만들도록 한다.

gh-pages의 브렌치와 깃허브 페이지 연결하기

• gh-pages가 github 리포지토리 settings -> Pages의 Source from a branch 옵션의 대상 브렌치가 gh-pages 브렌치 docs 폴더로 지정되어 있다면 깃 허브 리포지토리에 gh-pages 브렌치에 코드를 갱신하는 순간 부터 docs 폴더 안의 소스 코드가 github pages에서 제공하는 조직명_또는_유저명.github.io 또는 조직명_또는_유저명.github.io/리포지토리명으로 접속할 수 있도록 서버가 세팅된다.
• 깃허브 페이지 설정으로 브렌치와 깃허브 페이지의 연결이 되었다면, 브렌치에 코드가 푸시되면 깃허브 리포지토리 상단 메뉴 중 Actions 메뉴의 페이지에서 브렌치의 코드가 인터넷에서 접속하기 위해 갱신되는 과정을 확인할 수 있다. 초록색 원 안의 체크 표시가 생성되면 배포가 완료되었다는 의미이다.
• 만약 깃허브 페이지를 github.io 주소가 아닌 별도의 도메인으로 연결하고자 하는 경우에는 공개폴더 최상단(여기서는 docs 폴더 바로 밑)에 CNAME이란 파일을 만들고 도메인명을 입력해 주면 된다. 당연히 도메인을 구매하는 것이 전제되고 도메인 구매 사이트에서 제공하는 DNS 레코드 설정에서 CNAME에 깃허브 페이지 주소를 연결 해 주어야 한다.

git switch gh-pages

echo N0FreeLunch.github.io > docs/CNAME

• CNAME이란 파일을 직접 만들어도 되지만 위 명령어를 사용해서 CNAME이란 파일 안에 도메인명 N0FreeLunch.github.io을 넣을 수도 있다. 도메임명은 자신이 구매하고 연결하고자 하는 도메인으로 설정하도록 한다.
• CNAME 파일을 만들어 주지 않으면 브렌치의 코드가 깃허브페이지 사이트로 배포될 때마다 깃허브 리포지토리의 settings 탭 메뉴 -> Pages 사이드 메뉴의 페이지에서 domain 항목에서 연결하고자 하는 도메인명을 갱신해 주어야 한다.
• 한 번 gh-pages폴더에 CNAME 파일이 생성되었다면 다시 만들어주지 않아도 된다.

git add docs/CNAME

git commit -m "깃허브 페이지 배포 도메인 세팅"

git push origin gh-pages

• 생성된 CNAME을 커밋으로 저장하는 위 명령어는 한 번만 만들어주면 된다.
• 가끔 깃의 조작 실수로 CNAME이 제거되는 경우가 생길 수 있기 때문에 gh-pages 브렌치로 사이트 갱신 후 도메인 주소로 사이트에 접속해서 잘 접속이 되어 있는지 확인하도록 하자. 만약 사이트 접속이 되지 않는다면 CNAME 세팅이 누락되어 있을 수 있다.
• CNAME 파일을 직접 추가하는 방법도 있지만 깃허브의 깃허브 페이지 설정으로 추가할 수도 있다. settings -> Pages의 domain 항목에 도메인을 설정하고 저장하면 CNAME 파일이 새로 생성되고 다시 배포가 된다.

빌드된 결과물을 스테이징 브렌치에 갱신하기

• 빌드된 결과물이라도 항상 브렌치를 새롭게 만드는 것이 아니라 이전의 빌드 결과물을 커밋 히스토리로 남기는 방식을 사용하는 것이 좋다. 이는 릴리스가 실패한 경우, 이전 히스토리의 커밋을 완전히 삭제하지 않고 남겨 두어 되돌리는 용도로 사용하기 위함이다.

1. 먼저 이전에 빌드된 파일 및 폴더가 들어 있는 dist 폴더를 삭제한다.

   rm -rf dist

   • 위 명령어로 삭제해도 되지만 그냥 파인더나 탐색기 또는 IDE에서 삭제해도 무방하다.

2. 빌드 명령어를 사용하여 빌드된 파일 및 폴더가 들어 있는 dist 폴더를 새로 만든다.

   yarn run build

   • dist 폴더를 삭제되지 않으면 빌드된 파일이 dist에 덮어씌워지게 된다. 덮어 씌워지는 것은 새로 빌드되면서 더 이상 쓰이지 않는 파일은 그대로 두고, 변경되거나 추가된 파일은 추가 변경을 한다는 의미이다. 새로 빌드 했을 때 더 이상 쓰이지 않는 파일은 필요가 없기 때문에 지워 줘야 한다. 따라서 덮어쓰기를 하지 않고 dist 폴더를 지우고 새로 빌드하여 생성하는 방식을 사용한다.
   • dist 폴더를 지우지 않았을 경우 새 빌드 결과물에서는 더 이상 사용하지 않는 파일 및 폴더가 남게되고 dist 폴더가 웹 사이트로 게제될 때 웹에서 더 이상 사용하지 않는 파일 접근할 수 있으므로 반드시 삭제하고 다시 빌드하여 dist 폴더를 생성하도록 하자.

3. 스테이징 브렌치로 변경한다.

   git switch staging

   • 이 때 브렌치 변경이 되지 않는다면 파일이 변경되거나 삭제된 케이스 모두 커밋해야 한다. 새로 추가된 파일은 커밋을 해도 되고 안 해도 된다.

4. 스테이징 브렌치에 커밋 되어 있는 docs 폴더를 삭제한다.

   rm -rf docs

   • docs 폴더는 코드를 작성하는 브렌치에는 존재하지 않는다.
   • docs 폴더만 삭제하며 다른 파일 및 폴더는 다시 개발 브렌치로 돌아갔을 때 필요한 것이므로 건드리지 않도록 주의하자.

5. dist 폴더명을 docs 라는 이름으로 바꾸어준다.

   mv dist docs

   • docs 라는 폴더는 깃허브 페이지에 게시하기 위해서 반드시 사용해야 하는 폴더 이름이다.
   • 웹팩으로 빌드된 결과물을 깃허브 페이지에 올리므로 docs라는 이름의 폴더로 변경해야 한다.

6. docs 폴더를 깃으로 스테이징 한다.

   git add docs

   • 깃으로 스테이징을 하면 이전 docs 폴더와 새로 빌드한 dist 폴더로 만든 docs 폴더를 비교하여 변경 사항을 기록한다.
   • docs 폴더만 깃허브에 올릴 것이기 때문에 다른 파일이나 폴더는 추가하지 않도록 주의하자.

7. docs 파일을 커밋 한다.

   git commit -m "build 23.08.24"

   • 커밋 이름은 언제 빌드한 것인지 파악할 수 있도록 날짜로 지어 주었다.

8. 스테이징 브렌치에 푸시한다.

   git push origin staging

스테이징 브렌치의 변경사항을 gh-pages 브렌치에 전파하기

• 실수를 방지하기 위해 CLI 명령어로 적용하지 않는다.
• 깃 허브에서 Pull Request를 작성한다.
• 브렌치의 변경사항 전파 관계는 gh-pages <- staging이다.
• staging에 올린 빌드 결과물에 대한 검증이 끝나면 작성된 Pull Request를 승인한다.
• 승인된 PR(Pull Request)을 merge 버튼을 눌러 staging 브렌치의 변경 사항을 gh-pages 브렌치로 전파한다.

깃 명령어를 사용하기

• 명령어를 사용한 방식을 권장하지는 않는데, 일반적으로 프로덕션 웹 페이지의 적용은 신중하게 이뤄져야 하기 때문이다.
• 개인이 관리하는 홈페이지의 경우에는 특별히 문제가 되지 않겠지만, 회사 홈페이지의 경우는 홈페이지의 동작이 충분히 검증된 이후에 올려야 하기 때문에 여러 사람의 검토를 거친 후 적용하는 게 좋다.
• 여러 사람의 검증 이후 깃 명령어를 사용해서 staging 브렌치의 코드를 gh-pages 브렌치에 올려도 되지만, github에서 제공하는 PR을 이용하는 방식으로 프로덕션 적용의 기록을 남기고 깃허브에서 제공하는 최소 1인 이상의 검토를 강제하는 기능 등의 도움을 통해서 이런 절차를 좀 더 엄격하게 지킬 수 있으므로 깃 명령어를 사용하기 보다는 PR을 이용하는 방식을 사용하는 것을 추천한다.

git switch gh-pages

• gh-pages 브렌치로 이동한다.

git merge staging

• 검증이 끝난 빌드된 결과물이 있는 statig 브렌치를 gh-pages 브렌치의 코드에 전파한다.
• 만약 머지 이후에 Merge branch로 시작하는 터미널의 에디터(vi 에디터)가 표시될 수 있다. esc키 -> : -> q 또는 q!을 사용해서 터미널의 vi 에디터 화면에서 빠져 나온다.

git push origin gh-pages

• 깃허브 페이지의 사이트가 gh-pages에 연결되는 설정이 되어 있다면 브렌치에 코드 푸시 후 자동으로 깃허브에서 사이트 배포 과정이 이뤄진다. 깃허브 리포지토리의 상단 메뉴 리스트에서 Action 탭에서 확인할 수 있다. 배포가 이뤄지기까지 약간의 시간이 걸리는데 Action 페이지에서 배포 작업의 진행 정도를 확인할 수 있다.