yarn package manager creates a
yarn.lock file when you install packages
yarn add. This file helps
yarn determine the proper dependency versions
I ran into a merge conflict recently between my branch's
yarn.lock file and
the one that existed on
master. My first instinct was to resolve the conflicts
by hand, but it felt wrong. According to
you shouldn't edit this file directly.
yarn will manage it by itself. If this
is the case, then what's the best way to handle these merge conflicts?
A comment on GitHub shows a more efficient and safer way to get around this problem.
Note: The comment discusses merge conflicts involving a `master` branch. This post will describe how to handle conflicts involving _any_ branch.
The first thing you need to do is rebase against the branch you're attempting to merge into:
git rebase <SOME_BRANCH>
This command will take all the commits on your branch and "replay" them on top
<SOME_BRANCH>. If you're unfamiliar with rebasing in
here's a good primer.
rebase each commit one at a time. Eventually you will run into your
first conflict in
yarn.lock. What you want to do is checkout the version from
the branch you are rebasing against:
git checkout -- yarn.lock
Understanding this command requires some knowledge of rebasing in
first bit of context we have is a
in the same issue as the one I linked above:
git checkout -- yarn.lock, which is more general and just resets it to whatever is committed on your current branch."
The GitHub user @idris recommends this command over the one shown in the first comment. But why? What do they mean by "more general", and what is the "current branch"?
At first it would seem that the current branch is our branch. At least that's how I perceived it. This confused me, so I took to Google. After some digging I found this StackOverflow comment. It explains the concept in detail.
During a rebase, the current branch is the branch that you're rebasing against.
In this case we are rebasing against
SOME_BRANCH, so it is the current branch.
This means that running
git checkout -- yarn.lock resets
whatever exists on
The command is the same as running:
git checkout SOME_BRANCH -- yarn.lock
The comment from @idris says we can omit the name of the branch, making the
command "more general".
git will just give us the file from whatever branch
we're rebasing against.
Pretty neat! 💯
After checking out the other branch's
yarn.lock file it's time to install
your branch's dependencies:
yarn will update the contents of
yarn.lock, using your branch's
package.json for context.
Once the process finishes you can add
yarn.lock and continue with the rebase:
git add yarn.lockgit rebase --continue
Depending on the situation you may run into further conflicts for each commit. All you have to do is rinse and repeat the steps above. That's all, folks!