Pull request reviews, the commit graph and merges in VS Code

All of this runs on KODEO's server with your own GitHub connection — a GitHub token never reaches VS Code.

Review a pull request

Pull Requests & Checks (KODEO side bar) lists the linked repository's open pull requests and the current commit's CI. Click one and it opens as a tab:

• Files changed — every file as a diff. Click a line number of the new code to comment on that line; your comments wait as pending until you submit the review.
• Conversation — the description and every comment, rendered from Markdown as text.
• Submit review — choose Comment, Approve or Request changes, add a summary, and your line comments go with it. (GitHub doesn't let you approve your own pull request — it says so.)
• Merge — create a merge commit, squash, or rebase. Merging needs editing rights in the project.
• Check out — switches the project to the pull request's branch, for everyone in it (KODEO's branches are project-wide); uncommitted changes are parked on the branch they were made on. If KODEO doesn't have the branch yet, it's fetched first.
• GitHub opens it on github.com. Right-click a pull request in the list for the same.

The commit graph

KODEO Git: Show Commit Graph (also in Source Control's menu and KODEO History's title bar) draws every branch as lanes, newest first, with branch and tag labels. Click a commit for the files it changed — each opens as a diff. Right-click a commit to copy its id, create a branch or tag there, or open it on GitHub. It refreshes itself when someone commits, switches branch, merges or fetches.

Blame

• Inline — who last changed the line your cursor is on, at the end of that line (setting KODEO › Git: Inline Blame).
• The whole file — KODEO Git: Toggle File Blame adds a column before every line: the commit, who and when, written once per run of lines from the same commit and shaded by age (recent changes stand out). Run it again to hide it.

Blame shows only for files that match the last commit — with uncommitted edits the line numbers wouldn't match.

Resolving merge conflicts

When a merge (or a pull) has conflicts, the files get the usual markers and appear under Merge Conflicts in Source Control.

• Above each conflict: Accept Current, Accept Incoming, Accept Both — or Open in Merge Editor.
• The merge editor (also the button on the file in Merge Conflicts) shows the current side, the incoming side and the result — the result is the file itself, so what you choose lands in the live file, in front of everyone. (Editors without VS Code's merge editor use the buttons above each conflict instead.)
• When a file has no conflicts left, stage it to mark it resolved; then commit.

Branch rules and branches on GitHub

• A Team workspace can protect the default branch (only admins commit or push to it) and require pull requests. VS Code says so before anything is refused — in the commit box's placeholder and when you push — and offers to create a branch instead. KODEO Git: Show Branch Rules shows them.
• Switch Branch… lists GitHub's branches too: pick one and it's fetched and checked out as a local branch that tracks it.
• A shallow clone (the default when bringing in a big repository) can fetch its whole history with KODEO Git: Fetch the Full History.