图解Git——分布式Git《Pro Git》

分布式工作流程

Centralized Workflow（集中式工作流）

所有开发者都与同一个中央仓库同步代码，每个人通过拉取、提交来合作。
如果两个开发者同时修改了相同的文件，后一个开发者必须在推送之前合并其他人的更改。

Integration-Manager Workflow（集成管理者工作流）

每个开发者拥有自己仓库的写权限，主仓库由维护者管理。
开发者通过 fork 主仓库，推送更改到自己的仓库后，向维护者请求合并。
维护者拉取开发者的更改，进行测试和合并后，推送回主仓库。

Dictator and Lieutenants Workflow（主管与副主管工作流）

适用于大型项目，尤其是多个维护者的项目。项目中的 Dictator 负责最终的合并，Lieutenants 负责各自模块。
开发者在自己的分支上工作，提交到 Lieutenant 的分支，再由 Lieutenant 合并到主分支，最终由 Dictator 合并到中央仓库。

向一个项目做贡献

向一个项目贡献代码的过程涉及到几个关键的因素，其中每个因素都可能影响贡献的方式、流程以及最终效果。以下是一个稍微详细的描述，包括了如何贡献代码、涉及的困难以及如何有效管理提交。

1. 活跃贡献者的数量

项目的活跃贡献者数量直接影响代码贡献的难易程度。对于小型项目，活跃的贡献者可能只有几位，每天的提交次数不多。而对于大型开源项目，贡献者可能成千上万，提交的频率也非常高。随着贡献者增多，代码的合并和应用会面临更多挑战：

问题：当多个贡献者提交改动时，代码可能会发生冲突。不同的开发者可能修改相同的文件或功能，导致合并时出现冲突或代码不兼容。
解决方案：使用频繁的拉取最新代码（git pull）和解决合并冲突的技巧非常重要。合并冲突必须在本地解决，确保最终代码与其他人提交的代码兼容。

2. 项目使用的工作流程

项目的工作流程通常取决于项目的大小和复杂度。以下是常见的几种工作流：

集中式工作流：所有贡献者都拥有对主分支（master）的写入权限，可以直接提交代码。这种工作流简单，适用于小团队或私有项目。
分支工作流：每个开发者在自己的分支上工作，修改完成后通过**拉请求（pull request）或合并请求（merge request）**向主分支提交代码。这是更常见的工作流，尤其是对于开源项目。
维护者工作流：对于大型项目，维护者或核心开发人员负责审查和合并来自其他开发者的代码，外部贡献者需要通过提交拉请求来提供自己的改动。

影响：你需要明确自己所参与的项目采用哪种工作流程。如果是分支工作流，你可能需要在自己完成代码后，推送到自己的分支上，再通过拉请求的方式提交合并。

3. 提交权限

提交权限的管理是一个重要的因素，它决定了你如何将代码提交到项目中：

有写权限：如果你有直接的写权限，可以直接提交代码到主分支或者其他分支。
没有写权限：如果没有写权限，通常需要通过提交拉请求或合并请求的方式贡献代码。维护者将审核你的代码，并决定是否合并。

影响：如果没有直接的写权限，你需要了解项目是否有贡献指南，遵循规定的流程来提交代码。

4. 如何确保代码合并成功

代码合并的过程中，通常会涉及以下步骤：

拉取最新代码：确保你的本地分支与远程仓库的代码是同步的。

git pull origin master

如果有人提交了新的改动，你需要合并他们的代码到自己的分支。

解决冲突：在合并时，如果出现冲突，Git 会提示你冲突的文件。你需要手动解决这些冲突。

git mergetool

使用适当的工具来解决冲突。

推送代码：将你的代码提交到远程仓库。对于有写权限的用户，可以直接推送到主分支；对于没有写权限的用户，推送到自己的分支并发起拉请求。

git push origin my-feature-branch

5. 提交准则和提交信息规范

提交信息是贡献中非常重要的一部分，合理的提交信息有助于项目维护者理解你的改动，并在后期进行回溯时找到问题。以下是一些常见的提交准则：

避免空白错误：在提交代码前，运行 git diff --check 检查代码是否有空格或其他格式错误。
保持提交逻辑清晰：每个提交应该是一个逻辑上独立的变更集。避免将多个不相关的功能或修复合并成一个提交。你可以通过 git add --patch 来分拆提交，确保每次提交都是相关的、功能明确的。
提交信息的格式：通常，提交信息应包含以下部分：

- 简洁的摘要：不超过 50 个字符，简要描述改动内容。
- 详细描述：如果需要，可以提供更多的背景信息，包括为什么要进行这个改动，改动的动机以及如何影响代码的行为。

示例：

Add user authentication logic

Implement login and registration features with validation and error handling.
This change introduces a new User model and modifies the authentication flow.

6. 常见的合并和冲突处理

在多人协作的项目中，冲突是不可避免的。以下是一些处理冲突的技巧：

频繁同步：尽量在自己提交之前拉取远程的最新代码，并解决冲突。
避免长时间拖延合并：如果开发周期较长，尽量频繁将自己的修改与主分支合并，减少出现复杂冲突的概率。

7. 私有小型团队的工作流程

在一个小型私有团队中，可能会采用集中式的工作流。在这种情况下，团队成员通常拥有直接的写权限，可以直接将代码推送到主分支。这种工作流程较为简单，适用于团队成员较少且沟通较为直接的项目。
示例：Git - 向一个项目贡献

8. ⭐私有管理团队的工作流程

在大型私有团队中，通常会有一个整合者（例如项目经理或核心开发人员）来负责代码的合并工作。开发者会在自己创建的分支上进行工作，完成后通过拉请求（pull request）或合并请求（merge request）提交代码。这种工作流更为规范，适用于需要高质量代码管理的大型团队。
示例：Git - 向一个项目贡献

9. 派生的公开项目

在许多公开项目中，你无法直接向主仓库提交代码，因为你没有写入权限。这时，派生（Fork）是常用的操作，具体步骤如下：

派生原项目：

- 首先，你需要从原项目的页面点击“Fork”按钮。这样会创建一个你自己的仓库副本，通常在 GitHub、GitLab、BitBucket 等平台上。

克隆到本地：

- 使用 git clone 克隆你派生的仓库到本地：

git clone <your-fork-url>
cd <project-directory>

创建一个新分支进行开发：

- 在本地仓库中，创建一个新的分支来进行开发，避免直接在 master 分支上工作：

git checkout -b feature-branch

在新分支上做修改并提交：

- 在 feature-branch 上进行开发，提交修改：

git add .
git commit -m "Add feature A"

将修改推送到派生的仓库：

- 修改完成后，你将分支推送到你自己的远程仓库：

git push origin feature-branch

创建拉取请求（Pull Request，PR）：

- 然后，前往 GitHub 或其他平台，进入你自己派生的仓库，在该仓库上创建一个 Pull Request。你需要选择将修改合并到原项目的 master 或其他目标分支。
- 在 PR 描述中，清楚地说明你所做的更改，维护者会基于此来审查你的修改。

维护者审查和合并：

- 项目的维护者会审查你的修改，可能会要求你进一步修改，或者直接合并你的工作。如果审查通过，维护者会将你的更改合并到原仓库。

总结

1. 派生是贡献代码的标准方式，尤其是在没有直接写入权限的情况下。
2. 创建 Pull Request 是你提交修改的正式方式，维护者会在合并之前审查你的工作。
3. 变基和冲突解决是常见的流程，以确保你的提交与原项目兼容。

10. 变基（Rebase）与冲突解决

变基（Rebase）： 如果在提交 PR 之前，原项目的 master 分支发生了更新，可能会出现合并冲突。这时，你可以通过 git rebase 将你的分支基于最新的 master 分支重新应用提交，避免冲突：

git checkout feature-branch
git fetch upstream
git rebase upstream/master

这会将你的更改基于最新的原仓库的 master 分支上，冲突解决后再推送。

合并（Merge）： 你也可以选择通过合并（git merge）来解决冲突，具体选择取决于项目的惯例。

结论

向一个项目贡献代码的流程是多种多样的，取决于项目的规模、工作流、贡献者的角色以及提交权限。最重要的是理解项目的工作流、遵循项目的提交准则，并保持代码的清晰与规范。在实际开发中，良好的协作和沟通是确保代码顺利合并和项目成功的关键。