===歷史===
的那部分。正如民族間會無休止的爭論誰犯下了什麼暴行一樣，如果在另乙個人的轉殖
裡，歷史版本與你的不同，當你們的樹互操作時，你會遇到一致性方面的問題。
一些開發人員強烈地感覺歷史應該永遠不變，不好的部分也不變所有都不變。另一些覺
得**樹在向外發布之前，應該整得漂漂亮亮的。git同時支援兩者的觀點。像轉殖，分
支和合併一樣，重寫歷史只是git給你的另一強大功能，至於如何明智地使用它，那是你
的事了。
=== 我認錯 ===
剛提交，但你期望你輸入的是一條不同的資訊？那麼鍵入：
$ git commit --amend
來改變上一條資訊。意識到你還忘記了加乙個檔案？執行git add來加，然後執行上面的
命令。希望在上次提交裡包括多一點的改動？那麼就做這些改動並執行：
$ git commit --amend -a
=== 更複雜情況 ===
假設前面的問題還要糟糕十倍。在漫長的時間裡我們提交了一堆。但你不太喜歡他們的
組織方式，而且一些提交資訊需要重寫。那麼鍵入：
$ git rebase -i head~10
並且後10個提交會出現在你喜愛的$editor。乙個例子：
pick 5c6eb73 added repo.or.cz link
pick a311a64 reordered analogies in "work how you want"
pick 100834f added push target to makefile
之後：- 通過刪除行來移去提交。
- 通過為行重新排序行來重新排序提交。
- 替換 `pick` 使用：
* `edit` 標記乙個提交需要修訂。
* `reword` 改變日誌資訊。
* `squash` 將乙個提交與其和前乙個合併。
* `fixup` 將乙個提交與其和前乙個合併，並丟棄日誌資訊。
儲存退出。如果你把乙個提交標記為可編輯，那麼執行
$ git commit --amend
否則，執行：
$ git rebase --continue
這樣盡早提交，經常提交：你之後還可以用rebase來規整。
=== 本地變更之後 ===
你正在乙個活躍的專案上工作。隨著時間推移，你做了幾個本地提交，然後你使用合併
與官方版本同步。在你準備好提交到中心分支之前，這個迴圈會重複幾次。
但現在你本地git轉殖摻雜了你的改動和官方改動。你更期望在變更列表裡，你所有的變
更能夠連續。
這就是上面提到的 *git rebase* 所做的工作。在很多情況下你可以使用 *--onto* 標
記以避免互動。
另外參見 *git help rebase* 以獲取這個讓人驚奇的命令更詳細的例子。你可以拆分提
交。你甚至可以重新組織一棵樹的分支。
=== 重寫歷史 ===
偶爾，你需要做一些**控制，好比從正式的**中去除一些人一樣，需要從歷史記錄
裡面徹底的抹掉他們。例如，假設我們要發布乙個專案，但由於一些原因，專案中的某
個檔案不能公開。或許我把我的信用卡號記錄在了乙個文字檔案裡，而我又意外的把它
加入到了這個專案中。僅僅刪除這個檔案是不夠的，因為從別的提交記錄中還是可以訪
問到這個檔案。因此我們必須從所有的提交記錄中徹底刪除這個檔案。
$ git filter-branch --tree-filter 'rm top/secret/file' head
參見 *git help filter-branch* ，那裡討論了這個例子並給出乙個更快的方法。一般
地， *filter-branch* 允許你使用乙個單一命令來大範圍地更改歷史。
此後，+.git/refs/original+目錄描述操作之前的狀態。檢查命令filter-branch的確做
了你想要做的，然後刪除此目錄，如果你想執行多次filter-branch命令。
最後，用你修訂過的版本替換你的專案轉殖，如果你想之後和它們互動的話。
=== 製造歷史 ===
[[******history]]
想把乙個專案遷移到git嗎？如果這個專案是在用比較有名氣的系統，那可以使用一些其
他人已經寫好的指令碼，把整個專案歷史記錄匯出來放到git裡。
否則，查一下 *git fast-import* ，這個命令會從乙個特定格式的文字讀入，從頭來創
建git歷史記錄。通常可以用這個命令很快寫乙個指令碼執行一次，一次遷移整個專案。
作為乙個例子，貼上以下所列到臨時檔案，比如/tmp/history：
----------------------------------
commit refs/heads/master
committer alice thu, 01 jan 1970 00:00:00 +0000
data eot
m 100644 inline hello.c
data <#include
int main()
eotcommit refs/heads/master
committer bob tue, 14 mar 2000 01:59:26 -0800
data eot
m 100644 inline hello.c
data <#include
int main()
eot----------------------------------
之後從這個臨時檔案建立乙個git倉庫，鍵入：
$ mkdir project; cd project; git init
$ git fast-import --date-format=rfc2822 < /tmp/history
你可以從這個專案checkout出最新的版本，使用：
$ git checkout master .
命令*git fast-export* 轉換任意倉庫到 *git fast-import* 格式，你可以研究其輸
出來寫匯出程式， 也以可讀格式傳送倉庫。的確，這些命令可以傳送倉庫文字檔案
通過只接受文字的渠道。
=== 哪兒錯了？ ===
你剛剛發現程式裡有乙個功能出錯了，而你十分確定幾個月以前它執行的很正常。天啊！
這個臭蟲是從**冒出來的？要是那時候能按照開發的內容進行過測試該多好啊。
現在說這個已經太晚了。然而，即使你過去經常提交變更，git還是可以精確的找出問題所在：
$ git bisect start
$ git bisect bad head
$ git bisect good 1b6d
git從歷史記錄中檢出乙個中間的狀態。在這個狀態上測試功能，如果還是有問題：
$ git bisect bad
如果可以工作了，則把"bad"替換成"good"。git會再次幫你找到乙個以確定的好版本和
壞版本之間的狀態，通過這種方式縮小範圍。經過一系列的迭代，這種二分搜尋會幫你
找到導致這個錯誤的那次提交。一旦完成了問題定位的調查，你可以返回到原始狀態，
鍵入：$ git bisect reset
不需要手工測試每一次改動，執行如下命令可以自動的完成上面的搜尋：
$ git bisect run my_script
git使用指定命令（通常是乙個一次性的指令碼）的返回值來決定一次改動是否是正確的：
命令退出時的**0代表改動是正確的，125代表要跳過對這次改動的檢查，1到127之間
的其他數值代表改動是錯誤的。返回負數將會中斷整個bisect的檢查。
你還能做更多的事情: 幫助文件解釋了如何展示bisects, 檢查或重放bisect的日誌,並
可以通過排除對已知正確改動的檢查，得到更好的搜尋速度。
=== 誰讓事情變糟了？ ===
和其他許多版本控制系統一樣，git也有乙個"blame"命令：
$ git blame bug.c
這個命令可以標註出乙個指定的檔案裡每一行內容的最後修改者，和最後修改時間。但
綠色通道：
好文要頂
關注我收藏該文
與我聯絡
你所需要知道的一些git 的使用命令 基本技巧
與其一頭紮進git命令的海洋中，不如來點基本的例子試試手。它們簡單而且實用。實際 上，在開始使用git的頭幾個月，我所用的從來沒超出本章介紹的內容。要不來點猛的？在做之前，先為當前目錄所有檔案做個快照，使用 git init git add git commit m my first backup ...
食物與癌症，你需要知道的一些事情
癌症，在現代是一種關注率大增的疾病。以前總覺得它雖然嚴重，但離我還很遠，可是，隨著越來越多的新聞和身邊的傳言，這個死神變得有一點 司空見慣 起來。根據世界癌症研究 會 wcrf 的報告，2008年一年中，全球共有一百三十萬例新診斷的癌症病例，這個數字還會持續增長。癌症有很多種，所有病例中，比重最高的...
你所需要知道的關於AutoML和NAS的知識點
翻譯 pprp 日期 2018 8 21 automl和nas是深度學習領域的新秀。不需要過多的工作量，他們可以使用最暴力的方式讓你的機器學習任務達到非常高的準確率。既簡單又有效率。那麼automl和nas是如何起作用的呢？如何使用這種工具？神經網路架構搜尋，簡稱nas。開發乙個神經網路模型往往需要...