Git基本使用

1. 初见-版本控制简介

1. 释义：版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统；通俗地说就是记录自己工作以及学习情况，并且可对其进行修改*
   1. 1初见-版本控制系统分类
   本地版本控制系统
   通常人们都是复制一份自己的项目目录当作副本进行修改，并且会备注时间和说明，这一点很方便，但是也容易出错。
   所以出现了本地版本控制系统，最流行的一种RCS，它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化），通过应用不同的补丁，可以得到想要的版本的文件内容。
   
   集中化的版本控制系统
   本地版本控制系统在工作时效率太低，无法让多个开发者协同工作，于是集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）出现了，这种系统都有一个单一的集中管理的服务器，保存所有文件的修订版本，不同的开发者都可以通过客户端连接到服务器，取出自己需要做修改的文件，可以同时工作，每个人都可以在服务器上看到总项目的进度，管理员也可以轻松地掌控不同开发者的权限进行明确分工，比较流行的有CVS、Subversion以及Perforce等。
   但是，缺点也很明显，保存位置单一，如果服务器故障，中心数据库文件损失，项目的变更历史也消失了，无法回到之前的版本。
   
   分布式版本控制系统
   于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。常见的有：Git、Mercurial、Bazaar 以及 Darcs 等。它的特点是项目的存储位置灵活，因为每个开发者都可以把服务器的代码仓库完整地克隆下来到自己的客户端，包括完整的历史修改记录。就算服务器发生故障，可以用其他的镜像的代码仓库进行恢复，每一次克隆操作实际上就是一次完整的代码仓库备份。许多这类系统都可以指定和若干不同的远端代码仓库进行交互
   
   1.2初见-安装Git
   安装Git
   在Linux系统上安装Git
   1. 下载Git源代码压缩归档文件
      wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.26.2.tar.xz
   2. 解压缩和解归档
      xz -d git-2.26.2.tar.xz
      tar -xf git-2.26.2.tar
   3. 进入git源代码文件夹执行安装前的准备工作
      cd git-2.26.2 进入git源代码文件
      yum install zlib-devel libcurl-devel 安装zlib包
      ./configure --prefix=/usr/local 配置安装目录到usr/local
   4. 构建和安装
      make && make install
   5. 检查安装是否成功
      git --version 查看git的版本
      在 Windows 系统上安装
      官方版本可以在 Git 官方网站下载。 打开 https://git-scm.com/download/win，下载会自动开始
      2.Git基础-Git仓库
      2.1本地获取 Git 仓库
      有两种获取 Git 项目仓库的方式：
      1、将尚未进行版本控制的本地目录转换为 Git 仓库；
      2、从其它服务器 克隆 一个已存在的 Git 仓库。
      （1）将本地目录转换成Git 仓库，首先需要进入该项目目录中
      cd /xxx
      git init 初始化git仓库
      该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的骨干。
      工作区和暂存区
      工作区（Working Directory）：就是你在电脑里能看到的目录，比如我的xxx文件夹就是一个工作区版本（Repository）
      工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库，Git的版本库里存了很多东西，其中最重要的就是称为 stage（或者叫index）的暂存区
      （2）将文件放到仓库的暂存区（缓存区）
      git add
      git add . 把项目中所有文件放入仓库的暂存区
      （3）将暂存区内容提交到本地版本仓库
      首次提交需要填写所有者信息
      git config --global user.email “jackfrued@gmail.com” 常用邮箱
      git config --global user.name “username”
      上述两个操作只需首次提交设置
      git commit -m ‘提交的原因’ 例如添加/修改/删除了xx文件
      提交后还可以使用git diff HEAD --filname 查看工作区和版本库里最新版本的区别
      （4）查看提交日志
      git log 查看所有
      git reflog 查看当前版本之后的版本号
      （5）回退版本
      git reset --hard 版本号
      git reset --hard HEAD 当前版本
      （6）查看版本控制状态
      git status 查看暂存区中的文件
      git status -s
      git status --short 紧凑查看
      （7）使用暂存区或仓库内容恢复工作区
      git restore
      git restore --stage
      （8）撤销修改
      git checkout --filename 把文件在工作区的修改全部撤销。
      有两种情况：
      1、修改了后还没有放到暂存区现在撤销修改就回到和版本库一样的状态
      2、已经使用git add添加到了暂存区，但是又在工作区做了修改，现在撤销修改就是撤销工作区的修改回到添加到暂存区 的状态
      修改了添加到暂存区
      git reset HEAD filename 撤销暂存区的修改，放回工作区，但是工作区的修改还在，再使用checkout又可以撤销工作区的修改。
      （9）删除文件
      rm filename
      git知道你删除了文件，你的工作区就和版本库不一致了，用git status时git会告诉你哪些文件被删除了。现在有两个选择：
      1、确定要删除这个文件，用git rm filename删除，并且git commit；工作区和版本库就一致了
      2、删错了文件，使用git checkout --filename恢复，如果这个文件没有被添加到过版本库，不能恢复

2.2从服务器上远程获取Git仓库
Git服务器
GitHub —>全球最大的代码托管平台 https://github.com/
gitee.com —>码云
coding.net —>扣丁
（1）关联远端仓库
设置需要连接的远端仓库
git remote add origin(给url取一个名字) 仓库的url(HTTPS/SSH)
使用HTTPS每次提交需要输入密码，使用SSH可以创建密钥对实现免密访问
查看远端仓库
git remote -v
移除已连接的远端仓库
（2）向服务器推送代码
git push -u origin master 第一次推送master分支的所有内容
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改
（3）从连接的服务器仓库克隆项目代码到本地
git clone 远端仓库url --depth=1 加上depth=1克隆最新版本
（4）从服务器拉取代码
git pull origin master 拉取合并代码
git fetch origin master 拉取代码
（5）创建免密访问的密钥对
ssh-keygen -t -rsa -b 2048 -C"邮箱地址"
cat ~/.ssh/id_rsa.pub 查看密钥对，并且将密钥对复制下来部署到Gitee个人设置的SSH公钥部署中
3.分支管理
3.1创建与合并分支
在版本回退里，已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点；每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上
创建分支
Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变。
合并分支
直接把master指向dev的当前提交，就完成了合并；Git合并分支也很快！就改改指针，工作区内容也不变；合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支。
命令相关
git branch dev --创建dev分支
git checkout dev --切换到dev分支
git checkout -b dev --创建并切换到dev分支
git branch --查看当前分支，git branch命令会列出所有分支，当前分支前面会标一个*号
修改某个文件后，git add提交
git checkout master --切换回master分支
可以看到修改的内容没有生效，因为是在dec分支上提交的
git merge dev --将dev分支合并到当前分支
这时可以看到当前分支的内容改变了
合并完成后就不需要dev分支了
git branch -d dev --删除dev分支 -d即delete删除
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全
switch命令
切换分支这个动作，用switch更科学
git switch -c dev --创建并切换到新的dev分支 -c即create创建
git switch master --直接切换到已有的master分支
3.2解决冲突
创建新的分支，修改a文件内容，在新的分支上提交，然后切换到master分支，这时Git还会自动提示我们当前master分支比远程的master分支要超前1个提交，在master分支上修改a文件，然后提交。
这时候master和新创建的分支都有了新的提交，这种情况下执行合并分支就会发生冲突。
修改master分支的a文件内容和新创建的分支一样就可以解决冲突，然后提交，最后删除新创建的分支。
git log --graph --可以查看分支合并图
3.3分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
git merge --no-ff -m “merge with no-ff” dev 禁用Fast forward并创建一个新的commit
合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并
3.4Bug分支
在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
出现bug了可以创建分支来修复，但是当前的工作还没有提交，git提供了储藏功能
git stash --储藏当前工作
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支
修复完成后，切换到master分支，并完成合并，最后删除临时创建的分支，然后回到工作的分支继续工作
git stash list --查看储藏的工作区
恢复有两种方式
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了
可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash
git stash apply stash@{0}
bug在分支创建的分支都存在
git cherry-pick