DevOps - Git

Git 是一个分布式版本控制系统。它在 DevOps 工作流中发挥着重要作用。我们使用 Git 来管理源代码、帮助开发人员协作以及自动化持续集成/持续部署 (CI/CD) 管道。Git 可以轻松跟踪版本、创建分支和合并代码更改。

这些功能对于快速协作和快速开发周期非常重要。Git 存储库是 DevOps 管道的核心。它们触发自动构建、测试和部署。这确保我们能够快速、一致地交付软件，并具有完全的可追溯性。

为 DevOps 工作流设置 Git

在本节中，让我们了解如何为 DevOps 工作流设置 Git。

安装和配置 Git

要在 DevOps 工作流中开始使用 Git，首先，我们需要在我们的系统上安装它 −

Linux

sudo apt-get install git

macOS

brew install git

Windows

我们可以从 官方网站。

安装 Git 后，我​​们需要全局设置用户详细信息 −

git config --global user.name "您的姓名"
git config --global user.email "you@example.com"

这可确保我们的提交正确链接到我们。要检查设置，我们可以使用 −

git config --list

将 Git 与 CI/CD 工具(Jenkins、GitLab CI 等)集成

Git 可与 Jenkins、GitLab CI 等 CI/CD 工具配合使用。它有助于自动触发构建和部署。

Jenkins

首先，我们需要在 Jenkins 中安装 Git 插件。在 Jenkins 作业设置中，我们添加 Git 存储库 URL 和我们的凭据。我们将构建配置为基于 Git 事件(如推送或拉取请求)启动。请查看以下示例 −

scm:
  git:
    - url: 'https://github.com/your-repository.git'
      branch: 'main'

GitLab CI

我们在存储库中名为 .gitlab-ci.yml 的文件中定义 CI/CD 管道。请查看以下示例−

stages:
  - build
  - test
  - deploy
build:
  stage: build
  script:
    - npm install
test:
  stage: test
  script:
    - npm test
deploy:
  stage: deploy
  script:
    - ./deploy.sh

这可确保每次推送到 Git 存储库都会触发正确的 CI/CD 管道。

DevOps 中的分支策略

在 DevOps 中，分支策略可帮助我们管理如何在 Git 存储库中对代码进行更改。良好的分支策略对于更好的团队合作、更快的开发和顺畅的 CI/CD 管道非常重要。我们使用的一些常见策略是 Git Flow、GitHub Flow 和基于主干的开发。

Git Flow 与 GitHub Flow 与基于主干的开发

Git Flow − Git Flow 是一种旧方法。在此策略中，主分支具有用于生产的稳定代码，而开发分支具有最新的开发更改。新功能进入单独的功能分支。我们从发布分支创建发布，任何紧急修复都在修补程序分支中完成。此方法适用于需要计划发布的大型项目。

git flow init

GitHub Flow − GitHub Flow 更简单，最适合持续交付。在此方法中，我们从主分支创建功能分支，对其进行处理，一旦准备就绪，就将其合并回主分支。这对于经常部署并使用拉取请求来审查代码的团队非常有用。

git checkout -b feature-branch
git push origin feature-branch

基于主干的开发 − 基于主干的开发专注于直接向主分支(或主干)进行小规模、频繁的提交。我们经常创建短暂的功能分支，或者有时直接在主分支上工作并每天多次合并更改。该方法支持持续集成和交付，并且分支最少。

git checkout main
git pull origin main
git merge feature-branch

创建和管理功能、发布和修补程序分支

在 DevOps 中，我们为功能、发布和修补程序创建和管理不同的分支。这有助于我们在不干扰主代码的情况下处理不同的任务。

功能分支 − 我们使用功能分支来开发新功能或改进，而无需更改主代码。这些分支是从主分支或开发分支创建的。

git checkout -b feature/login-ui

发布分支 − 发布分支帮助我们准备代码以进行部署。在合并回主版本和开发版本之前，我们会使用它们进行最后的更改、错误修复和版本控制。

git checkout -b release/1.0.0

修补程序分支 − 修补程序分支用于在生产环境中进行快速修复。修复问题后，我们将修补程序合并回主分支和开发分支，以使其保持最新状态。

git checkout -b hotfix/fix-crash

团队协作中的合并和变基策略

我们可以使用合并或变基将不同分支的更改整合在一起。

合并 − 合并将一个分支的更改合并到另一个分支，同时保留提交历史记录。当我们想要维护每个更改的完整上下文时，这很有用。

git merge feature-branch

变基 −变基将整个分支移动到从目标分支的最新提交开始，从而提供更清晰的历史记录。当我们想要避免额外的合并提交时，它很有用。

git rebase main

何时使用合并或变基

• 当我们想要保留更改的准确历史记录时，我们更喜欢合并。
• 当我们想要干净的历史记录时，我们会使用变基，尤其是在将功能分支合并到主分支之前。

我们选择的策略取决于我们团队的工作流程、发布时间表以及我们是否想要详细或干净的提交历史记录。

DevOps 自动化中的 Git Hooks

Git Hooks 是在 Git 流程的不同点运行的简单脚本。它们有助于在某些 Git 操作之前或之后自动执行任务。使用钩子可以使我们的工作流程更顺畅，并有助于在 DevOps 管道中实施良好的做法。

• pre-commit − 此钩子在创建提交之前运行。它对于检查代码样式或运行 linters 以保持代码清洁很有用。
• commit-msg − 它在提交消息写入之后但在提交完成之前运行。它确保提交消息遵循特定的样式。
• post-commit − 这个钩子在提交后运行。它通常用于通知团队或运行额外的测试。
• pre-push − 此钩子在将更改推送到远程存储库之前运行。它可用于在推送之前运行单元测试或验证检查。
• post-merge −合并后运行。它可以在合并代码后触发部署脚本或运行额外测试。

我们通常将这些钩子放在 .git/hooks/ 文件夹中。我们还可以根据 DevOps 管道需求自定义它们。

使用 Git Hooks 自动执行 Linting、测试和部署

Git 钩子非常适合在开发过程中自动执行 Linting、测试和部署等任务。例如:

预提交(Linting)

我们可以在每次提交之前自动对代码进行 lint，以确保代码干净。

预提交钩子的示例(使用 eslint 进行 JavaScript) −

# .git/hooks/pre-commit
#!/bin/sh
npm run lint
if [ $? -ne 0 ]; then
  echo "Linting failed, commit aborted!"
  exit 1
fi

预推送(测试)

我们可以在推送之前运行单元测试，以确保代码不会破坏任何东西。

预推送钩子示例(使用 jest 进行测试)−

# .git/hooks/pre-push
#!/bin/sh
npm test
if [ $? -ne 0 ]; then
   echo "Tests failed, push aborted!"
   exit 1
fi

提交后(部署)

提交后，我们可以触发部署脚本，尤其是对于暂存或生产环境。

提交后钩子的示例(部署到服务器) −

# .git/hooks/post-commit
#!/bin/sh
./deploy.sh

这些钩子有助于自动执行检查代码、运行测试和部署等任务，同时与 Git 工作流紧密集成。

结论

在本章中，我们解释了在 DevOps 环境中使用 Git 的关键方面。我们介绍了如何为工作流设置 Git、自动执行常见的 Git 操作、管理分支、使用 Git 钩子以及自动执行部署脚本。

通过在 DevOps 管道中使用 Git 的强大功能，我们可以确保一致的代码质量。它还帮助我们简化测试和部署并改善协作。