在Ubuntu上安装Git
sudo apt-get install git
创建版本库
创建一个库非常简单，首先，选择一个合适的地方，创建一个空目录：
mkdir 000 cd 000 pwd
第二步，通过git init命令把这个目录变成Git可以管理的仓库:
git init
现在我们编写一个a.py文件，内容如下：
aaa
一定要放到000目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
第一步，用命令git add告诉Git，把文件添加到仓库：
git add a.py
执行上面的命令，没任何显示，这就对了，Unix的哲学是"没有消息就是好消息"，说明添加成功。
第二步,用命令git commit告诉Git，把文件提交到仓库:
git commit -m "qa" [master cd9604a] qa 1 file changed, 1 insertion(+) create mode 100644 a.py
简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到记录。
嫌麻烦不想输入-m "xxx"行不行？确实有办法可以这么干，但是强烈不建议你这么干，因为输入说明对自己对别人阅读都很重要。实在不想输入说明的同学请自行Google,我不告诉你这个参数。
git commit命令执行成功后会告诉你，1file changed:1个文件别改动（我们新添加的a.py文件）;1 inserton:插入了两行内容（a.py有两行内容）。
版本回退
版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看：
root@lwj-virtual-machine:/home/lwj/000# git log
commit 57a1560a29f9f98a7970aae0009e3f2626d34ec8 (HEAD -> master)
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 22:17:50 2019 +0800
1.txt
commit fa4152aafcd5d65f6d31dc396200b43c77cb26e6
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 22:16:59 2019 +0800
bbb
commit cd9604a85944aed6ca08524e5974aaee6c357e6e
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 14:33:07 2019 +0800
qa
commit bf3c4d7f75162054bdbc26c3f064401d93c3519f
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 01:36:12 2019 +0800
sb
commit 3b25857cd5b82a877845c5e097e87a203b66066a
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 01:31:11 2019 +0800
1.txt
commit 472747df732efac1033f2f5450ca103443720a49
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 01:29:30 2019 +0800
1.txt
git log命令显示从最近到最远的提交日志。
如果嫌输出信息太多，看到眼花缭乱的，可以试试加上--pretty=oneline参数:
57a1560a29f9f98a7970aae0009e3f2626d34ec8 (HEAD -> master) 1.txt fa4152aafcd5d65f6d31dc396200b43c77cb26e6 bbb cd9604a85944aed6ca08524e5974aaee6c357e6e qa bf3c4d7f75162054bdbc26c3f064401d93c3519f sb 3b25857cd5b82a877845c5e097e87a203b66066a 1.txt 472747df732efac1033f2f5450ca103443720a49 1.txt
需要友情提示的是，你看到的一大串类似57a1560...的是commit id(版本号)。
用HEAD表示当前版本，上一个版本就是HEAD^,上上一个版本就是HEAD^,当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
现在，我们要把当前版本1.txt回退到上一个版本bbb，就可以使用git reset命令：
root@lwj-virtual-machine:/home/lwj/000# git reset --hard HEAD^ HEAD 现在位于 fa4152a bbb
--hard参数有啥意义？这个后面再讲，现在你先放心使用。
我们用git log再看看现在版本库的状态：
root@lwj-virtual-machine:/home/lwj/000# git log
commit fa4152aafcd5d65f6d31dc396200b43c77cb26e6 (HEAD -> master)
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 22:16:59 2019 +0800
bbb
commit cd9604a85944aed6ca08524e5974aaee6c357e6e
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 14:33:07 2019 +0800
qa
commit bf3c4d7f75162054bdbc26c3f064401d93c3519f
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 01:36:12 2019 +0800
sb
commit 3b25857cd5b82a877845c5e097e87a203b66066a
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 01:31:11 2019 +0800
1.txt
commit 472747df732efac1033f2f5450ca103443720a49
Author: 2023413143 <2023413143@qq.com>
Date: Sun Dec 22 01:29:30 2019 +0800
1.txt
最新的那个版本1.txt已经看不到了，好比你从21世纪坐时光穿梭机来到了19世纪，想回去已经回不去了，肿么办？
办法其实还是有的，只要上面的命名行窗口还没有别关掉，你就可以顺着往上找，找到那个1.txt的commit id是57a1560...，于是就可以指定回到未来的某个版本：
root@lwj-virtual-machine:/home/lwj/000# git reset --hard 57a1560 HEAD 现在位于 57a1560 1.txt
版本号没必要写全，前几位就可以了，Git会自动去找，当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的，当你git reset --hard HEAD^回退到1.txt版本时，再恢复到bbb,就必须找到bbb的commit id。Git提供了一个命令git reflog用来记录你的每一次命令:
root@lwj-virtual-machine:/home/lwj/000# git reflog
57a1560 (HEAD -> master) HEAD@{0}: reset: moving to 57a1560
fa4152a HEAD@{1}: reset: moving to HEAD^
57a1560 (HEAD -> master) HEAD@{2}: commit: 1.txt
fa4152a HEAD@{3}: commit: bbb
cd9604a HEAD@{4}: commit: qa
bf3c4d7 HEAD@{5}: commit: sb
3b25857 HEAD@{6}: commit: 1.txt
472747d HEAD@{7}: commit (initial): 1.txt
终于舒了口气，从输出可知，1.txt的commit id是57a1560，现在，你又可以乘坐时光机回到为未来了。
撤销修改
自然，你是不会犯错的。不过现在·是凌晨两点，你正在赶一份工作报告，你在readme.txt中添加了一行：
$ cat 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. My stupid boss still prefers SVN.
在你准备提交前，你发现了stupid boss可能会让你丢掉这个月的奖金！
既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态，如果用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会告诉你，git checkout --file可以丢弃工作区的修改：
$ git checkout -- readme.txt
命令git checkout --readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改后还没有被提交到暂存区，现在撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit 或 git add时的状态。
现在，看看readme.txt的文件内容：
$ cat 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.
文件内容果然复原了。
git checkout -- file 命令中的 -- 很重要，没有 -- ，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。
删除文件
在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：
$ git add test.txt $ git commit -m "add test.txt" [master b84166e] add test.txt 1 file changed, 1 insertion(+) create mode 100644 test.txt
一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：
$ rm test.txt
这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，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: test.txt no changes added to commit (use "git add" and/or "git commit -a")
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit:
$ git rm test.txt rm ‘test.txt‘ $ git commit -m "remove test.txt" [master d46f35e] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt
现在，文件就从版本库中被删除了。
分支管理
分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。
但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
创建与合并分支
在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master,master才是指向提交的，所以HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上:
你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把maste指向dev的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完成分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下一条master分支：
真是太神奇了，你看得出来有些提交是通过分支完成的吗？
下面开始实战。
首先，我们创建dev分支，然后切换到dev分支：
root@lwj-virtual-machine:/home/lwj/master# git checkout -b dev 切换到一个新分支 ‘dev‘
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev $ git checkout dev Switched to branch ‘dev‘
然后用git branch命令查看当前分支：
root@lwj-virtual-machine:/home/lwj/master# git branch * dev master
git branch命令会列出所有分支，当前分支前面会标一个*号。
然后，我们就可以在dev分支上正常提交，比如myname.py做个修改，加上一行:
print("dev")
然后提交：
root@lwj-virtual-machine:/home/lwj/master# git add . root@lwj-virtual-machine:/home/lwj/master# git commit -m "dev" [dev 786791b] dev 1 file changed, 1 insertion(+)
现在，dev分支的工作完成，我们就可以切换回master分支：
root@lwj-virtual-machine:/home/lwj/master# git checkout master 切换到分支 ‘master‘ 您的分支与上游分支 ‘origin/master‘ 一致。
切换回到master分支后，再查看一个myname.py文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，我们把dev分支的工作成果合并到master分支上：
root@lwj-virtual-machine:/home/lwj/master# git merge dev 更新 d9d865f..786791b Fast-forward myname.py | 1 + 1 file changed, 1 insertion(+) root@lwj-virtual-machine:/home/lwj
git merge命令用于合并指定分支到当前分支。合并后，再查看myname.py的内容就可以看到，和dev分支的最新提示完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快速模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其它方式的合并。
合并完成后，就可以放心地删除dev分支了：
root@lwj-virtual-machine:/home/lwj/master# git branch -d dev 已删除分支 dev（曾为 786791b）。
删除后，查看branch，就只剩下master分支了：
root@lwj-virtual-machine:/home/lwj/master# git branch * master
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
解决冲突
人生不如意之事十之八九，合并分支往往也不是一帆风顺的。
准备新的feature1分支，继续我们的新分支开发：
root@lwj-virtual-machine:/home/lwj/master# git checkout -b feature1 切换到一个新分支 ‘feature1‘
修改myname.py最后一行，改为:
print("feature1")
在feature1分支上提交：
root@lwj-virtual-machine:/home/lwj/master# git add . root@lwj-virtual-machine:/home/lwj/master# git commit -m "feature1" [feature1 e5ad3a7] feature1 1 file changed, 2 insertions(+), 1 deletion(-)
切换到master分支：
root@lwj-virtual-machine:/home/lwj/master# git checkout master 切换到分支 ‘master‘ 您的分支领先 ‘origin/master‘ 共 1 个提交。 （使用 "git push" 来发布您的本地提交）
Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
在master分支上把myname.py文件的最后一行改为：
print("master1")
提交：
root@lwj-virtual-machine:/home/lwj/master# git add . root@lwj-virtual-machine:/home/lwj/master# git commit -m "master1" [master 1a61702] master1 1 file changed, 1 insertion(+), 1 deletion(-)
现在，master分支和feature1分支各自都分别有新的提交，变成了这样：
这种情况下，Git无法执行"快速合并"，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
root@lwj-virtual-machine:/home/lwj/master# git merge feature1 自动合并 myname.py 冲突（内容）：合并冲突于 myname.py 自动合并失败，修正冲突然后提交修正的结果。
果然冲突了，Git告诉我们，myname.py文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：
root@lwj-virtual-machine:/home/lwj/master# git status 位于分支 master 您的分支领先 ‘origin/master‘ 共 2 个提交。 （使用 "git push" 来发布您的本地提交） 您有尚未合并的路径。 （解决冲突并运行 "git commit"） （使用 "git merge --abort" 终止合并） 未合并的路径： （使用 "git add <文件>..." 标记解决方案） 双方修改： myname.py 修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）
我们可以直接查看mynae.py的内容：
root@lwj-virtual-machine:/home/lwj/master# cat myname.py
def myname():
print("master")
<<<<<<< HEAD
print("master1")
=======
print("feature1")
>>>>>>> feature1
Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容，我们修改如下后保存：
def myname():
print("master")
print("master1")
print("feature1")
再提交：
root@lwj-virtual-machine:/home/lwj/master# git add . root@lwj-virtual-machine:/home/lwj/master# git commit -m "master2" [master 6f533fc] master2
现在，master分支和feature1分支变成了下图所示：
用带参数的git log也可以看到分支的合并情况：
root@lwj-virtual-machine:/home/lwj/master# git log --graph --pretty=oneline --abbrev-commit * 6f533fc (HEAD -> master) master2 |\ | * e5ad3a7 (feature1) feature1 * | 1a61702 master1 |/ * 786791b dev * d9d865f (origin/master) master
最后，删除feature1分支：
root@lwj-virtual-machine:/home/lwj/master# git branch -d feature1 已删除分支 feature1（曾为 e5ad3a7）。
分支管理策略
通常，合并分支时，如果可能Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge：
首先，仍然创建并切换dev分支：
root@lwj-virtual-machine:/home/lwj/master# git checkout -b dev 切换到一个新分支 ‘dev‘
修改myname.py文件，并提交一个新的commit：
root@lwj-virtual-machine:/home/lwj/master# git add . root@lwj-virtual-machine:/home/lwj/master# git commit -m "dev" [dev c994a9c] dev 1 file changed, 1 insertion(+)
现在，我们切换回master:
root@lwj-virtual-machine:/home/lwj/master# git checkout master 切换到分支 ‘master‘ 您的分支领先 ‘origin/master‘ 共 2 个提交。 （使用 "git push" 来发布您的本地提交）
准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward:
root@lwj-virtual-machine:/home/lwj/master# git merge --no-ff -m "merge with no-ff" dev Merge made by the ‘recursive‘ strategy. myname.py | 1 + 1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们用git log看看历史：
* adc9efd (HEAD -> master) dev master |\ | * 8333c94 (dev) dev |/ * 6f533fc (origin/master) master2 |\ | * e5ad3a7 feature1 * | 1a61702 master1 |/ * 786791b dev * d9d865f master
可以看到，不使用Fast forward模式merge后就像这样：
Bug分支
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到一个修复一个代号为101的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
root@lwj-virtual-machine:/home/lwj/master# git status
位于分支 dev
尚未暂存以备提交的变更：
（使用 "git add <文件>..." 更新要提交的内容）
（使用 "git checkout -- <文件>..." 丢弃工作区的改动）
修改： myname.py
修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两小时内修复bug，怎么办？
幸好，Git还提供一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
root@lwj-virtual-machine:/home/lwj/master# git stash 保存工作目录和索引状态 WIP on dev: 9d5e2f4 merged bug fix 101
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件，）因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要再master分支上修复，就从master创建临时分支：
root@lwj-virtual-machine:/home/lwj/master# git checkout master 切换到分支 ‘master‘ 您的分支领先 ‘origin/master‘ 共 6 个提交。 （使用 "git push" 来发布您的本地提交） root@lwj-virtual-machine:/home/lwj/master# git checkout -b issue-101 切换到一个新分支 ‘issue-101‘
现在修复bug，需要在最后面添加一条数据为print("bug")，然后提交：
root@lwj-virtual-machine:/home/lwj/master# git add . root@lwj-virtual-machine:/home/lwj/master# git commit -m "fix bug 101" [issue-101 30f9bb8] fix bug 101 1 file changed, 1 insertion(+) root@lwj-virtual-machine:/home/lw
修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
root@lwj-virtual-machine:/home/lwj/master# git checkout master 切换到分支 ‘master‘ 您的分支领先 ‘origin/master‘ 共 6 个提交。 （使用 "git push" 来发布您的本地提交） root@lwj-virtual-machine:/home/lwj/master# git merge --no-ff -m "merge bug fix 101" issue-101 Merge made by the ‘recursive‘ strategy. myname.py | 1 + 1 file changed, 1 insertion(+)
太棒了，原计划两小时的bug修复只花了1个小时！现在，是时候接着回到dev分支干活了！
root@lwj-virtual-machine:/home/lwj/master# git checkout dev 切换到分支 ‘dev‘ root@lwj-virtual-machine:/home/lwj/master# git status 位于分支 dev 无文件要提交，干净的工作区
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
root@lwj-virtual-machine:/home/lwj/master# git stash list
stash@{0}: WIP on dev: 9d5e2f4 merged bug fix 101
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：
root@lwj-virtual-machine:/home/lwj/master# git stash pop
位于分支 dev
尚未暂存以备提交的变更：
（使用 "git add <文件>..." 更新要提交的内容）
（使用 "git checkout -- <文件>..." 丢弃工作区的改动）
修改： myname.py
修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）
丢弃了 refs/stash@{0} (055fee597c446985458a813f6fdcfa2992e8b947)
再用git stash list查看，就看不到任何stash内容了：
root@lwj-virtual-machine:/home/lwj/master# git stash list
Feature分支
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新的功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新的功能，最好新创建一个feature分支，在上面开发，完成后，合并最后，删除该feature分支。
现在，你终于接到一个新的任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。
于是准备开发：
root@lwj-virtual-machine:/home/lwj/master# git checkout -b feature-vulcan 切换到一个新分支 ‘feature-vulcan‘
5分钟后，开发完毕：
root@lwj-virtual-machine:/home/lwj/master# git add myname.py
root@lwj-virtual-machine:/home/lwj/master# git status
位于分支 feature-vulcan
要提交的变更：
（使用 "git reset HEAD <文件>..." 以取消暂存）
修改： myname.py
root@lwj-virtual-machine:/home/lwj/master# git commit -m myname.py
[feature-vulcan 03dee90] myname.py
1 file changed, 1 insertion(+)
切回dev，准备合并：
root@lwj-virtual-machine:/home/lwj/master# git checkout dev
一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
但是！
就在此时，接到上级命令，因经费不足，新功能必须取消！
虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：
root@lwj-virtual-machine:/home/lwj/master# 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分支还没被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。
现在我们强行删除：
$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e).
终于删除成功！
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
要查看远程库的信息，用git remote：
root@lwj-virtual-machine:/home/lwj/master# git remote origin
或者，用git remote -v显示更详细的信息：
root@lwj-virtual-machine:/home/lwj/master# git remote -v origin https://github.com/2023413143/000.git (fetch) origin https://github.com/2023413143/000.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应得远程分支上：
root@lwj-virtual-machine:/home/lwj/master# git push origin master
如果要推送其它分支，比如dev，就改成：
root@lwj-virtual-machine:/home/lwj/master# git push origin dev
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时该与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，是你的心情而定！
抓取分支
多人协作时，大家都会往master和dev分支上推送各自的修改。
现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：
root@lwj-virtual-machine:/home/lwj/000# git clone git@github.com:2023413143/000.git 正克隆到 ‘000‘... remote: Enumerating objects: 18, done. remote: Counting objects: 100% (18/18), done. remote: Compressing objects: 100% (8/8), done. remote: Total 18 (delta 3), reused 18 (delta 3), pack-reused 0 接收对象中: 100% (18/18), 完成. 处理 delta 中: 100% (3/3), 完成.
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。
不信可以用git branch命令看看：
root@lwj-virtual-machine:/home/lwj/000/000# git branch * master
现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支
root@lwj-virtual-machine:/home/lwj/000/000# git checkout -b dev origin/dev 分支 ‘dev‘ 设置为跟踪来自 ‘origin‘ 的远程分支 ‘dev‘。 切换到一个新分支 ‘dev‘
现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：
root@lwj-virtual-machine:/home/lwj/000/000# git add myname.py root@lwj-virtual-machine:/home/lwj/000/000# git commit -m "000 dev" [dev 4dcf1c9] 000 dev 1 file changed, 1 insertion(+) root@lwj-virtual-machine:/home/lwj/000/000# git push origin dev 对象计数中: 3, 完成. Delta compression using up to 4 threads. 压缩对象中: 100% (2/2), 完成. 写入对象中: 100% (3/3), 276 bytes | 276.00 KiB/s, 完成. Total 3 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), completed with 1 local object. To github.com:2023413143/000.git 018da08..4dcf1c9 dev -> dev
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：
root@lwj-virtual-machine:/home/lwj/master# git add myname.py root@lwj-virtual-machine:/home/lwj/master# git commit -m "master dev" [dev 81cdfaa] master dev 1 file changed, 1 insertion(+) root@lwj-virtual-machine:/home/lwj/master# git push origin dev Username for ‘https://github.com‘: 2023413143 Password for ‘https://2023413143@github.com‘: To https://github.com/2023413143/000.git ! [rejected] dev -> dev (fetch first) error: 无法推送一些引用到 ‘https://github.com/2023413143/000.git‘ 提示：更新被拒绝，因为远程仓库包含您本地尚不存在的提交。这通常是因为另外 提示：一个仓库已向该引用进行了推送。再次推送前，您可能需要先整合远程变更 提示：（如 ‘git pull ...‘）。 提示：详见 ‘git push --help‘ 中的 ‘Note about fast-forwards‘ 小节。
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先有git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
root@lwj-virtual-machine:/home/lwj/master# git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
展开对象中: 100% (3/3), 完成.
来自 https://github.com/2023413143/000
018da08..4dcf1c9 dev -> origin/dev
当前分支没有跟踪信息。
请指定您要合并哪一个分支。
详见 git-pull(1)。
git pull <远程> <分支>
如果您想要为此分支创建跟踪信息，您可以执行：
git branch --set-upstream-to=origin/<分支> dev
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
root@lwj-virtual-machine:/home/lwj/master# git branch --set-upstream-to=origin/dev dev 分支 ‘dev‘ 设置为跟踪来自 ‘origin‘ 的远程分支 ‘dev‘。
再pull:
root@lwj-virtual-machine:/home/lwj/master# git branch --set-upstream-to=origin/dev dev 分支 ‘dev‘ 设置为跟踪来自 ‘origin‘ 的远程分支 ‘dev‘。 root@lwj-virtual-machine:/home/lwj/master# git pull 自动合并 myname.py 冲突（内容）：合并冲突于 myname.py 自动合并失败，修正冲突然后提交修正的结果
这回git pull成功，但是合并有冲突，需要手动解决，解决的办法和分支管理中的解决冲突完全一样。解决后，提交，再push：
root@lwj-virtual-machine:/home/lwj/master# git add myname.py root@lwj-virtual-machine:/home/lwj/master# git commit -m "master dev" [dev 3b84c37] master dev root@lwj-virtual-machine:/home/lwj/master# git push origin dev Username for ‘https://github.com‘: 2023413143 Password for ‘https://2023413143@github.com‘: 对象计数中: 6, 完成. Delta compression using up to 4 threads. 压缩对象中: 100% (4/4), 完成. 写入对象中: 100% (6/6), 505 bytes | 505.00 KiB/s, 完成. Total 6 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 1 local object. To https://github.com/2023413143/000.git 4dcf1c9..3b84c37 dev -> dev
Rebase
在上一节我们看到了，多人在同一分支协作时，很容易出现冲突。即使没有冲突，后push的同学不得不先pull，在本地合并，然后才能push成功。
每次合并再push后，分支变成了这样：
$ git log --graph --pretty=oneline --abbrev-commit * d1be385 (HEAD -> master, origin/master) init hello * e5e69f1 Merge branch ‘dev‘ |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed
总之看上去很乱，有强迫症的同学会问：为什么Git的提交历史不能是一条干净的直线？其实是可以做到的！
Git有一种称为rebase的操作，有人把它翻译成“变基”。
先不要随意展开想象。我们还是从实际问题出发，看看怎么把分叉的提交变成直线。
在和远程分支同步后，我们对hello.py这个文件做了两次提交。用git log命令看看：
$ git log --graph --pretty=oneline --abbrev-commit * 582d922 (HEAD -> master) add author * 8875536 add comment * d1be385 (origin/master) init hello * e5e69f1 Merge branch ‘dev‘ |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env ...
注意到Git用（HEAD -> master）和（origin/master）标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello,本地分支比远程分支快两个提交。
现在我们尝试推送本地分支：
$ git push origin master To github.com:michaelliao/learngit.git ! [rejected] master -> master (fetch first) error: failed to push some refs to ‘git@github.com:michaelliao/learngit.git‘ hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., ‘git pull ...‘) before pushing again. hint: See the ‘Note about fast-forwards‘ in ‘git push --help‘ for details.
很不幸，失败了，这说明有人先于我们推送了远程分支。按照经验，先pull下：
$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngit d1be385..f005ed4 master -> origin/master * [new tag] v1.0 -> v1.0 Auto-merging hello.py Merge made by the ‘recursive‘ strategy. hello.py | 1 + 1 file changed, 1 insertion(+)
再用git status看看状态：
$ git status On branch master Your branch is ahead of ‘origin/master‘ by 3 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean
加上刚才合并的提交，现在我们本地分支比远程分支超前3个提交。
用git log看看：
$ git log --graph --pretty=oneline --abbrev-commit * e0ea545 (HEAD -> master) Merge branch ‘master‘ of github.com:michaelliao/learngit |\ | * f005ed4 (origin/master) set exit=1 * | 582d922 add author * | 8875536 add comment |/ * d1be385 init hello ...
对强迫症童鞋来说，现在事情有点不对头，提交历史分叉了。如果现在把本地分支push到远程，有没有问题？
有！
什么问题？
不好看！
有没有解决方法？
有！
这个时候，rebase就派上了用场。我们输入命令git rebase试试：
$ git rebase First, rewinding head to replay your work on top of it... Applying: add comment Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py Applying: add author Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py
输出了一大堆操作，到底是啥效果？再用git log看看：
$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 * d1be385 init hello ...
原本分叉的提交现在变成了一条直线了！这种种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。
这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。
最后，通过push操作把本地分支推送到远程：
Mac:~/learngit michael$ git push origin master Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done. Total 6 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 1 local object. To github.com:michaelliao/learngit.git f005ed4..7e61ed4 master -> master
再用git log看看效果：
$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master, origin/master) add author * 3611cfe add comment * f005ed4 set exit=1 * d1be385 init hello ...
远程分支的提交历史也是一条直线。
创建标签
root@lwj-virtual-machine:/home/lwj/000# git branch * dev master root@lwj-virtual-machine:/home/lwj/000# git checkout master 切换到分支 ‘master‘
然后，敲命令git tag <name>就可以打一个新标签：
root@lwj-virtual-machine:/home/lwj/000# git tag v1.0
可以用命令git tag查看所有标签：
wj-virtual-machine:/home/lwj/000# git tag v1.0
默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
方法是找到历史提交的commit id，然后打上就可以了：
root@lwj-virtual-machine:/home/lwj/000# git log --pretty=oneline --abbrev-commit768d7e7 (HEAD -> master, tag: v1.0, origin/master, dev) myname1 21f7782 myname
比方说要对myname这次提交打标签，它对应得commit id是21f7782，敲入命令：
root@lwj-virtual-machine:/home/lwj/000# git tag v0.9 21f7782
再用命令git tag查看标签：
root@lwj-virtual-machine:/home/lwj/000# git tag v0.9 v1.0
注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
root@lwj-virtual-machine:/home/lwj/000# git show v0.9
commit 21f7782881b0afda7e45ad373c8e03976e7637a9 (tag: v0.9)
Author: 2023413143 <2023413143@qq.com>
Date: Wed Jan 1 15:30:23 2020 +0800
myname
diff --git a/myname.py b/myname.py
new file mode 100644
index 0000000..9f64bb9
--- /dev/null
+++ b/myname.py
@@ -0,0 +1,2 @@
+def myname():
+ print("1")
可以看到，v0.9确实打在myname这次提交上。
还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
root@lwj-virtual-machine:/home/lwj/000# git tag -a v0.1 -m "version 0.1 released" 21f7782
用命令git show <tagname>可以看到说明文字：
root@lwj-virtual-machine:/home/lwj/000# git show v0.1
tag v0.1
Tagger: 2023413143 <2023413143@qq.com>
Date: Wed Jan 1 15:44:44 2020 +0800
version 0.1 released
commit 21f7782881b0afda7e45ad373c8e03976e7637a9 (tag: v0.9, tag: v0.1)
Author: 2023413143 <2023413143@qq.com>
Date: Wed Jan 1 15:30:23 2020 +0800
myname
diff --git a/myname.py b/myname.py
new file mode 100644
index 0000000..9f64bb9
--- /dev/null
+++ b/myname.py
@@ -0,0 +1,2 @@
+def myname():
+ print("1")
操作标签
如果标签打错了，也可以删除：
root@lwj-virtual-machine:/home/lwj/000# git tag -d v0.1 已删除标签 ‘v0.1‘（曾为 4eb558f）
因为创建的标签只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
如果要推送某个标签到远程，使用命令git push origin <tagname>:
root@lwj-virtual-machine:/home/lwj/000# git push origin v1.0 Username for ‘https://github.com‘: 2023413143 Password for ‘https://2023413143@github.com‘: Total 0 (delta 0), reused 0 (delta 0) To https://github.com/2023413143/666.git * [new tag] v1.0 -> v1.0
或者，一次性推送全部尚未推送到远程的本地标签：
root@lwj-virtual-machine:/home/lwj/000# git push origin --tags Username for ‘https://github.com‘: 2023413143 Password for ‘https://2023413143@github.com‘: Total 0 (delta 0), reused 0 (delta 0) To https://github.com/2023413143/666.git * [new tag] v0.9 -> v0.9
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
root@lwj-virtual-machine:/home/lwj/000# git tag -d v0.9 已删除标签 ‘v0.9‘（曾为 21f7782）
然后，从远程删除。删除命令也是push，但是格式如下：
root@lwj-virtual-machine:/home/lwj/000# git push origin :refs/tags/v0.9 Username for ‘https://github.com‘: 2023413143 Password for ‘https://2023413143@github.com‘: To https://github.com/2023413143/666.git - [deleted] v0.9
要看看是否真的从远程库删除了标签，可以登录GitHub查看。
使用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，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：
如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以干活，干完后，往自己的仓库推送。
如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。
使用码云
使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况（原因你懂的）。
如果我们希望体验Git飞一般的速度，可以使用国内的Git托管服务---码云（gitee.com）。
和GitHub相比，码云也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。对于团队协作开发，码云还提供了项目管理、代码托管、文档管理的服务，5人以下小团队免费。
码云的免费版本也提供私有库功能，只是有5人的成员上限。
使用码云和使用GitHub类似，我们在码云上注册账号并登录后，需要先上传自己的SSH公钥。选择右上角用户头像->菜单“修改资料”，然后选择“SSH公钥”，填写一个便于识别的标题，然后把用户主目录下的.ssh/id_rsa.pub文件的内容粘贴进去：
如果我们已经有了本地的git仓库（例如，一个名为learngit的本地库），如何把它关联到码云的选择的远程库呢？
首先，我们在码云上创建一个新的项目，选择+，然后点新建仓库：
项目名称最好与本地库保持一致：
然后，我们在本地库上使用命令git remote add把它和码云的远程库关联：
git remote add origin https://gitee.com/wen_jun_lil/liwenjun.git
之后，就可以正常地用git push和git pull推送了！
如果在使用命令git remote add时报错：
git remote add origin https://gitee.com/wen_jun_lil/liwenjun.git fatal: remote origin already exists.
这说明本地库已经关联了一个名叫origin的远程库，此时，可以先用git remote -v查看远程库信息：
root@lwj-virtual-machine:/home/lwj/333# git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push)
可以看到，本地库已经关联了origin的远程库，并且，该远程库指向GitHub。
我们可以删除已有的GitHub远程库：
git remote rm origin
再关联码云的远程库（注意路径中需要填写正确的用户名）：
git remote add origin https://gitee.com/wen_jun_lil/liwenjun.git
此时，我们再查看远程库信息：
root@lwj-virtual-machine:/home/lwj/333# git remote -v origin https://gitee.com/wen_jun_lil/liwenjun.git (fetch) origin https://gitee.com/wen_jun_lil/liwenjun.git (push)
现在可以看到，origin已经被关联到码云的远程库了。通过git push命令就可以把本地库推送到Gitee上。
有的小伙伴又要问了，一个本地库能不能即关联GitHub，又关联码云呢？
答案是肯定的，因为git本身是分布版本控制系统，可以同步到另外一个远程库，当然也可以同步到另外两个远程库。
使用多个远程库时，我们要注意，git给远程库起的默认名称是origin，如果有多个远程库，我们需要用不同的名称来标识不同的远程库。
然后以liwenjun本地库为例，我们先删除已关联的名为origin的远程库：
git remote add github git@github.com:michaelliao/liwenjun.git
注意，远程库的名称叫github，不叫origin了。
接着，再关联码云的远程库：
git remote add gitee git@gitee.com:liaoxuefeng/liwenjun.git
同样注意，远程库的名称叫gitee，不叫origin。
现在，我们用git remote -v查看远程库信息，可以看到两个远程库：
git remote -v gitee https://gitee.com/wen_jun_lil/liwenjun.git (fetch) gitee https://gitee.com/wen_jun_lil/liwenjun.git (push) origin https://github.com/2023413143/liwenjun.git (fetch) origin https://github.com/2023413143/liwenjun.git (push)
如果要推送到GitHub，使用命令：
git push github master
如果要推送到码云，使用命令：
git push gitee master
这样一来，我们的本地库就可以同时与多个远程库互相同步：
码云也同样提供了Pull request功能，可以让其他小伙伴参与到开源项目中来。
忽略特殊文件
有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件，等等，每次git status都会显示Untracked files ...，有强迫症的同学心里肯定不爽。
好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览https://github.com/github/gitignore
忽略文件的原则是：
1、忽略操作系统自动生成的文件，比如缩略图等；
2、忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如java编译产生的.class文件‘
3、忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
举个例子：
假设你在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 configuratuons: db.ini deploy_key_ras
最好一步就是把.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的第三行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。
配置别名
有没有经常敲错命令？比如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的时候，加上--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服务器
在远程仓库一节中，我们讲了远程仓库实际上和本地仓库没什么不同，纯粹为了7x24小时开机并交换大家的修改。
GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，即不想公开开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器为私有仓库使用。
搭建Git服务器需要准备一台Linux的机器，强烈推荐用Ubuntu和Debin，这样，通过几条简单的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
第五步：
出于安全考虑，第二步创建的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了，不要把有限的生命浪费到权限斗争中。
使用Source Tree
当我们对Git的提交、分支已经非常熟悉，可以熟练使用命令操作Git后，再使用GUI工具，就可以更高效。
Git有很多图形界面工具，这里我们推荐Source Tree，它是由Atlassian开发的免费Git图形界面工具，可以操作任何Git库。
首先从官网下载Source Tree并安装，然后直接运行Source Tree。
第一次运行Source Tree时，Source Tree并不知道我们的Git库在哪，如果本地已经有了Git库，直接从资源管理器把文件夹拖拽到Source Tree上，就添加了一个本地Git库：
也可以选择“New”-“Glone from URL”直接从远程克隆到本地。
提交
我们双击leargit这个本地库，Source Tree会打开另一个窗口，展示这个Git库的当前所有分支以及文件状态。选择左侧面板的“WORKSPACE”-“File status”,右侧会列出当前已修改的文件（Unstaged files）：
选中某个文件，改文件就自动添加到“Staged files”，实际上是执行了git add README.md命令：
然后，我们在下方输入Commit描述，点击“commit”,就完成了一个本地提交：
实际上是执行了git commit -m "update README.md"命令。
使用Source Tree进行提交就是这么简单，它的优势在于可以可视化观察文件的修改，并以红色和绿色高亮显示。
分支
在左侧面板的“BRANCHES”下，列出了当前本地库的所有分支。当前分支会加粗并用○标记。要切换分支，我们只需要选择该分支，例如master，然后点击右键，在弹出菜单中选择“Checkout master”，实际上是执行命令git checkout master：
要合并分支，同样选择待合并分支，例如dev，然后点击右键，在弹出菜单中选择“Merge dev into master”，实际上是执行命令git merge dev:
推送
在Source Tree的工具栏上，分别有pull和push，分别对应命令git pull和git push，只需要注意本地和远程分支的名称要对应起来，使用时十分简单。
注意到使用Source Tree时，我们只是剩下敲命令的麻烦，Source Tree本身还是通过Git命令来执行任何操作。如果操作失败，Source Tree会自动显示执行的Git命令以及错误信息，我们可以通过Git返回的错误信息知道出错的原因：
原文：https://www.cnblogs.com/linglinglingling/p/12081739.html