在变基并合并到 master 之后，我是否必须（或者应该）删除我的本地分支？
我正在本地分支机构开发一项功能。我只是重新调整了它的基础，并将我的更改合并回主分支。如果我想继续在当地分公司发展，可以在现有的分公司继续发展吗？如果我使用该分支进行变基，它会变基自上次合并以来的提交，还是会再次变基对该分支所做的所有提交？
或者我应该删除它并开始一个新的？
谢谢。
I'm developing a feature in a local branch. I just rebased it, and merged my changes back into the main branch. If I want to continue to develop in a local branch, can I continue to develop in the existing one? If I rebase with that branch, will it rebase the commits since the last merge, or will it once again rebase all the commits that have been made to that branch?
Or should I just delete it and start a new one?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，您可以继续在本地分支上工作（假设它称为
feature），并且只要您愿意，就可以在feature上执行git rebase master>。对此需要注意的一点是，一般来说，一旦您将分支公开（即将其推送到另一个存储库或允许某人从您的存储库中获取它），您就不应该对其进行变基。仅当您认为您正在开发的功能已完成并经过测试时，才应将您的feature分支合并到master中。之后，如果你想添加另一个功能，我会为此创建一个新分支。当您在使用
feature时运行git rebase master时，git 首先会考虑feature中未包含在中的所有更改大师。 （这大约是您从 git log master..feature 中看到的一组提交。）然后它尝试将每个提交引入的更改重新应用到 master 上，但是跳过任何似乎已经应用的内容。在您的情况下，这意味着，如果您将feature合并到master中，然后对feature进行了更多提交，则只有这些由于合并将在后续变基中重新应用。Yes, you can carry on working on your local branch (let's say it's called
feature) and whenever you like do agit rebase masterwhile onfeature. The one point of caution about this is that in general you shouldn't rebase your branch once you've made it public (i.e. pushed it to another repository or allowed someone to fetch it from your repository). You should only merge yourfeaturebranch intomasterwhen you consider the feature that you've been developing to be complete and tested. After that, if you want to add another feature, I would create a new branch for that.When you run
git rebase masterwhile you're onfeature, git starts by considering every change infeaturethat isn't inmaster. (This is approximately the set of commits you see fromgit log master..feature.) It then tries to reapply the changes introduced by each of those commits ontomaster, but skipping any that seem to have already been applied. The implication of this in your situation is that if you've mergedfeatureintomasterand then made some more commits onfeature, it's only those since the merge that will be reapplied in a subsequent rebase.您不必每次都重新设置基准。当变基一次应用您的提交时，您可能会遇到更多冲突需要解决。因此，请考虑仅合并。
如果您将主题分支指向新的合并提交，则第二次变基只会移动合并后的提交。变基会下降到历史上最后一次公共提交，并将该范围移动到您指定的分支顶部。
注意：
有效地改变该分支的历史记录。如果其他人也在该分支上工作，当他们试图将更改向上推而 git 告诉他们不能时，你会给他们一个令人讨厌的惊喜！这是有充分理由的。他们将不得不重新调整他们的工作以推动其发展。正如您所看到的，随着越多的人一起工作，这种情况就会不断循环下去。
合并并不像某些人想象的那么邪恶。因为很多人习惯了基于主干的开发，他们喜欢看到漂亮的线性历史。当每个人都融合在一起时，它看起来会很不一样！答案是，最终我们不再需要查看连接提交的行，而是可以简单地依靠工具来告诉我们什么已经合并，什么仍然需要合并 - 无论将所有内容连接在一起的毛茸茸的线如何。当你获得更多经验时，合并可能是你会更加欣赏的事情。
由于您正在为您的功能创建一个分支，所以这是一本关于我所使用的流程的好读物，并希望它能够阐明每个功能分支的优缺点。希望你让它们短暂！链接：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
You don't have to rebase each time. You will potentially have many more conflicts to resolve as a rebase applies your commits one at a time. So consider just merging instead.
The second rebase will only move the commits since you merged if you point your topic branch onto the new merge commit. Rebase goes down to the last common commit in history and moves that range on top of the branch you specify.
Notes:
Rebasing changes history effectively of that branch. If someone else is working on that branch as well, you will give them a nasty surprise when they try to push their changes up and git tells them they can't! This is for a good reason. They will have to rebase THEIR work to push it up. As you can see, this can go on in circles the more people work together.
Merging is not as evil as some people think. Because a lot of people are used to trunk-based development, they like to see a nice linear history. When everyone is merging, it can look quite different! The answer to this is that eventually we outgrow needing to look at lines joining commits and can simply rely on the tooling to tell us what is merged already and what still needs merging - regardless of the hairy lines connecting everything together. Merging is probably what you will appreciate more as you get more experience.
Since you are doing a branch for you feature, this is a good read about a process that I work with and hope it can shed a bit of light on the pros and cons of branch-per-feature. Hope you keep them short lived! link: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR