我正在开发一个本地分支的功能。我刚刚重新定义它，并将我的更改合并回主分支。如果我想继续在当地分支机构发展，我可以继续在现有分支机构中发展吗？如果我使用该分支进行rebase，它是否会重置自上次合并以来的提交，还是会再次对所有对该分支进行的提交进行修改？
或者我应该删除它并开始一个新的？
感谢。
答案 0 :(得分：1)
您不必每次都进行变基。您可能会有更多冲突需要解决，因为rebase一次只应用一次提交。所以请考虑合并。
如果您将主题分支指向新的合并提交，则第二个rebase将仅在您合并后移动提交。 Rebase下降到历史记录中的最后一个常见提交，并将该范围移动到您指定的分支之上。
注意：
重新定位有效更改该分支的历史记录。如果其他人也在那个分支上工作，当他们试图推动他们的改变时，你会给他们一个令人讨厌的惊喜，git告诉他们他们不能！这是有充分理由的。他们将不得不重新调整他们的工作来推动它。正如您所看到的，这可以在更多人一起工作的圈子中继续。
合并并不像有些人想象的那么邪恶。因为很多人习惯于基于主干的开发，所以他们喜欢看到一个很好的线性历史。当每个人都在合并时，它看起来会有很大的不同！对此的答案是，最终我们需要查看加入提交的行，并且可以简单地依靠工具来告诉我们已经合并的内容以及仍然需要合并的内容 - 无论将所有内容连接在一起的毛茸茸的线条。合并可能是您在获得更多经验时会更加欣赏的。
由于你正在为你的功能做一个分支，这是一个很好的阅读我正在使用的过程，并希望它可以阐明每个功能分支的优缺点。希望你让他们保持短暂的生活！链接：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
答案 1 :(得分：1)
是的，你可以继续在你当地的分支机构工作（假设它叫做feature），随时随地git rebase master进行feature。关于这一点的一点要注意的是，一般情况下，一旦你将其公开（即将其推送到另一个存储库或允许某人从你的存储库中获取它），你就不应该对你的分支进行rebase。当您考虑到您正在开发的功能已完成并经过测试时，您应该只将feature分支合并到master。之后，如果你想添加另一个功能，我会为此创建一个新的分支。
当您在git rebase master时运行feature时，git会首先考虑feature中master以内的所有更改。 （这大约是您从git log master..feature看到的提交集。）然后尝试将每个提交引入的更改重新应用到master，但跳过任何似乎已经应用的提交。这种情况的含义是，如果您已将feature合并到master，然后在feature上进行了更多提交，那么只有在合并后才会重新应用于{{1}}随后的变种。