变基时 Gemfile.lock 发生冲突
在 Git 中变基时,人们有什么策略来解决 Gemfile.lock 冲突?
我在最近的一个项目中不得不经常这样做,这不仅很乏味,而且并不总是清楚如何进行合并。
What strategies do people have for resolving Gemfile.lock conflicts while rebasing in Git?
I am having to do this a lot in a recent project, and not only is it tedious, it's not always clear how to do the merge.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以通过合并驱动程序在每次合并时重新锁定它(我通常使用它在合并期间始终保留文件的本地版本)。
请参阅自动合并 Gemfile.lock” href="http://bitfission.com/" rel="noreferrer">威尔·莱因韦伯:
you could relock it on every merge, through a merge driver (that I usually use to always keep the local version of a file during a merge).
See "Auto Merge Gemfile.lock" from Will Leinweber:
使用 git log Gemfile.lock 查找先前提交的哈希值。然后运行 git checkout abcde Gemfile.lock 来恢复。之后您的
bundle install
命令应该可以工作。Use
git log Gemfile.lock
to find the hash of a previous commit. Then rungit checkout abcde Gemfile.lock
to revert back. Yourbundle install
command should work after that.您可以使用此脚本自动设置 git 存储库以使用提到的合并解析策略: https://gist .github.com/itspriddle/5548930
或者,您可以使用 tpope 的连接在 git pull 后自动执行此操作(并运行数据库迁移):https://github.com/tpope/hookup
You can use this script to automatically set up a git repository to use the mentioned merge resolution strategy: https://gist.github.com/itspriddle/5548930
Alternatively, you can use tpope's hookup to do this (and run database migrations) automatically after git pulls: https://github.com/tpope/hookup