我正在嘗試設置與編程相關的教程的版本控制。因爲有兩個不同的歷史它的證明問題：教程的版本控制設置
還有的項目由教程，其中可用於每個章節，是什麼讀者會看到正在興建的歷史。如果我從未打算再次修改本教程的已編寫章節，則可以將每章作爲項目歷史記錄中的標記存儲。
再有就是還教程本身的歷史（不僅是文字，但我對工作的假裝項目的歷史）。如果我發現一個錯誤，我需要回頭修復第1章，在最後添加一個新的提交不起作用，因爲我想改變項目在該階段「出現」的方式，即在項目歷史記錄中插入提交併向前移動章節的標籤。
到目前爲止，我已經考慮過幾種可能性 - 使用git分支，其中每個章節都是一個分支，每當我做出更改時都會重新分配到前一章的前面，插入補丁的mercurial補丁隊列，或圍繞一系列可以放入子庫的模塊構建教程。
我想我會問，如果任何人有經驗，這種事情，什麼解決方案的工作，並沒有。
git rebase --interactive可能是這裏最直接的解決方案。這將讓你選擇一個特定的提交進行編輯，然後重新應用所有後續的提交。當然，不應該比常規合併困難得多，這取決於您的變化有多大。查看分裂提交的部分git rebase手冊頁。這可以讓你保留你的原始版本的歷史原因，然後添加一個新的提交緊隨其後的歷史，你可以移動你的標籤。
這就是標籤的。標記你的「快照」點，然後從那裏開始。如果您需要返回並更改某些內容，請執行此操作並更新標籤。如果你不希望人們看到中間階段，只需創建第二個存儲庫，並逐個檢查提交一個標籤。
而不是重寫，因爲後期修復早日章的所有項目的歷史，我寧可隔離在自己的分公司每一章，讓每個HEAD代表每章的當前狀態。
組裝所有教程是那麼多版本管理問題（通過提取來自混帳回購協議的相關信息部署您的教程）。
然後，您可以開發自己的教程，以達到類似於git immersion東西。
（注意：如果這是更多的電子書，那麼git-scribe將是一個更有趣的方式來對其進行版本化。）
的OP rusky增加在評論：
我想版本的章節，每個章節的代碼是基於前面的章節中的代碼示例代碼
這意味着您添加的任何錯誤修正需要報告給代表其他章節的其他分支，在這種情況下請參閱：
約基於CLI的版本控制偉大的事情是，你可以使用shell腳本建立教程例如：
#!/bin/bash
mkdir example_repo
cd example_repo
git init .
touch file1
git add file1
git commit -m "Added file 1"
git checkout -b branch2
echo "New line" > file1
git commit -am "Added new line to file 1"
你明白了。它可以讓您從頭開始構建新的回購協議，無論您喜歡什麼點，中間的錯誤都很容易修復，因爲您每次都從空白的板岩開始。您可以將shell腳本本身置於版本控制之下，或者只是將不需要的部分註釋爲不同的示例。
這是一個有趣的想法。我想知道它是如何擴展到很多代碼的 - 它可能最終會導致大量的heredocs，或者從項目的「真實」存儲庫中選擇一些。 – rpjohnst 2011-05-08 02:43:04
@Rusky，根據你的評論我想我誤解了你的初衷。我的回答是基於你的教程的主題是使用版本控制本身，即分支模型等，而不是示例代碼。 – 2011-05-08 06:32:14
我現在增加了一個新的答案，我更好地理解你的問題。決定不要編輯這一個，因爲有人會發現它在另一種情況下很有用。 – 2011-05-08 07:05:50
我不確定我是否遵循 - 如果我將代碼標記爲我希望它出現在第1章中，添加一些更多的提交，然後返回並根據第1章添加一個新的提交，以後的東西不會除非我執行重新綁定或合併等操作，否則會解決此問題。 – rpjohnst 2011-05-07 22:34:40
這是正確的。這不會很有趣。您可以選擇提交（如果您使用git）將其應用於所有後續標記。 – 2011-05-07 22:41:12