Git常用指令整理及说明(详细)

本地库和远程库

新建仓库

建立远程库(为空，不要加README.md，不然后面会push不上去)
本地新建文件夹
git init初始化仓库，可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的。勿人为瞎改
远程库的名字就是origin，这是Git默认的叫法
git remote add origin git@github.com:michaelliao/learngit.git 这个命令是在本地的learngit仓库下执行的。这两个地方的仓库名不需要相同，因为会通过在本地的仓库目录下执行这条命令（命令中包含远程库的名字）已经将两者建立了联系
git push -u origin master 把本地库的所有内容推送到远程库上。把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送master分支时，加上了-u参数(推送和关联)，Git不但会把本地的master分支内容推送到远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
git push origin master每次本地提交后,推送最新修改到远程库
从远程库克隆

假设github上面已经有一个远程库，但是本地没有，需要克隆到本地，远程库的名字叫gitskills

git clone git@github.com:michaelliao/gitskills.git 克隆一个本地库,则在当前文件夹下会多一个gitskills的文件夹。
cd gitskills进入克隆下来的本地库，默认的名字是和github上的一样的
git push origin master 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上

常用查看指令

git status 查看仓库当前的状态
git diff 文件名查看对文件做什么修改
git diff 版本号1 版本号2 –stat查看两个版本的差异的文件列表，包括被修改行数和增删图。参数改为–name-status前面显示修改说明字母(A,M等)，无行数
git log显示从最近到最远的提交日志
git log –pretty=oneline 简化日志输出的显示信息，commit id很长,详细显示见这里
git reflog 记录你的每一次命令，最先显示的是这个命令执行之后的版本的版本号的前七位，这样就算你清屏了或者重启了，也能找到某个版本的版本号，就可以轻松回退到那个版本
git branch 查看当前所在的分支。git branch命令会列出所有分支，当前分支前面会标一个*号
git log –graph –pretty=oneline –abbrev-commit用带参数的git log可以看到分支的合并情况。用git log –graph命令可以看到分支合并图
git remote 查看远程库的信息
git remote -v 显示更为详细的信息

常用修改指令

git add readme.txt添加，但是不提交
git commit -m “提交描述”提交，只有add后提交才有效。“改文件->add文件->再改->提交”，则第二次修改无效,不会被提交，只会成功提交第一次的修改。
撤销修改和版本回退

git checkout – 文件名把没暂存(即没add)的干掉，或者说，丢弃工作区，回到到暂存状态
git reset HEAD 文件名把暂存的状态取消，工作区内容不变，但状态变为“未暂存”。
简单来说，没有add过的修改，只需要git checkout – 文件名即可撤销；add 过的修改，先git reset HEAD 文件名变成没add 过的修改，再git checkout – 文件名撤销。操作示例可以看这张图

git reset –hard HEAD^ 会回退到上一个版本
git reset –hard 某版本号前几位通过命令行上的历史信息（假如你没清屏的话），找到某版本 的版本号回到指定版本。不一定要全部的版本号，就像这个命令的例子，只要前面的约7、8位这样就可以。
分支管理

创建和合并分支

git checkout -b dev创建一个新的分支：dev，并且会切换到dev分支。所以这条命令有两个作用。git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：git branch dev和git checkout dev
git branch dev，新建分支是新建指针,指向当前commit
git checkout dev切换到dev分支
git checkout masterdev分支的工作完成，我们就可以切换回master分支(此时在dev分支的修改在master上是看不到的)
git merge dev 这是在master分支上执行的命令，作用是：把dev分支上的工作成果合并到master分支上
git branch -d dev 删除已合并的分支。删除分支就是删除指针
git branch -D devGit友情提醒，dev分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用git branch -D dev命令
git rebase master变基。在当前分支(非master)下执行该命令，则相当于把当前分支和mater分支合并，和merge操作类似，但提交历史不同，rebase操作的log更干净。具体可参考Git 分支 - 变基
解决冲突

假设在master分支和feature1分支对同一文件做了修改

git merge feature1 在master分支上执行该命令，与feature1分支合并。这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息

git merge –no-ff -m “merge with with no-ff” dev准备合并dev分支，注意–no-ff参数表示禁用Fast forward，因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去
bug分支

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作

git stash保存工作现场
git stash list 查看工作现场
git stash apply 恢复工作现场，但是恢复后，stash内容并不删除，有多个工作现场时可以git stash apply stash@{0}恢复特定的现场
git stash drop删除stash的内容
git stash pop恢复的同时也把stas内容删除了
远程分支

这部分只介绍常用的几个操作
git fetch origin 这个命令查找 “origin” 是哪一个服务器，从中抓取本地没有的数据，并且更新本地数据库，移动 origin/master指针指向新的、更新后的位置
git push (remote) (branch)推送本地的分支来更新远程仓库上的 同名分支。如前文提到的git push origin master就是将本地master分支推送到远程master分支；复杂一点的，git push origin serverfix:awesomebranch将本地的 serverfix分支推送到远程仓库上的awesomebranch分支
git push origin –delete serverfix或者git push origin :remotebranch,删除远程的serverfix分支
git pull在大多数情况下它的含义是一个git fetch紧接着一个git merge命令。具体可参考Git远程操作详解和Documentation git-pull

查看git版本
[plain] view plain copy
$ git –version
git version 1.7.11.msysgit.1

查看git所有配置项
[plain] view plain copy
$ git config -l
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
…

查看git某个配置
[plain] view plain copy
$ git config gui.encoding
utf-8

查看git远程库地址
[plain] view plain copy
$ git remote -v
origin http://xhl@github.com/web/crm2.git (fetch)
origin http://xhl@github.com/web/crm2.git (push)

查看remote地址，远程分支，还有本地分支与之相对应关系等一系列信息
[plain] view plain copy
$ git remote show origin
* remote origin
Fetch URL: https://github.com/appMobi/jQ.Mobi.git
Push URL: https://github.com/appMobi/jQ.Mobi.git
HEAD branch: master
Remote branches:
1.1 new (next fetch will store in remotes/origin)
1.2 tracked
beta tracked
master tracked
Local branch configured for ‘git pull’:
master merges with remote master
Local ref configured for ‘git push’:
master pushes to master (local out of date)

git reset
git reset –hard commit:
1.替换引用的指向.引用指向新的提交ID;
2.替换暂存区.替换后,暂存区的内容和引用指向的目录树一致;
3.替换工作区.替换后,工作区的内容变得和暂存区一致,也和HEAD所指向的目录树内容相同.

git reset –soft commit:
1.替换引用的指向.引用指向新的提交ID.
即只更改引用的指向,不该编暂存区和工作区.

git reset –mixed commit或git reset commit:
1.替换引用的指向.引用指向新的提交ID;
2.替换暂存区.替换后,暂存区的内容和引用指向的目录树一致;
即更改引用的指向及重置暂存区,但是工作区不变.

实例:
git reset
仅用HEAD指向的目录树重置暂存区,工作区不受影响,相当于将之前用git add命令更新到暂存区的内容撤出暂存区.引用也未改变,因为引用重置到HEAD相当于没有重置.

git reset HEAD
同上

git reset – filename
仅将文件filename的改动撤出暂存区,暂存区中其他文件不该变.相当于git add filename的反向操作.

git reset HEAD filename
同上

git reset –soft HEAD^
工作区和暂存区不改变,但是引用向前回退一次.当对最新提交的提交说明或提交不满意更改时,撤销最新的提交一遍重新提交.

git reset HEAD^
工作区不变,但是暂存区会回退到上一次提交之前,引用也会回退一次.

git reset –mixed HEAD^
同上

git reset –hard HEAD^
彻底撤销最近的提交.引用回退到前一次,而且工作区和暂存区都会回退到上一次提交的状态.自上一次以来的提交全部丢失.

git format-patch 打补丁的用法

使用git format-patch生成所需要的patch:
当前分支所有超前master的提交：
git format-patch -M master
某次提交以后的所有patch:
git format-patch 4e16 –4e16指的是commit名
从根到指定提交的所有patch:
git format-patch –root 4e16
某两次提交之间的所有patch:
git format-patch 365a..4e16 –365a和4e16分别对应两次提交的名称
某次提交（含）之前的几次提交：
git format-patch –n 07fe –n指patch数，07fe对应提交的名称
故，单次提交即为：
git format-patch -1 07fe
git format-patch生成的补丁文件默认从1开始顺序编号，并使用对应提交信息中的第一行作为文件名。如果使用了– numbered-files选项，则文件名只有编号，不包含提交信息；如果指定了–stdout选项，可指定输出位置，如当所有patch输出到一个文件；可指定-o

指定patch的存放目录；

补丁检测：./scripts/checkpatch.pl xxx.patch
这个时候补丁就制作成了，但是还要使用内核提供的补丁检测工具检测一下补丁的正确性，应为我们发布的补丁不能把很明显错误带进去。

使用checkpatch.pl输出的主要错误或警告：scripts/checkpatch.pl输出的错误或警告有很多种，其中有一些比较具有代表性的，如下所示。在编写的阶段就应当充分注意它们。
错误
换行符为DOS格式（CR+LF）。
行首、行尾有多余的空格。
不是用制表符，而是用空格缩进。
switch语句和case语句的缩进不一致。
函数定义块(block)以外的“{”写在独立的行中。
注释符使用的是“//”。
全局变量或静态变量是明确指定以0初始化的。
前括号“(”或“[”后面有多余的空格。
后括号“)”或“]”前面有多余的空格。
逗号“,”后面没有空格。
if、for、while的前括号“(”前面没有空格。
else未与if块结尾的“}”写在同一行。
使用了将来要废弃的头文件或函数。
补丁内没有Signed-off-by行。

警告

补丁内含有的路径起点不是内核源码树的根目录。
1行的长度超过80字。
制表符前面有空格。
const关键词的使用方法有问题。
printk()没有指定输出级别（KERN_*）。
goto的分支终点的标签label缩进。
用“{}”括住了只有1行的代码块。
使用了volatile修饰符。
kmalloc()的返回值已经转换。

在git使用当中，会有很多时候别人（供应商或者其他的开发人员）发过来一系列的patch

这样来打patch，但是这样会把这些有用的信息丢失。由于这些patch显然是用git format-patch来生成的，所以用git的工具应该就可以很好的做好。git-am 就是作这件事情。

在使用git-am之前， 你要首先git am –abort 一次，来放弃掉以前的am信息，这样才可以进行一次全新的am。git-am 可以一次合并一个文件，或者一个目录下所有的patch，或者你的邮箱目录下的patch.

下面举两个例子：

你现在有一个code base： small-src, 你的patch文件放在~/patch/0001-trival-patch.patch

cd small-src
git-am ~/patch/0001-trival-patch.patch
如果成功patch上去， 你就可以去喝杯茶了。如果失败了， git 会提示错误，

比如：
error: patch failed: android/mediascanner.cpp:452 error: android/mediascanner.cpp: patch does not apply
这样你就需要先看看patch， 然后改改错误的这个文件，让这个patch能够patch上去。

你有一堆patch， 名字是上面提到的那一堆patch， 你把他们放在~/patch-set/目录下（路径随意）

cd opencore
git am ~/patch-set/*.patch
(这里git就会按照文件名的顺序一次am这些patch）如果一切顺利， 你所有的patch都OK了， 你又Lucky了。不过不顺利的时候十有八九，如果git am中间遇到了patch,am就会停到打这个patch的地方， 告诉你是哪个patch打不上去。