Git学习

文档：https://git-scm.com/book/zh/v2

版本控制

关于版本控制

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 在所展示的例子中，我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。

如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。 有了它你就可以将选定的文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。

本地版本控制系统

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

记录文件每次的更新，可以对每一个版本做一个快照，或者是记录补丁文件，适合个人使用，如RCS

Figure 2. 集中化的版本控制.

这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

分布式版本控制系统

于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

使用码云

github 是有墙的，比较慢，在国内使用gitee，公司中有时候会搭建自己的gitlab服务器

1. 注册登录码云，完善个人信息
2. 设置本机绑定SSH公钥，实现免密码登录（免密码登录，这一步挺重要的，码云是远程仓库，我们是平时工作在本地仓库！）

git命令生成RSA公钥密码（生成的目录是C:Userswp990.ssh），并复制公钥密码的文本在gitee公钥框中并确定

3. 将公钥信息pulic key添加到码云账号即可
4. 使用码云创建一个自己仓库！（用户头像信息傍边）

许可证：开源是否可以随意转载，开源但是不能商用，不能转载

5. 克隆到本地

IDEA中集成Git

1. 新建项目，绑定git

   • 将我们远程的git项目目录拷贝到项目中即可
   • 注意idea的变化

2. 修改文件，使用IDEA操作git

   • 添加到暂存区
   • commit提交
   • push到远程仓库

3. 提交测试

Git分支

多个分支如果并行执行，就会导致我们的代码不冲突，也就是同时存在多个版本！

如果同一个文件在合并分支时被修改了则会引起冲突；解决办法是我们可以修改文件后重新提交！选择

要保留谁的代码

master主分支应该非常稳定，用来发布新版本，一般情况下不允许在上面工作，工作一般在新建的dev分支上工作，工作后，比如要发布，或者说dev分支代码稳定后可以合并到主分支master上来

anch]
#合并指定分支到当前分支
git merge [branch]
#删除分支
git branch -d [branch-name]
#删除远程分支
git push origin –delete [branch-name]
git branch -dr [remote/branch]

文章知识点与官方知识档案匹配，可进一步学习相关知识Git技能树首页概览2895 人正在系统学习中

来源：咸鱼的想法