全栈日记

Source: Dev.to

🌟 介绍

作为 DevOps 微实习（DMI）的一部分，第三周重点在于掌握 Git、GitHub 协作工作流，以及使用 Nginx 在 AWS EC2 上部署真实的静态网站。

本周彻底改变了我对以下内容的认识：

• 版本控制系统
• 分支策略
• 开源贡献工作流
• 生产级部署在 Linux 服务器上

本博客记录了完整的实操过程。

第1部分：在本地设置 Git

创建项目仓库

• 项目名称：CodeTrack
• 已初始化 Git：

git init

我的收获

• Git 使用快照来跟踪更改。
• .git 目录存储提交历史。
• 版本控制可以防止代码意外丢失。

第2部分：Git 身份配置

已在本地和全局配置 Git 身份：

git config user.name "Manjay Verma"
git config user.email "..."

关键学习

• 本地配置针对每个仓库生效。
• 全局配置在系统范围内生效。
• 企业环境通常更倾向于使用本地配置。

第3部分：暂存、提交与整洁的历史

创建了 index.html 和 style.css，随后暂存并提交：

git add .
git commit -m "Initial commit: Add index and style files"

做了一个小改动并单独提交。

我学到的

• 干净的提交信息有助于协作。
• 小的提交更易于审查。
• 提交历史讲述了项目的故事。

第4部分：分支工作流（基于功能的开发）

创建一个功能分支：

git checkout -b feature/contact-page

添加了 contact.html 并更新了 index.html，随后合并回 main：

git merge feature/contact-page

关键学习

• 功能分支将开发隔离。
• main 分支保持稳定。
• 这是业界标准的 Git 工作流。

第5部分：GitHub 协作工作流

遵循的步骤：

1. Fork 了上游仓库。
2. 克隆了该 fork。
3. 添加了 upstream 远程。
4. 创建了功能分支。
5. 推送到 origin。
6. 创建了 Pull Request。

git remote add upstream 
git push origin feature/update-readme

我学到的内容

• origin 与 upstream 的区别。
• 为什么在开源项目中需要 fork。
• Pull Request 如何实现协作。

第 6 部分：部署到 AWS EC2（生产级）

实例详情

• 区域：亚太地区（孟买）
• 操作系统：Ubuntu 22.04
• 实例类型：t2.micro（免费套餐）
• 安全组：SSH + HTTP

通过 SSH 连接：

ssh -i codetrack-key.pem ubuntu@

安装 Nginx：

sudo apt update
sudo apt install nginx -y

将静态站点部署到 /var/www/html/。

🌍 实时部署结果

网站已在 AWS EC2 上通过 Nginx 上线，提供了以下实战经验：

• Linux 服务器管理
• 安全组配置
• 公网 IP 设置
• 服务管理（systemctl）

已执行的生产级检查

sudo systemctl status nginx
curl localhost
netstat -tulpn | grep 80

我的收获

• 必须始终确认服务已启动。
• 必须始终测试端口绑定情况。
• 部署只有在验证通过后才算完成。

🚧 面临的挑战

每个问题都加强了故障排除技能。

🎯 实践的关键 DevOps 概念

• Git 内部原理
• 分支策略
• 干净的提交规范
• Fork 与 PR 工作流
• Linux 服务器配置
• Nginx 部署
• 安全最佳实践

🧠 我的最大收获

DevOps 不仅仅是工具——它关乎：

• 清晰的工作流
• 可复现性
• 验证
• 安全意识
• 专业文档

本周让我更接近真实的 DevOps 工程实践。

🚀 接下来是什么？

• 使用 CI/CD 自动化部署
• 使用 GitHub Actions
• 绑定自定义域名
• 使用 Docker 部署

🙌 致谢

感谢 DevOps 微实习（DMI）项目和导师提供的结构化实践指导。