logo标签列表

在git中，为什么应该在分支上工作而不是主分支？

gitversion-control
5

我经常看到关于在与主分支不同的分支上工作的建议。只要完成了工作，就将它们合并。这样做有什么好处，为什么不直接在主分支上工作呢？

我一开始看到的唯一优势是，这样就有一个相对安全的方式来知道什么是“最后已知的可工作版本”——即主分支。这是原因吗？

3个回答
4
在分支中工作的主要优势在于，您可以为一个隔离的功能进行提交，同时仍然能够在主分支上进行修复。如果您认为多个提交实际上应该显示为单个提交，则可以使用rebase -i等方式“压缩”提交，以便向其他用户展示。
您还可以同时处理多个实验性功能。您可能会后来决定放弃该功能或以另一种方式实现它，并且只需删除该分支即可，而无需使主分支历史记录混乱。
在任何给定项目中，我经常有几个实验性功能分支。即使只是快速将一些想法以代码形式记录下来，它们也非常有用。
3
这是我经常遇到的一个例子：
假设你正在开发一个非常复杂的功能，需要多次提交。你完成了大约一半，所以代码还不稳定，但进展顺利。
现在，在生产版本的代码中发现了一个关键性的错误（可能是您的主干分支）。如果您一直在对主干分支进行提交，该如何修复并推出修复程序而不会推出有问题、未完成的代码？
如果您在一个不是主干的分支上开发新功能，那么您可以轻松地切换到主干分支，修复错误并推出代码，然后切换回您的功能分支继续工作。
仅凭这个能力，我就足以在任何时候都创建一个新的分支了。
这正是我在讲rebase -i时所指的。你可以创建一个不完整的提交，然后将其压缩为一个“真实”的提交。非常好用。 - Jim Mitchener
此外，您可以简单地使用 git stash 命令来储藏您当前未提交的更改，并在主分支上进行修改。 - Jim Mitchener
如果您已经向主分支提交了更改，该怎么办？这在进行大型功能更改时经常发生。Stash 在这种情况下无法帮助您，但我理解您所说的压缩操作。 - Chris Cherry
如果需要进行一些修复并搞砸了master，当然可以始终执行git branch -m master feature && git checkout origin/master && git checkout -b master...只是这么说。 - Benjamin Bannier
好观点，这只是稍后创建“特性分支”。同时假设您有一个起点/主分支可以拉取，许多人都会有这个，谢天谢地。 - Chris Cherry
1
其他回答提出了一些很好的观点，但还有另一个重要的问题：如果您将工作发布到中央存储库，其他人也可以访问怎么办？也许是通过推送，也许是通过拉取请求，但总之，你做的事情会变得公开。坚持仅从您的主分支发布工作的常规确实有所帮助。
正如您所说，您可以将主分支视为“最后已知的工作版本”，但您也可以将其视为“我的最新稳定版本”。如果它是您唯一发布的版本，那么您就知道您不能对其进行任何疯狂的操作，但您也可以在任何其他分支上执行这些疯狂的操作。您可以自由地修改提交，压缩它们，重新构建分支，Git提供了所有这些方法来解决我们在开发时不可避免的疏忽。而且你永远不必考虑，“嗯，我已经推送了那个工作吗？”-你没有，因为它还没有在你的主分支上。您还可以尝试任何与编码相关的内容-砍掉，提交部分完成的工作，移动想法之间，无论您喜欢什么-并且有信心在将其合并到主分支之前，永远不会意外地向任何其他人显示它。
关键部分在于发布你的工作。如果这是你自己的私人存储库，如果你意识到你的主分支有问题，那只会给你带来不便。但一旦其他人参与进来，你可能也会给他们带来麻烦。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接