我正在重新学习git，我对rebase不是很熟悉，我想开始使用它。我工作的团队不允许提交到我们的主分支。我们必须创建一个功能分支，然后创建一个合并请求。当我是唯一一个在功能分支上工作的人时，我希望我的功能分支与master保持同步，我希望我的提交在我创建pull request之前被附加在最后。所以，我的计划是在我的特性分支上工作，并定期用（on？）master进行变基。当我准备好提交我的pull请求时，这会保留我所有的提交吗？
jdzmm42g1#
至于rebased，你可以做任何次数，但考虑到你的场景，不断rebased功能在主可能会导致问题，在某些情况下。考虑这样一个场景：由于某些依赖关系，其他分支（比如“A”）被合并到您的特性分支中。现在，所有提交都被合并到这个合并的分支中（比如说X次提交）将被引入到你的特性分支中，同时还有一次额外的合并提交。现在，如果你试图用master来重定你的特性分支的基，对于合并分支A引入的所有X次提交，将发生变基。因此，在此操作期间存在X次冲突的可能性。但是，最好将master合并到您的特性分支中。在这种情况下，冲突只能发生一次，具体取决于您的特性分支和master分支的当前状态。
uurity8g2#
是的，你可以不止一次地重新定基。在重新定基之后，你会得到一组新的提交。这些提交和其他提交一样，没有被重新定基的记录。你需要小心的主要事情是可能发生的变基冲突。由于你经常变基，你可能会更经常地遇到冲突，并且需要更经常地解决它们。但是只要你准备好处理它们，你就应该没事。
xam8gpfp3#
在另一个分支上重定基会将当前 checkout 的分支的提交“重新应用”（现在相当聪明）到目标的顶部。所以，是的，如果你一遍又一遍地这样做，那么你将保持你当前的分支是最新的。我认为这是一个错字的问题，但你不想“rebase master”，但你想rebaseonmaster。有时候，你可能会遇到很多冲突，在这种情况下，你可能更应该考虑从这个特定的点上合并。在rebase时解决冲突是一件相当痛苦的事情，因为你必须从第一次提交开始修复冲突：如果以后的提交修改了同一段代码，那么第一次合并就会产生冲突，等等等等。通过合并你可以一次解决所有的问题。但是他们，一旦你合并你就必须继续合并。
ifmq2ha24#
是的，你可以rebase很多次。事实上，你想要做的是如此常见，以至于pull命令有一个内置的标志：
rebase
git pull --rebase
字符串
rhfm7lfc5#
看起来你对这个过程有正确的理解。我的团队的运作方式与你描述的类似，因为我们的团队领导更喜欢在一次提交（最好是小的）中完成所有相关的更改。在完成对特性分支的更改后，我确保本地master与上游分支匹配，然后是git rebase -i master。这让所有的东西都能在master上更新，-i允许我查看我所有的提交--并按照我的团队领导的要求把它们压缩在一起。就像你建议的那样，变基总是我在发出pull request之前的最后一步。
master
git rebase -i master
-i
cvxl0en26#
我想解释一个REBASING错误的场景：假设您正在处理功能分支A，1.你做了2个本地提交，提交ID分别为1和2。1.现在，您将这些提交推送到您的远程功能分支，并且在远程分支上创建了相同的ID。1.危险-现在，如果使用master/main/other对本地要素分支A进行REBASE（本地提交ID从1和2更改为例如21和22），然后您将添加ID为3的新提交提交，现在您决定将新的本地提交ID 3推送到远程特性分支A，GIT给出一个错误，说更新被拒绝，因为您当前分支的提示在后面1.**请勿进行REBASE：**如果您已将本地更改推送到远程分支。1.**仅在以下情况下才能多次REBASE：**您的更改是本地提交的。
**注意：**除了上述情况，永远不要在公共共享分支上进行Rebase，并始终遵循Rebase的黄金法则。如果有任何澄清，请让我知道
6条答案
按热度按时间jdzmm42g1#
至于rebased，你可以做任何次数，但考虑到你的场景，不断rebased功能在主可能会导致问题，在某些情况下。
考虑这样一个场景：由于某些依赖关系，其他分支（比如“A”）被合并到您的特性分支中。现在，所有提交都被合并到这个合并的分支中（比如说X次提交）将被引入到你的特性分支中，同时还有一次额外的合并提交。现在，如果你试图用master来重定你的特性分支的基，对于合并分支A引入的所有X次提交，将发生变基。因此，在此操作期间存在X次冲突的可能性。
但是，最好将master合并到您的特性分支中。在这种情况下，冲突只能发生一次，具体取决于您的特性分支和master分支的当前状态。
uurity8g2#
是的，你可以不止一次地重新定基。
在重新定基之后，你会得到一组新的提交。这些提交和其他提交一样，没有被重新定基的记录。
你需要小心的主要事情是可能发生的变基冲突。由于你经常变基，你可能会更经常地遇到冲突，并且需要更经常地解决它们。但是只要你准备好处理它们，你就应该没事。
xam8gpfp3#
在另一个分支上重定基会将当前 checkout 的分支的提交“重新应用”（现在相当聪明）到目标的顶部。
所以，是的，如果你一遍又一遍地这样做，那么你将保持你当前的分支是最新的。我认为这是一个错字的问题，但你不想“rebase master”，但你想rebaseonmaster。
有时候，你可能会遇到很多冲突，在这种情况下，你可能更应该考虑从这个特定的点上合并。在rebase时解决冲突是一件相当痛苦的事情，因为你必须从第一次提交开始修复冲突：如果以后的提交修改了同一段代码，那么第一次合并就会产生冲突，等等等等。通过合并你可以一次解决所有的问题。但是他们，一旦你合并你就必须继续合并。
ifmq2ha24#
是的，你可以
rebase很多次。事实上，你想要做的是如此常见，以至于pull命令有一个内置的标志：字符串
rhfm7lfc5#
看起来你对这个过程有正确的理解。我的团队的运作方式与你描述的类似，因为我们的团队领导更喜欢在一次提交（最好是小的）中完成所有相关的更改。
在完成对特性分支的更改后，我确保本地
master与上游分支匹配，然后是git rebase -i master。这让所有的东西都能在master上更新，
-i允许我查看我所有的提交--并按照我的团队领导的要求把它们压缩在一起。就像你建议的那样，变基总是我在发出pull request之前的最后一步。
cvxl0en26#
我想解释一个REBASING错误的场景：
假设您正在处理功能分支A，
1.你做了2个本地提交，提交ID分别为1和2。
1.现在，您将这些提交推送到您的远程功能分支，并且在远程分支上创建了相同的ID。
1.危险-现在，如果使用master/main/other对本地要素分支A进行REBASE（本地提交ID从1和2更改为例如21和22），然后您将添加ID为3的新提交提交，现在您决定将新的本地提交ID 3推送到远程特性分支A，GIT给出一个错误，说更新被拒绝，因为您当前分支的提示在后面
1.**请勿进行REBASE：**如果您已将本地更改推送到远程分支。
1.**仅在以下情况下才能多次REBASE：**您的更改是本地提交的。
**注意：**除了上述情况，永远不要在公共共享分支上进行Rebase，并始终遵循Rebase的黄金法则。如果有任何澄清，请让我知道