版本控制（5）

学习目标

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

• 将GitHub工作流转换为适用于团队的有效分支策略。
• 解决GitHub上的合并冲突。
• 创建代表单个工作单元的原子提交。

分支策略的工作

现在您已经通过一个简单的GitHub流程示例，想象一下工作流程如何与团队一起工作。将所有分支，提交和请求数量乘以团队中同事的数量，并积极开发。以前有很多团队都做过这样的事情，而且有一些成功的模式。

一般来说，分支机构应该是短暂的，创建完成一个功能，并在合并后删除。短命的分支可避免混淆，鼓励最新的代码，并设置开发人员对项目进行迭代改进。

长时间运行的分支可能会造成问题，如果不被有意使用。有时候，长期的分支对于开发分支是有意义的，或者对于需要多级部署级代码的其他情况。长期运行的分支所面临的大部分挑战来自于没有每个分支的最新版本的开发人员，造成了不必要的合并冲突，混淆和工作。虽然更复杂的分支工作流可能看起来是正确的解决方案，但是它们经常过于复杂，更简单的GitHub流更有效地工作。

有些问题要问你的团队分支：

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

请记住，分支的力量来自一个安全的地方进行更改，并有权审查和测试拉请求。当你决定团队的分支期望时，保持轻量级，易于学习。专注于协作。

处理合并冲突

当你和一个团队一起工作（甚至有时候你独自一人工作），你偶尔会产生合并冲突。起初，合并冲突可能是令人恐惧的，但解决它们其实很简单。

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

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

我们知道合并冲突是在多个提交到相同文件的相同部分的分支上进行的。所以，要练习，让我们来设置。

1. 从master创建一个新分支（new-branch-1），更改README.md文件，并创建一个pull请求：
   1. 输入命令： git checkout -b new-branch-1
   2. 更改存储库中的README.md文件。记下你改变的哪一行。
   3. 在新分支1上，添加并提交更改：
      1. 输入命令： git add README.md 
      2. 输入命令： git commit -m "Changes to the README"
         注意：在正常的实践中，我们不建议直接向主人提交 – 我们只是在这里做，它很快就会造成合并冲突。
   4. 将分支推到远程仓库： git push -u origin new-branch-1
   5. 打开GitHub并为此提交创建一个拉取请求
2. 现在，为了创建下一个分支和拉取请求，请检查返回给master：
   git checkout master
3. 创建一个新分支（new-branch-2），对同一个文件进行更改并创建一个pull请求：
   1. 输入命令： git checkout -b new-branch-2
   2. 将README.md文件更改为文件的同一行。
   3. 输入命令: git add README.md
   4. 输入命令: git commit -m “More changes to the README”
   5. 输入命令: git push -u origin new-branch-2
   6. 在GitHub中，创建一个拉请求

合并一个请求

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

解决对方的冲突

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

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

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

1. 签出有冲突的分支: git checkout new-branch-2
2. 确保你的本地仓库是最新的: git pull
3. 合并主功能分支：git merge origin / master注意你正在合并远程追踪分支，而不是你的本地主副本 – 这是因为pull命令更新了远程分支和你正在使用的分支，但没有更新主分支。
4. 当你看到有冲突的时候，没关系！输入git status来验证哪个文件有冲突。有冲突的文件列在Unmerged Paths下。
5. 在文本编辑器中打开该文件，然后查找合并冲突标记。(<<<<<<<, =======, >>>>>>>)
6. 两个分支的代码版本都存在 – 选择你想要保留的代码并删除其他代码。确保删除由Git创建的合并冲突标记并保存更改。
7. 添加并提交保存的更改以解决合并冲突：
   1. 输入命令： git add README.md
   2. 输入命令： git commit -m “Commit to resolve merge conflict”
8. 将功能分支推到远程： git push
9. 回到GitHub的pull请求。拉请求现在没有冲突。没有冲突的分支屏幕截图。
10. 合并拉取请求。

现在我们已经完成了这些分支，在GitHub中删除它们，然后使用git checkout master和git pull命令来同步您的本地存储库。

工艺原子提交

编写原子提交是创建项目可读和信息丰富的历史的重要组成部分。

在一个完美的世界里，你永远不需要去看或改变你的历史。然而，我们并不是生活在一个完美的世界，所以版本控制让我们在必要的时候查看我们的变化历史。每个提交都应该是一个小小的逻辑变化单元，并讲述你的存储库的故事。

让我们练习一个命令来帮助您完成原子提交，git add –patch或git add -p。这个命令可以让您将文件的不同部分添加到暂存区域，帮助您进行确实是逻辑单元更改的提交。

1. 将 bigFile.md 下载到您的计算机（您可能需要右键单击并选择 Save Target A）
2. 在GitHub中，将bigFile.md上传到最好的仓库中的master分支：
   1. 点击 Upload files
   2. 从您的电脑中选择 bigFile.md
   3. 选择 Commit directly to the master branch
   4. 点击 Commit changes
3. 确保您的本地主存储库是最新的：
   1. 输入命令: git checkout master
   2. 输入命令: git pull
4. 看看git跟踪的是什么： git status
   你应该看到没有什么可以提交的。
5. 对第1行和第100行上的bigFile.md进行更改（修改内容无关紧要）。
6. 使用–patch标志将一些文件的某些部分移至暂存区： git add -p
7. 按y或n选择是否放弃hunk。

想知道为什么所有这些其他选项是为人？使用 ？查看大块以上的选项列表。