小猪的Git使用总结
文件夹
概述：
接触Git也些年头了，对于Git的使用也算是略有心得，想着
出于自己日后回想，也便于他人查阅学习的目的。遂有此文，
相信看完此文你的Git使用会更进一步，谢谢~
PS：有些童鞋曾私信问我为什么有图形化的Git工具还要学
命令行。原因挺多的，我认为最基本的原因有三点：
- 1.降低跨平台使用Git成本，不用另外花时间去熟悉各种工具。
- 2.知道原理，出问题的时候不会一脸懵逼；
- 3.装逼，敲起来命令噼里啪啦，不知道还以为你真的是大神；
在线版（排版更佳，优先更新）：https://www.zybuluo.com/coder-pig/note/581320
本文不收取不论什么费用，欢迎转载，但请注明原文出处。
禁止将本文用于商业用途。想了解很多其它内容可见：
http://blog.csdn.net/coder_pig
假设本文对你学习Git有一定帮助，最好还是小额打赏下小猪，
你的鼓舞是我不断写博客的动力， 万分感谢~
微信：
支付宝：
如有什么疑问欢迎加群：421858269 反馈，谢谢~
安装配置与文档
1.下载安装
- Windows系统：到 Git For Windows 或 git-for-windows.github.io下载，傻瓜式下一步。
- Linux系统：到 Download for Linux and Unix 下载。假设是Ubuntu的话，直接Terminal键入：
sudo apt-get install git 安装。 - Mac系统：到 Installing on Mac 下载，只是新系统貌似默认已经带有Git了，另外假设安装了
Homebrew的话能够直接命令行键入：brew install git 进行安装。
2.文档教程相关
- Pro Git(官方)：https://git-scm.com/book/zh/v2
- Pro Git中文版(oschina)：http://git.oschina.net/progit/index.html
- 廖雪峰的Git教程：
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000 - 猴子都看得懂的Git入门：http://www.backlogtool.com/git-guide/cn/
- Git Community Book 中文版：http://gitbook.liuhui998.com/index.html
- 沉浸式学Git：http://igit.linuxtoy.org/contents.html
- .gitignore 文件模板：https://github.com/github/gitignore
- git log –pretty 输出格式定制：https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History
- Git Cheat Sheet: Useful Commands, Tips and Tricks：
https://sentheon.com/blog/git-cheat-sheet.html
概念
1.Git的四个组成部分
2.文件的几个状态
按大类划分。分为两种状态：Tracked(已跟踪)和Untracked(未跟踪)，
依据是：该文件是否已加入版本号控制？
流程简述：
假设某个项目已加入版本号控制系统
- 1.新建一个文件，该文件处于 Untracked 状态；
- 2.通过git add命令加入到缓存区。此时文件处于Tracked状态又或者说
此时这个文件已经被版本号控制系统所跟踪，并且他处于Staged(暂存)状态；- 3.通过git commit命令把暂存区的文件提交提交到本地仓库，此时文件
处于Unmodified(未改动)状态；- 4.此时假设去编辑这个文件，文件又会变成Modified(改动)状态。
3.Git与SVN版本号版本号控制存储差异
Git关心的是：文件总体是否发生变化，而SVN关心的是：文件内容的详细差异。
SVN每次提交记录的是：哪些文件进行了改动。以及改动了哪些行的哪些内容
如图：版本号2中记录的是文件A和C的变化，而版本号3中记录文件C的变化。以此类推；
而Git中。并不保存这些前后变化的差异数据。而是保证整个缓存区中的全部文件，
又叫快照。有变化的文件保存，没变化的文件不保存，而是对上一次的保存的快照
做一个链接！由于这种不同的保存方式，Git切换分支的速度比SVN快非常多！
4.每次Commit时仓库中的数据结构
分为四个对象：
blob对象：存放文件数据。
tree对象：文件夹。内容为blob对象的指针或其它tree对象的指针
commit对象：快照。包含指向前一次提交对象的指针，commit相关的信
通过索引找到文件快照。
tag对象：一种特殊的commit对象，一般对某次重要的commit加TAG，以示重要(方便找)
本地操作命令
1.相关配置【git config】
区分global 和 local。前者代表 全局设置，就是设置了在整个系统中，
全部的带Git版本号管理的项目都是这种配置。后者代表 本地设置
即在某个项目中独立的设置，后者优先级高于前者。
比方全局设置
的username是”Coder-pig”，本地设置的是”Jay”，commit的时候author
就是Jay而不是Coder-pig。
除了通过命令行改动，还能够直接改动
相应文件：
全局配置文件：etc/gitconfig (Mac下是隐藏文件，用户/.gitconfig)
本地配置文件：当前仓库/.git/config
# 安装完Git后第一件要做的事，设置用户信息(global可换成local在单独项目生效)：
git config --global user.name "username" # 设置username
git config --global user.email "用户邮箱" #设置邮箱
git config --global user.name # 查看username是否配置成功
git config --global user.email # 查看邮箱是否配置
# 其它查看配置相关
git config --global --list # 查看全局设置相关參数列表
git config --local --list # 查看本地设置相关參数列表
git config --system --list # 查看系统配置參数列表
git config --list # 查看全部Git的配置(全局+本地+系统)
2.获取帮助【git help】
git help 命令 # 如：git help init3.创建本地仓库【git init】
git init 仓库名 # 创建一个新的带Git仓库的项目
git init # 为已存在的项目生成一个Git仓库4.加入文件到暂存区/文件跟踪标记【git add】
能够使用git add 文件名称，将工作空间的文件加入到暂存区，或批量加入文件
git add 文件名称 # 将工作区的某个文件加入到暂存区
git add -u # 加入全部被tracked文件里被改动或删除的文件信息到暂存区，不处理untracked的文件
git add -A # 加入全部被tracked文件里被改动或删除的文件信息到暂存区。包含untracked的文件
git add . # 将当前工作区的全部文件都加入暂存区
git add -i # 进入交互界面模式。按需加入文件到缓存区附：交互界面模式演示样例
上图流程：
1.先在GitForTest的文件夹里创建了两个文件
2.键入git add -i。进入后，键入4。选择加入untracked的文件
3.他给我们列出了untracked的文件，然后我们依据序号来加入文件
4.输入?会弹出相关提示，然后直接回车，结束选择！
5.然后再次输入git add -i，输入4，能够看到已不存在untacked的文件了！
5.让Git不Tracked特定文件【.gitignore文件配置】
将未tracked的文件加入到缓存区后，Git就会開始跟踪这个文件了！
对于一些比方：自己主动生成的文件，日志，暂时编译文件等。就
不是必需进行跟踪了，这个时候能够编写.gitignore文件，在里面
把不须要跟踪的文件或文件夹都写上。git就不会对这些文件进行跟踪！
另外.gitignore文件与.git文件夹在同级文件夹下！
假设不想自己写，能够直接到：https://github.com/github/gitignore 复制粘贴！
也能够自行编写。支持简化了的正則表達式(规范与演示样例模板摘自：Git王者超神之路)
- * ： 匹配零个或多个随意字符
- [abc]：仅仅匹配括号内中的随意一个字符
- [0-9]：- 代表范围，匹配0-9之间的不论什么字符
- ?：匹配随意一个字符
- *：匹配随意的中间文件夹。比如a/*/z能够匹配:a/z,a/b/z,a/b/c/z等
演示样例模板：
# 忽略全部以 .c结尾的文件
*.c
# 可是 stream.c 会被git追踪
!stream.c
# 仅仅忽略当前文件夹下的TODO文件, 不包含其它文件夹下的TODO比如: subdir/TODO
/TODO
# 忽略全部在build文件夹下的文件
build/
# 忽略 doc/notes.txt, 但不包含多层下.txt比如: doc/server/arch.txt
doc/*.txt
# 忽略全部在doc文件夹下的.pdf文件
doc/**/*.pdf。。。特别要注意一点！！
！：
配置.gitignore仅仅对那些没有加入到版本号控制系统的文件生效(未Tracked的文件)！
举个样例：
有A，B两个文件，你先把他两个add了，然后在.gitignore文件里
配置了不跟踪这两个文件，可是你会发现根本不会生效。
git add A
git add B
# 配置不跟踪A和B
git add .gitignore所以。最好的做法就是在项目刚開始的时候，先加入.gitignore文件。
当然，即使是发生了，还是有解决方法的，能够键入下述命令清除标
记状态，然后先加入.gitignore。再加入文件就可以：
git rm -r --cached . # 清除版本号控制标记，.代表全部文件，也可指定详细文件还有，假设你用的是IDEA的编辑器的话。能够下一个.ignore的插件。能够手动
直接勾选不须要跟踪的文件。
6.将暂存区内容提交到本地仓库【git commit】
git commit -m "提交说明" # 将暂存区内容提交到本地仓库
git commit -a -m "提交说明" # 跳过缓存区操作，直接把工作区内容提交到本地仓库假设不加-m “提交说明”，git会让用你让默认编辑器(如vi)来编写提交说明，
可能有些朋友用不惯vi，要么别漏掉-m “提交说明”，要么自己设置编译器：
git config --global core.edit 喜欢的编辑器除此之外，有时可能须要改动上次提交的内容，比方改动提交说明，或者改动文件等：
# 合并暂存区和近期的一次commit，生成新的commit并替换掉老的
# 假设缓存区没内容。利用amend能够改动上次commit的提交说明
# 注：由于amend后生成的commit是一个全新的commit，旧的会被
# 删除，所以别在公共的commit上使用amend！切记！
！。
git commit --amend
git commit --amend --no-edit # 沿用上次commit的提交说明
7.查看工作区与缓存区的状态【git status】
git status # 查看工作区与暂存区的当前情况
git status -s # 让结果以更简短的形式输出8.差异对照(内容变化)【git diff】
git diff # 工作区与缓存区的差异
git diff 分支名 #工作区与某分支的差异。远程分支这样写：remotes/origin/分支名
git diff HEAD # 工作区与HEAD指针指向的内容差异
git diff 提交id 文件路径 # 工作区某文件当前版本号与历史版本号的差异
git diff --stage # 工作区文件与上次提交的差异(1.6 版本号前用 --cached)
git diff 版本号TAG # 查看从某个版本号后都改动内容
git diff 分支A 分支B # 比較从分支A和分支B的差异(也支持比較两个TAG)
git diff 分支A...分支B # 比較两分支在分开后各自的改动
# 另外：假设仅仅想统计哪些文件被改动，多少行被改动。能够加入 --stat 參数9.查看历史提交记录【git log】
git log # 查看全部commit记录(SHA-A校验和，作者名称，邮箱，提交时间。提交说明)
git log -p -次数 # 查看近期多少次的提交记录
git log --stat # 简略显示每次提交的内容更改
git log --name-only # 仅显示已改动的文件清单
git log --name-status # 显示新增，改动。删除的文件清单
git log --oneline # 让提交记录以精简的一行输出
git log –graph –all --online # 图形展示分支的合并历史
git log --author=作者 # 查询作者的提交记录(和grep同一时候使用要加一个--all--match參数)
git log --grep=过滤信息 # 列出提交信息中包含过滤信息的提交记录
git log -S查询内容 # 和--grep相似，S和查询内容间没有空格
git log fileName # 查看某文件的改动记录。找背锅专用除此之外，还能够通过 –pretty 对提交信息进行定制，比方：
很多其它规则与定制例如以下(摘自：Git王者超神之路)，或參见：Viewing the Commit History ：
format相应的经常使用占位符：(注：作者是指最后一次改动文件的人。提交者是提交该文件的人)
| 占位符 | 说明 | 占位符 | 说明 |
|---|---|---|---|
| %H | 提交对象（commit）的完整哈希字串 | %h | 提交对象的简短哈希字串 |
| %T | 树对象（tree）的完整哈希字串 | %t | 树对象的简短哈希字串 |
| %P | 父对象（parent）的完整哈希字串 | %p | 父对象的简短哈希字串 |
| %an | 作者（author）的名字 | %ae | 作者的电子邮件地址 |
| %ad | 作者修订日期（能够用 –date= 选项定制格式） | %ar | 按多久曾经的方式显示 |
| %cn | 提交者(committer)的名字 | %ce | 提交者的电子邮件地址 |
| %cd | 提交日期 | %cr | 提交日期，按多久曾经的方式显示 |
| %s | 提交说明 |
一些其它操作：
| 选项 | 说明 |
|---|---|
| -p | 按补丁格式显示每一个更新之间的差异 |
| –stat | 显示每次更新的文件改动统计信息(行数) |
| –shortstat | 仅仅显示 –stat 中最后的行数改动加入移除统计 |
| –name-only | 仅在提交信息后显示已改动的文件清单 |
| –name-status | 显示新增、改动、删除的文件清单 |
| –abbrev-commit | 仅显示 SHA-1 的前几个字符，而非全部的 40 个字符 |
| –relative-date | 使用较短的相对时间显示（比方，“2 weeks ago”） |
| –graph | 显示 ASCII 图形表示的分支合并历史 |
| –pretty | 格式定制。可选选项有：oneline。short，full，Fullerton和format(后跟指定格式) |
还有一些限制log输出的选项
| 选项 | 说明 |
|---|---|
| -(n) | 仅显示近期的 n 条提交 |
| –since, –after | 仅显示指定时间之后的提交。 |
| –until, –before | 仅显示指定时间之前的提交。 |
| –author | 仅显示指定作者相关的提交。 |
| –committer | 仅显示指定提交者相关的提交。 |
| –grep | 仅显示含指定关键字的提交 |
| -S | 仅显示加入或移除了某个关键字的提交 |
10.查看某行代码是谁写的【git blame】
git blame 文件名称 # 查看某文件的每一行代码的作者，最新commit和提交时间
Tip：
假设你用的IDEA系列的编译器，右键行号，选择Annotate也能够实现相同的效果
11.设置Git命令别名【git config –global alias】
能够为常见的命令起个简单的别名。就不用每次都敲完整命令。比方能够设置：
status为st。checkout为co ; commit为ci ; branch为br等
git config --global alias.st status
12.为重要的commit打标签【git tag】
对于某些提交，我们能够为它打上Tag，表示这次提交非常重要。
比方为一些正式公布大版本号的commit，打上TAG，当某个版本号
出问题了，通过TAG能够高速找到此次提交。拿到SHA1值，再
去查找问题，比起一个个commit看，省事非常多。
Git标签分两种：轻量标签 和 附加标签
前者仅仅是在提交上加个Tag，指向提交的Hash值。
而后者还会保存打标签者的信息。时间和附加信息；
git tag 标记内容 # 轻量标签
git tag -a 标记内容 -m "附加信息" # 附加标签假设想为之前的某次commit打TAG的话，能够先找出SHA1值。设置调下述命令：
git tag -a 标记内容 版本号id # 比方：git tag -a v1.1 bcfed96默认情况，git push不会把标签推送TAG到远程仓库，假设想推送到server，能够：
git push origin 标记内容 # 推送某标签到
# 删除全部本地仓库中不存在的TAG：
git push origin --tags 另外，能够在新建分支的时候也加上TAG
git checkout -b 分支名 标记内容还能够用show命令查看标签相应的信息
git show 标记内容假设你想删除本地Tag：
git tag -d 标记内容假设是删除远程Tag：
git push origin --delete tag 标记内容13.Git命令自己主动补全【输命令的时候按两次tab键】
文件回复/版本号回退
1.文件恢复(未commit)【git checkout】
假设在工作区直接删除被Git Tracked的文件，暂存区中还会存在该文件，
此时键入：git status，会是这样：
Git告诉你工作区的文件被删除了，你能够 删掉暂存区里的文件或 恢复被删文件
# 删除暂存区中的文件：
git rm 文件名称
git commit -m "提交说明"
# 误删恢复文件
git checkout -- 文件名称
# 另外注意：git checkout会抛弃当前工作区的更改!!!不可恢复！！！务必小心！
！。
2.文件恢复(已add未commit)【git reset HEAD】
假设更改后add到了暂存区，想恢复原状，下述指令能够让文件恢复原状：
git reset HEAD 文件名称
git checkout 文件名称3.版本号回退(已commit)【git reset –hard】
文件已经commit了，想恢复成上次commit的版本号或者上上次。能够：
git reset HEAD^ # 恢复成上次提交的版本号
git reset HEAD^^ # 恢复成上上次提交的版本号，就是多个^，以此类推或用~次数
git reset --hard 版本号号 # git log查看到的SHA1值，取前七位就可以。依据版本号号回退reset命令事实上就是：重置HEAD指针。让其指向还有一个commit
而这个动作可能会对工作区与缓存区造成影响，举个样例
- 本来的分支线：- A - B - C (HEAD, master)
- git reset B后：- A - B (HEAD, master)
解释：看不到C了。可是他还是存在的。能够通过git reset C版本号号找回，前提是
C没有被Git当做垃圾处理掉(通常是30天)。
reset三个可选參数解析：
- –soft：仅仅是改变HEAD指针指向，缓存区和工作区不变；
- –mixed：改动HEAD指针指向，暂存区内容丢失。工作区不变。
- –hard：改动HEAD指针指向，暂存区内容丢失，工作区恢复曾经状态；
4.查看输入指令记录【git reflog】
Git会记住你输入的每一个Git指令。比方上面的git reset 切换成一个旧的
commit，然后git log后发现新提交的记录没了。想切换回新的那次commit，
能够先调git reflog 获取新commit的SHA1码，然后git reset 回去。
git reflog
注意：这个指令记录不会永久保存！
Git会定时清理用不到的对象！
。！
5.撤销某次提交【git revert】
有时可能我们想撤销某次提交所做的更改，能够使用revert命令
git revert HEAD # 撤销近期的一个提交
git revert 版本号号 # 撤销某次commit不是真的把提交给撤销了，而是生成一个新的提交来覆盖旧的提交，被撤销的提交
和新的提交记录都会保存！
！
。不信你再调一次revert HEAD 会发现被撤销的更改
又变回来了，另外，每次revert后。都须要发起新的commit！
简单点说，撤销的仅仅是文件变化，提交记录依然是存在的！
6.查看某次提交改动内容【git show】
git show 提交id # 查看某次commit的改动内容7.查看某个分支的版本号号【git rev-parse】
git rev-parse 分支名 # 查看分支commit的版本号号，能够写HEAD8.找回丢失对象的最后一点希望【git fsck】
由于你的某次误操作导致commit丢失。假设git reflog都找不到。你
能够考虑使用git fsck，找到丢失的对象的版本号id，然后恢复就可以。
git fsck --lost-found
本地分支
1.分支概念
提交记录串成的时间线。默认初始创建的分支(时间线) —— master分支。
假设不切换到其它分支上，每次commit生成的快照都会串在这条分支上！
另外还有个 —— HEAD指针，该指针指向正在工作的本地分支，前面的版
本回退事实上改动的就是这个HEAD指针的指向。
比方：在master分支上运行四次commit，分支的状态图例如以下
不难发现这种规律：
- 每次commit，master都会向前移动一步，指向最新的提交
- HEAD则指向正在工作的本地分支，而git reset改动的就是HEAD指针的指向！
2.创建其它分支的原因
通过两个场景来体会创建其它分支的必要性
- 场景一：
项目一般都是一步步迭代升级的，有大版本号和小版本号的更新：
大版本号通常是改头换面的更新。比方UI大改，架构大改，版本号是：
v2.0.0这样；小版本号的更新通常是UI小改。Bug修复优化等。版本号是：
v2.0.11这样。仅仅有一条master分支，意味着：你的分支线会
非常非常的长，假如你已经公布到了第二个大版本号，然后用户反馈
第一个版本号有非常严重的BUG。这时候想切回第一个版本号改BUG。
然后改完BUG切回第二个大版本号，想想也是够呛的。
(PS：可能你说我能够对重要的commit打tag，然后找到这个tag
切回去，当然也行这里是想告诉你引入其它分支会给你带来的便利)- 场景二：
仅仅有一个master分支的话。假如某次提交冲突了。而这个冲突非常难解决或者
解决不了， 那么，那个整个开发就卡住在这里了，无法继续向后进行了！
3.一个最简单有用的分支管理策略
为了解决仅仅有一个master分支引起的问题。能够引入分支管理，最简单的一种策略例如以下：
在master分支上开辟一个新的develop分支，然后我们依据功能或者业务，再在develop
分支上另外开辟其它分支。完毕分支上的任务后，再将这个分支合并到develop分支上！
然后这个功能分支的任务也到此结束。能够删掉，而当公布正式版后。再把develop分支
合并到master分支上。并打上TAG。
master与develop分支都作为长期分支。而其它创建的分支作为暂时性分支。
简述各个分支的划分：
- master分支：可直接用于产品公布的代码，就是正式版的代码
- develop分支：日常开发用的分支，团队中的人都在这个分支上进行开发
- 暂时性分支：依据特定目的开辟的分支，包含功能(feature)分支，或者预公布(release)分支。
又或者是修复bug （fixbug）分支，当完毕目的后。把该分支合并到develop分支。
然后删除 该分支，使得仓库中的经常使用分支始终仅仅有：master和develop两个长期分支！
4.分支创建与切换【git branch】
git branch 分支名 # 创建分支
git branch # 查看本地分支比方在master分支上创建develop分支。此时的分支状况例如以下：
git checkout 分支名 # 切换分支
git checkout -b 分支名 # 创建分支同一时候切换到这个分支切换到develop分支后。改点东西，再commit，此时的分支状况例如以下：
git checkout master 切回master分支，打开之前改动的文件，发现内容
并没有发生更改，由于刚刚的更改是在develop上提交的，而master上没有
变化，此时的分支状况例如以下：
5.分支的合并【git merge】 VS 【git rebase】
Git中，能够使用 git merge 和 git rebase 两个命令来进行分支的合并
git merge合并分支
合并的方式分为两种：高速合并 和 普通合并，两者的差别在于：
前者合并后看不出曾经做过合并，而后合并后的历史会有分支记录，如图：
高速合并：
普通合并 ：
演示样例：
高速合并，把develop分支合并到master分支上，来到master分支后，键入下述命令
git merge develop
打开文件：
普通合并。切到develop分支下，改动note_2.txt的内容，再通过下述指令合并分支：
注：–no-ff參数表示禁用高速合并！
git merge --no-ff -m "合并的信息(TAG)" develop
分支线情况：
git reabse合并分支
rebase(衍合或变基)。发现非常多所谓的教程把这个东西写得太深奥了，
事实上并没有那么复杂，仅仅是这种合并会使得树整洁，易于跟踪，
举个简单的样例来对照下，有一个项目由两个人同一时候开发，
当前远程仓库的提交记录是这种：
然后A和B各自开了一个条分支来完毕相应功能，接着他们在自己的
分支上都做了多次的commit。此时两人的分别分支线是这种：
A先合并，再到B合并。这里我们假设两人做的是全然不关联的模块。合并没有冲突
merge合并
rebase合并
使用方法：
git rebase 想合并到哪个分支的分支名6.解决合并冲突
在我们合并分支的时候，有时会遇到合并冲突，然后合并失败的问题。
此时须要我们先解决冲突后才干进行合并，个人开发倒非常少会遇到。多人
开发的时候遇到合并冲突则是家常便饭。
一个最简单的样例。A和B在develop分支上开辟出两个分支来完毕相关的
功能，A做完了，把自己的分支合并到develop分支，此时develop分支向前
移动了几次commit，接着B也完毕了他的功能，想把自己分支合并到develop
分支，假设改动的文件和和A改动的文件相同的话，此时就会合并失败，
然后须要处理完冲突。才干够继续合并。简单模拟下这个样例。先试试merge！
merge分支后处理冲突
打开冲突文件，然后处理冲突部分，保留什么代码你自己决定，处理完后把
<<< 和 >>> 这些去掉：
处理后：
然后add，然后commit就可以。合并结束：
此时的分支线：
接着试试
rebase分支后处理冲突
又一次来一遍。然后把A直接merge到master，再切到B，rebase master，此时出现
合并冲突，这里有三个可选的操作：
git rebase --continue # 处理完冲突后。继续处理下一个补丁
git rebase --abort # 放弃全部的冲突处理。恢复rebase前的情况
git rebase --skip # 跳过当前的补丁，处理下一个补丁，不建议使用，补丁部分的commit会丢失！
好的，有三次补丁要处理。一个个来：
处理后：
接着git add 加入改动后的文件。git rebase –continue继续处理补丁：
接着反复之前的过程：
处理后：
第三个补丁是与A分支无关联的改动，所以没有冲突。所以也就直接合并了！
假设合并中途出了什么差错能够git rebase –abort 恢复rebase前的状况！
最后看下分支线会发现是一条直线，这也是用rebase合并分支的优点：
附上栗子，能够自己试试：GitTest.7z
7.删除分支
对于合并完的分支。基本都没什么作用了。能够使用下述命令删除：
git branch -d 分支名 # 删除分支。分支上有未提交更改是不能删除的
git branch -D 分支名 # 强行删除分支。虽然这个分支上有未提交的更改8.恢复误删分支
两步。找出被删除分支的最新commit的版本号号，然后恢复分支
git log --branches="被删除的分支名" # 找到被删分支最新的commitb版本号号
git branch 分支名 版本号号(前七位就可以) # 恢复被删分支9.切换分支时保存未commit的更改【git stash】
有时我们可能在某个分支上正编写着代码，然后有一些突发的情况。须要
我们暂时切换到其它分支上。比方要紧急修复bug，或者切换分支给同事
review代码。此时假设直接切换分支是会提示切换失败的，由于这个分支
上做的更改还没有提交。你能够直接add后commit，然后再切换，只是我们
习惯写完某个功能再提交，我们想：
先暂存这个分支上的改动，切去其它分支上搞完事，然后回来继续
继续在之前的改动上写代码。
那么能够使用：
git stash # 保存当前的改动然后放心的切换分支，然后再切换回来，接着使用：
git stash apply # 恢复保存改动另外有一点一定要注意！
！
！
能够stash多个改动！。假设你切换
到还有一个分支又stash了，然后切换回来stash apply是恢复成还有一个
分支的stash。！
！
假设你这样stash了多次的话，我建议你先键入：
git stash list # 查看stash列表找到自己想恢复的那个
比方我这里恢复的应该是netword上的stash。而第一个stash是devlop上的
直接git stash apply恢复的就是这个，然而恢复的应该是network的那个stash：
git stash apply stash@{1}就是这样，按自己须要恢复就可以！
10.分支重命名
git branch -m 老分支名 新分支名 # 分支重命名远程仓库与远程分支
1.远程仓库简述
用于代码托管。能够自己搭建远程仓库。或者选择专业的代码托管平台：
自己搭建的优点有：可控，内网安全，能够做一些定制。比方集成编译，IM等，
当然，肯定是须要一些学习成本的，(PS：我厂就是自己搭的Gitlab，自己配置
还是比較麻烦的，简单点的能够试试 Gogs)
常见的代码托管平台(自己搜关键字去~)：
Github。Git@OSC。GitCafe，GitLab，coding.net，gitc。BitBucket。Geakit，Douban CODE
2.推送本地仓库到远程仓库【git push】
首先建立好与本地仓库同名的远程仓库，然后复制下远程仓库的地址，比方：
键入下述命令关联本地与远程仓库
git remote add origin 远程仓库地址 能够键入下述命令可查看远程仓库状况
接着把本地仓库推送到远程仓库，这里的 -u參数 作为第一次提交使用。
作用是把本地master分支和远程master分支关联起来(设置默认远程主机)。
兴许提交不须要这个參数！
git push -u origin master
另外。假设想改动远程仓库地址。可键入：
git remote set-url origin 远程仓库地址
# 也能够先删除origin后再加入
git remote rm origin # 删除仓库关联
git remote add origin 远程仓库地址 # 加入仓库关联或直接改动.git文件夹中的config文件。直接替换圈住位置
还要说明一点，origin 并非固定的东西。仅仅是后面仓库地址的一个 别名！
！
能够写成其它的东西，然后你也能够设置多个仓库关联，用不同的别名标志，比方：
git remote add github https://github.com/coder-pig/SimpleTea.git
git remote add osc git@git.oschina.net:coder-pig/SimpleTea.git3.克隆远程仓库【git clone】
把项目推送到远程仓库后，其它开发人员就能够把项目clone到本地
git clone 仓库地址 # 克隆项目到当前文件夹下
git clone 仓库地址 文件夹名 # 克隆项目到特定文件夹下4.同步远程仓库更新【git fetch】VS 【git pull】
关于获取远程server更新的方式有两种，他们各自是fetch和pull，
虽然都能够获取远程server更新。可是两者却又是不一样的。
git fetch：
仅仅仅仅是从远处server获取到最新版本号到本地。假如你不去合并(merge)
的话，本地工作空间是不会发生变化的！
比方：
我们在Github上创建一个README.md文件，然后调 git fetch 去获取远程
仓库的更新。
git pull：
一步到位。或者说：pull = fetch + merge。比方：相同改动Github上的
README.md 文件，然后git pull 同步远程仓库的更新
差别显而易见，实际开发中。使用git fetch会更安全一些，毕竟merge的时候
我们能够查看更新的情况。再决定是否进行合并，当然看实际须要吧。
5.推送本地分支到远程仓库
依照前面所讲。在本地开辟分支来完毕某些工作。本地提交了多次后，
你想把分支推送到远程仓库，此时远程仓库并没有这个分支，你能够：
git push origin 分支名 # 推送本地分支的内容到远程分支6.查看远程分支
git branch -r # 查看全部分支7.拉取远程分支到本地仓库
git checkout -b 本地分支 远程分支 # 会在本地新建分支，并自己主动切换到该分支
git fetch origin 远程分支:本地分支 # 会在本地新建分支。但不会自己主动切换，还需checkout
git branch --set-upstream 本地分支 远程分支 # 建立本地分支与远程分支的链接8.删除远程分支
git push origin :分支名 9.重命名远程分支
先删除远程分支。然后重命名本地分支，接着再Push到远程仓库
10.为项目加入SSH Key免去提交输入账号password的麻烦
不知道细心的你有没有发现，仓库地址除了Https外，还有一个SSH。
这里我们简介下两者的差别。第一点：使用Https url能够随意克隆
Github上的项目；而是用SSH url克隆的话，你必须是项目的拥有者或
管理员，并且还要加入SSH Key，否则会无法克隆。还有一点是，
Https每次push都须要输入username和password。而使用SSH则不须要输入
username假设配置SSH Key时设置了password。则须要输入password，否则直接
git push就能够了！
另外。SSH，Secure shell(安全外壳协议)，专为远程登陆会话
与其它网络服务提供安全性的协议，而SSH传输的数据是能够经过压缩的。
能够加快传输的速度，出于安全性与速度。我们优先考虑使用SSH协议，
而SSH的安全验证规则又分为基于password和基于密钥两种！
我们这里用的是基于另外一种的，即在本地创建一对密钥，
公钥(id_rsa.pub)和私钥(id_rsa),然后把公钥的内容贴到
Github账号的ssh keys中。这样就建立了本地和远程的认证关系，
当我们再push到远程仓库，会将你本地的公共密钥与server的进行匹配。
假设一致验证通过直接推送更新！
以下我们来建立ssh key。首先来到电脑的根文件夹下，这里假定我们没
创建过SSH key：
运行完ssh-keygen那个指令后，后面依次要你输入文件名称。
直接回车会生成两个默认的秘钥文件，接着提示输入password。
直接回车。假设这里你输入password了的话，那么push的时候
你还是须要输入password，接着又输多一次password。相同回车，
然后出现最以下的这串东西就说明ssh key已经创建成功了！
我们接着能够用编辑器打开id_rsa.pub文件或者键入:
clip <id_rsa.pub拷贝文件内容。然后打开Github，点击你的头像，选择：Settings。
然后点击左側SSH Keys,然后New SSH Key
然后Github会给你发来一个提示创建了一个新ssh key的邮件。
无视就好。接下来我们能够键入：ssh -T git@github.com，
然后假设你上面设置过password则须要输入password，
否则直接输入yes然后一直按回车就好！
，最后出现Hi xxx那句话
就说明ssh key配置成功了。
PS：其它远程仓库配置方法与此类同，
内容參考自：https://help.github.com/articles/generating-an-ssh-key/
附1：Githubclient
事实上，安装好Git后，就一有一个GitGui的东东了，就能够直接
用有用户界面的Git来做版本号管理的工作了，而Githubclient则是
Github给我们提供的一个专门用来管理Github项目的一个工具而已。
比方，假如你装了Githubclient，在Clone项目的时候，你仅仅需点击：
就能直接把项目clone下来，就是一些Git操作的图形化罢了，首先来到以下的链接
下载Githubclient：https://desktop.github.com/
文件非常小。后面点击运行文件后，他还要在线下载安装。100多m，
然后傻瓜式安装，安装完毕后，会自己主动打开Githubclient。然后
使用你的Github账号登陆，接着他会默认为你创建SSH Key信息。
接着的你自己摸索了！
这里另外补充一点。就是win 8.1装Githubclient的问题，
昨晚安装的时候一直报这个错误：
直接，win + x，选择”命令行提示符(管理员)“，运行以下以下的这个指令：
%SYSTEMROOT%SYSTEM32REGSVR32.EXE %SYSTEMROOT%SYSTEM32WUAUENG.DLL然后再点击Github的安装程序。等待安装完毕就可以，下载并不需梯子。
附2：删除Git仓库
点击进入你的仓库，点击Setting，拉到最后：
点击Delete this repository
弹出的对话框中输入要删除的仓库名称，接着点击删除
附3：为开源项目贡献代码
你能够Clone别人的开源项目，在看别人代码的时候。你认为作者有
某些地方写得不好，写错，或者你有更好的想法，你在本地改动后，
想把改动push推送到开源项目上，想法非常好，可是你不是项目的拥
有着和參与者。是无法推送更改的。。。这样是为了
避免熊孩子，毕竟熊孩子无处不在。參与开源项目的方法有两种：
第一种方法：
是让作者把你加为写作者，加入协作者流程：点击仓库的Settings
–>Collaborators然后输入想加入的人的username或者邮箱。点击
加入就可以。
另外一种方法：
点击Forkbutton，把这个项目fork到自己的账号下，然后Clone
到本地，然后做你想做的改动，commit提交，然后push到自己账
号里的仓库，然后打开开源项目。点击
。然后新建一个
pull request。接着设置自己的仓库为源仓库。设置源分支，
目标仓库与目标分支，然后还有pull request的标题和描写叙述信息，
填写完毕后，确定。这个时候开源项目的作者就会收到一个pull
request的请求，由他来进行审核。作者审查完代码认为没问题
的话，他能够点击一下mergebutton就可以将这个pull request合并
到自己的项目中。假如作者发现了你代码中还有些bug，他能够
通过Pull Request跟你说明，要修复了xxBUG才同意合并，那么
你再改动下BUG。提交，更改后的提交会进入Pull Request。
然后作者再审核这样。
PS:假如作者不关闭或者merge你的这个Pull Request，你能够一直
commit骚扰主项目…( ╯□╰ )
Git工作流
关于Git工作流。看到一篇图文并茂非常好的文章。就不反复造轮子了。
此处仅仅是做下相应工作流的简述。详情见：Git Workflows and Tutorials
1.集中式工作流
相似于SVN，只是仅仅有一条master分支，然后一群人就在这条分支上嗨，比方有小A和小B：
(冲突解决參照上面的套路)
- 1.项目管理者初始化仓库。然后推到远程仓库
- 2.其它人克隆远程仓库项目到本地
- 3.小A和小B完毕各自的工作
- 4.小A先完毕了，git push origin master 把代码推送到远程仓库
- 5.小B后完毕了，此时推送代码到远程仓库，出现文件改动冲突
- 6.小B须要先解决冲突。git pull –rebase origin master，然后rebase慢慢玩
- 7.小B把冲突解决后，git push origin master 把代码推送到远程仓库
2.功能分支工作流
和集中式分部流相比仅仅是分支再不是仅仅有master。而是依据功能开辟新的分支而已。演示样例：
注：这里的仓库管理者是拥有仓库管理权限的人
- 1.小A要开发新功能。git branch -b new-feature 开辟新分支
- 2.小A在new-feature上新功能相关的编写，他能够这个分支推到远程仓库
- 3.功能完毕后。发起请求pull request(合并请求)。把new-feature合并到master分支
- 4.仓库管理员能够看到小A的更改。能够进行一些评注。让小A做某些更改，
然后再发起pull request，或者把pull request拉到本地自行改动。- 5.仓库管理员认为能够了，合并分支到master上，然后把new-feature分支删掉
3.Gitflow工作流
事实上就是功能分支工作流做了一些规范而已，大概流程參见上面Git分支里的：
一个最简单有用的分支管理策略。
4.Forking工作流
分布式工作流，每一个开发人员都拥有自己独立的仓库，和上面的附3：为开源项目贡献代码
套路相似，把项目fork到自己的远程仓库，完毕相应更改。然后pull request到源仓库，
源仓库管理者能够决定是否合并。
5.Pull Request工作流
和Forking工作流相似。Pull Requests是Bitbucket上方便开发人员之间协作的功能
查缺补漏
一些高级技巧。工具。插件安利
1.巨好用的Git图形化工具SourceTree
命令行虽酷炫可装逼。可是有时用图形化工具还是能提高我们不少效率的。
如题，SourceTree。官网下载地址：https://www.sourcetreeapp.com/
2.把提交的commit从一个分支放到还有一个分支【git cherry-pick】
有时你可能须要把某个分支上的commit放到还有一个分支上，这个时候能够
使用cherry-pick。比方有以下这样两个分支：
master分支：A -> B -> C
feature分支：a -> b
如今想把feature上的b。放到master的C后，能够这样：
- Step 1：切换到feature分支上，git log拿到b commit的版本号号(SHA1)
- Step 2：切换到master分支，键入：git cherry-pick 版本号号
出现上面这种情况的话说明出现冲突了。处理冲突后，git add 和 git commit 走一波
就可以。
问题解决
1.fatal: refusing to merge unrelated histories
问题描写叙述：在Github上新建了一个仓库，里面带有一个licence文件，然后本地
本地项目想推到这个远程仓库上，git remote 设置了远程仓库后，push提示先pull，
pull的时候就报这个错了。解决方法例如以下：
git pull origin master --allow-unrelated-histories待续…(近期更新：2017.10.26)
编辑日志：
- 2017.5.3： 加入.gitignore注意事项
- 2017.9.5： 排版与内容优化，勘误。新增查缺补漏
- 2017.10.26：新增问题解决模块
- 顶
- 17
- 踩
- 0
