分布式版本控制系统Git的安装和使用

分布式版本控制系统Git的安装和使用

🌈个人主页: Hygge_Code🔥热门专栏:从0开始学习Java | Linux学习| 计算机网络💫个人格言: “既然选择了远方,便不顾风雨兼程”

在这里插入图片描述

文章目录

一、关于版本控制

1. 什么是“版本控制”?

• 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统

2. 版本控制系统(VCS)带来的好处🐦‍🔥

•可以将选定的文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态
•可以比较文件的变化细节,查出最后是谁修改了哪个地方,从而找出导致问题的原因
• 就算你把整个项目中的文件改的改删的删,你也照样可以轻松恢复到原先的样子

3. 版本控制系统分类

• 本地版本控制系统(如:RCS)
• 集中化的版本控制系统(如:CVS、Subversion)
分布式版本控制系统(如:Git、Mercurial、Bazaar)

二、Git核心

1. 三大文件状态

Git通过三种状态精准管理代码变化,每一步操作都对应状态的转换:

  • 已修改(modified):文件在工作区被修改,但尚未存入本地数据库,是代码变化的“初始状态”。
  • 已暂存(staged):对已修改文件的当前版本做标记,确认这部分修改会纳入下次提交的快照,相当于给代码“拍了张待存档的照片”。
  • 已提交(committed):暂存区的快照被永久存入Git目录(本地数据库),代码进入“安全存储”状态。

这三种状态对应Git项目的三个核心区域:工作区(实际编写代码的文件夹)、暂存区(临时存放待提交修改的文件)、Git目录(存储元数据和对象数据库的核心区域)=

在这里插入图片描述

2. 四步完成一次代码提交

Git的基础操作围绕“修改-暂存-提交-同步”展开,每一步都有明确的目标:

  1. 工作区修改:在本地项目文件夹中编写或修改代码,比如新增一个user.js文件实现用户登录功能。
  2. 暂存区标记:通过git add命令将需要提交的修改加入暂存区,可精准选择单个文件(git add user.js)或所有修改(git add .),避免误提交无关内容。
  3. 本地库提交:用git commit -m "新增用户登录功能:实现账号密码验证"将暂存区内容存入本地Git目录,同时填写清晰的提交信息,方便后续追溯。
  4. 远程库同步:通过git push将本地提交推送到远程仓库(如GitHub、GitLab),或用git pull拉取远程最新代码,确保团队协作时版本一致。

三、Git实战:从环境配置到命令详解

1. 环境配置

安装Git后,首要任务是配置用户信息——这会写入每一次提交,成为你的“身份标识”,在团队协作中至关重要:

# 全局配置(所有本地仓库通用)git config --global user.name "你的姓名"git config --global user.email "你的工作邮箱"# 查看配置是否生效git config --list # 单独查看某项配置,如用户名git config user.name 

若需要为特定项目配置不同信息,只需进入项目目录,去掉--global参数重新执行命令即可。

Git的安装操作

Git的下载安装 (图文教程)

2. 本地操作命令

本地仓库是Git操作的基础,常用命令覆盖了从初始化到版本回溯的全流程:

命令功能说明示例
git init初始化本地仓库,生成隐藏的.git目录cd 项目文件夹 && git init
git status查看文件状态,区分已修改、已暂存、未跟踪文件git status
git add将文件添加到暂存区git add *.js(添加所有JS文件)
git commit提交暂存区内容到本地仓库git commit -m "修复登录页表单验证bug"
git log查看提交历史,--oneline参数可简化输出git log --oneline
git rm从版本库移除文件(同时删除本地文件)git rm obsolete.js
git mv移动或重命名文件,保留版本记录git mv oldname.js newname.js
git reset取消暂存区文件,或回溯版本git reset HEAD user.js(取消user.js暂存)
git checkout撤销工作区修改,或切换分支git checkout -- user.js(撤销user.js未暂存的修改)

3. 远程操作命令

远程仓库是团队共享代码的核心,以下命令覆盖了远程仓库的管理与同步:

代码同步

# 从远程仓库抓取代码(不合并到工作区)git fetch origin # 拉取远程代码并合并到当前分支(多人协作常用)git pull origin main # 推送本地分支到远程仓库(首次推送需加-u关联分支)git push -u origin main # 克隆远程仓库到本地(初始化新项目时用)git clone https://github.com/你的账号/项目名.git 

查看/管理远程仓库

# 查看已配置的远程仓库(-v显示详细URL)git remote -v # 添加远程仓库,命名为origin(默认名称)git remote add origin https://github.com/你的账号/项目名.git # 重命名远程仓库(如将origin改为github)git remote rename origin github # 移除远程仓库git remote remove github # 查看某个远程仓库的详细信息git remote show origin 

当拉取远程代码遇到“无关历史”冲突时,可添加--allow-unrelated-histories参数强制合并,如git pull origin main --allow-unrelated-histories

四、Git分支与标签

1. 分支:隔离开发

  • 分支协作流程
    1. 接到需求后,从主分支(main)创建功能分支(如feature/user-profile)。
    2. 在功能分支开发完成后,切换回主分支(git checkout main)。
    3. 合并功能分支到主分支(git merge feature/user-profile)。
    4. 确认无误后,删除功能分支(git branch -d feature/user-profile),若分支未合并需强制删除,用git branch -D 分支名

核心分支命令

# 创建分支(如开发新功能的feature/payment分支)git branch feature/payment # 切换分支git checkout feature/payment # 创建并切换分支(推荐用法)git checkout -b feature/payment # 查看所有分支(当前分支前带*)git branch # 查看分支最后一次提交git branch -v 

2. 标签:标记重要版本

在项目发布节点(如V1.0、V2.0),用标签标记特定提交,能快速定位发布版本,方便后续维护。Git标签分为两种:

标签同步:默认git push不推送标签,需手动推送:

# 推送单个标签到远程git push origin v1.0 # 推送所有标签到远程git push origin --tags 

附注标签:包含标签者信息、创建时间、附注描述,更适合团队共享:

git tag -a v1.0 -m "V1.0版本:完成用户注册、登录、商品列表功能"

轻量标签:仅存储提交校验和,适合本地临时标记:

git tag v1.0 # 给当前提交打轻量标签

五、版本库目录与编码规范

1. 版本库目录规范

混乱的目录结构会增加团队协作成本,统一的目录规范能提升开发效率。推荐的Git仓库根目录结构如下:

项目根目录/ ├─ documents/ # 项目相关文档(需求文档、设计文档、测试报告等) ├─ projects/ # 项目源代码(按模块划分,如前端项目放projects/frontend,后端放projects/backend) ├─ README.md # 项目说明文档(中文),包含项目介绍、目录结构、环境搭建步骤等 └─ README.en.md# 项目说明文档(英文),方便国际协作 

可参考模板仓库(https://gitee.com/zero-awei/hello-gitee.git)快速搭建目录结构,确保团队成员遵循统一标准。

在这里插入图片描述

2. 编码规范

编码规范是团队协作的“语言共识”,Git仓库需配合编码规范与检查工具,确保代码质量:

  • 常用编码规范
    • Java项目:遵循《阿里巴巴Java开发手册》,涵盖命名规范、注释要求、异常处理等细节。
    • 多语言通用:参考《Google开源项目风格指南》,适配C++、Python、JavaScript等多种语言。
  • 编码检查工具

C++:用Cpplint工具,可集成到Visual Studio等IDE,配置示例:

命令:D:\software\Python27\python.exe 参数:Tools\Scripts\cpplint.py --output=vs7 --filter=-build/include_subdir 初始目录:$(ItemDir) 

通过工具自动化检查,能减少人工 review 成本,让代码风格保持一致。

六、冲突解决

例如:

在这里插入图片描述

多人协作时,同一文件的同一部分被修改,合并分支会触发冲突。Git会在冲突文件中标记冲突区域,只需三步即可解决:

  1. 查看冲突:执行git status,会显示“both modified: 冲突文件名”,明确冲突文件。
  2. 提交结果:执行git add 冲突文件名将修改加入暂存区,再用git commit提交(无需额外写信息,Git会自动生成冲突解决日志)。

修改文件:打开冲突文件,Git用<<<<<<< HEAD(当前分支内容)、=======(待合并分支内容)、>>>>>>> 分支名标记冲突区域,按需保留代码并删除标记。例如:

# 冲突前 <<<<<<< HEAD String welcome = "欢迎登录"; ======= String welcome = "Welcome to Login"; >>>>>>> feature/i18n # 冲突后(保留国际化版本) String welcome = "Welcome to Login"; 

若冲突复杂,可使用git mergetool启用可视化冲突解决工具(如VS Code、Beyond Compare),降低操作难度。


如果我的内容对你有帮助,请 点赞 , 评论 , 收藏 。创作不易,大家的支持就是我坚持下去的动力!

在这里插入图片描述

Read more

HarmonyOS应用开发实战(基础篇)Day07-《登录注册页面》

HarmonyOS应用开发实战(基础篇)Day07-《登录注册页面》

设计:从零构建一个专业级登录页面 在移动应用开发中,登录/注册页面是用户与系统建立身份关联的第一道门户,其设计质量直接影响用户的第一印象与使用体验。本文将基于 ArkTS 与 HarmonyOS 的 ArkUI 框架,从 UI 设计到交互逻辑,完整实现一个简洁、安全、响应式的登录页面。 一、设计目标与视觉规范 根据需求草图,我们的登录页面需包含以下核心元素: * 顶部 Logo:品牌标识,增强识别度; * 账号输入框:支持文本输入,带占位提示; * 密码输入框:密文显示,保障安全; * 操作按钮组:包含“登录”与“取消”两个功能按钮; * 交互反馈:输入校验、加载状态、跳转逻辑。 整体风格遵循 HarmonyOS 设计语言(HUAWEI Design): * 使用 vp

By Ne0inhk
Flutter 三方库 highlight 构建鸿蒙跨端开发者社区全量编程语言高亮适配研究:兼容各类型复杂文本节点正则表达式切割引擎、移动端极客视觉质感高定体验-适配鸿蒙 HarmonyOS ohos

Flutter 三方库 highlight 构建鸿蒙跨端开发者社区全量编程语言高亮适配研究:兼容各类型复杂文本节点正则表达式切割引擎、移动端极客视觉质感高定体验-适配鸿蒙 HarmonyOS ohos

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 highlight 构建鸿蒙跨端开发者社区全量编程语言高亮适配研究:极限兼容各类型复杂文本节点正则表达式切割引擎、全栈重塑移动端极客阅读展示视觉质感高定体验 前言 在 OpenHarmony 的专业技术文档、代代码代码编辑器或者是社区学习类应用中,能够优雅、清晰地展示各种编程语言的代码片段,是业务质量的直接体现。普通的富文本标签在处理复杂的语法高亮(Syntax Highlighting)时不仅效率低下,且配色失准。highlight 库为 Flutter 开发者提供了一套支持全语言、高性能的语法高亮引擎。本文将带大家在鸿蒙端实战接入,实现“像素级”的技术排版。 一、原直线性 / 概念介绍 1.1 基础原理/概念介绍 highlight 的核心逻辑是基于 词法模式匹配(Lexical Pattern Matching)与主题样式的动态映射。它不仅依赖简单的关键字匹配,更通过各语言专有的正则表达式集(Modes)

By Ne0inhk

Ubuntu 26.04 LTS“坚毅浣熊”(Resolute Raccoon) 新特性前瞻

Ubuntu 26.04 LTS 发布计划与新功能详解 * 发布计划与生命周期 * 1.1 关键时间节点 * 1.2 支持周期 * 核心系统与桌面环境 * 2.1 GNOME 50:全面进入 Wayland 时代 * 核心变化 * NVIDIA Wayland 性能大幅优化 * 2.2 Linux 内核:6.20 或 7.0 * 2.3 系统核心组件 * 开发工具链全面升级 * 3.1 编译器工具链 * GCC 15 编译器套件 * 完整工具链更新 * 3.2 大规模重编译保障系统一致性 * 3.3 Web

By Ne0inhk

Flutter for OpenHarmony: Flutter 三方库 pedantic_mono 引入最严格的代码静态审计规范(鸿蒙项目代码质量卫士)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在进行 OpenHarmony 项目开发,尤其是多人协作的大型工程时,“代码风格不统一”和“潜在逻辑风险”是性能和维护的双重杀手。虽然 Dart 官方提供了 lints 包,但其约束力往往较弱。 pedantic_mono 是一套极度严格、由社区资深开发者维护的统计审计(Lint)规则集。它不仅包含了基础的排版规范,更深入到了异步安全(Async Safely)、集合操作性能以及代码健壮性等多个维度。引入它,就像是为你的鸿蒙项目请来了一位 24 小时待命的“代码审计专家”。 一、核心审计范围图 pedantic_mono 覆盖了从变量命名到高阶逻辑的每个角落。 pedantic_mono 规则库 基础规范 (命名/排序) 异步安全 (忘记 await/

By Ne0inhk