版本控制系统->分支问题
我正在处理下一个任务，突然意识到我需要与主管讨论一些细节才能继续。几天后我会见我的主管时会讨论这个问题。在那之前我需要完成另一项任务。
正确的做法是什么？
我看到 2 个选项：
1）将头修订版从存储库复制到新分支并在那里启动另一个任务。完成后 - 将其合并到主干。或者也许我需要先从主干合并到分支，然后再合并回主干？
2) 从工作副本复制到新分支。将主干恢复到最新版本（在开始我需要讨论的任务之前），切换到主干并处理另一个任务，然后在分支中完成当前任务并合并。
请详细解释正确的方法，因为我不是经验丰富的 VCS 用户。先感谢您。
I am working on the next task and suddenly understand that I need to discuss some details with my chief in order to continue. I will discuss it in a couple of days when I meed my chief. Until then I need to work on another task.
What is the correct way to do?
I see 2 options:
1) Copy head revision from repository to a new branch and start another task there. After I finish it - merge it to the trunk. Or maybe I will need to merge from trunk to the branch first, and then merge back to the trunk?
2) Copy from working copy to a new branch. Revert trunk to the last revision (before I started the task I need to discuss), switch to the trunk and work on another task, then finish my current task in the branch and merge.
Please, explain correct way in details, as I am not an experienced VCS user. Thank you in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您面临的问题是您在主干上开始了更改，但想将其提交到其他地方。不幸的是，大多数版本控制系统没有内置的行为。在 SVN 中，最好的选择是：
希望有帮助
The trouble your facing is that you started the changes on trunk but want to commit it somewhere else. Most version-control systems don't have a built in behavior for this, which is unfortunate. In SVN, your best bet is this:
Hope that helps
实际上，这两种选择都适合您，并且没有哪一种比另一种更正确。决定最简单行动方案的是合并更改所需的难度。一般来说，在 svn 中，如果可能的话，您希望避免合并。
通常这种决定取决于你的团队文化；如果您的同事通常不希望在主干中进行未完成/未批准的更改，那么将您的更改移动到分支，然后在您的主管批准您的代码后合并是有意义的。当然，如果您单独工作，那么一切都取决于您。
您确实有第三种选择，根据您的情况，它可能有效也可能无效，即同时处理主干中的两项任务，并分别提交各个更改。
Really both choices will work for you and neither is more correct than the other; what will determine the easiest course of action is the difficulty required to merge the changes. In general in svn you want to avoid merging, if possible.
Usually this kind of decision depends on your team culture; if your coworkers don't generally want unfinished/unapproved changes in the trunk then it makes sense to move your changes to the branch and then merge after your chief approves your code. Of course if you are working solo then it is all up to you.
You really have a third option that may or may not work depending on your situation, which is just to work on two tasks in the trunk at the same time, and commit the individual changes separately.
我会选择第一个选项，因为我可以保持后备箱清洁（始终工作）。因为你说的功能还需要你老板确认。如果该功能最终被丢弃，您的主干仍然不会受到影响，并且团队中的其他成员也不会对该更改感到困惑。
I will do the first option because I can keep my trunk clean (working at all time). Since the feature you are talking about still need to be confirmed by your boss. If the feature end up thrown away, you trunk will still be unaffected and other members in your team will not be confused with that changes.
我们基于发布而不是任务进行分支。所以现在我们准备在几周内发布的所有内容都在分支 5.1.1 中。当更改发布到生产环境时，这些更改将合并回主干。
We branch based on release not task. So right now everything we are getting ready to release in a few weeks is in branch 5.1.1. The changes are merged back to trunk when they are published to production.