Git－学习笔记（经常使用命令集合）

时间 2019-12-10

标签 git 学习笔记经常使用命令集合栏目 Git 繁體版

原文原文链接

这里引用一下百度百科里Git的内容：git

Git --- The stupid content tracker, 傻瓜内容跟踪器。Linus Torvalds 是这样给咱们介绍 Git 的。

Git 是用于 Linux内核开发的版本控制工具。与经常使用的版本控制工具 CVS, Subversion 等不一样，它采用了分布式版本库的方式，没必要服务器端软件支持（wingeddevil注：这得分是用什么样的服务端，使用http协议或者git协议等不太同样。而且在push和pull的时候和服务器端仍是有交互的。），使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来讲天然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

怎样安装Git这里不做介绍，请自行百度，谢谢。算法

一、初见Git服务器

二、实时查看修改点app

三、版本回退分布式

四、版本修改工具

八、Git管理软件

一、初见Git

如下例子在终端操做，咱们先建立一个名为“TestGit”的文件夹：

$ mkdir TestGit

进入“TestGit”文件夹并使用git init命令把这个目录变成Git能够管理的仓库：

$ cd TestGit/
$ git init

你会看见“Initialized empty Git repository in /Users/baijiawei/Desktop/TestGit/.git/”，提示建立的是一个空的仓库。

在当前目录下，建立文件“readme.txt”，内容为"one edit"，以下图：

另外，在终端使用ls命令，能够查看当前目录下的全部文件：

$ ls
readme.txt

使用pwd命令能够看见当前所在的目录结构：

$ pwd
/Users/这个不能让大家知道/Desktop/TestGit

回归正题，使用命令git add命令把文件添加到仓库：

$ git add readme.txt

执行完成后不会有任何提示，说明添加成功。

最后使用git commit命令提交到仓库：

$ git commit -m "first commit"
[master (root-commit) dc09f1d] first commit 1 file changed, 1 insertion(+) create mode 100644 readme.txt

-m后面输入的为本次提交的备注，能够是任何字符，但最好是有意义的。

执行完命令后会告诉你此次提交的结果。

二、实时查看修改点

咱们修改一下readme.txt的内容，以下图：

咱们可使用git status命令查看仓库当前的状态：

$ git status
On branch master

Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt

结果告诉咱们，readme.txt被修改过了，但尚未提交修改。

使用git diff命令，查看文件具体的修改：

$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt index 4f1b13a..8794b68 100644 --- a/readme.txt +++ b/readme.txt @@ -1 +1,3 @@ -one edit \ No newline at end of file +one edit + +two edit \ No newline at end of file

diff就是difference，能够从上面的命令输出看到，咱们在第三行添加了“two edit”文字。

使用add和commit命令把修改提交到Git仓库：

$ git add readme.txt 
$ git commit -m "two edit" [master 299e07a] two edit 2 files changed, 3 insertions(+), 1 deletion(-) create mode 100644 .DS_Store

三、版本管理

咱们可使用git log命令查看提交的记录：

$ git log
commit 299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4
Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:25:17 2015 +0800 two edit commit dc09f1df94afd30bca6726e9f0d3459e358ac560 Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:11:31 2015 +0800 first commit

从查询结果咱们能够看见，我刚刚总共提交了2次到Git仓库。咱们还能够看见，commit后面有一串很长的数字，那是每次提交至Git版本库都会随机生成的一串ID（哈希算法），用做版本号，后面咱们会使用到。提示：每个版本号都是随机且是不一样

咱们还能够把记录内容显示压缩为一行，在后面添加参数“--pretty=oneline”：

$ git log --pretty=oneline
299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4 two edit
dc09f1df94afd30bca6726e9f0d3459e358ac560 first commit

先来回忆一下，最后修改的readme.txt文件内容以下图所示：

咱们把它回退一个版本，也就是只有“one edit”内容的readme.txt文件。

使用git reset命令进行版本回退：

$ git reset --hard HEAD^
HEAD is now at dc09f1d first commit

在Git中，HEAD表示当前版本，HEAD^表示上一个版本，HEAD^^表示再上一个版本。若是要回退更多的版本，咱们可使用HEAD~n表示。你会看见reset命令后面带着参数“--hard”，如今先不用管它用来干什么的，先用着，在后面会说到。

咱们看一下回退后的readme.txt文件内容：

能够看出来，咱们已经回退了一个版本。

如今使用git log命令查看一下：

$ git log
commit dc09f1df94afd30bca6726e9f0d3459e358ac560
Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:11:31 2015 +0800 first commit

从log命令查看的结果中发现，最新的那个版本已经看不到了，那咱们还能回到最新的版本吗？

方法是有的，前面咱们介绍了Git的版本号，咱们就是使用它来进行回到最新的版本：

$ git reset --hard 299e07a39e54
HEAD is now at 299e07a two edit

咱们通常不须要把一整串版本号写上去，只须要打前面的几位便可，Git会本身进行查找。但也不要只打前面1－2位，由于这样有可能找到重复的。

咱们再次查看readme.txt文件内容：

咱们再使用git log来看一下提交至Git仓库的记录：

$ git log
commit 299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4
Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:25:17 2015 +0800 two edit commit dc09f1df94afd30bca6726e9f0d3459e358ac560 Author: GarveyCalvin <1147626297@qq.com> Date: Sat Jan 17 17:11:31 2015 +0800 first commit

那么，若是咱们当初回退了版本以后，并关闭了终端。没过一下子，你后悔了，须要回到最新的那个版本怎么办？幸亏，在Git中是能够有后悔药吃的，咱们可使用git reflog命令回到将来：

$ git reflog
299e07a HEAD@{0}: reset: moving to 299e07a39e54 dc09f1d HEAD@{1}: reset: moving to HEAD^ 299e07a HEAD@{2}: commit: two edit dc09f1d HEAD@{3}: commit (initial): first commit

有了版本号ID，你就可使用回到将来了。

四、版本修改

4.一、管理修改

这里先说一下，Git有工做区和暂存区。工做区就是咱们肉眼能看到的目录，暂存区存放的是修改的记录。咱们前面的git add命令就是把文件添加到暂存区，git commit命令就是提交暂存区的全部修改：

好比咱们如今把readme.txt文件稍做修改，添加多一行文字，以下图所示：

使用git add命令把readme.txt文件添加到暂存区：

$ git add readme.txt

咱们再修改readme.txt文件的内容为：

最后使用git commit命令将暂存区提交全部修改：

$ git commit -m "three edit"
[master 5308250] three edit 1 file changed, 3 insertions(+), 1 deletion(-)

使用git status命令查看一下Git仓库的状态：

$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

提示有文件修改了没添加至暂存区，为何呢？咱们刚刚不是把readme.txt文件添加到暂存区了吗？

咱们先回想一下刚刚添加的步骤：

1.修改readme.txt文件

2.把readme.txt文件添加到暂存区

3.再次修改readme.txt文件

4.提交到Git仓库

咱们是把第一次修改readme.txt文件时添加到暂存区中，所以暂存区只存放了咱们的第一次修改记录，而第二次修改后咱们没及时把readme.txt文件添加到暂存区，所以提交时只会把暂存区记录的第一次修改提交到Git仓库。

不相信？咱们可使用git diff命令查看本地和最新版本里readme.txt文件的区别：

$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt index 60f01b0..f469ed7 100644 --- a/readme.txt +++ b/readme.txt @@ -2,4 +2,4 @@ one edit two edit -three \ No newline at end of file +four \ No newline at end of file

可见，第二次修改是没有被提交到Git仓库里的。

若是你的当前仓库状态没有任何修改，那么仓库状态应为：

$ git status
On branch master
nothing to commit, working directory clean

4.二、撤消修改

咱们把readme.txt文件修改成以下内容：

咱们先使用git status查看一下状态：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

有一句提示是，使用git checkout -- <file>撤消对工做区的修改。

好了，我忽然间不想改这个文件了，我须要复原。那么可使用git checkout -- file撤消对工做区的修改：

$ git checkout -- readme.txt

再次打开readme.txt文件查看内容：

果真，readme.txt已经复原了。提示：git checkout -- <file>命令是把文件回到最近一次git commit或git add时的状态。

咱们再次添加一些无用的内容，并把文件添加至暂存区：

使用git status命令查看当前的状态：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) modified: readme.txt

有一句提示为，使用git reset HEAD <file>能够把该文件在暂存区的修改撤消掉。

回到正题，刚改的内容我不想提交到Git仓库，咱们可使用git reset HEAD <file>把暂存区的修改撤消，把该文件的修改所有放回到工做区中：

$ git reset HEAD readme.txt 
Unstaged changes after reset:
M    readme.txt

如今再使用git status命令查看当前状态：

$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

4.三、删除文件

咱们先增长一个“git.txt”文件，而后把它提交上Git仓库：

$ git add git.txt 
baijiawei-de-mac:TestGit baijiawei$ git commit -m "add git.txt" [master e7a8c02] add git.txt 1 file changed, 5 insertions(+) create mode 100644 git.txt

如今，咱们把“git.txt”删除，删除后使用git status命令查看一下状态：

$ git status
On branch master
Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: git.txt no changes added to commit (use "git add" and/or "git commit -a")

git会告诉你删除了“git.txt”文件，但还没提交。

状况一：使用git rm命令删除“git.txt”命令并提交：

$ git rm git.txt
rm 'git.txt' $ git commit -m "delegate git.txt" [master 8652eea] delegate git.txt 1 file changed, 5 deletions(-) delete mode 100644 git.txt

状况二：删除错了文件，想要复原：

$ git checkout -- git.txt
$ ls
git.txt        readme.txt

不少时候咱们修改错了文件，均可以使用git checkout命令进行复原。

五、分支管理

5.一、建立与合并

咱们如今新建test分支，并切换至test分支：

$ git branch test
$ git checkout test Switched to branch 'test'

或：

$ git checkout -b test
Switched to a new branch 'test'

使用git checkout命令加上-b参数，表示新建并切换至分支。

使用git branch命令查看全部分支：

$ git branch
  master
* test

其中*号后面的就是当前所在分支。

这个分支能够正常使用了，咱们修改一下readme.txt的内容：

而后提交：

$ git add readme.txt 
$ git commit -m "add New Num" [test 6f9e769] add New Num 1 file changed, 3 insertions(+), 1 deletion(-)

咱们如今切换到master分支：

$ git checkout master
Switched to branch 'master'

再看一下readme.txt文件：

刚刚新增的一行内容已经不见了，由于咱们刚刚提交的是test分支，master分支是没有提交的。

咱们如今把它们合并一下：

$ git merge test
Updating c684781..6f9e769
Fast-forward readme.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

显示快速合并，由于不存在冲突，所以直接合并就能够了，后面会说到发生冲突时的状况。

合并后咱们再看一下readme.txt文件：

内容已经合并完成了。

咱们如今能够把test分支删除：

$ git branch -d test
Deleted branch test (was 6f9e769).

在git branch命令后面加上-d参数，表示删除分支。

咱们使用git branch命令查看全部分支：

$ git branch
* master

如今就只剩下master这个分支了。

5.二、合并冲突

每每进行合并时都不会那么顺心，每每会发生冲突。

咱们如今建立branchTest分支：

$ git checkout -b branchTest
Switched to a new branch 'branchTest'

修改readme.txt文件：

在branchTest分支上提交：

$ git add readme.txt
$ git commit -m "I like here" [branchTest f1dc9cb] I like here 1 file changed, 1 insertion(+), 1 deletion(-)

切换至master分支：

$ git checkout master
Switched to branch 'master'

修改readme.txt文件：

而后在master分支提交：

$ git add readme.txt 
$ git commit -m "I don't like here" [master 87ef579] I don't like here 1 file changed, 1 insertion(+), 1 deletion(-)

咱们尝试一下使用git merge合并分支：

$ git merge branchTest
Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result.

果真，Git提示咱们有错误发生（冲突）。它本身不能完成合并，咱们须要手动解决冲突。

咱们也可使用git status命令查看冲突的文件：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

咱们查看readme.txt文件：

Git用<<<<<<<、=======、>>>>>>>表示不一样分支的内容。

咱们把readme.txt文件内容改为以下图所示：

提交修改：

$ git add readme.txt 
$ git commit -m "finish merge" [master 1bb3712] finish merge

咱们可使用git log命令查看分支的合并状况：

$ git log --graph
* commit 1bb37128048d172cfe928fff96f68578b7c6f933 |\ Merge: 87ef579 f1dc9cb | | Author: GarveyCalvin <1147626297@qq.com> | | Date: Sun Jan 18 23:28:12 2015 +0800 | | | | finish merge | | | * commit f1dc9cb9e2f387b35fe323b67bf6d49eeae00ea8 | | Author: GarveyCalvin <1147626297@qq.com> | | Date: Sun Jan 18 23:16:09 2015 +0800 | | | | I like here | | * | commit 87ef57980131541f82216b7359ca7beb50c65010 |/ Author: GarveyCalvin <1147626297@qq.com> | Date: Sun Jan 18 23:19:25 2015 +0800 | | I don't like here | * commit 6f9e769ac382f77001b29bd8b2d3b92054390c3e | Author: GarveyCalvin <1147626297@qq.com> | Date: Sun Jan 18 22:55:52 2015 +0800 |

使用--graph参数能够查看分支的合并图。你们是否以为显示的内容太多了？大家能够尝试在后面添加--pretty=oneline --abbrev-commit参数，添加后再查看，你会发现结果简洁了许多。

如今咱们能够删除branchTest分支了：

$ git branch -d branchTest
Deleted branch branchTest (was f1dc9cb).

5.三、分支管理技巧

在合并分支时，若是Git可以快速合并（Fast-forward），那么它会直接执行合并（merge）操做。可是，使用它来进行合并（merge），合并（merge）并删除分支后，会丢失分支信息，这样不利于咱们往后查看。

所以，咱们通常会禁用快速合并（Fast-forward）功能，Git会在合并（merge）时提交一个新的Commit，这样，咱们就能从历史上看到分支的信息。

Git merge命令后加上--no-ff就是禁用快速合并（Fast-forward）功能。

咱们先创建并切换到一个新分支test：

$ git checkout -b test
Switched to a new branch 'test'

修改并提交readme.txt文件：

$ git add readme.txt 
$ git commit -m "hello world" [test 4a06fc6] hello world 1 file changed, 2 insertions(+)

提交完后切换回master分支：

$ git checkout master
Switched to branch 'master'

合并test分支：

$ git merge --no-ff -m "merge test" test
Merge made by the 'recursive' strategy. readme.txt | 2 ++ 1 file changed, 2 insertions(+)

--no-ff参数表示禁用快速合并（Fast-forward），由于此次是合并并提交，所以须要加上-m参数备注分支。

合并后查看日志记录：

$ git log --graph --pretty=oneline --abbrev-commit
* 2b7a3a0 merge test now |\ | * 561f8b3 edit readme |/

经过禁用快速合并（Fast-forward），咱们能够从日志里清晰看到曾经作过合并。这是快速合并所作不到的。

为了更清晰地展示二者间的区别，我刚刚又作了一个快速合并（Fast-forward）的操做：

$ git log --graph --pretty=oneline --abbrev-commit
* 6e84f57 error * 2b7a3a0 merge test now |\ | * 561f8b3 edit readme |/

从历史上咱们能够看到，若是是直接使用快速合并（Fast-forward），咱们在历史上就只能看到分支提交的Commit，但并不知道是从test分支上合并的; 但若是使用--no-ff参数禁用快速合并（Fast-forward），那么咱们就能从历史上清晰看到是与哪一个分支合并。

5.四、临时分支

有时候，咱们想要建立一个临时分支，用来修复一些紧急问题或者是突如其来的任务变动，这些谁也说不许。

在你工做没完成的时候，忽然测试人员走过来跟你说，有一个很紧急的BUG须要修复。这时候你不得不抛下目前的工做去完成他指派给你的BUG，可是，你手头上还有工做没完成，只完成了一部分：

$ git status
On branch master
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

那么，这个时候咱们可使用git stash命令，把当前工做区的内容存储起来，往后继续工做的时候能够把它恢复：

$ git stash
Saved working directory and index state WIP on master: 6e84f57 error
HEAD is now at 6e84f57 error $ git status On branch master nothing to commit, working directory clean

使用git status验证工做区是不是干净的：

$ git status
On branch master
nothing to commit, working directory clean

从结果看出工做区是干净的。

好比如今咱们要修复一个BUG，它的ID为4293－1，咱们先建立并切换到新分支：

$ git checkout -b bug-4293-1
Switched to a new branch 'bug-4293-1'

假设咱们已经完成了BUG修复，提交到Git：

$ git add readme.txt 
$ git commit -m "fix bug" [bug-4293-1 d82ca8f] fix bug 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支，合并bug-4293-1分支，最后删除bug-4293-1分支：

$ git checkout master
Switched to branch 'master' $ git merge --no-ff -m "merge fix bug" bug-4293-1 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -D bug-4293-1 Deleted branch bug-4293-1 (was d82ca8f).

那么该回到以前的工做区上工做了，咱们可使用git stash list查看存储的工做区列表：

$ git stash list
stash@{0}: WIP on master: 6e84f57 error

使用git stash apply恢复：

$ git stash apply
Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt

如今，工做区的文件已经所有恢复了。

最后把存储的工做区删除掉：

$ git stash drop stash@{0}
Dropped stash@{0} (783bdbe7bc4cfff89709dd273fd7b469a9041277)

如今已经把存储的工做区给删除了。如今恢复和删除是分两步的操做，咱们还能够把它们合并为一步，也就是恢复而且删除，咱们可使用git stash pop命令。

如今使用git stash list命令已经查看不到有存储的工做区了：

$ git stash list

5.五、远程分支

这里假定你的仓库已经连接上了远程仓库

如何把本地分支推送到远程分支？好比现已有分支dev，咱们须要把 dev 推送到远程分支

$ git push origin dev

有时候远程分支已存在与本地分支相同名称的分支，可是你又想把本地的分支覆盖远程相同名字的分支，这时就要强制推送了

git push -f origin dev

注意：此举影响重大，在多人协做的时候必定要注意，很容易坑了别人又坑了本身，因此尽可能避免强制推送吧

那么咱们想要删除一个远程分支呢？好比咱们要删除远程的dev分支

$ git push origin :dev

六、Git标签

6.一、建立标签

使用git tag <name>命令打标签：

$ git tag v1.0.0

使用git tag命令能够查看全部标签：

$ git tag
v1.0.0

使用git tag show <name>命令能够查看标签信息：

$ git show v1.0.0
commit 9e53375e4a84bde213aa2a8d5c77adc251ca1503
Author: GarveyCalvin <1147626297@qq.com> Date: Tue Jan 20 11:16:58 2015 +0800 formal ...

若是是已提交但忘记打标签的状况下，能够找到当时提交的ID，而后针对ID打标签：

$ git log --pretty=oneline 
7d5e44602cd32284782ea401dd8c2481fc12ca94 add tag
9e53375e4a84bde213aa2a8d5c77adc251ca1503 formal
ce809c52cb944e679f099ddf2d07e92469a25d53 merge fix bug
d82ca8f16ee7237bdafede1cc709a2d520137c18 fix bug
6e84f5775b0df132f4a737d7281eb0900d1de878 error
2b7a3a07c991a6a5ed4a28bc863d5211336ad96e merge test now
561f8b385bd03e8294fba643289c105de6ffc3df edit readme
ec1ffe29f87da4304abf964e7629dc671c3a59b1 test
87ef57980131541f82216b7359ca7beb50c65010 I don't like here
6f9e769ac382f77001b29bd8b2d3b92054390c3e add New Num c6847813d853e7e70739a55df487407314b7ee30 three edit new 5308250b75470b5754eca360d43a03c74820d4de three edit 299e07a39e547e1b48f3fc657daa7e6d4ecbf6f4 two edit dc09f1df94afd30bca6726e9f0d3459e358ac560 first commit

好比在merge test now提交的那一次打标签，对应的ID是“2b7a3a07c”：

$ git tag v0.1.0 2b7a3a07c

使用git tag看一下当前全部的标签：

$ git tag
v0.1.0 v1.0.0

能够看到咱们刚刚新打的标签v0.1.0。

再查询v0.0.1标签的信息：

$ git show v0.1.0
commit 2b7a3a07c991a6a5ed4a28bc863d5211336ad96e
Merge: ec1ffe2 561f8b3
Author: GarveyCalvin <1147626297@qq.com> Date: Mon Jan 19 10:21:26 2015 +0800 merge test now

能够看到，标签已经打在了merge test now此次提交上。

咱们还能够建立有说明的标签，用-a表示标签名称，-m表示说明文字：

$ git tag -a v2.0.0 -m "formal v2.0.0"

查看标签的信息：

$ git show v2.0.0
tag v2.0.0 Tagger: GarveyCalvin <1147626297@qq.com> Date: Tue Jan 20 11:38:10 2015 +0800 formal v2.0.0 commit d5161f9ba613100455a010a3afc312d32a99b68b Author: GarveyCalvin <1147626297@qq.com> Date: Tue Jan 20 11:37:28 2015 +0800 detail tag ...

能够看到咱们刚刚写的说明“formal v2.0.0”。

6.二、标签管理

使用git tag -d命令删除标签：

$ git tag -d v1.0.0
Deleted tag 'v1.0.0' (was 9e53375)

使用git push origin <tagName>推送至远程仓库：

$ git push origin v1.0.0
Total 0 (delta 0), reused 0 (delta 0) To https://git.oschina.net/GarveyCalvin/testProject.git * [new tag] v1.0.0 -> v1.0.0

使用git push origin --tags把全部未推送的标签推送到远程仓库：

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0) To https://git.oschina.net/GarveyCalvin/testProject.git * [new tag] v0.0.1 -> v0.0.1 * [new tag] v0.1.0 -> v0.1.0

若是已经推送到远程仓库，如今想要删除的话，首先从本地移除对应的tag：

$ git tag -d v0.0.1
Deleted tag 'v0.0.1' (was bc2cb64)

而后在git puh origin命令后面加上:refs/tags/<tag name>删除：

$ git push origin :refs/tags/v0.0.1
To https://git.oschina.net/GarveyCalvin/testProject.git
 - [deleted]         v0.0.1

除了这种方法，你也能够自行到远程仓库网站把Tag删除。

七、自定义Git

7.一、忽略特殊文件/文件夹

在有些时候，咱们的Git项目里会有一些特殊的文件，多是系统自生成的文件，在你每次提交的时候都会提示你有文件改动了，提示你添加这些文件。这样是否是很烦人？所以咱们须要忽略这类文件。

好比在Mac系统里，每一个文件夹都会生成一个".DS_Store"的隐藏文件，用来存放文件夹的排序等信息，这些文件也会在查看git status时出现，而且它们出现的次数很是多，使人感受很是烦。你是否有疑惑为何你看了这篇博文这么久，都没有看到过这些提示，那是由于我没截所有的提示：）。好了，下面就教你们怎样去忽略它。

咱们须要在Git工做区的根目录下建立.gitignore文件，在这以前咱们先建立一些须要忽略的文件夹：

以上这些文件和文件夹都是须要Git去忽略掉的。

咱们先使用git status查看一下状态：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) .DS_Store bad/ ignore/ other/ nothing added to commit but untracked files present (use "git add" to track)

没自定义忽略的文件/文件夹前，会把全部改动过的文件/文件夹进行提示。

若是大家没看见有文件夹显示，那是由于你的文件夹下没有文件/文件夹，Git自动会忽略空目录。解决方法很简单，只要在文件夹下添加文件就能够了。

如今咱们能够建立.gitignore文件了，文件内容以下所示：

# remark
*.DS_Store ignore
other
bad

有#号的那一行都是备注，并无实质做用。

*.忽略后缀名为……的文件

ignore、other、bad为忽略的文件夹

注意，要把.gitignore文件放到版本库里：

$ git add .gitignore

如今咱们再使用git status查看一下状态：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: .gitignore

如今就只能查询到.gitignore文件了，其它须要忽略的文件/文件夹已经被忽略掉。

7.2 建立别名

咱们能够像开发那样，本身定义一个关键字类型。

咱们查看状态时，通常都是使用git status，若是你想简化成git st，那么：

$ git config --global alias.st status

--global参数表示全局定义，也就是说定义了以后，在当前电脑下的全部Git仓库都通用。若是不想定义为全局，那么把--global参数去掉便可。

之后就能够直接使用git st命令查看状态了：

$ git st
On branch master
Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: .gitignore

前面咱们想要简化git log显示内容时，是否须要输入一大串字符(git log --pretty=oneline --abbrev-commit)？如今咱们能够为它建立别名进行简化输入了，而且显示更增强大：

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"

代码片断转自：http://blog.csdn.net/n289950578/article/details/24465663

效果以下：

全局的Git配置文件在用户主目录（Macintosh HD ▸ Users ▸ 你的用户名）下的隐藏文件.gitconfig中：

当咱们想要取消别名时，只须要把对应的别名行删除便可。若是是定义非全局的Git配置文件，那么它在当前项目的根目录下的.git隐藏文件夹下的config文件。

八、Git管理软件

创建你们使用SourceTree管理Git库，功能强大，界面友好，使用简单，这里就很少做介绍了。

博文做者：GarveyCalvin

博文出处：http://www.cnblogs.com/GarveyCalvin/

本文版权归做者和博客园共有，欢迎转载，但须保留此段声明，并给出原文连接，谢谢合做！