Git笔记(22) 项目贡献要点

视觉SLAM笔记
视觉SLAM十四讲学习笔记
氢键H-H


1. 项目影响因素

因为 Git 非常灵活,人们可以通过不同的方式来一起工作
所以描述应该如何贡献并不是非常准确——每一个项目都有一点儿不同
影响因素包括

  • 活跃贡献者的数量
  • 使用的工作流程
  • 提交权限
  • 可能包含的外部贡献方法

1.1. 活跃贡献者的数量

积极地向这个项目贡献代码的用户数量以及他们的贡献频率

在许多情况下,可能会有两三个开发者一天提交几次,对于不活跃的项目可能更少
对于大一些的公司或项目,开发者的数量可能会是上千,每天都有成百上千次提交
这很重要,因为随着开发者越来越多
在确保自己的代码能干净地应用或轻松地合并时会遇到更多问题:

  • 提交的改动可能表现为过时的
  • 正在做改动或者等待改动 被批准应用时 被合并入的工作 严重损坏

如何保证代码始终是最新的,并且提交始终是有效的?


1.2. 使用的工作流程

是中心化的吗,即每一个开发者都对主线代码有相同的写入权限?
项目是否有一个检查所有补丁的维护者或整合者?
是否所有的补丁是同行评审后批准的?
是否参与了那个过程?
是否存在副官系统,必须先将自己的工作提交到上面?


1.3. 提交权限

是否有项目的写权限会使向项目贡献所需的流程有极大的不同
如果没有写权限,项目会选择何种方式接受贡献的工作?
是否甚至有一个如何贡献的规范?

所有这些问题都会影响实际如何向一个项目贡献
以及对你来说哪些工作流程更适合或者可用


2. 提交准则

Git 项目提供了一个文档,其中列举了关于创建提交到提交补丁的若干好的提示
可以在 Git 源代码 中的 Documentation/SubmittingPatches 文件中阅读它


2.1. 检查空白错误

首先,不会想要把空白错误提交上去
根据 git help diff 的描述,结合下面给出的图片
空白错误是指行尾的空格、Tab 制表符,和行首空格后跟 Tab 制表符的行为

Git 提供了一个简单的方式来检查这点
在提交前,运行 git diff --check,它将会找到可能的空白错误并列出来
在这里插入图片描述
这样可以知道提交中是否包含空白问题


2.2. 独立变更

接下来,尝试让 每一个提交 成为 一个逻辑上的独立变更集
如果可以,尝试让改动可以理解:
不要在整个周末编码解决五个问题,然后在周一时将它们提交为一个巨大的提交
即使在周末期间无法提交,在周一时使用暂存区域将工作最少拆分为每个问题一个提交
并且为每一个提交附带一个有用的信息


2.3. 提交信息

有一个创建优质提交信息的习惯会使 Git 的使用与协作容易的多
一般情况下,信息应当以少于 50 个字符(25个汉字)的单行开始且简要地描述变更
接着是一个空白行,再接着是一个更详细的解释
Git 项目要求一个更详细的解释,包括做改动的动机和它的实现与之前行为的对比

在这些信息中使用 现在时态祈使语气 也是一个好想法
换句话说,使用命令
使用 “Add tests for” 而不是 “I added tests for” 或 “Adding tests for
这里是一份最初由 Tim Pope 写的模板:

修改的摘要(50 个字符或更少)

如果必要的话,加入更详细的解释文字。在
大概 72 个字符的时候换行。在某些情形下,
第一行被当作一封电子邮件的标题,剩下的
文本作为正文。分隔摘要与正文的空行是
必须的(除非你完全省略正文);如果你将
两者混在一起,那么类似变基等工具无法
正常工作。

空行接着更进一步的段落。

  - 句号也是可以的。

  - 项目符号可以使用典型的连字符或星号
    前面一个空格,之间用空行隔开,
    但是可以依据不同的惯例有所不同。

出于简洁性的原因这里不会有像这样漂亮格式的信息
相反,平时还是经常使用 -m 选项的 git commit
就如:“老师的话可以听,样子不可以学”


参考: git
以上内容,均根据git官网介绍删减、添加和修改组成


相关推荐:

Git笔记(21) 分布式工作流程
Git笔记(20) 配置服务器
Git笔记(19) 生成SSH公钥
Git笔记(18) 搭建服务器Git
Git笔记(17) 协议


谢谢

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: Age of Ai 设计师: meimeiellie
应支付0元
点击重新获取
扫码支付

支付成功即可阅读