通过优锐课核心java学习笔记中，我们可以看到，码了很多专业的相关知识， 分享给大家参考学习。

Java中的合并与重组上部分链接：https://www.cnblogs.com/youruike1/p/12376482.html

推力

如果你尝试将重新建立基础的主分支推送回远程存储库，Git将阻止你这样做，因为它与远程主分支冲突。 但是，你可以通过传递--force标志来强制执行推送，如下所示：

1 # Be very careful with this command!
2 
3 git push --force
4 
5  

 

这将覆盖远程主分支以匹配你存储库中重新设置的分支，并使团队的其他成员感到非常困惑。 因此，只有当你确切知道自己在做什么时，请务必小心使用此命令。

强制推送的唯一一次情况是在将私有功能分支推送到远程存储库后（例如出于备份目的）执行本地清理后。 这就像说：“糟糕，我并不是真的想推送功能分支的原始版本。 取而代之的是当前的。” 同样，重要的是没有人要处理来自功能分支原始版本的提交。

工作流程演练

只要你的团队感到满意，就可以将基础调整纳入你现有的Git工作流程中。 在本部分中，我们将研究功能开发的各个阶段，重新定标可以提供的好处。

利用git rebase的任何工作流程的第一步都是为每个功能创建一个专用分支。 这为你提供了必要的分支结构，以安全地使用重新基准化：

 

 

 

 

本地清理

将基础整合到工作流程中的最佳方法之一是清理本地的正在进行的功能。 通过定期执行交互式变基，可以确保功能中的每个提交都具有针对性和意义。 这样，你就可以编写代码，而不必担心将其分解为孤立的提交，你可以在事后对其进行修复。

调用git rebase时，你有两个用于新基础的选项：功能的父分支（例如master）或功能中的较早提交。 我们在交互重定基础部分中看到了第一个选项的示例。 当你只需要修复最后的几次提交时，使用后一种方法是不错的选择。 例如，以下命令开始仅对最后3个提交的交互式变基。

1 git checkout feature
2 
3 git rebase -i HEAD~3

 

 

通过指定HEAD〜3作为新的基础，你实际上并没有移动分支-你只是交互式地重写了紧随其后的3个提交。 请注意，这不会将上游更改合并到功能分支中。By

 

 

 

 

如果要使用此方法重写整个功能，则git merge-base命令可用于查找功能分支的原始基础。 以下代码返回原始数据库的提交ID，然后你可以将其传递给git rebase：

git merge-base feature master

 

交互式重定基的这种用法是将git rebase引入工作流的一种好方法，因为它仅影响本地分支。 其他开发人员唯一会看到的是成品，它应该是干净，易于遵循的功能分支历史记录。

但是同样，这仅适用于私有功能分支。 如果你通过同一功能分支与其他开发人员进行协作，则该分支是公开的，并且你不能重写其历史记录。

没有用于通过交互式rebase清除本地提交的git merge替代方案。

将上游更改纳入功能

在``概念概述''部分中，我们了解了功能分支如何使用git merge或git rebase合并来自master的上游更改。 合并是一个安全的选项，可保留存储库的整个历史记录，而重新基准化则通过将要素分支移至master的顶端来创建线性历史记录。

git rebase的这种用法类似于本地清理（可以同时执行），但是在此过程中，它合并了master的上游提交。

请记住，基于远程分支而不是master分支是完全合法的。 与另一位开发人员协作使用同一功能时，可能会发生这种情况，并且你需要将他们的更改合并到存储库中。

例如，如果你和另一个名为John的开发人员将提交添加到功能分支，则从John的存储库中获取远程功能分支后，你的存储库可能如下所示：

 

 

 

 

你可以使用与从master集成上游更改完全相同的方法来解决此派生问题：将本地功能与john / feature合并，或将本地功能重新建立到john / feature的尖端。

 

 

 

 

请注意，此重新设置并没有违反``重新设置黄金原则''，因为仅移动了本地功能提交-之前未进行任何操作。 这就像在说：“将我的更改添加到John已经完成的操作中。” 在大多数情况下，这比通过合并提交与远程分支同步更为直观。

默认情况下，git pull命令执行合并，但是你可以通过传递--rebase选项来强制它将远程分支与rebase集成在一起。

通过拉取请求查看功能

如果在代码审查过程中使用拉取请求，则需要在创建拉取请求后避免使用git rebase。 发出拉取请求后，其他开发人员就会查看你的提交，这意味着这是一个公共分支。 重写其历史记录将使Git和你的队友无法跟踪添加到该功能的任何后续提交。

 

 

 

来自其他开发人员的任何更改都需要与git merge合并，而不是git rebase。

因此，在提交拉取请求之前，最好先使用交互式资源库清理代码。

集成批准的功能

在你的团队批准某个功能后，你可以选择在使用git merge将功能集成到主代码库之前，将该功能重新部署到主分支的尖端。

这类似于将上游更改合并到功能分支中，但是由于不允许在主分支中重写提交，因此最终必须使用git merge来集成功能。 但是，通过在合并之前执行变基，可以确保合并将快速进行，从而实现完美的线性历史记录。 这也使你有机会压缩在请求请求期间添加的任何后续提交。

 

 

 

如果你对git rebase不太满意，则可以始终在临时分支中执行rebase。 这样，如果你不小心弄乱了功能的历史记录，可以查看原始分支，然后重试。 例如：

 1 git checkout feature
 2 
 3 git checkout -b temporary-branch
 4 
 5 git rebase -i master
 6 
 7 # [Clean up the history]
 8 
 9 git checkout master
10 
11 git merge temporary-branch

 

摘要

这就是你真正需要重新建立分支机构的全部知识。 如果你希望没有任何不必要的合并提交的干净，线性的历史记录，则在集成来自另一个分支的更改时，应该使用git rebase而不是git merge。

另一方面，如果你想保留项目的完整历史记录并避免重写公共提交的风险，则可以坚持使用git merge。 两种选择都非常有效，但是至少现在你可以选择利用git rebase的好处。

 

> 喜欢这篇文章的可以点个赞，欢迎大家留言评论，记得关注我，每天持续更新技术干货、职场趣事、海量面试资料等等
 > 如果你对java技术很感兴趣也可以交流学习，共同学习进步。 
> 不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代

文章写道这里，欢迎完善交流。最后奉上近期整理出来的一套完整的java架构思维导图，分享给大家对照知识点参考学习。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java干货