Em desenvolvimentoPlataformas
GitFlow Desktop
O GitFlow Desktop (nome provisório) é um aplicativo desktop em Tauri, Rust, React e TypeScript para operar repositórios Git locais sem digitar comandos. Ele mostra o estado do repositório e os diffs, lista, cria e troca branches, cria commits apenas com os arquivos que o usuário selecionou e executa fetch, pull e push mostrando o resultado real do Git. O projeto está em desenvolvimento: as fases 1 a 3 estão implementadas, e ZIP, merge manual, pull requests, autenticação própria e instalador ainda não existem.
O problema
Operações do Git pelo terminal exigem comandos precisos, e um descuido pode incluir arquivos indesejados em um commit ou enviar alterações para o destino errado.
A solução
Uma interface que executa o Git local de forma controlada — sem shell, com argumentos separados e bloqueios explícitos — e só mostra sucesso quando o Git comprova o resultado: o HEAD avançou, o push não teve linhas rejeitadas, o pull alterou o HEAD.
Arquitetura
- 1
React + TypeScript — telas e hooks; services/gitService.ts é a única fronteira com o backend
- 2
Comandos Tauri finos (commands.rs), assíncronos, com permissões mínimas e CSP restritiva
- 3
Crate Rust separado (gitflow-git), sem dependência do Tauri — execução do Git, status, diff, branches, commit e sincronização remota
- 4
Git CLI executado sem shell, com ambiente endurecido, tempo limite, limite de saída e trava de uma operação de escrita por repositório
O que o projeto faz
- Fase 1 (leitura): seleção de pasta, validação do repositório e exibição de branch, estado, arquivos alterados e diffs, com preparados e não preparados em grupos separados
- Fase 2: listagem, criação e troca de branches; a troca é bloqueada com alterações em arquivos rastreados, e o app nunca usa --force, stash, reset ou clean para viabilizá-la
- Commit seletivo: só os arquivos marcados entram (git commit --only, sem add . nem commit -a), com revisão do diff exato e recusa se algo mudou durante a revisão
- Fase 3: diagnóstico de sincronização (sincronizada, adiantada, atrasada ou divergente) calculado com as referências locais, e fetch, pull e push com confirmação do destino exato
- Push sem --force, sem alterar upstream e sem pular hooks; main e master exigem uma segunda confirmação validada também no backend
- Classificação de falhas (autenticação, rede, TLS, push rejeitado, conflito) com detalhes técnicos higienizados; o app não armazena credenciais
Decisões técnicas
Estado atual
Segundo o README, as fases 1 a 3 (leitura, operações locais e sincronização remota) estão implementadas. Ainda não existem importação de ZIP, merge manual, resolução de conflitos, pull requests, autenticação própria nem instalador: hoje o app é iniciado em modo de desenvolvimento pelo iniciar.bat, que instala as dependências no Windows.
Decisões de segurança
A interface nunca envia comandos, só caminhos, que são validados e interpretados literalmente. O Git roda com fsmonitor desativado, sem terminal interativo e com variáveis perigosas removidas. Pull e push recebem o destino que o usuário viu, e o backend recusa a operação se o estado mudou nesse intervalo.
Testes e limitações
O README descreve testes de integração em Rust com Git real em repositórios temporários (incluindo remotos locais) e testes de frontend para a lógica pura; não há testes de componentes React. Falhas reais de autenticação e TLS não são reproduzíveis sem servidor, então a classificação é coberta por testes unitários com saídas reais do Git. As operações de rede não têm progresso percentual nem cancelamento.