Git小技巧
先說一下自己的基底好了，畢業前我基本上沒有接觸到開源專案的開發，自然對版控的理解只停在下圖的程度。
剛開始找工作的時候有試著使用Github，不過一人專案也不會對Git有什麼深入理解。倒是接觸到了一個之後其實很少用到的概念:Fork(大部分的內部專案都不會使用)
Branch<->Remote/Local
第一份工作的時候，大致釐清了一個我覺得新手(X)老技術使用者(O)很容易困惑的概念:不同的分支(Branch)跟Local之於Remote是兩個方向的概念。至於連Branch的概念，都感到難以理解的老式TFS、SVN(非分散式版控)使用者，那又是另一個境界了(遷入與遷出的境界)。
這個概念在正確的標準操作下，搞不清楚也無所謂(比如pull、push的時候，雖然預設會是Remote的同名Branch，但實際上是可以從不同名的Branch做這些操作的)，但出現例外的時候，往往就不容易明白到底發生什麼事了。
那時候就有處理同時有兩個Remote的Repository的經驗。
Rebase/Merge
第一份工作時，習慣用merge，正確流程下merge也不會有問題(先pull trunck，再把trunck merge進自己的branch，測試自己的功能沒有被蓋掉，並祈禱測試期間沒有人push上trunck，趕快merge 回trunck後push)。
雖然有看過一點Rebase資料，但沒有很懂。直到第二份工作的時候，推行的是git flow(第一份末期也有提出類似的觀念，雙trunck的專案版控就是頭痛)，才開始上手Rebase。
GUI/分解動作
剛開始學git看的文章，很強調staging的概念。
但那時候自己沒有使用GUI的習慣(雖然第一份公司大部分的人用TortoiseGit，極少數的人用SourceTree，不過我是更少數的人用Command Line)XD，commit的習慣變成把所有的code都檢查過，不要的code用IDE處理掉，git指令: git add . + git commit，收工。
但無分解動作的commit，就有一點像上圖的感覺，不論你commit描述寫的再清楚，程式碼可讀性再高，你都錯過了用板控來提高他人理解的機會了。
開發者可以先以任意的方式進行開發嘗試，如無分解動作的一般，把魔術方塊轉出來。但最後的紀錄，應該是開發者在審思過這些內容最適合的順序(不必要的code移除就不多提了)後留下，並可以讓專案保留只使用某些步驟的可能性。
要這麼做的話，好的GUI就蠻重要的了。GitKraken的介面蠻好的，不過前陣子開始收費了。我目前是用Fork Gui，繞了一圈又回到Fork(x)，還算好用。
搶救錯誤操作
沒有GUI使用的情況下，還有一個操作蠻麻煩的-就是discard掉自己不要的部分。用指令要打檔名實在懶，有時候寫了一堆爛code，發現其實只需要一兩行的時候，需要全部discard掉，就會使用git指令: git add . + git reset -hard head，結果不小心手滑就……
這跟常見的用git reflog挽回reset 掉的commit的情況不太一樣，因為這時候你的程式碼還沒committed，只存在staging。只能靠 git fsck -cache -unreachable再使用 git show <hash>，找出檔案內容了。
