什么是 Git?

Git 已成为版本控制的全球标准。 那么究竟是什么呢?

Git 是一个分布式版本控制系统。 这意味着项目的本地副本是一个完整的版本控制存储库。 使用这些功能齐全的本地存储库,可以轻松开展脱机或远程工作。 开发人员在本地提交其工作,然后将其存储库的副本与服务器上的副本同步。 这种范例不同于集中式版本控制,后者要求客户端必须先与服务器同步代码,然后才能创建新版代码。

Git 的灵活性和普及程度使其成为任何团队的理想选择。 许多开发人员和大学毕业生已经知道如何使用 Git。 Git 的用户社区创建了许多资源来训练开发人员和 Git 的受欢迎程度,以便在需要时轻松获得帮助。 几乎每个开发环境都有 Git 支持,Git 命令行工具在每个主要操作系统上运行。

Git 基础知识

每次保存工作时,Git 都会创建 commit。 Commit 是所有文件在某个时间点的快照。 如果文件未从一个提交更改到下一个提交,Git 将使用以前存储的文件。 此设计不同于存储文件的初始版本的其他系统,并在一段时间内保留增量记录。

Git 中的开发的线性图形

提交创建指向其他提交的链接,从而形成开发历史记录的关系图。 可以将代码恢复到以前的提交,检查文件从一次提交到下一个提交的方式,并查看信息(如位置和发生更改的时间)。 提交由提交内容的唯一加密哈希值在 Git 中标识。 由于所有内容都经过哈希处理,因此无法进行更改、丢失信息或损坏的文件,而无需对其进行 Git 检测。

分支

每个开发人员保存自己的本地代码存储库的更改。 因此,可以基于同一提交进行许多不同的更改。 Git 提供了用于隔离更改和稍后将它们合并在一起的工具。 分支是进行中工作的轻型指针,可管理此分离。 在分支中创建的工作完成后,可以合并回团队的主分支 (或) 分支。

分支上的提交

文件和提交

Git 中的文件处于以下三种状态之一:已修改、已分步或已提交。 首次修改文件时,更改仅存在于工作目录中。 它们尚不是提交或开发历史记录的一部分。 开发人员必须 步更改的文件,以包含在提交中。 暂存区域包含要包含在下一个提交中的所有更改。 开发人员对分步文件满意后,会打包为提交 ,并包含 描述更改内容的消息。 此提交将成为开发历史记录的一部分。

file_status_lifecycle-2

通过暂存,开发人员可以选取要保存在提交中的文件更改,以将大型更改分解为一系列较小的提交。 通过缩小提交范围,可以更轻松地查看提交历史记录以查找特定文件更改。

Git 的好处

同时开发

每个人都有自己的代码本地副本,并且可以在自己的分支上同时工作。 Git 脱机工作,因为几乎每个操作都是本地的。

更快版本

分支允许灵活且同时进行开发。 主分支包含您发布的稳定的高质量代码。 功能分支包含正在进行的工作,并在完成时合并到主分支中。 通过将发布分支与正在进行的开发分离,更轻松地管理稳定的代码和交付更新。

内置集成

由于其普及,Git 已集成到大多数工具和产品。 每个主要 IDE 都具有内置的 Git 支持,许多工具支持持续集成、持续部署、自动测试、工作项跟踪、指标和报告功能与 Git 的集成。 此集成简化了日常工作流。

强大的社区支持

Git 是开源的,已成为版本控制的事实上的标准,因此,团队无可用的工具和资源。 与其他版本控制系统相比,Git 的社区支持量使你可以在需要时轻松获得帮助。

Git 适用于任何团队

将 Git 与源代码管理工具结合使用,可以鼓励协作、强制实施策略、自动化流程,以及改进工作的可见性和可跟踪性,从而提高团队的工作效率。 团队可以针对版本控制、工作项跟踪以及持续集成和部署来进行单独的工具。 或者,他们可以选择 GitHubAzure DevOps 等解决方案,在一个位置支持所有这些任务。

拉取请求

在将代码更改合并到主分支之前,使用 拉取请求 与团队讨论代码更改。 拉取请求中的讨论非常有用,可确保代码质量并增加团队的知识。 GitHub 和 Azure DevOps 等平台提供了丰富的拉取请求体验,开发人员可在其中浏览文件更改、保留注释、检查提交、查看生成以及投票以批准代码。

分支策略

团队可以配置 GitHub 和 Azure DevOps,以在整个团队中强制实施一致的工作流和流程。 他们可以设置 分支策略, 以确保拉取请求在完成之前满足要求。 分支策略通过阻止直接推送、要求审阅者并确保干净生成来保护重要分支。