수정 및 업데이트 된 웹 사이트 기사
hexo s이후 , 우리 는 GitHub 블로그 사이트에 배포 한 후 로컬에서 사용 하고 콘텐츠가 변경되지 않았 음을 발견했습니다. 정오를 찾아 보니 드디어 그 이유를 찾았다.
처음에 유효성 검사를 업데이트 한 후 hexo dgithub 에 이미 배포 된 사용 , github도웨어 하우스에 업데이트되었지만 블로그 내용은 변경되지 않았습니다. Baidu는 지연이있을 것이라고 말했다. 그러나 하룻밤을 기다린 후에도 내용은 여전히 업데이트되지 않았습니다. 그래서 GitHub웨어 하우스를 다시보고 오른쪽 사이드 바에서이 항목을 찾았습니다.
github-pages가 GitHub의 기본 제공 정적 페이지 생성 기능이라는 것을 알고 있습니다. 클릭 한 후 변경 로그를 찾았습니다. 업데이트 날짜 또는 테스트를 위해 GitHub에 처음 배포 된시기. 그래서 블로그 콘텐츠가 전혀 업데이트되지 않았기 때문에 변경되지 않았다는 것을 알고 있습니다.
그런 다음 분기 문제 일 수 있음을 발견했습니다. 비디오를 따라갈 때 루트 디렉터리 에 있는 _config.yml 파일의 배포 줄은 다음 과 같습니다.
deploy:
type: 'git'
repo: [email protected]:W-alker/W-alker.github.io.git
branch: master
이렇게하면 hexo가 마스터 브랜치에 배포되어 창고에 추가 마스터 브랜치가 생깁니다. 이것은 GitHub가 얼마 전에웨어 하우스의 기본 마스터 브랜치를 기본으로 변경했음을 상기시켜줍니다. 따라서 기본을 변경했지만웨어 하우스에 두 개의 브랜치 (메인 및 마스터 하나)가 있고 메인은 "활성"브랜치입니다. 브랜치는 마스터 브랜치이지만 블로그 페이지가있는 브랜치는 여전히 기본 브랜치입니다. 두 브랜치의 내용은 완전히 다르며, 수정 된 hexo 파일은 마스터 브랜치에서 업데이트되고 메인 브랜치는 수정되지 않은 원래 파일을 유지합니다.
즉, 페이지 서비스는 메인 브랜치에서 생성 한 페이지를 사용하고 페이지를 생성하는 데 필요한 코드는 마스터 브랜치에 있습니다.
그래서 양고기, 그냥이 창고를 삭제하고 같은 이름의 창고를 구축하고, 지점의 구성 파일을 메인으로 만든 다음 hexo clean hexo g hexo d블로그가 실제로 업데이트 된 후에 재배포합니다.
나중에 GitHub에 배포가 너무 느리고 Baidu가 블로그를 gitee에 배포했지만 많은 문제가 있었다고 느꼈습니다 .gitee의 기본 브랜치 이름이 여전히 멀어서 페이지 서비스와의 충돌이 여러 번 나타났습니다. 마지막으로 GitHub의 기본 브랜치 이름을 master로 변경하여 문제를 해결하십시오.
요약 : 창고 지점에주의하십시오. 가장 좋은 창고는 단일 지점입니다. 다른 지점으로 변경해야하는 경우 페이지 서비스를 해당 지점으로 변경해야합니다. 물론 github의 기본 브랜치 이름을 master로 직접 변경할 수도 있습니다. 이렇게하면 gitee 및 코딩과 같은 다른 코드 호스팅 플랫폼에 동시에 배포 할 때 문제를 방지 할 수 있습니다.