在云原生中，python扮演的角色是什么？

在云原生环境中，Python 作为一种高级编程语言，在多个方面扮演着重要角色。云原生是指利用云计算的各种优势（如弹性、可扩展性和自动化），构建和运行应用程序的方法和技术集合。在这样的环境中，Python 的特点和优势如下：

1. 微服务架构：云原生应用通常基于微服务架构，这意味着应用被拆分为一系列小的、独立的服务，每个服务执行应用的特定功能。Python 由于其简洁性、易读性和广泛的库支持，非常适合快速开发和部署微服务。

2. 容器和编排：在云原生环境中，容器（如Docker）和容器编排技术（如Kubernetes）是核心组件。Python 应用可以容易地容器化，并在任何支持容器技术的环境中部署。此外，还有多个用于管理容器化应用程序生命周期的 Python 库和工具。

3. 自动化和API：Python 是自动化的一个非常强大的工具，这在云原生环境中尤为重要。利用 Python，可以编写脚本和工具来自动化部署流程、监控、数据收集等。同时，Python 的广泛的库和框架可以用于快速开发 RESTful API，这对于微服务之间的通信至关重要。

4. 数据分析和机器学习：云原生应用程序常常需要处理大量数据以及进行实时分析。Python 在数据科学、分析和机器学习领域非常强大，拥有如 NumPy、Pandas、SciPy、TensorFlow 和 PyTorch 等库，使其能够高效地处理数据操作和计算。

5. DevOps 工具链集成：在云原生和 DevOps 环境中，持续集成和持续部署（CI/CD）是常见的实践。Python 可以集成到 DevOps 工具链中，提供脚本支持，用于构建、测试、部署和监控应用程序。

6. 云服务交互：大多数云提供商（如 AWS、Google Cloud Platform、Microsoft Azure 等）都提供了 Python SDK，使得开发人员能够直接与云服务进行交互，更轻松地集成云功能和服务。

总之，Python 由于其灵活性、易用性以及丰富的库生态系统，在云原生开发的许多方面都扮演着关键角色。它帮助团队快速迭代，适应云原生环境中不断变化的需求和挑战。

1、用python的 subprocess就能写出ping 255个ip哪个不通。多进程就能快很多，用fork

2、子进程在循环中不写exit(),会发生再生成子进程，核心就是子进程下次循环就少一次，生出孙进程，循环少两次。。。直到结束

windows是没有os.fork的，多进程不行，但支持多线程

import os
import timedef main():for i in range(5):  # 仅仅为了示例，我们尝试创建5个子进程pid = os.fork()if pid == 0:  # 判断当前进程是否是子进程# 这里是子进程print(f"子进程: {os.getpid()}")# 如果没有exit，子进程将继续执行循环# ... 子进程需要执行的代码 ...# 非常重要: 子进程完成工作后应该退出# os._exit(0)else:# 这里是父进程print(f"父进程: {os.getpid()}, 创建了子进程: {pid}")time.sleep(1)  # 让循环稍微慢一点，更容易观察if __name__ == "__main__":main()

3 python和go的区别

4 进程和线程，协程概念

5 爬虫 urllib

可以读取网页内容，保存成文件，图片，视频，声音都可以
有些大文件，每次读取一部分

urllib是比较底层的，可以用上层wget这个工具， python中 import wget

可以把网站的所有图片都下载到本地一个文件夹中

面对障碍

1、可以设置一些headers信息（User-Agent）,模拟成浏览器去访问这些网站
2、url 里面有中文，阿斯码解不了，浏览器人家是自己给转码了，代码中要加上 request.quote(‘中文’)

6 paramiko

pip install paramiko
代码中变成ssh客户端，用于 多线程 执行远程命令

7 邮件

发送邮件,收邮件
plain代表纯文本，就像vi编辑的都是文本，富文本就是又有图片，又有链接
下面是给自己主机上面的其他用户发邮件。还可以向互联网上发邮件

SMTP: 简单邮件传输协议，用的TCP 端口25。python 中用 smtplib

8 JSON

跨语言通信，python有元组，列表list，没数组，发送给另一个语言有数组的就会用到 json, 先转成json字符串作为中介

9 request – HTTP库，比urillib3更简单

GET PUT POST DELETE

10 Ansible

它是python编写的，可以 pip install ansible==2.7.2
ssh-keyscan就能把密钥扫描保存下来就省的每台注意ssh后输入yes
比如 ssh-keyscan host1 host2 host3 >> ~/.ssh/known_hosts

playbook
模块名字，目标hosts是谁？tasks干什么？

1. 能每台机器yum安装，可以更新到最新的版本或者已经存在
2. 能设置服务起来并且enable

Ansible API

下面两点 interview 问遇到的问题，这个就可以用上
3. 就是用 python 控制 ansible Adhoc和 Playbook
ssh控制其他主机的时候提供的用户不是root，就需要提权操作
become = yes
become_method= sudo
become_user= root
become_ask_pass = no 不用输入密码，需要设置这个需要提权的用户 NOPASSWD: ALL
4. 不希望 playbook 中明文出现密码的时候，可以用vault_pass加密,
ansible-vault encrypt /tmp/passwd 输入加密密码
cat /tmp/passwd 就是加密文件了
解密用 ansible-valut decrypt /tmp/passwd
5. 运行playbook 就是方法里传入 hosts文件和 yaml 文件

Ansible 模块开发

灰色注释就是用法，不过首先要配置环境变量=你设计的这些模块的代码的目录
把注释中的“用法”，删掉，不要有中文，否则编码错误

下面是从url文件下载到本地，远程主机，就是执行代码那台也要安装wget

11 Git 版本控制系统

能回溯到以前的版本，多人协作

暂存区就是后悔药

01 git安装后，配置用户信息

–global代表全局生效
执行 git config --global core.editor vim 后，当 Git 需要你编辑文本的时候，它会自动打开 Vim 编辑器让你进行编辑。这是一种个性化你的工作环境的方式，确保 Git 在各种需要输入文本的情况下使用你最喜欢或最习惯的编辑器。

02 基础应用

1. 创建仓库
   
   
   .git就是版本库
   也可以git clone过来项目，上面就是初始化仓库的三个方法
   
   git add就是放到暂存区，也就是开始跟踪文件了，commit就是放到版本库里了
   git add .把所有的文件都跟踪
   不想跟踪某些文件，用 .gitignore来控制
   ls .git会看到 index这个文件，这个就是暂存区，commit之后才会进入到版本库 .git
   干净的工作区：就是无文件要提交
   git add 后，可以 git reset HEAD … 撤出暂存区。
   git commit -m “这次提交的注释”
   

03 git reset 和 git rm 是 Git 中用于处理文件更改的两个不同命令，它们的用途和行为有重要差异。以下是每个命令的功能及其常见用例。

1. git reset：就是从暂存区撤出，之前修改的内容还在，就是需要再次git add

• 用途：git reset 主要用于取消已经暂存的更改。你可以用它来撤销对暂存区的修改，例如错误地添加了一些文件到暂存区（stage）时。

• 行为：当你使用 git add <file> 将文件添加到暂存区后，如果你决定不想提交某些文件，可以使用 git reset HEAD <file> 来将它们从暂存区移回工作区。

• 示例：假设你修改了两个文件 file1.txt 和 file2.txt 并用 git add 将它们添加到暂存区。如果你决定只提交 file1.txt，可以使用 git reset HEAD file2.txt 将 file2.txt 从暂存区移除。

  git add file1.txt file2.txt # 将文件添加到暂存区
  git reset HEAD file2.txt    # 将 file2.txt 从暂存区移除
  

  这样，file2.txt 的更改不会出现在接下来的提交中，但文件的更改仍会保留在你的工作目录中。

2. git rm：

• 用途：git rm 用于从工作目录和暂存区中删除文件，它告诉 Git 你希望在接下来的提交中删除这些文件，同时也将文件从你的实际工作目录中移除。

• 行为：git rm 不仅会将文件从暂存区中移除，还会从物理磁盘中删除文件。

• 示例：如果你不再需要 file3.txt，你可以用 git rm file3.txt 来删除它。

  git rm file3.txt            # 删除文件并从暂存区移除
  git commit -m "Remove file3.txt" # 提交这次删除操作
  

  这会在你的下一次提交中删除 file3.txt，并且 file3.txt 也不再出现在你的文件系统中。

总的来说，git reset 更多的是关于取消暂存的更改，而 git rm 是关于完全删除文件（从工作目录和版本历史中）。使用这些命令时需要谨慎，以确保不会误删工作或者将不想提交的更改添加到版本历史中。

04 git log 查看提交历史

05 git check out 慎用，因为你的修改不在，直接回到解放前某个提交版本

在 Git 中，git checkout 命令用于切换分支或恢复工作目录文件。它是一个多功能命令，主要用于以下几种情况：

1. 切换分支：如果你想要切换到一个不同的分支，你可以使用 git checkout 加上你想要切换到的分支的名字。

   示例：

   git checkout develop
   

   这个命令会将你当前的工作分支切换到名为 develop 的分支。如果这个分支不存在，Git 会给出一个错误提示。

2. 创建新分支并切换到该分支：如果你想要创建一个新分支并立即切换到这个分支，你可以添加 -b 参数来实现。

   示例：

   git checkout -b new-feature
   

   这个命令会创建一个名为 new-feature 的新分支，并将当前分支切换到这个新分支。

3. 恢复文件：如果你对一些文件进行了修改但还未提交，而现在你想放弃这些修改，返回到最后一次提交的状态，你可以使用 git checkout。

   示例：

   git checkout -- file1.txt
   

   这条命令会放弃对 file1.txt 文件的所有修改，使其返回到最后一次提交的状态。请注意，这会删除自上次提交以来对该文件的所有修改，所以在使用此命令前要确保不需要这些修改。

4. 检出特定的提交：如果你想查看项目历史中的特定提交或标签，可以使用 git checkout 加上提交的哈希值或标签名。

   示例：

   git checkout 7a052cf
   

   这会更新工作目录中的所有文件，使其反映在哈希值为 7a052cf 的提交时的状态。在这种状态下，你处于一个“DETACHED HEAD”状态，意味着不在任何分支上，这个状态下的任何更改都不会记录到项目历史中，除非你创建一个新分支。

请注意，在 Git 的新版本中，一些 git checkout 的功能已经被更专一的命令所取代，例如用于切换分支的 git switch 命令和用于恢复文件的 git restore 命令。这些新命令的目的是使 Git 的操作更加直观和用户友好。不过，git checkout 命令在很多情况下仍然可用，且被广泛理解和采纳。

06 git 分支管理

git如果两人都同时修改了一个项目的代码，都提交了会发生什么？git是怎样保证多人协作开发一个项目的呢？

在使用Git进行多人协作开发时，多个开发者同时对代码进行更改并提交是常见的情况。当两个开发者都修改了同一项目的代码并尝试提交时，Git的处理方式取决于具体的操作和情况。以下是通常会发生的情况和Git如何管理这种多人协作的方式。

1. 分支和合并（Branching and Merging）：

   • Git鼓励使用分支来进行功能开发。每个开发者可以在自己的分支上工作，完成后再将分支合并回主分支（如main或master）。这样可以减少冲突的可能性。

2. 拉取和合并代码（Pull and Merge）：

   • 当一个开发者（比如说开发者A）想要提交（push）代码到远程仓库时，如果在此期间另一个开发者（开发者B）已经提交了更新，那么开发者A的提交可能会被拒绝，因为他的本地版本已经落后于远程仓库的版本。
   • 在这种情况下，开发者A需要先执行git pull（这通常会自动合并远程的更改，或者如果有冲突则需要手动解决）或者git fetch然后git merge（如果希望分步操作）来整合开发者B的更改。
   • 如果两个开发者更改了同一文件的同一部分，Git无法自动解决合并冲突，此时开发者A需要手动解决这些冲突。

3. 解决合并冲突（Resolving Merge Conflicts）：

   • 在合并时，如果两个开发者修改了同一文件的同一部分，Git会标记出冲突并要求手动解决。开发者需要选择保留哪些更改，或者创建新的内容来替换冲突部分。
   • 解决冲突后，开发者需要进行提交，以完成合并过程。

4. 代码审查（Code Reviews）：

   • 在多人团队中，通常会通过Pull Requests（PR）或Merge Requests（MR）来引入更改。这为团队提供了一个审查代码、提出修改建议并讨论更改的平台，从而可以在代码合并到主分支之前确保代码质量。

5. 使用分布式工作流（Distributed Workflows）：

   • Git是一个分布式版本控制系统，每个开发者都有项目的完整本地副本。这允许开发者离线工作，并在准备好之后推送更改，系统会自动合并冲突或提示需要手动解决。

通过以上方法，Git可以高效地管理多人对代码库的更改，确保版本的一致性和项目的顺利进行。同时，开发者也需要遵循一定的最佳实践（例如常规同步远程更改、合理使用分支等），以保证多人协作的流畅。

07 git tag

在 Git 中，标签（tags）通常用于标识某些重要的提交点，常见于版本发布等场景。Git 提供了两种类型的标签：轻量标签（lightweight）和附注标签（annotated）。下面我们将讨论这两种标签的区别以及它们的使用场景。

轻量标签（Lightweight）:

• 轻量标签类似于一个不变的分支，它实质上是一个指向特定提交的引用。
• 它实际上是一个指向提交对象的引用，它不会改变任何文件。
• 创建轻量标签不需要额外的步骤，只需为特定提交指定一个名字就行了。
• 它没有包含任何额外信息（日期、标签创建者信息、标签信息等）。

创建轻量标签的命令:

git tag my-lightweight-tag

附注标签（Annotated）:

• 附注标签是存储在 Git 数据库中的一个完整对象。它们是可以被校验的；含有签名者的名字、电子邮件地址、日期时间；一条标签信息；并且可以使用 GPG 签名。
• 它会包含更多的信息，例如创建者的名字、电子邮件、日期，以及一条附加的信息消息。
• 通常用于公共或发布的版本，因为这些版本需要有关作者的信息，以及创建时间等。

创建附注标签的命令:

git tag -a my-annotated-tag -m "This is an annotated tag"

何时使用它们？

1. 使用轻量标签:

   • 快速临时标记，例如，你可能想要记住某个特定的提交状态。
   • 个人参考或者在单人项目中的简单标记。
   • 不需要保留与标签相关的额外信息。

2. 使用附注标签:

   • 官方发布版本，这非常重要，因为它们包含了创建时间、标签信息和创建者信息。
   • 需要进行签名的提交（通过 GPG）。
   • 当你想要保留关于该特定标签点的详细历史记录时，这对于项目维护者或多人协作的项目来说非常有用。这些信息可以帮助验证标签的完整性和来源。

总的来说，附注标签因其携带的详细信息而更适合用于正式的或重要的基准标记，特别是在需要发布的项目里。而轻量标签更适合个人用途或临时标记，因为它只是一个简单的指向特定提交的引用。
Git 标签（tags）主要用于标识特定的版本提交点，通常用在发布软件版本（如 v1.0 等）的场景中。以下是 Git 标签的几个主要用途及其解决的问题：

1. 版本发布（Releases）

问题：在软件开发过程中，需要有一个明确且不变的方式来标识某个特定点作为“发布版本”。否则，开发者和用户都难以追踪和引用项目的特定状态。

解决：通过创建一个标签，可以清晰地标记软件的重要发布点。

示例：

git tag -a v1.0 -m "Release version 1.0"

这样，就创建了一个名为 v1.0 的标签，代表软件的一个发布版本。

2. 代码审查（Code Reviews）

问题：在大型项目中，可能会有许多提交和更改，审查者可能希望引用或检查特定的提交。

解决：可以为代码审查创建标签，确保审查者查看正确的代码快照。

示例：

git tag -a review-2023-10-28 -m "Code review on October 28, 2023"

这个标签标识了审查者应该关注的代码状态。

3. 创建里程碑（Milestones）

问题：在项目进展中，需要标识特定的里程碑或成就点，以便将来回溯或参考。

解决：通过对重要提交创建标签来标识项目的关键阶段或里程碑。

示例：

git tag -a milestone-1 -m "Completed the first major segment of the project"

通过这个标签，团队知道这个提交代表了项目的一个重要阶段。

4. 辅助回滚（Aiding Rollbacks）

问题：如果新的代码引入了严重的错误，可能需要回滚到工作良好的状态。

解决：标签可以帮助识别安全的回滚点，尤其是在紧急修复时。

示例：

git tag stable-before-migration

之后，如果需要回滚，可以简单地通过以下命令回到这个稳定状态：

git checkout stable-before-migration

5. 文档或说明（Documentation or Annotations）

问题：项目文档需要引用代码库中的特定点，以说明特定的功能或代码示例。

解决：通过为文档中提及的示例或教程创建标签，读者可以直接访问具体的代码状态。

示例：

git tag -a documented-example -m "This commit was used in the tutorial documentation"

在项目文档中，可以提及这个标签，方便读者查找。

通过使用标签，开发者可以更容易地管理项目的版本历史，无论是对于特定发布、重要更改还是简单的项目里程碑。标签为 Git 仓库提供了一个更加组织化的管理方法，并确保团队成员和最终用户都能准确无误地引用代码的特定状态。

08 分支

大家都在主干上改，很乱，自己写自己的分支，最后首先切换到master分支，然后git merge 你的分支，合并的时候，分支里面特有的文件也进来了

如果合并分支的时候，和主干有相同的文件，但是内容不同，会发生什么？

当尝试合并两个分支时，如果两个分支都对同一文件进行了更改，Git 将尝试自动合并更改。然而，根据更改的性质，情况会有所不同：

1. 非冲突更改：如果更改发生在文件的不同部分，Git 通常可以自动合并这些更改。这意味着每个分支对相同文件的不同部分所做的更改都将被结合在一起。

例如：

• 主分支中，你改变了文件的第一部分。
• 在另一个分支中，更改发生在文件的第二部分。
• 合并这两个分支时，Git 将两处更改整合到一起。

2. 冲突更改：如果两个分支更改了文件的同一部分，Git 将无法自动合并更改，这会导致合并冲突。

例如：

• 主分支中，你改变了文件的第一部分。
• 在另一个分支中，同样的文件的同一部分被以不同的方式更改。
• 当你尝试合并这两个分支时，Git 不知道应该保留哪个版本，因此它停止合并过程，让你解决这个“冲突”。

当合并冲突发生时，你需要手动介入做决定。Git 会在文件中标记出冲突的部分，大致如下所示：

<<<<<<< HEAD
这里是主分支中的版本内容
=======
这里是你尝试合并的分支中的版本内容
>>>>>>> feature-branch

要解决这些冲突，你需要：

1. 打开包含冲突的文件。
2. 决定保留哪个版本的更改，或者可能手动合并内容，编辑为最终想要的状态。
3. 删除 <<<<<<< HEAD, =======, 和 >>>>>>> feature-branch 这些标记行，它们不应出现在最终内容中。
4. 保存文件。
5. 提交这些更改。

通过解决所有冲突并提交更改，你将完成合并过程。解决合并冲突是版本控制工作流中的一个重要组成部分，它需要开发者仔细比较冲突的内容，做出最符合项目需求的决策。
在 Git 中，分支（branch）是开发工作流中的一个核心概念。理解和有效管理分支对于协同工作、特性开发、以及保持代码的稳定性至关重要。

分支的概念：

1. 定义：Git 中的分支本质上是项目历史的不同版本。每个分支代表一个独立的开发线，可以包含特定的更改或新功能。分支可以合并回主线（通常是 main 或 master 分支），这样不同开发线的更改可以集成到一起。

2. 工作方式：在 Git 中，提交对象包含一个指向它们父对象的指针。“分支” 实际上是一个轻量级的可移动指针，指向这些提交对象之一。当你创建新的提交时，分支指针自动向前移动，指向新创建的提交。

何时使用分支：

1. 新功能开发：当你打算添加一个新功能时，你可以创建一个分支，这样不会影响主开发线（如 main 或 master 分支）。这使得你可以在不打乱主开发流程的情况下工作。

2. 实验和探索：如果你想尝试新的想法或不确定的修改，创建一个新分支是安全的，因为它不会影响主分支。

3. 修复错误：对于 bug 修复，创建一个新分支可以让你在不影响或阻断其他开发工作的情况下处理这些问题。

4. 代码审查和协作：在多人项目中，你可以在分支中工作并推送（push）你的更改，然后请求他人审查并合并你的更改。

怎么使用分支：

以下是使用分支的基本命令和步骤：

1. 创建分支：

   git branch feature-branch
   

   这将创建一个名为 feature-branch 的新分支，但你仍在当前分支上。

2. 切换分支：

   git checkout feature-branch
   

   这会切换到新创建的 feature-branch。现在，所有新的提交都会添加到这个分支上。

   注：你可以通过一个命令创建新分支并立即切换到该分支：

   git checkout -b feature-branch
   

3. 添加更改并提交：
   在分支中，你可以修改文件并提交这些更改：

   git add .
   git commit -m "Add my new feature."
   

4. 推送分支到远程仓库：
   如果你想分享这个分支，或将其保存到远程仓库（如 GitHub），你需要推送（push）它：

   git push origin feature-branch
   

5. 合并分支：
   一旦分支中的工作完成，并通过测试，你可能想要将这些更改合并回主分支（比如 main）：

   • 首先，切换回主分支：

     git checkout main
     

   • 然后，合并你的功能分支：

     git merge feature-branch
     

6. 删除分支：
   合并完成后，如果不再需要 feature-branch，你可以删除它：

   • 本地删除：

     git branch -d feature-branch
     

   • 远程删除：

     git push origin --delete feature-branch
     

通过以上步骤，你可以看到，分支在 Git 工作流中扮演着重要角色，它们帮助团队维护代码的稳定性，同时允许多线程开发。

git fetch然后git merge和git pull的区别是什么？git fetch然后git merge这两步分别做了什么？

git fetch、git merge 和 git pull 都是 Git 中用于更新本地代码库的命令。尽管它们都是为了从远程仓库获取最新更改并将这些更改应用到本地仓库，但它们的工作方式有所不同。下面是每个命令的具体作用和这些命令之间的区别。

1. git fetch：

• 当你执行 git fetch 时，Git 会连接到远程仓库，检查你当前没有的所有更改或更新（比如其他人提交的新分支或提交等），并将这些信息拉取到你的本地仓库。
• 重要的是，git fetch 只是将这些更新下载到本地仓库，并不会自动合并到你当前的工作分支。这些更改保留在所谓的“远程分支”中。

2. git merge：

• 在执行 git fetch 之后，如果你想要将这些更改应用到你的当前分支（比如 main），你需要执行 git merge（例如，git merge origin/main）。
• git merge 会将指定分支（在本例中是远程分支 origin/main）的更改合并到当前活动分支。如果存在冲突，你需要手动解决这些冲突。

3. git pull：

• git pull 是一个方便的命令，实际上它是 git fetch 和 git merge 的组合。当你执行 git pull 时，Git 会从远程仓库拉取最新的更改（就像 git fetch 那样）并立即尝试将这些更改合并到你的当前分支（就像 git merge 那样）。
• 这意味着，如果你直接使用 git pull，你可能需要立即处理合并冲突。而使用 git fetch 后再使用 git merge 可以让你有更多的控制：你可以先查看更新，然后再决定如何合并。

总结一下，git fetch 然后 git merge 提供了更多的控制，允许你在合并之前检查更改。这对于复杂的项目或需要审慎合并的场景特别有用。而 git pull 是一个更快捷的方式，适用于你信任拉取的更改并希望直接合并它们的情况。在团队协作中，了解何时使用哪种方法是非常重要的，以确保代码库的整洁和项目的稳定性。

9 gitlab

一个项目，哪些组能访问，哪些人能访问，最后还是用户上传代码

Pull Requests（PR）或Merge Requests（MR）是什么？请举例说明

Pull Requests（PR）和 Merge Requests（MR）是版本控制协作中的关键概念，常用于多人开发的项目中。这些请求允许开发者通知团队成员他们对代码所作的更改，请求他人审查这些更改，并将它们合并到主分支。这两个术语在功能上非常相似，但它们是由不同的Git仓库托管服务使用的；GitHub使用“Pull Requests”，而GitLab使用“Merge Requests”。

以下是Pull Request或Merge Request的一般流程，以及它们是如何用于团队协作的：

1. 创建分支：
   开发者从主代码库（通常是main或master分支）创建一个新分支，在这个新分支上进行开发。这确保了主分支的稳定性，即使是在多人同时工作的情况下。

2. 提交更改：
   开发者在新分支上进行更改，这可能包括修复错误、添加新功能等。更改完成后，开发者会将这些更改提交到新分支，并将该分支推送到远程仓库（如GitHub或GitLab）。

3. 发起Pull Request/Merge Request：
   开发者在远程仓库上创建一个PR或MR。这实际上是一种请求，要求其他团队成员审查代码、提出反馈或建议，并最终将这个分支的更改合并到主分支。

4. 代码审查和讨论：
   团队其他成员（如同事、审查者或维护者）审查提交的代码，并在PR或MR的评论或讨论区提供反馈。开发者可以根据反馈继续改进代码。

5. 合并或关闭：

   • 如果代码审查成功，并且更改被接受，那么维护者或有权限的团队成员会合并这个请求，也就是将这个分支的更改合并到主分支。合并后的代码变更现在是项目代码的一部分。
   • 如果代码有问题或者不需要合并，PR或MR可以被关闭，相关的更改也就不会合并到主分支。

通过Pull Requests或Merge Requests，整个团队能够更有效地协作，增强代码质量控制，并保持代码库的整洁和组织性。此流程提供了一个透明、可审计的变更管理机制，使所有团队成员都能看到什么时候、为什么以及如何进行代码更改。