不太知名的Git命令

Git對向後兼容性有着強烈的承諾：許多功能強大的特性隱藏在選項背後，而不是做爲默認行爲公開。幸運的是，Git也支持別名，所以您能夠建立本身的命令來執行各類各樣的Git魔法。如下是在個人.gitconfig中定義的一些更有用(或至少是有趣的)別名的選擇：

Git Please

$ git config --global alias.please 'push --force-with-lease'

每一個開發人員都與他們的團隊負責人進行了交流，討論了強制推動共享分支的問題(也就是說，不要這麼作)。Rebase、amend和squash。直到你重寫了一些共享的歷史，並在你的存儲庫中溢出了重複的提交，這些都是很是有趣的事情。幸運的是，Git不會讓您隨意重寫服務器上的歷史。您必須顯式地將--force選項傳遞給git push，以顯示您的業務。可是強制推動有點笨拙：它會用你的本地版本在上游分支上踩下，而你尚未得到的任何改變都將從歷史中抹去。

Git的 --force-with-lease 選項會更優雅：它會檢查您的本地副本是否在重寫以前是最新的。這代表您至少已經獲取了您將要進行的更改。因爲 git push --force-with-lease 每次都要輸入不少東西，因此我已經爲它建立了一個優雅的別名：git please

Git Commend

$ git config --global alias.commend 'commit --amend --no-edit'

每次 commit，而後當即意識到你已經忘記了要stage一個文件？無需煩惱！git commend 靜默的將提交的文件附加在你的上次commit上，複用上次的commit內容。

$ git add Dockerfile
$ git commit -m ‘Update Bitbucket pipeline with new Docker image’
# (facepalm)
$ git add bitbucket-pipelines.yml
$ git commend

Git It

$ git config --global alias.it \
'!git init && git commit -m 「root」 --allow-empty'

存儲庫的第一個提交不能像常規提交同樣從新構建，所以建立一個空提交做爲存儲庫根是很好的實踐。git it 即初始化您的存儲庫，並在一個快速步驟中建立一個空的根提交。下一次，當你啓動一個項目時，不要只是將它添加到版本控制中：git it 吧！

$ cd shiny-new-thing
$ git it
Initialized empty Git repository in /shiny-new-thing/.git/
[master (root-commit) efc9119] root

Git Staaash

$ git config --global alias.stsh 'stash --keep-index'
$ git config --global alias.staash 'stash --include-untracked'
$ git config --global alias.staaash 'stash --all'

git stash 是最使人愉快和有用的git命令之一。在您的工做樹中跟蹤文件的任何更改，並將它們清除，以便之後使用，留下一個乾淨的工做樹。可是，若是您已經建立了任何新文件，而且尚未設置它們，那麼 git stash 將不會在默認狀況下對它們進行操做，這將給您留下一個髒的工做樹。相似地，未被跟蹤或忽略的文件的內容在缺省狀況下不會被隱藏。

我已經建立了一些方便的別名來處理不一樣的git stash，基於您須要存儲的工做樹的哪些部分：

git stsh      # 只保存對跟蹤文件的未保存更改
git stash     # 保存對跟蹤文件的任何更改
git staash    # 保存未跟蹤文件並跟蹤
git staaash   # 保存忽略的，未跟蹤的和跟蹤的文件

若是有疑問，長期的(git staaash)將會使您的工做樹恢復到看起來像您的存儲庫的新克隆。

Git Shorty

$ git config --global alias.shorty 'status --short --branch'

我運行 git status 可能比任何其餘git命令都要多。多年來，Git的內聯幫助變得更加友好，這對於初學者來講是很是好的，可是對於那些熟悉Git的人來講，輸出的內容過於冗長。例如，git status 給出了18行代碼，告訴我有一些分段的、未分段的和未跟蹤的更改：

$ git status
On branch master
Changes to be committed:
  (use 「git reset HEAD <file>…」 to unstage)
  
    modified: package.json
    
Changes not staged for commit:
  (use 「git add <file>…」 to update what will be committed)
  (use 「git checkout -- <file>…」 to discard changes)
  
    modified: package.json
    
Untracked files:
  (use 「git add <file>…」 to include in what will be committed)
  
    index.js

git shorty只須要三行，就能夠告訴我一樣的事情：

$ git shorty
## master
AM test
?? .gitignore

(好吧，爲了簡潔起見，我實際上把這個別名做爲git st)

Git Merc

$ git config --global alias.merc 'merge --no-ff'

若是您使用的是標準的non-rebasing分支工做流，那麼運行一個標準的 git merge 來將功能分支與主分支結合起來實際上並不理想。沒有選項，git merge使用 --ff 合併策略，若是主分支沒有新的更改，它只會建立一個合併提交，不然它只是簡單地「快速轉發」您的主分支，以指向您的特性分支上的最新提交。只有在建立合併提交時，纔會考慮在查看git歷史時哪些代碼是在哪一個分支上開發的。

Git merc 使用 --no-ff 策略，老是建立一個合併提交。

順便說一句，當在Bitbucket中合併拉取請求時，咱們使用的是 --no-ff (默認狀況下)。

Git Grog

$ git config --global alias.grog 'log --graph --abbrev-commit --decorate --all --format=format:"%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(dim white) - %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)"'

個人git grog (或「graphicallog」)的別名已經通過了多年的演變，以致於我再也不肯定我是否準確地理解了它所作的事情。但它看起來確實很漂亮：

下面是標準的 git log 比較：

commit 352ee71473c173283836f8d375be0b2c8a1579f5
Merge: 3171837 c86f21b
Author: demo <demo@example.com>
Date:   Fri Oct 20 16:00:19 2017 +0800

    Merge branch 'dev'
...


*   352ee71 - Fri, 20 Oct 2017 16:00:19 +0800 - user1 (3 days) (HEAD -> master, origin/master, origin/dev, origin/HEAD, dev)
|\   Merge branch 'dev'
| *   c86f21b - Fri, 20 Oct 2017 15:12:50 +0800 - user1 (3 days)
| |\   Merge branch 'master' into dev
| * | cfa8980 - Mon, 16 Oct 2017 15:05:38 +0800 - user1 (7 days)
| | |  modify  memo
* | | 3171837 - Fri, 20 Oct 2017 15:59:42 +0800 - user1 (3 days)
| |/   modify user
|/|   
...

這裏有各類各樣的漂亮格式，因此請使用上面的命令，並將它變成您本身的！