Menu
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.
991
The Gemfile is where you specify which gems you want to use, and lets you specify which versions. The Gemfile. lock file is where Bundler records the exact versions that were installed. This way, when the same library/project is loaded on another machine, running bundle install will look at the Gemfile.
The Gem Development guide says that the Gemfile. lock file "should always be checked into version control." However, this is NOT true for Gems. For Applications, like your Rails apps, Sinatra apps, etc., it is true. The same does not go for Gems.
Gemfile. lock is automatically generated when you run bundle install or bundle update . It should never be edited manually.
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:
All you have to do is run
(obsolete in Rail3)bundle lockbundle installto getbundlerto relock then add that and continue your rebase.First is your
~/.gitconfigfile.
Here we're going to give it a new merge strategy, one that will just relock the gemfile.
Add this to the end:
[merge "gemfilelock"] name = relocks the gemfile.lock driver = bundle install Next up, we have to tell git to use our new strategy for
Gemfile.lock, and we do that withgitattributes.
You can either put this inproject/.git/info/attributesorproject/.gitattributes.
Gemfile.lock merge=gemfilelock If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
