GitHub社交编码（Social Coding）

1、当启动一个软件项目，为什么要从本地创建资源库，而Git怎么将那称作分布式的版本控制？

答：这个本地控制的想法，允许我们只从新项目启动，就在我们的命令行上，我们仅需要输入 git init新项目 ，就在我们的文件系统中，这个即被称为新的项目，如果继续前进转到文件夹目录结构，我们将会看到它只包含一个简单的.git文件。

.git文件：

一个具有一些简单的文件的文件夹，这些主要是纯文本格式，就是在这里，所有的东西得以保存，当我们对我们的源代码和项目做历史演变时，好处就是.git文件夹就是每一个Git和GitHub的工具的写入目标。无论它是GUI或命令行，它只需写入.git文件夹中。

 

2、添加远程目标时该怎么做呢？ 如何远程与他人交互？

答：与一个不同的远程端进行交互时，可以通过创建一个不用的地址来设置它，就在配置文件里面。

$ Git remote add origin https://git.com/……

$ cat.git/config

这只是Git用于开始读取的另一个地方,不仅要了解它将数据发送到那里，还要了解它可以从那里提取数据。所以这种想法很简单，再次，仅需要从文本文件中读取，让GIT知道有这么个地址，我想从那里得到资料，也有可能要将信息发送到那里，但同样，仅当你指定了位置。所以我们设置了这个地址，它可以是在您的网络中的，如果您有一个自托管的解决方案，它也可以在web上，如果您正在使用GitHub.com，工具知道如何与他对话  

 

PUSH    PULL

置清单（Setup Checklist）

1、设置：Git版本（Setup Git Version）

Git-scm.com 查看安装 Git命令行工具

2、设置：GitHub安装包

Windows.git.com

3、设置：GitHub账号

配置（Config）

1、配置用户信息（Config User Info）

$ git config --global user.name

Xiao YiYun

$git config --global user.email

Xiao_yiyun@qq.com

在git.com发布时会看到你的这些信息

 

2、配置行尾&颜色（Config Line Endings & Color）

行尾是特别重要的，因为在不同平台中的仍然有区别：Mac,linux,Windows,CR等，所有这些选择，Git将帮助标准化那些正在被check的文件到存储库，通过设置比如 core.autocrlf

$ git config --global core.autocrlf true

$ git config --global core.autocrlf input

颜色是更多的用户界面调整，颜色是非常容易识别的东西

$ git config --global color.ui auto

$ git diff

红色：正在进行处理

绿色：运行正常

 

3、Config有用的设置

local：具有最高的优先级，大于global

global：稍弱，将被local覆盖

System：最弱，通常是最模糊的或者不常用的设置，将被global或者local覆盖

初始化Git仓库

1、本地仓库（Local Repository）

$ git init //将该目录变成有git仓库的了

$ git init新项目名称//创建一个新项目并且是有git仓库的

$ git status //查看当前仓库的信息  

 

2、在GitHub.com上创建仓库

通过码云创建一个项目

提交（Commit）

Commit：源代码管理系统的关键——跟踪更改。

 

1、Commit：命令行（CommandLine）

$ git status  //告诉你什么文件有空能需要被提交，已更改的文件，或者是自上次提交后，你添加的文件

$ git add //将文件放在成为暂存区的持久化容器中 ，git status查看时变为绿色，每一个提交的文件都要经过暂存区，这是Git架构的一个关键部分

$ git commit // -m增加一些描述信息

 

2、Commit：GitHub.com

 

3、Commit：GitHub的Windows

差异指令（Diff）

Diff：观察你所做的成果和Git是怎样看待这些变化的窗口。

 

1、Diff git diff

$ git diff

找出项目中哪些地方被改动了，通过这个命令，对你的工作树的精确描述，也就是，仅仅是你的文件，而不同于你的暂存区域。

 

2、Diff --staged, HEAD

$ git diff --staged

暂存区域文件和最近提交的历史文件的区别

$ git diff HEAD

将你的工作树和头一次提交相比较，这只是在提交历史中最近一次提交的另一个别名。

 

3、Diff --color-words, --word-diff

$ git diff --color-words

$git diff --word-diff

一种对长行小改动而言更易读的报告

$ git diff --stat

让Diff阻止输出所有的代码块，而是仅仅输出更改了的文件。

日志（Log）

Log：一个很好的方式去了解你的仓库的进展，仓库的提交内容以及提交修改的文件。

 

1、 Getting started

在仓库中键入git log

$ git log

最上面记录的是我们最新的提交，最早提交的位于底部，他们是按照时间先后顺序排列的。

第一行：40个字符的十六进制码，作为唯一标识符，或者是git生成的提交引用。

第二行：提交者的用户名和邮箱地址

第三行：显示那次提交发生的时间

第四行：提交本身的内容  

如果你的仓库中有许多次提交，在你屏幕的左下角部分，你将会看到一个冒号，你可以使用上下方向键来滚动这些提交的内容，按照时间顺序来浏览这些内容。

 

2、 --oneline, --stat

尽管git日志给我们提供了很多可以查看的信息,但是我们使用

$ git log --oneline

可以更加方便的去快速查看一个概要，关于我们提交的是什么，提交的信息和一个简短的版本，关于标识符或者提交，这让我们能够快速了解到仓库历史是什么样子的以及代码是怎么前进的。

 

$git log --stat

查看每次提交中包含了哪些文件是更加经常用到的，我们不仅可以看到提交信息，提交引用，并且可以看到列出的每次提交包含的文件，我们可以看到他们的路径，甚至可以看到他们的相对改变，使用加减符号列出，表示每次提交中内容的增加或者减少。

 

 

3、 log --patch

$ git log --patch

在每次提交之间那些内容改变了，它会展示不同的地方，和后续的提交做对比，如果在两次提交之间，内容改变以及增加了，你将会看到使用绿色列出来并且会看到一些加法符号；

如果一些东西呗移除了，你将会看到一些减法符号，那可能会用红色展示。

记住，这些选项并不相互排斥，你可以把他们组合起来得到一个日志输出，那对于你的需求来说是最有用的，你可能想看看提交信息的概括，所以oneline听上去像是正确的选择。

但是，接着你也想要输出不同的地方，只需要运行

$ git log --patch --oneline

 

4、Diff --graph

$ git log --graph --all --decorate --oneline

展示每次提交的一行概括，将会使用ASCII码描述全部提交，同时他会提供我们每个分支的标签和我们提交的其他的标志，例如tags。

移除（Remove）

1、 Git rm命令

$ git rm file1.txt

如果你只有一个文件想要删除，使用这个命令可以真正的从文件系统中删除了文件，并且它会暂存这个文件已经被删除的事实，如果你提交了，这个文件不会从之前的历史中消失，

但会从未来的提交中消失。

 

2、 Git add -u命令

$ git add -u .

会遍历你的工作树，寻找Git之前已经识别到的文件，现在要消失的文件，它会把他们作为新的删除来暂存，这里输入了一个点作为文件名字，那只是意味着当前工作目录的简写，当它看到add时，它会从你当前所在的目录递归到最深处寻找它能够添加的所有文件，或者说，在这个场景下，所有能够被删除的文件。

 

 

3、 Git rm --***d命令

$ git rm --***d

删除这样一个文件，不想从文件系统中真正的删除它，换个说法，你想告诉Git，不再跟踪这个文件，但是把它保留在工作树中，这可能是一种情况，你以外地提交了一个文件，你并不想让他成为历史的一部分。它暂存了删除，但是，他在那里保存了文件，现在，在你的工作树中，作为一个不被追踪的文件。

移动（Move）

1、 Git mv指令

在Git中，重命名和移动文件是同一件事情 ，最基本的想法是，你有一段内容，比如一些代码，你把它从一个地方移动到另外一个地方，所以，假设我们有一些想要移动的文件从一个目录下面：

$ git mv源路径 目标路径

git已经暂存了move发生的事实，但是，如果你只是简单的使用mv命令来移动文件，然后忘了告诉git，Git注意到，某个地方出现了一个本不应该出现的新文件，它同时注意到原来的文件区域已经被删除掉了，我们可以一次一个步骤来解决它：

$ git rm //删除原来的文件

$ git add production.log //添加新文件

 当我们做这些的时候，状态把这些拼在一起了，告诉我们一个移动已经发生了。  

 

2、 git add -A

$ git add -A

它发现所有的移动过去的新文件，删除所有原来的就文件，然后解释为移动已经发生了，记住，这个只是告诉git从当前工作目录开始无限向下递归，你可以比这个更加具体，比如说，如果你已经在一个目录下作了移动，称作源暮落或者类似其他的，这一切都很好，但是注意到我们并没有改变这里的文件，当我们移动他们的时候，在一个真实的场景中，你可能会改变一点文件，当你将它们从一个目录移动到另外一个目录的时候，git仍然把它看做一次移动。

 

3、git log -M --follow

接着上面的，移动文件之后，我们在新的路径下面编辑这个文件，做另外一次提交，所以现在我们有了3次提交——文件创建的提交，文件移动的提交，在新的地方，文件编辑的提交，我们可以使用日志命令来展示这个文件在移动过程中的历史，历史在移动的时候停止了添加开关-M和--follow：

$git log --stat -M --follow

告诉日志在文件移动过程中跟踪文件，现在就可以得到想要的结果。

 

4、Similarity Index

回想一下，我们什么时候提交的？在我们移动这些文件之后，commit给我们一些数字，这些数字是一个类似度，可以表现文件在移动前后内容的相似度。Git默认提供一个50%的相似度阈值，如果文件在移动前后，50%相似，他会在移动的过程中追踪它，认为它是一个移动而不仅仅是一个删除和添加，我们可以调整这个阈值，通过在开关-M之后提供一个数字，如果你比较挑剔，可以使用大于50%的数值，你可以自由地添加参数，尽管如此，注意不要把阈值设置的太小，因为在一个比较低的相似度的情况下，你不认为是相同的文件最后可能会被判定为相同的。  

提修斯之船（Ship of Theseus）

1、 版本控制（Version Control）

1）CVS系统：当你移动文件的时候，历史就会被破坏，它认为这是一个完全不同的东西，你不能在移动过程中追踪文件的历史。

2）企业的版本控制：每个文件都有标识，文件可以分支，追踪文件的移动是很简单的事情，因为数据库记录这个东西。  

3） Git处理相似度：默认，只要有100%相似它就被判定为同一个东西。你可以上下调整这个参数：

$ git log --stat -1 -M

$ git log -M99 -1 --stat

使用-M在开关log命令中，当我们的相似度管的改变的时候，Git不存储Move内部的持久化数据结构，Move是时候的说明，关于日志的命令或者合并的命令，在仓库中发生，在持久化数据结构这个level，他只是存储一个删除和添加的操作，代码在以后能够读到那个数据，然后能够定义它是什么意义。

忽略（ignore）

Git ignore：会让你主观上避免暂存或者提交文件到我们的目标仓库中。

 

1、 The.gitignore File

为了避免文件或者目录提交到目标仓库，只需要在你的工程的根目录下面创建一个 .gitignore 文件：

$ touch .gitignore

$ git add .gitignore

$ git commit -m ” Preparing to ignore temporary files ”  

$ vim .gitignore

这里每一行的样式应该和你想要忽略的文件相匹配而且不再去关注它们，ignore的格式可以是简单的字符串或者更好地方式是使用*

*.log

目录/

记住，ignore匹配规则应该用到目录中的所有文件以及该目录下的所有次级目录，ingore格式也可以放在子目录中，我们需要在路径方面给他排一个优先级，它也可以让我们用！来应用于.git样式。

如果你有一个.gitignore的文件，而且需要评论一行，直接在描述或者评论的前面加上#号，这样这一行就称为了你ignore样式的描述了。  

如果你忘记在本地创建Git的ingnore文件，只需要在GitHub仓库页面点击+号创建文件，命名为 .gitignore 。

 

2、 选择忽略模式（Checking lgnore Patterns）

如果你想知道仓库中哪些文件被忽略了，而且你不想看.gitignore文件样式了，只需要到命令行下运行：

$ git ls-files --others --ignored --exclude-standard

显示出来的这些文件就是被忽视的文件，而且不再被关注了。

分支（Branch）

1、为什么要用分支（Why use Branch？）

当开始一个新项目或者打开一个已经存在的项目的时候，我们一开始就要新建一个分支，这是非常重要的。很多人认为master分支是许多工作代码所在的地方，但是我们在提交的时候要十分小心，因为他就是对产品特性的一种呈现，通过在这个分支上自由工作，允许我们安全地工作并且远离master分支。

 

2、 创建/删除（Creating&Deleting）

创建一个新分支：

$ git branch新分支名字

删除一个分支：

$ git branch -d分支名字  

如果它没有完全被合并，将会报错，告诉你把-d替换为-D  

 

3、 转换分支（Switching）

切换分支：

$ git checkout分支名字

当我们切换分支时，任何出现在面板区的工作或者工作目录都会跟着我们转过来，我们需要注意的是，如果我们处于这个活动目录或者面板去的文件被覆盖的话，是无法切换到新分支上面去的。  

最后一点，你可能看到文件消失又重现，在进行切换分支的时候不用担心这些文件和它们的改变，它们会待在各自的分支里，知道你合并它们为止。

切换分支（Check out）

1、 Check out to a branch

$ git checkout分支名字

重写那个分支的工作树和视图，它可以让我们看到我们的文件，就是我们版本控制中分支视图中看到的文档，我们可以检查我们正处于哪个分支：

$ git branch  

$ git status  

checkout的目的在于改变分支，之后就在 该分支或者环境下进行commit，一旦你commit到你已经切换的分支，你可以很容易切换到另外一个不同的分支，通过简单地使用相同的指令。

 

2、 Detached head

Checkout的另一个目的就是把你项目下的工作树、目录和文件等东西做一个更加详细的commit。

$ git checkout提交引用（40个16进制标识码）

这样我们的工作树在commit提交的那个时间点被覆盖了。当我们看到这个状态时，注意，我们正处于 detached head 状态，这不是我们想要commit的地方。这只是一种显示我们的工作树、目录和文件看起来是什么样子的方式。

 

一旦一已经了解了detached head状态后，一定要回去检查你的分支，使用这种方式，你将不会丢掉任何东西。

 

3、 丢弃编辑（Discarding edits）

checkout的另外一个目的是撤销或者丢弃编辑的内容。可能，我们有许多文件，但是只有一个是正确的。如果我们想丢弃掉这些改变我们可以运行：

$ git checkout --文件名

这个可以为我们做到的是它会清理掉最后一次commit的内容。

 

4、 联合移动（Combo moves）

Checkout的另一个功能是缩短一些其他的步骤，如果你想要创建一个分支然后切换到它，只使用一步的话，只需要运行：

$ git checkout -b新分支的名字  

合并（Merge）

Merge：把分支和多条线的历史操作汇聚起来。

 

1、 Git merge指令

通过merge我们可以把两个或者多分支的历史汇聚起来然后在工作树中展示，所有这些分支全部commit的累积结果。对于一个经典的工作流，我们会切换到master分支，然后确认该分支有我们想要合并的commit，我们运行git merge：

$ git merge分支名字

master分支现在有了累积的结果，包括文件、修改和历史，这些东西之前只是在那个主题分支上。  

 

2、 解决冲突（Resolving conflicts）

合并过程中遇到冲突意味着两个文件的变化非常的相似，Git自己不知道如何去解决这些冲突，或者把他们合并在一个文件里。为了解决这个，从冲突信息中很容易确认冲突文件，或者通过运行git status，然后可以看到哪些文件没有在commit中显现出来，手动解决冲突后再次提交即可。

 

3、 --abort指令

有一种情况是你遇到了分支冲突，但是你不想马上解决它或者你目前只想抛弃它，如果你这么做，简单地运行：

$ git merge --abort

这将会从你当前分支的最后一次提交中清除你的工作目录，它同样会清除你的暂存区。

 

4、 --squash指令

如果你不想把历史汇聚起来，但是你想要一个具体分支中的全部commit简单的运行：

$ git merge --squash目标分支名字

在你目前切换到的分支上创建一个新的提交，者代表了发生在目标分支上的所有改变。  

5、 git branch -d指令

一旦你成功地完成了一次合并，没必要保存分支标签或者名字，因为你可以从你的最终分支或者当前分支看到所有的历史，所有的提交，你需要做的事情实在合并之后清除分支名字：

$ git branch -d分支名字

这样就会清理分支名字，你不必再关注这个分支了。因为这些提交现在已经是主分支或者历史分支的一部分了。  

NetWork

1、 远端（Remotes）

$ git remote add目的地的名字 整个url地址

$ git remote set-url目的地名字 修改url地址

$ git remote rm远端名字

$ git remote -v得到全部的输出

远端追踪的分支则是分支间的中间人，这些分支有一些不同的唯一原因是在所有分支名字前面有一个前缀就是用来响应远程控制的，大部分情况加，这个将是origin/。

 

2、 Fetch，Pull，Push

Fetch命令本身失去github.com抓取任何信息下载下来，把它放在远程追踪分支里。

$ git fetch origin

pull命令和fetch非常像，它将要拉取东西到origin/分支名字里，然后做合并操作合并到那个分支名字的本地版本里。

$ git pull orgin

当我们的电脑完成工作时，并且我们准备把它发送到gitHub,com，我们输入：

$ git push origin

它会把全部信息发送到gitHub.com，现在，在做这个的过程中，它同时也会更新远端追踪的分支。

GUI

在你日常工作任务中，去和Git和GitHub交互，图形化用户界面是一种很方便的方式。图形化用户界面可以分为两类：第一类是提供关于所有命令行的抽象，这样你就可以点击按钮开替代输命令了；第二类的目的不在于去抽象Git命令行中的一切而是使用视觉化和图表来作为补充，这些只有在臃肿的客户端中才有可能，同时，仍然提供到命令行的入口作为大部分的选择切换。GitHub为Windows/mac提供了图形用户接口，其余的可以从git-scm网站上得到跨平台界面。

Forking

forKing可以用来获取你的仓库并拷贝它到自己的账户下。现在，拷贝这个行为让你安全地在沙盒里进行修改。这个可以工作在开源模型中以及开放公司模型中，极大地扩展了员工的数量去向工程贡献代码。

当我们看到一个我们想要贡献代码的项目，我们点击Fork按钮，从而在自己的账户下面建立一份拷贝，然后就可以开始我们自己的修改。合适的步骤是创建一个分支在那个拷贝库上，这样就会有一个名字、标签和容器服务于一个潜在的变更版本，我们之后会把这个版本加入到原来的仓库中。

一旦这个在你的账户下面，那里就会有一些元数据可以展示哪些用户拥有这个项目的原始拷贝，你也可以看到谁复制了这个项目。网络图提供了一些元数据到提交level上，可以看到人们在这个仓库干了些什么工作。

这些是一个准备步骤，会把你的变动返回个最初项目开发者，通过Pull Request的机制。

Pull Requests

Pull requestds是一个核心部分，可以把一些修改弄到其他GitHub仓库中。提交一个修改到另一个代码库中，你可以这样做，无论是一个核心代码贡献者亦或者是使用fork的帮手。如果你不是一个核心开发人员，你可以fork这个项目在你自己的仓库中工作、修改代码然后把这个修改发送回去。使用pull request，返回给原来的作者，者意味着，做出一个修改比抱怨一下更加舒服，这也就是为什么GitHub一直促进了开源的成长和发展。这也应用到闭源项目、公司项目和私人项目。

 

1、 Promoting Collaboration

如果你有权利push到仓库，你仍然应该工作在啊一个分支上，然后发送那个pull request去获得代码的一些review。这意味着你将要创建一个分支，开始一些提交，并且当你准备好接受review的时候，使用pull request把它发送给团队里的其他每个人。

这意味着pull request是一个会话，不仅仅是一个分支的一次提交而已。相反的，一些对白和讨论，对于代码的一些复审，以时间先后顺序出现。URL和pull request都是他们的依赖所在。

 

2、 Further Conversation

你不必停止会话，仅仅因为某些东西关闭或者不被接受，你可以继续找出他们为什么不被接受，找出在你以后可以做出哪些修改，确保你的所有的pull request都会被接受，它可以当做一个教育类工具用来教后面加入团队的人们，这些pull request是哪种变化，可能在文化上被接受的对话，有哪些期待、要求、格式是人们希望添加进去的。你可以保存这些URLs并且把他们当成教育工具送给新人。

这意味着，你不必弄一些邮件会话去讨论接下来的新特性，你只需要把URL给他们，然后他们随时都可以查看了。我们同时对技术输入很感兴趣，而不仅仅是人类的输入。一个CI系统，也就是持续集成系统都可以使用GitHub的pul request来集成并且报告这个分支的编译状态。Pull request的基础单位和会话一起发送。

随着会话和代码的改动，有一些编译的状态会弹出来，这同时会影响合并按钮的状态。给你一个警告，说“你不愿意让所有的测试通过，以及让分支清楚无误，在你按下合并pull request按钮之前？”。所以现在我们有CI状态和人类反馈的想法集成在一起，我们有整体、人类的review外加一些技术测试，不仅在分支内容上，并且预测分支和目的地的合并之后的情况。所以，你将看到未来，如果合并之后会怎么样。者并不意味着合并是持久的，这实际上是作了一次预计的合并，看看事情如何发展，然后告诉你，如果你这样做了一次合并，你是会成功还是会失败。

 

3、 Merging

如果CI报告了一个号状态，你会获得社交认可，得到一些赞，是时候按下合并pull request按钮了。一旦这个发生了，你也被提供选项去删除这个分支。这听起来有点令人担心，但是这并不知道一件坏事情。我们不必担心关闭和删除分支，因为所有的提交已经在目标分支了，它们已经被保存了。所以你可以删除分支，让人们知道将来的发展不会再在这个分支上发生了。Pull request仍然待在旁边，万一你想要讨论的记录以及你的身份认证和你已经做的贡献的声望出现在目标分支，随着这些提交合并。

重置（Reset）

Git reset：是一个允许你塑造仓库历史的命令。

 

1、 Mixed，soft，and hard：overview

Mixed：推荐模式，它会显示在status命令中。它修改了历史和工作记录，所以叫做混合模式，修改了多个东西。当你在暂存区有一些改动的时候，输入git status，我们可以看到reset Head，这允许我们把这些改变移除暂存区把他们放回到工作目录中。  

Soft：选取一条或者多条commit把它们的全部改变放回到暂存区，让你在此基础上继续创建新的提交。这些改动可能过于分散，但是这些commit都属于同一个事项，把它们全部弄到一起，通过

$ git reset --soft HEAD~5（几个commit就写几）

把这5次commit当做一次提交压缩进暂存区，对于重新塑造历史非常有用，但重塑历史操作有时候走的太远了，它把commit丢弃掉，并不添加任何价值，如果你不想发送，传送或者和其他人分享他们，这就是hard模式发挥作用的地方。

Hard：是一个具有破坏性的操作，这意味着擦除掉你不想保存的东西。如果你想完全丢掉一些你的工作，可能想丢掉一些不再发挥作用的变动你可以使用：

$ git reset --hard

完全丢掉这些提交。用Hard模式你可以在你喜欢的任何时候，清除这个历史操作。

 

2、 Checkout

与reset不同的地方是reset经常操作的是仓库的整个历史，checkout更加关注在一个目录或者文件级别的精度上，不是撤销或者改变一条提交，我们可以回到一个特定文件的某次提交的历史上，然后把这个文件和版本拉回到我们目前的工作目录。

清晰的沟通是所有Git仓库历史的目标，所以不管你是使用git reset har, reset soft,reset mixed或者更加精确的checkout命令，使用这些命令吧你的变动的清晰意图传达给你的同事。Git reset对于新手来说是一个有点让人害怕的工具，但是当你去处理创建你更好地仓库历史的时候它是一个非常有用的工具。

Reflog

1、 Git reflog

它会追踪你对修改内容的修改。

Git用户首先会发现他们在仓库的每次提交是一个实时的记录快照，会展示代码库是怎么发展的，但是更高级的git用户会发现reflog会追踪制造的commit以及丢弃的commit。这提供了一个30天的缓冲时间，在这期间，你可以从任何错误中回复，包括git reset命令带来的不好的部分，分支的删除或者可能rebase消失了。

Git reset对每个分支都很特别，你会注意到，如果你选择去观察，在.git目录下有一个子目录叫做logs，在那下面，每个分支都有具体的文件，你本地仓库里有的分支。每个这些日志都追踪你做的变动，包括前进和后退方向的。Git reflog命令是做到这个的用户接口，它打印出大部分最近的历史，分页机制让你可以通过已经发生的旧的入口去到你目前已经切换到的分支上。

 

2、 Using a GUI

Reflog提供的线性历史是很难查看的，哪一个是孤单的分支？哪一个是不在代码库里一部分的提交，一些有技巧和创造性的命令行可以把reflog的结果通过管道到一个图形用户界面：

$ gitk --all ‘ git reflog | cut -c1-7 ’ &

这样很容易看出来哪些分支是独立的，哪些提交不再是这个分支的一部分，哪些东西你想要恢复，通过捕获他们的哈希值和使用reset --hard命令。

 

3、 Frequent commits

Git reflog是你做频繁提交的动力，频繁提交意味着，在reflog里有历史存储着，不管你reset了它们，抛弃了提交，修改它们还是犯了一个错误。没有提交的所有东西，在工作区或者暂存区都是有风险的。但是，如果它被提交了，你可以恢复它们，这最近的30天有一个保证措施允许你采取大的，勇敢的步骤使用Git的其他特性。

Rebase

1、 standard usage

Rebase,在它的标准使用方式中允许一个分支在历史操作追踪中重新定位，意味着，把所有仅在你分支的所有变更表现为他们像发生在主分支下的当前工作之后。这完成了同一件事情，和一个反合并的将是相比，有着更加干净的历史。反合并从主分支挪到特色分支，相同的内容将会在特色分支中呈现。但是，不用复杂的合并进入到特色分支，然后在它的历史中记录。

 

2、 git checkout, git rebase

切记，rebase命令会修改所有提交在分支中的呈现，它保存你做的所有工作，但是他们的位置和跟其它提交的关系也改变了。这主要应用在一个只有你拥有的分支上，并且别人将不会在上面工作。Commit之前关系和这些每次提交的标识符的改变让它很难与其它人工协调时保持一致。

$ git checkout特色分支

$ git rebase原来的分支（一般是master分支）

这个将会依次检查发生在特色分支上的所有提交，然后在主分支上重播他们，似乎他们被重写，从最近的一个时间点开始，当这个过程完成的时候，看着所有单条提交都导入之后它会让你知道，rebase已经完成了，你也会回到一个命令行提示界面，这似乎是一个类似的状态和你运行哪个指令之前相比。然而，所有这些历史提交现在有了新的标识。

 

3、 History vs features

持续发布的应用一般用merge优化而不是rebase，他们想要一个最快可能的，发表机制去发送一个变更，小而专注，到master分支上。如果它没有做它应该做的所有事情，另外一个分支就会开始工作，然后再回来把它合并掉。rebase是一个非常有用的特色工具，让你优化仓库历史的清晰度。只需要记住你的项目和你的团队的需求，如果它需要快速发表特色分支，那么合并它们，如果它需要历史的清晰度，那么使用rebase.