什么是 Git?

Git 已成为版本控制的全球标准。 那么,它到底是什么?

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

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

Git 基础知识

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

Git 中开发的线性图

提交创建指向其他提交的链接,形成开发历史记录的图。 可以将代码还原到以前的提交,检查文件如何从一个提交更改为下一个提交,并查看更改的位置和时间等信息。 提交通过提交内容的唯一加密哈希在 Git 中标识。 由于所有内容都经过哈希处理,因此在未检测到 Git 的情况下无法进行更改、丢失信息或损坏文件。

分支

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

分支上的提交

文件和提交

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

file_status_lifecycle-2

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

Git 的优势

Git 的优势很多。

同时开发

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

更快的版本

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

内置集成

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

强大的社区支持

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

Git 与任何团队合作

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

拉取请求

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

分支策略

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

后续步骤

安装并设置 Git