對於git reset --hard 《版本號》 ，如果工作區新增了乙個檔案，那個檔案不會被刪除，因為沒有add過，不能對它追蹤。同樣，假如工作區新增了新檔案，如果git reset 《版本號》,再git checkout 《新檔名》，是會報錯的，也是沒有追蹤那個新檔案。（這個時候如果git status，會顯示有新檔案沒有提交。）
不過如果是對某個已經add過的檔案進行修改，是可以通過git reset --hard 《版本號》 或者git reset 《版本號》,再git checkout 《新檔名》，來回到某個版本下的狀態。（本質上是看有沒有對該檔案進行追蹤，必須要有該檔案的索引）
使用git log 時，後面版本號會顯示所在分支，以及頭結點指向。
1 如果有紅色的origin/***，說明所在的版本號與遠端分支一致。（需要注意的是，這裡所說的遠端分支是本地倉庫認為的遠端分支，如果真正的遠端分支發生了變換，是不會顯示的。這個是有要git fetch 才能更新。）
2 如果有綠色***，說明該分支中，這個版本和當前倉庫版本一致。
3 如果紅色綠色字型都有，說明該版本與該分支的當前倉庫、遠端倉庫都一致。
以上git reflog中也一樣。
如果遠端庫更新了，git fetch之後可以把遠端庫拉到本地庫。fetch會把遠端庫拉到叫origin/master的本地的乙個庫。這個時候如果checkout，也不會切換到新的版本分支，而是一般提示落後於遠端分支。這個時候應該只能git pull或者git merge，只有合併分支以後，才能看到工作區傳送改變（如果快速合併的話）。
並且，如果把遠端庫的某個分支合併到本地庫的分支，它的log會把遠端庫的log也載入到本地庫分支的log。
因此，一般都需要先pull下來，然後合併以後，才能繼續修改或者push。
對於遠端分支做了修改：
1 可以直接git pull下來，這樣本地master和工作區都會發生改變。
2 如果git fetch下來，只是本地的origin/master分支發生了改變，需要git merge來合併，合併之後也是本地master分支和工作區都會改變。（git merge應該就是和本地的遠端分支合併。）
3 如果直接checkout 到 origin/master分支，就會提示是游離分支。因為沒有本地的分支指向origin/master分支。（個人理解，應該是只有本地分支，並且該分支的指標指向那個版本，這樣head指向這個版本的這個分支，才不是游離的。其他情況，包括origin/***的分支也都是游離的。）
4 如果處於游離分支，提交的話，是不可見的（即切換到別的分支就找不回來了）。如果想要儲存下來，這個時候可以建立乙個分支，git checkout -b temp，這樣就提交到該分支下了。
對於git push的引數-u
1 第一次提交也可以git push origin master ，即說明伺服器名字和分支名字即可。如果用來git push -u origin master ，就是預設伺服器是origin，之後可以只是git push，就提交到origin 對應的分支。
2 同乙個目標下，可以與不同的伺服器建立聯絡。比如git push origin1 master，就是另乙個伺服器名字，提交到另乙個倉庫的master分支。
關於SpringIOC的一些個人理解
根據上面這個思路接著說的話，那就順理成章了，首先spring容器將所有的bean都放在一起進行管理，然後當某個應喲經程式需要用到某個bean物件的時候，說一下，然後spring自動給這個程式分配他所需要的物件。這就是所謂的控制反轉了吧？本來這個宣告建立bean物件的過程應該由程式自己進行，建立呼叫然...
關於拓撲排序的一些個人理解
拓撲排序首先針對的是有向無環圖，其主要的目的是將乙個有向圖變為乙個線性序列，就像任務排序那樣的感覺。對於任何任務，必然先要完成其先導任務，對於同等級的任務，就可以隨意進行排序處理，當是乙個正常可完成的無環圖，必然可以使得生成乙個同節點個數的線性序列 對於拓撲排序，核心的步驟要借助佇列進行 首先，根據...
關於KMP演算法的一些個人理解
kmp演算法其實理解起來也不難，只不過很多過於公式化的講解以及太過晦澀的說法會讓人一頭霧水 kmp演算法主要是判斷乙個字串是否是另乙個字串的字串 對於這兩個字串，在演算法描述中有固定的稱謂 我們把最長的字串稱為text，需要判定的子串稱為模式pattern 對於這個問題，其實最容易想到的就是暴力列舉...