小猪的Git使用总结

文件夹

小猪的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 init

3.创建本地仓库【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的版本号号，能够写HEAD

8.找回丢失对象的最后一点希望【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.git

3.克隆远程仓库【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%\SYSTEM32\REGSVR32.EXE %SYSTEMROOT%\SYSTEM32\WUAUENG.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

上一篇我的2016年(先占坑，有时间再写)
下一篇怎样让孩子爱上设计模式 —— 1.面向对象相关概述