過去，我的“index.html”頁面（標記為這樣）不是您在我的域中鍵入時顯示的第一頁，以前我遇到過麻煩。以我目前在 Github 中的方式，我所有的頁面（只有三個）都位于“主分支”上。我應該把我的索引頁單獨放在主分支上嗎？并為我的其他頁面創建（a）單獨的分支？

該網站不過是html和css。非常非常基本的東西。

是否有任何其他常見原因可以解釋索引頁面不是默認主頁？

正如你所知道的，我對任何型別的編碼都是超級新手（并且是自學成才的），對此的任何幫助將不勝感激。

uj5u.com熱心網友回復：

在處理專案時，分支使您能夠處理專案的不同部分，而不會影響主分支或主分支。

例如 - 對于一個簡單的 html 專案，我需要處理三個頁面：index.html、about.html 和 contact.html

為了處理 index.html，我將創建一個名稱來描述我想要處理的功能的分支。

當我在新分支上完成該功能時，我可以合并到主分支

git status - 查看分支詳細資訊和提交狀態

git branch index-page- 創建一個名為index-page的新分支

git checkout index-page- 切換到新的分支索引頁面

完成提交后，對 index.html 進行更改

git add . - 階段新的變化

git commit -m "Your commit message" - 提交更改

git checkout main - 如果這是您的主分支，請切換到主分支

git merge index-page - 將索引頁面的更改合并到主頁面

uj5u.com熱心網友回復：

TL；DR：您將以適合您的方式使用分支。它們實際上沒有任何意義，因此您可以隨意使用它們。

長

您在這里混淆了幾件事，但公平地說，(a) 它很復雜，并且 (b) GitHub 在這里對您沒有幫助，因為它們在這個已經很復雜的事情上增加了更多的復雜性。

• Git是一個版本控制系統。版本控制系統 (VCS) 有著悠久（而且有些乏味）的歷史；Git 的 VCS 風格是分布式的，或 DVCS，其中每個存盤庫都可以復制任意多次。一些 DVCS 具有主/從或單一真實來源設定（“SSOT”）：有一個“真實”版本和一堆副本。 Git 不使用此模型：每個版本都是它自己的國王或主權物體，所有副本都是次等克隆。這讓生活變得有趣，因為您計算機上的克隆認為 GitHub 克隆低劣，而他們系統上的 GitHub 克隆認為您的計算機低劣。?? 大多數人喜歡通過將其中一個克隆指定為 SSOT 來簡化，而將所有其他克隆指定為可以從 SSOT 銷毀和重新創建的單純副本。您當然可以使用 Git 來執行此操作，因為這是“多真相來源”設定的一個子集。

• GitHub是一個托管 Git存盤庫的網站。轉到一個github.com/user/repo.git站點會顯示存盤庫及其README.md檔案。

• GitHub Pages是由運行github.com. 隨著時間的推移，他們改變了它的作業方式；當前版本用于github.io訪問github.com存盤庫并顯示它。但是顯示的內容與顯示的內容并不完全相同github.com。

不過，您已經詢問了有關分支的問題，這是一個 Git 主題。GitHub 會使用分支，但分支本身是由 Git 自己提供的。那么讓我們看看什么是分支。它……也許比你想要的要少；事實上，在 Git 中，分支這個詞被過度使用以至于變得毫無意義（另請參閱我們所說的“分支”到底是什么意思？），它有助于更??具體，例如，說分支名稱或提示提交而不是分支。

Git 是關于提交的

使用 Git 的第一個關鍵是要意識到 Git 不是關于分支，也不是關于檔案。相反，Git 是關于提交的。提交保存檔案，分支名稱可幫助您（和 Git）找到提交，但重要的是提交本身。這意味著您需要至少在一些細節上確切地知道提交是什么以及為您做了什么。

每次提交，在 Git 中：

• 有編號。每個提交都有一個唯一的哈希 ID，以十六進制表示。從某種意義上說，這個哈希 ID就是提交：一旦某個哈希 ID 被分配給您所做的某個提交，該哈希 ID 就意味著該提交，永遠，并且在宇宙中的每個 Git 存盤庫中，即使那些不是你的克隆。¹ 它不能重復用于任何其他提交。因此，兩個相互接觸的 Git 存盤庫可以通過比較哈希 ID 輕松判斷誰提交了另一個缺少的提交。

• 存盤兩個東西：

  • 每個提交都存盤每個檔案的完整快照。這些檔案是一種特殊的、壓縮的（有時是高度壓縮的）、只讀的、僅限 Git 的格式：只有 Git 可以讀取它們，實際上沒有任何東西可以覆寫它們，甚至 Git 本身也不能覆寫它們。這允許它們在提交之間（甚至在提交中）共享，這意味著 Git 可以對相同的檔案內容進行重復資料洗掉。

    重復資料洗掉意味著即使每次提交都有每個檔案，存盤庫也不會變得非常胖。事實上，如果一個新的提交與之前的提交具有完全相同的快照——這并不常見，但你可以做到這一點——通過重復資料洗掉技巧，檔案實際上根本不占用空間。（由于下一點，提交本身會占用一些空間。）

  • 每個提交都存盤一些元資料：您的姓名和電子郵件地址等資訊，以及您提交時的日期和時間戳。您還可以提供一條日志訊息，說明您提交提交的原因，git log稍后將向您展示。

    此元資料中包含 Git 為其自身目的添加的內容：每個提交記錄一個先前提交哈希 ID的串列，Git 將其稱為此提交的父級或父級。大多數提交只有一個父級。

• 完全只讀/不可更改。（這適用于所有 Git 的內部物件，并且是使散列技巧發揮作用的關鍵。散列技巧也是 Git 執行檔案內容重復資料洗掉的方式。）

父元資料放在一起時，意味著提交會找到更早的提交。每個提交都指向其直接父級，后者又指向父級的父級（提交的祖父級），依此類推，如下所示：

... <-F <-G <-H

這里H代表最新提交的實際哈希 ID。Commit H，無論其真正的哈希 ID 是什么，都存盤完整的快照和一些元資料。元資料包括較早提交的原始哈希 ID G。

Git can therefore extract both commits and compare the files in G and H. Whatever is the same—and is therefore de-duplicated—is usually uninteresting; for files that are different, though, Git can now compute a recipe for changing the old version (in G) into the new one (in H). This is a (single-file) diff. Diffs are how we usually view the files in a commit, as diffs from the previous commit. So we see commit H as its changes from its parent G, when we run git log -p. But H actually stores a full snapshot.

Having shown H, git log now moves back to commit G. This is, of course, a snapshot plus metadata, and the metadata allow Git to find earlier commit F. So Git can now show G as its log message and the diff with respect to commit F. This repeats for every commit, one parent/child pair at a time, until Git gets back to the beginning of time: a commit that has no parents. Git shows all files as new, in this root commit, but otherwise it's the same as any other commit. Then git log stops going backwards.

¹This does not—can not—work forever, due to the pigeonhole principle. The huge size of the hash ID in Git is meant to make it work well enough, long enough, that we don't care about the eventual failure: it should ideally not happen until long after the universe ends.

How branch names help us find commits

To view commit H—or to extract it so that we can get some work done—Git needs to know H's hash ID. If we want commit G, we can give Git H's hash ID and say "and then go back one hop". If we want commit F, we can give Git H's hash ID and say "and then go back two hops". But we have to give Git H's hash ID.

One alternative here is to memorize the hash IDs. That's no fun and—humans being such a big source of errors—a very bad idea, but instead of having humans memorize hash IDs, why not have the computer do it? We could have a little file or database where we write down rows of names and hash IDs: master or main means a123456 or whatever H's hash ID is, for instance.

That is, in fact, what a branch name is: an entry in a small database. The commits themselves are entries in a bigger database. Both databases are simple key-value stores; the object database, with commits in it, uses hash IDs as keys, and the names database, with branch and tag and other such names in it, uses names. The values in the object database are the commits themselves (and the files and other internal objects), and the values in the names database are the hash IDs.

Curiously, though, a branch name stores only one hash ID. This is actually true for all entries in the names database: they all store just one hash ID. For a branch name, that hash ID is always the ID of a commit, and we simply define it as the latest commit. So if we have:

             I--J   <-- feature1
            /
...--F--G--H   <-- main
            \
             K--L   <-- feature2

then the name main selects commit H as the "latest" commit, while the name feature1 selects J as the latest and feature2 selects L as the latest. All three commits are in fact latest, even though two of them are obviously "later".

Commit J points back to commit I, which points back to H, which points back to G, and so on. Commit L points back to commit K, which points back to H and so on. What this means is that all commits up through and including H are on all three branches at the same time. Commits I-J are only on feature1, and commits K-L are only on feature2.

Making new commits

Branch names are allowed to—indeed, encouraged to—move, and will do so automatically as we make new commits. We pick a branch to be "on", like this:

             I--J   <-- feature1
            /
...--F--G--H   <-- feature2 (HEAD), main

This means we're "on" branch feature2, using commit H. H is the latest commit on both main and feature2, since both names point here. Git will extract, into a work area, all the files from commit H.

Note that the files in Git are in a special weird Git-ized format, that only Git can use. But Git has copied these files out of the repository, into our work area. The copies—which are not actually in Git at this point—are ordinary everyday files; we can do work with them.

We do whatever we like with these files and run git add (for reasons I won't cover here) and git commit, and Git now prepares a new commit:

• Git gathers any metadata it needs, such as name and email address and log message.
• Git uses the current commit hash ID (H in this case) as the parent in the new commit's metadata.
• Git freezes all the files into the permanent-storage form (they're actually pre-compressed-and-de-duplicated so that this goes very fast, compared to old-school version control systems) to go into the new commit.
• Git actually writes out this new commit, which assigns it the unique hash ID—K in this case.
• The sneaky part: Git writes the new commit's hash ID into the current branch name, i.e., the one HEAD is attached-to.

The result is our new commit K:

             I--J   <-- feature1
            /
...--F--G--H   <-- main
            \
             K   <-- feature2 (HEAD)

K is now our latest commit on branch feature2. It got there automatically: Git made K just now (from Git's index / staging-area, which we haven't covered, plus the metadata) and made it link back to H, and then updated the name feature2.

If we make another new commit now, we get the picture I drew earlier:

             I--J   <-- feature1
            /
...--F--G--H   <-- main
            \
             K--L   <-- feature2 (HEAD)

How GitHub and GitHub Pages use branch names

We now know that a branch name just points to some commit. That commit has a bunch of files in it, stored as a (permanent, unchangeable) snapshot.

We—humans—use branches (or branch names, to be precise) for whatever purpose we like, but we do need to be aware of how some software might use them. When you view a repository on GitHub, they show you the README.md from the main branch. By default, that's the literal name main. So you'd want your main to point to a commit that has the right README.md file in it.

You can change which branch name is considered the "main" one, on GitHub, using the GitHub web interface.

When you view the same repository on github.io, they will show the index.html or README.md from a commit selected by some branch name. Which one? Well, the default is main again, but again, you can change it. It looks like you can change this independently of the setting on github.com (although I have not tried this myself).

Know that they'll show files out of some commit. You pick a branch name; that picks some commit in their repository; and then you see files from that commit's snapshot. Then, remember one other key item about Git: their branch names are theirs. Your branch names are separate from theirs. You may, if you wish, use the name fred to remember a commit, but have them—GitHub—use a different name (wilma or barney perhaps) to remember that same commit. To get GitHub to:

1. store some particular commit (and all its parents/ancentry), and
2. remember that commit with some branch name

你將使用git push. 該git push命令會將您的存盤庫中的提交（通常會使用您的分支名稱找到）發送到他們的存盤庫，現在使用原始哈希 ID，以便您的 Git 和他們的 Git 可以知道他們已經擁有哪些提交，以及哪些提交他們仍然需要。然后你的 Gitgit push會向他們的 Git 發出一個請求來結束這個會話：如果沒問題，請將你的名字 ________ 設定為指向哈希 ID ________。如果他們這樣做了，他們會告訴你的 Git。（如果沒有，您可以使用 將其轉換為強制命令git push --force，但在許多情況下這是一個錯誤：相反，您想弄清楚他們為什么不同意這樣做。）

如果您在兩個存盤庫中使用相同的分支名稱，這會大大簡化您的作業。所以你可能想要這樣做。但這不是必需的，并且在您使用向git push他們發送提交之前，他們不會擁有您的新提交。

同樣，您可以使用git fetch從其他 Git 存盤庫獲取提交。但是這里有一個奇怪的地方：當你使用 時git fetch，你會從另一個 Git 獲得提交，但這不會讓你的 Git 更新你的分支名稱。相反，你的 Git 有一組完全獨立的名稱，我稱之為remote-tracking names，以記住其他 Git 的分支名稱。Git 呼叫這些遠程跟蹤分支名稱，但是到此為止，那個糟糕的多載單詞分支幾乎失去了它的所有含義，我發現“遠程跟蹤名稱”的效果也一樣好或更好。

標籤：

上一篇：django表單non_field_errors自定義

下一篇：使用GitHub檢查的專案是否具有持續集成？