git知识点

初始化版本库 ：

进入到新需要创建版本库的文件夹

git init 

创建版本库设置签名

设置用户名和密码 ，用来区分不同的开发人员的不同身份

• 项目级别：只对当前项目起作用

git config user.name zhangsan 
git config user.email zhanngsan@qq.com

签名存在路径： 当前工作空间的config文件里

• 系统级别：对当前系统起作用（一般都是用这个）

git config --global user.name lisi
git config --global user.email lisi@qq.com

签名存在路径： 当前windows登录用户的.gitconfig文件里

如果两个都设置了 则使用项目级别的 ，如果只有系统级别的就默认使用系统级别的

添加文件到暂存区并提交到版本库中

• 在工作区中 创建一个文件 a.txt
• 添加到暂存区中

git add a.txt // 添加单个文件
git add . // 添加所有文件

• 提交到版本库

git commit -m '第一次提交'

-m: 添加备注

• 查看日志 ,查看所有已提交版本的日志

git log 

步骤总结：

git add：将文件从工作区 添加到暂存区
git commit -m '备注信息'： 将暂存区的文件提交到版本库 当第一次提交时git会为我们自动创建第一主分支 master，以及指向master的一个指针叫HEAD，之后的每一次提交 都是默认提交到master分支上，然后把HEAD指向最新提交的内容
git log：查看版本库的提交日志

工作区：当前工作的的目录
版本库：.gti文件夹

差异对比

当我们修改文件后，如何对比工作区中的文件与暂存区中的文件？ 又或者暂存区中的文件与版本库中的文件进行对比呢？

接下来使用 git diff 命令来完成在进行修改，添加，提交过程中对文件差异的比较。

• 暂存区和工作区的对比

git diff a.txt

• 已提交版本之间的对比
  命令可以查看上一个commit之后的版本和最近commit的版本的区别

git diff HEAD^ HEAD 

// HEAD 代表当前版本
 // HEAD＾　代表　上一个版本库　
 // HEAD＾＾　代表　上上个版本库

• 已提交版本和工作区的对比

git diff HEAD a.txt // 当前工作区文件与最近已提交版本的对比
git diff 83dfnfd a.txt // 当前工作区与指定已提交版本号对比

查看状态

当我们修改数据后，如果不确定自己是否修改了，可以通过git status命令。查看当前工作区的装态

版本回退

将版本库中的版本回退到历史版本的某一个时刻

git reset  --hard HEAD^ // 回退到上一个版本
git reset --hard fds78fhdsj // 回退到指定版本号
git reflog // 查看所有历史版本

撤销修改

当我们修改工作区文件时，还没提交到暂存区，就发现这些修改是错误的，打算恢复到原来的样子。怎么办？
如果修改的不过，可以自己手动修改恢复到原始的状态，如果改动较大的话，手动处理就很容易出现有遗漏，而且麻烦。可以使用git checkout <file> 来撤销修改，如果以及提交到缓存区了，可以之间提交上去，然后将版本回退到上一个版本

远程推送

• https方式

git remote add origin https://gitee.com/xxx
git push -u origin master // 推送 只能推送已提交的版本库到远程仓库
在第一次推送时加了参数-u后，以后如果分支使用默认的即可直接用git push 代替git push origin master

• ssh协议
  gitbash执行命令 生成密钥：

ssh-keygen -t rsa // 三次回车 即可生成

随后打开公钥 把里面的内容复制到gitee 中设置中的公钥里

随后建立连接。

这里提示远程主机origin已经存在 这是因为之前使用https方式时添加过一次。这里我们把之前的链接删除，重新建立就好

建立连接时要输入yes,它问你是否需要建立安全连接，是的就要生成一个文件，因为安全连接依赖于此文件

远程拉取

git pull origin master 地址 // 如果已经建立了连接 可简写为 git pull

clone 远程仓库

git clone 仓库地址

通过clone 得到的仓库，会自动建立远程仓库的连接

解决冲突

冲突产生 A用户先 push了一个文件到远程库，B用户也push了一个同名的文件到远程成，这个时候，按理论来说，B后面提交的会覆盖A前面提交的，但是git版本控制工具就有这么一个功能，就是不能让你随随便便区覆盖别人的功能，这个时候B是提交不上去的，它会提示你 产生差异冲突。

• 模拟冲突：
  
  

• 解决冲突
  B 用户先把远程的代码pull下来，手动解决冲突
  这时后pull下来的文件是这样的
  
  这个时候的解决方案有三种：
  1.覆盖服务器的 以你的为准
  2.以服务器的为准
  3.两者合并
  这时候就要跟A协商了，看是使用哪种方案 假如这个时候选择第三种方案，
  
  然后继续push 即可解决冲突

远程跨团队开发

场景：A公司成员邀请B公司协助 完成某一个功能模块，但是又不想将其拉到开发者团队中，此时就需要完成跨团队的协作开发

第一步：B公司成员通过a公司的项目地址 把项目fork到自己的远程仓库中

第二步：A公司完成代码后需要 pull Requests 代码到A公司的远程库审核，B公司通过审核后 。代码将被合并

分支管理

分支有什么用

简单地说就是 。要开发一个新的模块，就先从master 分支上创建一个新的分支，这个新的分支内容是和master分支一样的，而你之后的操作都在分支上，直到功能开发完成，再把分支合并到master上

• 新建分支

用命令创建

git branch dev  // 创建一个dev分支
git checkout dev // 选中当前分支 dev

注：上面两个命令可以组合成一个复合命令
git checkout -b dev 

在gitee上创建

• 新建文件 提交到新的分支
  
  
  
• 分支合并

如果此时分支功能已经开发完成 就需要合并到master上

git checkout master // 切换回master分支
git pull // 合并前 拉取一下最新的master分支
git merge dev // 将dev下面的内容全部合并到master中  这里是合并本地上的分支
git push // 合并后将master分支推送到远程库

• 删除分支

git branch -d dev

• 查看所有分支

git branch

分支冲突

解决 ： 跟正常解决一样的。

忽略不需要提交的文件

通过 .gitignore 文件将不想推送的文件忽略掉
匹配规则：
#开头的文件标识注释，可以使用反斜杠进行转义
! 开头的模式标识否定，该文件将会再次被包含，如果排除了该文件的父级目录，则使用 ! 也不会再次被包含。可以使用反斜杠进行转义
/ 结束的模式只匹配文件夹以及在该文件夹路径下的内容，但是不匹配该文件
/ 开始的模式匹配项目跟目录
如果一个模式不包含斜杠，则它匹配相对于当前 .gitignore 文件路径的内容，如果该模式不在 .gitignore 文件中，则相对于项目根目录
** 匹配多级目录，可在开始，中间，结束
? 通用匹配单个字符
[] 通用匹配单个字符列表

idea 整合GIT

• 安装gitignore插件
• 
• idea 配置git
  如果git安装在默认路径下，那么idea会自动找到git的位置，如果更改了git的安装位置则需要手动配置一下git的路径
  
  启用git版本管理(第一次使用时需要配置）
  
  
• 创建版本控制
  

就在当前项目中创建了版本管理 。相当于执行了命令 git init

通过刚刚安装的插件，在当前项目中添加ignore 文件

可以勾选相对的模板，这里我们不勾选，直接创建空白的

配置需要忽略的文件

添加到暂存区中 （未添加到暂存区的文件名显示为 绿色）

之后进行提交 （已添加到暂存区的 但是还没提交的 文件名显示为 橙色）


提交完成后的文件颜色变回正常

• 同步到远程仓库
  
  
  
  查看远程仓库
  

• 从远程库拉取最新版本
  
  

• 冲突解决
  当push遇到冲突时，选择Merge进行处理

• 
  

冲突解决后，会自动commit 所以我们推送就行了

• idea 分支管理
  ~landexiel
• idea 版本回退
• 
  一般情况下 回退到历史版本，会放到新的分支上面