对于开发人员来说，Git 中的分支如何比常规的提交/推送/拉取周期更有效？
我已经使用 git 一段时间了，我喜欢它，但是，我通常以 cvs/svn 风格使用它（我不分支/分叉，除非我无法访问头部）。
我发现提交/拉取/推送循环是有效的：如果出现冲突，我通常只需签出源代码的新副本，重新合并我的更改，然后继续。当然，如果我在源代码树中编辑热点，就会出现问题 --- 但我认为这是任何多开发人员源代码控制工作流程的问题。
所以我的问题是：与 cvs 风格、集中提交/拉/推开发周期相比，我怎样才能开始实现 git“分支”开发工作流程产生的附加值？一般来说，当采用这种主要的 git 风格的开发实践时，我们是否会看到生产力的提高？
I have been using git for some time now, and i like it, however, I generally use it in the cvs/svn style (i dont branch/fork unless I don't have access to the head).
I find that the commit/pull/push cycle is effective: if I have conflicts, I usually just checkout a fresh copy of the source, remerge my changes, and move on. Of course, if I edit a hotspot in the source tree, there are issues --- but i assume that this is a problem with any multi-developer source control workflow.
So my question is: how can I begin to realize the added value which git "branch" development workflows yield, compared with cvs style, centralized commit/pull/push development cycles? In general, do we see a rise in productivity when adopting such staple git-style development practices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在单分支模型中，大更改只有两种可能性：
大更改作为单个提交签入。这太糟糕了，在整个事情完成之前，从事更改的人员将无法使用源代码控制。如果更改需要四个星期，那么这四个星期就没有源代码控制。 （想象一下，如果您想在这四个星期内在两个不同的工作站上工作......）
大型更改会作为多次提交进行签入。这太可怕了，任何同时检查代码的人都会得到一棵断树。如果更改需要四个星期，那么这四个星期里没有其他人可以完成任何事情。
唯一可行的解决方案是分支和合并。
注意：我希望这是您帖子中的拼写错误。正确的循环是提交/拉取/推送。在合并并测试合并结果之前，不要推送更改。否则，您只是将未经测试的代码提供给其他人，这只会为您带来干草叉和火把。
In a one-branch model, there are only two possibilities for large changes:
The large change gets checked in as a single commit. This is terrible, the person working on the change won't be able to use source control until the entire thing is finished. If the change takes four weeks, that's four weeks without source control. (Imagine if you want to work on two different workstations during those four weeks...)
The large change gets checked in as several commits. This is terrible, anyone who checks out the code in the meantime gets a broken tree. If the change takes four weeks, that's four weeks where nobody else can get anything done.
The only viable solution is to branch and merge.
Note: I hope that was a typo in your post. The correct cycle is commit/pull/push. Don't push your changes until you've merged and tested the resulting merge. Otherwise you are just giving untested code to other people, which will earn you nothing but pitchforks and torches.
svn）。如果较新的 svn 确实记录了合并，那么大部分工作应该可以通过它实现，但是在远程集中存储库上模拟此工作流程也慢。
svndoes it as well now, but haven't worked with newersvn).Most of it should be possible with newer svn if it indeed records merges, but emulating this workflow on a remote centralized repository is also slow.
事实上，分支非常重要。想象一下您和您的同事正在开发一项功能。你们俩花了几天时间来编写代码。与此同时，您可能希望编译自己的代码并对其进行测试，而不想让您的同事在您的程序中引入损坏的代码。分支可以帮助您将自己对源的修改分开，直到您决定合并它们。
另一个例子可能是您想要发布软件并且需要对其进行广泛的测试/调试。与此同时，您的同事已经开始开发下一个版本。此处的分支可以帮助您将正在测试的旧代码和正在开发的代码分开。
您可以在此处查看有趣的分支使用模式。
有了 Git，您就不必害怕合并。如果您曾经尝试故意制造冲突然后解决它，您就会知道这很简单。实际上，除非两个人对代码的同一部分做出了广泛的贡献，否则解决冲突并不是什么大问题。
Branching is in fact quite important. Imagine you and your colleague are each working on a feature. It takes both of you a couple of days to write the code. In the meanwhile, you would want to compile your own code and test it, without having broken code introduced in your program by your colleague. Branching helps you keep your own modification to the source separate, until you decide to merge them.
Another example could be that you reach a point that you want to release your software and you need to put it under extensive test/debugging. In the meanwhile your colleague has already started working on the next version. Branching here helps you keep the older code being tested and the code under development apart.
You could take a look here for an interesting usage pattern of branches.
And with Git, you don't need to be afraid of merging. If you have ever tried intentionally creating a conflict and then resolve it, you would know it is simple. In reality, unless two people have contributed extensively to the exact same part of the code, resolving the conflicts is not such a big deal.