责任编辑转发于提前布局Ruheng，归纳十分好，故无须多次重复造车轮。

在日常生活组织工作中，时常会加进Git操作方式。但对后辈来说，刚上去对Git很孤单，操作方式出来也很懵逼。第一集该文主要就特别针对刚开始碰触Git的后辈，认知Git的基本概念，掌控常见的许多指示。

一、Git组织工作业务流程

以内主要就包括许多单纯而常见的指示，但先不重视那些，先来介绍上面这4个辞汇。

Workspace：组织工作区Index / Stage：甲类Repository：库房区（或邻近地区库房）Remote：远距库房

组织工作区

开发人员展开合作开发更动的地方性，是你现阶段看见的，也是新一代的。

平时我们合作开发是复本远距库房中的一个组成部分，如前所述该组成部分展开合作开发。在合作开发操作过程中是对组织工作区的操作方式。

甲类

.git产品目录下的index文档, 甲类会历史记录git add加进文档的有关重要信息(文档名、大小不一、timestamp…)，不留存文档虚拟, 透过id对准每一文档虚拟。能采用git status查阅甲类的状况。甲类记号了你现阶段组织工作区中，什么样文本是被git管理工作的。

当你顺利完成某一市场需求或机能后须要递交到远距库房，所以第二步是透过git add先递交到甲类，被git管理工作。

邻近地区库房

留存了对象被递交 过的各版，较之组织工作区和甲类的文本，它要更旧许多。

git commit后并行index的产品目录树到邻近地区库房，方便从下一步透过git push并行邻近地区库房与远距库房的并行。

远距库房

远距库房的文本可能被分布在多个地点的处于协作关系的邻近地区库房修改，因此它可能与邻近地区库房并行，也可能不并行，但它的文本是最旧的。

小结

任何第一类都是在组织工作区中诞生和被修改；任何修改都是从进入index区才开始被版控制；只有把修改递交到邻近地区库房，该修改才能在库房中留下痕迹；与协作者分享邻近地区的修改，能把它们push到远距库房来共享。

上面这幅图更加直接阐述了四个区域之间的关系，可能有些指示不太清楚，没关系，下部分会详细介绍。

二、常见Git指示

网上找了个图，别人整理的一张图，很全很好，借来用下。上面详细解释许多常见指示。

HEAD

在掌控具体指示前，先认知下HEAD。

HEAD，它始终对准现阶段所处组成部分的新一代的递交点。你所处的组成部分变化了，或者产生了新的递交点，HEAD就会跟着改变。

add

add有关指示很单纯，主要就实现将组织工作区修改的文本递交到甲类，交由git管理工作。

git add . 加进现阶段产品目录的所有文档到甲类 git add [dir] 加进指定产品目录到甲类，主要就包括子产品目录 git add [file1] 加进指定文档到甲类

commit

commit有关指示也很单纯，主要就实现将暂存区的文本递交到邻近地区库房，并使得现阶段组成部分的HEAD向后移动一个递交点。

git commit -m [message] 递交甲类到邻近地区库房,message代表说明重要信息 git commit [file1] -m [message] 递交甲类的指定文档到邻近地区库房 git commit –amend -m [message] 采用一次新的commit，替代上一次递交

branch

涉及到协作，自然会涉及到组成部分，关于组成部分，大概有展示组成部分，切换组成部分，创建组成部分，删除组成部分这四种操作方式。

git branch 列出所有邻近地区组成部分 git branch -r 列出所有远程组成部分 git branch -a 列出所有邻近地区组成部分和远距组成部分 git branch [branch-name] 新建一个组成部分，但依然停留在现阶段组成部分 git checkout -b [branch-name] 新建一个组成部分，并切换到该组成部分 git branch –track [branch][remote-branch] 新建一个分支，与指定的远距组成部分建立追踪关系 git checkout [branch-name] 切换到指定组成部分，并更新组织工作区 git branch -d [branch-name] 删除组成部分 git push origin –delete [branch-name] 删除远距组成部分

关于组成部分的操作方式虽然比较多，但都比较单纯好记。

merge

merge指示把不同的分支合并出来。如上图，在实际开放中，我们可能从master组成部分中切出一个组成部分，然后展开合作开发顺利完成市场需求，中间经过R3,R4,R5的commit历史记录，最后合作开发顺利完成须要合入master中，这便加进了merge。

git fetch [remote] merge之前先拉一下远距库房新一代代码 git merge [branch] 合并指定组成部分到现阶段组成部分

一般在merge之后，会出现conflict，须要特别针对冲突情况，手动解除冲突。主要就是因为两个用户修改了同一文档的同一块区域。如下图所示，须要手动解除。

rebase

rebase又称为衍合，是合并的另外一种选择。

在开始阶段，我们处于new组成部分上，执行git rebase dev，所以new组成部分上新的commit都在master组成部分上重演一遍，最后checkout切换回到new组成部分。这一点与merge是一样的，合并前后所处的组成部分并没有改变。git rebase dev，通俗的解释是new组成部分想站在dev的肩膀上继续下去。rebase也须要手动解决冲突。

rebase与merge的区别

现在我们有这样的两个组成部分,test和master，递交如下：

D—E test / A—B—C—F master复制代码

在master执行git merge test,然后会得到如下结果：

D——–E / \ A—B—C—F—-G test, master复制代码

在master执行git rebase test，然后得到如下结果：

A—B—D—E—C—F test, master复制代码

能看见，merge操作方式会生成一个新的节点，之前的递交分开显示。而rebase操作方式不会生成新的节点，是将两个组成部分融合成一个线性的递交。

如果你想要一个干净的，没有merge commit的线性历史树，所以你应该选择git rebase

如果你想保留完整的历史历史记录，并且想要避免重写commit history的风险，你应该选择采用git merge

reset

reset指示把现阶段组成部分对准另一个位置，并且相应的变动组织工作区和甲类。

git reset —soft [commit] 只改变递交点，甲类和组织工作产品目录的文本都不改变 git reset —mixed [commit] 改变递交点，同时改变甲类的文本 git reset —hard [commit] 甲类、组织工作区的文本都会被修改到与递交点完全一致的状况 git reset –hard HEAD 让组织工作区回到上次递交时的状况

revert

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的文本。

push

上传邻近地区库房组成部分到远距库房组成部分，实现并行。

git push [remote][branch] 上传本地指定组成部分到远距库房 git push [remote] –force 强行推送现阶段组成部分到远距库房，即使有冲突 git push [remote] –all 推送所有组成部分到远距库房

其他指示

git status 显示有变更的文档

git log 显示现阶段组成部分的版历史

git diff 显示甲类和组织工作区的差异

git diff HEAD 显示组织工作区与现阶段组成部分新一代commit之间的差异

git cherry-pick [commit] 选择一个commit，合并进现阶段组成部分

以内是关于Git的许多常见指示及详细阐述，相信能对Git有一个初步的认识。

作者：苏州韭菜明

链接：

https://www.jianshu.com/p/9685a56bdf7a

來源：简书

简书著作权归作者所有，任何形式的转发都请联系作者获得授权并注明出处。