在GitHub上与多人协作的Branch运用基本规则与命名法
通过本系列之前的文章,您已经学习了从GitHub的基本用法到利用`Fork`和`Pull Request`为协同开发项目做贡献的方法。相信无论是个人开发还是为开源项目做贡献,对您来说都已不再是难事。
作为本系列的最后一篇文章,我们将聚焦于为保障团队开发顺利进行的“Branch(分支)运用”。当多人在同一个仓库中工作时,如果没有规则,很快就会陷入混乱。为了让所有成员朝着同一个方向高效地进行开发,让我们来学习一下基本的分支运用规则和清晰易懂的命名规范,力争成为团队开发的高手吧!
为何需要分支运用规则?
如果团队内部没有创建分支的规则,会发生什么呢?
A君可能会创建`feature-A`,B君创建`fix-B`,C君则创建`sato-branch`,每个人都开始用自己喜欢的方式命名分支。这样一来,谁也搞不清楚哪个分支在做什么工作。结果就是,无用的分支林立,合并(merge)错误频发,开发将陷入极大的混乱。
为了防止这种混乱,并顺利推进开发,一个由团队共享的、简单的“分支运用规则(分支策略)”是必不可少的。虽然有像“Git-flow”这样著名的分支策略,但对于初学者来说,首先掌握更简单的“功能分支工作流”的基础就足够了。
基本的分支类型及其职责
在简单的团队开发中,主要会区分使用两种类型的分支。让我们来しっかり理解它们各自的职责。
- `main`分支 (旧称`master`分支)
这是一个神圣的分支,用于存放“始终能够正常运行的、生产环境的代码”。必须绝对避免直接编辑此分支,或将不稳定的代码混入其中。
【规则】: 任何人都不应直接向`main`分支进行提交(commit)或推送(push)。所有的更改都应该通过功能分支,经由Pull Request进行合并。
- 功能分支 (Feature Branch)
这是一种为执行特定任务(如开发新功能、修复bug、进行小修改等)而创建的工作用分支。有时也称为“主题分支”。它从`main`分支分叉出来,在工作完成后再合并回`main`分支。这是一种生命周期短暂的分支,工作完成后即被删除。
【规则】: 无论多小的修改,都务必先创建一个新的功能分支再开始工作。
清晰易懂的分支命名规则
为了让任何人都能看懂功能分支的用途,一个一致的命名规则至关重要。通常,“`前缀/工作内容`”这种形式被广泛使用。
前缀的种类与具体示例:
feature/: 用于添加新功能时- 示例:
feature/add-login-page(添加登录页面)
- 示例:
fix/: 用于修复bug时- 示例:
fix/correct-header-layout-bug(修复页眉布局错乱的bug)
- 示例:
refactor/: 用于在不改变功能的前提下提升代码质量(重构)时- 示例:
refactor/optimize-database-query(优化数据库查询)
- 示例:
docs/: 用于修改文档(如README.md)时- 示例:
docs/update-installation-guide(更新安装步骤)
- 示例:
只要团队共享这样的规则,任何人仅通过看分支名就能一目了然地知道该分支正在进行什么工作。
实践!团队开发的基本流程
那么,让我们结合命令,来看看基于这些规则的团队开发基本流程。
第一步:获取最新的`main`分支
在开始工作前,务必先将本地的`main`分支更新到远程仓库的最新状态。首先切换到`main`分支。
git checkout main
接下来,将远程的最新信息拉取到本地。
git pull origin main
第二步:创建用于工作的功能分支
从最新的`main`分支创建出你的工作分支。这次我们假设要“添加一个联系表单”,并以此为想定来创建分支。
git checkout -b feature/add-contact-form
第三步:进行修改/开发并提交
在新建的分支上,尽情地修改和添加代码。当工作告一段落时,创建一个提交。
git add .
git commit -m "Add basic structure of contact form"
第四步:推送到远程仓库
将创建的功能分支推送到远程仓库。这样,你的工作内容才能首次被团队成员看到。
git push origin feature/add-contact-form
第五步:创建Pull Request并接受审查
推送完成后,在GitHub上针对`main`分支创建一个Pull Request。请求团队成员进行代码审查,并获取反馈。(Pull Request的创建方法请参考上一篇文章)
第六步:合并后删除不再需要的分支
当Pull Request被顺利合并后,用于该项工作的功能分支就不再需要了。为了保持仓库的整洁,我们应该将其删除。
首先,删除远程分支。这通常只需在GitHub的Pull Request页面合并后,点击显示的“Delete branch”按钮即可完成。
[图片:合并后显示的“Delete branch”按钮]
接下来,删除本地还保留的分支。我们先回到`main`分支。
git checkout main
然后,删除不再需要的本地分支。
git branch -d feature/add-contact-form
这样,一个完整的工作周期就结束了。当开始新的工作时,就从第一步开始重复。
总结:简单的规则能拯救团队
多人开发成功的秘诀,不在于记住复杂的规则,而在于所有人都持续遵守简单的规则。只要团队内部彻底执行本次介绍的基本规则,开发效率就会显著提升,并能避免不必要的麻烦。
- 始终保护`main`分支。
- 工作务必在功能分支中进行。
- 彻底执行清晰易懂的命名规则。
- 向`main`分支的合并必须通过Pull Request进行。
- 勤于删除已合并的分支。
通过这个GitHub入门系列,您已经学会了从创建账户到协同开发的基本流程。作为一名Web开发者,这是巨大的一步。请务必将在这里学到的知识作为基础,在实际的项目中活用Git和GitHub。祝您的开发生活更加舒适和富有创造力!