git2:git概述

1.简介

• git分布式版本控制系统 性能优越
• 什么是版本控制？
  记录文件内容变化（可以让用户查看文件历史版本）
  方便版本切换
• 公司中很多人修改代码，如何版本合并？
  用专业的版本控制工具
• 集中式和分布式的区别？
  集中式：SVN
  集中管理服务器（保证修改的同一套代码）
  优点：管理员轻松对每个人管理
  缺点：每次必须等上一个人修改完成之后再改，单点故障
  分布式：Git
  分布式 每个人在自己的本地库做版本控制，代码托管中心（远程库），每个人都可以推到远程库中，无单点故障（本地也有版本控制）
  解决了问题：断网情况下我也可以版本开发，因为版本是在本地开发的，且每个客户端都保存了完整的项目（包含历史记录）
• git发展
  linux开源，大神手动合并代码
  大神手动合并代码精力都不够
  自己用c语言开发了版本控制系统 Git管理
  开发了Github远程库，吸引了开源框架
• git工作机制
  工作区：代码存放的地方
  暂存区（git追踪到代码add）：将工作区的代码添加暂存区
  本地库（暂存区的代码提交本地库commit）：生成对应的历史版本（不能单独删除某个版本，删库跑路）
• 代码托管中心
  网络服务器的远程库(push)：本地库推送到的远程库
  互联网：GitHub（外网）
  Gitee：码云
  局域网：GitLab（自己搭建服务器）

2.git常用命令

• 用户签名 代表本地git客户端
  git config --global user.name 用户名
  git config --global user.email 邮箱
• 初始化本地库，git获取管理权
  在指定目录中执行git init
• 查看本地库状态
  git status
  On branch master 在默认分支master中
  No commits yet 还没提交
  nothing to commit (create/copy files and use “git add” to track) 没什么东西提交
  红色代表没被追踪（工作区）
• git add 文件名
  添加文件到暂存区即git追踪文件
  注意：linux换行符为 LF window换行符为CRLF
  而git默认linux行，故warning警告只是默认转换换行符
  此时绿色（当前已经追踪到该文件），但此时只是存在暂存区的文件，需要提交本地库
  可以删除暂存区
• git commit -m “日志信息” 文件名提交本地库
  形成历史版本
  On branch master
  nothing to commit, working tree clean
  已经提交过了，没有东西需要提交，工作树干净
• git reflog 查看历史记录
  查看版本
• git log 查看详细的用户日志
• git reset --hard 版本号 查看详细日志
• 修改文件
  Changes not staged for commit:
  (use “git add …” to update what will be committed)
  (use “git restore …” to discard changes in working directory)
  modified: hello.txt
  文件被修改，红色代表不在工作区
• 追踪add，提交commit（查看本地库状态又是干净）
• 查看版本信息
  命令git reflog
  ed592ea (HEAD -> master) HEAD@{0}: commit: second commit
  c659e16 HEAD@{1}: commit (initial): first commit
  注意此时head指针指向第二个版本
• git reflog 精简版日志
  git log 详细版日志

3.命令 版本穿梭

• git reset --hard 版本号
  git reflog 查看版本信息（获取版本号）
  git reset --hard 版本号 穿越回过去的版本
• 保存了 版本号 和 分支
  底层保存了版本信息
  调用Head指针来指向具体的版本

4.git分支操作

• 什么是分支（测试分支，开发分支）
  一个分支为一个副本（即程序员可以把自己从开发主线上分离开来，开发自己的分支不会影响主线的运行）
  分支的底层也是指针的调用
  运行的过程中，可以从（用户用着）主分支中剥离一块功能出来到我们复制的分支，开发复制的分支，之后直接将开发的分支加如主分支中即可，开发过程中不影响主分支的使用
• 分支的好处？
  并行推进多个功能开发
  某个分支失败，不会对整个程序有影响
• git branch 分支名 创建分支
  git branch -v 查看分支
  git checkout 分支名 切换分支
  git merge 分支名 把指定的分支合并到当前分支上
• 查看分支
  git branch -v
• 创建分支
  git branch hot-fix
• 此时master为用户使用分支，创建了一个热修分支，此时维护功能，切换分支
• git checkout hot-fix
  修改功能之后
  再提交功能
  $ git commmit -m “hot-fix first commit” hello.txt
• 此时hello.txt已经被修改
  且此时分支为hot-fix
• 切换分支
  Switched to branch ‘master’（hot-fix没改之前的版本）
• 分支合并（站在master分支上进行合并）
  git merge hot-fix
  此时hello.txt改成为为了hot-fix修改的文件
• 什么时候会有冲突合并？
  合并分支时，两个分支在同一个文件的同一个位置两套不一样的修改，无法觉得使用哪一个，人为决定使用哪个内容？
  比如master 中在最后一行增加了内容
  比如hot-fix 中在倒数第二行增加了内容
  即两个分支都有修改，此时无法自动合并
  需要手动合并文件（只会修改master文件内容）
  <<<<<<< HEAD(master中的文件)
  hello atguigu! hello git!
  master test
  =======(hot-fix中的文件)
  hello atguigu! hello git! hot-fix test
  >>>>>>> hot-fix
  合并完成之后，需要添加到暂存区，提交
  git commit -m “merge test” 不能携带文件名
• 合并分支底层也是指针
  HEAD:指向哪个分支(master)
  master分支指向哪个版本
• git团队协作机制（代码托管中心）
  相同团队
  push(首个提交远程库，设置push权限)
  clone（程序员修改clone，有push权限即push上去修改代码版本）
  pull（拉取下来）
  不同团队
  fork(一个团队远程库到另一个团队远程库)
  clone,push
  Pull Request–>–>审核（看看）–>merge
  pull