Git笔记（22）项目贡献要点

你的名字 2023-07-08 15:26 120阅读 0赞

### Git笔记（22） 项目贡献要点 ###

*  1. 项目影响因素
 *   *  1.1. 活跃贡献者的数量
     *  1.2. 使用的工作流程
     *  1.3. 提交权限
 *  2. 提交准则
 *   *  2.1. 检查空白错误
     *  2.2. 独立变更
     *  2.3. 提交信息

--------------------

# 1. 项目影响因素 #

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

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

--------------------

## 1.1. 活跃贡献者的数量 ##

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

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

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

**如何保证代码始终是最新的，并且提交始终是有效的？**

--------------------

## 1.2. 使用的工作流程 ##

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

--------------------

## 1.3. 提交权限 ##

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

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

--------------------

# 2. 提交准则 #

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

--------------------

## 2.1. 检查空白错误 ##

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

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

--------------------

## 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官网介绍删减、添加和修改组成

--------------------