Git Cheat Sheet
國外網友製作的Git Cheat Sheet，已經翻譯為中文，描述了常用的Git命令和使用git的最佳做法 我對翻譯後的文案加上序號和格式的調整 建議記下它們，如果你使用git
一、常見命令
1. 建立
克隆現有的儲存庫
$ git clone ssh://[email protected]/repo.git
建立新的本地儲存庫
$ git init
2. 本地變化
更改工作目錄中的檔案
$ git status
對跟蹤檔案的更改
$ git diff
將所有當前更改新增到下一次提交
$ git add .
將< file >中的一些更改新增到下一次提交
$ git add -p <file>
提交跟蹤檔案中的所有本地更改
$ git commit -a
提交先前階段的更改
$ git commit
更改最後提交 不要修改釋出的提交！
$ git commit --amend
3. 提交歷史
顯示所有提交，從最新開始
$ git log
顯示特定檔案隨時間的變化
$ git log -p <file>
誰在< file >中更改了內容和時間？
$ git blame <file>
4. 分支和標籤
列出所有現有分支
$ git branch -av
切換分支
$ git checkout <branch>
根據當前的頭部建立一個新分支
$ git branch <new-branch>
基於遠端分支建立新的跟蹤分支
$ git checkout --track <remote/bran- ch>
刪除本地分支
$ git branch -d <branch>
提交標籤
$ git tag <tag-name>
5. 更新和釋出
列出所有當前配置的遠端主機
$ git remote -v
顯示有關遠端
$ git remote show <remote>
新增名為< Remote >的新遠端儲存庫
$ git remote add <shortname> <url>
從< Remote >下載所有更改，但不要整合到Head中
$ git fetch <remote>
下載更改並直接合並/整合到頭中
$ git pull <remote> <branch>
在遠端上釋出本地更改
$ git push <remote> <branch>
刪除遠端上的分支
$ git branch -dr <remote/branch>
釋出標籤
$ git push --tags
6. 合併和重基
將<分支>合併到當前的頭部
$ git merge <branch>
將當前的頭重新定位到<分支>不要重新發布已釋出的提交！
$ git rebase <branch>
中止重基
$ git rebase --abort
解決衝突後繼續重基
$ git rebase --continue
使用配置的合併工具解決衝突
$ git mergetool
使用編輯器手動解決衝突，並(在解決後)將檔案標記為“已解決”。
$ git add <resolved-file> $ git rm <resolved-file>
7. 撤銷
放棄工作目錄中的所有本地更改。
$ git reset --hard HEAD
放棄特定檔案中的本地更改。
$ git checkout HEAD <file>
還原一個提交(通過產生一個新的具有相反更改的提交)
$ git revert <commit>
將頭指標重置為上一次提交 …並放棄自那以後的所有變化
$ git reset --hard <commit>
…並將所有更改保留為未分階段的更改。
$ git reset <commit>
…並儲存未提交的本地更改。
$ git reset --keep <commit>
二、最佳做法
1. 提交相關修改
提交應該是相關更改的包裝。例如，修復兩個不同的bug應該產生兩個單獨的提交。訊息使其他開發者更容易理解禪宗。 如果出了什麼問題就把它們退回去。
有了諸如分階段區域和ABI特性這樣的工具，只對檔案的部分進行分級，Git使建立非常細粒度的提交變得非常容易。
2. 經常提交
提交經常使您的承諾保持較小，並且再次幫助您僅提交相關的更改。 此外，它允許您更頻繁地與其他人共享程式碼。 這樣對每個人來說都比較容易 定期整合更改，避免合併衝突。
相反，很少有大量的提交，並且很少分享它們，這使得解決衝突變得困難。
3. 不要半途而廢
您應該只在程式碼完成時提交程式碼。這並不意味著您必須在提交之前完成一個完整的大型功能。完全相反：分裂
特性的實現分為邏輯塊，並記住要儘早提交。
但是，不要只承諾在一天結束前離開辦公室之前就在儲存庫中有一些東西。如果僅僅因為需要一個乾淨的工作副本(檢查分支)而想提交 在變化，拉等）考慮使用Git的«stash»特徵相反。
4. 在提交之前測試程式碼
抵制誘惑，去做一些你認為已經完成的事情。徹底測試它，以確保它真的完成了。
而且沒有副作用(據我們所知)。雖然在本地儲存庫中提交半生不熟的東西只需要您原諒自己，但是在以下情況下進行程式碼測試就更重要了。 這涉及到推送/與他人共享程式碼。
5. 編寫良好的提交訊息
開始您的訊息，以一個簡短的總結，您的變化(多達50個字元作為一個Gui-deline)。將它與下面的正文分隔開，方法是包含一個空行。您的訊息正文應該提供如以下問題的郵件式解答：
改變的動機是什麼？ 它與以前的實施方式有何不同？
使用祈使句、現在時態（省去變化、不改變或改變）與來自Git合併的命令生成的訊息一致。
6. 版本控制不是備份系統。
在遠端伺服器上備份檔案是擁有版本控制系統的一個很好的副作用。但是你不應該像使用備份系統一樣使用你的VCS。在執行版本控制時，您將應該注意語義上的（見相關的Chan-Ges）-你不應該只是在檔案中填塞。
7. 使用分支
分支是Git最強大的特性之一，這不是偶然的：快速和容易的分支是第一天的中心要求。分支是幫助你避免混淆不同發展方向的完美工具. 您應該在開發工作流程中廣泛使用分支：用於新特性、bug修復、想法……
8. 就工作流達成一致
git允許您從許多不同的工作流中選擇：長時間執行的分支、主題bran-ch、合併或重基、git-flow…。您選擇哪一個取決於以下幾個因素：你的專案，你的整體開發和部署工作流程，（也許最重要的）是你和你的隊友的個人喜好。無論你選擇工作，只要確保達成一個共同的工作流程，每個人都遵循這個工作流程。
9. 使用幫助和文件
獲取命令列的幫助
$ git help <command>
免費線上資源
ofollow,noindex" target="_blank">http://www.git-tower.com/learn http://rogerdudler.github.io/git-guide/ http://www.git-scm.org/
作者：Xyns
連結：https://blog.csdn.net/xinyan233/article/details/80593091
版權歸作者所有，轉載請註明出處