git相关整理（rebase，远程仓库，标签相关待整理）

1 简介

分布式版本控制系统

2 对比（集中式vs分布式）

• 集中式（svn） ：版本库是集中存放在中央服务器的，所有的操作（代码commit之类的操作）都需要和中央服务器交互。
• 分布式（git） ：每个人电脑里都有完整的版本库，分布式版本控制系统也会有一个中央服务器存放代码，方便交换开发者的修改。

• 版本库（repository）：仓库，（工作区的 .git 目录） 简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来,每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
• 工作区：git init所在目录，我们工作文件所在的目录区域。
• 暂存区（stage）：存在于版本库中，工作区的.git目录中。

– 此处应有图，暂无

3 git常用操作-版本相关

• 初始化仓库： git init
• 添加变动（暂存区）： git add

• 将工作区变动提交到暂存区

• 提交变动（版本库）： git commit -m

• 将暂存区变动提交到版本库对应分支

• 查询状态： git status

• 查看当前git状态

• 查看历史提交记录： git log
• 版本回退： git reset
• 版本回撤： git revert

• git reset 无需填写完整版本号，前几位即可，也不要太少，太少有可能重复
• 每一次commit记录都会生成一个十六进制的唯一id，版本回退等操作，指定commitId即可将版本后退到指定版本

• 查看命令历史： git reflog

• 当使用git reset回退一个版本之后，最新的版本依然存在，只不过git的HEAD指针指向了你回退的版本，可以通过 git reflog 找出最新版本的版本号，使用git reset 回到最新的版本。
• git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，git仅仅是把HEAD从指向最新版本调整为指向你回退的版本。

3 git常用操作-分支相关

1. 每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。在Git里，默认叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
2. 最新版本新增 git switch 命令，和git checkout 切换分支使用相同。

• 创建并切换至dev分支： git checkout -b dev

• 切换分支/分离head： git checkout <branchName/commitId>

也可将head从指向分支分离出来，切换至指定提交节点。
场景：master分支提交了三次，c1，c2，c3。现在想从c2拉一个新的分支，就可以先git checkout c2 ，head将指向c2节点。然后通过git checkout -b dev 拉取新分支。

//图 从提交历史拉新分支

• 指定分支合并到当前所在分支： git merge

默认Fast forward，可指定参数 --no-ff 会在merge的时候，创建一个新的commit，可用 -m 指定新的commit的描述信息

• 储存暂存区的修改： git stash
• 查看stash列表： git stash list
• 恢复stash中的内容到工作区： git stash apply
• 删除stash列表中的某个stash： git stash drop

• git stash save 可添加说明注释
• 恢复/删除命令中的 格式：stash@{0} ，stash@{1}…,不指定默认恢复stash@{0}。
• stash list先进后出，最新的永远是 stash@{0}
• 场景：当正在dev分支开发新版本的时候，需要切换到v1分支修改bug，只需要将当前分支变动全部git add 到暂存区，然后执行git stash，此时工作区内容全部恢复，和版本库中相同，此时可以切换至v1分支进行修改。
  

• 复制指定commit到当前分支 git cherry-pick

• 可以复制不连续的提交。
• 场景：接上一个场景，v1分支修改完bug，上线，合并到master，然后档dev开发完之后，需要上线新版本的时候，难道还需要修改bug的分支合并到dev上去吗？其实用cherry-pick更加简单，只需要把修改bug的那个提交记录的复制到dev分支就行了。需要注意的是，复制过去之后，commitId将会改变。所以实质其实就是将修改内容复制过去，重新做了一次提交。