版本控制工具 之 Git

目录

一、版本控制

1. 概念

2. 功能

01 - 不同版本的存储管理

02 - 重大版本的备份维护

03 - 恢复之前的项目版本

04 - 记录项目的点点滴滴

05 - 多人开发的代码合并

3. 历史

01 - 版本控制的史前时代（没有版本控制）

02 - CVS（Concurrent Versions System）

03 - SVN（Subversion）

04 - Git（Linus的作品）

4. 集中式版本控制

01 - 概念

02 - 优点

03 - 缺点 

5. 分布式版本控制

二、准备 Git

1. 安装

2. Bash – CMD – GUI 区别

3. Git 的配置分类

01 - 仓库的通用配置

02 - 针对当前用户，所有的仓库生效

03 - 针对该仓库

4. Git 的配置选项

01 - 设置用户名

02 - 设置邮箱 

03 - 检测配置信息

5. Git的别名（alias）

三、Git 操作本地仓库

1. 获取Git仓库

01 - 初始化Git仓库

02 - Git拉取远程仓库

2. 文件的状态划分

3. git status

4. git add

5. git commit 

6. git merge 

7. git log 

8. git reflog 

9. git reset

10. Git 的忽略文件 GitHub - github/gitignore

​11. git 底层原理

四、Git 远程仓库和本地仓库建立联系 

1. 概念

2. 本地无仓库，远程有仓库

01 - 远程仓库的验证 – 凭证

        拉取代码

        输入账号密码

        提交代码

        删除凭证

                windows

                mac 

02 - 远程仓库的验证 – SSH密钥

        one 生成公钥和私钥 生成/添加SSH公钥 - Gitee.com

        two 拿到公钥

        three 把公钥放置在服务器中

        fore拉取代码

3. 本地有仓库，和远程仓库建立连接  

01 - 添加远程地址

02 - 建立连接 ( 重要 )

        本地有分支，远程有分支

        本地有分支，远程没分支

03 - 查看远程仓库地址

04 - 重命名远程仓库别名

05 - 移除远程地址

五、Git 操作远程仓库

1. git clone

2. git push 

3. git fetch

4. git merge

5. git pull

六、git tag

1. 创建标签

01 - 轻量标签

02 - 附注标签

2. 查看标签 

3. 把打的标签推送到远程仓库中

4. 删除本地tag

5. 删除远程tag

6. 检出tag，回退到打tag的版本

七、git 分支

1. 创建分支 

2. 查看分支

3. 切换分支 

4. 分支所在HEAD 

5. 创建分支并同时切换

6. 在分支上提交图解

01 - 初始状态在master上提交

02 - 创建新分支testing，并在新分支上继续提交 

03 - 切换回master分支上，并继续提交

04 - 在master分支上创建新分支dev，并继续提交

7. 分支的开发与合并

01 - 遇到线上bug

02 - 解决完后合并hotfix分支

8. 删除分支

9. 修改分支名称

10. git merge 

八、git rebase

1. 使用了merge

2. 使用了rebase

3. 原理 

4. rebase和merge的选择

九、总结操作

十、Git常见命令速查表 

---

一、版本控制

1. 概念

• 版本控制的英文是 Version control
• 是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程
• 版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程序文件都得到同步

版本控制在软件开发中，可以帮助程序员进行代码的追踪、维护、控制等等一系列的操作

2. 功能

01 - 不同版本的存储管理

• 一个项目会不断进行版本的迭代，来修复之前的一些问题、增加新的功能、需求，甚至包括项目的重构
• 如果我们通过手动来维护一系列的项目备份，简直是一场噩梦

02 - 重大版本的备份维护

• 对于很多重大的版本，我们会进行备份管理

03 - 恢复之前的项目版本

• 当我们开发过程中发生一些严重的问题时，想要恢复之前的操作或者回到之前某个版本

04 - 记录项目的点点滴滴

• 如果我们每一个功能的修改、bug的修复、新的需求更改都需要记录下来，版本控制可以很好的解决

05 - 多人开发的代码合并

• 项目中通常都是多人开发，将多人代码进行合并，并且在出现冲突时更好的进行处理

3. 历史

01 - 版本控制的史前时代（没有版本控制）

• 人们通常通过文件备份的方式来进行管理，再通过diff命令来对比两个文件的差异

02 - CVS（Concurrent Versions System）

• 第一个被大规模使用的版本控制工具，诞生于1985年

• 由荷兰阿姆斯特丹VU大学的Dick Grune教授实现的，也算是SVN的前身（SVN的出现就是为了取代CVS的）

03 - SVN（Subversion）

• 因其命令行工具名为svn因此通常被简称为SVN
• SVN由CollabNet公司于2000年资助并发起开发，目的是取代CVS，对CVS进行了很多的优化
• SVN和CVS一样，也属于集中式版本控制工具
• SVN在早期公司开发中使用率非常高，但是目前已经被Git取代

04 - Git（Linus的作品）

• 早期的时候，Linux社区使用的是BitKeeper来进行版本控制
• 但是因为一些原因，BitKeeper想要收回对Linux社区的免费授权
• 于是Linus用了大概一周的时间，开发了Git用来取代BitKeeper
• Linus完成了Git的核心设计，在之后Linus功成身退，将Git交由另外一个Git的主要贡献者Junio C Hamano来维护

4. 集中式版本控制

01 - 概念

• CVS和SVN都是是属于集中式版本控制系统（Centralized Version Control Systems，简称 CVCS）
• 它们的主要特点是单一的集中管理的服务器，保存所有文件的修订版本
• 协同开发人员通过客户端连接到这台服务器，取出最新的文件或者提交更新

02 - 优点

相较于老式的本地 管理来说，每个人都可以在一定程度上看到项目中的 其他人正在做些什么

03 - 缺点 

是集中式版本控制有一个核心的问题：中央服务 器不能出现故障

• 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作
• 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据

5. 分布式版本控制

Git是属于分布式版本控制系统（Distributed Version Control System，简 称 DVCS）

• 客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录
• 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复
• 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份

集中式版本控制 : 将仓库放到服务器，一旦服务器崩溃可能会导致代码及记录都消失

分布式版本控制 : 通过git clone把仓库完全镜像到本地，就算服务器出现问题也没有关系，记录和代码会在本地仓库保存一份，提交到远程仓库时会进行同步刷新

二、准备 Git

1. 安装

git : Git - Downloads

2. Bash – CMD – GUI 区别

• Bash，Unix shell 的一种，Linux 与 Mac OS X 都将它作为默认 shel
  • Git Bash 就是一个 shell，是 Windows 下的命令行工具，可以执行 Linux 命令
  • Git Bash 是基于 CMD 的，在 CMD 的基础上增添一些新的命令与功能
  • 所以建议在使用的时候，用 Bash 更加方便
• Git CMD
  • 命令行提示符（CMD）是 Windows 操作系统上的命令行解释程序
  • 当你在 Windows 上安装 git 并且习惯使用命令行时，可以使用 cmd 来运行 git 命令
• Git GUI
  • 基本上针对那些不喜欢黑屏（即命令行）编码的人
  • 它提供了一个图形用户界面来运行 git 命令

3. Git 的配置分类

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量

01 - 仓库的通用配置

地址 : /etc/gitconfig  =>  包含系统上每一个用户及他们仓库的通用配置

• 如果在执行 git config 时带上 --system 选项，那么它就会读写该文件中的配置变量
• 由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它
• 开发中通常不修改

02 - 针对当前用户，所有的仓库生效

地址 : ~/.gitconfig  =>  只针对当前用户

• 可以传递 --global 选项让 Git 读写此文件，这会对你系统上所有的仓库生效

03 - 针对该仓库

地址 : 当前使用仓库的 Git 目录中的 config 文件，即.git/config  =>  针对该仓库

• 可以传递 --local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它

4. Git 的配置选项

设置Git的 用户名和邮件地址

01 - 设置用户名

git config --global user.name 'coderstar'

02 - 设置邮箱 

git config --global user.email'[email protected]'

03 - 检测配置信息

git config --list

5. Git的别名（alias）

如果不想每次都输入完整的 Git 命令

可以通过 git config 文件来轻松地为每一个命令设置一个别名

命令        : git checkout

设置别名 : git config --global alias.co checkout

使用        : git co

三、Git 操作本地仓库

1. 获取Git仓库

需要一个Git来管理源代码，本地也需要有一个Git仓库

通常有两种获取 Git 项目仓库的方式：

• 方式一：初始化一个Git仓库，并且可以将当前项目的文件都添加到Git仓库中（目前很多的脚手架在创建项目时都会默认创建一个Git仓库）
• 方式二：从其它服务器 克隆（clone） 一个已存在的 Git 仓库（第一天到公司通常我们需要做这个操作） 

01 - 初始化Git仓库

git init

• 该命令将创建一个名为 .git 的子目录，这个子目录含有你初始化的 Git 仓库中所有的必须文件，这些文件是 Git 仓库的核心
• 但是，在这个时候，我们仅仅是做了一个初始化的操作，你的项目里的文件还没有被跟踪 

02 - Git拉取远程仓库

git clone 地址

2. 文件的状态划分

需要对文件来划分不同的状态，以确定这个文件是否已经归于Git仓库的管理：

• 未跟踪：默认情况下，Git仓库下的文件没有添加到Git仓库管理中，需要通过add命令来操作
• 已跟踪：添加到Git仓库管理的文件处于已跟踪状态，Git可以对其进行各种跟踪管理

通过使用 ( git add . ) 命令，可以使得文件被git跟踪，文件状态变为暂缓区

 

ps : 但是此时的文件并没有和commit对象建立联系，git log查看不到更改的记录

已跟踪的文件又可以进行细分状态划分：

• staged：暂缓区中的文件状态
• Unmodified：commit命令，可以将staged中文件提交到Git仓库

• Modified：修改了某个文件后，会处于Modified状态

不管是新增的文件、修改的文件，都需重新让 add && commit   

3. git status

git status  =>  检测文件的状态

 

git status -s  ||  git status --short  =>  文件状态的简洁信息

4. git add

git add  =>  文件添加到暂存区

 

git add 文件  =>  跟踪新文件,并将其加入到暂存区

git add .  =>  将所有文件加入到暂存区

5. git commit 

git commit  =>  文件更新提交，将暂存区的文件提交，和commit对象联系在一起

 

git commit –m "提交信息"  =>  提交文件，并写上记录

git commit --no-verify -m "XXX"  =>  忽略提交限制，一般eslint有

 

git commit -a -m "haha"  =>  相当于 git add.  ->  git commit -m 'haha' 的简写

6. git merge 

git merge  =>  合并两分支代码  =>  git merge xxx分支名称

 

git merge dev --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并，可加 )

7. git log 

git log  =>  查看一下所有的历史提交记录

 

git log  =>  详细记录

git log --oneline => 好看一点的记录

git log --pretty=oneline  =>  更好看一点的记录

git log --pretty=oneline --graph  =>  可以看到多分支的记录

ps : 空格继续看记录，q是退出键 

8. git reflog 

git reflog  =>  不仅可以查看历史提交记录，而且切换版本的记录也会留下来

9. git reset

git reset  =>  版本回退

Git通过HEAD指针记录当前版本 :

• HEAD 是当前分支引用的指针，它总是指向该分支上的最后一次提交
• 理解 HEAD 的最简方式，就是将它看做 该分支上的最后一次提交 的快照 
• 切换版本就是在改HEAD的指向

可以通过HEAD来改变Git目前的版本指向( 切换版本 )

• 上一个版本就是HEAD^，上上一个版本就是HEAD^^  =>  git reset --hard HEAD^
• 如果是上1000个版本，可以使用HEAD~1000  =>  git reset --hard HEAD~1000
• 指定版本切换 通过git log 的 commit id  =>  git reset --hard 2d44982

10. Git 的忽略文件 GitHub - github/gitignore

新建.gitignore文件  =>  有些文件无需纳入Git 的管理，不需增加到缓存区

• 包括一些不需要提交的文件、文件夹
• 包括本地环境变量文件
• 包括一些日志文件
• 包括一些编辑器自动生成的文件

例如 vue 项目的.gitignore文件

​11. git 底层原理

在进行提交操作时，Git 会保存一个提交对象（commit object）

• 该提交对象会包含一个指向暂存内容快照的指针
• 该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针
• 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象
• 而由多个分支合并产生的提交对象有多个父对象

四、Git 远程仓库和本地仓库建立联系 

1. 概念

项目通常是多人开发的，所以会将本地仓库中管理的代码共享到远程仓库中

• 远程仓库通常是搭建在某一个服务器上的（当然本地也可以，但是本地很难共享）
• 使用第三方的Git服务器：比如GitHub、Gitee、Gitlab等等
• 在自己服务器搭建一个Git服务 ( 可以使用Gitlab软件搭建一个git服务器 ) 

常见的远程仓库 ：

• GitHub : GitHub: Where the world builds software · GitHub
• Gitee : Gitee - 基于 Git 的代码托管和研发协作平台
• 自己搭建Gitlab

不管是用哪个仓库，验证的方式都基本一样，这里使用gitee为例 

2. 本地无仓库，远程有仓库

对于私有的仓库需要进行验证 

 

ps : 如果git bash中拉取不下来，记得在cmd环境中再试试

目前Git服务器验证手段主要有两种 : 

• 方式一：基于HTTP的凭证存储（Credential Storage）
• 方式二：基于SSH的密钥 

01 - 远程仓库的验证 – 凭证

        拉取代码

拉取 : 测试仓库    =>    git clone 地址 

 

ps : 一旦拉取仓库下来成功，就已经和远程仓库建立起了连接，可直接进行git操作

        输入账号密码

        提交代码

   git add .           =>           git commit -m 'change'           =>           git push   

        删除凭证

                windows

                mac 

在系统用户的钥匙串中（加密的），删除即可 

02 - 远程仓库的验证 – SSH密钥

Secure Shell（安全外壳协议，简称SSH）是一种加密的网络传输协议，可在不安全的网络中为网络服务提供安全的传输环境。

SSH以非对称加密实现身份验证

• 例如其中一种方法是使用自动生成的公钥-私钥对来简单地加密网络连接，随后使用密码认证进行登录
• 另一种方法是人工生成一对公钥和私钥，通过生成的密钥进行认证，这样就可以在不输入密码的情况下登录
  • 公钥需要放在待访问的电脑之中，而对应的私钥需要由用户自行保管

0. 步骤

1. 用户在命令行输入命令，会生成公钥和私钥

2. 把公钥放在远程仓库中

        one 生成公钥和私钥 生成/添加SSH公钥 - Gitee.com

ssh-keygen -t ed25519 -C “your email"

        two 拿到公钥

 .pub文件中的内容就是公钥，复制下来即可

        three 把公钥放置在服务器中

        fore拉取代码

git clone 地址

 

ps : 一旦拉取仓库下来成功，就已经和远程仓库建立起了连接，可直接进行git操作

3. 本地有仓库，和远程仓库建立连接  

ps : 如果git bash中拉取不下来，记得在cmd环境中再试试

01 - 添加远程地址

添加远程地址：添加远程服务器（让本地的仓库和远程服务器仓库建立连接）

git remote add 远程仓库别名( 默认是origin ) 远程仓库地址

地址为HTTPS

验证方式则为 用户名 + 密码 > git remote add origin https://gitt.com

 

地址为SSH

验证方式则需配公钥和私钥 > git remote add origin [email protected]

 

ps : 一个本地仓库可以和多个远程仓库建立连接

02 - 建立连接 ( 重要 )

origin => 远程仓库名称，一个本地仓库可以和多个远程仓库连接，所以要指定是哪个

ps :

建议 远程仓库分支名字 和 本地仓库分支名 保持一样

否则拉取和推送时，可能需要多敲些许命令

0. 前提是拥有本地仓库 

 git init           =>          git add .          =>           git commit -m 'message'

1. 添加远程仓库地址

git remote add origin [email protected]

 

2. 触发输入账号密码 || 验证密钥，并拉取远程分支到本地

git pull

        本地有分支，远程有分支

3. 分支关联，建立跟踪分支 ( 上游分支 )   =>

=> git branch --set-upstream-to=远程仓库名字/远程分支的名字 本地分支的名字

git branch --set-upstream-to=origin/master master

4. 把远程仓库代码和本地代码合并  => git pull 远程仓库名字 远程仓库分支

git pull origin master --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并 )

5. 把代码推送到远程仓库中        ---     如果本地分支和远程分支名称不一样

git push                                     ----    git push 远程仓库名字 远程仓库分支

        本地有分支，远程没分支

3. 推送本地分支到远程，并建立远程跟踪分支   =>

=>  git push --set-upstream 远程仓库名字 远程分支

git push --set-upstream origin dev  ||  git push -u origin dev ( 简写 )

 

4. 若想要和远程的其他分支代码合并  =>  git merge 远程仓库名字/远程仓库分支 

git merge origin/master --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并，如果有关系可以不写 )

03 - 查看远程仓库地址

查看远程地址：比如上面从GitHub上clone下来的代码，它就是有自己的远程仓库的

 

git remote                =>        简洁信息

git remote –v           =>        详细信息

04 - 重命名远程仓库别名

git remote rename 原仓库名 新仓库名

git remote rename origin gitlab

05 - 移除远程地址

git remote remove 仓库名

git remote remove gitlab

五、Git 操作远程仓库

1. git clone

git clone 地址  =>  把远程仓库克隆到本地

2. git push 

git push  =>  将本地仓库的代码推送到远程仓库中

git push

git push -u 远程仓库名字 远程仓库分支

git push -u origin dev

3. git fetch

git fetch  =>  从远程仓库获取最新的代码

git fetch

git fetch 远程仓库名字 远程仓库分支

git fetch origin dev

4. git merge

git merge  =>  合并两分支代码 

git merge 

git merge 远程仓库名字 远程仓库分支 允许两毫不相干的分支合并 ( 看情况加 )

git merge origin dev --allow-unrelated-histories

5. git pull

git pull  =>  从远程仓库pull代码，拉取远程代码到本地，并且合并

git pull  =>  相当于 git fetch + git merge

git pull 远程仓库名字 远程分支 允许两毫不相干的分支合并 ( 看情况加 )

git pull origin master --allow-unrelated-histories

六、git tag

对于重大的版本我们常常会打上一个标签，以表示它的重要性

• Git 可以给仓库历史中的某一个提交打上标签
  • 提交之后再打标签
• 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）

1. 创建标签

01 - 轻量标签

创建tag标签 : git tag 标签名 (xxx版本号) 

git tag v1.0.0

02 - 附注标签

创建附注标签：通过-a选项，并且通过-m添加额外信息 => git tag -a 版本号 -m 信息

git tag -a v1.1.0 -m 'message，我干了什么'

2. 查看标签 

基本查看 : 只能看到打的版本信息

git tag

 

详细查看 : 可以看到附注标签写的内容以及更改的代码内容 => git show 版本号

git show v1.1.0

3. 把打的标签推送到远程仓库中

默认情况下，git push 命令  并不会  传送标签到远程仓库服务器上

推送指定tag到远程仓库中    =>    git push 远程仓库名 xxx版本号 

git push origin v1.0.0

 

推送全部tag到远程仓库中    =>    git push 远程仓库名 --tags

git push origin --tags

4. 删除本地tag

删除本地tag   =>   git tag -d 版本号

git tag -d v1.0.0

5. 删除远程tag

删除远程tag   =>   git push 远程仓库名 --delete 版本号

git push origin -d v1.0.0

6. 检出tag，回退到打tag的版本

回退到打tag的地方   =>   git checkout 版本号

git checkout v1.1.0

 

回退回来后，不要直接修改，若要修改，创建个新分支即可

git checkout -b '新分支名'

七、git 分支

Git 的分支，其实本质上仅仅是指向提交对象的可变指针

• Git 的默认分支名字是 master，在多次提交操作之后，其实已经有一个指向最后那个提交对象的 master 分支
• master 分支会在每次提交时自动移动

master分支

• Git 的 master 分支并不是一个特殊分支
• 它就跟其它分支完全没有区别
• 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它，并且大多数人都懒得去改动它

1. 创建分支 

Git 是怎么创建新分支的本质  =>  只是创建了一个可以移动的新的指针

 

创建分支  =>  git branch xxx分支名

git branch testing

2. 查看分支

查看当前所有的分支

git branch

同时查看最后一次提交

git branch –v

查看所有合并到当前分支的分支

git branch --merged

查看所有没有合并到当前分支的分支

git branch --no-merged

3. 切换分支 

切换分支  => git checkout xxx分支名

git checkout testing

4. 分支所在HEAD 

Git 通过一个名为 HEAD 的特殊指针 知道当前在哪一个分支上

5. 创建分支并同时切换

创建分支并同时切换  =>  git checkout -b 'xxx分支名'

git checkout -b testing

 

推送到远程仓库中  =>  git push -u 远程仓库名 远程分支

git push -u origin testing

或者

git push origin testing  +  git branch --set-upstream-to=origin/testing  testing 

6. 在分支上提交图解

01 - 初始状态在master上提交

02 - 创建新分支testing，并在新分支上继续提交 

03 - 切换回master分支上，并继续提交

04 - 在master分支上创建新分支dev，并继续提交

7. 分支的开发与合并

01 - 遇到线上bug

02 - 解决完后合并hotfix分支

8. 删除分支

删除远程分支             

git push -d origin 分支名

删除本地分支

git branch -d 分支名

9. 修改分支名称

修改本地分支名称

git branch -m 原分支名 新分支名

 

修改远程分支名称

1.删除远程分支             

   git push --delete origin 分支名

2.修改本地分支名称

   git branch -m 原分支名 新分支名

3.推送到远程仓库中

   git push -u origin 分支名

10. git merge 

git merge  =>  合并两分支代码  =>  git merge xxx分支名称 || git merge 远程仓库/远程分支

 

git merge dev --allow-unrelated-histories ( 该参数为了使得两毫不相干的分支合并，可加 )

八、git rebase

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase

1. 使用了merge

在master上直接使用merge

git merge experiment

2. 使用了rebase

在experiment上直接使用rebase

git rebase  master

 

再次执行master上的合并操作

git checkout master

git merge experiment

3. 原理 

rebase是如何工作的 : 

• 它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master） 的最近共同祖先 C2
• 然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件
• 然后将当前分支指向目标基底 C3
• 最后以此将之前另存为临时文件的修改依序应用

4. rebase和merge的选择

rebase和merge是对Git历史的不同处理方法：

• merge : 用于记录git的所有历史，那么分支的历史错综复杂，也全部记录下来
• rebase : 用于简化历史记录，将两个分支的历史简化，整个历史更加简洁

rebase有一条黄金法则：永远不要在主分支上使用rebase

• 如果在主分支上面使用rebase，会造成大量的提交历史在main分支中不同
• 而多人开发时，其他人依然在原来的main中，对于提交历史来说会有很大的变化 

九、总结操作

远程仓库有项目 ( 公司 )

0. git服务器验证，看上面文章内容 

1. 克隆项目到本地

git clone xxxxxxxx地址

2. 一般在master分支上创建自己的分支或者功能分支 dev-star

git checkout -b dev-star

3. 把创建好的分支推送到远程仓库，建立跟踪分支 dev-star

git push -u origin dev-star

4. 编写代码

阿巴阿巴阿巴阿巴阿巴

5. 把本地代码添加到暂存区

git add .

6. 把暂存区代码和commit对象关联，生成提交记录

git commit -m 'feat: messsage'

7. 从远程拉取最新代码到本地

git pull

8. 推送本地代码到远程仓库

git push

 

9. 合并代码到master分支上

    01 - 切换回主分支

    git checkout master 

 

    02 - 合并最新的master代码

    git pull

    03 - 自己的分支或者功能分支

    git merge dev-star 

    04 - 解决可能存在的冲突，提交合并的代码

    git commit -a -m ' '   =>   git push

十、Git常见命令速查表