[Git] 极简Git——关于Git的简要回顾
- Git历史:它起源于Linux内核开发时,为辅助Linux开发而设计的版本控制系统,发源于C时代的它,有不少C的影子和影响,其中 stash 命令就算一个。
- Git属于第三代版本控制系统,Subversion属于第二代,而所谓最开始的版本控制,也就是手工复制啦
- Git是分布式版本控制系统,Subversion是中心化版本控制系统,依赖服务器,主要区别在于有无本地仓库(Repository)
- Git和Subversion第二区别:关于文件的快照,svn将某个文件的修改记录为文件,即某文件版本=初始文件+文件改动,而Git更加激进,对每个版本的文件都做了个克隆。
- Git中所有数据在存储前都计算校验和(Hash),然后以校验和来引用。校验和包括文件目录结构,文件自身校验和,以此来检测是否发生改动。
- Git的几个状态,其是啥,与命令的关系:
-
untracked 仅在项目文件夹下,仍未加入.git仓库底下,或被git rm 。
-
unmodified 受Git版本控制管理了,git add + git commit 但自上一次加入以来未更改过。
- modified 受Git版本控制管理了,但自上一次加入以来已更改。
- staged 受Git版本控制管理了,但自上一次加入以来已更改,且执行了git add再度生成了份克隆。
-
- Git的几个区域,及其与命令的关系
Working Directory Staging Area .git repository
|__________< check_out_____________|
|__< reset/add >__|_____commit >_____| - 所以checkout 会覆盖Working Directory 记得保存。IDEA有警告,nice.
- git init 进入文件夹后执行,以同步设置(repository等)
- git clone以克隆代码到本地
- git pull以更新云端代码到本地。
- stash与add,stash代表了当前文件的缓存区,stash to stack。与add的区别在于,它不会生成克隆,实际使用时,你会看到working directory的变更回到了上衣版本同步时的样子,更改则进入了栈,应用更改的时候pop出来,直白的面对数据结构,使人联想到C。
- Git分支,没什么好讲的,rebase的时候增加分支,值得注意的是,push冲突时,rebase 变基会有个小分支,会改变remote tracking branch。
- Git merge。合并
- Chery pick。在另外一个分支,通常是master,将其他分支,通常是dev,pick过来,merge的操作。
- 理论上提交的代码应该要做到没问题,不影响其他模块,实际上往往不行,所以2~3个分支总是需要的,dev,test,master。根据进度,测试情况,一点一点chery pick或者merge过来
- 正常的Git流程:git init/git clone-->git add-->[git stash-->git pull-->git stash apply ]-->git commit-->[git add -->git commit --amend]-->git push
- 各IDE的git 插件在保存时都会add。有文章说IDEA只会stash,是错的。可以开个cmd,定位到仓库底下,编保存边验证下。
- Git push 和pull 的本质在于同步commit对象,这点很重要,也是为什么可能会把别人的提交 变成 自己的提交的原因。