软件设计

当前位置:首页>博客专栏>软件设计
全部 15 硬件设计 4 嵌入式系统 2 软件设计 4 Web建设与开发 4 C#入门到精通 0 人工智能 1

Git 极速入门

时间:2020-09-21   访问量:1079
文章内容

1. Git 基本概念

了解一门技术,最好的方式是从官方文档开始,Git 的官网:

https://git-scm.com/

1.1 Git 到底是什么?能为我们做什么呢?

官网的描述如下:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

我们简单翻译一下:

Git 是一个免费开源的分布式版本管理系统,可以高效快速地处理任何大小的项目。

Git 易于学习,占用空间小,性能极快。它与 Subversion、CVS、Perforce 和 ClearCase 等 SCM 工具具有廉价的本地分支、方便的暂存区和多个工作流等特性。

1.2 Git 核心概念

在这里插入图片描述

1.3 Git 与其他版本工具的区别

常见的版本工具如 SVN,它们为集中式版本管理,所有的提交必须使用网络,且所有的记录只会在最后提交记录一次 commit;另外由于集中式版本管理,天然安全性较弱,一旦服务器坏了,很容易造成团队无法写作。

Git 是分布式版本管理系统,本机拥有一份完整的版本管理,因此本地的每一次提交,都有完整的记录,方便后期维护、代码合并等,同时本地提交,可以不依赖网络,只有最后同步给“中央 Git 仓库”时,才会依赖网络;同时分布式一台计算机或服务器坏了,并没有太大影响,只需要同步其他服务器或计算机代码即可。

2. Git 安装与配置

2.1 安装

2.1.1 Windows 系统

下载地址:

https://git-scm.com/download/win

在这里插入图片描述

下载 exe 文件,一路默认即可安装。安装成功后,右击菜单,如果可以看到“Git GUI Here”和“Git Bash Here”,安装成功。

在这里插入图片描述

2.1.2 Mac 系统

下载地址:

https://git-scm.com/download/mac

在这里插入图片描述

安装方式有 2 种:

建议使用 homebrew 安装,如果没有安装 homebrew,安装国内 homebrew 安装。

/bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"

安装完成后,执行:

brew install git

2.2 配置

2.2.1 配置用户名

用于查看 Git 提交记录,方便查看谁操作的,可以随便设置,不建议随便设置。

git config --global user.name "yourname"
2.2.2 配置用户邮箱

用于查看 Git 提交记录,方便查看谁操作的,可以随便设置,不建议随便设置。

git config --global user.email "youremail@xxx.com"
2.2.3 设置 ssh-key

Git 服务器都会选择使用 SSH 公钥来进行授权。系统中的每个用户都必须提供一个公钥用于授权,没有的话就要生成一个。生成公钥的过程在所有操作系统上都差不多。你也可以先确认一下本机是否已经有一个公钥,路径详见 2.2.4 ssh-key 路径,如果有,可以不生成。后续 GitHub 和 Gitee 都会使用该公钥。

生成 SSH 公钥命令如下:

ssh-keygen -t rsa -C“youremail@xxx.com"

执行命令后需要进行 3 次或 4 次确认:

2.2.4 ssh-key 路径

Windows 默认 ssh-key 路径默认:C:/Users/用户名/.ssh。

Mac 默认 ssh-key 路径默认:/Users/用户名/.ssh。

3. 常见命令

提示:所有命令均可参考 git help 命令,本文仅仅针对常见命令介绍,如果需要更详细的可以参考官方文档或 git <command> --help

3.1 仓库相关

3.1.1 git clone

描述:git clone 命令,克隆远程仓库到本地,即获取远程仓库文件。

# 克隆远程仓库到本地,即获取远程仓库文件git clone <远程仓库地址>

举例,如下图:

在这里插入图片描述

执行后,本地会多出一个 my_demo 的文件夹,如下图,里面包含了所有文件。

在这里插入图片描述

后续 Git 相关操作需要切换到 my_demo 目录下(因为 .git 版本库管理的是 my_demo)。

3.1.2 git init

描述:初始化本地 Git 仓库,即将该目录交予 Git 管理,通常将项目使用 Git 管理时使用。

git init

操作如下,可以看到目录中通过 git init 可以创建 .git 版本库。

在这里插入图片描述

3.1.3 git remote

描述:远程仓库操作,可以对远程仓库进行关联、移除关联、更换远程仓库名字等。

# 添加远程仓库git remote add origin <远程仓库地址># 获取 git remote 其他命令及说明git remote --help

在这里插入图片描述

执行 git remote --help 如下图,按 Q 键退出。

在这里插入图片描述

可以按照 Git 的 help 文档进行操作。

3.2 提交相关

3.2.1 git add

描述:只有添加到版本库的文件,才由 Git 管理。

# 添加指定文件到版本库,此时添加到的是版本库中的暂存区git add <filepath># 添加所有文件到版本库git add .

常见操作,添加 a.txt 文件,并添加到版本库。

在这里插入图片描述

此时文件颜色为绿色,文件还在暂存区,如需添加到本地仓库,仍需使用 git commit 命令。

若没使用 git add 命令,当前文件没有交予 Git 管理,如下图,显示红色。

在这里插入图片描述

3.2.2 git commit
# 将暂存区的数据,提交到本地仓库git commit -m [描述信息] 
# git commit 和 git add 可以合并操作  使用 -am 命令# 注意:-am 时候要保证文件是修改操作,如果是新增的文件,仍需分开,否则无效git commit -am [描述信息]

具体操作如下:

在这里插入图片描述

3.2.3 git rm

描述:删除本地仓库中的文件,注意 git rm 无法删除暂存区、非版本库中的文件。

# 删除工作区文件git rm [file]

删除本地仓库文件 a.txt,如下图,可正常删除。

在这里插入图片描述

删除暂存区、非版本库中的文件 b.txt,如下图,均报错。

在这里插入图片描述

那么暂存区中的文件如何删除呢?下面我们看看 git reset 命令。

3.2.4 git reset

描述:git reset 可以将暂存区的文件回退到非版本库git reset 也可以将提交的 commit 进行回退到暂存区,或者强制回退到指定版本。

# 回退 commit,保留源码,默认方式,回退到非版本库。用于撤销前几次操作git reset --mixed HEAD^# 回退至 3 个版本,只回退 commit 信息,回退到暂存区。用于将前几次 commit 撤销git reset --soft HEAD~3# 彻底回退至某个版本,不保留代码。用于彻底回退,放弃后续修改的内容git reset --hard HEAD^

用 git reset --hard 举例,我们强制回退到上个版本。

在这里插入图片描述

3.2.5 git status

描述:查看本地仓库状态,显示变更的文件。

# 查看当前本地仓库状态git status# 查看指定分支的仓库状态git status -b <branch># 查看本地仓库状态,使用简短输出git status -s

举例,如下图:

在这里插入图片描述

3.2.6 git log

描述:查看提交记录。

# 查看提交记录git log# 查看提交记录,获取简短描述git log --oneline 
# 查看提交记录,可以显示分支的创建、合并信息git log --graph

举例,如下图:

在这里插入图片描述

3.2.7 git fetch

描述:从远程获取代码库,命令执行完后需要执行 git merge 远程分支到你所在的分支。

git fetch

举例,如下图:

在这里插入图片描述

此时发现,git fetch 并没有合并代码,我们再执行 git merge 命令。

在这里插入图片描述

此时,代码才合并到本地分支,git merge 后续 3.3.3 节会介绍,此命令用于分支之间合并。

3.2.8 git pull

描述:从远程获取代码并合并到本地分支,相当于 git fetch + git merge

# 下载远程代码并合并
git pull
git pull <remote> <branch>

操作如下图,如果远程分支没有更新,则显示“Already up to date”;有更新则显示哪些文件更新和更新信息。

在这里插入图片描述

3.2.9 git push

描述:将本地仓库代码,推送到远程仓库。

# 推送到远程git push# 推送到远程自定分支git push origin <branch>

举例,如下图:

在这里插入图片描述

3.3 分支相关

3.3.1 git branch

描述:进行分支管理。

# 查看当前分支,带有 * 的是当前分支git branch# 查看当前分支,并显示版本信息git branch -v# 查看所有分支,包含远程分支git branch -a# 创建分支git branch < newbranch ># 删除分支git branch -d < branch >

举例,如下图,带有 * 号的是当前分支。

在这里插入图片描述

3.3.2 git checkout

描述:切换分支。

# 切换分支git checkout < branch >

举例,如下图,可以看到 git checkout 正确的切换到想要的分支。

在这里插入图片描述

3.3.3 git merge

描述:合并分支内容。

# 合并指定分支的代码到当前分支git merge < branch >

如我们 dev 分支做了相关更新,通过 git merge 可以将相关更新合并到 master 分支,具体操作如下:

在这里插入图片描述

3.3.4 git stash

描述:主要用于暂存工作内容,并在后续恢复工作内容。

使用场景:如我们没注意分支,将代码开发在了 master 分支,现在需要将这部分代码放到 dev 分支,可以通过 git stash 处理。

# 工作内容暂存git stash# 恢复工作内容git stash pop

在这里插入图片描述

3.3.5 git tag

描述:像其他版本控制系统( VCS )一样,Git 可以给仓库历史中的某一个提交打上标签,以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点( v1.0、v2.0 等等)。

# 添加标签,-a 代表添加 说明,不加也可以 git tag -a < tagName ># 添加标签,-m 是给 -a 添加的说明,不加 -m 则 git 会给出弹框,让你填写,添加 -m 则不会弹出 git tag -a < tagName > -m < comment ># 删除标签git tag -d < tagName ># 查看标签git tag

在这里插入图片描述

3.4 文件冲突相关

3.4.1 git diff

描述:比较不同,注意没有执行 git add . 或 git add <filename>,无论工作区中的文件怎么变化 git diff 都是没有任何反应的。

#是工作区和暂存区的比较git diff 
#是暂存区和版本库的比较git diff --cached

在这里插入图片描述

3.4.2 冲突解决流程

构建冲突

在远程分支 master 将一个文件中的某一行进行修改,保存并提交 在本地分支 master 将同一个文件同一行内容进行修改,执行添加 & 提交。

执行 git pull 命令,显示如下:

在这里插入图片描述

查看冲突文件

冲突文件都会显示 CONFLICT。

我们查看 d.txt 文件,可以使用 git diff d.txt 或者文本编辑器查看。

在这里插入图片描述

可以看到冲突内容是由

<<<<<<< HEAD 与 ======= 包裹的地方,和
 ======= 与 >>>>>>> d1e12c98fbb5b91c8ba4a28049aa49c6813cc4fe 包裹的地方冲突

我们保留需要的,删除不需要,然后执行下述命令即可。

git add . 
git commit -m "fix conflict"git push

4. Git 常见的高级用法

4.1 git rebase

描述:git rebase 主要作用是让提交的分支树呈现简洁,线性的 commit 记录,那就采用 rebase,不然就使用 git merge

假设先都使用 git merge 进行代码合并,我们模拟 2 个用户提交,由于冲突与分支合并,导致分叉。

在这里插入图片描述

先基于 master 拉取 feature 分支,通过模拟 2 个用户操作,构建依赖冲突,并进行查看提交历史。

git log --oneline --graph

在这里插入图片描述

基于 rebase 将 feature 合并到 master 分支。

# 基于 master 版本,将后续提交全部合成一个提交git rebase master# 如果 git rebase 有冲突,需要先解决冲突,再执行下面两条命令,直到成功git add .
git rebase --continue

在这里插入图片描述

最后,合并 feature 到 master,如下图,查看提交记录,发现后续提交记录全部合并线性提交(注意执行 git rebase 后解决几次冲突,就会有几次线性提交 + 最后一次提交,如果无任何冲突,只有一个提交记录)。

在这里插入图片描述

4.2 git revert

描述:git revert 可以撤销指定的提交,主要用于不想回退全部代码,最大可能性减少工作量。

# 回退指定提交记录git revert <commitHash># 回退指定提交记录 --no-commit 不会自动提交成一条 commit 后续手动操作git revert --no-commit <commitHash># 回退多个提交记录git revert --no-commit <commitHash1> <commitHash2># 回退一定范围的提交记录,前开后闭(不包含 1,包含 N)git revert --no-commit <commitHash1>..<commitHashN># 手动提交git commit -a -m <描述>

举例,如下图,虽然有冲突,但可以看到撤销指定的提交已经成功。

在这里插入图片描述

4.3 git cherry-pick

描述:git cherry-pick 能够把另一个分支的一个或多个提交复制到当前分支,主要用于指定提交合并。

# 合并指定提交记录git cherry-pick <commitHash># 合并多个提交记录git cherry-pick <commitHash1> <commitHash1># 合并一定范围的提交记录,前开后闭(不包含 1,包含 N)git cherry-pick <commitHash1>..<commitHashN># 发生代码冲突,cherry pick 会停下来,需要解决玩冲突后,git add . 再执行 --continue 命令git cherry-pick --continue# 只更新工作区和暂存区,不产生新的提交,后面可以手动提交git cherry-pick --no-commit <commitHash>

如下图,合并指定提交记录。

在这里插入图片描述

4.4 gitignore 文件

描述:有时候我们希望某些文件和目录不被 Git 管理,Git 提供了 .gitignore 文件,可以配置忽略指定文件和目录。例如使用 IDEA 产生的 .iml 文件,maven 打包生成的 target 文件夹等。

4.4.1 .gitignore 文件目录
.gitignore 文件放到工作区,即和 .git 文件夹 同目录
4.4.2 .gitignore 使用

在工作区,新建 file.txt 文件,git status 查看当前工作区状态,发现 file.txt 文件被 Git 识别。

在这里插入图片描述

此时,在根目录下新建 .gitignore 文件,配置忽略 file.txt 文件。

在这里插入图片描述

此时 git status 查看工作区当前状态,发现文件 Git 已经忽略了 file.txt 文件;最后,将该文件提交到远程分支,保证所有使用者,都可以使用同一套配置文件。

4.4.3 .gitignore 语法
  1. 空行或是以 # 开头的行即注释行将被忽略

  2. 可以直接写文件名,表示忽略该文件

  3. 忽略文件的目录以当前路径开始,如 file.txt 或者 src/abc.txt

  4. 正斜杠 / 开头避免递归

  5. 后面加正斜杠 / 表示忽略文件夹,例如 target/ 即忽略 target 文件夹

  6. ! 来否定忽略,即比如在前面用了 *.properties,然后使用 !application.properties,则这个 application.properties 不会被忽略。

  7. * 用来匹配零个或多个字符,如 *.[oc] 忽略所有以 ".o" 或 ".c" 结尾

  8. [] 用来匹配括号内的任一字符,如 [abc],也可以在括号内加连接符,如 [0-9] 匹配 0 至 9 的数

  9. ? 用来匹配单个字符

举例:

*.txt# 但否定忽略 lib.txt,尽管已经在前面忽略了 .txt 文件!lib.txt# 仅在当前目录下忽略 a.jar 文件, 但不包括子目录下的  subdir/a.jar/a.jar# 忽略 build/ 文件夹下的所有文件build/#忽略 build 文件夹下的所有文件,但不包括 build 文件夹本身build/*# 忽略 doc/notes.txt, 不包括 doc/server/arch.txtdoc/*.txt# 忽略所有的 .pdf 文件 在 doc/ directory 下的doc/**/*.pdf

注意:.gitignore 只能忽略那些原来没有被 track 的文件,如果某些文件已经被纳入了版本管理中,则修改 .gitignore 是无效的。需要先删除缓存才可以。

4.5 gitmodules(git submodule)

描述:Git 子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中,同时还保持提交的独立。

优点:项目中如果经常使用别人维护的模块,在 Git 中使用子模块的功能能够大大提高开发效率。使用子模块后,不必负责子模块的维护,只需要在必要的时候同步更新子模块即可。

# 添加子模块,url 为子模块的路径,path 为该子模块存储的目录路径git submodule add <url> <path># 删除子模块,首先,要在“ .gitmodules ”文件中删除相应配置信息。然后,执行“ git rm –cached ”命令将子模块所在的文件从 git 中删除# git clone 时候,submodule 的内容并不会自动下载,需要执行下面命令git submodule update --init --recursive

4.6 githooks

描述:Git 可以在特定的动作发生时触发自定义脚本,这一类动作称作钩子;Git 钩子分为 Client-Side Hooks(客户端钩子)和 Server-Side Hooks (服务端钩子)两类。

作用:客户端钩子可以做代码提交时的代码扫描等给予客户端触发的;服务端钩子可以做一些 bug id 的校验等操作,避免代码提交问题追溯。

详细说明文档:

https://git-scm.com/book/zh/v2/自定义-Git-Git-钩子

Git hooks 通常放在 .git/hooks 目录中,如下图:

在这里插入图片描述

示例都是 shell 脚本,任何正确命名(按照官方要求的 hook 名称)的可执行脚本都可以正常使用,可以使用 Ruby 或 Python 等任何你熟悉的语言。 示例的名字都是以 .sample 结尾,如果想启用它们,得先移除这个后缀即可。把一个正确命名(不带扩展名)且可执行的文件放入 .git 目录下的 hooks 子目录中,即可激活该钩子脚本。

例如,新增一个自定义脚本 pre-commit,内容写入:

# !/bin/shecho "hello hooks"

执行提交的时候,发现 hook 已经生效,如下图,到此,一个简单的 hook 完成。

在这里插入图片描述

5. 常见 Git Web

5.1 使用 Github

5.1.1 注册&登录

GitHub 官网地址:https://github.com/

注册和登录按照步骤即可,本文不在介绍。

5.1.2 配置 ssh-key

登录后,点击右上角,选择 Settings,如下图:

在这里插入图片描述

选择 SSH and GPG keys -> New SSH key,根据第二部分“Git 安装与配置”中生成的 key,填写即可。

在这里插入图片描述

5.1.3 创建项目

右上角,选择 New repository,如下图:

在这里插入图片描述

按照要求设置即可,如下图:

在这里插入图片描述

此处我们选择私有仓库,点击“Create repository”,如下图,发现 GitHub 非常友好的列出了后续操作的方法。

在这里插入图片描述

5.1.4 初始化项目

由于我们目前还没创建本地仓库,所以选择第一条示例操作。

mkdir my_demo
cd my_demo
git init// 此处我们 copy 代码到 my_demo 目录中// 接下来执行git add .
git commit -m "add code"git branch -M master
git remote add origin git@github.com:xxxxxx/my_demo.git
git push -u origin master

此时我们看一下 github 远程仓库,代码已经传到远程仓库,后续操作与之前的操作无异,不在赘述。

在这里插入图片描述

5.2 使用 Gitee

说明:Gitee 操作基本与 Github 一致,下面简单描述一下。

5.2.1 注册&登录

按要求即可。

5.2.2 设置 ssh-key

登录后,右上角,点击用户,选择设置,找到 SSH 公钥,配置即可。

在这里插入图片描述

5.2.3 创建代码仓库

右上角,点击“+”选择新建仓库:

在这里插入图片描述

在这里插入图片描述

点击确定,即可。

5.2.4 上传代码

和 Github 1.4 节相同,完全一致,略。

6. Git 常见 GUI 工具

下面我们也介绍几个常见的 Git GUI 工具。

说明:建议使用 Git 命令行进行操作,方便快捷,只需要记住 git 关键命令即可。

6.1 GitHub for Desktop

GitHub for Desktop 是 为我们提供一个图形客户端,方便我们的操作 GitHub。

官网:https://desktop.github.com/

运行截图:

在这里插入图片描述

6.2 Source Tree

Sourcetree 简化了如何与 Git 存储库进行交互,这样您就可以集中精力编写代码。通过 Sourcetree 的简单 Git GUI 可视化和管理存储库。

官网地址:https://www.sourcetreeapp.com/

运行截图:

在这里插入图片描述

6.3 TortoiseGit

TortoiseGit 则受到 Windows 用户的一致推荐,并且它还是开源的。

官网地址:https://tortoisegit.org/

运行截图:

在这里插入图片描述

7. Git Flow

7.1 什么是 Git Flow

Git Flow 是规范化分支管理模型的一种方案。Vincent Driessen 曾经写过一篇博文,题为“A successful Git branching model”(一个成功的 Git 分支模型)。Git Flow 工作流程就是从这篇文章里来的。

7.2 常见 Git Flow 分支

7.3 Git Flow 操作流程

Vincent Driessen 提出的 Git Flow 流程图如下:

在这里插入图片描述

7.4 Git Flow 工具

如果理解上述的过程,可以完全不使用 Git Flow 工具。

下面简单介绍下 Git Flow 工具,可以约束使用 Git Flow 流程。

7.4.1 下载 Git Flow 工具

macOS 下载:

$ brew install git-flow-avh

Linux 下载:

$ apt-get install git-flow

Windows(Cygwin)下载:

$ wget -q -O - --no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash
7.4.2 常见操作命令

在这里插入图片描述

# 初始化 git-flowgit flow init# 基于 develop 分支的,开始开发新特性git flow feature start MYFEATURE# 发布新特性分支到远程服务器git flow feature publish MYFEATURE# 合并 MYFEATURE 分支到 develop,删除这个 MYFEATURE 分支,切换回 develop 分支git flow feature finish MYFEATURE# 从 MYFEATURE 远程分支拉取的变更git flow feature pull origin MYFEATURE# 从 develop 分支开始创建一个 release 分支,BASE 是 commit 记录git flow release start RELEASE [BASE]# 发布 release 分支到远程服务器git flow release publish RELEASE# 归并 release 分支到 master 分支,用 release 分支名打 Tag,归并 release 分支到 develop,移除 release 分支git flow release finish RELEASE# 开始 git flow 紧急修复,VERSION 参数标记着修正版本。[BASENAME] 为 finish release 时填写的版本号git flow hotfix start VERSION [BASENAME]# 代码归并回 develop 和 master 分支。相应地,master 分支打上修正版本的 TAG,TAG 为 hotfix 分支名git flow hotfix finish VERSION

7.5 Git Flow 是不是都适合?

如果团队很大,很多功能并行,那么 Git Flow 很合适你们团队,如果团队人间很少,完全没有必要使用 Git Flow,建议自己定义团队的分支管理流程,效率会更高。

写在最后:Git 仍有很多内容等着你来探索。


上一篇:正则表达式

下一篇:没有了!