分享一个git日常开发流程

分享一个使用git的工作流程：每天上班之前从远程仓库更新master分支到本地开发分支，每天下班前提交代码到远程开发分支，定期将测试后的远程开发分支跟master分支合并。下面用一个流程图来展示整个流程的全貌：
否
是
开始新一天开发
切换到本地 dev 分支
拉取远程 master 到本地
将 master 合并到 dev

（解决可能的冲突）
进行日常开发
下班前提交代码到本地仓库
推送本地 dev 到远程 dev
是否定期测试通过？
创建 Merge Request
代码评审与测试
合并到 master 分支

下面，拆解图中的每一个日常和定期操作步骤。

🔄 每日开发前：同步远程 Master 到本地 Dev

这个操作的目的是将主干的最新更新合并到你的开发分支，保证你的开发起点是最新的。

确保你在本地 dev 分支：
bash 复制代码
```
git checkout dev
```
拉取远程 master 分支的最新代码：
bash 复制代码
```
git fetch origin master
```
这条命令只会获取更新，不会改变你本地任何文件。
将远程 master 分支的更新合并到本地 dev 分支：
bash 复制代码
```
git merge origin/master
```
关键提示 ：此时可能会发生代码冲突。如果发生，Git会提示你。你需要：
- 手动打开冲突文件，解决冲突（删除 <<<<<<<， =======， >>>>>>> 这些标记，保留正确的代码）。
- 解决所有冲突后，执行 git add . 标记冲突已解决。
- 最后执行 git commit 来完成这次合并。

💾 每日下班前：提交本地 Dev 到远程 Dev

这个操作是保存你一天的工作成果，并备份到远程服务器。

添加所有更改的文件到暂存区（也可指定具体文件）：
bash 复制代码
```
git add .
# 或添加特定文件 git add file1.py file2.js
```

提交更改到本地仓库：

bash 复制代码

git commit -m "清晰的提交说明，例如：完成用户登录模块前端界面"

推送本地 dev 分支到远程 origin 的 dev 分支：
bash 复制代码
```
git push origin dev
```
如果是第一次推送本地 dev 分支，需要使用 git push -u origin dev 来建立追踪关系，之后直接 git push 即可。

🚀 定期操作：将测试通过的 Dev 合并到 Master

这个操作通常在一个功能完成并通过测试后进行，建议在GitLab网页端完成，因为它提供了代码评审（Merge Request）的流程。

在GitLab上创建合并请求（Merge Request）：
- 进入你的项目页面。
- 点击侧边栏或仓库上方的 "Merge Requests" -> "New merge request"。
- 源分支（Source branch） 选择 dev，目标分支（Target branch） 选择 master。
- 填写标题和描述，说明本次合并的内容、测试情况等，并指派给相关同事评审。
代码评审与测试：
- 团队成员在Merge Request页面内评论代码、讨论修改。
- 可以利用GitLab CI/CD自动运行测试，确保合并不会破坏主线功能。
合并到 Master：
- 评审通过且所有测试成功后，由有权限的人员（可能是你或项目负责人）点击 "Merge" 按钮。
- 通常选择 "Merge commit" 方式，这样会生成一个合并提交记录，历史更清晰。

⚠️ 重要注意事项与最佳实践

先同步，后开发 ：养成每天第一步先 git fetch + git merge 的习惯，能极大减少后续合并的冲突范围和难度。
勤提交，描述清：本地提交可以频繁一些，但推送到远程前，建议整理成有逻辑的提交。清晰的提交信息对日后排查问题至关重要。
利用 git status ：任何时候不确定状态，运行 git status，Git会给出下一步该做什么的提示。
保护 Master 分支 ：在GitLab项目设置中，建议将 master 分支设置为"受保护分支"，禁止直接 push，强制通过Merge Request合并，这是保证代码质量的关键门禁。