Versionamento Power BI
com Git & GitHub
Um padrão corporativo para versionar projetos .pbip, TMDL e relatórios Power BI usando GitHub Web, GitHub Desktop, VS Code e linha de comando — com fluxos para iniciantes e intermediários.
1 Conceitos fundamentais
Antes de começar é importante entender o vocabulário básico. Estes termos aparecem em toda a interface do Git, do GitHub Desktop, do VS Code e do GitHub Web.
Repositório
Pasta do projeto com histórico completo de versões. Pode ficar local (no PC) e remoto (no GitHub).
Commit
Um marco salvo no histórico. Como uma "foto" da pasta naquele momento, com mensagem explicando o que mudou.
Branch
Linha de trabalho isolada. Permite testar sem afetar a versão principal (main).
Push
Envia commits do PC para o GitHub. Sem push, ninguém vê suas mudanças.
Pull
Baixa do GitHub para o PC. Sempre faça pull antes de começar a trabalhar.
Pull Request (PR)
Pedido formal para fundir uma branch na main, com revisão por outra pessoa.
Commit salva localmente. Push envia para o GitHub. Quem só faz commit e esquece o push fica com tudo trancado no PC.
2 Arquitetura: Power BI + Git + Service
Cada ferramenta tem um papel diferente. O GitHub não publica no Power BI Service automaticamente — ele apenas versiona o projeto.
flowchart LR
A[👤 Você] -->|edita .pbip| B[💻 Power BI Desktop]
B -->|salva| C[📁 Pasta local]
C -->|commit + push| D[(☁️ GitHub)]
D -->|pull| C
C -->|publish| E[📊 Power BI Service]
E -->|consome| F[👥 Usuários finais]
D -.->|CI/CD opcional| E
style A fill:#6366f1,color:#fff
style D fill:#1f2328,color:#fff
style E fill:#F2C811,color:#000
Fluxo conceitual: Git versiona código; Service entrega o relatório.
| Ferramenta | Papel |
|---|---|
| Power BI Desktop | Desenvolver relatório e modelo (cria .pbip) |
| Git + GitHub | Versionar código, branches, commits, pull requests |
| GitHub Desktop | Interface visual do Git (perfil iniciante) |
| VS Code | Editor com Git embutido + revisão de TMDL/JSON |
| Power BI Service | Publicar, agendar atualização, distribuir |
| Gateway | Conectar Service a fontes de dados locais |
3 Instalar as ferramentas
Para o perfil Iniciante você precisa apenas de duas ferramentas:
GitHub Desktop
Baixe em desktop.github.com e instale com sua conta GitHub.
Power BI Desktop
Baixe na Microsoft Store ou em powerbi.microsoft.com e habilite o formato Power BI Project (.pbip) em Arquivo › Opções › Visualizações.
Para o perfil Intermediário, instale o stack profissional completo. O VS Code é a ferramenta central — combina edição de TMDL/JSON, Git visual (Source Control) e terminal integrado.
Git for Windows
Instale em git-scm.com. Inclui Git Bash e integração com PowerShell.
powershell# verificar instalação git --version # saída esperada: git version 2.45.xConfigurar identidade Git (uma vez só)
bashgit config --global user.name "Seu Nome" git config --global user.email "voce@empresa.com" git config --global init.defaultBranch main git config --global core.autocrlf true git config --global pull.rebase false # para Windows: prefere editor padrão do VS Code git config --global core.editor "code --wait"VS Code + extensões
Baixe em code.visualstudio.com. Extensões essenciais para o stack PBI + Git:
Extensão Para que serve GitLens Mostra blame, autoria e histórico inline em cada linha Git Graph Visualiza o gráfico de commits e branches em árvore Git History Histórico amigável de arquivos individuais TMDL (powerbi-tools) Syntax highlight para arquivos de modelo semântico Power BI Studio Suporte ampliado a PBIP/PBIR Better TOML / YAML Para arquivos de configuração e CI/CD powershell# instalar extensões via terminal (após VS Code estar no PATH) code --install-extension eamodio.gitlens code --install-extension mhutchie.git-graph code --install-extension donjayamanne.githistoryAutenticação no GitHub
Duas opções (escolha uma):
- Personal Access Token (PAT) — recomendado para começar. Gere em github.com → Settings → Developer settings → Personal access tokens. Cole quando o Git pedir senha.
- SSH Key — mais profissional. Gere com
ssh-keygen -t ed25519 -C "voce@empresa.com"e adicione a chave pública em github.com → Settings → SSH keys.
Power BI Desktop com PBIP habilitado
Arquivo › Opções › Visualizações › Power BI Project (.pbip). Reinicie o Power BI após habilitar.
Ctrl + Shift + G→ abre o painel Controle do Código-FonteCtrl + `→ abre o terminal integrado (PowerShell/Bash)Ctrl + Enter(no painel SCM) → confirma o commitCtrl + Shift + P→ paleta de comandos (digite Git: para ver tudo)
4 Criar o repositório
Acesse github.com
Faça login e clique no botão verde New repository no canto superior direito.
Preencha os campos
- Repository name:
relatorio-vendas-powerbi(sem espaços, kebab-case) - Description: breve descrição do relatório
- Visibility: ✅ Private
- Initialize: ✅ Add a README file
- .gitignore template: deixe em branco (vamos criar um customizado)
- Repository name:
Clique em Create repository
Pronto. Agora seu repositório existe na nuvem com a branch
mainjá criada.
5 Clonar o repositório
No GitHub Desktop
File › Clone repository…
Aba GitHub.com
Selecione o repositório recém-criado da lista.
Local path
Escolha a pasta do PC. Sugestão:
C:\Projetos\PowerBI\Clone
Pronto — uma cópia local foi criada e já está conectada ao GitHub.
Mockup da tela do GitHub Desktop após clonar e adicionar arquivos.
Via terminal (PowerShell ou Bash)
git clone https://github.com/empresa/relatorio-vendas-powerbi.git
cd relatorio-vendas-powerbi
git statusVia VS Code
- Pressione
Ctrl+Shift+Pe digite Git: Clone - Cole a URL HTTPS do repositório
- Escolha a pasta local
- Aceite "Open repository"
6 GitHub Desktop a fundo
Para o perfil Iniciante, o GitHub Desktop é a ferramenta principal. Ele esconde a complexidade do Git por trás de botões claros, permitindo que você commite, troque de branch e faça push sem decorar comandos. Toda a documentação oficial está em docs.github.com/pt/desktop.
O que é o GitHub Desktop
É um aplicativo gratuito da Microsoft/GitHub que conecta o seu PC ao GitHub. Funciona como um tradutor visual: você clica em botões e ele executa comandos Git por baixo. Ideal para quem trabalha com Power BI Project (.pbip), arquivos TMDL, README e quer evitar terminal.
Visual e clicável
Vê o que mudou em cada arquivo, marca o que vai entrar no commit, escreve a mensagem e clica para enviar.
Histórico cronológico
Aba History mostra cada commit em ordem, quem fez, quando e o que mudou linha por linha.
Branches sem dor
Criar e trocar de branch é um clique. O Git Desktop pergunta o que fazer com mudanças não commitadas.
Push/Pull com 1 clique
Botão grande no topo. Indica setas para cima/baixo dizendo se você está atrás ou à frente do remoto.
Anatomia da janela
A interface tem três grandes áreas:
- Barra de topo com três botões:
Current repository(qual projeto),Current branch(qual ramo),Push origin / Pull origin / Fetch origin(sincronizar) - Painel esquerdo com duas abas:
Changes(alterações ainda não commitadas) eHistory(commits já feitos) - Painel direito mostra o diff do arquivo selecionado, lado a lado ou inline
GitHub Desktop com 5 alterações em uma branch de trabalho.
Os botões mais importantes (e quando clicar)
| Botão | Em inglês | O que faz | Quando usar |
|---|---|---|---|
| 📁 Repositório atual | Current repository | Lista todos os repos clonados, troca entre eles | Trabalho em vários projetos PBI |
| 🌿 Branch atual | Current branch | Lista branches; permite criar/trocar | Sempre antes de começar trabalho novo |
| ⬆️ Enviar | Push origin | Manda commits do PC para o GitHub | Ao terminar de trabalhar |
| ⬇️ Baixar | Pull origin | Baixa atualizações do GitHub | Antes de começar (pega trabalho dos colegas) |
| 🔄 Consultar | Fetch origin | Verifica se há novidades sem aplicar | Para ver se vale fazer pull |
| 📤 Publicar branch | Publish branch | Cria a branch nova no GitHub remoto | Primeira vez que envia uma branch |
| 📜 Histórico | History | Lista cronológica de commits | Ver o que já foi feito; reverter |
| 📝 Alterações | Changes | Arquivos modificados ainda não commitados | Antes de cada commit |
Fluxo do dia a dia (visual)
flowchart LR
A[🌅 Início do dia] --> B[Fetch origin]
B --> C{Há mudanças
no remoto?}
C -->|sim| D[Pull origin]
C -->|não| E[Current branch]
D --> E
E --> F[Trabalhar no
Power BI Desktop]
F --> G[Aba Changes
revisa diffs]
G --> H[Mensagem
do commit]
H --> I[Commit to branch]
I --> J[Push origin]
J --> K[🌙 Fim do dia]
style A fill:#0052B4,color:#fff
style K fill:#1a7f37,color:#fff
style I fill:#4DA3FF,color:#fff
style J fill:#D52B1E,color:#fff
Trocando de branch com mudanças abertas
Esta é uma das situações mais comuns. Você está editando em uma branch e precisa trocar para outra. O GitHub Desktop pergunta:
🟦 Leave my changes on main
Deixar as alterações na branch atual. Use quando você não quer levar esse trabalho para a outra branch — vai voltar nele depois.
🟥 Bring my changes to nova-branch
Levar as alterações junto. Use quando você quer continuar o mesmo trabalho na nova branch (ex.: você criou na branch errada e quer mudar).
Indicadores no botão Push/Pull
Os números ao lado do botão dizem onde você está:
↑ 3= você tem 3 commits locais que ainda não foram enviados (faça Push)↓ 2= há 2 commits no GitHub que você ainda não baixou (faça Pull)↑ 3 ↓ 2= histórico divergiu — Pull primeiro, resolva conflito se houver, depois Push- Sem números = está tudo sincronizado
Recursos oficiais (links docs.github.com)
| Tópico | Link |
|---|---|
| Sobre o GitHub Desktop | docs.github.com/pt/desktop/overview |
| Instalar e autenticar | installing-github-desktop |
| Adicionar repositório | cloning-a-repository |
| Trabalhar com branches | managing-branches |
| Fazer commits | committing-and-reviewing |
| Push e Pull | pushing-changes-to-github |
| Reverter um commit | reverting-a-commit |
| Atalhos de teclado | keyboard-shortcuts |
Atalhos de teclado úteis (Windows)
Repositórios e branches
Ctrl + TTrocar de repositórioCtrl + BTrocar de branchCtrl + Shift + NNova branchCtrl + NNovo repositórioCommits e sincronização
Ctrl + EnterConfirmar commitCtrl + PPush originCtrl + Shift + PPull originF5Atualizar (refresh)Navegação
Ctrl + 1Aba ChangesCtrl + 2Aba HistoryCtrl + Shift + AMostrar mudanças no ExplorerCtrl + Shift + GMostrar no GitHub.pbip rapidamente.6 VS Code — IDE para o fluxo intermediário
O VS Code combina três coisas que você precisa no dia a dia: editor de código (TMDL, JSON, README), controle de código-fonte visual (Source Control / SCM) e terminal integrado (PowerShell ou Bash). Você pode usar tudo por GUI, tudo por terminal, ou misturar.
Anatomia do painel Controle do Código-Fonte
Abra com Ctrl + Shift + G. É o ícone com duas bolinhas e uma linha (3º na barra de atividades).
Painel Controle do Código-Fonte do VS Code com 7 alterações em um projeto PBIP.
Os dois caminhos: GUI vs Terminal
No VS Code você pode fazer a mesma operação de duas formas. Use o que for mais rápido em cada momento.
Source Control (GUI)
- Salve os arquivos no Power BI Desktop
- Volte para o VS Code, abra
Ctrl + Shift + G - Veja a lista de Alterações com cada arquivo marcado
M(modified),U(untracked) ouD(deleted) - Clique no + ao lado de cada arquivo para fazer stage (ou no + do cabeçalho para todos)
- Digite a mensagem do commit no campo do topo
- Clique em Confirmação (ou
Ctrl + Enter) - Clique no botão ··· → Push (ou na nuvem na barra de status)
Terminal integrado
Abra com Ctrl + `. Mesma operação:
Significado de cada letra ao lado do arquivo
| Letra | Significado | O que isso quer dizer |
|---|---|---|
| M | Modified | Arquivo já existia e foi alterado |
| U | Untracked | Arquivo novo, ainda não está sendo versionado |
| A | Added (staged) | Arquivo novo já no stage, pronto para commit |
| D | Deleted | Arquivo foi apagado |
| R | Renamed | Arquivo foi renomeado |
| ! | Conflict | Conflito de merge — resolver antes de commitar |
Ações rápidas no painel Source Control
| Ícone | Ação | Quando usar |
|---|---|---|
| ✓ | Commit (Confirmação) | Cria o commit com a mensagem digitada |
| ↻ | Refresh | Reler estado dos arquivos do disco |
| + | Stage all | Marca todos os arquivos para o próximo commit |
| − | Unstage | Remove o arquivo do stage |
| ↺ | Discard | Descarta as alterações (cuidado, não tem volta!) |
| ··· | More actions | Push, Pull, Fetch, Sync, Stash, Branch, Checkout to… |
Painel Gráfico (Git Graph)
Logo abaixo das alterações, com a extensão Git Graph instalada, você vê a árvore de commits. Cada bolinha colorida é um commit; as etiquetas mostram em qual branch cada commit está. Clique com botão direito sobre um commit para reverter, criar branch ou fazer cherry-pick.
Ctrl + Shift + P) e digite Git: — você vê todas as operações Git disponíveis (mais de 60). Ex.: Git: Checkout to…, Git: Stash, Git: Cherry Pick…, Git: Fetch, Git: Rebase Branch…Workflow recomendado no VS Code (passo a passo)
Abrir a pasta do projeto
Ctrl + K, Ctrl + Oou Arquivo → Abrir Pasta. Selecione a raiz do repositório clonado.Atualizar antes de começar
No painel SCM, clique em ··· → Pull (ou no terminal:
git pull).Criar branch de trabalho
Clique no nome da branch na barra de status (canto inferior esquerdo) → Create new branch… → digite
feature/dashboard-vendas.# equivalente no terminal PS > git checkout -b feature/dashboard-vendasTrabalhar no Power BI Desktop
Abra o
.pbip, faça as alterações, salve. Os arquivos.tmdle.jsonserão atualizados em disco.Revisar o diff no VS Code
Volte para o VS Code. Clique em cada arquivo modificado no painel SCM — abre o diff lado a lado com a versão anterior. Confira que não está commitando lixo (cache, bookmarks).
Commit + Push
Mensagem no padrão (
feat: …) →Ctrl + Enter→ clique no ícone de nuvem para fazer push.Abrir Pull Request
Clique no link que aparece como notificação, ou abra o GitHub Web manualmente. (Com a extensão GitHub Pull Requests, dá pra abrir o PR sem sair do VS Code.)
Configurações do VS Code recomendadas para PBI
Adicione no .vscode/settings.json do projeto (ou nas configurações globais):
{
"git.autofetch": true,
"git.confirmSync": false,
"git.enableSmartCommit": true,
"git.postCommitCommand": "push",
"git.suggestSmartCommit": false,
"scm.defaultViewMode": "tree",
"diffEditor.ignoreTrimWhitespace": false,
"files.eol": "\n",
"files.exclude": {
"**/*.pbix": true,
"**/cache.abf": true,
"**/localSettings.json": true
}
}7 .gitignore para Power BI
.gitignore deve estar pronto antes do primeiro commit. Se você commitar arquivos errados (como .pbix ou cache), eles entram no histórico e dão trabalho para remover depois.O que deve ser versionado
| Arquivo | O que é |
|---|---|
*.pbip | Arquivo de projeto Power BI (texto) |
**/definition/**/*.tmdl | Modelo semântico em TMDL |
**/definition/**/*.json | Metadados do projeto |
*.pbir | Definição do relatório |
*.pbism | Definição do modelo semântico |
README.md | Documentação |
.gitignore | Este próprio arquivo |
O que NÃO deve ser versionado
Crie o arquivo .gitignore na raiz do projeto com este conteúdo:
# ============================================
# .gitignore — Power BI Project (PBIP/TMDL)
# ============================================
# Power BI - não versionar PBIX no repo principal
*.pbix
# Configurações locais / cache
**/localSettings.json
**/.pbi/localSettings.json
**/*.abf
**/cache.abf
**/*.tmp
**/*.temp
# Bookmarks e artefatos de sessão
**/*.bookmark.json
**/*bookmark*.json
# Arquivos de sistema
.DS_Store
Thumbs.db
desktop.ini
# Ambiente de desenvolvimento
.vscode/settings.json
.env
*.log
# Backups locais
backup/
_bkp/
*.bakAdicionar ao .gitignore depois não remove o arquivo do histórico. Use:
git rm --cached caminho/do/arquivo.pbix
git commit -m "chore: remove pbix do versionamento"
git push8 Primeiro commit
O primeiro commit é especial: ele nasce na main e contém apenas a estrutura limpa do projeto. Depois disso, todo trabalho do dia a dia acontece em branches.
gitGraph
commit id: "init: README"
commit id: "chore: estrutura inicial"
branch feature/dashboard-vendas
checkout feature/dashboard-vendas
commit id: "feat: cria página"
commit id: "feat: medidas DAX"
checkout main
merge feature/dashboard-vendas
branch fix/relacionamento
commit id: "fix: produto x venda"
checkout main
merge fix/relacionamento
Linha do tempo: primeiro commit na main, depois sempre branches.
Checklist antes do primeiro commit
- ✅ Salvou o projeto no formato
.pbip - ✅ Criou o
.gitignorecom o template acima - ✅ Conferiu que não há
.pbix,cache.abf,localSettings.jsonna lista de mudanças - ✅ A mensagem do commit segue o padrão
Mensagem recomendada
chore: estrutura inicial do projeto Power BIComo fazer no GitHub Desktop
Aba Changes
Confira os arquivos listados. Marque o checkbox apenas dos que devem entrar.
Escreva a mensagem
No campo de baixo:
chore: estrutura inicial do projeto Power BICommit to main
Clique no botão verde.
Push origin
Obrigatório — clique no botão no topo. Sem isso, nada vai para o GitHub.
Via terminal
# 1. Conferir o que vai entrar
git status
# 2. Adicionar tudo o que não está no .gitignore
git add .
# 3. Criar o commit
git commit -m "chore: estrutura inicial do projeto Power BI"
# 4. Enviar para o GitHub
git push9 Branches
Depois do primeiro commit, nunca trabalhe direto na main. Crie uma branch para cada assunto.
Quando criar uma branch nova
| Tipo | Quando usar | Exemplo |
|---|---|---|
| feature/ | Nova funcionalidade, página, medida | feature/dashboard-vendas |
| fix/ | Correção de bug, cálculo, relacionamento | fix/calculo-margem-bruta |
| chore/ | Ajuste técnico, gitignore, organização | chore/ajuste-gitignore |
| docs/ | Documentação, README | docs/atualiza-readme |
| refactor/ | Reorganização sem mudar regra | refactor/medidas-receita |
| hotfix/ | Correção urgente em produção | hotfix/erro-publicacao |
Criar branch no GitHub Desktop
Clique em Current branch
No topo da janela, clique no nome da branch atual (geralmente
main).New branch
Botão azul no fundo do menu.
Digite o nome
Ex:
feature/dashboard-vendas— use/para separar tipo e descrição.Create branch
Pronto, você já está nela. Faça suas alterações no Power BI e volte para commitar.
Publish branch
Após o primeiro commit, clique em Publish branch para enviar a branch ao GitHub.
O GitHub Desktop pergunta:
- Leave my changes on main = deixar as mudanças na branch atual
- Bring my changes to nova-branch = levar as mudanças para a nova branch
Use a primeira se você não quer levar esse trabalho. Use a segunda se quer continuar na nova branch.
Comandos PowerShell e Bash
Criar e mudar para nova branch
git checkout -b feature/dashboard-vendasListar branches locais
git branchListar todas (incluindo remotas)
git branch -aTrocar de branch
git checkout mainPrimeiro push da branch
git push -u origin feature/dashboard-vendasRenomear branch atual
git branch -m novo-nomeDeletar branch local
git branch -d feature/antigaDeletar branch remota
git push origin --delete feature/antigaSequência completa em uma branch nova
# 1. Atualizar a main
git checkout main
git pull
# 2. Criar branch nova a partir da main atualizada
git checkout -b feature/dashboard-vendas
# 3. (editar arquivos no Power BI Desktop, salvar)
# 4. Commit + push
git add .
git commit -m "feat: cria página de análise de vendas"
git push -u origin feature/dashboard-vendas10 Commits — padrão profissional
Formato
tipo: descrição objetiva no imperativoTipos disponíveis
Nova funcionalidade
feat: adiciona página de vendas
Correção de erro
fix: corrige cálculo de margem
Documentação
docs: atualiza README
Ajuste técnico
chore: ajusta gitignore
Reorganizar sem mudar regra
refactor: reorganiza medidas DAX
Ajuste visual/layout
style: ajusta cores do painel
Exemplos prontos para copiar
| Situação | Mensagem de commit |
|---|---|
| Criou nova página | feat: adiciona página de análise de vendas |
| Criou medida nova | feat: cria medida de faturamento mensal |
| Adicionou coluna calculada | feat: adiciona coluna de status do pedido |
| Adicionou segmentação | feat: adiciona segmentação por ano e mês |
| Corrigiu relacionamento | fix: corrige relacionamento entre produto e venda |
| Corrigiu DAX | fix: ajusta cálculo de margem bruta |
| Corrigiu filtro | fix: corrige filtro de data no relatório |
| Atualizou README | docs: revisa README do projeto |
| Adicionou gitignore | chore: adiciona gitignore para arquivos Power BI |
| Reorganizou pastas | chore: reorganiza estrutura de pastas |
| Reorganizou medidas | refactor: reorganiza medidas de receita |
| Ajuste de cores | style: corrige cores do painel |
- Um commit = um objetivo
- Descrição em minúsculas, no imperativo (adiciona, não adicionei)
- Tamanho ideal: até 72 caracteres na primeira linha
- Se a branch é
feature/X, comece os commits comfeat:
11 Push, Pull e Fetch
| Comando | O que faz | Quando usar |
|---|---|---|
git push | Envia commits locais → GitHub | Após cada commit que você quer publicar |
git pull | Baixa mudanças → integra na branch local | Antes de começar a trabalhar |
git fetch | Verifica se há novidades sem aplicar | Quando quer só conferir antes de baixar |
12 Pull Request & Merge
O Pull Request (PR) é o pedido formal para fundir uma branch de trabalho na main. Em equipes, ele permite revisão e discussão antes da junção.
Faça push da sua branch
No GitHub Desktop: Push origin. No terminal:
git push -u origin feature/...Abra o GitHub Web
Vá ao seu repositório. Aparece uma faixa amarela: Compare & pull request.
Preencha o PR
- Título: mesmo padrão do commit (
feat: adiciona dashboard de vendas) - Descrição: contexto do que mudou + screenshots se possível
- Reviewers: marque colega(s) que revisarão
- Título: mesmo padrão do commit (
Aguarde aprovação
Ajuste o que for sugerido com novos commits na mesma branch.
Merge pull request
Após aprovação, clique no botão verde. Use Squash and merge para histórico limpo.
Delete branch
O GitHub oferece deletar a branch após o merge. Aceite — mantém o repo organizado.
13 Rollback & recuperação de erros
Errou algo? Calma — o Git tem várias formas de voltar atrás. A escolha depende de onde está o erro.
🟢 Commit ainda local
Não fez push? Use Undo commit ou git reset. É seguro porque só afeta seu PC.
🟡 Commit já publicado
Já fez push? Use Revert. Cria um novo commit que desfaz o anterior, sem alterar o histórico.
🔴 Voltar a um ponto antigo
Use Reset to commit com cuidado — pode apagar commits posteriores. Em equipe, evite.
No GitHub Desktop
Vá em History, clique com botão direito no commit:
| Opção | O que faz | Quando usar |
|---|---|---|
| Undo commit… | Desfaz commit local; arquivos voltam para Changes | Acabou de commitar e percebeu erro, ainda não fez push |
| Revert changes in commit | Cria novo commit que desfaz o anterior | Commit já está no GitHub |
| Reset to commit… | Move a branch para um commit antigo | Casos avançados, individual; evite em equipe |
| Checkout commit | Inspeciona commit antigo sem mudar branch | Quero só ver como estava |
| Amend commit… | Edita o último commit (mensagem ou arquivos) | Errei a mensagem do último commit |
| Create branch from commit | Cria nova branch a partir de um ponto antigo | Quero recuperar um estado anterior em outra linha |
Regra prática
- Commit local com erro → Undo commit…
- Commit publicado errado → Revert changes in commit
- Quero voltar para um ponto antigo → Create branch from commit
Comandos de rollback
Reverter o último commit (já publicado)
git revert HEAD
git pushReverter um commit específico
git log --oneline # pegue o hash
git revert <hash>
git pushDesfazer último commit local sem perder mudanças
git reset --soft HEAD~1Desfazer último commit local apagando mudanças
git reset --hard HEAD~1Recuperar estado antigo em uma branch nova (seguro)
git checkout -b baseline-recuperado <hash>Reset com força no remoto (perigoso, só uso pessoal)
git reset --hard <hash>
git push --force--force em branches compartilhadas. Você pode apagar trabalho de outros sem aviso. Em equipe, sempre prefira git revert.14 Conflitos de merge
Acontecem quando duas pessoas (ou você em duas branches) editam a mesma linha do mesmo arquivo. O Git não sabe qual versão manter e pede que você decida.
.tmdl e report.json. Para reduzir, mantenha branches curtas e faça pull da main com frequência.Anatomia de um conflito
Quando há conflito, o Git insere marcações no arquivo:
// dentro de um arquivo .tmdl ou .json
<<<<<<< HEAD
medida = SUM(Vendas[Valor])
=======
medida = SUMX(Vendas, Vendas[Valor] * Vendas[Quantidade])
>>>>>>> feature/nova-medidaVocê precisa:
- Abrir o arquivo
- Decidir qual versão manter (ou combinar as duas)
- Apagar as marcações
<<<,===,>>> - Salvar
- Commitar a resolução
Comandos úteis
# Ver arquivos com conflito
git status
# Após resolver manualmente, marcar como resolvido
git add caminho/arquivo
git commit -m "fix: resolve conflito de merge na medida"
# Abortar o merge e voltar ao estado anterior
git merge --abort15 Mensagens de erro frequentes
| Mensagem | Causa | Solução |
|---|---|---|
fatal: not a git repository | Você está fora da pasta do repo | cd para a pasta correta |
nothing to commit, working tree clean | Nada mudou desde o último commit | Edite alguma coisa antes de commitar |
Your branch is ahead of 'origin/main' by N commits | Tem commits locais que não foram enviados | git push |
error: failed to push some refs | Tem coisa nova no remoto que você não tem | git pull primeiro, resolva conflitos, depois git push |
Updates were rejected because the tip of your branch is behind | Mesmo do anterior | git pull --rebase e depois git push |
Please commit your changes or stash them before you switch branches | Tentou trocar de branch com mudanças não commitadas | Commitar primeiro, ou git stash |
Permission denied (publickey) | SSH não configurado | Use HTTPS ou configure SSH (ssh-keygen + adicionar ao GitHub) |
Authentication failed | Senha/token inválido | Gere um Personal Access Token no GitHub e use como senha |
16 Publicação no Power BI Service
push no GitHub não publica o relatório para os usuários. A publicação é uma etapa separada no Power BI Desktop.Fluxo manual recomendado
Garanta que está na
mainatualizadaO PR foi mergeado e a versão está aprovada.
Abra o
.pbipno Power BI DesktopConfira que o relatório abre sem erro.
Clique em Publicar
Botão na faixa superior. Escolha o Workspace destino.
Configure no Service
- Credenciais da fonte de dados
- Gateway (se a fonte é local)
- Agendamento de atualização
- Permissões de acesso
Valide com um usuário final
Peça para alguém abrir o relatório e confirmar que tudo funciona.
Quando publicar?
Não publique a cada commit. Publique apenas quando:
- A alteração foi revisada
- O PR foi mergeado na
main - O relatório abre corretamente
- O responsável aprovou
17 Automação CI/CD (avançado)
Para times maduros com workspaces DEV/HML/PRD, vale automatizar a publicação. Três caminhos:
1. Fabric Git Integration
Conecta um workspace do Fabric diretamente a uma branch. Sincronização nativa, sem código.
2. fabric-cicd (Python)
Biblioteca oficial Microsoft para deploy de PBIP via GitHub Actions ou Azure DevOps.
3. Power BI REST API
Para automação totalmente customizada com Service Principal.
flowchart LR
A[Commit + Push] --> B[Pull Request]
B --> C{Review}
C -->|aprovado| D[Merge na main]
D --> E[GitHub Actions]
E --> F[fabric-cicd]
F --> G[Workspace DEV]
G --> H[Workspace HML]
H --> I[Workspace PRD]
style A fill:#6366f1,color:#fff
style I fill:#1a7f37,color:#fff
18 Nomenclaturas — padrão do projeto
Repositórios
Use kebab-case (palavras em minúsculas separadas por hífen):
- ✅
relatorio-vendas-powerbi - ✅
painel-financeiro-2026 - ❌
Relatório Vendas(espaços, maiúsculas, acentos)
Branches
Padrão: tipo/descricao-curta
feature/dashboard-vendas
feature/medidas-faturamento
fix/correcao-relacionamento-produto
fix/ajuste-calculo-margem
hotfix/erro-publicacao-producao
chore/ajuste-gitignore-powerbi
docs/atualiza-readme-projeto
refactor/medidas-receitaCommits
Padrão: tipo: descrição objetiva
feat: adiciona página de análise de vendas
fix: corrige relacionamento entre produto e venda
chore: adiciona gitignore para arquivos Power BI
docs: atualiza instruções de publicação no service
refactor: reorganiza medidas de receita
style: ajusta layout da página executivoBoas práticas gerais
- Sem espaços, acentos ou caracteres especiais em nomes técnicos
- Hífen (
-) para separar palavras, nunca_ - Tudo em minúsculas
- Nome curto (até 50 caracteres) e descritivo
19 Glossário inglês ↔ português
| Inglês | Português | Explicação |
|---|---|---|
| Repository | Repositório | Local onde o projeto fica salvo |
| Main | Principal | Branch oficial e estável |
| Branch | Ramificação | Linha de trabalho separada |
| Commit | Registro de alteração | Ponto salvo no histórico |
| Push | Enviar | Manda commits locais para o GitHub |
| Pull | Baixar atualização | Traz mudanças do GitHub |
| Fetch | Consultar atualizações | Verifica sem aplicar |
| Clone | Clonar | Baixar repo conectado ao GitHub |
| Pull Request | Solicitação de revisão | Pedido de merge com revisão |
| Merge | Mesclar | Juntar duas branches |
| Stage / Staged | Preparado | Arquivos selecionados para o commit |
| Unstage | Despreparar | Tirar do commit antes de confirmar |
| Publish branch | Publicar branch | Criar branch no remoto |
| Workspace | Espaço de trabalho | Área no Power BI Service |
| Publish | Publicar | Enviar relatório para o Service |
| Semantic Model | Modelo semântico | Modelo de dados do relatório |
| Report | Relatório | Camada visual |
| PBIP | Projeto Power BI | Formato versionável (pasta) |
| PBIX | Arquivo Power BI | Binário tradicional (não versionar) |
| TMDL | Tabular Model Definition Language | Formato textual do modelo semântico |
| Hash / SHA | Identificador do commit | Código único de cada commit |
| HEAD | Cabeça | Aponta para o commit atual |
| Origin | Origem | Apelido padrão do repo remoto |
| Conflict | Conflito | Mesma linha alterada em branches diferentes |
| Stash | Esconderijo | Guarda mudanças temporariamente |
20 Templates README para Power BI
Template Iniciante
# Nome do Projeto Power BI
## O que este projeto faz
Breve descrição (1-2 frases) do que o relatório mostra.
## Como abrir
1. Abrir o arquivo `Projeto.pbip` no Power BI Desktop
2. Aguardar o carregamento do modelo
3. Atualizar dados se necessário
## Como contribuir
1. Criar uma branch: `feature/sua-mudanca`
2. Fazer alterações e salvar
3. Commit: `feat: descrição da mudança`
4. Push da branch
5. Abrir Pull Request
## Regras importantes
- Não versionar `.pbix`
- Sempre fazer push depois do commit
- Usar branch para mudanças grandes
## Responsável
Nome: [Seu nome]
E-mail: [seu@email.com]Template Intermediário
# Nome do Projeto Power BI
## Objetivo
Descreva o objetivo de negócio do relatório e o público-alvo.
## Stack
- Power BI Desktop (PBIP habilitado)
- TMDL para modelo semântico
- Git + GitHub para versionamento
- VS Code com extensões GitLens, Git Graph, Power BI TMDL
- Power BI Service (workspace: `nome-do-workspace`)
## Estrutura do projeto
```
Projeto/
├── Projeto.pbip
├── Projeto.Report/
│ └── definition/
├── Projeto.SemanticModel/
│ └── definition/
├── README.md
└── .gitignore
```
## Fluxo de trabalho
1. `git checkout main && git pull`
2. `git checkout -b feature/sua-mudanca`
3. Editar no Power BI Desktop e salvar
4. `git add . && git commit -m "feat: descrição"`
5. `git push -u origin feature/sua-mudanca`
6. Abrir Pull Request, aguardar review
7. Merge na main após aprovação
8. Publicar manualmente no Power BI Service (versão aprovada)
## Convenção de commits
| Tipo | Uso |
|---|---|
| feat | Nova funcionalidade |
| fix | Correção |
| refactor | Reorganização |
| docs | Documentação |
| chore | Ajuste técnico |
## Workspaces
- DEV: `workspace-dev-relatorio`
- HML: `workspace-hml-relatorio`
- PRD: `workspace-prd-relatorio`
## Fontes de dados
- SQL Server: `servidor.empresa.local`
- Gateway: `Gateway-Corporativo-01`
## Responsável técnico
Nome: [Seu nome]
E-mail: [seu@email.com]
Data da última revisão: AAAA-MM-DD21 Cheatsheet final
GitHub Desktop — onde clicar
📁 Trocar repositório
🌿 Trocar branch
➕ Nova branch
💾 Fazer commit
⬆️ Push
⬇️ Pull
↩️ Desfazer último commit
🔄 Reverter publicado
Comandos essenciais — terminal
📥 Iniciar trabalho do dia
git checkout maingit pullgit checkout -b feature/X💾 Commit + push
git statusgit add .git commit -m "feat: ..."git push -u origin feature/X🔍 Inspecionar histórico
git log --oneline --graph -10git diff HEAD~1git show <hash>↩️ Rollback
git revert HEADgit reset --soft HEAD~1git checkout -b backup <hash>🧹 Limpar / arquivar
git stashgit stash popgit rm --cached arquivo🌿 Branches
git branch -agit branch -d antigagit push origin --delete antiga