Git概述：常用命令，工作流程，开发规范

Vstag

已于 2023-12-17 20:03:45 修改

阅读量1k

点赞数 26

文章标签： git github gitlab

于 2023-12-17 19:39:28 首次发布

本文链接：https://blog.csdn.net/weixin_73981108/article/details/135048699

版权

一、简介

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。它是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

Git工作流程

workspace：表示工作区
Index：表示暂存区
Repository：表示本地仓库
Remote：表示远程仓库

二、环境配置

要使用git，首先要下载git安装包：

官网地址：https://git-scm.com/

官网下载会比较慢，附上淘宝镜像地址：https://registry.npmmirror.com/binary.html?path=git-for-windows/
下载好安装包后，点击安装，安装选项一般保持默认即可
安装完成后在任意目录下右键，选择git bash here即可在此目录执行git命令

三、常用命令

命令	作用	说明
git -v	查看git版本
git init	初始化本地git仓库
git config --global user.name “用户名”	设置用户名
git config --global user.emal “电子邮件”	设置电子邮件
git add <文件名>	暂存工作区指定文件	工作区->暂存区
git add .	暂存工作区所有文件	工作区->暂存区
git commit -m ‘提交说明’	提交暂存区所有文件并产生版本记录	暂存区->本地仓库
git status	查看文件状态-详细信息
git status -s	查看文件状态-简略信息	第一列表示版本库与暂存区之间的比较状态；第二列表示暂存区与工作区之间的比较状态
git ls-files	查看暂存区文件列表
git restore <文件名>	从暂存区恢复指定文件到工作区
git restore .	从暂存区恢复所有文件到工作区
git rm --cached <文件名>	从暂存区移除指定文件	移除暂存区的指定文件后将不再跟踪工作区对应文件的变化
git log	查看提交记录-详细信息
git log --online	查看提交记录-简略信息	每列分别表示版本号，分支指针，提交说明
git reflog --online	查看完整历史-简历信息	包括提交，切换，回退等所有记录
git reset [–soft\|–mixed\|–hard] <版本号>	回退到指定版本	–soft模式保留暂存区和工作区原本内容；–hard模式不保留暂存区和工作区原本内容；–mixed模式不保留暂存区，保留工作区（默认）。
git branch <分支名>	创建分支	创建后并不会自动切换到新创建的分支，要手动切换
git branch	查看本地分支
git branch -d <分支名>	删除本地指定分支	一般在成功合并分支后使用
git branch -D <分支名>	删除本地指定分支-强制删除
git switch <分支名>	切换到指定分支
git checkout -b <分支名>	创建并切换到指定分支
git merge <分支名>	把指定分支合并到当前分支
git remote add <远程仓库别名> <远程仓库地址>	添加远程仓库地址	别名唯一，地址是以`.git`结尾的网址
git remote -v	查看远程仓库地址
git remote remove <远程仓库别名>	删除指定远程仓库地址
git clone <远程仓库地址>	克隆指定远程仓库内容到工作区	远程仓库->工作区。一般在未创建本地仓库时使用，克隆完成后想要获取远程仓库更新内容一般用pull
git pull [<远程仓库别名> <分支名>]	从远程仓库拉取内容到本地指定分支	远程仓库->工作区。可选内容为空时拉取与本地当前分支同名的远程分支（需先添加远程分支）
git pull --rebase [<远程仓库别名> <分支名>]	从远程仓库拉取并合并内容到本地指定分支	远程仓库->工作区
git push [<远程仓库别名> <分支名>]	从本地指定分支推送内容到指定远程分支	本地仓库->远程仓库。可选内容为空时推送本地当前分支到同名的远程分支（需先添加远程分支）

命令语法字符说明

[]：内的内容是可选的

{}：一组必须的项目，必须要在{a|b|c}内给出的选择里选一个

<>：表示必须被替换的占位

文件状态说明

' ' （空格）表示文件未发生更改
M 表示文件发生改动
A 表示新增文件
D 表示删除文件
R 表示重命名
C 表示复制
U 表示更新但未合并
? 表示未跟踪文件
! 表示忽略文件

未跟踪和忽略文件会显示相同的两列，如 ??。

四、忽略文件

在Git中，通过创建一个名为 .gitignore 的文件，可以指定哪些文件或目录应该被Git忽略。.gitignore 文件中列出的文件和目录将不会被Git跟踪，这对于避免将不必要的或敏感信息包含在版本库中非常有用。

以下是一些常见的应该被忽略的文件和目录：

操作系统生成的文件：

.DS_Store（MacOS 生成的文件）

Thumbs.db（Windows 生成的缩略图数据库文件）
编程语言和开发工具生成的文件：

编译输出目录，如 bin/、obj/、target/ 等

.class、.jar、.war 等 Java 编译输出文件

.pyc、.pyo 等 Python 编译输出文件

.dll、.exe 等编译生成的二进制文件

.log、.logs 等日志文件
临时文件和缓存文件：

*.log、*.log.* 等日志文件

*.tmp、*.swp、*~ 等临时文件
IDE和编辑器生成的文件：

.idea/、.vscode/ 等 IDE 配置目录

*.iml、*.ipr、*.iws 等 IDEA 工程文件

*.suo、*.user 等 Visual Studio 用户文件
敏感信息和配置文件：

.env、.env.local 等包含敏感信息的环境变量文件

*.key、*.pem、*.cer 等包含私密密钥的文件

config.ini、settings.xml、secrets.json 等配置文件
依赖管理和包管理：

node_modules/、bower_components/、vendor/ 等包含依赖库的目录
编译和构建配置文件：

build/、dist/、out/ 等构建输出目录

*.log、*.pid 等运行时文件

五、图形化界面

相比命令行操作，使用Git图形化工具可以更方便快捷地执行Git常用操作，同时，图形化界面的分支图也更为直观。

常用的Git图形化工具有：

Git GUI：安装Git时自带
Git Graph：VSCode的Git图形化插件（需自行安装）
IDEA自带的Git插件
GitHub Desktop
GitKraken
Source Tree

六、工作流程

在多组员，多项目等环境进行协同工作时，如果没有统一规范、统一流程，则会导致额外的工作量，甚至会做无用功。所以要减少版本冲突，减轻不必要的工作，就需要规范化的工作流程。因此，团队间选择合适的工作流程并遵守相应的规范和流程对提升开发效率显得尤为重要。

常用的Git工作流程有：

Git Flow
Github Flow
Gitlab Flow

以上Git工作流程应被视作为指导方针，而非“铁律”。只是想告诉你可能的做法。因此，如果有必要的话，你可以组合使用不同的流程。

分支命名规范

以Git Flow为例，以下是在工作流程中常用的分支命名及其说明：

main：主分支

也称为master分支，是在初始化仓库时自动创建的分支，存放项目的可用的稳定版本，只能从其他分支合并，不能直接修改；

只接受hotfix和release的合入；

每一次更新主分支，都需要在此分支上使用tag打上对应的版本号以对外发布项目。
release：预发布分支

命名规范：release/预发布版本号，如release/1.2.0

基于main创建的分支，存放项目的预发布版本。在此分支上，不能再添加新的功能，只能用于项目测试和bug修复；

只能拉取自develop，测试完成后合并回main和develop。
develop：开发分支

多人协作的开发分支，只能从其他分支合并，不能直接修改；

只接受feature和release的合入。
feature：功能开发分支

命名规范：feature/模块名-功能描述，如feature/login-checkPassword

基于develop创建的分支，用于开发新的功能。每个版本、每个人有自己独立的功能分支；

只能拉取自develop，在每个人的对应功能开发完成后合并回develop。
hotfix：热修复分支

命名规范：hotfix/bug描述或编号，如hotfix/nullPointer，hotfix/PROJ-123

基于main创建的分支，用于已发布版本的bug修复；

只能拉取自main的对应版本，bug修复完成后合并回main；

每次合并回main时记得用tag更新main的修订版本。

版本号命名规范

Git项目的版本号通常体现在main分支的tag上。常用的项目版本号采用主版本.次版本.修订版本的形式，如1.2.6，其每部分的含义如下：

主版本（Major Version）：主要的功能变化或重大更新；
次版本（Minor Version）：一些新的功能、改进和更新，通常不会影响现有功能；
修订版本（Patch Version）：一些小的bug修复，安全漏洞补丁等。通常不会更改现有功能和接口。

此外，在正式版本发布前，根据实际开发情况，也可在版本号前加上对应的开发周期，如alpha-0.4.12，RC-1.18.5。常用的开发周期及其含义如下：

develop（简称Dev）：也称为pre-alpha，指在项目进行正式测试之前执行的所有活动，这些活动包括需求分析、软件设计、软件开发和单元测试；
alpha：是软件测试的第一阶段，其功能亦未完善。此版本通常会送到开发软件的组织或某群体中的软件测试者作内部测试；
beta：是紧随alpha阶段之后的软件开发阶段，通常在软件已经具备全部功能的情况下开始beta阶段。此版本是项目最早对外公开的版本，由公众（通常为第三方开发者和业余玩家）参与测试。与完整的软件相比，处于beta阶段的软件通常会有更多的错误性能问题，并且仍可能导致崩溃或数据丢失。beta测试的重点是减少对用户的影响，通常包括可用性测试；
release（简称RC）：是具备成为稳定产品的潜力的beta版本，除非出现重大错误，否则准备好发布。当开发团队同意不会再添加全新的源代码时，发行版被称为代码完成。仍然可能会对代码进行修改以修复缺陷、修改文档和数据文件以及对测试用例或实用程序进行外围代码的更改。