VSCode Compare & Merge Branches with GitLens assist

Viewed 9746

There is some basic glitch in my understanding of VSCODE and GitLens.(and maybe I need remedial GIT training, oh well).

I am looking to merge a branch someone else created (and checked into BitBucket, so GitBucket PullRequest extension is not an option).

With GitLens I can visually compare branches. With VSCODE & GitLens I can interactively approve/deny each change that occur on the same branch where both of us modified and committed different changes (BTW, where is THAT useful. Does don't most developers create a different feature branch, and not have two developers changing a single branch at one time).

But how can I have the combination of effects, both working on separate feature branches, and then the ability to merge both branches? (not just overwrite with the new merge, but interactively see both changes and approve or disapprove or add both?), and keep all the blame annotation?

3 Answers

The quick Git howto would be:

  1. First merge the other branch into yours: git merge [other branch]

  2. Fix any merge conflicts using the editor or a favorite diff tool.

  3. Commit the merge: git commit

Then periodically when you want to stay current with the other branch, repeat the process. But to keep it as merge-conflict seamless as possible, it's best your branch merges into the mainline. And that you repeat the steps above after they make their final commit to that branch and before you merge into the mainline. Or that they merge back into your branch and then you merge again back to the mainline if they make changes after you merged to mainline.

I'd say your best bet would be to rebase to target on one of the branches, then merge it in, and then do the same with the next one.

So for the second merge, you'd be dealing with the first branch's changes already applied. In this case, you can then choose to approve/disapprove the change or keep both.

Hope this helps!

In my mind's eye, I would merge the 2 branches together without squashing anything(to keep the blame annotations) and then user VSC & GitLens to interactively pick and choose.

Another option is to educate the devs to use commits properly(every logical unit per commit) and then cherrypick whatever you need .

Related