凡使用Git（分行或中繼）

Question

我用SVN並有3 environments

• 發展環境
• 試製環境
• 生產環境

實際工作， 一個該團隊將與trunk一起工作。

我們想遷移到Git。 我們應該在開發環境中工作？

我們應該與分支機構合作，當我們將代碼上傳到生產環境時，將分支機構重新集成到主機（中繼線）？

Answer 1

Git和SVN對提交和分支的「思考」非常不同。具體而言，Git 沒有中繼線。

在其他版本控制系統中，分支和分支名稱非常穩固（並且相應地非常重），在某些情況下完全不可分割。例如，在Mercurial中，一旦某個分支提交了，那個提交是就即分支，而只有那個分支，永遠。 （在SVN中，分支是非常重的，但不同於Mercurial與Git相比，我喜歡使用Mercurial作爲比較器，因爲Git和Mercurial都是分佈式，而SVN是集中式的。也從根本上改變了怎麼一個使用版本控制。混帳允許你指定一箇中央同步資料庫，但它是可選的，而不是強制性的。）

與此相反，在Git中，分支名是一個微小的，輕量級的東西，的幾乎不重要。它只是一個人類可讀的名稱提交，與另一個特殊屬性。 Git有兩個方便的，人類可讀的提交名稱：分支名稱和標籤名稱。它們之間最大的區別是分支名稱是假設移動 - 以便Git自動移動 - 並且標籤名稱不夠，這樣Git可以防止您意外移動它們。

注意這個區別小心，在Git中，分支名之間，和分支，呃，東西或 - 其他。 Git並沒有完全做出這樣的區分。至少有兩種不同的東西，都稱爲「一個分支」。關於這方面的更多信息，請參閱What exactly do we mean by "branch"?我會盡量總結一下，說實際的歷史 - 構成一個分支的一組事件是由提交本身構成的。承諾，一旦提出，永久和不變。沒有人 - 不是你，也不是Git-可以改變一個提交，因爲它的哈希ID--它的「真實名稱」，它是完全不可讀的 - 是其內容的加密散列。更改這些內容的一個位，並更改哈希ID，以便您有一個新的不同的提交。

每次提交含有作爲它的數據的一部分，其父（直接祖先）的ID提交，或用於多個父多個ID提交，如果所述提交是合併提交。就是這些形成分支的ID鏈，它在Git中形成分支，這意味着任何給定的提交可能同時在多個分支上。在某些情況下，一個提交可能在沒有分支！

當你做一個新的提交時，Git通過將其提交到存儲庫數據庫並將其父設置爲當前提交，將新提交添加到當前分支。因此，總是存在當前提交，其被稱爲HEAD。一旦新提交被永久安全地保存，Git就會將新提交的ID寫入分支名稱。 HEAD實際上是作爲一個文件實現的，但該文件通常只包含當前分支的名稱。它是提供當前提交的哈希ID的分支到提交ID映射。

分公司名稱可以添加和刪除在任何時間，雖然在腳註1中，移除分支名可以，如果這些提交有沒有其他名通過找到他們，放棄提交到了冷酷的死神收藏家。

因爲所有這些，Git應該以一種非常不同的方式使用。你可以並且應該在帽子下方創建新的分支。當你完成任何需要分支的任務時，合併它，重新分配它，重新壓縮它，或者扔掉它，無論你想要什麼：所有這些都非常快。當你完成後，無論提交你有是的歷史，你查看歷史通過啓動Git出一些分行名稱或其他起點（標籤，甚至原始提交散列ID，例如）。它會向您顯示這些具體的提交，然後顯示他們的父母以及他們父母的父母等等，一直回到第一位（無父母，或根）提交。

---

永久，即，除了 「拋棄」 提交（和其他GIT中的對象）。這些最終是垃圾收集使用git gc。分支名稱服務額外的目的：他們保護承諾從這樣的收集。但是，任何名稱分支名稱，標籤名稱，來自git stash命令的stash，來自git notes的任何notes名稱等都將保護提交。然後該提交保護其父提交，回溯所有提交歷史。

這條規則有一個例外。必須要處理一個空的倉庫，它根本沒有任何提交。這個例外也用於所謂的孤兒或未出生的分支（某些Git使用第一學期，一些使用第二學期），但大多數人只會在新的空知識庫中看到異常。