Git与SVN的主要差别
Svn是封闭式的版控制技术，而git是分布式系统的
封闭式就存在ECC风险，除非SVN的远距库房读出来了，那我的邻近地区工程建设项目再也不会做递交，也不能做组成部分的转换，也不能够干和版管理相关的任何人事情。更顽固一点儿，假如svn的伺服器硬盘机械故障，虽然他们可能利用这类雇员邻近地区的快照版尽量恢复正常工程建设，但当他们把这个相对完备的版布署到伺服器的新库房时，将会遗失大部份的历史版主要包括笔记。
git是分布式系统的，表示他们每一人的邻近地区工程建设项目都包涵两个完备Git库房。这一点儿一定要谨记，邻近地区也是两个库房。
.svn而已单纯的留存一些版信息，但假如你把.git产品目录的表面积大小不一跟.svn比较，你会发现它们差距非常大。因为.git产品目录是处在你的电脑上的两个永古约省的版库，并不只抽取新一代版的文档快照， 而要把标识符库房完备地快照留下来，主要包括完备的历史纪录。
基本工作基本原理的不同
该些最关键性，请冷静看完。认知git的价值观，而不是纯粹的会使用几个指示。索韦泰，而要博奈。
SVN是历史记录每一文档每一版的差别变化，可以说是如前所述文档差别的版控制
如图，svn是储存每一文档在版的不断插值中产生的差别。
git不一样。如下图右图，git在你每天递交时，单厢对大部份文档工业生产两个快照。总之，假如文档没有修正，此次的快照而已聚合两个镜像，对准以后的文档，不会再copy这份文档。这和docker的多层快照有点儿相近。
对比两张图，git倾向于纵向切分，每两个版是两个清晰独立的版。而svn的每两个版，需要在前两个版的基础上追加差别才能得到。
标识符递交方式
svn相对来说更容易上手，更新标识符–>开发标识符–>递交标识符commit
git相对来说要复杂一点儿，更新标识符–>开发标识符–>add –>commit –>push
为什么步骤这么多，因为邻近地区也是两个库房。
邻近地区操作
因为git在邻近地区是两个完备的库房。所以绝大部分git指示都不需要访问远距库房。
Git理论基础
首先明确git中的术语
库房
workspace：工作区。当前你修正的标识符所在的地方。
index：暂存区。执行 git add指示后变动会递交到这。进入暂存区的变动才开始被git管理。
repository：邻近地区库房。git commit指示
remote：远端库房/中央库房。git push指示。
下面这张图更详细一点儿：
组成部分
有人把 Git 的组成部分模型称为它的“必杀技特性”，也正因为这一特性，使得 Git 从众多版控制技术中脱颖而出。为何 Git 的组成部分模型如此出众呢？Git 处理组成部分的方式可谓是难以置信的轻量，创建新组成部分这一操作几乎能在瞬间完成，并且在不同组成部分之间的转换操作也是一样便捷。认知和精通这一特性，你便会意识到 Git 是如此的强大而又独特
前面他们讲过，Git 保存的不是文档的变化或者差别，而要一系列不同时刻的 快照 。
Git 是怎么创建新组成部分的呢？很单纯，它而已为你创建了两个可以移动的新的指针。
如图，最早的递交是98ca9，每天递交后，整个master组成部分不断变长。HEAD是两个特殊指针，告诉git，他们现在在哪个组成部分上。
备注：Git 的 master 组成部分并不是两个特殊组成部分。它就跟其它组成部分完全没有差别。之所以几乎每两个库房都有 master 组成部分，是因为 git init 指示默认创建它，并且大多数人都懒得去改动它。
然后，他们在f30ab这个递交上，使用git branch指示创建两个testing组成部分。（git branch指示而已创建组成部分，并不会转换组成部分）
使用git checkout testing进行组成部分转换
现在head指针就对准了testing组成部分，他们所作的改动全部发生在testing组成部分上。
做一次新的改动递交。testing组成部分继续变长。但master组成部分依然对准f30ab。
假如现在他们想回到master组成部分继续开发，只需要git checkout master切回master组成部分。
注意，这时你的工作产品目录恢复正常成 master 组成部分所对准的快照内容。也就是说，你现在做修正的话，工程建设项目将始于两个较旧的版。本质上来讲，这就是忽略 testing 组成部分所做的修正，以便于向另两个方向进行开发。
这与过去大多数版控制技术形成了鲜明的对比，它们在创建组成部分时，将大部份的工程建设项目文档都复制一遍，并留存到两个特定的产品目录。。所需时间的长短，完全取决于工程建设项目的规模。而在 Git 中，任何人规模的工程建设项目都能在瞬间创建新组成部分。同时，由于每天递交单厢历史记录父对象，所以寻找恰当的合并基础（即共同祖先）也是同样的单纯和高效。
创建新组成部分的同时转换过去
通常他们会在创建两个新组成部分后立即转换过去，这可以用 git checkout -b 一条指示搞定。
Git基本操作
常用指示
组成部分操作
常用指示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又称为衍合，是合并的另外一种选择。
在开始阶段，他们处在new组成部分上，执行git rebase dev，那么new组成部分上新的commit都在master组成部分上重演一遍，最后checkout转换回到new组成部分。这一点儿与merge是一样的，合并前后所处的组成部分并没有改变。head依然对准new组成部分
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
resetreset指示把当前组成部分对准另两个位置，并且相应的变动工作区和暂存区。这个指示还是比较危险的。操作时请确保你知道你要做什么。
git reset —soft [commit]只改变递交点，暂存区和工作产品目录的内容都不改变git reset —mixed [commit]改变递交点，同时改变暂存区的内容git reset —hard [commit]暂存区、工作区的内容单厢被修正到与递交点完全一致的状态git reset –hard HEAD让工作区回到上次递交时的状态，邻近地区的修正都不要了。
revertgit revert用两个新递交来消除两个历史递交所做的任何人修正。如上图，将递交回滚到15df9b6。
revert与reset的差别master主组成部分应该非常稳定，用来发布新版，一般情况下不允许在上面工作，工作一般情况下在新建的dev组成部分上工作，工作完后，比如上要发布，或者说dev组成部分标识符稳定后可以合并到主组成部分master上来。
push
上传邻近地区库房组成部分到远距库房组成部分，实现同步。
git push [remote] [branch]上传邻近地区指定组成部分到远距库房git push [remote] –force强行推送当前组成部分到远距库房，即使有冲突。不建议使用git push [remote] –all推送大部份组成部分到远距库房
打标签操作
Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）。
git tag v1.0 //轻量标签git tag -a tagName -m “my tag” //附注标签。建议使用后期打标签假如你忘记了对某个递交打标签，可以后期补上
git tag -a v1.29fceb02 -m“补打标签”将tag同步到远端库房默认情况下，git push 指示并不会传送标签到远距库房伺服器上。在创建完标签后你必须显式地推送标签 使用git push origin [tagName]推送单个组成部分。
git push origin v1.0推送邻近地区大部份tag，使用git push origin –tags。
转换到某个tag跟组成部分一样，可以直接转换到某个tag去。
git checkout v1.0但注意：这个时候不位于任何人组成部分，处在游离状态，可以考虑如前所述这个tag创建两个组成部分。
git checkout -b 新组成部分名 v1.0其他指示
git status显示有变更的文档git log显示当前组成部分的版历史git diff显示暂存区和工作区的差别git diff HEAD显示工作区与当前组成部分新一代commit之间的差别git cherry-pick [commit]选择两个commit，合并进当前组成部分
Git问题解决
雇员密码定期修正后的问题
他们的git库房bitbucket密码是和雇员账号密码绑定的。他们的雇员密码每两个月会强制修正一次，导致git密码校验失败。
错误显示：remote error: CAPTCHA required
解决：1，打开控制面板；
2.点击打开用户账户；
3.点击打开凭证管理（windows凭证管理栏）
4.普通凭证下拉打开修正你已存在的git账号密码
修正或删除都可以
回到浏览器上把账户退出，重新登录下这一步经常会漏。放弃邻近地区修正
邻近地区标识符被改乱了。想要放弃重来。分三种情况。
1. 未使用git add 缓存标识符放弃某个文档的修正注意中间有–git checkout — filename放弃大部份文档修正 git checkout .git checkout .此指示用来放弃掉大部份还没有加入到缓存区（就是 git add 指示）的修正：内容修正与整个文档删除注意：此指示不会删除新建的文档，因为新建的文档还没加入git管理系统中，所以对git来说是未知，只需手动删除即可2. 已使用git add 缓存标识符，未使用git commit使用 git reset HEAD filenamegitreset HEAD filename放弃大部份文档修正 git reset HEADgit reset HEAD此指示用来清除 git 对于文档修正的缓存。相当于撤销 git add 指示所做的工作。在使用本指示后，邻近地区的修正并不会消失，而要回到了第一步1. 未使用git add 缓存标识符，继续使用用git checkout — filename，就可以放弃邻近地区修正
3. 已经用 git commit 递交了标识符使用 git reset –hard HEAD^ 来回退到上一次commit的状态gitreset –hard HEAD^或者回退到任意版git reset –hard commit id ，使用git log指示查看git递交历史和commit idgitreset –hard commit id
