在 GitHub 中与团队合作

学习目标

完成本单元后，您将能够：

• 将 GitHub 工作流转变为团队的有效分支策略。
  
• 解决 GitHub 上的合并冲突。
  
• 创建表示单个工作单位的原子提交。
  

有效的分支策略

现在，您独自完成了一个简单的示例 GitHub 流程，想象一下这个工作流如何与团队配合。将所有分支、提交和拉取请求乘以团队中的同事数量，再乘以活跃开发。许多团队已经这样做了，而且随着时间的推移，有一些模式被证明是成功的。

分支一般用于短期内完成单一功能，并在合并后删除。短期分支可以防止混乱，使代码保持最新，并允许开发人员迭代改进他们的项目。

如果不谨慎使用，长期分支可能会导致问题。有时长期分支适用于开发分支，或其他您需要多层次的部署级代码的情况。大多数长期分支问题都源于开发人员在各自的分支上没有最新版本，导致不必要的合并冲突、混乱和工作。更复杂的分支工作流似乎是正确的解决方案，但它们经常过于复杂，而 GitHub 程则既简单又高效。

关于分支要询问团队的几个问题：

• 我们将采用哪种分支策略？
  
• 哪个分支将作为我们的主代码或部署代码？
  
• 我们是否会为分支使用命名约定？
  
• 我们将如何使用标签和代理人？
  
• 我们是否会使用里程碑？
  
• 我们是否会使用项目板（项目）？
  
• 我们是否有问题或拉取请求的必要模板/元素（例如运输清单）？
  
• 如何表示拉取请求的签核？
  
• 谁将合并拉取请求？
  

请记住，分支的最大优点是它们允许您在安全的地方进行更改，并在拉取请求中进行审查和测试。确定了您的团队对分支的期望后，请使其尽可能紧凑和易于理解。专注于协作。

处理合并冲突

当您与团队合作时（甚至当您单独工作时），偶尔会产生合并冲突。一开始，合并冲突可能令人望而生畏，但实际上解决它们很容易。 

让我们来创建一个合并冲突，看看会发生什么。

创建具有冲突提交的多个分支

我们知道，在不同的分支上对相同文件的相同部分进行多次提交时，就会发生合并冲突。所以，为了练习解决冲突，我们用命令行设置一个冲突。您将创建两个不同的分支，并在每个分支中对 README.md 文件进行修改。您的本地存储库应位于主分支上。

1. 创建一个新分支 (new-branch-1)：
   git checkout -b new-branch-1

2. 更改存储库中的 README.md 文件。记下您更改的行。
   
3. 将更改添加到暂存 (Staging)：
   git add README.md
   

4. 提交更改：
   git commit -m "Changes to the README”
   

5. 在 GitHub Desktop 中单击 Publish branch（发布分支）。
   
6. 打开 GitHub 并为此提交创建一个拉取请求。
   

现在让我们创建第二个分支并更新 README.md 文件。首先通过命令行切换回主分支。

1. 切换回主分支：
   git checkout main
   

2. 创建第二个分支 (new-branch-2)：
   git checkout -b new-branch-2
   

3. 更改 README.md 文件中的同一行。
   
4. 将更改添加到暂存 (Staging)：
   git add README.md
   

5. 提交更改：
   git commit -m "More changes to the README”
   

6. 在 GitHub Desktop 中单击 Publish branch（发布分支）。
   
7. 打开 GitHub 并为此提交创建一个拉取请求。
   

合并一个拉取请求

到目前为止，两个分支中都没有显示合并冲突。在 GitHub 中合并您的第一个拉取请求“Changes to the README”（来自 new-branch-1），以更新主分支。

解决另一个分支上的冲突

合并 new-branch-1 拉取请求之后，转到 new-branch-2 的拉取请求“More changes to the README”。 

您会看到有一个合并冲突！不要害怕，您可以解决。根据合并冲突的复杂程度，您可以选择在 GitHub 上的浏览器中解决冲突，也可能需要在本地解决。

要在本地解决冲突，您需要将 main 合并到您的分支中，解决冲突，然后完成合并。

1. 如果您看到有冲突，没关系！输入 git status 验证哪个文件有冲突。有冲突的文件列在 Unmerged Paths 下。
   
2. 在文本编辑器中打开该文件，并查找合并冲突标记。(<<<<<<<, =======, >>>>>>>)
   
   

3. 显示了两个分支的代码版本——选择您要保留的代码并删除另一个。请务必删除 Git 创建的合并冲突标记并保存您的更改。
   
   

4. 添加并提交保存的更改以解决合并冲突：
   输入命令：
   git addREADME.md
   
   输入命令：
   git commit -m “Commit to resolve merge conflict”

5. 在 GitHub Desktop 中单击 Publish branch（发布分支）。
   
6. 返回到 GitHub 上的拉取请求。拉取请求现在已没有冲突。
   

7. 合并拉取请求。
   

处理完这些分支后，在 GitHub 中删除它们，然后使用 git checkout main 和 git pull 命令来同步您的本地存储库。

创建原子提交

创建原子提交是创建可读且信息丰富的项目历史的重要部分。

在一个完美的世界中，您永远不需要查看或更改历史记录中的任何内容。然而，我们所处的世界并不完美，因此版本控制让我们可以在必要时查看我们的变更历史。每个提交都应该是一个小的逻辑更改单元，并讲述存储库的故事。

让我们来练习使用 git add --patch 命令（或缩写为 git add -p）来帮助创建原子提交。此命令可让您将文件的不同部分添加到暂存区，帮助您提交真正的逻辑更改单元。

1. 将 bigFile.md 下载到您的计算机（您可能需要右键单击并选择目标另存为）
   
2. 在 GitHub 中，将 bigFile.md 上传到 best-repo-ever 存储库的 main 分支：
   
   1. 单击 Upload files（上传文件）。
      
   2. 从计算机中选择 bigFile.md。
      
   3. 选择 Commit directly to the main branch（直接提交到 main 分支）
      
   4. 单击 Commit changes（提交更改）
      
3. 确保您的本地主存储库是最新的：
   输入命令：
   git checkout main
   
   输入命令：
   git pull

4. 查看 git 正在跟踪什么：
   git status
   
   您会看到没有可提交的内容。
   
5. 对 bigFile.md 的第 1 行和第 100 行进行更改。（更改什么并不重要。）
   
6. 将某些文件的某些部分移动到带有 --patch 标志的暂存区：
   git add -p

7. 按 y 暂存 hunks（Git 语言中所指的更改单元）。
   

想知道对于这些 hunks 还有哪些选项？请使用 ? 在 hunk 上方查看选项列表。