Git教程，常用命令

admin管理员组

文章数量:1122852

学习廖雪峰老师的git教程，本人比较懒，大部分是盗图，笔记比较乱，都是一些常用的命令。
Git的所有工作都是现在本地缓存的，只有执行git commit -m "简短说明" 后才会向服务器提交。
安装Git Debian/Ubuntu apt-get install git
Centos/RedHat yum install git
Windows 安装包下载 https://git-for-windows.github.io/
Mac 图形化界面 https://sourceforge/projects/git-osx-installer/
git --version 查看版本
################################################################################# Git配置 ls -a 或 ls -ah 方便查看隐藏文件 执行git config命令就是调用此文件 /etc/gitconfig 全部用户生效 --system调用的文件 ～/.gitcinfig 当前用户有效 --global调用的文件 .git/config 当前项目的配置文件 .git/config的配置会覆盖 /etc/gitconfig 中的同名变量。 win中配置文件一般在主目录下的对应用户文件夹擦 C:\Documents and Settings\$USER win中 /etc/gitconfig是在安装目录中。
################################################################################# 用户信息配置 git config --global user.name "leolan" git config --global user.email 842632422@qq 用了global选项后当前用户的所有项目默认使用此用户信息，某一项目若食用其它的用户信息。把--global去掉重新配置，会在该项目.git/config中重新生成配置就行了。 git config --global core.editor emace 指定emace为默认编辑器，不指定默认为vim
################################################################################# 差异化分析工具（冲突合并） git config --global merge.tool vimdiff git可以理解kdiff3 ,tkdiff,meld,xxdiff,emerge,vimdiff,gvimdiff,ecmerge,opendiff等工具的输出信息。
git config --list 查看已配置的用户信息 git config user.name 查看配置的用户名，改为user.email则为邮箱，改为对应的就行。
################################################################################# 使用方法 一般进入某项目的目录后再执行以下命令。 git init 设置当前目录为Git仓库 git init 目录名 指定目录为Git仓库
git clone ［源］ 从源拷贝项目到本地的当前目录 git clone ［源］［目录］ 指定源下载到某个目录 例：git clone git://github/schacon/grit.git mygrit
git status 查看当前目录文件的状态，加 -s 显示简短信息。 A是已添加到缓存、 M为文件有改动、 空格为未缓存的文件，组合显示如： AM代表已缓存的文件有改动， 空格M代表未缓存的文件有改动。 git add 文件名 添加文件到项目缓存中，没有添加的文件不属于项目文件，也不会痛不到服务器。 git add . 添加当前目录到项目缓存中，如果添加多个文件，此命令更方便。 git commit -m "项目的版本或简短说明" 可以指定版本号及简单说明改动了哪些内容，同时会把所有改动同步到服务器上。 git commit -am "项目的版本或简短说明" 改动了多个文件又不想一个个添加，此命令自动添加所有改动的文件并同步到服务器。
git diff 未缓存的改动 git diff --cached 已缓存的改动 git diff HEAD 已缓存和未缓存的所有改动 git diff --stat 显示摘要而非整个diff git reset -- HEAD 文件 取消文件已缓存的内容， --很重要，没有加 --表示切换到另一个分支。 git rm 文件 从项目中及本地删除文件 git mv 文件 从项目中及本地重命名文件
################################################################################# 版本回退 日常使用 git status 查看当前状态 git diff 查看做了哪些修改 git add file 添加到缓存 git commit -m "xxx" 提交
git log 进入项目目录执行，可以看到所有的历史版本，信息太多加 --pretty=oneline参数简化。
首先，Git必须知道当前版本是哪个版本，在Git中，用 HEAD 表示当前版本，也就是最新的提交 3628164...882e1e0 （注意我的提交ID和你的肯定不一样），上一个版本就是 HEAD^ ，上上一个版本就是 HEAD^^ ，当然往上100个版本写100个 ^ 比较容易数不过来，所以写成 HEAD~100 。 现在，我们要把当前版本“append GPL”回退到上一个版本“add distributed”，就可以使用 git reset 命令： git reset --hard HEAD^ 退回上一个版本 HEAD is now at ea34578 add distributed 看看readme.txt的内容是不是版本 add distributed ： $ cat readme.txtGit is a distributed version control system.Git is free software. 果然。 还可以继续回退到上一个版本 wrote a readme file ，不过且慢，然我们用 git log 再看看现在版本库的状态： $ git log commit ea34578d5496d7dd233c827ed32a8cd576c5ee85Author: Michael Liao <askxuefeng@gmail>Date: Tue Aug 20 14:53:12 2013 +0800 add distributedcommit cb926e7ea50ad11b8f9e909c05226233bf755030Author: Michael Liao <askxuefeng@gmail>Date: Mon Aug 19 17:51:55 2013 +0800 wrote a readme file 最新的那个版本 append GPL 已经看不到了！好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？ 办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个 append GPL 的 commit id 是 3628164... ，于是就可以指定回到未来的某个版本： $ git reset --hard 3628164 退回指定版本 HEAD is now at 3628164 append GPL 版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。 Git的版本回退速度非常快，因为Git在内部有个指向当前版本的 HEAD 指针，当你回退版本的时候，Git仅仅是把HEAD从指向 append GPL ：
改为指向 add distributed ：
然后顺便把工作区的文件更新了。所以你让 HEAD 指向哪个版本号，你就把当前版本定位在哪。 你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的 commit id 怎么办？ 在Git中，总是有后悔药可以吃的。当你用 $ git reset --hard HEAD^ 回退到 add distributed 版本时，再想恢复到 append GPL ，就必须找到 append GPL 的commit id。Git提供了一个命令 git reflog 用来记录你的每一次命令： $ git reflog 查询历史版本号 ea34578 HEAD@{0}: reset: moving to HEAD^3628164 HEAD@{1}: commit: append GPLea34578 HEAD@{2}: commit: add distributedcb926e7 HEAD@{3}: commit (initial): wrote a readme file 终于舒了口气，第二行显示 append GPL 的 commit id 是 3628164 ，现在，你又可以乘坐时光机回到未来了。
################################################################################# 管理修改 第一次修改 -> git add -> 第二次修改 -> git commit 你看，我们前面讲了，Git管理的是修改，当你用 git add 命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以， git commit 只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。 提交后，用 git diff HEAD -- readme.txt 命令可以查看 工作区 和 版本库 里面最新版本的区别： 怎么提交第二次修改呢？你可以继续 git add 再 git commit ，也可以别着急提交第一次修改，先 git add 第二次修改，再 git commit ，就相当于把两次修改合并后一块提交了： 第一次修改 -> git add -> 第二次修改 -> git add -> git commit 好，现在，把第二次修改提交了。
################################################################################# 撤销修改 当发现某部分代码需要撤销时 git checkout -- file 可以丢弃工作区的修改： $ git checkout -- readme.txt 命令 git checkout -- readme.txt 意思就是，把 readme.txt 文件在工作区的修改全部撤销，这里有两种情况： 一种是 readme.txt 自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态； 一种是 readme.txt 已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。 总之，就是让这个文件回到最近一次 git commit 或 git add 时的状态。
第一种： git checkout -- file（文件名） 命令中的 -- 很重要，没有 -- ，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到 git checkout 命令。 第二种： 现在假定是凌晨3点，你不但写了一些胡话，还 git add 到暂存区了： 庆幸的是，在 commit 之前，你发现了这个问题。用 git status 查看一下，修改只是添加到了暂存区，还没有提交： Git同样告诉我们，用命令 git reset HEAD file 可以把暂存区的修改撤销掉（ unstage ），重新放回工作区： git reset 命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用 HEAD 时，表示最新的版本。 再用 git status 查看一下，现在暂存区是干净的，工作区有修改 丢弃工作区的修改： $ git checkout -- readme.txt 直接恢复文件并恢复版本库的内容 $ git status # On branch master nothing to commit (working directory clean) git reset --hard HEAD 恢复到当前版本（git rm 后没有commit的那个版本，如果进行了commit，此次commit就是一个新版本，只能通过 git reset --hard HEAD^ 回到上一个commit） 现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还可以版本回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程，递交到远程后就没有办法咯。 注意：要完全撤回修改的代码，要git reset HEAD file 后执行git checkout -- file 才会完全包括工作区的内容也删除。
################################################################################# 删除文件 一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用 rm 命令删了： $ rm test.txt 此时文件删除了但版本库里还有记录，文件可能恢复不了。 这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了， git status 命令会提示你哪些文件被删除了 要从版本库中删除该文件，那就用命令 git rm 删掉，并且 git commit ［git rm会同时删除版本库及文件］ 另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本： $ git checkout -- test.txt git checkout 其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
提交代码的更改一共分2个阶段。 1).从工作目录，提交到 stage 。2).从 stage 提交到 master 。 从工作目录提交到 stage ，需要用 add 或者 rm 命令，只提交到 stage ，而没有提交到 master ，是不会自动同步到 master 的。 从 stage 提交到 master 用 commit 命令。 退回也是要分两步，一个是从 master 退回到 stage ，然后再从 stage 退回到工作目录。 对于还没有提交到 stage 的，可以从 stage 用 checkout 命令退回，这一步会取 stage 中的文件状态，覆盖掉工作目录中文件的状态，跟 master 完全没关系。 对于已经到达 stage 的，想把 state 中的文件状态用 master 中的覆盖掉，就用 reset 命令，这样就把 stage 中修改用 master 的状态覆盖掉了，完全跟工作目录没关系
################################################################################# 远程仓库
在继续阅读后续内容前，请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置： 第1步：创建SSH Key。在用户主目录下，看看有没有 .ssh 目录，如果有，再看看这个目录下有没有 id_rsa 和 id_rsa.pub 这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key： $ ssh-keygen -t rsa -C "youremail@example" 你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个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：
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。 当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。 最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。 ssh -T git@github 提示：Hi MyLeoLan! You've successfully authenticated, but GitHub does not provide shell access. 则成功添加sshkey #################################################################################
添加远程库 首先，登陆GitHub，然后，在右上角找到“ Create a new repo ”按钮，创建一个新的仓库： 在Repository name填入 learngit ，其他保持默认设置，点击“ Create repository ”按钮，就成功地创建了一个新的Git仓库： 目前，在GitHub上的这个 learngit 仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。 现在，我们根据GitHub的提示，在本地的 learngit 仓库下运行命令： $ git remote add origin git@github:myleolan/learngit.git 请千万注意，把上面的 myleolan 替换成你自己的GitHub账户名，否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。 添加后，远程库的名字就是 origin ，这是Git默认的叫法，也可以改成别的，但是 origin 这个名字一看就知道是远程库。 错误解决： error: src refspec master does not match any. 引起该错误的原因是，目录中没有文件，空目录是不能提交上去的 执行 git commit -m “xxx” error: insufficient permission for adding an object to repository database ./objects 服务端没有可写目录的权限［可能不是你的库，或 sshkey不对 ］ error：fatal: remote origin already exists. 解决办法： $ git remote rm origin error: failed to push som refs to ........ 解决办法： $ git pull origin master //先pull 下来 再push 上去 error: failed to push some refs to 'git@github:myleolan/learnpython.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. 解决办法：是因为远程用web创建的的库和本地不一样。 $ git pull origin master //先pull 下来 再push 上去 解决github push错误The requested URL returned error: 403 Forbidden while accessing # 将 [remote "origin"]   url = https://github/iopqrst/learn20140823.git 修改为： [remote "origin"] url =  https://iopqrst@github/iopqrst/learn20140823.git 就是加上 用户名@ 之后再次执行 git push 输入密码即可。
要关联（ 添加 ）一个远程库，使用命令 git remote add origin git@github:MyLeoLan/testgit.git 关联后，使用命令 git push -u origin master 第一次推送 master分支 的所有内容； 【由于远程库是空的，我们第一次推送 master分支 时，加上了 -u 参数，Git不但会把本地的 master 分支内容推送的远程新的 master 分支，还会把本地的 master 分支和远程的 master 分支关联起来，在以后的推送或者拉取时就可以简化命令。】
此后，每次本地提交后，只要有必要，就可以使用命令 git push origin master 推送最新修改； 分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！
当前的远程库 git remote 或 git remote -v
从远程库下载新分支和数据 git fetch origin
从远程仓库提取数据并尝试合并到当前分支 git pull origin
删除远程仓库 git remote rm ［别名，仓库名］
#################################################################################
从远程库克隆
现在，假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。 首先，登陆GitHub，创建一个新的仓库，名字叫 gitskills ： 我们勾选 Initialize this repository with a README ，这样GitHub会自动为我们创建一个 README.md 文件。创建完毕后，可以看到 README.md 文件 现在，远程库已经准备好了，下一步是用命令 git clone 克隆一个本地库： $ git clone git@github:michaelliao/gitskills.git 实际上，Git支持多种协议，默认的 git:// 使用 ssh ，但也可以使用 https 等其他协议。 使用 https 除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放 http 端口的公司内部就无法使用 ssh 协议而只能用 https 。
pull：本地 <-- 远程push：本地 --> 远程 本质上都是同步 commi t 如果你本地落后远程，必然要 pull 如果你本地超前远程，必然要 push
#################################################################################
分支 详见： http://www.liaoxuefeng/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840038939c291467cc7c747b1810aab2fb8863508000 创建分支可以在分支上工作而不影响 master 分支，党分支工作完成时再合并到 master 分支上。 一般流程： 先查看分支： git branch 创建+切换分支： git checkout -b <分支name> 等价于： 创建分支： git branch <分支name> + 切换分支： git checkout <分支name> 查看当前分支： git branch 在新建分支上进行工作，工作完成时。 切换回主分支： git checkout master 合并某分支到当前分支（当前已切换回 master 分支了）： git merge <分支name> 删除分支： git branch -d <分支name> 查看当前分支： git branch 只剩 master分支 啦。
################################################################################# 解决冲突 详见： http://www.liaoxuefeng/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840202368c74be33fbd884e71b570f2cc3c0d1dcf000 当合并出现冲突时，一般要手动解决。 直接查看master分支的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 59 bc1cb] conflict fixed
用带参数的 git log 也可以看到分支的合并情况： $ git log --graph --pretty=oneline --abbrev-commit 用 git log --graph 命令可以看到分支合并图。
#################################################################################
分支管理策略 合并分支时，如果可能，Git会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。 如果要强制禁用 Fast forward 模式，Git就会在 merge 时生成一个 新的commit ，这样，从分支历史上就可以看出分支信息。 下面我们实战一下 --no-ff 方式的 git merge ： 创建分支、修改文件，提交缓存，切换回 master分支 准备合并 dev 分支，请注意 --no-ff 参数，表示禁用 Fast forward ，因为本次合并要创建一个新的commit，所以加上 -m 参数，把commit描述写进去。 $ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 用 git log 看看分支历史： $ git log --graph --pretty=oneline --abbrev-commit * 7825a50 merge with no-ff|\| * 6224937 add merge|/* 59bc1cb conflict fixed... 分支策略 在实际开发中，我们应该按照几个基本原则进行分支管理： 首先， master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活； 那在哪干活呢？干活都在 dev 分支上，也就是说， dev 分支是不稳定的，到某个时候，比如1.0版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布1.0版本； 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。 所以，团队合作的分支看起来就像这样： Git分支十分强大，在团队开发中应该充分应用。 合并分支时，加上 --no-ff 参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。
#################################################################################
Bug分支
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支 issue-101 来修复它，但是，等等，当前正在 dev 上进行的工作还没有提交： $ git status # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # 。。。。。。。。 # modified: readme.txt # 并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？ 幸好，Git还提供了一个 stash 功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作： $ git stash Saved working directory and index state WIP on dev: 6224937 add mergeHEAD is now at 6224937 add merge 现在，用 git status 查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在 master 分支上修复，就从 master 创建临时分支： $ git checkout master $ git checkout -b issue-101 Switched to a new branch 'issue-101' 现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交： $ git add readme.txt $ git commit -m "fix bug 101" 修复完成后，切换到 master 分支，并完成合并，最后删除 issue-101 分支： $ git checkout master $ git merge --no-ff -m "merged bug fix 101" issue-101 $ git branch -d issue-101 Deleted branch issue-101 (was cc17032). 太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到 dev 分支干活了！
[root@VM_163_167_centos testgit]# git push origin master To git@github:MyLeoLan/testgit.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'git@github:MyLeoLan/testgit.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. push被拒绝,此时排除了没有commit的问题之后 先 git pull --rebase origin master 再 git pull origin master 即可解决。 git pull -f origin master 强制覆盖也行，但很危险。 $ 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 来删除；(stash只是临时封存区，建议删除) 另一种方式是用 git stash pop ，恢复的同时把stash内容也删了 $ git stash pop # On branch dev 。。。。。。。。 # modified: readme.txt # Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd4 0 ) 再用 git stash list 查看，就看不到任何stash内容了 可以多次 stash ，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash ，用命令： $ git stash apply stash@{0} 【stash@{0}是封存的标识】
################################################################################# Feature分支 软件开发中，总有无穷无尽的新的功能要不断添加进来。 添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该 feature分支 。 $ git checkout -b feature-vulcan Switched to a new branch 'feature-vulcan' 修改代码完成之后 $ git add vulcan.py $ git status $ git commit -m "add feature vulcan" 切回 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).
################################################################################# 多人协作 当你从远程仓库克隆时，实际上Git自动把本地的 master 分支和远程的 master 分支对应起来了，并且，远程仓库的默认名称是 origin 。 要查看远程库的信息，用 git remote ： $ git remote origin 或者，用 git remote -v 显示更详细的信息： $ git remote -v origin git@github:michaelliao/learngit.git (fetch)origin git@github:michaelliao/learngit.git (push) 上面显示了可以抓取和推送的 origin 的地址。如果没有推送权限，就看不到push的地址。

抓取分支 多人协作时，大家都会往 master 和 dev 分支上推送各自的修改。 现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆： $ git clone git@github:michaelliao/learngit.git 当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的 master 分支。不信可以用 git branch 命令看看： $ git branch * master 现在，你的小伙伴要在 dev 分支上开发， 就必须创建远程 origin 的 dev 分支 到本地，于是他用这个命令创建本地 dev 分支： $ git checkout -b dev origin/dev 【在 origin 上创建 Dev ， -b 切换到 Dev 分支】 现在，他就可以在 dev 上继续修改，然后，时不时地把 dev 分支 push 到远程： $ git commit -m "add /usr/bin/env" 本地已经有 dev 分支了就不用创建了，直接执行下面的命令会自动在远程服务器新建 dev 分支。 $ git push origin dev 【把本地 dev 推到远程 origin 上，会自动寻找 origin 的 Dev 分支】

多人协作时，大家都会往 master 和 dev 分支上推送各自的修改。 现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆： $ git clone git@github:michaelliao/learngit.git Cloning into 'learngit'...remote: Counting objects: 46, done.remote: Compressing objects: 100% (26/26), done.remote: Total 46 (delta 16), reused 45 (delta 15)Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.Resolving deltas: 100% (16/16), done. 当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的 master 分支。不信可以用 git branch 命令看看： $ git branch * master 现在，你的小伙伴要在 dev 分支上开发，就必须创建远程 origin 的 dev 分支到本地，于是他用这个命令创建本地 dev 分支： $ git checkout -b dev origin/dev ［如果本地已经有dev分支了，则pull就行］ 现在，他就可以在 dev 上继续修改，然后，时不时地把 dev 分支 push 到远程： $ git commit -m "add /usr/bin/env" [dev 291bea8] add /usr/bin/env 1 file changed, 1 insertion(+)$ git push origin dev
你的小伙伴已经向 origin/dev 分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送： $ git add hello.py $ git commit -m "add coding: utf-8" $ git push origin dev To git@github:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward)error: failed to push some refs to 'git@github:michaelliao/learngit.git'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Merge the remote changes (e.g. 'git pull')hint: before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details. 推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用 git pull 把最新的提交从 origin/dev 抓下来，然后，在本地合并，解决冲突，再推送： $ git pull remote: Counting objects: 5, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From github:michaelliao/learngit fc38031..291bea8 dev -> origin/devThere is no tracking information for the current branch.Please specify which branch you want to merge with.See git-pull(1) for details git pull <remote> <branch>If you wish to set tracking information for this branch you can do so with: git branch --set-upstream dev origin/<branch> git pull 也失败了，原因是没有指定本地 dev 分支与远程 origin/dev 分支的链接，根据提示，设置 dev 和 origin/dev 的链接： $ git branch --set-upstream dev origin/dev 【官方更改了命令 git branch --set-upstream-to=origin/dev dev 】 Branch dev set up to track remote branch dev from origin. 再次 git pull 成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的 解决冲突 完全一样。解决后，提交，再push： $ git commit -m "merge & fix hello.py" $ git push origin dev
多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin branch-name推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！

如果 git pull 提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令 git branch --set-upstream branch-name origin/branch-name 。 这就是多人协作的工作模式，一旦熟悉了，就非常简单。
F&Q 签出远程分支，出现以下错误： fatal: Cannot update paths and switch to branch 'develop' at the same time. 解决方案 先 git fetch 再 git checkout -b develop origin/develop 因为本地还没有'develop'分支信息，需要先 fetch 或者 pull
假设有人往服务器上推送了一个新的分支，但是我不知道分支的名称是什么，我如何能获取到服务器上的分支列表呢？

• 1. 你直接去问他
  2. 如果用GitHub，直接去网站看
  3. git ls-remote --heads origin

推送分支 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上： $ git push origin master 如果要推送其他分支，比如 dev ，就改成： $ git push origin dev 但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；
• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
################################################################################# 标签管理 发布一个版本时，我们通常先在版本库中打一个标签（ tag ），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。 Git的标签虽然是版本库的快照，但其实它就是指向某个 commit 的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。 Git有commit，为什么还要引入tag？ “请把上周一的那个版本打包发布，commit号是6a5819e...” “一串乱七八糟的数字不好找！” 如果换一个办法： “请把上周一的那个版本打包发布，版本号是v1.2” “好的，按照tag v1.2查找commit就行！” 所以， tag 就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。
创建标签 在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 101cc17032 fix bug 1017825a50 merge with no-ff6224937 add merge59bc1cb conflict fixed400b400 & simple75a857c AND simplefec145a branch testd17efd8 remove test.txt... 比方说要对 add merge 这次提交打标签，它对应的 commit id 是 6224937 ，敲入命令： $ git tag v0.9 6224937 再用命令 git tag 查看标签： $ git tag v0.9v1.0 注意，标签不是按时间顺序列出，而是按字母排序的。可以用 git show <tagname> 查看标签信息： $ git show v0.9 commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4Author: Michael Liao <askxuefeng@gmail>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.1Tagger: Michael Liao <askxuefeng@gmail>Date: Mon Aug 26 07:28:11 2013 +0800version 0.1 releasedcommit 3628164fb26d48395383f8f31179f24e0882e1e0Author: Michael Liao <askxuefeng@gmail>Date: Tue Aug 20 15:11:49 2013 +0800 append GPL 还可以通过 -s 用私钥签名一个标签： $ git tag -s v0.2 -m "signed version 0.2 released" fec145a 签名采用PGP签名，因此，必须首先安装 gpg（GnuPG） ，如果没有找到gpg，或者没有gpg密钥对，就会报错： gpg: signing failed: secret key not availableerror: gpg failed to sign the dataerror: unable to sign the tag 如果报错，请参考GnuPG帮助文档配置Key。 如果签名不成功可以加-u 参数，详见： http://airk000.github.io/git/2013/09/30/git-tag-with-gpg-key 用命令 git show <tagname> 可以看到PGP签名信息： $ git show v0.2 tag v0.2Tagger: Michael Liao <askxuefeng@gmail>Date: Mon Aug 26 07:28:33 2013 +0800signed version 0.2 released-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.12 (Darwin)iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo...-----END PGP SIGNATURE-----commit fec145accd63cdc9ed95a2f557ea0658a2a6537fAuthor: Michael Liao <askxuefeng@gmail>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可以查看所有标签。

操作标签

• 命令git tag -d <tagname>可以删除一个本地标签；
• 命令git push origin <tagname>可以推送一个本地标签；
• 命令git push origin --tags可以推送全部未推送过的本地标签；
• 先删除本地对应的标签，再运行命令git push origin :refs/tags/<tagname>删除一个远程标签。

################################################################################# 使用GitHub 如何参与一个开源项目呢？比如人气极高的bootstrap项目，这是一个非常强大的CSS框架，你可以访问它的项目主页 https://github/twbs/bootstrap ， 点“ Fork ”就在自己的账号下克隆了一个bootstrap仓库 ，然后，从自己的账号下clone： git clone git@github:michaelliao/bootstrap.git 一定要从自己的账号下clone仓库，这样你才能推送修改。如果从bootstrap的作者的仓库地址 git@github:twbs/bootstrap.git 克隆，因为没有权限，你将不能推送修改。 Bootstrap的官方仓库 twbs/bootstrap 、你在GitHub上克隆的仓库 my/bootstrap ，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样： 如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。 如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个 pull request 。当然，对方是否接受你的 pull request 就不一定了。 如果你没能力修改bootstrap，但又想要试一把 pull request ，那就 Fork 一下我的仓库： https://github/michaelliao/learngit ，创建一个 your-github-id.txt 的文本文件，写点自己学习Git的心得，然后推送一个pull request给我，我会视心情而定是否接受。
################################################################################# 自定义Git 我们已经配置了 user.name 和 user.email ，实际上，Git还有很多可配置项。 比如，让Git显示颜色，会让命令输出看起来更醒目： $ git config --global color.ui true
忽略特殊文件 有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次 git status 都会显示 Untracked files ... ，有强迫症的童鞋心里肯定不爽。 好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。 不需要从头写 .gitignore 文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览： https://github/github/gitignore 已经配置好了要忽略的文件，下载回来要文件名要改为 .gitignore 忽略文件的原则是：

1. 忽略操作系统自动生成的文件，比如缩略图等；
2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

举个例子： 假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有 Desktop.ini 文件，因此你需要忽略Windows自动生成的垃圾文件： 然后，继续忽略Python编译产生的 .pyc、.pyo、dist 等文件或目录： 加上你自己定义的文件，最终得到一个完整的 .gitignore 文件，内容如下： # Windows: Thumbs.dbehthumbs.dbDesktop.ini # Python: *.py[cod]*.so*.egg*.egg-infodistbuild # My configurations: db.inideploy_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.classUse -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做版本管理！

配置别名 有没有经常敲错命令？比如 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 adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2Merge: bd6ae48 291bea8Author: Michael Liao <askxuefeng@gmail>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: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 配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。
#################################################################################
搭建Git服务器 在 远程仓库 一节中，我们讲了远程仓库实际上和本地仓库没啥不同，纯粹为了7x24小时开机并交换大家的修改。 GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。 搭建Git服务器需要准备一台运行Linux的机器，强烈推荐用Ubuntu或Debian，这样，通过几条简单的 apt 命令就可以完成安装。 假设你已经有 sudo 权限的用户账号，下面，正式开始安装。 第一步，安装 git ： $ sudo apt-get install git 或 yum install git 第二步，创建一个 git 用户，用来运行 git 服务： $ sudo adduser git
第三步，初始化Git仓库： 先选定一个目录作为Git仓库，假定是 /data/git/learngit.git ，在 /data/git/ 目录下输入命令： $ sudo git init --bare learngit.git Git就会创建一个裸仓库，裸仓库没有工作区，因为服务器上的Git仓库纯粹是为了共享，所以不让用户直接登录到服务器上去改工作区，并且服务器上的Git仓库通常都以 .git 结尾。 $ sudo chown -R git:git learngit.git
Git服务器就已经搭得差不多了。下面我们在客户端clone一下远程仓库$ git clone git@192.168.199.206:/data/git/learngit.git Cloning into 'learngit'...The authenticity of host '192.168.8.34 (192.168.8.34)' can't be established.RSA key fingerprint is 2b:55:45:e7:4c:29:cc:05:33:78:03:bd:a8:cd:08:9d.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '192.168.8.34' (RSA) to the list of known hosts.git@192.168.8.34's password: 能连接但要密码，接着下一步。
第四步，创建证书登录（Git服务器打开RSA认证）： 然后就可以去Git服务器上添加你的公钥用来验证你的信息了。 vim /etc/ssh/sshd_config 中将RSA认证打开，即： RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys 这里我们可以看到公钥存放在 .ssh/authorized_keys 文件中。所以我们在 /home/git 下创建 .ssh 目录，然后创建 authorized_keys 文件，收集所有需要登录的用户的公钥，就是他们自己的 id_rsa.pub 文件，把所有公钥导入到 /home/git/.ssh/authorized_keys 文件里，一行一个。 此时$ git clone git@192.168.199.206:/data/git/learngit.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@192.168.199.206:/data/git/learngit.git Cloning into 'sample'...warning: You appear to have cloned an empty repository. 剩下的推送就简单了。 管理公钥 如果团队很小，把每个人的公钥收集起来放到服务器的 /home/git/.ssh/authorized_keys 文件里就是可行的。如果团队有几百号人，就没法这么玩了，这时，可以用 Gitosis 来管理公钥。 这里我们不介绍怎么玩 Gitosis 了，几百号人的团队基本都在500强了，相信找个高水平的Linux管理员问题不大。管理公钥也可用 Gitolite 管理权限 有很多不但视源代码如生命，而且视员工为窃贼的公司，会在版本控制系统里设置一套完善的权限控制，每个人是否有读写权限会精确到每个分支甚至每个目录下。因为Git是为Linux源代码托管而开发的，所以Git也继承了开源社区的精神，不支持权限控制。不过，因为Git支持钩子（hook），所以，可以在服务器端编写一系列脚本来控制提交等操作，达到权限控制的目的。 Gitolite 就是这个工具。 这里我们也不介绍 Gitolite 了，不要把有限的生命浪费到权限斗争中。
搭建服务器的同时采用Gitolite来管理权限，参考： https://my.oschina/u/2351685/blog/509322 Gitolite的使用，参考： http://www.uml/pzgl/201404092.asp
#################################################################################
完结！
外国友人git手册 https://pan.baidu/s/1kU5OCOB#path=%252Fpub%252Fgit
10 个迅速提升你 Git 水平的提示 http://www.oschina/translate/10-tips-git-next-level





个人学习笔记，不当之处还请指正。
----------不定期更新------------

本文标签： 常用命令教程Git