git 开源代码提交流程

2022-10-12 develop git

这里以 GitHub 上的工作流程为例，讲解如何维护、提交代码。

简介

在 GitHub 上提交代码大致分成如下几步：

  1. 先 Fork 别人的项目到自己的仓库中去。
  2. Clone 到本地进行修改，由于是自己的仓库，所以想怎么改都行，例如可以使用自己熟悉的分支管理策略。
  3. 修改完 bug 后，当然，也可以是某个特性，先 push 回自己的仓库。
  4. 如果你觉得自己已经修改完了，那么就可以 Pull Request，相当于请作者看一下自己的修改。
  5. 最后如果作者也认同这个修改，那么他会 Merge 到主干分支上，而你也就成了这个项目的 Contributor。

是不是很简单。

另外，还会涉及到与社区代码的同步，这里简单介绍一种同步策略，自己 Fork 的仓库主干始终与社区代码保持一致，用其它分支做 bugfix 或者特性开发。

----- 先获取已经fork的代码库，可以自己维护代码
$ git clone https://github.com/YourName/SomeRepo.git
----- 切换到仓库目录然后添加社区的仓库
$ git remote add community https://github.com/Community/Repo.git

----- 获取社区库的最新提交
$ git fetch community
----- 切换到自己的分支上
$ git checkout master
----- 合并社区的代码
$ git merge community/master

----- 将代码rebase到自己的分支上
$ git checkout YourDevBranch
$ git rebase master

在 rebase 过程中可能会涉及到冲突，只需要解决即可。

提交信息

提交信息中一般会包含常用的提示，例如：

feat(feature): 新增/修改特性
fix(bugfix): 修复bug
docs(documentation): 文档
style: 调整格式，不会影响程序运行，例如修改空白字符、格式等等
refactor: 重构，对原有功能实现进行优化
perf: 优化提升性能
test: 增加测试用例
chore: 代码构建或者辅助工具的调整
revert: 撤销之前的提交

黑话

如果经常逛逛 Github ，那么经常会看到很多的 Code Review 中各种奇葩的缩写，各种老司机开车炫富，不过第一次看到时还是一脸懵逼，所以，这里简单整理下一些常见缩写的含义。

  • PR Pull Request. 拉取请求，给其他项目提交代码
  • LGTM Looks Good To Me. 代码已经过 Review 可以合并啦
  • SGTM Sounds Good To Me. 同上
  • WIP Work In Progress. 通常某个大修改，可以在 PR 中标记 WIP 以告诉项目维护者这个功能还未完成
  • PTAL Please Take A Look. 一般同时会 @SomeBody ，告诉他来瞅瞅是否有问题
  • TL;DR Too Long; Didn’t Read. 长篇文章开头总结部分，提示用户这篇内容篇幅较长，如不想深入探讨或时间有限，可看总结