git学习与使用（远程仓库、分支、工作流）

前言

阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。

简介

Git 是一个分布式版本控制系统，用于管理和跟踪代码或文件的变更。它可以记录文件的每一次修改，帮助开发者协作、管理代码版本、追踪项目历史，并在需要时恢复到之前的版本。

Git 是免费、开源的，由林纳斯·托瓦兹（Linus Torvalds）在 2005 年开发，最初用于 Linux 内核开发。如今，它广泛应用于各种软件开发项目中，尤其是在团队协作开发中。

除了git还有svn、cvs这样的版本控制系统，它们的区别在于一个是分布式一个是集中式

集中式的版本控制系统，有一个单一的服务器，保存所有文件的修订版本。协同工作的人通过客户端连接到这台服务器，在每次写代码时都需要从服务器中拉取一份下来，从而取出最新的文件或者提交更新。你本机客户端仅保存当前的版本信息，换句话说，集中式就是把代码放在一个服务器上集中管理，你的所有回滚等操作都需要服务器的支持。（如下图）

分布式的区别在于，每个人的电脑都是服务器，当你从主仓库拉取一份代码下来后，取的不是最新的文件快照，而是把代码仓库完整的镜像下来到本地库(克隆/备份)，无需担心主仓库被删或者找不到的情况，你可以自由在本地回滚，提交，当你想把自己的代码提交到主仓库时，只需要合并推送到主仓库就可以了，同时你可以把自己的代码新建一份仓库分享给其它人。

git的工作流程

• 工作区是你当前正在进行开发和编辑文件的地方。它就是你的项目文件所在的目录，包含你正在修改、编辑、编写的所有文件。
• 暂存区是一个临时的存储区域，保存你想要提交的改动。它类似于“准备提交”的区域。你可以将修改部分地加入暂存区，只将当前开发的一部分内容提交，而不是整个工作区的内容。
• 本地仓库是你计算机上的 Git 仓库，保存项目的所有历史提交记录。当你对文件进行提交（git commit）时，文件会被从暂存区提交到本地仓库，成为项目的永久记录。
• 远程仓库是托管在服务器上的仓库，如 GitHub、GitLab 或 Gitee。它与本地仓库不同，通常用于团队协作或代码备份。你可以将本地的提交推送到远程仓库，其他开发者也可以从远程仓库拉取代码。

git的安装

官方网站：https://git-scm.com/

点击下载：

找到对应电脑系统的网址：

配置选择，基本上一直下一步即可：

配置git环境：git config --global

初次使用git需要设置你的用户名以及邮箱，这将作为当前机器git的标识，如果你用它来下载远程仓库一些需要登录权限的仓库会要求登录，git默认使用配置邮箱以及用户名登入，但会要求你手动输入密码

git config --global user.name "你的用户名"
git config --global user.email "你的邮箱"

git的基本使用

新建目录

新建一个目录，作为要管理的库。该目录下可以存放要管理的文档、项目等。以下图为例，在某目录下创建了一个MyProject的文件夹，
双击进入该文件夹后，右键菜单选择Git Bash Here。

输入git stash查看状态，显示并没有将该目录初始成一个仓库，所以git此时是对他是无法进行管理的。

初始化仓库（repository）

git初始化仓库命令

git init

初始化的结果如下：

从上图的初始化可以看出：

• 已经被初始化成一个空的仓库，也说明此时可以进行git版本控制管理
• （master） 就是我们当前初始化的仓库是主分支,也是当前所处分支的状态

初始化成功之后，在项目文件夹下会多了一个.git 文件夹，（如果没有显示，是因为该文件为隐藏文件）。
之后所有的版本都会放到.git文件夹中，第一次提交commit会将所有文件都放进来，之后每一次commit只把修改的内容保存进来。

添加到暂存区

现在E:\00\MyProject\ 目录下创建一个git_test.py 文件

通过命令查看当前管理文件的状态

git status

查看结果显示如下图：

从上面显示的可以看出，此时主分支还没有任何提交（commit），untracked file就是未被跟踪 / 追踪的文件，下面蓝框中的git_test.py显示为红色 说明该文件还没有被git管理起来，下面给的提示是可以用git add 进行追踪管理。

git status有三种状态：

红色：修改、创建、删除都是显示红色
绿色：git add 添加之后变成绿色
白色：git commit提交之后变成白色

添加要管理的文件，命令：

git add <file>

用命令git add将文件添加到暂存区：之后用git status查看状态，此时git_test.py文件显示为绿色。

新增/修改/删除 文件状态会改变

在git_test.py 文件中添加一行文字如下，然后再使用git status查看添加文字之后的状态。

如果修改了之前已经添加或者提交的文件，它又会变成红色，还需要使用git add 添加。

如果有多个文件都被修改了，可以有多种方法将这些文件进行添加。

git add file1  file2 ... 

git add . 
# 这个点表示，把当前文件夹下所有的文件（会递归的把每一个子文件夹下的文件也同样管理起来）都添加管理

# 可以结合通配符使用
git add *.py

提交到仓库

将暂存区所添加的改动 提交到仓库

git commit -m "message"

-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

执行命令：`git commit -m “第一次提交到仓库” ，此时就已经把所有的文件都提交到了仓库中，显示信息如下：

• 在主分支上的第一次提交（带有注释信息）
• 有一个文件被修改（是一行内容插入），就是git_test.py文件
• commit提交之后信息中git_test.py文件变成白色 此时说明提交成功

查看提交（commit）的历史记录

git log

# 查看历史的所有提交记录
git reflog

显示每次提交的提交哈希值、提交信息和时间：

git其他命令

版本回滚

将提交到仓库的代码进行版本回滚，命令：

git reset 回退版本号

• soft：回退到某一版本，保留工作区和暂存区的所有修改内容。
• had：回退到某一版本，丢弃工作区和暂存区的所有修改内容。
• mixed：是git的默认参数，保留工作区的所有修改内容，丢弃暂存区的所有修改内容。

案例：使用默认参数 mixed

假设现在已经有了三次提交记录，每次提交一个txt文件。

使用git rest HEAD^ 或者使用 git rest 5af90b8 进行版本回退，表示回退到上一个版本。

通过命令 git log查看记录发现，已经回退到上一个版本了。


查看工作区 发现还存在着三个文件，利用git ls-files查看暂存区发现 暂存区中只有两个文件，表示版本已经回退成功。

查看差异

git diff [参数1] [参数2]

可以查看 工作区、暂存区、仓库之间的差异，也可以用来查看同一文件在不同版本之间的差异。平时开发时会使用一些图形化的界面来查看差异。
不加任何参数的情况下，默认比较工作区与暂存区之间的区别

案例：
假设有一个文件file3.txt 原本里面的内容是 “333”，现在将内容修改为"一键三连了吗？"
输入git diff命令查看差异

第一行提示了，发生变更的文件。下方则是修改的内容，红色表示删除的内容、绿色是新增的内容。

版本库中删除文件

方式一：在工作区中删除文件，随后git add所删除的文件，最后git commit提交。

方式二：使用命令

git rm 文件名

使用该命令后，工作区、暂存区的文件会被删除，随后我们需要进行一次提交（git commit），这样仓库中的文件也会删除完毕。

.gitignore忽略文件

这个文件的作用是可以让我们忽略掉一些不应该被加入到版本库中的文件，这样可以让我们的仓库体积更小，更加干净。

在工作目录下新建一个.gitignore文件，在里面写入要忽略的文件（也可以配合通配符进行书写），git就会忽略与其中内容匹配的文件，不对这些文件进行版本管理。

注：如果文件已经被git所管理了，再将该文件写入到.gitignore中，git不会忽略该文件，仍然会对该文件进行管理。

远程仓库的使用

远程仓库常见的有github、gitee、gitlab，以github为例。

注册github账号

打开网站：https://github.com/

点击右上角的 Sign up 按钮

输入邮箱、密码、用户名、是否接收推送，随后做一个简单的验证，输入邮箱所接收到的验证码，随后选择开发团队等 即可完成注册。

github上创建仓库

readme文件是github上的md文件，用来显示项目简介的。

创建完成之后就是这个样子的，什么也没有，只有一个readme文件

SSH配置克隆仓库

SSH配置

在用户根目录下，进到.ssh目录，使用命令

ssh-keygen -t rsa -b 4096
# 输入密钥文件名，随后按回车。
# 如果之前未配置过， 可不输入密钥文件名 直接回车，会自动生成id_rsa的密钥文件

随后输入私钥密码（可选，增加安全性）

查看该目录下的id_ras.pub，并将其中的内容复制。回到github页面，点击个人头像，点击settings。

选择左侧的SSH andGPG keys选项卡，点击New SSH key

Title可以随便输入

克隆仓库

在github上找到一个项目的SSH链接

在本地电脑 某一个目录中使用 git clone命令，随后该项目的文件就被克隆到本地仓库了。

git clone 克隆地址

拉取与推送

假设所克隆的仓库发生了更新，我们需要同步更新，则要拉取所更新的内容

git pull <remote> <branch>

如果本地对所克隆的项目进行了修改，想要上传到远程仓库。

• 执行 git add 将工作区所修改的文件提交到暂存区
• git commit -m “message” 将暂存区添加到本地库
• git push origin 推送到远程仓库

github将本地仓库关联到远程仓库：git remote add origin

假如，我们本地有一个仓库，远程仓库中没有内容，想把它推送到远程上去。使用git remote add origin命令。

首先选找到github生成的远程仓库链接

然后关联

git remote add origin git@github.com:beiszhihao/test.git

然后使用git push推送到远程

git push -u origin master

push：将本地仓库与远程仓库合并
-u：将本地仓库分支与远程仓库分支一起合并，就是说将master的分支也提交上去，这样你就可以在远程仓库上看到你在本地仓库的master中创建了多少分支，不加这个参数只将当前的master与远程的合并，没有分支的历史记录，也不能切换分支
origin：远程仓库的意思，如果这个仓库是远程的那么必须使用这个选项
master：提交本地matser分支仓库

分支

• 适合团队协作和开发管理
• 同时并进行多个功能开发，提高了开发效率
• 各个分支再开发过程中，如果某个分支开发失败，不会对其他分支有任何影响，失败的分支删除重新开始即可
  （如下图所示，项目中有一条主分支main，所有的文件都在该分支上。main分支一般为稳定的上线运行版。现在需要开发一个新功能Feature 1，那么开发人员就在main分支的基础上创建一条分支Feature 1，与main分支中文件完全相同。在开发完毕后，在合并到main分支上。）

创建分支

要完成开发新功能，维修BUG等任务，不会直接在main分支上进行修改。会新建一个分支修改代码

git branch 分支名
# 根据对当前选定分支创建分支

查看分支

查看所有的分支，一个项目初始化时会默认创建main(master)分支

git branch

切换分支

要在不同的分支之间完成不同的任务，或要进行合并等操作，需要切换到不同的分支进行工作。

git checkout 分支名

git switch 分支名

删除分支

一般在开发完毕、并已经合并推送后，会删除已完成任务的分支。

git branch -D 分支名

# 删除远程仓库中的分支
git push origin --delete 远程分支名

合并分支

在完成功能开发后，要将修改的内容合并到原来的基础之上，一般是将feature分支 合并到 dev分支上。

# 把指定的分支合并到当前分支上
git merge 需要合并的分支名  

如下图，图中的main和dev仅作参考。一般是在dev分支上，创建feature分支进行工作。在图中main:3的基础上创建分支，
随后开发dev分支。开发完毕后，合并回main分支。

合并冲突

如果两个分支修改了同一文件中的同一部分，Git就不知道要保留哪个分支中的内容，冲突也就发生了。

方式一：通过手动合并文件中的内容，相当于人为手动的决定了哪些内需要保留，冲突也就解决了。

方式二：利用rebase命令

# 格式
git rebase 分支名

已下图为例，这是一开始的情况，dev分支是以main:3这个节点为基础创建的分支。但之后，有人合并且提交了main:4、main:5。
而且这两个改动还对相同文件中的相同部分进行了修改，所以和dev分支发生了冲突。那么

# 以main:3为基点开发
git pull origin main # 从远程仓库拉取最新main分支、拉取到了新改动main:4、main:5
# git merge main 发现发生了冲突
git switch dev # 切换到dev分支
git rebase main # 将dev变基为main

**变基之后：**如下图所示，变基之后，相当于dev分支已main:5为基础创造了一个分支。相当于改变了创建分支时的基点，在最新版本的main:5上进行修改内容，随后进行内容合并，最后解决冲突。

merge和rebase的优缺点（重要）

让我们举一个例子，如果我们有一个项目在master分支上有3个commit作为commit1、2、3,而feature分支commit作为commit A
和B。如果我们执行git merge操作，则commit A和B将作为commit4合并到master分支中。其中分支上commit的日志是完整的。

优势：

• 日志非常详尽，可以帮助理解每次merge发生的方式和时间的完整历史。
• 发现错误并解决它们很容易。
  缺点
• 导致笨拙的日志/历史记录
• 不是很人性化

Git Rebase 这种技术中，日志在merge之后被修改。
让我们举一个例子，如果我们有一个项目在master分支上有3个commit作为commit1、2、3。而feature分支commit作为commitA和B。如果我们执行git rebase操作，则commit A和B将作为commit4和5重新基于master分支，并且将没有feature分支的日志。

缺点：无法跟踪在目标分支上合并commit的时间和方式

提交合并

在分支上开发时，可能在本分支中进行多次提交。与此同时，其他人也会在其他分支进行开发。
此时，如果合并代码，不同分支不同的commit记录会犬牙交错在一起。
再或者由于某些原因，导致需要代码回滚，由于commit记录太复杂，无法准确回退到指定版本。

此时，如果能够把我们在同一分支的commit合并为一个commit，然后merge到目标分支，事情将会变得简单起来。

使用以下命令，可以将一个分支中的多次提交合并成一次提交，最终合并到目标分支上就只会呈现一次conmmit。

git merge --squash

GitHub工作流（多人协作，仅作参考）

1. git clone 将项目克隆到本地仓库（假设该项目中有main、dev分支，main是稳定上线版代码，dev开发分支）
2. git switch dev 然后根据 dev 分支新建 my_feature分支 用于开发
3. 在my_feature上修改好代码 添加到暂存区 并提交（可能会有多次提交）
4. 将这个my_feature推送到远程仓库 git push origin my_feature
5. 假设在开发期间 远程仓库中的dev分支发生了更新 我们切换到本地的dev分支 使用git pull origin dev拉取更新
6. 为了同步dev上的更新，切换到my_feature分支 并 git rebase dev，切换基点。相当于my_feature的功能基于新的dev分支开发，如果发生冲突需手动解决。
7. 随后再将本地的my_feature推送到远程仓库上 git push -f origin my_feature
8. 随后就需要将远程仓库中的 my_feature合并到dev分支上 也就是要进行 pull request
   dev分支、以及main 是属于项目的，并不属于个人。合并一般由项目负责人进行，如下图 如何在github上创建pull request

回到github的项目主页，可以看到刚才提交的记录（图中内容仅为演示，可以理解为 我们提交了my_feature分支到项目）。接下来，点击箭头所指的Pull Requests选项。

点击箭头所指的New pull request按钮

接下来，点击Creat pull request即可提交成功。（本地自己提交代码所在的分支为my_feature，共享分支为dev分支）

9. 代码改动完毕，远程仓库上的my_feature分支。在合并完毕后需要删除，可能由项目负责人进行。我们删除本地的my_feature分支即可。
10. 拉取最新的main、dev分支，准备进行下一次的开发。

在IDE中使用git (工作使用更多，图像化界面更直观，由于IDE众多，不作演示)

可以通过一些IDE中使用git，并通过鼠标点击等进行操作，而不是使用git bash命令行的方式。

Git 命令大全

https://blog.csdn.net/XH_jing/article/details/121900458

参考目录

https://www.bilibili.com/video/BV1HM411377j
https://www.bilibili.com/video/BV19e4y1q7JJ
https://www.bilibili.com/video/BV1MU4y1Y7h5
https://www.bilibili.com/video/BV1FE411P7B3
https://www.bilibili.com/video/BV1ai4y1M7FN
https://www.bilibili.com/video/BV1oKXhY9E6z
https://blog.csdn.net/2401_88244350/article/details/143321853
https://blog.csdn.net/bjbz_cxy/article/details/116703787
https://blog.csdn.net/dont_curry/article/details/134832710
https://blog.csdn.net/feverfew1/article/details/135441302