在 GitHub 中与团队合作

学习目标

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

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

有效的分支策略

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

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

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

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

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

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

处理合并冲突

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

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

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

我们知道，在不同的分支上对相同文件的相同部分进行多次提交时，就会发生合并冲突。所以，为了练习解决冲突，让我们来设置一个冲突。

1. 从 main 中创建一个新分支 (new-branch-1)，更改 README.md 文件，然后创建一个拉取请求：
   • 输入命令：git checkout -b new-branch-1
   • 更改存储库中的 README.md 文件。记下您更改的行。
   • 在 new-branch-1 上添加并提交更改：
     • 输入命令：git add README.md 
     • 输入命令：git commit -m "Changes to the README"

• 将分支推送到远程存储库：git push -u origin new-branch-1
• 打开 GitHub 并为此提交创建一个拉取请求

1. 现在，要创建下一个分支和拉取请求，请返回到 main：
   git checkout main
2. 创建新分支 (new-branch-2)，对同一文件进行更改并创建拉取请求：
   • 输入命令：git checkout -b new-branch-2
   • 更改 README.md 文件中的同一行。
   • 输入命令：git add README.md
   • 输入命令：git commit -m “More changes to the README”
   • 输入命令：git push -u origin new-branch-2
   • 在 GitHub 中，创建拉取请求

合并一个拉取请求

到目前为止，两个分支中都没有显示合并冲突。在 GitHub 中，合并您的第一个拉取请求（来自 new-branch-1）。

解决另一个分支上的冲突

合并 new-branch-1 拉取请求之后，转到 new-branch-2 的拉取请求。 

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

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

1. 检出至包含冲突的分支：git checkout new-branch-2
2. 确保您的本地存储库是最新的：git pull
3. 将 main 合并到 feature 分支：git merge origin/main 请注意，您合并的是远程跟踪分支，而不是 main 的本地副本——这是因为拉取命令更新了远程分支和您所在的分支，但没有更新 main 分支。
4. 如果您看到有冲突，没关系！输入 git status 验证哪个文件有冲突。有冲突的文件列在 Unmerged Paths 下。
5. 在文本编辑器中打开该文件，并查找合并冲突标记。 (<<<<<<<, =======, >>>>>>>)
6. 显示了两个分支的代码版本——选择您要保留的代码并删除另一个。请务必删除 Git 创建的合并冲突标记并保存您的更改。
7. 添加并提交保存的更改以解决合并冲突：
   • 输入命令：git add README.md
   • 输入命令：git commit -m “Commit to resolve merge conflict”
8. 将功能分支推送到远程： git push
9. 返回到 GitHub 上的拉取请求。拉取请求现在已没有冲突。
   
10. 合并拉取请求。

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

创建原子提交

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

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

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

1. 将 bigFile.md 下载到您的计算机（您可能需要右键单击并选择 Save Target As（目标另存为）。
2. 在 GitHub 中，将 bigFile.md 上传到 best-repo-ever 存储库的 main 分支：
   • 单击 Upload files（上传文件）。 
   • 从计算机中选择 bigFile.md。
   • 选择 Commit directly to the main branch（直接提交到 main 分支） 
   • 单击 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 上方查看选项列表。