分布式 git

向右看齐 2022-05-31 05:06 136阅读 0赞

# 分布式 git #

*  分布式 git
    
     *  分布式工作流程
        
         *  1 集中式工作流
         *  2 集成管理员工作流
         *  3 司令官和副官工作流
     *  项目协作
        
         *  1 提交指南
         *  2 私有小型团队
         *  3 私有团队之间的协作
         *  4 公开的小型项目
         *  5 大型公共项目
     *  项目管理
        
         *  1 使用特性分支进行工作
         *  2 采纳来自邮件的补丁
         *  3 代码集成

## 1. 分布式工作流程 ##

在 Git 网络中，每个开发者同时扮演着节点和集线器的角色。

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

### 1.1 集中式工作流 ###

![集中式][SouthEast]

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

### 1.2 集成管理员工作流 ###

1.  项目维护者可以推送数据到公共仓库 blessed repository。
2.  贡献者克隆此仓库，修订或编写新代码。
3.  贡献者推送数据到自己的公共仓库 developer public。
4.  贡献者给维护者发送邮件，请求拉取自己的最新修订。
5.  维护者在自己本地的 integration manger 仓库中，将贡献者的仓库加为远程仓库，合并更新并做测试。
6.  维护者将合并后的更新推送到主仓库 blessed repository。  
    ![集中管理员][SouthEast 1]

在 GitHub 网站上使用得最多的就是这种工作流。人们可以复制（亦即克隆）某个  
项目到自己的列表中，成为自己的公共仓库。随后将自己的更新提交到这个仓库，所有人都可以看到你的每次更新。这么做最主要的优点在于，你可以按照自己的节奏继续工作，而不必等待维护者处理你提交的更新；而维护者也可以按照自己的节奏，任何时候都可以过来处理接纳你的贡献。

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

### 1.3 司令官和副官工作流 ###

这其实是上一种工作流的变体。一般超大型的项目才会用到这样的工作方式，像是拥有数百协作开发者的 Linux 内核项目就是如此。各个集成管理员分别负责集成项目中的特定部分，所以称为副官（lieutenant）。而所有这些集成管理员头上还有一位负责统筹的总集成管理员，称为司令官（dictator）。司令官维护的仓库用于提供所有协作者拉取最新集成的项目代码。  
1. 一般的开发者在自己的特性分支上工作，并不定期地根据主干分支（dectator 上的  
master）衍合。  
2. 副官（lieutenant）将普通开发者的特性分支合并到自己的 master 分支中。  
3. 司令官（dictator）将所有副官的 master 分支并入自己的 master 分支。  
4. 司令官（dictator）将集成后的 master 分支推送到共享仓库 blessed repository  
中，以便所有其他开发者以此为基础进行衍合。

![司令官][SouthEast 2]

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

## 2. 项目协作 ##

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

### 2.1 提交指南 ###

1.  不要在更新中提交多余的白字符（whitespace）。Git 有种检查此类问题的方  
    法，在提交之前，先运行 git diff –check，会把可能的多余白字符修正列出来。
2.  每次提交限定于完成一次逻辑功能。并且可能的话，适当地分解为多次小更  
    新，以便每次小型提交都更易于理解。
3.  提交说明最好限制在一行以内，50 个字符以下，简明扼要地描述更新内容，空开一行后，再展开详细注解。

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

### 2.2 私有小型团队 ###

一般使用集中式工作流

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

### 2.3 私有团队之间的协作 ###

一般使用典型的集成管理员式工作流，每个组都有一名管理员负责集成本组代码，及更新项目主仓库的 master 分支。所有开发都在代表小组的分支上进行。

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

### 2.4 公开的小型项目 ###

要给公开项目作贡献，因为你没有直接更新主仓库分支的权限，得寻求其它方式把工作成果交给项目维护人。第一种使用 git 托管服务商提供的仓库复制功能，一般称作 fork，比如 repo.or.cz和 GitHub 都支持这样的操作，而且许多项目管理员都希望大家使用这样的方式。另一种方法是通过电子邮件寄送文件补丁。  
但不管哪种方式，起先我们总需要克隆原始仓库，而后创建特性分支开展工作。然后把特性分支推上去，等待维护者采纳。

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

### 2.5 大型公共项目 ###

许多大型项目都会立有一套自己的接受补丁流程。多数项目都允许通过开发者邮件列表接受补丁。为每个补丁创建独立的特性分支，你只需将每次提交的差异内容以电子邮件的方式依次发送到邮件列表中即可。  
可以用 git format-patch 命令来生成 mbox 格式的文件然后作为附件发送。  
git send-email 命令把补丁作为邮件依次发送到指定的 IMAP 服务器上的文件夹中。

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

## 3. 项目管理 ##

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

### 3.1 使用特性分支进行工作 ###

如果想要集成新的代码进来，最好局限在特性分支上做。临时的特性分支可以让你随意尝试，进退自如。

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

### 3.2 采纳来自邮件的补丁 ###

如果收到一个通过电邮发来的补丁，你应该先把它应用到特性分支上进行评估。有两种应用补丁的方法：git apply 或者 git am。

如果收到的补丁文件是用 git diff 或由其它 Unix 的 diff 命令生成，就该用 git apply 命令来应用补丁。git apply 是一个事务性操作的命令，也就是说，要么所有补丁都打上去，要么全部放弃。  
在实际打补丁之前，可以先用 git apply –check 查看补丁是否能够干净顺利地应用到当前分支中。

对于 format-patch 制作的新式补丁，应当使用 git am 命令。

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

### 3.3 代码集成 ###

一般最简单的情形，是在 master 分支中维护稳定代码，然后在特性分支上开发新功能，或是审核测试别人贡献的代码，接着将它并入主干，最后删除这个特性分支，如此反复。

对于大型项目，至少需要维护两个长期分支 master 和 develop。  
先将所有新代码合并到临时特性分支，等到该分支稳定下来并通过测试后，再并入 develop 分支。然后，让时间检验一切，如果这些代码确实可以正常工作相当长一段时间，那就有理由相信它已经足够稳定，可以放心并入主干分支发布。

一些维护者更喜欢衍合或者挑拣贡献者的代码，而不是简单的合并，因为这样能够保持线性的提交历史。  
挑拣类似于针对某次特定提交的衍合。

如果你想要得到一个便于理解的提交号可以运行git describe命令。

代码发布前可以使用git archive将代码压缩包归档。

使用git shortlog命令可以方便快捷的制作一份修改日志（changelog），告诉大家上次发布之后又增加了哪些特性和修复了哪些bug。

[SouthEast]: /images/20220531/bb75a4555e67421c880e0d14ec46831d.png
[SouthEast 1]: /images/20220531/6368f519a34048ef8e9a4990c3be8406.png
[SouthEast 2]: /images/20220531/0337b654aeec4f9c8966dbc19e01c87a.png