---
id: "fluxos.git-conceito"
titulo: "Git in Elyra: the repository belongs to the project"
resumo: "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."
idioma: "en"
tipo: "conceito"
categoria: "arquivos-git"
aplicavelDesde: "0.0.16"
capabilities: ["git.panel.navigate", "git.branch.base", "git.worktrees.list"]
estadoEditorial: "aprovado"
nivelEvidencia: "artefato-distribuido"
refFonte: "27574c339b58316408f6be2d62169d59041d07bf"
revisaoFonte: "2026-09-24"
revisor: "mantenedor (v1, 2026-10-03)"
rota: "/docs/en/fluxos/git-conceito/"
fonte: "pt-br/fluxos/git-conceito.md"
caminhoPublico: "docs/publica/en/fluxos/git-conceito.md"
hashFonte: "sha256:e54fb3fd85f5620d22afb6c608b161d1ae59720aa5548a5ea2a9980fe9d29085"
hashDestaPagina: "sha256:6f541777b7d866af682d2fae27d6dcdc225389ab6ee8b356dc4f7e94772eef89"
traducaoAssistidaPorIA: true
traducaoDesatualizada: false
corpoRetido: false
---
<!-- traducao-assistida-por-ia: idioma=EN fonte=pt-br/fluxos/git-conceito.md fonteHash=sha256:e54fb3fd85f5620d22afb6c608b161d1ae59720aa5548a5ea2a9980fe9d29085 estado=atual -->

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.

## Next steps

- [Changes and diff](/docs/en/fluxos/git-alteracoes-e-diff/)
- [Stage and create a commit](/docs/en/fluxos/git-preparar-e-commitar/)
- [Repository worktrees](/docs/en/fluxos/git-worktrees/)