跳到主要内容

115 篇博文 含有标签「开发工具与环境」

开发工具和环境配置相关文章

查看所有标签

Git 放弃当前分支使用远程分支

· 阅读需 1 分钟
素明诚
素明诚
Full stack development

用 dev 分支举例子想要放弃本地 dev 分支上所有的更改，并且完全同步远程 dev 分支的代码，您可以删除本地的 dev 分支然后重新创建它，以匹配远程分支的状态。以下是步骤

首先，确保您没有在 dev 分支上，因为您不能删除当前检出的分支

git checkout main  # 切换到main分支或任何其他分支

删除本地的 dev 分支

git branch -D dev

拉取远程 dev 分支并在本地创建一个新的 dev 分支

git fetch origin
git checkout -b dev origin/dev

-b 标志告诉 Git 创建一个新的分支并立即切换到这个新分支。origin/dev 指定了新分支应该跟踪的远程分支

这样做的好处是您不需要处理任何合并冲突，因为您直接采用了远程分支的状态。适用于你的同事在处理完冲突进行了硬重置，你可以直接先保存一份代码，直接使用远程分支，进行修改。

systemd 的基本使用

· 阅读需 2 分钟
素明诚
素明诚
Full stack development

服务控制​

  • 启动服务(可简写)
sudo systemctl start apache2.service
sudo systemctl start apache2
  • 停止服务
sudo systemctl stop apache2.service
  • 重新启动服务
sudo systemctl restart apache2.service
  • 查看服务状态
systemctl status apache2.service

服务开机自启设置​

  • 启用服务开机自启
sudo systemctl enable apache2.service
  • 禁用服务开机自启
sudo systemctl disable apache2.service

系统状态查看​

  • 查看服务的网络连接
ss -tnlp | grep apache2
  • 查看所有日志
journalctl -u apache2.service
  • 查看最新日志
journalctl -u apache2.service -e
  • 列出所有运行的服务
systemctl list-units --type=service
  • 查看系统日志
journalctl

定时器和计划任务​

  • 创建一个文件 /etc/systemd/system/backup.service 来定义要执行的任务：
plaintextCopy code[Unit]
Description=Daily Backup

[Service]
ExecStart=/usr/local/bin/backup.sh
  • 创建一个文件 /etc/systemd/system/backup.timer 来定义定时器：
plaintextCopy code[Unit]
Description=Runs backup every day at 2am

[Timer]
OnCalendar=*-*-* 020000
Unit=backup.service

[Install]
WantedBy=timers.target
  • 启动并启用定时器：
sudo systemctl start backup.timer
sudo systemctl enable backup.timer

创建和管理自定义服务​

  • 以下是一个简单的自定义服务单元文件的例子，该文件应保存为 /etc/systemd/system/custom.service
plaintextCopy code[Unit]
Description=Custom Service

[Service]
ExecStart=/usr/local/bin/custom.sh
Restart=always

[Install]
WantedBy=multi-user.target
  • 在创建了单元文件后，可以通过以下命令启动、停止或重新启动服务：
sudo systemctl start custom.service
sudo systemctl stop custom.service
sudo systemctl restart custom.service

GitHub Actions 的工作流文件的主要模块

· 阅读需 1 分钟
素明诚
素明诚
Full stack development

名称 (name): 描述工作流程的名称，这在 GitHub 的操作 UI 中是可见的。

name: My CI/CD Workflow

触发器 (on): 定义什么时候运行工作流程。它可以是 GitHub 事件（如 push、pull_request）或者定时任务。

 on: [push]

或者更复杂的触发器：

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

工作 (jobs): 工作是一组要在同一个运行环境中执行的步骤。你可以定义多个工作，它们可以并行执行或按照特定的依赖顺序执行。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      ...
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      ...

步骤 (steps): 步骤是在工作中执行的单个任务。每个步骤可以是执行命令、运行脚本或使用 GitHub Actions 市场上的现有操作。

 steps:
  - name: Check out code
    uses: actions/checkout@v2
  - name: Run tests
    run: npm test

环境变量和路径 (env 和 with): 为步骤或整个工作设置环境变量或输入参数。

env:
  NODE_ENV: production
steps:
  - name: Use Node.js
    uses: actions/setup-node@v2
    with:
      node-version: '14'

策略 (strategy): 定义工作的策略，例如矩阵构建，它可以同时测试多个版本或配置。

 strategy:
  matrix:
    node-version: [12.x, 14.x, 16.x]

Gitignore如何优雅地忽略不必要的文件

· 阅读需 1 分钟
素明诚
素明诚
Full stack development

使用 .gitignore 排除不必要的文件

在使用 Git 进行版本控制时，经常有一些文件或目录我们不希望加入到版本控制中，例如依赖文件、配置文件或是编译生成的文件。.gitignore 文件就是用来帮助我们实现这个目的的。

创建 .gitignore 文件

在你的 Git 项目根目录下，新建一个 .gitignore 文件。

# .gitignore 内容示例

# 依赖文件
/node_modules
/.pnp
.pnp.js

# 测试产生的文件夹
/coverage

# 生产构建目录
/build

# 其他常见不需要的文件
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*

.gitignore 过滤规则

  • # 开头的行为注释。
  • / 开头表示目录。
  • * 用于匹配多个字符。
  • ? 可以匹配任何单个字符。
  • [] 用于匹配字符集中的任何字符（例如，[abc] 将匹配任何 a、b 或 c 字符）。
  • 使用 ! 开头的模式将排除之前定义的模式。

通过上述规则，你可以轻松地定制 .gitignore，确保只有需要的文件被加入到 Git 版本控制中。

解决GitHub push 不上去

· 阅读需 1 分钟
素明诚
素明诚
Full stack development

一、配置 host 方法​

1.https://github.com.ipaddress.com/​

12c873d84a956c9ad9c37eefcc30f934

2.https://fastly.net.ipaddress.com/github.global.ssl.fastly.net#ipinfo​

ef152ae3bf890ac8ed00326087af6e7e

3.https://github.com.ipaddress.com/assets-cdn.github.com​

961478a1d45f15436e95c381153e2cc9

4.打开 hosts 文件，把记录的 IP 和对应的域名写上​

140.82.112.3 github.com //图1
199.232.69.194 github.global.ssl.fastly.net    //图2
185.199.108.153 assets-cdn.github.com  //图3
185.199.109.153 assets-cdn.github.com  //图3
185.199.110.153 assets-cdn.github.com	 //图3
185.199.111.153 assets-cdn.github.com  //图3

二、修改本地 host​

140.82.112.3 github.com

刷新本地的 DNS​

ipconfig /displaydns

其他错误​

error 11053​

git config --global http.postBuffer 524288000

三、刷新代理​

配置/取消 http 代理​

# 配置socks5代理
git config --global http.proxy 'socks5://127.0.0.1:1080'
git config --global https.proxy 'socks5://127.0.0.1:1080'
# 配置http代理
git config --global http.proxy 'http://127.0.0.1:1080'
git config --global https.proxy 'https://127.0.0.1:1080'
git config --global --unset http.proxy

配置/取消 HTTPS 代理​

git config --global https.proxy
git config --global --unset https.proxy

四、指定代理的作用域​

#只对github.com
git config --global http.https://github.com.proxy socks5://127.0.0.1:7890

四种方法，最终肯定会解决你的问题，如果能开了代理，可以直接指定本地的代理软件，也就是按照四进行操作

DNS 的工作原理

· 阅读需 3 分钟
素明诚
素明诚
Full stack development

1.浏览器缓存检查:​

首先，浏览器会查看自己的缓存。如果你之前访问过 www.sumingcheng.cn，浏览器可能已经保存了它的 IP 地址。如果找到了，就会直接使用这个 IP 地址去访问，整个过程在这里结束！

2.操作系统缓存检查:​

如果浏览器没有相关缓存，它会查询操作系统的 DNS 缓存。操作系统每次成功解析域名后都会将结果暂时存储。如果操作系统缓存中有该域名的 IP 地址，查询过程在此结束，浏览器会用这个地址去访问网站。

3.本地 DNS 服务器查询:​

如果上述两个缓存都没有结果，浏览器会发出一个系统调用，请求操作系统查询配置好的 DNS 服务器。这个服务器通常是由你的网络服务提供商 (ISP) 设置的，但也可能是其他公共 DNS 服务器，如 Google DNS (8.8.8.8)。

4.真正的 DNS 查询开始:​

a.请求根服务器:​

本地 DNS 服务器首先会查询一个 DNS 根服务器。虽然根服务器不知道 www.sumingcheng.cn 的 IP 地址，但它知道哪些服务器负责 .cn 域名，因此它会返回一个 .cn 的顶级域名 (TLD) 服务器的地址。

b.查询.cnTLD 服务器:​

本地 DNS 服务器随后会向 .cn TLD 服务器发送查询请求。这个服务器会告诉本地 DNS 服务器哪个权威 DNS 服务器负责 sumingcheng.cn 这个域名。

c.查询权威 DNS 服务器:​

然后，本地 DNS 服务器会向 sumingcheng.cn 的权威 DNS 服务器发出请求。这个权威服务器包含了 www.sumingcheng.cn 的确切 IP 地址，并将这个地址返回给本地 DNS 服务器。

5.结果返回给用户:​

权威 DNS 服务器的答案随后被返回给本地 DNS 服务器。本地 DNS 服务器将这个答案传递给用户的操作系统，操作系统再把这个 IP 地址传递给浏览器。现在，浏览器可以使用这个 IP 地址与 www.sumingcheng.cn 的服务器建立连接。

6.结果被缓存:​

为了加速未来的 DNS 查询，该 IP 地址会在多个级别被缓存：浏览器、操作系统、以及本地 DNS 服务器。

整个过程结束

Git 的 Amend 功能

· 阅读需 2 分钟
素明诚
素明诚
Full stack development

背景​

你可能已经进行了一个提交，但随后意识到遗漏了一些文件或更改。而不是做一个新的提交，你可以使用 "Amend" 来将这些遗漏的文件添加到前一个提交中。但是这个提交会改变 hash

如何使用​

使用 git commit 命令的 --amend 选项来修正当前的提交：

git commit --amend

这会打开一个文本编辑器，让你修改提交消息。保存并关闭编辑器后，提交将被修正。

注意事项：​

  • 如果你不想修改提交消息，只想添加遗漏的文件或更改，你仍然需要打开并关闭编辑器，即使没有做任何更改。
  • 请确保你没有推送之前的提交到远程仓库，否则在尝试推送修正后的提交时可能会遇到问题。如果你已经推送了，你可能需要使用 git push origin branchname --force 来强制推送修正后的提交，但这样做可能会导致与其他开发者的合作问题。所以在 push -f 的时候一定要确认是否提交到了远程分支，是否会覆盖他人分支

没有网络连接的情况下如何将在两个不同的 git 仓库之间共享代码更改

· 阅读需 2 分钟
素明诚
素明诚
Full stack development

1. 仓库 A：生成补丁​

假设你已经在仓库 A 中做了一些更改，并提交了这些更改。

1.1. 首先，导航到仓库 A 的目录：

cd /path/to/repoA

1.2. 使用git format-patch生成补丁。例如，如果你想为最后一个提交生成补丁：

git format-patch -1 HEAD

这会生成一个以.patch结尾的文件。文件名通常包含提交的哈希值和提交信息。

生成指定分支

如果你只想生成 dev 分支中从 6cb7ceaab94573a13d1e2e7fa2095b5456fde5bd 之后的所有提交的补丁，你可以明确指定范围，以确保只考虑 dev 分支的提交。以下是如何做到这一点的命令：

bashCopy code
git format-patch 6cb7ceaab94573a13d1e2e7fa2095b5456fde5bd..dev

这会为 6cb7ceaab94573a13d1e2e7fa2095b5456fde5bd 之后的 dev 分支上的所有提交生成补丁。这样，你就可以确保只是针对 dev 分支的更改生成补丁，而不会包括其他分支的提交。

2. 仓库 B：应用补丁​

现在，你需要将上一步生成的补丁文件从仓库 A 传输到仓库 B 的机器上。你可以使用电子邮件、USB 驱动器、网络共享等任何方法来做到这一点。

2.1. 在仓库 B 的机器上，导航到仓库 B 的目录：

cd /path/to/repoB

2.2. 使用git apply来应用补丁：

git apply /path/to/patchfile.patch

这样，仓库 B 就会包含仓库 A 的那些更改。

注意：如果补丁不能直接应用，git apply可能会报错。这通常是因为两个仓库之间的代码有较大的差异。在这种情况下，你可能需要手动解决冲突或在应用补丁时使用某些额外的选项。