企业官网建设流程全解析

涟源网络建站,推广途径有哪些,wordpress版面混乱,wordpress抓取新闻一、详细解释#xff0c;什么是merge和rebase 假设你和团队在开发一个项目#xff0c;主分支叫 main#xff0c;你新建了一个分支 feature 来加新功能。 你在 feature 分支上写了两个提交#xff1a;C 和 D。 此时 main 分支上别人也加了一个提交 B。 历史看起来像这样什么是merge和rebase假设你和团队在开发一个项目主分支叫main你新建了一个分支feature来加新功能。你在feature分支上写了两个提交C 和 D。此时main分支上别人也加了一个提交 B。历史看起来像这样A --- B (main) \ C --- D (feature)现在你要把main的最新代码合并到你的feature分支或者反过来把你的功能合并到mainGit 提供了两种方式merge 和 rebase。1. merge合并—— 最常用、最安全的方式命令gitcheckout featuregitmerge main结果Git 会创建一个新的“合并提交”叫 merge commit把两个分支的代码合在一起。历史变成A --- B -------- M (merge commit) ← 当前在 feature 和 main 上 \ C --- D -------/特点历史有“分叉”和“汇合”看起来像一棵树真实反映了并行开发的过程多了一个合并提交 M完全不改动原来的提交C、D、B 都不变超级安全就算你已经把分支 push 到远程也随便 merge不会影响别人适合场景团队协作、把完成的特性合并到主分支时用 merge。2. rebase变基—— 让历史变得“一条直线”命令gitcheckout featuregitrebase main结果Git 把你的提交 C 和 D“搬家”先放到main的最新提交 B 后面重新生成两个新提交 C’ 和 D’内容一样但 commit ID 变了。历史变成A --- B --- C --- D ← 现在 feature 和 main 都在这条直线上特点历史变成一条干净的直线看起来就像你是在最新的main上直接开发的没有多余的合并提交会改写你的提交历史生成新的 commit ID如果你已经 push 过feature分支到远程再 rebase 后必须强制 pushgit push --force-with-lease可能会把别人搞混乱适合场景你在自己本地的特性分支还没完成、还没给别人看的时候用 rebase 把代码更新到最新并顺便整理提交让历史更干净。二、实际协作开发中的典型使用场景更清晰可视化说明在团队协作开发中通常有一个公共主分支常见名为main或master以下统一用main所有稳定代码都最终合并到这里。你想添加新功能时不会直接在main上修改而是采用以下标准流程。这个流程中rebase 的作用就是保持你的分支始终基于最新的 main避免最后合并时出现大量冲突。完整流程步骤 更清晰的可视化历史(1)从最新的 main 开新分支你先确保本地 main 是最新的然后新建一个特性分支feature branch。gitcheckout main#切换到分支maingitpull origin main# 确保本地 main 是最新的gitcheckout -b feature/new-login# 新建并切换到特性分支初始历史可视化新分支刚创建时它和 main 指向完全相同的最新提交假设当前 main 的最新提交是 X。... --- W --- X (main) ↑ feature/new-login刚创建还没有任何自己的提交(2)你在 feature 分支上开发你写了几个自己的提交Y、Z。历史变成... --- W --- X (main) \ Y --- Z (feature/new-login) # 你自己的提交(3)开发期间别人往 main 合并了新代码其他人完成了别的功能提 PR 并合并到了 main新增了提交 P 和 Q。历史变成... --- W --- X --- P --- Q (main) # 别人新增的 P、Q \ Y --- Z (feature/new-login) # 你的分支还停留在旧的 X 上问题出现了你的分支现在基于“旧版本”的 main停留在 X而远程 main 已经前进到 Q。继续开发的话你的代码缺少别人最新的 P 和 Q可能导致功能冲突别人改了你也要改的地方最后合并时冲突爆炸(4)用 rebase 把你的修改“移植”到最新的 main 上gitfetch origin# 先拉取远程最新代码gitrebase origin/main# 把你的 Y、Z 重新应用到最新的 main 上rebase 的执行过程Git 先把你的 Y、Z “暂时拿走”把 main 的最新提交P、Q放到你的分支下面然后把你的 Y、Z 一个个“重放”上去生成新的 Y’、Z’内容完全一样只是 commit ID 变了结果历史... --- W --- X --- P --- Q --- Y --- Z (feature/new-login)好处你的分支现在基于最新的 main自动包含了别人所有的修改你可以立刻发现并解决冲突冲突量通常小得多因为是逐步解决历史变成一条直线看起来非常整洁如果中途有冲突Git 会暂停让你解决解决完运行git rebase --continue。(5)开发完成清理提交gitrebase -i origin/main# 交互式 rebase你可以把零散的 Y’、Z’ 等提交合并squash成 1~3 个有意义的提交修改提交消息让它更清晰、专业这样提 PR 时reviewer 看得非常舒服。(6)推到远程提 PR并用 merge 合并到 maingitpush --force-with-lease origin feature/new-login# 因为 rebase 改了历史需要强制推送在 GitHub/GitLab 上提 Pull Request审核通过后用 merge 方式合并到 main保留合并记录安全最终 main 历史普通 merge... --- W --- X --- P --- Q --- Y --- Z --- M (merge commit)或者用 “Squash and merge”更干净... --- W --- X --- P --- Q --- 新合并提交包含你所有修改三、对比1.不做 rebase直接最后 merge... --- W --- X --- P --- Q (main) \ Y --- Z ---------------- M (大 merge commit)最后可能一次性解决大量冲突PR 历史很乱全是你的零散提交(2).定期 rebase 最后 merge... --- W --- X --- P --- Q --- Y --- Z (你的分支干净线性) \ M (最终合并)开发过程顺畅冲突早发现早解决PR 历史清晰review 友好主分支历史安全整洁这就是协作开发中最常见、最推荐的 rebase 使用场景在你的个人特性分支上定期 rebase 到最新的 main保持代码同步并让历史更漂亮。这样既充分发挥了 rebase 的优势又完全避免了它的风险。四、其它情况1.在提 Pull Request / Merge Request 前清理提交历史你在个人分支上写了 15 个提交很多是“fix typo”“test”“oops 错了”提 PR 前想让 reviewer 看得舒服做法gitrebase -i origin/main# 交互式 rebase在编辑器里你可以squash合并小提交成大提交reword修改提交消息让它更有意义drop删除无用提交reorder重排提交顺序结果PR 历史从 15 个乱提交变成 3~5 个清晰、有逻辑的提交review 通过率大幅提升。2.解决冲突时逐步处理比大 merge 更友好rebase 时如果有冲突Git 会暂停在每个有冲突的提交上让你一个个解决比一次性 merge 所有冲突更可控尤其当主分支变化很大时5.注意事项不要对别人可能在开发的分支rebase这会弄乱别人的提交历史因为你rebase后前面的commit id会改变别人继续开发会找不到历史提交。