[开发工具]Git！！！一文了解Git基本使用，git~

Git！！！一文了解Git基本使用，git~

前言

本文章是对Git的基本概念和操作进行整理，供于对git有一个基本的了解，以及基本的使用。

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

Git是一门工具，用于和仓库数据进行操作，抓取和克隆，提交等操作。

一、git安装

Git的安装并不难，从网上直接下载git安装包安装即可。

安装完成后，可以在电脑桌面右键，当看到有两个菜单（Git GUI Here 和 Git Bash Here）则说明Git安装成功。

• Git GUI：Git提供的图形界面工具
• Git Bash：Git提供的命令行工具（常用）

当安装Git后首先要做的事情是设置用户名称和email地址。这是非常重要的，因为每次Git提交都会使用该用户信息。切记~~~！

二、使用前的准备

1.基本配置

• 设置用户信息

git config --global user.name "XXX" # 设置用户名
git config --global user.email "XXXX" # 设置邮箱

• 查看配置信息

作用：查看用户名和用户邮箱

git config --global user.name

git config --global user.email

2.为常用指令配置别名

首先打开用户目录（~），创建 .bashrc文件

touch ~/.bashrc

在.bashrc文件中输入如下内容：

# 用于输出git提交日志 
alias git-log='git log --pretty=oneline --all --graph --abbrev-commit' 
#用于输出当前目录所有文件及基本信息 
alias ll='ls -al'

（注意，写入的时候，空格左右不能存在有空格）

（按vi 可以进入.bashrc，按下i键，进入编辑模式，写入之后按esc退出编辑模式，输入英文冒号进入末行模式，输入wq，保存并退出）

打开Git Bash Here来执行刚刚配置好的文件

source ~/.bashrc

3.创建本地仓库

1. 在仓库目录下，注意要有空目录，用此来作我们的本地Git仓库
2. 进入后右键打开Git Bash窗口
3. 执行git init命令
4. 成功！可在文件夹下看到隐藏的.git目录

三、git基础常用命令

1.status查看修改的状态

• 作用：查看修改的状态（暂存区、工作区）

• 命令形式：git status

git status

2.add添加工作区到暂存区

• 作用：添加工作区一个或多个文件的修改到暂存区

• 命令形式：git add 单个文件名|通配符

git add file.txt # 添加单个文件
git add .  #将所有修改加入暂存区

3.commit提交暂存区到本地仓库

• 作用：提交暂存区内容到本地仓库的当前分支

• 命令形式：git commit -m ‘注释内容

git commit -m "XXX update"

4.log查看提交日志

• 作用:查看提交记录

• 命令形式：git log [option] 或者 git-log

  —all 显示所有分支
  —pretty=oneline 将提交信息显示为一行
  —abbrev-commit 使得输出的commitId更简短
  —graph 以图的形式显示

（由于前面已经用别名进行了设置，故可以直接用git -log）

	git-log

5.版本回退

• 作用：版本切换

• 命令形式：git reset --hard commitID

git reset --hard commitID # commitID 可以使用 git-log 或 git log 指令查看

（用git reflog 可以查看执行的操作记录，用于回退后找不到最新版本）

git reflog

6.添加文件至忽略列表

一般我们总会有些文件无需纳入Git 的管理，也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。 在这种情况下，我们可以在工作目录中创建一个名为 .gitignore 的文件（文件名称固定），列出要忽略的文件模式。

四、分支

1.查看本地分支

git branch

2.创建本地分支

git branch 分支名

3.切换分支

git checkout 分支名

git checkout -b 新分支名  #切换到一个不存在的分支，创建并切换

4.合并分支

将指定的分支合并到当前分支上。

git merge 分支名  

5.删除分支

不能删除当前分支，只能删除其他分支

git branch -d 分支名 # 删除分支时，做检查

git branch -D 分支名  # 不做任何检查，强制删除

6.解决合并冲突

当两个分支上对文件的修改可能会存在冲突，例如同时修改了同一个文件的同一行，这时就需要手动解决冲突，解决冲突步骤如下：

• 处理文件中冲突的地方

  打开冲突的文件，其中会显示出两个分支对它的两种修改，将两种修合并改为一种修改，这样就解决了内容修改上的冲突。

• 将解决完冲突的文件加入暂存区(add)

• 提交到仓库(commit)

  提交后会弹出一个合并记录，git-log此时可以查看合并已经处理完毕

7.分支使用原则与流程

? 在开发中，一般有如下分支使用原则与流程：

• master （生产） 分支：线上分支，主分支，中小规模项目作为线上运行的应用对应的分支；

• develop（开发）分支：是从master创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到master分支，准备上线。

• feature/xxxx分支：从develop创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完成后合并到develop分支，之后该分支可以删除。

• hotfix/xxxx分支：从master派生的分支，一般作为线上bug修复使用，修复完成后需要合并到master、test、develop分支。

• test分支：用于代码测试

• pre分支：预上线分支

五、git远程仓库

1.常用的托管服务【远程仓库】

github、gitee码云、GitLab

• GitHub（ 地址：https://github.com/ ）是一个面向开源及私有软件项目的托管平台，因为只支持Git 作为唯一的版本库格式进行托管，故名GitHub

• 码云（地址： https://gitee.com/ ）是国内的一个代码托管平台，由于服务器在国内，所以相比于 GitHub，码云速度会更快

• GitLab （地址： https://about.gitlab.com/ ）是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务，一般用于在企业、学校等内部网络搭建git私服。

2.配置SSH公钥

• 生成SSH公钥

ssh-keygen -t rsa

输入后不断回车，若存在公钥，则会自动覆盖

• Gitee设置账号共公钥

获取公钥

cat ~/.ssh/id_rsa.pub

验证是否配置成功

ssh -T git@gitee.com

3.操作远程仓库

3.1添加远程仓库

（添加前需要先初始化本地仓库，再能与创建的远程仓库进行连接）

用前小知识点：

• 远端名称：默认是origin，取决于远端服务器设置

• 仓库地址：从远端服务器获取此URL（注意，只有连接上公钥的仓库，才可以进行push推送）

git remote add <远端名称> <仓库地址>

3.2查看远程仓库

git remote

3.3推送到远程仓库

git push [-f] [--set-upstream] [远端名称] [本地分支名][:远端分支名]

? 示例：

git push origin master:master

(tips：如果远程仓库的分支名与本地分支名相同，则可以只写本地分支名)，例如：

git push origin master

参数分析：

-f 表示强制推送，一般在公司内没有这个的使用权限，否则容易冲掉远程仓库的所有代码

--set-upstream 推送到远端的同时，建立起和远端分支的关联关系。用于第一次推送时。

? 示例：

git push --set-upstream origin master:master

• 查看本地分支与远程分支的绑定关系

git branch -vv

如果当前分支已经和远端分支关联，则可以省略分支名和远端名。

例如：利用git push 将master分支推送到已关联的远端分支（注意：前提是要关联，才能够像下面这样子写）

git push

3.4从远程仓库克隆

git clone <仓库地址> [本地指定目录，若没指定，则默认当下此目录]

3.5从远程仓库中抓取

抓取后的远程分支和本地的分支一样，我们都可以进行merge操作，只需要先更新下载到本地，就可以了

• 抓取命令，是将更新抓取到本地，不合并

• 若不指定远端名称和分支名，则抓取所有分支

git fetch [remote name] [branch name]

抓取后的合并命令。

? 示例：

git merge origin/master

3.6从远程仓库中拉取

注意拉取与抓取的区别：

• 拉取指令是将远端仓库的更新拉到本地并自动进行合并，等同于fetch+merge
• 若不指定远端名称和分支名，则抓取所有并更新合并当前分支

git pull [remote name] [branch name]

3.7解决合并冲突

当A、B两人一起修改了同文件，此时若A先推送到远程仓库，后面B再提交时就容易发送冲突。由于B晚于A，故需要先拉取远程仓库的提交后，经过合并，才能推送到远端分支。

由于修改了同一个文件的相同位置代码（经过测试，修改同一个文件不同位置也会产生冲突）。

解决方法：远程分支也是分支，所以合并时冲突的解决方式也和解决本地冲突相同

• 处理文件中冲突的地方

• 将解决完冲突的文件加入暂存区(add)

• 提交到仓库(commit)

六、Git知识点补充

1. rebase和merge

1.1 HEAD：

HEAD指向当前所在的分支，类似一个活动的指针，做一个[引用]。 （指向的是某个提交点）

1.2 fast-forward 与 --no-ff 的区别

假如有一个场景：有两个分支，master 分支和 feature 分支。现在，feautre 分支需要合并回 master 分支。

• fast-forward： 合并方式是条件允许的情况，通过将 master 分支的 HEAD 位置移动到 feature 分支的最新提交点上，这样就实现了快速合并。这种情况，是不会新生成 commit 的。（快进模式）

  git checkout master # 先切换到master分支
  git merge feature # 将feature分支合并到当前分支上（master）
  

• –no-ff ：该方式进行合并，master 分支就会新生成一次提交记录commit。

  git checkout master # 先切换到master分支
  git merge --no-ff feature # 将feature分支合并到当前分支上（master）
  

  如果**条件满足**时，merge 默认采用的 **fast-forward** 方式进行合并，
  除非你显示的加上 --no-ff 选项；
  
  而**条件不满足**（分叉了）时，merge 也是无法使用 fast-forward 合并成功的，
  则会采用**--no-ff**的方式进行合并！

（条件：快进模式能够进行的条件是：源分支和目标分支之间没有分叉。下图则是无法通过 HEAD 的快速移动实现分支的合并。）

? 举例说明：master/B 分支/节点后面没有其他节点。

1.3 merge 操作的 Tips ：

git merge 操作是区分上下文的。当前分支始终是目标分支，其他一个或多个分支始终合并到当前分支。这个注意点记住了，方便记忆！所以，当需要将某个分支合并到目标分支时，需要先切到目标分支上。（要合并到哪，就要先跳到哪去！！！）

举例：

git checkout master # 先切换到目标分支
git merge feature

1.4 rebase操作

rebase 合并往往又被称为 「变基」。这里的「基」就是一个「基点」、「起点」的意思。git rebase 命令通常称为向前移植（forward porting）。

「变基」就是改变当前分支的起点。注意，是当前分支！ rebase 命令后面紧接着的就是「基分支」。与merge操作相反。

变基前：

变基后：

执行的命令：

git checkout feature # 切换到当前分支，或待变基分支
git rebase master # 变基

# 可合并为下面的语句（与上同效果）
git rebase master feature

  解释：**rebase**，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，
  
  feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支
  
  的新基底。实际操作为把B之后feature的提交存下来，然后删掉原来这些提交，再找到master的最新提交位
  
  置，把存下来的提交再接上去（新节点新commit id），如此feature分支的基底就相当于变成了E而不是原来
  
  的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，
  
  此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）

当出现冲突时，解决每个冲突后要将修改后的文件 add 和 commit 然后执行

git rebase --continue

进行下一个冲突或合并成功

中途退出的代码，取消合并

git rebase --abort

1.5 merge 和 rebase 推荐使用场景

往公共分支上合代码的时候，推荐使用merge。

拉公共分支最新代码的时候，推荐使用rebase，也就是git pull -r或git pull --rebase，但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛。

1.6 git pull 和 git pull --rebase

在以下为实践操作中，来对两者做对比。

场景：从Develop分支分出两个分支，分属两个人员进行开发。F1分支开发完毕后，push到总分支。F2分支开发到F2_5时需要拉取最新代码，采用什么方式来进行拉取呢？？？

情况一： 如果F2分支采用git pull拉取最新代码：（生成一个新的提交commit）

F1分支的视角（F1分支的commit记录）：

F2分支的视角：这将会把F1分支的修改直接拉下来于本地代码merge，且产生一个commit F2_5，
也就是merge commit。

情况二：如果F2分支采用git pull --rebase 拉取最新代码：（会在F2的原最新提交F2_4上进行合并，不会产生新的提交commit）

F1分支视角不变
F2分支视角：

2. 强制拉取到本地仓库

git fetch --all  
git reset --hard origin/master 
git pull

3. 远程分支合并

该项职责由git管理员来完成。例如当开发分支Develop上的所有功能已经完成时，需要合并到master上时：

• 代码clone到本地仓库

git clone

• 在本地创建dev分支并与远程dev分支对应

git checkout -b dev origin/dev

• 切换到master分支

git checkout master

• 本地的dev合并到master上（遇到冲突解决完后再次提交）

git merge dev

• 推送到远程的master上（执行这项操作时，需要有操作远程master分支的权限）

git push origin master

总结

注：本文的资料参照是黑马的教程。

结束，以上便是在学习Git的过程中，整理的一系列操作，需要的直接跟着敲一敲命令，git基本操作起来并不是很难，保护好数据！切记，在换分支拉取仓库的时候记得提前把数据提交或推送上去，数据头等大事！。

就这样，老规矩，不秃头 日志，以上为个人笔记，也作为经验分享，大家可以参考使用，有问题也可以提出。