git使用方法总结

Git所涉及到的基本原理及常用命令记录

本博客主要用于总结巩固所学git知识，并进行记录，便于日后复习查询。

一、Git的工作流程

• 工作区：平常我们开发就是拷贝远程仓库中的一个分支，基于该分支进行开发。在开发过程中就是对工作区的操作。
• 暂存区：暂存区会记录git add添加文件的相关信息，不保存文件实体，通过id指向每个文件实体。可以使用git status查看暂存区的状态。暂存区标记了你当前工作区中，哪些内容是被git管理的。
• 本地仓库：保存了对象被提交 过的各个版本，比起工作区和暂存区的内容，它要更旧一些。
• 远程仓库：远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。

二、HEAD

HEAD始终指向当前所处分支的最新的提交点。你所处的分支变化了，或者产生了新的提交点，HEAD就会跟着改变。

三、常用命令

1、git add

git add：添加当前目录所有文件到暂存区
git add [dir]：添加指定目录到暂存区
git add [file]：添加指定文件到暂存区

2、git commit

git commit -m [massage]：提交到本地仓库，并说明
git commit [file] -m [massage]：提交暂存区的指定文件到暂存区，并说明
git commit --amend -m [massage]：使用一次新的提交，替代上一次提交（提交之后，发现-m的说明文字写的有问题，想要重新写一次，也就是想撤销上次的提交动作，重新提交一次。重新提交是在日志看不到操作记录的。）

git commit --amend -m [massage]适用场景：

场景一、本地开发代码已提交，提交后发现这次提交的代码有问题，或者漏提交了一些文件，此时，希望达到以下目的：
1、修改有问题的代码。
2、补足漏提交的文件（一般是新增的文件没有git add .）
3、把以上2点相关的代码，和前一次提交的代码合并成1个提交。
4、给合并后的这个提交添加新的注释。
解决办法： 1、修改问题代码
2、git add . （把漏提交的文件假如暂存区）
3、执行git commit --amend -m “这里填写提交的注释”

场景二、新接到需求，需要基于master分支拉取一个feature分支，且这个feature分支只有你自己使用（这一点极其重要），由于开发周期较长，你不想每一次都产生一个新的commit，而是每一次commit都修改前一次提交，这样做的好处是，等到你的feature分支提测时，就只有1个干净的commit，没有乱七八糟的提交历史，你只要把这1个commit合并到master里就好了。
解决办法：在feature分支上，第1次提交代码时，使用git commit -am “第1次提交的注释”，
第2次以后提交代码时，使用git commit --amend -m “这里填写提交的注释”。
这样，整个分支可以只有1个commit。

3、git branch

4、git merge

//开发分支（dev）上的代码达到上线的标准后，要合并到 master 分支
git checkout dev
git pull
git checkout master
git merge dev
git push -u origin master

//当master代码改动了，需要更新开发分支（dev）上的代码
git checkout master 
git pull 
git checkout dev
git merge master 
git push -u origin dev

5、git rebase（与git merge本质的不同在于基础不同）

//master 分支合入到 feature 分支，注意是以feature为基础
git checkout feature
git merge master

git merge 的优势是它保留了分支的结构与历史提交目录，但同时这也导致了提交历史会被大量的 merge 污染。它是将把所有的提交压缩成一个 patch 。然后把 patch 添加到目标分支里。rebase 与 merge 不同的是，rebase 通过为原始分支中的每个提交创建全新的 commits 来重写项目历史记录。git rebase 的优势是可以获得更清晰的项目历史。首先，它消除了 git merge 所需的不必要的合并提交；其次，正如你在上图中所看到的，rebase 会产生完美线性的项目历史记录，你可以在 feature 分支上没有任何分叉的情况下一直追寻到项目的初始提交。但是， rebase 会丢失合并提交的上下文， 使我们无法看到真实的更改是何时合并到目标分支上的。

//以 master 分支为基，对 feautre 分支进行变基，注意基础为master
git checout feature
git rebase master

git merge vs git rebase

git merge： 记录下合并动作；很多时候这种合并动作是垃圾信息；不会修改原 commit ID；冲突只解决一次；
分支看着不大整洁；但是能看出合并的先后顺序 记录了真实的 commit 情况；包括每个分支的详情；会创建一个新的commit

git rebase： 改变当前分支 branch out 的位置；得到更简洁的项目历史；每个 commit 都需要解决冲突；修改所有
commit ID；不会创建新的commit

6、git reset

//对版本进行回退
git reset --soft：影响最小，只有HEAD指向的内容回退到上一个版本。
git reset --mixed：默认值，影响中等，HEAD指向内容和暂存区内容都回退到上一个版本。
git reset --hard：影响最大，HEAD指向内容、暂存区和工作区的内容都回退到上一个版本。

7、git revert

revert和reset：

• git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
• 在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，减少冲突。但是git
  reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入，产生很多冲突。
• git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

8、git push

git push <远程主机名> <本地分支名>:<远程分支名>

9、git diff

• git diff：显示工作目录(working tree)与索引区(即暂存区快照，index，就是git add过的)之间的文件变更，即显示未被add的文件变更。
• git diff --cached 或 git diff --staged：显示索引区和最后一次commit(HEAD)之间的文件更改，即显示已add但还未commit的文件变更。也即用"git commit"（不带-a）将被提交的文件变更。
• git diff HEAD：显示工作目录与最后一次commit之间的文件变更，即显示所有未commit（包括未add和add两类）的文件变更。也即用"git commit -a”将被提交的文件变更。

10、git cherry-pick
将指定的提交(commit)应用与其他分支。

// 将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样
git cherry-pick <commitHash>
// 转移该分支的最新一次提交
git cherry-pick 分支名

//1、举例来说，代码仓库有master和feature两个分支。
    a - b - c - d   Master
         \
           e - f - g Feature
//2、现在将提交f应用到master分支。
//切换到 master 分支
$ git checkout master
//cherry pick 操作
$ git cherry-pick f
//3、上面的操作完成以后，代码库就变成了下面的样子。
 
    a - b - c - d - f   Master
         \
           e - f - g Feature
//4、从上面可以看到，master分支的末尾增加了一个提交f。

11、git pull

git pull <远程主机名> <远程分支名>:<本地分支名>

取回远程主机某个分支的更新，再与本地的指定分支合并。git pull = git fetch + git merge。git pull命令用来从远程仓库下载更新内容，并立即将对应内容更新到本地仓库。在Git的协作工作流中，合并远程仓库变更到本地仓库是很常见的工作。而git pull命令实际上就是其他两个命令的结合体，先git fetch然后紧接着git merge。在git pull命令执行的第一个阶段，会先对当前本地HEAD指针指向的分支执行git fetch。当原称更新内容下载完成之后，git pull会接着进入合并流程。合并操作会创建一个新的commit，并且HEAD指针也会随之更新而指向这个新的commit。


如果向git pull命令传递一个 --rebase选项，那么合并策略则随之改变为rebase合并，而不是直接合并。

12、git clone和git fetch

• git clone：本地没有库，将其他仓库克隆到本地，包括被clone仓库的版本变化。举个例子，你当前目录比方说是在e:/course/中，此时若想下载远程仓库，本地无需git init,直接git clone url（url是你远程仓库的地址，直接复制就可以了）。执行git clone等待clone结束，e:/course/目录下自动会有一个.git的隐藏文件夹（如果看不见，请尝试设置隐藏文件夹可见），因为是clone来的，所以.git文件夹里存放着与远程仓库一模一样的版本库记录。clone操作是一个从无到有的克隆操作，再次强调不需要git init初始化。
• git fetch：本地已经有一个库，于是从远程获取最新到本地，不会自动merge
• git pull 是本地有 repository 时，将远程 repository 里新的 commit 数据(如有的话)下载过来，并且与本地代码merge。