2013-05-01 47 views
42

Tôi đã tạo chi nhánh gh-pages cho một dự án mà tôi đang làm việc trên GitHub.Trang GitHub và đường dẫn tương đối

Tôi sử dụng văn bản tuyệt vời để tác giả trang web cục bộ và vấn đề của tôi là khi điều này được đẩy tới GitHub, tất cả các liên kết đến tệp javascrips, hình ảnh và tệp css không hợp lệ.

Ví dụ: tôi có điều này trong phần đầu của tôi.

<link href="assets/css/common.css" rel="stylesheet"> 

Điều này hoạt động rất cục bộ, nhưng không hoạt động từ GitHub vì các liên kết không được giải quyết bằng cách sử dụng tên kho lưu trữ như một phần của URL.

Nó yêu cầu:

http://[user].github.io/assets/css/common.css 

khi nó cần phải có được yêu cầu:

http://[user].github.io/[repo]/assets/css/common.css. 

tôi có thể tất nhiên đặt tên repo như là một phần của URL, nhưng điều đó sẽ ngăn chặn trang web của tôi để làm việc tại địa phương trong quá trình phát triển.

Bất kỳ ý tưởng nào về cách giải quyết vấn đề này?

+0

cùng một sự nghi ngờ ở đây. – diofeher

+0

Điều này làm tôi hài lòng. Bạn đã quản lý để tìm hiểu lý do của điều này? –

+0

Lưu ý: vào tháng 12 năm 2016, các trang GitHub đã thay đổi đáng kể. Xem [câu trả lời của tôi dưới đây] (http://stackoverflow.com/a/41127983/6309) – VonC

Trả lời

5

Bạn đang sử dụng trình duyệt nào? Bạn có chắc chắn điều này xảy ra không? Bởi vì nó không nên. Nếu bạn bao gồm một URL tương đối trong một liên kết, nó sẽ được giải quyết liên quan đến URL của tài liệu có chứa liên kết. Nói cách khác, khi bạn bao gồm

<link href="assets/css/common.css" rel="stylesheet"> 

trong một tài liệu HTML tại http://www.foo.com/bar/doc.html, liên kết để assets/css/common.css sẽ được giải quyết bằng cách thêm nó vào tiền tố của URL của tài liệu HTML mà không cần phần cuối cùng của con đường (không có doc.html), tức là liên kết sẽ giải quyết thành http://www.foo.com/bar/assets/css/common.css, không được http://www.foo.com/assets/css/common.css khi bạn xác nhận quyền sở hữu.

Ví dụ: xem nguồn của trang web Bootstrap Twitter: http://twitter.github.io/bootstrap/. Lưu ý các liên kết kiểu ở trên cùng, được chỉ định là <link href="assets/css/bootstrap.css" rel="stylesheet">. Liên kết đó giải quyết chính xác đến http://twitter.github.io/bootstrap/assets/css/bootstrap.css, tức là liên kết đó bao gồm tên repo.

-1

Dường như trang Github không phản hồi nhanh. Mặc dù nó làm cho các tập tin mới có sẵn ngay lập tức, các tập tin sửa đổi sẽ không xuất hiện ngay lập tức do bộ nhớ đệm hoặc một cái gì đó.

Sau khi chờ 15 phút hoặc lâu hơn, mọi thứ đều ổn.

51

Bạn cần phải use Jekyll.

Sao chép nguyên văn từ relevant documentation:

Đôi khi nó là tốt đẹp để xem trước trang web Jekyll của bạn trước khi bạn đẩy gh-pages chi nhánh của bạn để GitHub. Tuy nhiên, cấu trúc URL giống như thư mục con GitHub sử dụng cho Trang dự án làm phức tạp độ phân giải của URL thích hợp . Dưới đây là cách tiếp cận để sử dụng cấu trúc GitHub URL trang dự án (username.github.io/project-name/) trong khi duy trì khả năng xem trước trang web Jekyll của bạn cục bộ.

  1. Trong _config.yml, thiết lập các tùy chọn baseurl-/project-name - lưu ý các dấu gạch chéo hàng đầu và sự vắng mặt của một dấu gạch chéo.

  2. Khi tham chiếu tệp JS hoặc CSS, hãy thực hiện như sau: {{ site.baseurl}}/path/to/css.css - lưu ý dấu gạch chéo ngay sau biến (ngay trước “đường dẫn”).

  3. Khi thực hiện liên kết cố định hoặc liên kết bên trong, hãy thực hiện như sau: {{ site.baseurl }}{{ post.url }} - lưu ý rằng không có dấu gạch chéo giữa hai biến.

  4. Cuối cùng, nếu bạn muốn xem trước trang web của bạn trước khi cam/triển khai sử dụng jekyll serve, hãy chắc chắn để vượt qua một trống chuỗi các lựa chọn --baseurl, do đó bạn có thể xem tất cả mọi thứ tại localhost:4000 thường (không có/dự án -name ngay từ đầu): jekyll serve --baseurl ''

Bằng cách này bạn có thể xem trước trang web của bạn tại địa phương từ gốc trang web trên localhost, nhưng khi GitHub tạo ra trang web của bạn từ các chi nhánh gh-pages tất cả các URL sẽ bắt đầu bằng /project-name và giải quyết chính xác .

(Rõ ràng ai figured này ra only a few months ago.)

+3

Phải, câu trả lời này phải là câu trả lời được chấp nhận. Có vẻ một chút phức tạp cho một trường hợp sử dụng Jekyll phổ biến - Tôi tự hỏi nếu có một lý do họ không sử dụng site.baseurl theo mặc định? –

+2

Trong khi điều này là vài năm tuổi và tài liệu đã thay đổi, giải pháp này làm việc cho tôi hơn những gì đã được đề nghị trong tài liệu Jekyll của việc sử dụng '{{site.github.url}}' –

4

Đây không phải là một vấn đề nữa trong tháng 12 năm 2016, 3 và năm nửa sau.
Xem "Relative links for GitHub pages", xuất bản bởi Ben Balter:

Bạn đã có thể sử dụng liên kết tương đối khi authoring Markdown on GitHub.com for a while.

(có nghĩa là từ tháng giêng 2013)

Bây giờ, các liên kết này sẽ tiếp tục làm việc khi bố qua GitHub Pages.

Nếu bạn có một tập tin Markdown trong kho của bạn tại docs/page.md, và bạn muốn liên kết từ tập tin đó để docs/another-page.md, bạn có thể làm như vậy với các đánh dấu sau:

[a relative link](another-page.md) 

Khi bạn xem tệp nguồn trên GitHub.com, liên kết tương đối sẽ tiếp tục hoạt động, như trước đây, nhưng bây giờ, khi bạn xuất bản tệp đó bằng GitHub Pages, liên kết sẽ được âm thầm thành docs/another-page.html để khớp với URL được xuất bản của trang đích.

Dưới mui xe, chúng tôi đang sử dụng plugin nguồn mở Jekyll Relative Links, được kích hoạt theo mặc định cho tất cả các bản dựng.

Các liên kết tương đối trên Trang GitHub cũng tính đến các liên kết cố định tùy chỉnh (ví dụ:, permalink: /docs/page/) trong tài liệu YAML của một tệp, cũng như URL cơ sở của trang dự án trước khi thích hợp, đảm bảo các liên kết tiếp tục hoạt động trong bất kỳ ngữ cảnh nào.

Và đừng quên rằng since August 2016, you can publish your pages right from the master branch (không phải lúc nào các gh-pages chi nhánh)

Và kể từ Dec. 2016, bạn thậm chí không cần Jekyll hoặc index.md. Simple markdown files are enough.

0

Một tùy chọn khác là tạo một repo mới dành riêng cho các trang web github.io. Nếu bạn đặt tên cho repo là [user].github.io trên github thì nó sẽ được xuất bản tại https://[user].github.io và bạn có thể avoid having the repo name in the URL path completely. Rõ ràng nhược điểm là bạn chỉ có thể có 1 repo như thế này cho mỗi người dùng github, vì vậy nó có thể không phù hợp với nhu cầu của bạn, tôi không chắc chắn.

Các vấn đề liên quan