网站前端工资,开福区城乡建设局网站,天元建设集团有限公司衡阳分公司,宁波四方网络网站建设在云原生中#xff0c;python扮演的角色是什么#xff1f;
在云原生环境中#xff0c;Python 作为一种高级编程语言#xff0c;在多个方面扮演着重要角色。云原生是指利用云计算的各种优势#xff08;如弹性、可扩展性和自动化#xff09;#xff0c;构建和运行应用程序…在云原生中python扮演的角色是什么
在云原生环境中Python 作为一种高级编程语言在多个方面扮演着重要角色。云原生是指利用云计算的各种优势如弹性、可扩展性和自动化构建和运行应用程序的方法和技术集合。在这样的环境中Python 的特点和优势如下 微服务架构云原生应用通常基于微服务架构这意味着应用被拆分为一系列小的、独立的服务每个服务执行应用的特定功能。Python 由于其简洁性、易读性和广泛的库支持非常适合快速开发和部署微服务。 容器和编排在云原生环境中容器如Docker和容器编排技术如Kubernetes是核心组件。Python 应用可以容易地容器化并在任何支持容器技术的环境中部署。此外还有多个用于管理容器化应用程序生命周期的 Python 库和工具。 自动化和APIPython 是自动化的一个非常强大的工具这在云原生环境中尤为重要。利用 Python可以编写脚本和工具来自动化部署流程、监控、数据收集等。同时Python 的广泛的库和框架可以用于快速开发 RESTful API这对于微服务之间的通信至关重要。 数据分析和机器学习云原生应用程序常常需要处理大量数据以及进行实时分析。Python 在数据科学、分析和机器学习领域非常强大拥有如 NumPy、Pandas、SciPy、TensorFlow 和 PyTorch 等库使其能够高效地处理数据操作和计算。 DevOps 工具链集成在云原生和 DevOps 环境中持续集成和持续部署CI/CD是常见的实践。Python 可以集成到 DevOps 工具链中提供脚本支持用于构建、测试、部署和监控应用程序。 云服务交互大多数云提供商如 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 ansible2.7.2 ssh-keyscan就能把密钥扫描保存下来就省的每台注意ssh后输入yes 比如 ssh-keyscan host1 host2 host3 ~/.ssh/known_hosts playbook 模块名字目标hosts是谁tasks干什么
能每台机器yum安装可以更新到最新的版本或者已经存在能设置服务起来并且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 基础应用
创建仓库 .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 命令用于切换分支或恢复工作目录文件。它是一个多功能命令主要用于以下几种情况 切换分支如果你想要切换到一个不同的分支你可以使用 git checkout 加上你想要切换到的分支的名字。 示例 git checkout develop这个命令会将你当前的工作分支切换到名为 develop 的分支。如果这个分支不存在Git 会给出一个错误提示。 创建新分支并切换到该分支如果你想要创建一个新分支并立即切换到这个分支你可以添加 -b 参数来实现。 示例 git checkout -b new-feature这个命令会创建一个名为 new-feature 的新分支并将当前分支切换到这个新分支。 恢复文件如果你对一些文件进行了修改但还未提交而现在你想放弃这些修改返回到最后一次提交的状态你可以使用 git checkout。 示例 git checkout -- file1.txt这条命令会放弃对 file1.txt 文件的所有修改使其返回到最后一次提交的状态。请注意这会删除自上次提交以来对该文件的所有修改所以在使用此命令前要确保不需要这些修改。 检出特定的提交如果你想查看项目历史中的特定提交或标签可以使用 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如何管理这种多人协作的方式。 分支和合并Branching and Merging Git鼓励使用分支来进行功能开发。每个开发者可以在自己的分支上工作完成后再将分支合并回主分支如main或master。这样可以减少冲突的可能性。 拉取和合并代码Pull and Merge 当一个开发者比如说开发者A想要提交push代码到远程仓库时如果在此期间另一个开发者开发者B已经提交了更新那么开发者A的提交可能会被拒绝因为他的本地版本已经落后于远程仓库的版本。在这种情况下开发者A需要先执行git pull这通常会自动合并远程的更改或者如果有冲突则需要手动解决或者git fetch然后git merge如果希望分步操作来整合开发者B的更改。如果两个开发者更改了同一文件的同一部分Git无法自动解决合并冲突此时开发者A需要手动解决这些冲突。 解决合并冲突Resolving Merge Conflicts 在合并时如果两个开发者修改了同一文件的同一部分Git会标记出冲突并要求手动解决。开发者需要选择保留哪些更改或者创建新的内容来替换冲突部分。解决冲突后开发者需要进行提交以完成合并过程。 代码审查Code Reviews 在多人团队中通常会通过Pull RequestsPR或Merge RequestsMR来引入更改。这为团队提供了一个审查代码、提出修改建议并讨论更改的平台从而可以在代码合并到主分支之前确保代码质量。 使用分布式工作流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何时使用它们 使用轻量标签: 快速临时标记例如你可能想要记住某个特定的提交状态。个人参考或者在单人项目中的简单标记。不需要保留与标签相关的额外信息。 使用附注标签: 官方发布版本这非常重要因为它们包含了创建时间、标签信息和创建者信息。需要进行签名的提交通过 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-migration5. 文档或说明Documentation or Annotations
问题项目文档需要引用代码库中的特定点以说明特定的功能或代码示例。
解决通过为文档中提及的示例或教程创建标签读者可以直接访问具体的代码状态。
示例
git tag -a documented-example -m This commit was used in the tutorial documentation在项目文档中可以提及这个标签方便读者查找。
通过使用标签开发者可以更容易地管理项目的版本历史无论是对于特定发布、重要更改还是简单的项目里程碑。标签为 Git 仓库提供了一个更加组织化的管理方法并确保团队成员和最终用户都能准确无误地引用代码的特定状态。
08 分支
大家都在主干上改很乱自己写自己的分支最后首先切换到master分支然后git merge 你的分支合并的时候分支里面特有的文件也进来了
如果合并分支的时候和主干有相同的文件但是内容不同会发生什么
当尝试合并两个分支时如果两个分支都对同一文件进行了更改Git 将尝试自动合并更改。然而根据更改的性质情况会有所不同
非冲突更改如果更改发生在文件的不同部分Git 通常可以自动合并这些更改。这意味着每个分支对相同文件的不同部分所做的更改都将被结合在一起。
例如
主分支中你改变了文件的第一部分。在另一个分支中更改发生在文件的第二部分。合并这两个分支时Git 将两处更改整合到一起。
冲突更改如果两个分支更改了文件的同一部分Git 将无法自动合并更改这会导致合并冲突。
例如
主分支中你改变了文件的第一部分。在另一个分支中同样的文件的同一部分被以不同的方式更改。当你尝试合并这两个分支时Git 不知道应该保留哪个版本因此它停止合并过程让你解决这个“冲突”。
当合并冲突发生时你需要手动介入做决定。Git 会在文件中标记出冲突的部分大致如下所示 HEAD
这里是主分支中的版本内容这里是你尝试合并的分支中的版本内容feature-branch要解决这些冲突你需要
打开包含冲突的文件。决定保留哪个版本的更改或者可能手动合并内容编辑为最终想要的状态。删除 HEAD, , 和 feature-branch 这些标记行它们不应出现在最终内容中。保存文件。提交这些更改。
通过解决所有冲突并提交更改你将完成合并过程。解决合并冲突是版本控制工作流中的一个重要组成部分它需要开发者仔细比较冲突的内容做出最符合项目需求的决策。 在 Git 中分支branch是开发工作流中的一个核心概念。理解和有效管理分支对于协同工作、特性开发、以及保持代码的稳定性至关重要。
分支的概念 定义Git 中的分支本质上是项目历史的不同版本。每个分支代表一个独立的开发线可以包含特定的更改或新功能。分支可以合并回主线通常是 main 或 master 分支这样不同开发线的更改可以集成到一起。 工作方式在 Git 中提交对象包含一个指向它们父对象的指针。“分支” 实际上是一个轻量级的可移动指针指向这些提交对象之一。当你创建新的提交时分支指针自动向前移动指向新创建的提交。
何时使用分支 新功能开发当你打算添加一个新功能时你可以创建一个分支这样不会影响主开发线如 main 或 master 分支。这使得你可以在不打乱主开发流程的情况下工作。 实验和探索如果你想尝试新的想法或不确定的修改创建一个新分支是安全的因为它不会影响主分支。 修复错误对于 bug 修复创建一个新分支可以让你在不影响或阻断其他开发工作的情况下处理这些问题。 代码审查和协作在多人项目中你可以在分支中工作并推送push你的更改然后请求他人审查并合并你的更改。
怎么使用分支
以下是使用分支的基本命令和步骤 创建分支 git branch feature-branch这将创建一个名为 feature-branch 的新分支但你仍在当前分支上。 切换分支 git checkout feature-branch这会切换到新创建的 feature-branch。现在所有新的提交都会添加到这个分支上。 注你可以通过一个命令创建新分支并立即切换到该分支 git checkout -b feature-branch添加更改并提交 在分支中你可以修改文件并提交这些更改 git add .
git commit -m Add my new feature.推送分支到远程仓库 如果你想分享这个分支或将其保存到远程仓库如 GitHub你需要推送push它 git push origin feature-branch合并分支 一旦分支中的工作完成并通过测试你可能想要将这些更改合并回主分支比如 main 首先切换回主分支git checkout main然后合并你的功能分支git merge feature-branch删除分支 合并完成后如果不再需要 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
一个项目哪些组能访问哪些人能访问最后还是用户上传代码
配置ssh免密登录
自己的服务器生成公钥拷贝到gitlab. 然后把原来http的remote关联删掉重建ssh关联
10 git clone和git fetch
当然通过一个具体的例子来说明git clone和git fetch之间的区别可能会更加清晰。假设我们有一个位于GitHub上的项目我们将通过一系列的步骤来解释这两个命令是如何工作的。
步骤 1使用 git clone
假设你刚加入一个新项目该项目的代码托管在GitHub上。你还没有项目的任何文件你需要从远程仓库获取代码。这时你会使用git clone。
git clone https://github.com/exampleuser/exampleproject.git这个命令做了什么
在你的本地机器上创建了名为 “exampleproject” 的文件夹。初始化了一个空的Git仓库在这个文件夹中.git 文件夹。下载了该项目的所有文件文件夹和版本历史记录比如所有的提交。设置了一个指向原始或“远程”仓库的链接通常这个默认链接名叫做 “origin”。
现在你有了项目的本地副本并且可以开始工作了。
步骤 2项目的进展与 git fetch
现在假设几天已经过去团队成员已经在远程仓库中做了一些更改。你的本地仓库现在落后于远程仓库。你想看看团队都做了哪些更改但你不想立即更改你当前的工作或当前分支。这时你会使用git fetch。
git fetch origin这个命令做了什么
连接到名为 “origin” 的远程仓库即你最初克隆的仓库。下载了所有你还没有的新提交、分支和标签更新你的本地仓库使其反映远程仓库的最新状态。并没有 自动合并任何更改到你当前的工作分支。并没有 更改你的工作目录。你的文件保持不变直到你决定合并这些新拉取的更改。
为了合并这些更改例如来自远程的新提交你通常会使用 git merge 或者 git rebase。例如如果你想更新你的主分支你可能会这样做
git checkout main # 切换到你想要合并更改的分支
git merge origin/main # 合并来自远程主分支的更改总结
git clone 是你开始工作时使用的用来获取项目的副本。git fetch 用于当你已经有了一个仓库的副本想了解自上次下载以来发生了什么更改。它让你保持对项目进展的了解但又不强制立即合并这些更改从而保持你当前工作的状态。 我们可以通过一个更具体的示例来解释这两个命令之间的区别。假设我们有一个简单的远程仓库仓库中有几个提交。我们将通过一个场景来详细说明git clone和git fetch的工作方式和差异。
远程仓库的初始状态
假设在GitHub上有一个名为exampleproject的远程仓库仓库的内容很简单
exampleproject/
│
├── README.md
└── file1.txtREADME.md 只包含项目的标题。file1.txt 包含一些文本。
步骤 1克隆远程仓库
Alice一名开发者没有这个项目的本地副本她需要开始在项目上工作。她执行以下命令
git clone https://github.com/exampleuser/exampleproject.git现在Alice的本地环境有了项目的完整副本并且目录结构看起来与远程仓库完全一样。
步骤 2团队成员做出更改
几天过去了Bob另一名开发者向exampleproject项目做出了一些更改并提交到了远程仓库。Bob在项目中添加了一个新文件file2.txt并且更新了README.md。
远程仓库现在看起来像这样
exampleproject/
│
├── README.md (updated)
├── file1.txt
└── file2.txt (new)步骤 3Alice 获取更新
Alice已经在她的本地分支上工作了她想看看团队成员是否有任何更新。她还不想合并这些更改到她的工作中所以她决定先获取更新。她执行
git fetch origin该命令联系了远程仓库“origin”下载了自Alice上次克隆或获取以来其他人所做的所有提交。但是Alice的当前工作目录还没有改变。她的本地仓库现在包含了对远程更改的引用但她的工作目录还是旧的状态
exampleproject/ (Alices working directory)
│
├── README.md (old version)
└── file1.txt她现在可以查看远程分支上的提交了解发生了哪些更改。如果Alice决定她现在想合并这些更改她可以使用git merge或git rebase将这些新更改应用到她的当前分支。
总结
在这个例子中
git clone是Alice用来最初获取项目的方法。当项目有更新Alice使用git fetch来了解更改但她的本地工作未受到影响。这给了Alice一个机会来审查更改然后她可以决定最佳的合并或重新设置基础的策略而不是盲目地接受所有新更改。 _____________________ 让我们继续Alice的例子探讨她是如何查看更改并将它们合并到她的本地分支的。
步骤 4审查更改
在执行了git fetch origin之后Alice想要查看自从她上次更新以来Bob在远程仓库上具体做了哪些更改。她可以查看远程分支的最新状态而无需更改本地分支。为了做到这一点Alice可以使用git log命令
git log main..origin/main这条命令会显示main分支和origin/main即远程的main分支之间的差异。Alice现在能看到Bob的提交记录了解他添加了file2.txt并更新了README.md。
步骤 5合并更改
Alice决定Bob的更改对她当前的工作没有影响并且她想把这些更改合并到她的本地main分支。她首先确保自己在正确的分支上
git checkout main然后Alice可以使用git merge命令来合并远程仓库的更改
git merge origin/main这条命令将origin/main即她刚刚获取的远程更改合并到了她当前的main分支。如果有任何冲突Git将通知Alice她需要手动解决这些冲突。
合并完成后Alice的工作目录现在将包括Bob所做的更改
exampleproject/ (Alices working directory)
│
├── README.md (updated)
├── file1.txt
└── file2.txt (new)如果Alice希望以一种可以重新组织提交历史的方式来整合更改她可能会选择使用git rebase而不是git merge。使用rebase可以为项目历史创建一个更清晰的、线性的提交历史但它会改变提交ID并可能更复杂一些。
总结
在这个情景中Alice使用了git fetch来安全地查看项目中的更新审查了这些更改并决定了最佳的方法来整合这些更新到她的工作中无论是通过合并还是变基。这种方式使她能够保持对本地工作环境的完全控制同时又能保持与远程仓库的同步。 _____________________ 当然可以。我们继续Alice的故事这次她选择使用git rebase来整合更改。git rebase是另一种合并来自不同分支的更改的方法但它通过在一系列提交之上重新应用更改来创建一种线性的提交历史。
步骤 6使用git rebase整合更改
Alice已经用git fetch获取了最新的远程仓库更改现在她决定使用git rebase来整合这些更改。她选择rebase的原因是想保持提交历史的清晰性因为rebase会重写提交历史使得项目的历史看起来像是一条直线而非merge产生的多线条状。
假设Alice在main分支上有一些还没推送的本地提交而Bob的更改已经在远程的main分支。以下是Alice如何将这些远程更改重新应用到她的本地分支上的
首先她需要确保她在正确的分支上并已经获取了最新的远程更改这一步在前面的git fetch中已完成
git checkout main现在Alice使用git rebase开始变基操作
git rebase origin/main这个命令的作用是
暂停Alice的所有本地提交。将main分支指向与origin/main相同的提交。依次将Alice暂停的提交应用在main分支的顶端。
这个过程改变了提交历史的顺序和/或内容使之看起来像是Alice等待Bob完成他的更改然后才开始在最新版本的项目上工作。如果在此过程中遇到冲突git会暂停rebase并要求Alice解决这些冲突。解决后她可以使用git rebase --continue来继续应用余下的提交。
结果
完成后项目的提交历史将呈现为线性不分叉的即使实际上工作是并行进行的。这使得理解项目历史更加直观因为它避免了由于合并造成的额外的“合并提交”。
Alice的工作目录现在也会反映出Bob的更改同时她自己的更改也被重新应用了
exampleproject/ (Alices working directory)
│
├── README.md (updated)
├── file1.txt
└── file2.txt (new)警告
尽管git rebase有很多优点比如保持提交历史的清晰但它也有缺点。它改变了提交历史这意味着如果在共享或团队协作的分支上使用rebase其他协作者的历史记录与你的不同这可能会导致混乱。通常如果你的分支是共享的那么合并通常是更安全的选择。 _____________________ 当然我将通过一个更具体的场景来解释git rebase的工作原理及其对提交历史的影响。
假设Alice和Bob都在main分支上工作并且仓库的提交历史原本看起来是这样的
A - B - C (origin/main main)↑(Alice和Bob共同的起点)这里的每一个字母A、B、C都代表一个提交。
场景设置
Alice在她的本地main分支上做了一些工作并且做了两个提交形成了以下的提交历史
A - B - C - D - E (main)↑(Alice的新提交)同时Bob也在main分支上做了一些更改并且他先于Alice将这些更改推送到了远程仓库origin使远程的提交历史变成了
A - B - C - F - G (origin/main)↑(Bob的新提交)现在Alice决定将她的更改与远程仓库同步。她首先运行git fetch来获取远程仓库的最新状态但她还没有合并这些更改。
Rebase操作
Alice决定使用git rebase来整合远程仓库中的更改。在她的本地仓库她执行了以下命令
git rebase origin/main以下是rebase过程中发生的事情
Git暂时移除“lifts”Alice的提交D和E。Git把Alice当前的main分支指向G也就是origin/main的最新提交。Git尝试重新应用Alice的提交D和E到分支的顶端。
处理冲突
如果在这个过程中没有遇到冲突Alice的提交历史将变为
A - B - C - F - G - D - E (main)注意我用D’和E’来表示这些提交是重新应用的它们会有新的提交哈希值尽管它们的内容与原先的提交相同。
如果出现冲突例如Alice在提交D中更改的文件Bob在提交F中也更改了那么git rebase将会在达到那个点时停止并提示Alice解决冲突。Alice需要手动解决这些冲突然后
git add .
git rebase --continue这会让rebase进程继续前进。
结果
无论是否遇到冲突完成之后Alice的本地main分支提交历史将呈现为一条没有分叉的直线这意味着所有的更改都是按顺序发生的。尽管Alice和Bob实际上是并行工作但通过使用rebaseAlice的提交历史看起来就像她在Bob完成他的更改之后才开始工作。
这使得提交历史更加整洁也更容易理解每个更改是如何建立在之前的更改之上的。不过值得注意的是因为rebase改变了提交的哈希值因为它们现在基于不同的父提交所以在共享分支上使用rebase需要谨慎因为这可能导致与其他团队成员的历史不一致。 _____________________ git pull就是 git fetch后自动git merge
11 分支和仓库 跟踪分支
跟踪分支通常也被称为“上游分支”是本地分支与远程分支之间的一个链接这意味着你可以直接与你的本地仓库的远程分支进行交互。
如何工作
当你克隆一个仓库Git 会自动创建一个与远程的 main或master分支对应的本地分支并创建一个跟踪关系。这意味着当你执行诸如 git pull 或 git push 这样的命令时Git 知道你想与哪个远程分支交互。
为什么使用
使用跟踪分支的好处包括
简化了从远程获取更新或推送更改的流程。提供了关于本地和远程分支之间差异的信息。
举例说明 创建跟踪分支假设你的同事在远程仓库中创建了一个新分支 feature-x并且你想在本地上与之合作。你可能会这样做 git fetch origin # 更新你的远程分支列表
git checkout --track origin/feature-x # 创建一个新的本地分支它会跟踪远程的 feature-x 分支这样你就创建了一个名为 feature-x 的本地分支它自动“跟踪”远程的 feature-x 分支。这意味着当你使用 git push 或 git pull 时Git 会知道这些操作是针对 origin/feature-x。 检查状态当你在你的跟踪分支上工作并想看看你的本地分支与远程分支之间有何差异时你可以使用 git status这可能会告诉你远程分支比你的本地分支多了几次提交从而提醒你可能需要拉取这些更改。 获取更新由于存在跟踪关系如果你想更新你的本地分支你只需做 git pull这会自动从远程分支获取更改并合并到你的本地分支中因为 Git 知道你的分支跟踪的是哪个远程分支。
通过这种方式跟踪分支简化了与远程分支的交互并帮助团队成员保持最新状态。
12 数据保护 定期备份 使用GitLab内置的备份工具定期创建全站备份。这应包括仓库、数据库、配置文件等。存储备份在不同的物理位置并定期验证备份的完整性。 使用RAID存储 如果使用物理服务器可以设置RAID冗余独立磁盘阵列来提供数据冗余。如果一块硬盘失败RAID配置将保护你免受数据丢失。 数据库复制 如果使用的是高级设置可以配置数据库复制。这意味着你有一个实时的数据库副本在另一台服务器上运行。 故障恢复计划 准备详细的灾难恢复计划。在发生灾难性事件时团队知道如何迅速行动以最大限度地减少数据丢失。 更新和补丁管理 定期应用安全补丁和更新来减少安全漏洞避免因安全问题导致的数据丢失。 访问控制 设置合理的用户和访问权限防止未经授权的更改。 监控系统健康状况 使用系统监控工具来跟踪服务器的健康状况预防可能的硬件故障。
Pull RequestsPR或Merge RequestsMR是什么请举例说明
Pull RequestsPR和 Merge RequestsMR是版本控制协作中的关键概念常用于多人开发的项目中。这些请求允许开发者通知团队成员他们对代码所作的更改请求他人审查这些更改并将它们合并到主分支。这两个术语在功能上非常相似但它们是由不同的Git仓库托管服务使用的GitHub使用“Pull Requests”而GitLab使用“Merge Requests”。
以下是Pull Request或Merge Request的一般流程以及它们是如何用于团队协作的 创建分支 开发者从主代码库通常是main或master分支创建一个新分支在这个新分支上进行开发。这确保了主分支的稳定性即使是在多人同时工作的情况下。 提交更改 开发者在新分支上进行更改这可能包括修复错误、添加新功能等。更改完成后开发者会将这些更改提交到新分支并将该分支推送到远程仓库如GitHub或GitLab。 发起Pull Request/Merge Request 开发者在远程仓库上创建一个PR或MR。这实际上是一种请求要求其他团队成员审查代码、提出反馈或建议并最终将这个分支的更改合并到主分支。 代码审查和讨论 团队其他成员如同事、审查者或维护者审查提交的代码并在PR或MR的评论或讨论区提供反馈。开发者可以根据反馈继续改进代码。 合并或关闭 如果代码审查成功并且更改被接受那么维护者或有权限的团队成员会合并这个请求也就是将这个分支的更改合并到主分支。合并后的代码变更现在是项目代码的一部分。如果代码有问题或者不需要合并PR或MR可以被关闭相关的更改也就不会合并到主分支。
通过Pull Requests或Merge Requests整个团队能够更有效地协作增强代码质量控制并保持代码库的整洁和组织性。此流程提供了一个透明、可审计的变更管理机制使所有团队成员都能看到什么时候、为什么以及如何进行代码更改。
