Git in Elyra: the repository belongs to the project
Understand where Git lives in Elyra, what the panel's five sections are, and why the base branch is not the same as the publish destination.
Git in Elyra follows the project folder, not the workspace folder. A workspace is a unit of work — a name and a folder, possibly on another machine — and several workspaces can point to the same repository or to different folders. When you commit, push, or open a pull request, the operation happens in the repository of the open project, even if the current workspace is another one.
Where it lives
The Git panel lives in the inspector, the panel docked on the right that opens from the context line and
closes with Esc. There is no fixed Git bar: it is invoked when you need it and steps out of the way when
you don’t.
The panel has two parts that never leave the screen:
- The header answers three questions with no click at all — which branch you are on, what hasn’t left here yet, and what this is being compared against.
- The dock, at the bottom, is the place for the commit message and, with a clean tree, for the remote actions.
The body is divided into five sections:
| Section | What it shows |
|---|---|
| Changes | The files that changed, split into modified, staged, untracked and conflicted |
| Commits | The repository history, with the files and the diff of each commit |
| PR | The pull request or merge request of the branch: conflicts, checks and review comments |
| Issues | The repository’s open issues on the provider |
| Worktrees | The parallel checkouts of the repository |
The header stays mounted above all of them on purpose: a check that breaks while you are looking at “Changes” stays in view. The sections also carry signals — changed-file count, conflict, failing checks, open comments without resolution — and a conflict takes over the changes section, because nothing else moves while it exists.
Base branch is not a publish destination
This is the distinction that confuses people the most, and Elyra keeps the two things separate:
- The base is the reference the panel compares your work against: how many commits you have on top of it, which files changed relative to it. Changing the base changes the comparison and does not switch the current branch nor merge anything.
- The publish upstream is where your commits go when you publish the branch.
One can diverge from the other without any problem: comparing against the repository’s main branch while publishing to a branch of your own is the common case.
Workspace and worktree are different things
The word worktree appears only in the Git screen — and for a reason. A worktree is an extra checkout of
the same repository, on another branch and in another folder, so that two lines of work don’t fight over the
same files. It is a feature of Git itself.
A workspace is a unit of work in Elyra: a name, a folder and possibly a machine. Creating a worktree does not create a workspace, and the worktree list shows checkouts that Elyra did not create — including those made by hand in the terminal. Nothing is adopted automatically: if you want to work in that folder as an app workspace, the choice is explicit.
Scope and limits of this page
- The project’s Git can be local or remote. With a project on another machine, the commands run there, not on your computer; the panel does not decide that — the open project does.
- A folder without a repository is not an error. The panel offers to start a repository or detect an existing one; without git installed, it warns instead of pretending an empty list.
- A stale read does not become truth. When a re-read fails, the panel marks the state as unavailable instead of continuing to assert the last number read as if it were current.
- Providers. The PR and Issues sections cover GitHub and GitLab. Bitbucket, Azure DevOps and Gitea appear with the explanation that they are not supported — the documentation does not promise an integration that does not exist.