TFS中的搁置仅仅是一种软签入,以便其他团队成员可以看到源代码吗?

即搁置的代码将不会被编译,对吗?


当前回答

我经常遇到这个,关于分支的补充信息:

如果您正在处理多个分支,则搁置集将绑定到创建它们的特定分支。因此,如果您让一个变更集在货架上生锈太久,并且不得不将其释放到不同的分支,那么您就必须在7月份发布的电动工具中这样做。

tfpt unshelve /migrate

其他回答

搁置是一种在不签入的情况下保存所有更改的方法。更改被持久化在服务器上。在以后的任何时候,您或您的任何队友都可以将它们“解置”到您的任何一台机器上。

它也非常适合复习。在我的团队中,为了签入,我们将更改搁置起来,并发送带有更改描述和更改集名称的电子邮件。然后,团队成员可以查看变更集并给出反馈。

供您参考:查看搁置集的最佳方法是使用以下命令

tfpt review /shelveset:shelveset;用户名

tpt是Team Foundation Power Tools的一部分

搁置就像将更改存储在源代码控制中,而不影响现有更改。意味着如果你在源代码控制中签入一个文件,它会修改现有的文件,但搁置就像在源代码控制中存储你的更改,但不修改实际的更改。

这是正确的。如果您创建了一个架子,那么执行get latest操作的其他人将不会看到您的代码。

它将您的代码更改放到服务器上,这可能比您的工作PC备份得更好。

它使您能够在另一台机器上获取更改,如果您想在家工作的话。

其他人可以看到您的货架(尽管我认为这可能是可选的),因此他们可以在签入之前检查您的代码。

@JaredPar: 是的,你可以使用搁置集进行审查,但请记住,搁置集可以被自己或他人覆盖,因此不是长期稳定的。因此,对于法规相关的审查,您永远不应该使用搁置集作为基础,而应该使用签入(变更集)。 对于非正式的审查,这是可以的,但对于正式的(例如与自由贸易协定相关的)审查就不行!

置物架有很多用途。主要有:

Context Switching: Saving the work on your current task so you can switch to another high priority task. Say you're working on a new feature, minding your own business, when your boss runs in and says "Ahhh! Bug Bug Bug!" and you have to drop your current changes on the feature and go fix the bug. You can shelve your work on the feature, fix the bug, then come back and unshelve to work on your changes later. Sharing Changesets: If you want to share a changeset of code without checking it in, you can make it easy for others to access by shelving it. This could be used when you are passing an incomplete task to someone else (poor soul) or if you have some sort of testing code you would never EVER check in that someone else needed to run. h/t to the other responses about using this for reviews, it is a very good idea. Saving your progress: While you're working on a complex feature, you may find yourself at a 'good point' where you would like to save your progress. This is an ideal time to shelve your code. Say you are hacking up some CSS / HTML to fix rendering bugs. Usually you bang on it, iterating every possible kludge you can think up until it looks right. However, once it looks right you may want to try and go back in to cleanup your markup so that someone else may be able to understand what you did before you check it in. In this case, you can shelve the code when everything renders right, then you are free to go and refactor your markup, knowing that if you accidentally break it again, you can always go back and get your changeset.

还有其他用途吗?