git命令总结

git命令总结
1.建立版本库
初始化一个版本库
git init <dir> 或者 cd <dir> git init
添加文件到版本库
git add <file>
git commit -m "comment"

2.查看状态
查看工做区状态
git status
若是git status告诉文件已经被修改，查看修改内容：
git diff <file>

3.版本回退
HEAD 指向当前版本，在版本的历史记录之间切换：
git reset --hard commit_id
回退到上一版本：
git reset --hard HEAD^
回退到上上一版本：
git reset --hard HEAD^^
回退前100次版本
git reset --hard HEAD~100
查看版本历史，以肯定回退到哪一个版本：
git log
git log --pretty=oneline
git log --online --decorate --graph --all
要重返将来，查看命令历史：
git reflog

4.管理修改
查看工做区和版本库里面最新版本的区别
git diff HEAD -- <file>

5.撤销修改
当你改乱了工做区某个文件的内容，想直接丢弃工做区的修改时，用命令
git checkout -- <file> 文件在工做区的修改所有撤销

当你不但改乱了工做区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，
第一步用命令git reset HEAD <file>(把暂存区的修改撤销)，就回到了场景1
第二步按场景1操做。

已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

6.删除文件
git add test.txt
git commit -m "add test.txt"
rm test.txt
git status
git rm test.txt
git commit -m "remove test.txt"
删错了，由于版本库里还有呢，因此能够很轻松地把误删的文件恢复到最新版本：
git checkout -- test.txt

7.配置github
第1步：建立SSH Key：
在用户主目录下，查看有没有id_rsa和id_rsa.pub文件，有，跳下一步。
没有，打开Shell（Windows下打开Git Bash），建立SSH Key：
ssh-keygen -t rsa -C "youremail@example.com"
一路回车，使用默认值便可，因为Key也不是用于军事目的，无需设置密码。
若是一切顺利的话，能够在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，能够放心地告诉任何人。

第2步：登录GitHub，打开“Account settings”，“SSH Keys”页面：
而后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容后，
点“Add Key”，你就应该看到已经添加的Key。

8.github上添加远程仓库
首先，登录GitHub，而后，在右上角找到“Create a new repo”按钮，建立一个新的仓库
在Repository name填入learngit，其余保持默认设置，点击“Create repository”按钮，就成功地建立了一个新的Git仓库：

将本地仓库与远程仓库关联：
git remote add origin git@github.com:ileveli/learngit.git
添加后，远程库的名字就是origin，这是Git默认的叫法，也能够改为别的，可是origin这个名字一看就知道是远程库。

就能够把本地库的全部内容推送到远程库上：
git push -u origin master
把本地库的内容推送到远程，用git push命令，其实是把当前分支master推送到远程。

推送成功后，能够马上在GitHub页面中看到远程库的内容已经和本地如出一辙

从如今起，只要本地做了提交，就能够经过命令：
git push origin master
把本地master分支的最新修改推送至GitHub，如今，你就拥有了真正的分布式版本库！

小结：
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的全部内容；
此后，每次本地提交后，只要有必要，就可使用命令git push origin master推送最新修改；

9.从远程库克隆
首先，登录GitHub，建立一个新的仓库，名字叫gitskills
咱们勾选Initialize this repository with a README，这样GitHub会自动为咱们建立一个README.md文件。建立完毕后，能够看到README.md文件
如今，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：
git clone git@github.com:ileveli/gitskills.git
进入gitskills目录看看，已经有README.md文件了。

小结
要克隆一个仓库，首先必须知道仓库的地址，而后使用git clone命令克隆。
Git支持多种协议，包括https，但经过ssh支持的原生git协议速度最快。

10.建立与合并分支
建立dev分支，而后切换到dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b参数表示建立并切换，至关于如下两条命令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
而后，用git branch命令查看当前分支：
$ git branch
* dev
master
git branch命令会列出全部分支，当前分支前面会标一个*号。
而后，咱们就能够在dev分支上正常提交，好比对readme.txt作个修改，加上一行：
Creating a new branch is quick.
而后提交：
$ git add readme.txt
$ git commit -m "branch test"
[dev fec145a] branch test
1 file changed, 1 insertion(+)
如今，dev分支的工做完成，咱们就能够切换回master分支：
$ git checkout master
Switched to branch 'master'
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！由于那个提交是在dev分支上，而master分支此刻的提交点并无变：
如今，咱们把dev分支的工做成果合并到master分支上：
$ git merge dev
Updating d17efd8..fec145a
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就能够看到，和dev分支的最新提交是彻底同样的。
注意到上面的Fast-forward信息，Git告诉咱们，此次合并是“快进模式”，也就是直接把master指向dev的当前提交，因此合并速度很是快。
固然，也不是每次合并都能Fast-forward，咱们后面会讲其余方式的合并。
合并完成后，就能够放心地删除dev分支了：
$ git branch -d dev
Deleted branch dev (was fec145a).
删除后，查看branch，就只剩下master分支了：
$ git branch
* master
由于建立、合并和删除分支很是快，因此Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工做效果是同样的，但过程更安全。

小结
Git鼓励大量使用分支：
查看分支：git branch
建立分支：git branch <name>
切换分支：git checkout <name>
建立+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>

11.解决冲突
准备新的feature1分支，继续咱们的新分支开发：
$ git checkout -b feature1
Switched to a new branch 'feature1'
修改readme.txt最后一行，改成：
Creating a new branch is quick AND simple.
在feature1分支上提交：
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 75a857c] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
切换到master分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
Git还会自动提示咱们当前master分支比远程的master分支要超前1个提交。
在master分支上把readme.txt文件的最后一行改成：
Creating a new branch is quick & simple.
提交：
$ git add readme.txt
$ git commit -m "& simple"
[master 400b400] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
如今，master分支和feature1分支各自都分别有新的提交，变成了这样：
这种状况下，Git没法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，咱们试试看：
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
果真冲突了！Git告诉咱们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也能够告诉咱们冲突的文件：
$ git status
咱们能够直接查看readme.txt的内容：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>标记出不一样分支的内容，咱们修改以下后保存：

Creating a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed
如今，master分支和feature1分支变成了下图所示：
用带参数的git log也能够看到分支的合并状况：
$ git log --graph --pretty=oneline --abbrev-commit
* 59bc1cb conflict fixed
|\
| * 75a857c AND simple
* | 400b400 & simple
|/
* fec145a branch test
...
最后，删除feature1分支：
$ git branch -d feature1
Deleted branch feature1 (was 75a857c).
工做完成。

小结
当Git没法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
用git log --graph命令能够看到分支合并图。

12.分支管理策略
一般，合并分支时，若是可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
若是要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就能够看出分支信息。
下面咱们实战一下--no-ff方式的git merge：
首先，仍然建立并切换dev分支：
$ git checkout -b dev
Switched to a new branch 'dev'
修改readme.txt文件，并提交一个新的commit：
$ git add readme.txt
$ git commit -m "add merge"
[dev 6224937] add merge
1 file changed, 1 insertion(+)
如今，咱们切换回master：
$ git checkout master
Switched to branch 'master'
准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
由于本次合并要建立一个新的commit，因此加上-m参数，把commit描述写进去。
合并后，咱们用git log看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
* 7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
* 59bc1cb conflict fixed
...
能够看到，不使用Fast forward模式，merge后就像这样：

分支策略，在实际开发中，咱们应该按照几个基本原则进行分支管理：
首先，master分支应该是很是稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，好比1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每一个人都在dev分支上干活，每一个人都有本身的分支，时不时地往dev分支上合并就能够了。
因此，团队合做的分支看起来就像这样：
git-br-policy

小结
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就能够用普通模式合并，合并后的历史有分支，能看出来曾经作过合并，而fast forward合并就看不出来曾经作过合并。

13.BUG分支
软件开发中，bug就像屡见不鲜同样。有了bug就须要修复，在Git中，因为分支是如此的强大，因此，每一个bug均可以经过一个新的临时分支来修复，修复后，合并分支，而后将临时分支删除。
当你接到一个修复一个代号10的bug的任务时，很天然地，你想建立一个分支issue-10来修复它，可是，等等，当前正在dev上进行的工做尚未提交：
$ git status
并非你不想提交，而是工做只进行到一半，还无法提交，预计完成还需1天时间。可是，必须在两个小时内修复该bug，怎么办？

幸亏，Git还提供了一个stash功能，能够把当前工做现场“储藏”起来，等之后恢复现场后继续工做：
$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge
如今，用git status查看工做区，就是干净的（除非有没有被Git管理的文件），所以能够放心地建立分支来修复bug。

首先肯定要在哪一个分支上修复bug，假定须要在master分支上修复，就从master建立临时分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-10
Switched to a new branch 'issue-10'
如今修复bug，须要把“Git is free software ...”改成“Git is a free software ...”，而后提交：
$ git add readme.txt
$ git commit -m "fix bug 10"
[issue-101 cc17032] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后，切换到master分支，并完成合并，最后删除issue-10分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 101" issue-10
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-10
Deleted branch issue-10 (was cc17032).
太棒了，原计划两个小时的bug修复只花了5分钟！如今，是时候接着回到dev分支干活了！
$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)
工做区是干净的，刚才的工做现场存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge
工做现场还在，Git把stash内容存在某个地方了，可是须要恢复一下，有两个办法：
一是用git stash apply恢复，可是恢复后，stash内容并不删除，你须要用git stash drop来删除；
另外一种方式是用git stash pop，恢复的同时把stash内容也删了：
$ git stash pop
再用git stash list查看，就看不到任何stash内容了：
$ git stash list
你能够屡次stash，恢复的时候，先用git stash list查看，而后恢复指定的stash，用命令：
$ git stash apply stash@{0}

小结
修复bug时，咱们会经过建立新的bug分支进行修复，而后合并，最后删除；
当手头工做没有完成时，先把工做现场git stash一下，而后去修复bug，修复后，再git stash pop，回到工做现场。

14.Feature分支
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你确定不但愿由于一些实验性质的代码，把主分支搞乱了，因此，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
如今，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。
因而准备开发：
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
5分钟后，开发完毕：
$ git add vulcan.py
$ git status
$ git commit -m "add feature vulcan"
[feature-vulcan 756d4af] add feature vulcan
1 file changed, 2 insertions(+)
create mode 100644 vulcan.py
切回dev，准备合并：
$ git checkout dev
一切顺利的话，feature分支和bug分支是相似的，合并，而后删除。
可是，就在此时，接到上级命令，因经费不足，新功能必须取消！
虽然白干了，可是这个分支仍是必须就地销毁：
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.
销毁失败。Git友情提醒，feature-vulcan分支尚未被合并，若是删除，将丢失掉修改，若是要强行删除，须要使用命令git branch -D feature-vulcan。
如今咱们强行删除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).
终于删除成功！

小结
开发一个新feature，最好新建一个分支；
若是要丢弃一个没有被合并过的分支，能够经过git branch -D <name>强行删除。

15.多人协做
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，而且，远程仓库的默认名称是origin。
要查看远程库的信息，用git remote：
$ git remote
origin
或者，用git remote -v显示更详细的信息：
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面显示了能够抓取和推送的origin的地址。若是没有推送权限，就看不到push的地址。

推送分支
推送分支，就是把该分支上的全部本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master
若是要推送其余分支，好比dev，就改为：
$ git push origin dev
可是，并非必定要把本地分支往远程推送，那么，哪些分支须要推送，哪些不须要呢？
master分支是主分支，所以要时刻与远程同步；
dev分支是开发分支，团队全部成员都须要在上面工做，因此也须要与远程同步；
bug分支只用于在本地修复bug，就不必推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合做在上面开发。
总之，就是在Git中，分支彻底能够在本地本身藏着玩，是否推送，视你的心情而定！

多人协做时，你们都会往master和dev分支上推送各自的修改。

抓取分支
如今，模拟一个你的小伙伴，能够在另外一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另外一个目录下克隆：
$ git clone git@github.com:michaelliao/learngit.git
当你的小伙伴从远程库clone时，默认状况下，你的小伙伴只能看到本地的master分支。不信能够用git branch命令看看：
$ git branch
* master
如今，你的小伙伴要在dev分支上开发，就必须建立远程origin的dev分支到本地，因而他用这个命令建立本地dev分支：
$ git checkout -b dev origin/dev
如今，他就能够在dev上继续修改，而后，时不时地把dev分支push到远程：
$ git commit -m "add /usr/bin/env"
$ git push origin dev
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对一样的文件做了修改，并试图推送：
$ git add hello.py
$ git commit -m "add coding: utf-8"
$ git push origin dev
推送失败，由于你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示咱们，先用git pull把最新的提交从origin/dev抓下来，而后，在本地合并，解决冲突，再推送：
$ git pull
git pull也失败了，缘由是没有指定本地dev分支与远程origin/dev分支的连接，根据提示，设置dev和origin/dev的连接：
$ git branch --set-upstream dev origin/dev
再pull：
$ git pull
这回git pull成功，可是合并有冲突，须要手动解决，解决的方法和分支管理中的解决冲突彻底同样。解决后，提交，再push：
$ git commit -m "merge & fix hello.py"
$ git push origin dev

多人协做的工做模式：
首先，能够试图用git push origin branch-name推送本身的修改；
若是推送失败，则由于远程分支比你的本地更新，须要先用git pull试图合并；
若是合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
若是git pull提示“no tracking information”，则说明本地分支和远程分支的连接关系没有建立，用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协做的工做模式，一旦熟悉了，就很是简单。

小结
查看远程库信息，使用git remote -v；
本地新建的分支若是不推送到远程，对其余人就是不可见的；
从本地推送分支，使用git push origin branch-name，若是推送失败，先用git pull抓取远程的新提交；
在本地建立和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
创建本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，若是有冲突，要先处理冲突。

16.标签管理
发布一个版本时，咱们一般先在版本库中打一个标签（tag），这样，就惟一肯定了打标签时刻的版本。未来不管何时，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。因此，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？可是分支能够移动，标签不能移动），因此，建立和删除标签都是瞬间完成的。

Git有commit，为何还要引入tag？
“请把上周一的那个版本打包发布，commit号是6a5819e...”
“一串乱七八糟的数字很差找！”
若是换一个办法：“请把上周一的那个版本打包发布，版本号是v1.2”
“好的，按照tag v1.2查找commit就行！”
因此，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一块儿。

17.建立标签
在Git中打标签很是简单，首先，切换到须要打标签的分支上：
$ git branch
* dev
master
$ git checkout master
Switched to branch 'master'
而后，敲命令git tag <name>就能够打一个新标签：
$ git tag v1.0
能够用命令git tag查看全部标签：
$ git tag
v1.0
默认标签是打在最新提交的commit上的。有时候，若是忘了打标签，好比，如今已是周五了，但应该在周一打的标签没有打，怎么办？
方法是找到历史提交的commit id，而后打上就能够了：
$ git log --pretty=oneline --abbrev-commit
6a5819e merged bug fix 101
cc17032 fix bug 101
7825a50 merge with no-ff
6224937 add merge
59bc1cb conflict fixed
400b400 & simple
75a857c AND simple
fec145a branch test
d17efd8 remove test.txt
...
比方说要对add merge此次提交打标签，它对应的commit id是6224937，敲入命令：
$ git tag v0.9 6224937
再用命令git tag查看标签：
$ git tag
v0.9
v1.0
注意，标签不是按时间顺序列出，而是按字母排序的。能够用git show <tagname>查看标签信息：
$ git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4
Author: Michael Liao <askxuefeng@gmail.com>
Date: Thu Aug 22 11:22:08 2013 +0800

add merge
...
能够看到，v0.9确实打在add merge此次提交上。

还能够建立带有说明的标签，用-a指定标签名，-m指定说明文字：
$ git tag -a v0.1 -m "version 0.1 released" 3628164
用命令git show <tagname>能够看到说明文字：
$ git show v0.1
tag v0.1
还能够经过-s用私钥签名一个标签：
$ git tag -s v0.2 -m "signed version 0.2 released" fec145a
签名采用PGP签名，所以，必须首先安装gpg（GnuPG），若是没有找到gpg，或者没有gpg密钥对，就会报错：
gpg: signing failed: secret key not available
error: gpg failed to sign the data
error: unable to sign the tag
若是报错，请参考GnuPG帮助文档配置Key。

用命令git show <tagname>能够看到PGP签名信息：
$ git show v0.2
tag v0.2
Tagger: Michael Liao <askxuefeng@gmail.com>
Date: Mon Aug 26 07:28:33 2013 +0800
signed version 0.2 released
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo...
-----END PGP SIGNATURE-----
commit fec145accd63cdc9ed95a2f557ea0658a2a6537f
Author: Michael Liao <askxuefeng@gmail.com>
Date: Thu Aug 22 10:37:30 2013 +0800
branch test
用PGP签名的标签是不可伪造的，由于能够验证PGP签名。验证签名的方法比较复杂，这里就不介绍了。

小结
命令git tag <name>用于新建一个标签，默认为HEAD，也能够指定一个commit id；
git tag -a <tagname> -m "blablabla..."能够指定标签信息；
git tag -s <tagname> -m "blablabla..."能够用PGP签名标签；
命令git tag能够查看全部标签。

18.操做标签
若是标签打错了，也能够删除：
$ git tag -d v0.1
Deleted tag 'v0.1' (was e078af9)
由于建立的标签都只存储在本地，不会自动推送到远程。因此，打错的标签能够在本地安全删除。

若是要推送某个标签到远程，使用命令git push origin <tagname>：
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
或者，一次性推送所有还没有推送到远程的本地标签：
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 554 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v0.2 -> v0.2
* [new tag] v0.9 -> v0.9
若是标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
$ git tag -d v0.9
Deleted tag 'v0.9' (was 6224937)
而后，从远程删除。删除命令也是push，可是格式以下：
$ git push origin :refs/tags/v0.9
To git@github.com:michaelliao/learngit.git
- [deleted] v0.9
要看看是否真的从远程库删除了标签，能够登录GitHub查看。

小结
命令git push origin <tagname>能够推送一个本地标签；
命令git push origin --tags能够推送所有未推送过的本地标签；
命令git tag -d <tagname>能够删除一个本地标签；
命令git push origin :refs/tags/<tagname>能够删除一个远程标签。

19.使用GitHub
咱们一直用GitHub做为免费的远程仓库，若是是我的的开源项目，放到GitHub上是彻底没有问题的。其实GitHub仍是一个开源协做社区，经过GitHub，既可让别人参与你的开源项目，也能够参与别人的开源项目。

在GitHub出现之前，开源项目开源容易，但让广大人民群众参与进来比较困难，由于要参与，就要提交代码，而给每一个想提交代码的群众都开一个帐号那是不现实的，所以，群众也仅限于报个bug，即便能改掉bug，也只能把diff文件用邮件发过去，很不方便。

可是在GitHub上，利用Git极其强大的克隆和分支功能，广大人民群众真正能够第一次自由参与各类开源项目了。

如何参与一个开源项目呢？好比人气极高的bootstrap项目，这是一个很是强大的CSS框架，你能够访问它的项目主页https://github.com/twbs/bootstrap，点“Fork”就在本身的帐号下克隆了一个bootstrap仓库，而后，从本身的帐号下clone：
git clone git@github.com:michaelliao/bootstrap.git

必定要从本身的帐号下clone仓库，这样你才能推送修改。若是从bootstrap的做者的仓库地址git@github.com:twbs/bootstrap.git克隆，由于没有权限，你将不能推送修改。

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你本身克隆到本地电脑的仓库，他们的关系就像下图显示的那样：
github-repos
若是你想修复bootstrap的一个bug，或者新增一个功能，马上就能够开始干活，干完后，往本身的仓库推送。

若是你但愿bootstrap的官方库能接受你的修改，你就能够在GitHub上发起一个pull request。固然，对方是否接受你的pull request就不必定了。

若是你没能力修改bootstrap，但又想要试一把pull request，那就Fork一下个人仓库：https://github.com/michaelliao/learngit，建立一个your-github-id.txt的文本文件，写点本身学习Git的心得，而后推送一个pull request给我，我会视心情而定是否接受。

小结
在GitHub上，能够任意Fork开源仓库；
本身拥有Fork后的仓库的读写权限；
能够推送pull request给官方仓库来贡献代码。

20.自定义GIT
在安装Git一节中，咱们已经配置了user.name和user.email，实际上，Git还有不少可配置项。
好比，让Git显示颜色，会让命令输出看起来更醒目：
$ git config --global color.ui true
这样，Git会适当地显示不一样的颜色，好比git status命令：
git-color
文件名就会标上颜色。
咱们在后面还会介绍如何更好地配置Git，以便让你的工做更高效。

 

21.忽略特殊文件
有些时候，你必须把某些文件放到Git工做目录中，但又不能提交它们，好比保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋内心确定不爽。

好在Git考虑到了你们的感觉，这个问题解决起来也很简单，在Git工做区的根目录下建立一个特殊的.gitignore文件，而后把要忽略的文件名填进去，Git就会自动忽略这些文件。

不须要从头写.gitignore文件，GitHub已经为咱们准备了各类配置文件，只须要组合一下就可使用了。全部配置文件能够直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：
忽略操做系统自动生成的文件，好比缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是若是一个文件是经过另外一个文件自动生成的，那自动生成的文件就不必放进版本库，好比Java编译产生的.class文件；
忽略你本身的带有敏感信息的配置文件，好比存放口令的配置文件。

举个例子：
假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，若是有自定义目录，目录下就会有Desktop.ini文件，所以你须要忽略Windows自动生成的垃圾文件：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
而后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
加上你本身定义的文件，最终获得一个完整的.gitignore文件，内容以下：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# My configurations:
db.ini
deploy_key_rsa
最后一步就是把.gitignore也提交到Git，就完成了！固然检验.gitignore的标准是git status命令是否是说working directory clean。

使用Windows的童鞋注意了，若是你在资源管理器里新建一个.gitignore文件，它会很是弱智地提示你必须输入文件名，可是在文本编辑器里“保存”或者“另存为”就能够把文件保存为.gitignore了。

有些时候，你想添加一个文件到Git，但发现添加不了，缘由是这个文件被.gitignore忽略了：
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.
若是你确实想添加该文件，能够用-f强制添加到Git：
$ git add -f App.class
或者你发现，多是.gitignore写得有问题，须要找出来到底哪一个规则写错了，能够用git check-ignore命令检查：
$ git check-ignore -v App.class
.gitignore:3:*.class App.class
Git会告诉咱们，.gitignore的第3行规则忽略了该文件，因而咱们就能够知道应该修订哪一个规则。

小结
忽略某些文件时，须要编写.gitignore；
.gitignore文件自己要放到版本库里，而且能够对.gitignore作版本管理！

22.配置别名
有没有常常敲错命令？好比git status？status这个单词真心很差记。
若是敲git st就表示git status那就简单多了，固然这种偷懒的办法咱们是极力同意的。
咱们只须要敲一行命令，告诉Git，之后st就表示status：
$ git config --global alias.st status
好了，如今敲git st看看效果。

固然还有别的命令能够简写，不少人都用co表示checkout，ci表示commit，br表示branch：
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
之后提交就能够简写成：
$ git ci -m "bala bala bala..."
--global参数是全局参数，也就是这些命令在这台电脑的全部Git仓库下都有用。

在撤销修改一节中，咱们知道，命令git reset HEAD file能够把暂存区的修改撤销掉（unstage），从新放回工做区。既然是一个unstage操做，就能够配置一个unstage别名：
$ git config --global alias.unstage 'reset HEAD'
当你敲入命令：
$ git unstage test.py
实际上Git执行的是：
$ git reset HEAD test.py
配置一个git last，让其显示最后一次提交信息：
$ git config --global alias.last 'log -1'
这样，用git last就能显示最近一次的提交：
$ git last
commit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2
Merge: bd6ae48 291bea8
Author: Michael Liao <askxuefeng@gmail.com>
Date: Thu Aug 22 22:49:22 2013 +0800
merge & fix hello.py
甚至还有人丧心病狂地把lg配置成了：
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
来看看git lg的效果：
git-lg
为何不早点告诉我？别激动，咱不是为了多记几个英文单词嘛！

配置文件
配置Git的时候，加上--global是针对当前用户起做用的，若是不加，那只针对当前的仓库起做用。
配置文件放哪了？每一个仓库的Git配置文件都放在.git/config文件中：
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = git@github.com:michaelliao/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[alias]
last = log -1
别名就在[alias]后面，要删除别名，直接把对应的行删掉便可。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
配置别名也能够直接修改这个文件，若是改错了，能够删掉文件从新经过命令配置。

小结
给Git配置好别名，就能够输入命令时偷个懒。咱们鼓励偷懒。

 

23.搭建Git服务器
在远程仓库一节中，咱们讲了远程仓库实际上和本地仓库没啥不一样，纯粹为了7x24小时开机并交换你们的修改。
GitHub就是一个免费托管开源代码的远程仓库。可是对于某些视源代码如生命的商业公司来讲，既不想公开源代码，又舍不得给GitHub交保护费，那就只能本身搭建一台Git服务器做为私有仓库使用。

搭建Git服务器须要准备一台运行Linux的机器，强烈推荐用Ubuntu或Debian，这样，经过几条简单的apt命令就能够完成安装。

假设你已经有sudo权限的用户帐号，下面，正式开始安装。
第一步，安装git：
$ sudo apt-get install git
第二步，建立一个git用户，用来运行git服务：
$ sudo adduser git
第三步，建立证书登陆：
收集全部须要登陆的用户的公钥，就是他们本身的id_rsa.pub文件，把全部公钥导入到/home/git/.ssh/authorized_keys文件里，一行一个。
第四步，初始化Git仓库：
先选定一个目录做为Git仓库，假定是/srv/sample.git，在/srv目录下输入命令：
$ sudo git init --bare sample.git
Git就会建立一个裸仓库，裸仓库没有工做区，由于服务器上的Git仓库纯粹是为了共享，因此不让用户直接登陆到服务器上去改工做区，而且服务器上的Git仓库一般都以.git结尾。而后，把owner改成git：
$ sudo chown -R git:git sample.git
第五步，禁用shell登陆：
出于安全考虑，第二步建立的git用户不容许登陆shell，这能够经过编辑/etc/passwd文件完成。找到相似下面的一行：
git:x:1001:1001:,,,:/home/git:/bin/bash
改成：
git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
这样，git用户能够正常经过ssh使用git，但没法登陆shell，由于咱们为git用户指定的git-shell每次一登陆就自动退出。
第六步，克隆远程仓库：
如今，能够经过git clone命令克隆远程仓库了，在各自的电脑上运行：
$ git clone git@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.
剩下的推送就简单了。

管理公钥
若是团队很小，把每一个人的公钥收集起来放到服务器的/home/git/.ssh/authorized_keys文件里就是可行的。若是团队有几百号人，就无法这么玩了，这时，能够用Gitosis来管理公钥。
这里咱们不介绍怎么玩Gitosis了，几百号人的团队基本都在500强了，相信找个高水平的Linux管理员问题不大。

管理权限
有不少不但视源代码如生命，并且视员工为窃贼的公司，会在版本控制系统里设置一套完善的权限控制，每一个人是否有读写权限会精确到每一个分支甚至每一个目录下。由于Git是为Linux源代码托管而开发的，因此Git也继承了开源社区的精神，不支持权限控制。不过，由于Git支持钩子（hook），因此，能够在服务器端编写一系列脚原本控制提交等操做，达到权限控制的目的。Gitolite就是这个工具。
这里咱们也不介绍Gitolite了，不要把有限的生命浪费到权限斗争中。

小结 搭建Git服务器很是简单，一般10分钟便可完成； 要方便管理公钥，用Gitosis； 要像SVN那样变态地控制权限，用Gitolite。