不太知名的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
|/|   
...

这里有各类各样的漂亮格式，因此请使用上面的命令，并将它变成您本身的！