标签：测试 手动 abort tags 指针 ORC space list lob
工作中git是一项必不可少的技能，在项目的开发进程中起着至关重要的作用
下面介绍一些git在工作中的一些使用实践、常用流程、常用命令，供大家参考！
Git的定义是：分布式版本控制系统，用于项目开发中的版本控制。
从本质上来讲 Git 是一个内容寻址（content-addressable）文件系统，并在此之上提供了一个版本控制系统的用户界面。
Git 的核心部分是一个简单的键值对数据库（key-value data store）。你可以向该数据库插入任意类型的内容，它会返回一个键值，通过该键值可以在任意时刻再次检索（retrieve）该内容。
git管理的项目工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。
已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。
工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。
Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。
在进行提交操作时，Git 会保存一个提交对象（commit object）。该提交对象会包含一个指向暂存内容快照的指针。但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。
git将项目的存储分为4部分，每部分有自己作用，见下图：(图片来自：博客)
Workspace：工作区（当前用户操作修改的区域）
Index/Stage：暂存区 （add后的区域）
Repository：仓库区或本地仓库（commit后的区域）
Remote：远程仓库（push后的区域）整体过程可以简述为：
工作区-->?add-->暂存区-->?commit-->本地仓库区-->?push-->远程仓库区
远程仓库区-->?fetch-->使用refs\remotes下对应分支文件记录远程分支末端commit_id 和 本地仓库区 -->?merge-->工作区
pull-->使用refs\remotes下对应分支文件记录远程分支末端commit_id and 本地仓库区 and 工作区git pull和git fetch有什么不同呢？下面简单说一下
想要知道他们得不同，我们需要先了解两个概念
FETCH_HEAD：可以看做是一个版本链接，记录在本地的refs\remotes下对应分支文件中，指向着目前已经从远程仓库取下来的分支的最新版本的commit_id。
commit-id：在每次本地commit来保存当前工作到本地仓库区后， 会产生一个commit-id，这是一个能唯一标识一个版本的序列号。在使用git push后，这个序列号还会同步到远程仓库。所以他们之间的不同在于：
git pull?直接将远程分支的修改更新到本地仓库区和本地工作区，我们就可以在本地工作区中看到最新代码
git fetch?只将远程分支的修改拉取到本地仓库，并更新到FETCHHEAD，记录远程分支最新的commitid，不会更新本地工作区代码，只有使用了?git merge?才会将提交更新到本地仓库区和工作区其他想要了解更多git内部消息请移步我的另一篇博文：git内部存储实现机制
在 git status中的体现，见下图：
Changesto be committed：:代表被add的文件，被加载到了暂存区
Changesnotstagedforcommit：代表在当前分支中被修改的文件，还没有被add，存储在工作区
Untrackedfiles?：代表不被git追踪的文件，可以理解为不被git管理的文件
如果没有Changes to be committed和Changes not staged for commit说明现阶段所有的修改已经被commit到本地仓库
Git 作为一个系统，是以它的一般操作来管理并操纵(HEAD、index、Working Directory)三棵树的
HEAD：?是当前分支引用的指针，它总是指向该分支上的最后一次提交。这表示 HEAD 将是下一次提交的父结点。通常，理解 HEAD 的最简方式，就是将它看做 你的上一次提交的快照。
index：?index索引是你的 预期的下一次提交。我们也会将这个概念引用为 Git 的 “暂存区域”，这就是当你运行 git commit 时 Git 看起来的样子。Git 将上一次检出到工作目录中的所有文件填充到索引区，它们看起来就像最初被检出时的样子。之后你会将其中一些文件替换为新版本，接着通过 git commit 将它们转换为树来用作新的提交。
WorkingDirectory：最后，你就有了自己的工作目录。另外两棵树以一种高效但并不直观的方式，将它们的内容存储在 .git 文件夹中。工作目录会将它们解包为实际的文件以便编辑。如下图：
首先，有个问题需要确认一下，提交信息是使用中文还是英文呢？
如果你的项目是开源项目并且面向国际的开源项目，类似于阿里的Druid\PingCAP的TiDB等，那么一定要是用英文提交信息的！如果你的项目是公司内部使用或者只会被公司内部开发修改，那么中文也是不错的，更加便于查看和管理。当然，开发组中的英文能力都不错的话，用英文也是可以的。
分支Branch管理：如果没有一个好的branch管理的话，可能会有下述图的情况，刺不刺激~
推荐的分支管理：
master?分支为主分支(保护分支)，禁止直接在master上进行修改代码和提交，此分支的代码可以随时被发布到线上；
develop?分支为测试分支或者叫做合并分支，所有开发完成需要提交测试的功能合并到该分支，该分支包含最新的更改；
feature?分支为开发分支，大家根据不同需求创建独立的功能分支，开发完成后合并到develop分支；
fix?分支为bug修复分支，需要根据实际情况对已发布的版本进行漏洞修复；标签Tag管理：Tag采用三段式：v版本.里程碑.序号（v2.3.1）
架构升级或架构重大调整，修改第1位
新功能上线或者模块大的调整，修改第2位
当然，可以根据实际情况来设计，比如项目特别大，可以使用四段表达Tag，项目比较小也可以使用二段式Tag，只要符合场景并有实际意义即可?！
提交信息格式：下面只是提供一种建议格式，大家可以根据自己的项目实际情况来定格式，只要能把当前提交表达清楚,格式统一,方便快速阅读和定位即可！
1.建议中文示例：
<新功能>(urllAnalyz) 添加解析url功能l
<修改>(TestServiceImpl) 修改某功能的某个实现为另一个实现
<重构>(getData) 重构获取数据的方法
<测试>(getDataTest) 添加（修改、删除）获取数据的单元测试代码
2.建议的英文示例：
feat：新功能（feature）
style：格式
fix：修补bug
refactor：重构
test：测试相关
3.格式（type：scope：body：issue）?：<|新功能|修改|Bug修复|重构|测试>（影响模块）提交描述信息（#issue?）
4.优点：
与github数据issue关联，便于通过issue获取更多信息
commit 提交时，格式统一，便于后续快速准确定位提交
4.1 初始化项目，并上传到git服务器
基本过程：创建远程仓库、初始化本地git仓库、将本地仓库与远程仓库关联起来、添加本地仓库想要提交的代码到本地git缓冲区，将本地仓库的本地分支与远程仓库的远程分支关联起来、提交代码
在git服务器上创建同名git项目，并获取http地址
本地git初始化项目git仓库，在项目目录下 git init
git remote add<name><http地址>其中http地址为上述第一步获取的远程仓库的地址，name一般为origin，当然也可以设置其他的名字 例如：git remote add origin http://igit.corp.com/my/test.git
? ? 4. 添加项目文件到本地git缓冲区 git add-A git commit-m ‘初始化项目‘ 或者 git commit-a-m ‘初始化项目‘
? ? 5. 将本地分支关联远程分支并提交，git默认在远程分支上创建于本地分支同名的分支 git push--set-upstream origin master
这就是将本地的master分支 与 origin远程仓库关联起来并在远程仓库创建同名master分支，以后本地master都提交到远程仓库中的origin/master分支上。
upstream：上游的意思
至此，应该就可以了，我们可以在git服务器上刷新看看是否提交上去了
4.2?提交某一分支的修改
查看当前分支的修改?git status
查看想要查看的文件的修改?git diff<file_name>
确认正确后，提交修改到暂存区?git add-A或者git add<file_name><file_name>
提交到本地仓库?git commit-m‘提交信息‘
git push4.3?拉取远程分支修改到本地分支
当远程分支别人推了一版新的代码时，我们想要将代码拉下来，可以采用两种方式pull 和 fetch+merge：(他们的不同点文章上面已经解释)
使用pull：
git pull使用fetch：
将远程所有分支最新的commitid更新到FETCHHEAD，记录远程分支最新的commit_id 和 本地仓库区?git fetch
git merge4.4?取消track某一文件
git rm-r--cache<file_name>untrack后，使用commit -a 时，不会将其添加到暂存区中
4.5?保存账号密码，避免每次push都要输入(简单方法)
确保在git中手动输入过账号和密码
git config--globalcredential.helper store4.6?暂存自己的修改，便于接着工作（特别有用）
试想一个场景：如果你正在一个分支上工作修改，leader让你改另外的分支的BUG或者对其他的分支做一些操作。
我们知道如果一个分支上有还没有commit的修改的话，不可以切换分支，但是又因为自己的工作还未完成，不想commit，此时 git stash 就起作用了。
你要把现在正在工作的分支保存下来，等处理完其他的再回来接着当前分支的修改工作。
? ? 1. 将当前分支的修改暂存起来（此处不等于add+commit）?git stash
备份当前的工作区的内容，从最新的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区修改的内容保存到Git栈中暂存起来。
? ? 2. 切换到别的分支工作，完成后切换回原来的工作分支，查看暂存列表?git stash list
显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复
? ? 3. 恢复暂存的修改到工作区?git stash apply<stash_name>?恢复暂存之后不删除暂存
从Git栈中读取最新一次保存的内容，恢复工作区的相关内容。
? ? git stash pop 恢复暂存之后删除暂存
从Git栈中读取最新一次保存的内容，恢复工作区的相关内容。之后pop会删除最新的暂存。
? ? 4. 删除“暂存”?git stash drop<stash_name>
从Git栈删除最旧的一个暂存
结束
4.7?将文件修改回退到某一状态
一些已经提交的或者已经修改的部分，想要再修改一下，或者删除已经提交的
a. 删除某些commit，将head重定位到某一commit（回溯到以前的版本） git reset--hard<commit_id>?
注意！！！上述命令会将commit_id前的所有commit修改删除git reset<commit_id>?
上述命令不会将commit_id前的commit删除，而是会将修改回退到本地工作区?
git push origin HEAD--force 此步骤将服务器方也设置为相应的commit
b. 将文件修改恢复到当前已提交分支的原样（未 git add 情况下） 撤销修改就回到和版本库一模一样的状态，即用版本库里的版本替换工作区的版本
git checkout--<file_name>
c. 将文件修改恢复到当前已提交分支的原样（已经 git add 情况下）?
git reset HEAD 将add退回?
git checkout--<file_name>
d. 将文件修改恢复到已提交分支的原样（已经 git commit 情况下）?
git reset<commit_id> 此处commit_id可以是任意分支的commit_id?
git checkout--<file_name>
4.8?版本的回溯与前进
有时候需要回溯或前进到以前的版本 或 回溯前进到以前的commit
只要记住commit_id就可以在版本之间来回的穿梭，注意是可以“来回”穿梭哦
获取需要回溯到版本的commitid?git log?--> 复制所需的版本commitid
回退到该版本?git reset--hard<commit_id>
git push origin HEAD--force初始化项目为git项目?
git init
clone服务器代码到本地?
git clone<http_url>
添加修改文件到暂存区?
git add<file_name>?
git add-A 添加所有修改文件到暂存区
提交修改到本地仓库?
git commit-m‘提交信息‘?
git commit-a-m‘提交信息‘ 相当于git add -A + git commit -m 的整合
提交本地仓库的修改到远程仓库?
git push
将远程库<remote_name style="margin: 0px; padding: 0px; box-sizing: border-box;">的远程分支<branch_name style="margin: 0px; padding: 0px; box-sizing: border-box;">作为当前分支的上游分支</branch_name></remote_name>?
git push--set-upstream<remote_name><branch_name><remote_name style="margin: 0px; padding: 0px; box-sizing: border-box;">为远程仓库的别名，一般为origin</remote_name>
查看文件本次的修改?
git diff 显示本次所有被修改文件的修改?
git diff<file_name> 显示该文件本次的修改
查看当前分支下当前状态?
git status 显示出被修改的文件和提交的次数等
查看提交历史?
git log?
git log--graph 查看分支合并图
merge其他分支到当前分支?
git merge<branch_name>
在merge过程如果出现冲突，在解决冲突后会产生一个新的commit，并且HEAD指向该commit 如果没有冲突，HEAD会在分支的最新commit上
切换到上一个分支?
git checkout-
切换到其他分支?
git checkout<branch_name>
在某一分支基础上创建新分支?
git checkout<branch_name> 切换到基础分支
git checkout-b<new_branch_name> 在当前分支基础上 创建新分支
显示分支?
git branch 所有本地分支?
git branch-r 所有远程分支?
git branch-a 所有分支，本地和远程
删除本地分支?
git branch-D<branch-name>
删除远程分支?
git push origin--delete<branch-name>
添加一个新的远程仓库?
git remote add<shortname><url>
在同一个项目的git url中可以添加多个远程仓库 每个仓库相互隔离有自己的分支管理
将本地分支与远程仓库中分支联系起来?
git push--set-upstream<远程仓库名称><远程仓库中分支名称>
以后本地的该分支的push，会默认提交到设置的远程仓库中远程分支中
删除远程仓库 git remote rm<远程仓库name>
删除本地tag git tag-d<tag_name>
删除远程tag git push origin:refs/tags/<tag_name>
查看tag信息 git show<tag_name>
暂存当前修改 git stash
查看暂存列表 git stash lsit
恢复暂存的修改?
git stash apply （恢复后不删除暂存）?
git stash pop （恢复后删除暂存）
删除暂存 git stash drop
撤回已经add到暂存区的文件到本地工作区?
git reset HEAD<file_name>?
git reset HEAD 回退所有add
add会被标识为Changes to be committed，取消add后标识为Changes not staged for commit(不等于untrack)
取消track某一文件 git rm-r--cache<file_name>
untrack后，使用commit -a 时，不会将其添加到暂存区中
只merge某一个分支上的某一个commit git cherry-pick<被merge分支中的某一个commit的commit-id>
撤销在本地工作区的文件的修改
撤销修改就回到和版本库一模一样的状态，即用版本库里的版本替换工作区的版本 git checkout--<file_name>
删除某些commit，将head重定位到某一commit（回溯到以前的版本）?
git reset--hard<commit_id>?
git push origin HEAD--force 此步骤将服务器方也设置为相应的commit
删除本地在远程服务器上不存在的分支 git remote prune origin
拉取远程分支到本地 git fetch origin<branch_name>
新建一个tag到指定commit?
git tag<tag_name><commit_id> git tag<tag_name> 当前commit
取消当前合并，重建合并前状态 git merge--abort
本文介绍了Git是什么、Git的存储结构、Git的提交规则和一些工作中常会用到的git操作的过程，最后总结了常用的命令。Git在工作中的团队开发中起着至关重要的作用，希望本篇文章可以对大家有些许帮助~
更多技术文章，欢迎关注博主！
标签：测试 手动 abort tags 指针 ORC space list lob
原文地址：https://blog.51cto.com/14786935/2490977
