git使用

git起源与特性

git是分布式管理工具，由linux之父开发出来用于管理linux的源码，作为一种分布式管理工具，和其他集中式工具的差异点在于，git的每一个版本其实存储的都是该版本的完整的内容，它为该内容制作一个快照，并保存该快照的索引，然后通过该索引找到对应的内容，因此如果其中一个版本的内容被破坏了，那么其他版本的内容不会受到影响。集中式版本只在最初的版本中保存一个完整的版本，后续都是在上一个版本的基础上的修改内容，其中一环破坏了，后续的版本就不可用。git允许成千上万的并行分支的开发，是完全分布式的管理，除了与服务器之间需要按需进行同步之外，所有的提交过程均不需要使用到服务器。

git的安装和配置

linux

通过包管理工具安装或者源码安装，通过包管理工具的安装方法因操作系统而已，例如在ubuntu或者debian中，可以通过下面的方式安装，这种安装方式包含了git可以正常使用的核心包。

sudo apt-get install git

如果在centos，redhat等操作系统中，可以通过下面的包管理工具安装

yum install git

也可以通过源码安装，即通过make方式去安装，先从git官网 下载对应的tar.gz的包，然后解压处理，再安装，以ubuntu20.04为例子（自己经常用）

# 更新包管理器源信息
sudo apt update
# 安装必要的依赖包
sudo apt install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev make gettext libz-dev libssl-dev libghc-zlib-dev

tar zxvf git-2.5.0.tar.gz   # 解压
cd git-2.5.0   # 进入目录

sudo make prefix=/usr/local all			# 配置必要的包信息并安装
sudo make prefix=/usr/local install		

源码方式安装的git如果想要使用TAB补全功能，还需要将源码包中的补齐脚本复制到bash-completion对应的目录中，之后再重新加载自动补齐脚本，使得其在当前的shell中生效（短暂的，在当前shell关闭后就失效）

cp contrib/completion/git-completion.bash /etc/bash_completion.d/ 		# 将脚本信息复制到bash completion目录中

. /etc/bash_completion 			# 执行脚本使之生效

若要其长期生效，还需要配置环境变量，可以在~/.bashrc或者/etc/profile中添加下面的内容

if [ -f /etc/bash_completion ]; then
	. /etc/bash_completion
fi

windows

windows的git命令行使用命令的方式类似于linux：windows的git安装包自带minGW工具，在安装后minGW工具提供了类似于linux的shell环境，因此在git bash中使用方法和linux相同。 windows下的git安装按照提示步骤一步一步安装即可。

git 配置

配置类型

1. 系统配置：对所有用户都适用的配置，存放在git的安装目录下面，%git%/etc/gitconfig，如果要查看，那么需要使用命令：git config --system --list
2. 用户配置：只适用于该用户，存放在该用户的目录下，例如linux存放的位置在于~/.gitconfig，在查看时如果使用的是--global,查看的就是当前用户的配置，
3. 仓库配置：只对当前项目生效，存放在该项目的代码中的 .git/config下，加上--local即可查看仓库配置

每个级别的配置会覆盖上一级相同的配置。优先级最高的配置是仓库配置，其次是用户配置，最后是系统配置

配置个人身份

个人身份
如果git是首次安装则需要配置个人的名字和email，这在开发中比较重要，可以通过这个配置来决定你在开发中的工作量和具体输出的内容以及责任追踪。配置如下：

git config --global --user.name "xxx"
git config --global --user.email "xxx@163.com"

与服务器的认证配置

可以通过SSH，也可以通过http/https，常用SSH认证，该方式用公钥认证，即id_rsa.pub，不用输入密码，加密传输，操作便利且保证安全性。

生成公钥

ssh-keygen -t rsa -c xxx@163.com

生成过程会出现一系列的询问，直接回车，采用默认设置即可，见到下面的图就表明安装成功，然后去提示中的目录去查看对应的信息即可

在生成结束后，会在当前用户的目录下的.ssh/id_rsa.pub中生成git的公钥信息，此时打开代码平台，例如gitee，点击setting，点击SSH keys，然后点击add ssh key，然后将id_rsa.pub中的内容拷贝到里面，点击保存即可使用。

git基本操作

git版本控制下的三种工程区域&文件状态

1. 工程区域

• 版本库：repository，即git的版本库，里面存放git用户管理该工程的所有版本数据库，也叫做本地仓库。
• 工作区：日常工作的代码文件所在的文件夹
• 暂存区：一般存放在工程根目录 .git/index文件中，也称为索引

2. 文件状态

• 已提交，文件已经安全保存到本地版本库中
• 已修改，修改了某个文件，但未提交保存
• 已暂存，把已修改的文件放在下次提交时要保存的清单中。

项目初始化

git init firstproject # 创建项目目录

该命令会在当前文件夹下创建firstproject目录，并且该目录下会存在.git版本库控制文件夹

项目克隆

git clone git_url 		# 确保自己有权限克隆该项目
git lfs clone [url] 	# 如果项目中存在大量的二进制文件，那么项目使用git操作会非常慢，因此开发出lfs插件以适配二进制文件

在实际开发中，克隆项目需先询问是否支持git lfs，再决定使用git clone还是git lfs clone

新增/删除/移动文件到暂存区

git add  文件  	# 将文件添加到暂存区
git rm 文件		# 脱离当前git工程管理，操作之后无法再看到这个文件，即从暂存区中消失

git mv 		# 移动文件或者重命名文件
git mv test.conf conf/ 	# 将test.conf移动到conf文件夹下
git mv test.conf train.conf # 重命名test.conf为train.conf

work directory查看

git diff 比较项目中任意两个版本（分支）间的差异，也可以用于比较当前索引与上一次提交间的差异。如果因为修改内容太多，不想看到太多内容，也可以只查看修改的文件信息，即加参数--name-status。

git status：显示工作目录和暂存区的状态

• 分支信息
• 修改的文件是否被暂存
• 新增的文件是否被git管理

在git的命令行交互中，有许多提示信息，可以根据该提示信息做出对应的操作

commit提交

将暂存区中的文件改动提交到本地的版本库中

git commit file_name -m "commit message" # 提交单个文件到本地的版本库
git commit -am "commit message" # 提交当前版本库中的所有改动到版本库中

该操作是本地操作，是将本地的暂存文件提交到本地的版本库中记录起来，不影响远端服务器

git log日志中可以查到此次提交的id和描述信息

git日志

查看提交的历史

git log 	# 查看当前分支上的commit信息

包括commit_id author date以及commit message

git log可以和很多的参数搭配以查看不同的效果，例如-1表示查看最近的一条commit信息

提交远端服务器

与远端仓库建立联系，将代码修改推送到远端，其他开发者可以获取到你最新的修改

git push origin branch_name # 推送到远端相同分支名的仓库
git push origin branch_name:new_branch_name # 推送到远端不同的分支名下

windows下不同的分支名大小写不敏感，注意不要同时构建大小写不同的分支，这一步操作会影响远端文件的信息

git分支的管理

git branch # 本地仓库中所有的git分支名称，其中一个高亮的包括*的表示当前所处的分支
git branch -r # 返回的结果为远端仓库的所有分支，返回分支包括origin
git branch -a # 查看本地和远端的所有分支，其中远端带remotes

git branch 和git checkout -b 都可以新建分支
区别在于：git branch新建分支后不会切换到新分支；而git checkout -b 新建分支可以切换到新分支

git branch -d 和git branch -D 都可以删除本地分支，-D表示强制删除

如果要删除远端的分支，使用-r参数，使用完还需要推送到远端分支

git branch -d/D -r branch_name
git push origin branch_name

分支切换

git checkout branch_name # 切换
git checkout -f branch_name # 强制切换，如果有冲突，上面的checkout无法切换，可以用-f切换

分支拉取数据

git pull origin remote_branch  # 获取远端的相同名字的分支的代码
git pull origin remote_branch:local_branch # 从远端获取到代码，然后放入到local_branch中

###### git pull 能够拉取过来并进行分支合并，不给任何的思考空间，直接实现

git fetch # 拉取过来之后不会合并，这样子会留给用户一个操作空间，查看代码后再决定是否手动合并，更加安全
git fetch origin remote_branch / remote_branch:local_branch # 用法和git pull类似

分支合并

从指定的分支合并到当前的分支中，找到两个分支最近的共同点base，然后将指定分支在base之后的节点合并到当前分支上，即将两个分支之间的差异合并起来。

git merge branch_name
git rebase branch_name

git rebase 用于合并目标分支内容到当前分支，在于这点上和git merge相同，二者存在不同之处，具体如下

1. merge和rebase在合并分支后的区别，假设有分支A，然后从分支A拉出去一个分支B，分支B提交了几个commit，那么如果要将分支A和B合并起来，使用rebase会将分支B的commit信息放到分支A的commit信息的后面，如果使用merge则会将分支A和分支B的commit合并在一起，形成新的commit信息提交
2. git log会有一定的区别，merge命令不会保留merge的分支的commit，rebase则会保留
3. 使用merge命令合并分支，解决完冲突，执行add和commit之后会产生一个commit信息；rebase合并分支解决完冲突执行add和git rebase --continue不会产生额外的commit。好处就是干净，分支上不会存在分支合并的commit，坏处就在于如果合并的分支中存在多个commit，则需要重复多次处理冲突。
4. git pull/git pull --rebase ：git pull–>‘获取’和合并。加rebase是以rebase的方式进行合并分支，默认为merge

git撤销提交

在日常工作中难免会出现错误的误操作误提交，因此需要撤销提交，谨慎使用，修改内容可能会很多

git reset commit_id # 用于撤销当前工作区中的某些git add / commit操作, 后面跟随的是git log中的commit_id

#### 用于回退本地所有修改而未提交的内容，这条命令非常危险，
#### 会抹除本地工作区的修改内容，用暂存区的所有文件直接覆盖本地文件，
#### 达到回退内容的目标，且没有任何确认机会
git checkout .  

git checkout -filename  # 只是回退某个文件的未提交修改

git checkout commit_id # 回退到历史提交版本

git实操

远端仓库采用码云gitee实现，在实现之前先将生成的公钥添加到远端仓库的setting的ssh中，然后再开始下面的实验

模拟文件添加/提交/推送的功能

1. 首先克隆来自于远端仓库的代码。
   
   此时克隆下来的代码为远端仓库中的代码，在这个文件夹下面还有一个.git隐藏文件，用于管理本项目的版本库。在这里面简单的添加文件，然后加入内容。此时文件处于未被暂存unstage的状态，通过git status查看，但在截图中也表明了应该如何处理

echo "This is first test" >> test.md

待到git add后，可以看到状态已经改变，称为changes to be commited，此时的文件已经进入到暂存区

为将文件从暂存区放入到版本库中，需要commit

 git commit record.md -m "First Commit"

同时从git log中可以看到当前的提交信息，红色框中即为本次提交的信息，包括commit_id，时间，提交时的message

此时可以将更改推送到远端服务器上，远端服务器一般名字为origin，然后master分支

git push origin master

分支操作

先建立一个分支，即将当前分支的内容拉取到新的分支上，然后再在新的分支上开发，新的分支会继承原来分支上的git commit信息，然后可以自行commit，git log显示的是当前的分支上的commit信息

git checkout -b test1
git branch -a		# 查看远端和本地所有的分支
git branch -r		# 查看远端分支
git branch			# 查看本地分支

在本地新建分支后，通过git push操作可以在远端建立起新的分支

分支合并

git merge/rebase

git merge对原来的分支没有影响，且会在当前的分支上添加一个merge的commit信息
git rebase将被合并的分支的内容放到当前的commit后面，且新加的commit_id变化了，内容没有变化，git rebase相对于merge来说，会造成log的不清晰，即commit节点不清晰，使用原则：大量的人员协作时不要使用rebase，慎用

分支拉取

git fetch/pull

git fetch会将远端分支拉取到本地形成本地的一个分支，然后再进行合并，如果是git pull，直接拉取并合并，非常危险

git fetch origin feature/bugfix:feature/localfix		# 将远端的feature/bugfix拉取到本地的feature/localfix中

git冲突处理

先决条件：两个分支上对同一个文件进行修改，在合并的时候并不知道以谁的修改为准
实验条件：master分支和test1分支，均修改b.txt文件，master在文件中加入this is master edit，test1在文件中加入this is test1 edit。然后二者分别在各自的分支上commit并查看log信息，这是master的git log信息

这是test1分支的git log信息

然后在master分支上merge test1，此时发生conflict

此时我们需要解决冲突，从图中打印信息可看出冲突发生在0675+b.txt，由于两个分支上均编辑了b.txt，故本地仓库无法了解想要留下的是哪个分支上的信息，因此需要人为修改内容。注意，下图表明现在的状态是在master分支上的合并状态

此时需要修改b.txt以保留某一个分支的内容，这是单文件中的内容，表明两个分支的不同内容，可以保留上面，也可以保留下面，只要删除掉其中一种即可，这里保留this is master edit id

然后通过git status查看后续如何处理

git add b.txt

然后commit即可。从下面可以看出test1分支已经merge到master

git模块关系

上述的内容可以简单整理为一张图

上图展示了远端服务器与本地开发的关系，首先本地可以通过get clone/fetch/pull等方式从远端服务端拉取代码，拉取代码后可以在工作区修改代码，修改后的代码处于未被git管理状态，可通过git add filename的方式将修改文件加入到git的暂存区，进入暂存区后，还需要commit以形成版本库中的一个版本，可以通过git commit filename -m "commit message" 提交一个新的版本，这些版本被项目文件夹下的.git文件夹管理，等到commit后，可以通过git push 的方式将本地版本库中的代码push到远端服务器origin 中。

无论是本地还是远端开发都不可能只依靠master开发，因此需要多个分支，可通过git branch/checkout 等方式新建分支，在分支上开发后，可以通过git merge/rebase等方法将分支合并。