rebase与合并：整合GIT的变化

本文继续我们的“高级git”系列。在Twitter上关注我们，或订阅我们的新闻通讯以获取有关未来文章的最新信息！

有效的GIT分支对于开发人员至关重要。我上一篇文章详细介绍了分支策略，GIT的分支模型，分支类型和常见的工作流程。核心好处：孤立的工作区（分支）显着改善了版本控制。

本文着重于整合分支机构 - 将代码有效地合并回主开发线路。我们将探讨两种关键方法：合并和重新构造。

git merge和git rebase都解决了相同的问题：将一个分支的变化整合到另一个分支。但是，他们的方法差异很大。让我们先检查合并。

高级GIT系列：

• 第1部分：制定理想的吉特犯罪
• 第2部分：优化GIT分支策略
• 第3部分：简化与拉请求的合作
• 第4部分：有效解决合并冲突
• 第5部分： rebase vs. Merge（您在这里！ ）
• 第6部分：掌握互动式重新启动
• 第7部分：挑选樱桃的git提议
• 第8部分：利用反射仪恢复丢失的提交

了解GIT合并

git merge命令集成了分支。想象一下branch-B带有新提交；合并成branch-A ：

 <code>$ git checkout branch-A $ git merge branch-B</code>

这会在branch-A上创建一个新的合并提交，并连接两个分支历史。 GIT标识了三个关键提交：

• 共同的祖先：两个分支在分歧之前共享相同代码的点。
• 分支端点：每个分支上的最新提交，代表其当前状态。

git结合了这些承诺以实现整合。简化的方案（ branch-A以来分支以来没有提交的情况）导致“快速前进”合并 - 有效地添加了branch-B的直接提交。

但是，在大多数实际情况下，两个分支都独立发展。然后，与开发人员创建的提交不同，GIT创建了合并提交来结合这些更改的合并，这是自动生成的独特犯罪。了解此自动合并需要分析完整的分支历史。

人与合并提交

开发人员创建的提交经过精心构建，其中包含相关的更改和信息信息。相反，合并提交会自动连接分支，而不一定代表一系列具有语义连贯的更改。

与重新构造集成

重新打造提供了合并的替代方法。它本质上不是“更好”，只是不同的。您可以仅通过合并而成功管理git。但是，理解重新打击提供了宝贵的选择。

重新启动避免自动合并提交，创建线性项目历史记录，消除分支差距。

重新打击：逐步指南

让我们将branch-B重新为branch-A ：

 <code>$ git checkout branch-A $ git rebase branch-B</code>

该过程涉及三个步骤：

1. 暂时删除提交：在暂时存储共同祖先之后在branch-A上提交。
2. 应用branch-B的提交：应用branch-B的提交，暂时对齐两个分支。
3. 重新校长branch-A的提交：暂时存储的branch-A提交被重新应用于branch-B的提交，创建了线性历史记录。

结果：简化的历史没有合并。

rebasing的潜在陷阱

至关重要的是，重新编写命令历史。虽然内容保持不变，但提交的父母会改变，生成新的SHA-1哈希。

这对于未出版的提交是可以接受的。但是，重新出版的提交是有风险的，有可能破坏基于原始提交的工作的合作者。

黄金法则：永远不要反映公共分支机构！在集成到共享分支之前，请在本地使用重新打扫以清理历史记录。

集成策略：合并与重生

合并和重新构造都是有价值的工具。合并历史无损。重新设计精简历史，但需要谨慎对待发表的提交。

探索我免费的“高级GIT套件”，以深入了解GIT工具。

愉快的合并和重组！在下一个“高级git”部分中见！

高级GIT系列：

• 第1部分：制定理想的吉特犯罪
• 第2部分：优化GIT分支策略
• 第3部分：简化与拉请求的合作
• 第4部分：有效解决合并冲突
• 第5部分： rebase vs. Merge（您在这里！ ）
• 第6部分：掌握互动式重新启动
• 第7部分：挑选樱桃的git提议
• 第8部分：利用反射仪恢复丢失的提交

以上是rebase与合并：整合GIT的变化的详细内容。更多信息请关注PHP中文网其他相关文章！