有没有办法在某人推送 Mercurial 之前检查他们的代码？
我希望能够在其他开发人员将代码推送到中央存储库之前对其进行审查。开发人员位于偏远地区，因此无法前往他们的办公桌前进行操作。
目前他们只是推动，如果出现问题他们会回滚。但这不是一个好方法，因为有人可以在有机会回滚之前拉取。
I would like to be able to review other developers code before they push it to central repository. The developers are at remote locations so going to their desk is not an option.
Currently they just push and if there are issues they would rollback. But this is not a good approach since someone can pull before they get a chance to rollback.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Mercurial 是分布式的，因此应该能够适应任何工作流程。尝试将某人指定为集成经理或使用独裁者和副官工作流程。
Mercurial is distributed, and as such should be able to adapt to any workflow. Try designating someone as an integration manager or use the dictator and lieutenants workflow.
开发人员和主存储库之间的审查存储库怎么样？只有你从那里推到主要。
How about review repository between the developers and the main repository? Only you push from there to main.
我赞成凯洛蒂的答案，因为这只是它的扩展，但只是使用了存储库层。让人们将未经审查的变更集推送到需求审查中央存储库，并让审阅者将已审查的工作从那里推送到需求 QA 中央存储库，并让 QA 人员将发布候选版本中央存储库推送。
使用分布式版本控制系统，您可以像处理多个开发人员存储库一样轻松地处理多个集中式存储库。
I upvoted kelloti's answer as this is just an expansion of it, but just used tiers of repositories. Have people push their un-reviewed changesets to a needs-review central-ish repository, and have reviewers push reviewed works from there to the needs-QA central-ish repository and have QA people push the release candidate central-ish repositories.
With a distributed version control system you can do a plurality of centralized repos as easily as you can do a plurality of developer repositories.
在我的上一个项目中，我们遵循一个非常分支的开发模型 - 每个任务都有一个以任务编号命名的分支。针对指定分支执行代码审查。我们明确希望将它们推送到中央存储库并由开发人员拉取它们。
但是，在通过代码审查之前，没有名为分支的任务被合并到集成分支（在我们的情况下是默认分支，但它可以是任何功能分支）。
许多善变的开发人员不喜欢使用保留在存储库中的短期分支，但我发现它可以更轻松地跟踪历史记录，特别是在查看单个更改的历史记录时 - 您知道特定任务位于关联的命名分支上。
On my last project, we followed a very branchy development model - every task had a branch named with the task number. Code reviews were performed against the named branch. We explicitly wanted these pushed to the central repository and developers pulled them.
However, no task named branch was merged to the integration branch (in our case default, but it could have been any feature branch) until it had passed code review.
A lot of mercurial developers don't like to use short-lived branches that remain in the repository, but I find it makes it easier to follow the history, especially when looking at the history of a single change - you know that the changes for a particular task are on the associated named branch.
也许使用搁架扩展是一个很好的解决方案？我对 Mercurial 不太熟悉，但这可能对你有用。
https://www.mercurial-scm.org/wiki/ShelveExtension
Perhaps using a shelve extension is a good solution? I'm not very familiar with Mercurial but this might work for you.
https://www.mercurial-scm.org/wiki/ShelveExtension