TFS 中的搁置和签入有什么区别？
各自是什么概念？
什么时候可以搁置更改而不是签入？
What is the concept of each?
When is it ok to shelve your changes instead of checking in?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
各自是什么概念？
什么时候可以搁置更改而不是签入？
What is the concept of each?
When is it ok to shelve your changes instead of checking in?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
搁置意味着更改被搁置以供您稍后处理。
签入意味着更改可供团队的其他成员使用，将在构建中并最终发布。
非常不一样。 将搁置视为未完成任务时进行上下文切换的工具。 签入意味着您已完成（至少完成了一部分）。
Shelved means the changes are set aside for you to work on later.
Checked in means that the changes are made available to the rest of the team, will be in the build and will eventually ship.
Very different. Think of shelving as a tool for context switching when you're not done with a task. Checking in means you're done (at least a part of it).
当您想要保存所做的更改，但需要返回到以前的版本以进行要部署的其他更改（可能是错误修复）而不需要当前正在处理的更新时，请搁置更改。 由于您通常会定期检查，因此我发现这种情况很少发生 - 就像我刚刚部署到 QA 框并立即发现错误一样。 我将搁置当天的更改，让我回到 QA 部署的版本，进行更新，然后取消搁置我的更改 - 根据需要合并两者。 如果超过这个时间，您可能会想要查看以前的版本并改为分支。 不过，我很高兴听到其他证明搁置更有用的经验。
Shelve your changes when you want to save the changes that you have made, but need to go back to the previous version to make other changes (perhaps, bug fixes) that you want to deploy without the updates you are currently working on. Since you're usually checking in pretty regularly, I find this to be a rare occurence -- like I just deployed to the QA box and an error was immediately found. I'll shelve that day's changes bringing me back to the QA deployed version, make the update, then unshelve my changes -- merging the two as necessary. Any longer than that and you'll probably be looking to check out a previous version and branch instead. I'd be happy to hear of other experiences where shelving has proved more useful, though.
其他用户可以通过搜索来下载您的书架集，因此这是传递代码以进行评论的好方法。 但是，如果您尝试取消搁置已签出的代码文件，则会收到错误消息，因此您需要准备一个干净的环境。
如果我正在处理一些我无法签入的重大事情，我经常会在一天结束时搁置所做的更改。这样，如果我的电脑一夜之间死机，我可以在服务器上获得备份。
Other users can download your shelvesets by searching for them, so it is a good way to pass code around for reviews. however you will get an error if you try to unshelve code files that you already have checked out, so you need a clean environment ready.
I often shelve my changes at the end of the day if I'm working on something big that I can't check in. That way, if my PC dies overnight, I've got a backup on the server.
达西说得对。 您还可以将搁置视为大部分不公开可见的私人分支。 也可以完全删除搁置集，而不是像删除签入的代码那样。 如果删除搁置集，它就会永远消失。
Darcy gets it spot on. You can also think of shelving as a private branch that is not publicly visible for the most part. Shelvesets can also be deleted completely, not like deleting checked in code. If you delete a shelfset it is gone forever.
楼上的各位都说得很对，我也从中学到了很多。
只是补充一下我的经验，如有错误请指正。 在一个项目中，我们有一个特定于开发者每台PC的配置文件mypc.json。 我们通常在本地运行服务器时覆盖它。 其他团队成员具有相同的文件名，但其中包含不同的配置。 没有人希望他们的文件以相同的名称推送到开发分支。 所以我使用搁置来保存这些类型的更改。 每当我需要这些配置时，我都可以轻松应用搁置中的更改，并且我的环境配置又回到了我的项目中。
Everyone above has said so much true and I learned allot from it.
Just to add my experience, correct me if I am wrong. In a project, we have a configuration file mypc.json specific to each PC of the developer. We usually override it when running server locally. Other team members have the same file name with different configurations in it. No one wants their file to be pushed with the same name to the development branch. So I use shelve to save these type of changes. Whenever I need these configurations I can easily apply changes from shelve and my environment configurations are back in my project.