WIP是什么
在MR（Merge Request 或代码合并请求）中，WIP 是"Work In Progress" 的缩写，意思是"正在进行中"或"在制品"。当一个MR 被标记为WIP，通常表示它尚未准备好被合并，可能还在开发中，或者需要进一步的修改和完善。
WIP 的作用:
避免不成熟的代码被合并:
在开发过程中，如果一个MR 还没有完成，或者存在一些问题，将其标记为WIP 可以防止其他开发者在不了解情况的情况下将其合并，避免引入错误或不稳定的代码。
提醒其他开发者:
WIP 状态可以提醒其他开发者，这个MR 还在开发中，不要将其当做已完成的代码进行处理。
便于协作:
WIP 状态可以方便开发者在MR 中进行协作，共同完成代码的开发和完善。
如何使用WIP:
在MR 标题前添加 [WIP] 前缀:
这是一种常见的做法，例如将MR 标题改为 [WIP] 修复用户登录bug。
使用项目管理工具的WIP 状态:
一些项目管理工具，如GitLab，提供了WIP 状态的设置，可以直接在MR 中设置。
移除 [WIP] 前缀或取消WIP 状态:
当MR 准备好被合并时，需要移除 [WIP] 前缀或取消WIP 状态，表示它已经完成并可以被合并。
总结:
WIP 是在开发协作中常用的一个标记，表示MR 还在开发中，需要进一步完善。通过使用WIP 状态，可以避免不成熟的代码被合并，方便开发者之间的协作，并提高代码质量。
MR 的状态
MR (Merge Request/合并请求) 在GitLab 和其他版本控制系统中，通常有以下几种状态：Draft (草稿), Open (打开), Merged (已合并), Closed (已关闭),以及Reverted (已回滚)。
处理WIP (Work in Progress，正在进行中的工作) 的合并请求，通常需要先将其从Draft 状态转为Open 状态，然后才能进行代码审查和合并。
Draft 和 WIP区别
在MR（Merge Request，合并请求，常见于GitLab、GitHub等代码协作平台）的语境中，WIP （Work In Progress，工作进行中）和Draft（草稿）是两种标记未完成状态的机制，用于提示团队成员当前MR的进度，避免误合并。两者的核心功能相似，但在细节和平台支持上存在差异：
一、定义与核心作用
WIP（Work In Progress）
字面意为"正在进行的工作"，用于标记MR处于未完成状态，开发者可能还在持续提交代码、修复问题或进行测试，暂时不希望被审核或合并。
Draft（草稿）
意为"草稿"，与WIP功能一致，同样用于标记MR尚未完成，处于待完善状态，明确传递"暂不适合合并"的信号。
二、主要区别
维度
WIP
Draft
平台支持
多见于GitLab（原生支持），GitHub需通过标签或约定实现。
GitHub（原生支持，2019年推出）、GitLab（后期也支持）等主流平台原生支持。
触发方式
GitLab中通常在MR标题前加[WIP]前缀，或使用专用按钮标记。
直接通过平台按钮（如GitHub的"Convert to draft"）标记，无需手动修改标题。
状态标识
标题显示[WIP]前缀，平台会自动阻止合并（灰色合并按钮）。
标题旁显示"Draft"标签，合并按钮同样被禁用，视觉上更醒目（如GitHub显示黄色"Draft"徽章）。
转换逻辑
移除[WIP]前缀后，自动变为可合并状态。
需手动点击"Ready for review"按钮，明确标记为"已准备好审核"，状态转换更正式。
使用场景
更偏向"临时标记"，例如中途保存进度、等待依赖项。
更强调"流程化"，适合需要明确区分"草稿"和"待审核"阶段的团队协作。
三、本质差异与团队协作影响
形式与规范度
WIP依赖标题前缀（如[WIP]），属于"约定俗成"的标记方式，灵活但可能因团队习惯不同而不统一。
Draft是平台原生功能，通过按钮操作，状态变更更规范，且在UI上有明确标识（如徽章、颜色区分），减少沟通成本。
审核流程关联
WIP状态下，MR仍可被评论，但合并按钮被禁用，适合"边开发边讨论"的场景。
Draft状态在GitHub中会默认不通知审核者（需手动邀请），避免过早打扰他人；转为"Ready for review"时会自动发送通知，更符合审核流程设计。
平台兼容性
WIP在GitLab中是原生支持的功能（标题加[WIP]即生效），但在GitHub中需通过第三方工具或团队约定实现，原生不支持。
Draft是GitHub的原生功能，GitLab在13.2版本后也支持（称为"Draft MR"），跨平台兼容性更优。
四、总结
WIP：更灵活的"临时标记"，依赖标题前缀，适合快速标记未完成状态，常见于GitLab或习惯轻量化协作的团队。
Draft：平台原生的"正式草稿"功能，流程更规范，状态转换清晰，适合重视审核流程、需要明确阶段划分的团队，在GitHub中更常用。
两者核心目的一致------避免未完成的代码被合并，选择哪种方式主要取决于团队使用的平台（如GitHub优先用Draft，GitLab可用WIP或Draft）和协作习惯。