在 git 中，为什么应该在分支而不是主分支上工作？
我一直在阅读有关如何始终在与主分支不同的分支上工作的内容。一旦我完成工作，我就会将它们合并。为什么这比简单地在主分支上工作更好？
我第一眼看到的唯一优点是，有一种比较安全的方法可以始终知道什么是“最后一个已知的工作版本”——主分支。是这个原因吗？
I keep reading about how one should always work on a different branch than the main one. As soon as I get the job done, I merge them. Why is this any better than simply working on the main branch?
The only advantage I see at first glance is that then there is a somewhat safe way of always knowing what is the "last known working version" -- the main branch. Is that the reason?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在分支中工作的主要优点是，您可以对孤立的功能进行提交，同时仍然能够在主服务器上进行修复。如果您认为多个提交实际上应该显示为对其他用户的单个提交，您还可以使用
rebase -i执行“挤压”提交之类的操作。您还可以同时处理多个实验性功能。您稍后可能决定废弃该功能或以其他方式实现它，并且您可以删除该分支而不会弄乱您的主历史记录。
我经常在任何给定项目中都有一些实验性功能分支。即使只是以代码的形式快速记下一些想法，它们也非常有用。
The primary advantage of working in a branch is that you can make commits for an isolated feature while still being able to make fixes on master. You can also do things like "squash" commits with
rebase -iif you feel that multiple commits should actually show up as a single commit to other users.You can also work on multiple experimental features at the same time. You may later decide to scrap that feature or implement it in another way and you can just delete that branch without cluttering your master history.
I often have a handful of experimental feature branches in any given project. Even for just quickly jotting down some thoughts in the form of code they are very useful.
这是一个对我来说经常发生的例子：
假设您正在开发一项功能，它是一项广泛的功能，因此需要进行多次提交。您已经完成了大约一半，因此代码不稳定，但进展顺利。
现在，在代码的生产版本（可能是您的主分支）中发现了一个严重错误。如果您一直在针对主分支进行提交，那么如何修复它并推出修复程序而不推出损坏的未完成代码？
如果您一直在非主分支中开发新功能，则可以轻松切换到主分支，修复错误并推出代码。然后切换回您的功能分支并继续工作。
单独做到这一点的能力足以让我在任何时候做某件事时建立一个分支。
Here's one example that happens a lot for me:
Let's say you are working on a feature, its an extensive one, so its going to take many commits. You are about half way done, so the code isn't stable, but it's coming along nicely.
Now, a critical bug is found in the production version of the code, (your master branch, presumably). If you have been committing against the master branch, how do you fix it and push out the fix without pushing out the broken unfinished code?
If you had been working on your new feature in a branch that isn't the master, you can easily just switch to the master branch, fix the bug, and push out the code. Then switch back to your feature branch and continue working.
The ability to do that alone is enough for me to make a branch anytime im working on something.
其他答案提出了一些很好的观点，但还有另一个重要的观点：如果您将工作发布到其他人也可以访问的中央存储库怎么办？也许通过推送，也许通过拉取请求，但结果是你所做的事情就在那里。坚持仅从主分支发布工作的惯例确实有帮助。
正如您所说，您可以将 master 视为“最后一个已知的工作版本”，但您也可以将其视为“我最新的稳定版本”。如果它是您发布的唯一分支，那么您就知道您永远无法对它做任何疯狂的事情，而且您可以对任何其他分支做这些疯狂的事情。您可以自由地修改提交、压缩它们、重新调整分支基础，Git 提供的所有这些方法都可以解决我们在开发过程中不可避免的疏忽。你永远不必想，“嗯，我已经推动了这项工作吗？” - 你还没有，因为它还没有在你的主分支上。你也可以尝试任何事情，编码方面 - 破解、提交部分完成的工作、在想法之间移动，无论你喜欢什么 - 并且相信你永远不会意外地向其他人展示它，直到你说“我完成了”并且将其合并到 master 中。
这里的关键部分是出版你的作品的概念。如果这是您自己的私人存储库，如果您意识到您的主分支以某种方式损坏，这只会给您带来不便。但一旦涉及到其他人，你也可能会惹恼他们。
The other answers have made some good points, but there's another big one: what if you publish work to a central repository, which others also access? Perhaps by pushing, perhaps by pull requests, but the upshot is that things that you do get out there. Sticking to the convention of publishing work only from your master branch really helps.
As you said, you can think of master as "the last known working version", but you can also think of it as "my newest stable version". If it's the only one you publish from, then you know that you can't ever do anything crazy to it, but also that you can do those crazy things to any other branch. You have free reign to amend commits, squash them, rebase branches around, all of those ways that Git provide to fix the inevitable oversights we make while developing. And you never have to think, "hm, did I push that work already?" - you haven't, since it's not on your master branch yet. You can also try anything, coding-wise - hack away, commit partially finished work, move around between ideas, whatever you like - and be confident you'll never accidentally show it to anyone else until you say "I'm finished" and merge it to master.
The key part here is the notion of publishing your work. If this were your own private repository, if you realized your master branch was broken in some way, it'd only inconvenience you. But as soon as other people are involved, you could be messing with them too.