VSCode Compare & Merge Branches with GitLens assist

Question

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?

Wesle

Two engineers contributing on the same branch can occur when two developers choose to pair up on a feature. Or the feature is large enough that more than one engineer (or engineering subject matter experts) is required to complete the feature. – Snapshot

Answer 1

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.

Snapshot

Answer 2

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!

Chamaeleon

Answer 3

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 .

Scalawag