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 个字符的时候换行。在某些情形下，
第一行被当作一封电子邮件的标题，剩下的
文本作为正文。分隔摘要与正文的空行是
必须的（除非你完全省略正文）；如果你将
两者混在一起，那么类似变基等工具无法
正常工作。
空行接着更进一步的段落。
  - 句号也是可以的。
  - 项目符号可以使用典型的连字符或星号
    前面一个空格，之间用空行隔开，
    但是可以依据不同的惯例有所不同。