尧图网站建设 
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 2022 系列第 35 天的技术笔记整理对应仓库 2022/tr/Days/day35.md本文基于该文档展开并辅以仓库实践佐证。在这一天我们将抛开具体的安装细节先站在“全景视角”理解版本控制Version Control到底是什么、为什么重要随后用一组最简单的命令git init、git add、git commit、git log、git status、git diff、git checkout走完一个完整的最小工作流。读完后你将能够解释分支与合并解决什么问题、为什么“版本控制不是备份”并能在本地亲手复现从初始化仓库到提交、对比、回退的完整过程。什么是版本控制Git 只是众多版本控制系统中的一员。在深入 Git 之前先理解版本控制这一领域本身提供了哪些选项与方法论会帮助你建立正确的全局认识。追踪项目历史最直接的价值版本控制最明显、也最大的好处是能够追踪一个项目的完整历史。我们可以通过git log回看仓库看到大量提交记录与注释了解项目到目前为止发生了什么。设想一个真实的软件项目源码由多位作者在不同时间提交随后又有审查者reviewer介入。所有这些行为——发生了什么、发生在何时、由谁提交、由谁审查——都会被完整记录下来。这种可追溯性正是团队协作的事实基础。在版本控制尚未普及的年代人们只能在做修改之前手动复制一份副本或者抱着“万一以后用得上”的心态把旧代码注释掉。这种“手动备份式”的工作方式既不安全也无法扩展。一个重要声明版本控制不是备份版本控制能够记录历史、支持回滚但它承担的是“追踪变化”的职责不能替代独立的备份策略。这一点在本仓库90DaysOfDevOps中同样成立——版本库中的提交记录不等于数据冗余备份。管理一个项目的多个版本分支Branching版本控制的另一大价值是同时管理一个项目的多个版本。假设我们有一个在所有操作系统上免费提供的应用同时还有一个同样跨平台的付费应用两者共享大部分代码。免费版只包含常规提交normal commits付费版会追加额外特性可以称为“付费提交”premium commits。如果每次提交都把代码复制粘贴到两个应用中一旦开发规模超过一个人就会迅速变得混乱不堪错误也会随之而来。版本控制解决这一问题的方式是分支branching——让同一个应用拥有两条并行的代码流。合并Merging与冲突Conflicts免费版中的新特性最终也要出现在付费版中这需要通过**合并merging**来完成。合并看起来简单实际上可能很复杂假设一个团队在免费版上工作、另一个团队在付费版上工作双方都修改了影响整体代码的部分——比如某个变量被更新并破坏了其他功能——于是产生了一个破坏某个特性的冲突conflict。需要明确版本控制无法替你解决冲突冲突最终要由人来裁决。但版本控制让冲突的定位、对比与解决变得易于管理——这正是它优于手工复制粘贴的地方。协作版本控制存在的首要理由如果你还没意识到那这里直说版本控制最核心的意义是协作能力——在开发者之间共享代码。而且这种“共享”如今早已超出源码范畴和同事共同撰写一份演示文稿像 90DaysOfDevOps 这样的公开学习挑战中社区成员在项目的各个阶段提交修正与更新。没有版本控制时软件团队只能把代码拆成一个个功能模块然后在发布前艰难地把碎片拼到一起。有了版本控制我们拥有单一事实来源single source of truth——大家依然可以在不同模块上并行工作但协作变得更好、更可控。不只是开发者的工具团队与工具的可见性版本控制不仅让开发者受益团队所有成员都能获得可见性各类工具也能接入并利用它项目管理工具可以关联到仓库跟踪工作进度构建机器例如 Jenkins将在本系列的 CI/CD 模块中展开可以基于仓库中的代码自动完成构建、打包并自动化部署测试与指标收集。也就是说版本库是团队与自动化工具共同依赖的中枢。Git 是什么Git是一个追踪源代码或任何文件变化的工具也可以说它是一个开源的分布式版本控制系统Distributed Version Control System。Git 在系统上的使用方式多种多样最常见的方式是命令行也有图形用户界面GUIVisual Studio Code等编辑器内置了 git-aware感知 Git的操作可以直接利用。在把 Git 安装到本机之前先通过一个高层走查理解它的核心工作流这一步不需要任何前置安装。不安装 Git先走一遍核心命令流假设我们已经创建了一个文件夹也可以直接拿 90DaysOfDevOps 这样的现成项目文件夹来练习接下来按顺序执行下面的流程。第一步git init初始化仓库要让一个文件夹纳入版本控制首先需要初始化该目录git init可以把这条命令理解为把我们的目录登记为电脑上某个“数据库”中的一个仓库。此后 Git 才会开始跟踪该目录下的内容。第二步git add .暂存所有文件现在创建一些文件和文件夹让源码开始生长。接着执行git add .这条命令把目录中的所有文件和文件夹放进一个“快照”但此时还没有向数据库提交任何东西——它只是表示“目录中由.代表的所有文件都已准备好被添加”。第三步git commit -m My First Commit首次提交然后提交这些文件git commit -m My First Commit每次提交都应附上一段说明文字强烈建议这样做这样我们就能知道每一次提交到底发生了什么。第四步git log查看项目历史现在可以看到项目历史中发生的一切git loggit log展示提交历史、提交者与提交说明是回看项目演进的核心命令。第五步git status观察工作区状态再创建一个新文件samplecode.ps1仓库的状态就会发生变化。用git status检查仓库当前状态它提示“没有可提交的内容但可以添加名为 samplecode.ps1 的新文件”。再次运行git status可以看到有一个文件等待提交。第六步git add samplecode.ps1与第二次提交添加新文件并再次查看状态git add samplecode.ps1 git status此时文件显示为“可以提交”。接着执行第二次提交git commit -m My Second Commit再次运行git status工作区恢复干净clean状态。再用git log可以看到最新的这次变更以及最初的首次提交。第七步git diff对比两次提交如果想知道两次提交之间到底发生了什么——哪些文件被新增或修改git diff b8f8 709a这里的b8f8、709a是示例中两次提交哈希的前缀实际请替换为git log输出的真实提交号。命令会展示具体的变化内容在上述示例场景中显示的是“新增了一个文件”。第八步git checkout与git switch -在提交之间“时间旅行”更深一步我们可以在提交之间来回跳跃也就是时间旅行使用提交号即可回退到过去且不会丢失新文件git checkout 709a想要前进回来同样可以使用提交号也可以使用下面的命令撤销刚才的操作、切回原来的分支git switch -这一组命令展示了 Git 历史的可逆性探索旧版本、对比差异、返回原状全程不会破坏现有文件。小结版本控制解决了什么把第 35 天的核心结论浓缩如下追踪一个项目的历史管理一个项目的多个版本在开发者之间以及更广泛的团队与工具之间共享代码协调团队工作顺便还有一点“时间旅行”的能力。整个过程看起来像是在跳来跳去但即便暂时不熟悉每条命令的具体细节也已经能看清版本控制的威力与全景。仓库里的真实应用90DaysOfDevOps 本身就是用 Git 协作的本文讨论的理念并非纸上谈兵——本仓库就是最好的实践样本。从仓库结构可以观察到仓库根目录的 README.md 将自身定位为“learning in public”的公开学习项目并已成为社区的结构化学习地图——这正是原文档所描述的“社区成员在项目各阶段提交修正与更新”的协作场景CONTRIBUTING.md 定义了社区贡献与协作的流程是多人共享同一仓库、协调团队工作的制度化体现publishing.md 描述了内容发布与多语言翻译的协作工作流对应的多语言版本目录如 2022/es、2022/ja、2022/ko、2022/tr、2022/zh_cn 等实际上就是“同一项目的多版本并行管理”在文档项目上的映射——每个语言目录相当于一条并行的分支而社区翻译者的合并工作则对应 merging_sidebar.md 与 index.html 则依赖仓库文件作为单一事实来源生成站点导航与页面。同时本系列后续的 Day 36安装与配置 Git 将从“全景理解”过渡到“动手落地”在不同操作系统上安装 Git、配置user.name/user.email/core.editor等并对比**客户端-服务器型如 Apache Subversion与分布式如 Git**两类版本控制模型的核心差异——分布式模型下每位开发者下载的是包含全部提交历史与全部分支的完整仓库这也正是 Git “快速、智能、灵活、安全”特性的来源。建议把本文的命令流程与 Day 36 的安装配置结合起来完成从理论到实践的完整闭环。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 35 天Git 版本控制全景图——从版本管理基础到 Git 核心工作流90DaysOfDevOps 第 35 天Git 版本控制全景图——从版本管理基础到 Git 核心工作流 本篇是 90DaysOfDevOps 2022 年课文档/教程90DaysOfDevOps 第 29 天Microsoft Azure 基础概念与资源组实战90DaysOfDevOps 第 29 天Microsoft Azure 基础概念与资源组实战 本文是 90DaysOfDevOps 学习计划中 Cloud文档/教程90DaysOfDevOps 第 35 天Git 版本控制全景图——从为什么到第一个 Commit90DaysOfDevOps 第 35 天Git 版本控制全景图——从为什么到第一个 Commit 在进入 Git 的具体命令之前先回答两个根本问题什么是文档/教程上一篇Cycle.js性能优化最终指南响应式应用的性能优化手册下一篇终极JSON提示技巧如何用Ideogram-4-nf4生成专业级设计图像创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 90DaysOfDevOps 第 35 天：Git 与版本控制核心概念与基础命令实战
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本文是 90DaysOfDevOps 2022 系列第 35 天的技术笔记整理对应仓库 2022/tr/Days/day35.md本文基于该文档展开并辅以仓库实践佐证。在这一天我们将抛开具体的安装细节先站在“全景视角”理解版本控制Version Control到底是什么、为什么重要随后用一组最简单的命令git init、git add、git commit、git log、git status、git diff、git checkout走完一个完整的最小工作流。读完后你将能够解释分支与合并解决什么问题、为什么“版本控制不是备份”并能在本地亲手复现从初始化仓库到提交、对比、回退的完整过程。什么是版本控制Git 只是众多版本控制系统中的一员。在深入 Git 之前先理解版本控制这一领域本身提供了哪些选项与方法论会帮助你建立正确的全局认识。追踪项目历史最直接的价值版本控制最明显、也最大的好处是能够追踪一个项目的完整历史。我们可以通过git log回看仓库看到大量提交记录与注释了解项目到目前为止发生了什么。设想一个真实的软件项目源码由多位作者在不同时间提交随后又有审查者reviewer介入。所有这些行为——发生了什么、发生在何时、由谁提交、由谁审查——都会被完整记录下来。这种可追溯性正是团队协作的事实基础。在版本控制尚未普及的年代人们只能在做修改之前手动复制一份副本或者抱着“万一以后用得上”的心态把旧代码注释掉。这种“手动备份式”的工作方式既不安全也无法扩展。一个重要声明版本控制不是备份版本控制能够记录历史、支持回滚但它承担的是“追踪变化”的职责不能替代独立的备份策略。这一点在本仓库90DaysOfDevOps中同样成立——版本库中的提交记录不等于数据冗余备份。管理一个项目的多个版本分支Branching版本控制的另一大价值是同时管理一个项目的多个版本。假设我们有一个在所有操作系统上免费提供的应用同时还有一个同样跨平台的付费应用两者共享大部分代码。免费版只包含常规提交normal commits付费版会追加额外特性可以称为“付费提交”premium commits。如果每次提交都把代码复制粘贴到两个应用中一旦开发规模超过一个人就会迅速变得混乱不堪错误也会随之而来。版本控制解决这一问题的方式是分支branching——让同一个应用拥有两条并行的代码流。合并Merging与冲突Conflicts免费版中的新特性最终也要出现在付费版中这需要通过**合并merging**来完成。合并看起来简单实际上可能很复杂假设一个团队在免费版上工作、另一个团队在付费版上工作双方都修改了影响整体代码的部分——比如某个变量被更新并破坏了其他功能——于是产生了一个破坏某个特性的冲突conflict。需要明确版本控制无法替你解决冲突冲突最终要由人来裁决。但版本控制让冲突的定位、对比与解决变得易于管理——这正是它优于手工复制粘贴的地方。协作版本控制存在的首要理由如果你还没意识到那这里直说版本控制最核心的意义是协作能力——在开发者之间共享代码。而且这种“共享”如今早已超出源码范畴和同事共同撰写一份演示文稿像 90DaysOfDevOps 这样的公开学习挑战中社区成员在项目的各个阶段提交修正与更新。没有版本控制时软件团队只能把代码拆成一个个功能模块然后在发布前艰难地把碎片拼到一起。有了版本控制我们拥有单一事实来源single source of truth——大家依然可以在不同模块上并行工作但协作变得更好、更可控。不只是开发者的工具团队与工具的可见性版本控制不仅让开发者受益团队所有成员都能获得可见性各类工具也能接入并利用它项目管理工具可以关联到仓库跟踪工作进度构建机器例如 Jenkins将在本系列的 CI/CD 模块中展开可以基于仓库中的代码自动完成构建、打包并自动化部署测试与指标收集。也就是说版本库是团队与自动化工具共同依赖的中枢。Git 是什么Git是一个追踪源代码或任何文件变化的工具也可以说它是一个开源的分布式版本控制系统Distributed Version Control System。Git 在系统上的使用方式多种多样最常见的方式是命令行也有图形用户界面GUIVisual Studio Code等编辑器内置了 git-aware感知 Git的操作可以直接利用。在把 Git 安装到本机之前先通过一个高层走查理解它的核心工作流这一步不需要任何前置安装。不安装 Git先走一遍核心命令流假设我们已经创建了一个文件夹也可以直接拿 90DaysOfDevOps 这样的现成项目文件夹来练习接下来按顺序执行下面的流程。第一步git init初始化仓库要让一个文件夹纳入版本控制首先需要初始化该目录git init可以把这条命令理解为把我们的目录登记为电脑上某个“数据库”中的一个仓库。此后 Git 才会开始跟踪该目录下的内容。第二步git add .暂存所有文件现在创建一些文件和文件夹让源码开始生长。接着执行git add .这条命令把目录中的所有文件和文件夹放进一个“快照”但此时还没有向数据库提交任何东西——它只是表示“目录中由.代表的所有文件都已准备好被添加”。第三步git commit -m My First Commit首次提交然后提交这些文件git commit -m My First Commit每次提交都应附上一段说明文字强烈建议这样做这样我们就能知道每一次提交到底发生了什么。第四步git log查看项目历史现在可以看到项目历史中发生的一切git loggit log展示提交历史、提交者与提交说明是回看项目演进的核心命令。第五步git status观察工作区状态再创建一个新文件samplecode.ps1仓库的状态就会发生变化。用git status检查仓库当前状态它提示“没有可提交的内容但可以添加名为 samplecode.ps1 的新文件”。再次运行git status可以看到有一个文件等待提交。第六步git add samplecode.ps1与第二次提交添加新文件并再次查看状态git add samplecode.ps1 git status此时文件显示为“可以提交”。接着执行第二次提交git commit -m My Second Commit再次运行git status工作区恢复干净clean状态。再用git log可以看到最新的这次变更以及最初的首次提交。第七步git diff对比两次提交如果想知道两次提交之间到底发生了什么——哪些文件被新增或修改git diff b8f8 709a这里的b8f8、709a是示例中两次提交哈希的前缀实际请替换为git log输出的真实提交号。命令会展示具体的变化内容在上述示例场景中显示的是“新增了一个文件”。第八步git checkout与git switch -在提交之间“时间旅行”更深一步我们可以在提交之间来回跳跃也就是时间旅行使用提交号即可回退到过去且不会丢失新文件git checkout 709a想要前进回来同样可以使用提交号也可以使用下面的命令撤销刚才的操作、切回原来的分支git switch -这一组命令展示了 Git 历史的可逆性探索旧版本、对比差异、返回原状全程不会破坏现有文件。小结版本控制解决了什么把第 35 天的核心结论浓缩如下追踪一个项目的历史管理一个项目的多个版本在开发者之间以及更广泛的团队与工具之间共享代码协调团队工作顺便还有一点“时间旅行”的能力。整个过程看起来像是在跳来跳去但即便暂时不熟悉每条命令的具体细节也已经能看清版本控制的威力与全景。仓库里的真实应用90DaysOfDevOps 本身就是用 Git 协作的本文讨论的理念并非纸上谈兵——本仓库就是最好的实践样本。从仓库结构可以观察到仓库根目录的 README.md 将自身定位为“learning in public”的公开学习项目并已成为社区的结构化学习地图——这正是原文档所描述的“社区成员在项目各阶段提交修正与更新”的协作场景CONTRIBUTING.md 定义了社区贡献与协作的流程是多人共享同一仓库、协调团队工作的制度化体现publishing.md 描述了内容发布与多语言翻译的协作工作流对应的多语言版本目录如 2022/es、2022/ja、2022/ko、2022/tr、2022/zh_cn 等实际上就是“同一项目的多版本并行管理”在文档项目上的映射——每个语言目录相当于一条并行的分支而社区翻译者的合并工作则对应 merging_sidebar.md 与 index.html 则依赖仓库文件作为单一事实来源生成站点导航与页面。同时本系列后续的 Day 36安装与配置 Git 将从“全景理解”过渡到“动手落地”在不同操作系统上安装 Git、配置user.name/user.email/core.editor等并对比**客户端-服务器型如 Apache Subversion与分布式如 Git**两类版本控制模型的核心差异——分布式模型下每位开发者下载的是包含全部提交历史与全部分支的完整仓库这也正是 Git “快速、智能、灵活、安全”特性的来源。建议把本文的命令流程与 Day 36 的安装配置结合起来完成从理论到实践的完整闭环。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 35 天Git 版本控制全景图——从版本管理基础到 Git 核心工作流90DaysOfDevOps 第 35 天Git 版本控制全景图——从版本管理基础到 Git 核心工作流 本篇是 90DaysOfDevOps 2022 年课文档/教程90DaysOfDevOps 第 29 天Microsoft Azure 基础概念与资源组实战90DaysOfDevOps 第 29 天Microsoft Azure 基础概念与资源组实战 本文是 90DaysOfDevOps 学习计划中 Cloud文档/教程90DaysOfDevOps 第 35 天Git 版本控制全景图——从为什么到第一个 Commit90DaysOfDevOps 第 35 天Git 版本控制全景图——从为什么到第一个 Commit 在进入 Git 的具体命令之前先回答两个根本问题什么是文档/教程上一篇Cycle.js性能优化最终指南响应式应用的性能优化手册下一篇终极JSON提示技巧如何用Ideogram-4-nf4生成专业级设计图像创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考