Conventional commits

Conventional commits Conventional commits

Aviso: Este post foi traduzido para o português usando um modelo de tradução automática. Por favor, me avise se encontrar algum erro.

Este post foi criado a partir do vídeo de Carlos Azaustre, só que como ele explica como fazer tudo com ferramentas de JavaScript, há muita gente desenvolvedora de Python que não tem o Node.js instalado, por isso fiz uma versão do mesmo, mas tudo com ferramentas de Python.

O que são os conventional commits?link image 21

A integração com ferramentas de gerenciamento de alterações e releases.

Formato das Mensagens de Commitlink image 22

Um mensagem de commit em Conventional Commits segue um formato específico:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

Vamos vê-lo com mais detalhes

Tipo type

O tipo de commit indica a natureza da mudança. Alguns tipos comuns são:

  • fix: É utilizado para correção de bugs.
  • feat: Utiliza-se para novas funcionalidades.
  • docs: Utiliza-se para alterações na documentação.
  • estilo: Utiliza-se para alterações que não afetam o significado do código (por exemplo, formatação, remoção de espaços em branco).
  • refatorar: É utilizado para alterações no código que nem melhoram nem pioram a funcionalidade, como reorganizar o código.
  • perf: Utiliza-se para mudanças que melhoram o desempenho.
  • teste: Utilizado para adicionar ou atualizar testes.
  • chore: Utilizado para alterações no processo ou nas ferramentas de desenvolvimento.
  • ci: Utiliza-se para alterações nos arquivos de configuração de integração contínua.
  • build: Utilizado para alterações que afetam o sistema de compilação ou dependências externas.
  • revert: É utilizado para reverter um commit anterior.

Âmbito scope

O escopo é opcional e é utilizado para especificar a parte do projeto que foi modificada. Por exemplo, se você está trabalhando em um componente específico de uma aplicação web, o escopo poderia ser o nome do componente.

Exemplo:

fix(auth): corrigir problema de autenticação

Descrição description

A descrição é uma breve explicação da alteração. Deve ser concisa e clara, e fornecer contexto suficiente para entender o propósito do commit.

Exemplo:

fix(auth): corrigir erro de autenticação na página de login

Corpo body

O corpo é opcional e é utilizado para fornecer mais detalhes sobre a mudança. Aqui você pode incluir motivações para a mudança e contraste com a implementação anterior.

Exemplo:

fix(auth): corrigir erro de autenticação na página de login

O token de acesso estava expirando antes do esperado devido a um erro no cálculo da data de expiração. Isso foi corrigido ajustando a lógica de cálculo.

Rodapé footer

O rodapé é opcional e é utilizado para referências adicionais, como números de issues fechadas ou commits relacionados.

Exemplo:

fix(auth): corrigir erro de autenticação na página de login

O token de acesso estava expirando antes do esperado devido a um erro no cálculo da data de expiração. Isso foi corrigido ajustando a lógica de cálculo.
Fecha #123

Benefícios dos Conventional Commitslink image 23

  • Clareza e Consistência: As mensagens de commit padronizadas são mais fáceis de entender e acompanhar, o que melhora a colaboração em equipes de desenvolvimento.
  • Geração Automática de Notas de Versão: Ferramentas podem ser usadas para gerar notas de versão automaticamente com base nas mensagens de commit.
  • Integração com Ferramentas de Gestão de Mudanças: Muitas ferramentas de desenvolvimento e gestão de projetos podem se integrar com Conventional Commits para automatizar tarefas como a geração de changelogs e a gestão de releases.
  • Histórico Estruturado de Alterações: O histórico de alterações torna-se mais estruturado e fácil de navegar, facilitando a revisão de alterações e a depuração de problemas.

Exemplos práticoslink image 24

Exemplo 1: Correção de um Bug

fix(api): corrigir erro na validação do usuário

O ponto de extremidade de registro de usuários estava permitindo registros com endereços de e-mail inválidos. Foi adicionada uma validação adicional para garantir que os endereços de e-mail sejam válidos.

Fecha #456

Exemplo 2: Adicionar um novo recurso

feat(api): adicionar ponto final de recuperação de senha

Implementou um novo endpoint que permite aos usuários solicitar um link de recuperação de senha. O link é enviado para o endereço de e-mail registrado.

Fecha #789

Exemplo 3: Melhoria da documentação

docs: atualizar guia de contribuição

Atualizadas as instruções de configuração para o ambiente de desenvolvimento e adicionada uma seção sobre execução de testes.

Fecha #101

Ferramentas para construir mensagens que atendam aos conventional commitslink image 25

Embora tenhamos visto como criar mensagens de commit através de conventional commits, é bastante possível que cometamos erros, por isso podemos usar ferramentas que nos guiem na criação dessas mensagens. Vamos ver duas: commitizen e o plugin Conventional Commits do vscode.

Commitizenlink image 26

Para usá-la, primeiro vou criar uma pasta nova na qual vou iniciar um repositório do Git.

	
!mkdir ~/comitizen_folder && cd ~/comitizen_folder && git init
Copy
	
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch &lt;name&gt;
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m &lt;name&gt;
Initialized empty Git repository in /home/maximofernandez/comitizen_folder/.git/

Agora eu instalo commitizen

	
%pip install --user -U commitizen
Copy
	
Collecting commitizen
Downloading commitizen-3.29.1-py3-none-any.whl.metadata (7.6 kB)
Collecting argcomplete&lt;3.6,&gt;=1.12.1 (from commitizen)
Downloading argcomplete-3.5.1-py3-none-any.whl.metadata (16 kB)
Requirement already satisfied: charset-normalizer&lt;4,&gt;=2.1.0 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from commitizen) (3.3.2)
Requirement already satisfied: colorama&lt;0.5.0,&gt;=0.4.1 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from commitizen) (0.4.6)
Collecting decli&lt;0.7.0,&gt;=0.6.0 (from commitizen)
Downloading decli-0.6.2-py3-none-any.whl.metadata (17 kB)
Requirement already satisfied: jinja2&gt;=2.10.3 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from commitizen) (3.1.4)
Requirement already satisfied: packaging&gt;=19 in /home/maximofernandez/.local/lib/python3.12/site-packages (from commitizen) (24.1)
Requirement already satisfied: pyyaml&gt;=3.08 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from commitizen) (6.0.2)
Collecting questionary&lt;3.0,&gt;=2.0 (from commitizen)
Downloading questionary-2.0.1-py3-none-any.whl.metadata (5.4 kB)
Collecting termcolor&lt;3,&gt;=1.1 (from commitizen)
Downloading termcolor-2.5.0-py3-none-any.whl.metadata (6.1 kB)
Collecting tomlkit&lt;1.0.0,&gt;=0.5.3 (from commitizen)
Downloading tomlkit-0.13.2-py3-none-any.whl.metadata (2.7 kB)
Requirement already satisfied: MarkupSafe&gt;=2.0 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from jinja2&gt;=2.10.3-&gt;commitizen) (2.1.5)
Collecting prompt_toolkit&lt;=3.0.36,&gt;=2.0 (from questionary&lt;3.0,&gt;=2.0-&gt;commitizen)
Downloading prompt_toolkit-3.0.36-py3-none-any.whl.metadata (7.0 kB)
Requirement already satisfied: wcwidth in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from prompt_toolkit&lt;=3.0.36,&gt;=2.0-&gt;questionary&lt;3.0,&gt;=2.0-&gt;commitizen) (0.2.13)
Downloading commitizen-3.29.1-py3-none-any.whl (71 kB)
Downloading argcomplete-3.5.1-py3-none-any.whl (43 kB)
Downloading decli-0.6.2-py3-none-any.whl (7.9 kB)
Downloading questionary-2.0.1-py3-none-any.whl (34 kB)
Downloading termcolor-2.5.0-py3-none-any.whl (7.8 kB)
Downloading tomlkit-0.13.2-py3-none-any.whl (37 kB)
Downloading prompt_toolkit-3.0.36-py3-none-any.whl (386 kB)
Installing collected packages: tomlkit, termcolor, prompt_toolkit, decli, argcomplete, questionary, commitizen
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
ipython 8.27.0 requires prompt-toolkit&lt;3.1.0,&gt;=3.0.41, but you have prompt-toolkit 3.0.36 which is incompatible.
Successfully installed argcomplete-3.5.1 commitizen-3.29.1 decli-0.6.2 prompt_toolkit-3.0.36 questionary-2.0.1 termcolor-2.5.0 tomlkit-0.13.2
Note: you may need to restart the kernel to use updated packages.

Verificamos a instalação

	
!cz version
Copy
	
3.29.1

Crio um novo arquivo na pasta em que inicializei o repositório do Git e o adiciono à área de staging.

	
!cd ~/comitizen_folder && touch README.md && git add README.md
Copy

Se eu fizer git status verei que o arquivo está na área de staged e que agora devo fazer um commit.

	
!cd ~/comitizen_folder && git status
Copy
	
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached &lt;file&gt;..." to unstage)
new file: README.md

É hora de criar um commit com commitizen. Para isso, executamos cz commit e aparecerá um assistente para criar o commit.

	
!cd ~/comitizen_folder && cz commit
Copy
	
? Select the type of change you are committing docs: Documentation only changes
? What is the scope of this change? (class or file name): (press [enter] to skip)
readme
? Write a short and imperative summary of the code changes: (lower case and no period)
First innit, create readme
? Provide additional contextual information about the code changes: (press [enter] to skip)
This is the first commit, I create a empty readme
? Is this a BREAKING CHANGE? Correlates with MAJOR in SemVer No
? Footer. Information about Breaking Changes and reference issues that this commit closes: (press [enter] to skip)
docs(readme): First innit, create readme
This is the first commit, I create a empty readme
[master (root-commit) 4f646d4] docs(readme): First innit, create readme
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md
Commit successful!

Pronto, já temos nosso primeiro commit criado com commitizen que segue as regras de Conventional Commits

Plugin Conventional Commit do vscodelink image 27

Agora vamos fazer o mesmo com o plugin do VSCode Conventional Commit

Primeiro, é necessário instalar o plugin e, uma vez instalado, pressionamos Ctrl + Shift + P e escrevemos Conventional Commit, pressionamos Enter e aparecerá um assistente para criar o commit.

Para mim o uso deste plugin tem duas vantagens em relação ao commitizen

  • A primeira é que nos permite adicionar emojis de gitmoji. O que, se não abusarmos dos emojis e usarmos apenas alguns, torna mais fácil identificar o tipo de commit ao visualizar o histórico.* A segunda é que ela mantém os escopos scopes que você usou, então novos escopos não são criados, mas sim reutilizados os que já foram usados.

Ferramentas para verificar que se segue a convenção de conventional commitslink image 28

Vimos como criar mensagens de commit que sigam a convenção de conventional commits, mas uma boa prática é criar uma ferramenta para verificar se o commit criado segue a convenção, especialmente quando se trabalha em equipe.

Há ferramentas que nos permitem fazer isso, como pre-commit, mas o que elas fazem é modificar os hooks do git, então vamos fazer nós mesmos e usar commitizen para nos ajudar a validar a mensagem de commit.

Já instalamos commitizen, então vamos ver como podemos usá-lo para verificar uma mensagem de commit.

Primeiro criamos um arquivo chamado commit-msg na pasta .git/hooks e damos permissões de execução. Dentro dos hooks do Git há vários tipos de arquivos que podem ser usados para diferentes tarefas, neste caso vamos usar commit-msg que é executado logo antes da criação do commit.

	
!cd ~/comitizen_folder/.git/hooks && touch commit-msg && chmod +x commit-msg
Copy

Agora adicionamos o seguinte código ao arquivo commit-msg

#!/bin/sh
Este script valida a mensagem do commit usando commitizen

COMMIT_MSG_FILE=$1
cz check --commit-msg-file $COMMIT_MSG_FILE
	
!cd ~/comitizen_folder/.git/hooks && \
echo '#!/bin/sh' &gt; commit-msg && \
echo '# Este script valida el mensaje del commit usando commitizen' &gt;&gt; commit-msg && \
echo ' ' &gt;&gt; commit-msg && \
echo 'COMMIT_MSG_FILE=$1' &gt;&gt; commit-msg && \
echo 'cz check --commit-msg-file $COMMIT_MSG_FILE' &gt;&gt; commit-msg
Copy

Uma vez feito, tentamos fazer um commit com uma mensagem incorreta. Primeiro, modificamos o README e o adicionamos à área de staging.

	
!cd ~/comitizen_folder && echo '.' &gt;&gt; README.md && git add README.md
Copy

Agora fazemos um commit com uma mensagem incorreta

	
!cd ~/comitizen_folder && git commit -m "Add dot to README"
Copy
	
commit validation: failed!
please enter a commit message in the commitizen format.
commit "": "Add dot to README"
pattern: (?s)(build|ci|docs|feat|fix|perf|refactor|style|test|chore|revert|bump)((S+))?!?:( [^ ]+)(( .*)|(s*))?$

Agora fazemos um commit com uma mensagem correta

	
!cd ~/comitizen_folder && git commit -m "docs(readme): :memo: Add dot to README"
Copy
	
Commit validation: successful!
[master d488656] docs(readme): :memo: Add dot to README
1 file changed, 1 insertion(+), 1 deletion(-)

Nos validou o commit corretamente, portanto, se olharmos o histórico de commits, veremos que o commit com a mensagem incorreta não foi criado e o commit com a mensagem correta sim.

	
!cd ~/comitizen_folder && git log
Copy
	
commit d488656297c7cb448a25dd33a008cb5ce1e14e83 (HEAD -&gt; master)
Author: MaximoFN &lt;maximofn@gmail.com&gt;
Date: Tue Oct 8 11:22:19 2024 +0200
docs(readme): :memo: Add dot to README
commit fb518c2b903a259b2e44972e88aabf5656f97be9
Author: MaximoFN &lt;maximofn@gmail.com&gt;
Date: Tue Oct 8 10:57:41 2024 +0200
docs(readme): :memo: Update readme
Update readme with text conventional commits
commit 4f646d45047a45b549243efbfde9e331d45e23f1
Author: MaximoFN &lt;maximofn@gmail.com&gt;
Date: Tue Oct 8 10:48:07 2024 +0200
docs(readme): First innit, create readme
This is the first commit, I create a empty readme

Ferramentas para criar changelogs a partir de conventional commitslink image 29

Como temos os commits escritos seguindo a mesma convenção, podemos criar um changelog automaticamente com git-changelog. Instalamos as dependências

	
%pip install git-changelog
Copy
	
Collecting git-changelog
Downloading git_changelog-2.5.2-py3-none-any.whl.metadata (5.4 kB)
Collecting appdirs&gt;=1.4 (from git-changelog)
Downloading appdirs-1.4.4-py2.py3-none-any.whl.metadata (9.0 kB)
Requirement already satisfied: Jinja2&gt;=2.10 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from git-changelog) (3.1.4)
Requirement already satisfied: packaging&gt;=24.0 in /home/maximofernandez/.local/lib/python3.12/site-packages (from git-changelog) (24.1)
Collecting semver&gt;=2.13 (from git-changelog)
Downloading semver-3.0.2-py3-none-any.whl.metadata (5.0 kB)
Requirement already satisfied: MarkupSafe&gt;=2.0 in /home/maximofernandez/miniforge3/lib/python3.12/site-packages (from Jinja2&gt;=2.10-&gt;git-changelog) (2.1.5)
Downloading git_changelog-2.5.2-py3-none-any.whl (32 kB)
Downloading appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Downloading semver-3.0.2-py3-none-any.whl (17 kB)
Installing collected packages: appdirs, semver, git-changelog
Successfully installed appdirs-1.4.4 git-changelog-2.5.2 semver-3.0.2
Note: you may need to restart the kernel to use updated packages.

Agora podemos criar um changelog com git-changelog. Como criamos alguns commits muito simples, o changelog será muito simples.

	
!cd ~/comitizen_folder && git-changelog
Copy
	
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
&lt;!-- insertion marker --&gt;
## Unreleased
&lt;small&gt;[Compare with latest]()&lt;/small&gt;
&lt;!-- insertion marker --&gt;

Também podemos pedir-lhe que o escreva num arquivo e muitas mais opções

	
!git-changelog -h
Copy
	
usage: git-changelog [--config-file [PATH ...]] [-b] [-B VERSION] [-n SCHEME]
[-h] [-i] [-g REGEX] [-m MARKER] [-o FILE] [-p PROVIDER]
[-r] [-R] [-I FILE] [-c CONVENTION] [-s SECTIONS]
[-t TEMPLATE] [-T] [-E] [-Z] [-F RANGE] [-j KEY=VALUE]
[-V] [--debug-info]
[REPOSITORY]
Automatic Changelog generator using Jinja2 templates.
This tool parses your commit messages to extract useful data
that is then rendered using Jinja2 templates, for example to
a changelog file formatted in Markdown.
Each Git tag will be treated as a version of your project.
Each version contains a set of commits, and will be an entry
in your changelog. Commits in each version will be grouped
by sections, depending on the commit convention you follow.
### Conventions
#### Basic
*Default sections:*
- add: Added
- fix: Fixed
- change: Changed
- remove: Removed
*Additional sections:*
- merge: Merged
- doc: Documented
#### Angular
*Default sections:*
- feat: Features
- fix: Bug Fixes
- revert: Reverts
- ref, refactor: Code Refactoring
- perf: Performance Improvements
*Additional sections:*
- build: Build
- chore: Chore
- ci: Continuous Integration
- deps: Dependencies
- doc, docs: Docs
- style: Style
- test, tests: Tests
#### ConventionalCommit
*Default sections:*
- feat: Features
- fix: Bug Fixes
- revert: Reverts
- ref, refactor: Code Refactoring
- perf: Performance Improvements
*Additional sections:*
- build: Build
- chore: Chore
- ci: Continuous Integration
- deps: Dependencies
- doc, docs: Docs
- style: Style
- test, tests: Tests
positional arguments:
REPOSITORY The repository path, relative or absolute. Default:
current working directory.
options:
--config-file [PATH ...]
Configuration file(s).
-b, --bump-latest Deprecated, use --bump=auto instead. Guess the new
latest version by bumping the previous one based on
the set of unreleased commits. For example, if a
commit contains breaking changes, bump the major
number (or the minor number for 0.x versions). Else if
there are new features, bump the minor number. Else
just bump the patch number. Default: unset (false).
-B VERSION, --bump VERSION
Specify the bump from latest version for the set of
unreleased commits. Can be one of `auto`, `major`,
`minor`, `patch` or a valid SemVer version (eg.
1.2.3). For both SemVer and PEP 440 versioning schemes
(see -n), `auto` will bump the major number if a
commit contains breaking changes (or the minor number
for 0.x versions, see -Z), else the minor number if
there are new features, else the patch number.
Default: unset (false).
-n SCHEME, --versioning SCHEME
Versioning scheme to use when bumping and comparing
versions. The selected scheme will impact the values
accepted by the `--bump` option. Supported: `pep440`,
`semver`. PEP 440 provides the following bump
strategies: `auto`, `epoch`, `release`, `major`,
`minor`, `micro`, `patch`, `pre`, `alpha`, `beta`,
`candidate`, `post`, `dev`. Values `auto`, `major`,
`minor`, `micro` can be suffixed with one of `+alpha`,
`+beta`, `+candidate`, and/or `+dev`. Values `alpha`,
`beta` and `candidate` can be suffixed with `+dev`.
Examples: `auto+alpha`, `major+beta+dev`, `micro+dev`,
`candidate+dev`, etc.. SemVer provides the following
bump strategies: `auto`, `major`, `minor`, `patch`,
`release`. See the docs for more information. Default:
unset (`semver`).
-h, --help Show this help message and exit.
-i, --in-place Insert new entries (versions missing from changelog)
in-place. An output file must be specified. With
custom templates, you can pass two additional
arguments: `--version-regex` and `--marker-line`. When
writing in-place, an `in_place` variable will be
injected in the Jinja context, allowing to adapt the
generated contents (for example to skip changelog
headers or footers). Default: unset (false).
-g REGEX, --version-regex REGEX
A regular expression to match versions in the existing
changelog (used to find the latest release) when
writing in-place. The regular expression must be a
Python regex with a `version` named group. Default:
`^## [(?P&lt;version&gt;v?[^]]+)`.
-m MARKER, --marker-line MARKER
A marker line at which to insert new entries (versions
missing from changelog). If two marker lines are
present in the changelog, the contents between those
two lines will be overwritten (useful to update an
'Unreleased' entry for example). Default: `&lt;!--
insertion marker --&gt;`.
-o FILE, --output FILE
Output to given file. Default: standard output.
-p PROVIDER, --provider PROVIDER
Explicitly specify the repository provider. Default:
unset.
-r, --parse-refs Parse provider-specific references in commit messages
(GitHub/GitLab/Bitbucket issues, PRs, etc.). Default:
unset (false).
-R, --release-notes Output release notes to stdout based on the last entry
in the changelog. Default: unset (false).
-I FILE, --input FILE
Read from given file when creating release notes.
Default: `CHANGELOG.md`.
-c CONVENTION, --convention CONVENTION, --commit-style CONVENTION, --style CONVENTION
The commit convention to match against. Default:
`basic`.
-s SECTIONS, --sections SECTIONS
A comma-separated list of sections to render. See the
available sections for each supported convention in
the description. Default: unset (None).
-t TEMPLATE, --template TEMPLATE
The Jinja2 template to use. Prefix it with `path:` to
specify the path to a Jinja templated file. Default:
`keepachangelog`.
-T, --trailers, --git-trailers
Parse Git trailers in the commit message. See
https://git-scm.com/docs/git-interpret-trailers.
Default: unset (false).
-E, --omit-empty-versions
Omit empty versions from the output. Default: unset
(false).
-Z, --no-zerover By default, breaking changes on a 0.x don't bump the
major version, maintaining it at 0. With this option,
a breaking change will bump a 0.x version to 1.0.
-F RANGE, --filter-commits RANGE
The Git revision-range filter to use (e.g.
`v1.2.0..`). Default: no filter.
-j KEY=VALUE, --jinja-context KEY=VALUE
Pass additional key/value pairs to the template.
Option can be used multiple times. The key/value pairs
are accessible as 'jinja_context' in the template.
-V, --version Show the current version of the program and exit.
--debug-info Print debug information.

Já poderíamos gerar changelogs facilmente a partir dos commits que seguem a convenção de conventional commits. Além disso, podemos adicioná-lo a um pipeline de CI/CD para que seja gerado automaticamente em cada release.

Continuar lendo

MCP: Guia Completa para Criar Servidores e Clientes MCP (Model Context Protocol) com FastMCP

MCP: Guia Completa para Criar Servidores e Clientes MCP (Model Context Protocol) com FastMCP

Aprenda o que é o Model Context Protocol (MCP), o padrão de código aberto desenvolvido pela Anthropic que revoluciona como os modelos de IA interagem com ferramentas externas. Nesta guia prática e detalhada, eu te levo passo a passo na criação de um servidor e cliente MCP do zero usando a biblioteca fastmcp. Você construirá um agente de IA "inteligente" com Claude Sonnet, capaz de interagir com a API do GitHub para consultar issues e informações de repositórios. Vamos cobrir desde conceitos básicos até recursos avançados como filtragem de ferramentas por tags, composição de servidores, recursos estáticos e plantillas dinâmicas (resource templates), geração de prompts e autenticação segura. Descubra como MCP pode padronizar e simplificar a integração de ferramentas em suas aplicações de IA, de forma análoga ao como o USB unificou periféricos!

Últimos posts -->

Você viu esses projetos?

Horeca chatbot

Horeca chatbot Horeca chatbot
Python
LangChain
PostgreSQL
PGVector
React
Kubernetes
Docker
GitHub Actions

Chatbot conversacional para cozinheiros de hotéis e restaurantes. Um cozinheiro, gerente de cozinha ou serviço de quarto de um hotel ou restaurante pode falar com o chatbot para obter informações sobre receitas e menus. Mas também implementa agentes, com os quais pode editar ou criar novas receitas ou menus

Naviground

Naviground Naviground

Subtify

Subtify Subtify
Python
Whisper
Spaces

Gerador de legendas para vídeos no idioma que você desejar. Além disso, coloca uma legenda de cor diferente para cada pessoa

Ver todos os projetos -->

Quer aplicar IA no seu projeto? Entre em contato!

Quer melhorar com essas dicas?

Últimos tips -->

Use isso localmente

Os espaços do Hugging Face nos permitem executar modelos com demos muito simples, mas e se a demo quebrar? Ou se o usuário a deletar? Por isso, criei contêineres docker com alguns espaços interessantes, para poder usá-los localmente, aconteça o que acontecer. Na verdade, se você clicar em qualquer botão de visualização de projeto, ele pode levá-lo a um espaço que não funciona.

Flow edit

Flow edit Flow edit

Edite imagens com este modelo de Flow. Baseado em SD3 ou FLUX, você pode editar qualquer imagem e gerar novas

FLUX.1-RealismLora

FLUX.1-RealismLora FLUX.1-RealismLora
Ver todos os contêineres -->

Quer aplicar IA no seu projeto? Entre em contato!

Você quer treinar seu modelo com esses datasets?

short-jokes-dataset

Dataset com piadas em inglês

opus100

Dataset com traduções de inglês para espanhol

netflix_titles

Dataset com filmes e séries da Netflix

Ver mais datasets -->