---
id: "fluxos.git-conceito"
titulo: "Git no Elyra: o repositório é do projeto"
resumo: "Entenda onde o Git mora no Elyra, quais são as cinco seções do painel e por que a branch base não é o mesmo que o destino de publicação."
idioma: "pt-br"
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/pt-br/fluxos/git-conceito/"
fonte: "pt-br/fluxos/git-conceito.md"
caminhoPublico: "docs/publica/pt-br/fluxos/git-conceito.md"
hashFonte: "sha256:e54fb3fd85f5620d22afb6c608b161d1ae59720aa5548a5ea2a9980fe9d29085"
hashDestaPagina: "sha256:e54fb3fd85f5620d22afb6c608b161d1ae59720aa5548a5ea2a9980fe9d29085"
traducaoAssistidaPorIA: false
traducaoDesatualizada: false
corpoRetido: false
---
O Git no Elyra segue **a pasta do projeto**, não a pasta do workspace. Um workspace é uma unidade de
trabalho — um nome e uma pasta, possivelmente outra máquina — e vários workspaces podem apontar para o
mesmo repositório ou para pastas diferentes. Quando você faz um commit, um push ou abre um pull request,
a operação acontece no repositório do **projeto aberto**, mesmo que o workspace atual seja outro.

## Onde fica

O painel de Git vive no inspetor, o painel ancorado à direita que se abre pela **linha de contexto** e
fecha com `Esc`. Não existe barra fixa de Git: ele é invocado quando você precisa e sai da frente quando
não.

O painel tem duas partes que nunca saem da tela:

- **O cabeçalho** responde três perguntas sem clique nenhum — em que branch você está, o que ainda não
  saiu daqui, e contra o que isto está sendo comparado.
- **A doca**, embaixo, é o lugar da mensagem de commit e, com a árvore limpa, das ações de remoto.

O corpo é dividido em cinco seções:

| Seção | O que mostra |
|---|---|
| **Alterações** | Os arquivos que mudaram, separados em alterados, no commit, sem rastreio e em conflito |
| **Commits** | O histórico do repositório, com os arquivos e o diff de cada commit |
| **PR** | O pull request ou merge request da branch: conflitos, checks e comentários de revisão |
| **Issues** | As issues abertas do repositório no provedor |
| **Worktrees** | Os checkouts em paralelo do repositório |

O cabeçalho fica montado acima de todas elas de propósito: um check que quebra enquanto você olha
"Alterações" continua à vista. As seções também carregam sinais — contagem de arquivos alterados,
conflito, checks falhando, comentários abertos sem resolução — e um conflito manda na seção de
alterações, porque nada mais anda enquanto ele existir.

## Branch base não é destino de publicação

Esta é a distinção que mais confunde, e o Elyra mantém as duas coisas separadas:

- **A base** é a referência com que o painel **compara** o seu trabalho: quantos commits você tem sobre
  ela, quais arquivos mudaram em relação a ela. Trocar a base muda a comparação e **não** troca a branch
  atual nem mescla nada.
- **O upstream de publicação** é onde os seus commits vão quando você publica a branch.

Uma pode divergir da outra sem problema: comparar contra a branch principal do repositório enquanto se
publica numa branch própria é o caso comum.

## Workspace e worktree são coisas diferentes

A palavra `worktree` aparece **só na tela de Git** — e por um motivo. Uma worktree é um checkout extra do
mesmo repositório, em outra branch e em outra pasta, para que duas frentes não disputem os mesmos
arquivos. É um recurso do próprio Git.

Um **workspace** é uma unidade de trabalho do Elyra: um nome, uma pasta e possivelmente uma máquina.
Criar uma worktree **não** cria um workspace, e a lista de worktrees mostra checkouts que o Elyra não
criou — inclusive os feitos à mão no terminal. Nada é adotado automaticamente: se você quiser trabalhar
naquela pasta como um workspace do app, a escolha é explícita.

## Escopo e limites desta página

- **O Git do projeto pode ser local ou remoto.** Com um projeto em outra máquina, os comandos rodam lá,
  não no seu computador; o painel não decide isso — quem decide é o projeto aberto.
- **Pasta sem repositório não é erro.** O painel oferece iniciar um repositório ou detectar um já
  existente; sem git instalado, ele avisa em vez de fingir uma lista vazia.
- **Leitura desatualizada não vira verdade.** Quando uma releitura falha, o painel marca o estado como
  indisponível em vez de continuar afirmando o último número lido como se fosse atual.
- **Provedores.** As seções de PR e de Issues falam **GitHub e GitLab**. Bitbucket, Azure DevOps e Gitea
  aparecem com a explicação de que não são atendidos — a documentação não promete integração que não
  existe.

## Próximos passos

- [Alterações e diff](/docs/pt-br/fluxos/git-alteracoes-e-diff/)
- [Preparar e criar um commit](/docs/pt-br/fluxos/git-preparar-e-commitar/)
- [Worktrees do repositório](/docs/pt-br/fluxos/git-worktrees/)
