Hooks do Git
Hooks do Git são scripts executados com automação toda vez que um evento específico ocorre em um Repositório do Git. Eles deixam você personalizar o comportamento interno do Git e acionar ações personalizáveis em pontos-chave do ciclo de vida do desenvolvimento.
Casos de uso comuns para hooks do Git incluem incentivar uma política de commit, alterar o ambiente do projeto dependendo do estado do repositório e implementar fluxos de trabalho de integração contínua. Mas, como os scripts são personalizáveis ao infinito, você pode usar hooks do Git para automatizar ou otimizar quase todo e qualquer aspecto do fluxo de trabalho de desenvolvimento.
Neste artigo, vamos começar com uma visão geral conceitual de como os hooks do Git funcionam. Em seguida, vamos examinar alguns dos hooks mais populares para uso em repositórios locais e do lado do servidor.
Visão geral conceitual
Todos os hooks do Git são scripts comuns que o Git executa quando certos eventos ocorrem no repositório. Sendo assim, eles são muito fáceis de instalar e configurar.
Os hooks podem estar em repositórios locais ou no lado do servidor e só são executados em resposta a ações nesse repositório. Vamos olhar a fundo as categorias de hooks mais adiante neste artigo. A configuração discutida no restante desta seção se aplica a hooks locais e do lado do servidor.
Instalação de hooks
Os hooks se encontram no .git/hooks diretório de cada Repositório do Git. O Git preenche esse diretório com scripts de exemplo com automação quando você inicializa um repositório. Se você olhar dentro do .git/hooks, você vai encontrar os seguintes arquivos:
applypatch-msg.sample pre-push.sample
commit-msg.sample pre-rebase.sample
post-update.sample prepare-commit-msg.sample
pre-applypatch.sample update.sample
pre-commit.sample
Material relacionado
Como mover um Repositório do Git completo
VER SOLUÇÃO
Aprenda a usar o Git com o Bitbucket Cloud
Eles representam a maioria dos hooks disponíveis, mas a extensão .sample impede que eles sejam executados por padrão. Para “instalar” um hook, tudo o que você precisa fazer é remover a extensão .sample . Ou, se você estiver escrevendo um novo script do zero, você pode somente adicionar um novo arquivo que corresponda a um dos nomes de arquivo acima, menos a extensão .sample .
Por exemplo, tente instalar um hook prepare-commit-msg simples. Remova a extensão .sample desse script e adicione o seguinte ao arquivo:
#!/bin/sh
echo "# Please include a useful commit message!" > $1Os hooks precisam ser executáveis, então você pode precisar alterar as permissões de arquivo do script se estiver criando do zero. Por exemplo, para garantir que prepare-commit-msg seja executável, você precisaria executar o seguinte comando:
chmod +x prepare-commit-msgAgora você deve ver essa mensagem no lugar da mensagem padrão de commit toda vez que executar o git commit. Vamos olhar mais de perto o funcionamento real disso na seção Preparar mensagem de commit. Por enquanto, vamos nos divertir com o fato de que podemos personalizar algumas das funcionalidades internas do Git.
Os scripts de amostra build são referências muito úteis, pois documentam os parâmetros que são passados para cada hook (eles variam de um hook para outro).
Linguagens de script
Os scripts internos são, em sua maioria, scripts shell e PERL, mas você pode usar qualquer linguagem de script que quiser, desde que ela possa ser executada como executável. A linha shebang (#! /bin/sh) em cada script define como o arquivo deve ser interpretado. Então, para usar uma linguagem diferente, tudo o que você precisa fazer é fazer uma alteração nela para o caminho do intérprete.
Por exemplo, podemos escrever um script Python executável no arquivo prepare-commit-msg em vez de usar comandos shell. O hook a seguir vai fazer a mesma coisa que o script shell na seção anterior.
#!/usr/bin/env python
import sys, os
commit_msg_filepath = sys.argv[1]
with open(commit_msg_filepath, 'w') as f:
f.write("# Please include a useful commit message!")Observe como a primeira linha foi alterada para apontar para o interpretador Python. E, em vez de usar $1 para acessar o primeiro argumento passado para o script, usamos sys.argv[1] (de novo, mais sobre esse assunto em breve).
Esse é uma característica muito poderosa para hooks do Git porque permite que você trabalhe em qualquer linguagem que seja mais confortável para você.
Escopo dos hooks
Os hooks são locais para qualquer Repositório do Git e não são copiados para o novo repositório quando você executa o git clone. E, como os hooks são locais, eles podem ser alterados por qualquer pessoa com acesso ao repositório.
Esse escopo tem um impacto importante ao configurar hooks para uma equipe de desenvolvedores. Primeiro, você precisa encontrar uma maneira de garantir que os hooks permaneçam atualizados entre os membros da sua equipe. Segundo, você não pode forçar os desenvolvedores a criar commits com uma certa aparência — você só pode incentivar essa atitude.
Manter hooks para uma equipe de desenvolvedores pode ser um pouco complicado porque o diretório .git/hooks não é clonado com o resto do projeto, nem está sob controle de versão. Uma solução simples para esses dois problemas é armazenar os hooks no diretório real do projeto (acima do diretório .git ). Assim você pode editá-los como qualquer outro arquivo controlado por versão. Para instalar o hook, você pode criar um link simbólico para ele em .git/hooks, ou você pode somente copiar e colar no .git/hooks sempre que o hook for atualizado.
Como alternativa, o Git também oferece um mecanismo de diretório de templates que facilita a instalação automática de hooks. Todos os arquivos e diretórios contidos neste diretório de templates são copiados para o diretório .git toda vez que você usa git init ou git clone.
Todos os hooks locais descritos abaixo podem ser alterados — ou desinstalados por inteiro — pelo proprietário de um repositório. Depende apenas de cada membro da equipe se eles usam um hook de verdade. Com essas informações em mente, é melhor pensar nos hooks do Git como uma ferramenta de desenvolvedor conveniente, em vez de uma política de desenvolvimento aplicada com rigidez.
Também é possível rejeitar commits que não estejam em conformidade com algum padrão usando hooks do lado do servidor. Vamos falar mais sobre esse artigo adiante neste artigo.
Ganchos locais
Os hooks locais afetam somente o repositório onde estão. Ao ler esta seção, não esqueça que cada desenvolvedor pode alterar os próprios hooks locais, então você não pode usar estes como uma forma de impor uma política de commit. No entanto, eles podem tornar muito mais fácil para os desenvolvedores seguirem determinadas diretrizes. Nesta seção, vamos explorar 6 dos hooks locais mais úteis:
pre-commitprepare-commit-msgcommit-msgpost-commitpost-checkoutpre-rebase
Os 4 primeiros hooks permitem que você se conecte a todo o ciclo de vida do commit, e os 2 finais permitem que você execute algumas ações extras ou verificações de segurança para os comandos git checkout e git rebase, respectivamente.
Todos os hooks pre- permitem que você altere a ação que está prestes a acontecer, enquanto os hooks post- são usados apenas para notificações.
Também vamos ver algumas técnicas úteis para analisar argumentos de hook e solicitar informações sobre o repositório usando comandos Git de nível inferior.
Pre-commit
O script de pre-commit é executado toda vez que você executa o git commit antes que o Git solicite ao desenvolvedor uma mensagem de commit ou gere um objeto de commit. Você pode usar esse hook para inspecionar o instantâneo que está prestes a passar por commit. Por exemplo, você pode querer executar alguns testes automatizados que garantem que o commit não quebre nenhuma funcionalidade existente.
Nenhum argumento é passado para o script de pre-commit, e sair com um status diferente de zero aborta todo o commit. Vamos dar uma olhada em uma versão simplificada (e mais detalhada) do hook de pre-commit integrado. Este script aborta o commit se encontrar algum erro de espaço em branco, conforme definido pelo comando git diff-index (espaço em branco à direita, linhas com apenas espaço em branco e um espaço seguido por uma tabulação dentro do recuo inicial de uma linha são considerados erros por padrão).
#!/bin/sh
# Check if this is the initial commit
if git rev-parse --verify HEAD >/dev/null 2>&1
then
echo "pre-commit: About to create a new commit..."
against=HEAD
else
echo "pre-commit: About to create the first commit..."
against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi
# Use git diff-index to check for whitespace errors
echo "pre-commit: Testing for whitespace errors..."
if ! git diff-index --check --cached $against
then
echo "pre-commit: Aborting commit due to whitespace errors"
exit 1
else
echo "pre-commit: No whitespace errors :)"
exit 0
fiPara usar o git diff-index, precisamos descobrir com qual referência de commit estamos comparando o índice. No geral, ela é HEAD; no entanto, HEAD não existe ao criar o commit inicial, então a primeira tarefa é levar em conta esse caso extremo. Usamos o git rev-parse --verify, que apenas verifica se o argumento (HEAD) é ou não uma referência válida. A porção >/dev/null 2>& 1 silencia qualquer saída do git rev-parse. O HEAD ou um objeto de commit vazio é armazenado na variável against para uso com git diff-index. O hash 4b825d... é uma ID de commit mágica que representa um commit vazia.
O comando git diff-index --cached compara um commit com o índice. Ao passar a opção --check, estamos pedindo por um aviso caso as mudanças introduzam erros de espaço em branco. Se for esse o caso, abortamos o commit retornando um status de saída de 1, caso contrário, saímos com 0, e o fluxo de trabalho do commit continua sem problemas.
Este é apenas um exemplo do hook de pre-commit. Acontece que ele usa comandos Git existentes para executar testes nas alterações introduzidas pelo commit proposto, mas você pode fazer o que quiser no pre-commit, incluindo executar outros scripts, executar um conjunto de testes de terceiros ou verificar o estilo do código com o Lint.
Preparar mensagem de commit
O hook prepare-commit-msg é chamado após o hook de pre-commit para preencher o editor de texto com uma mensagem de commit. Esse é um bom lugar para alterar as mensagens de commit geradas com automação para commits com squash ou merge.
Um a três argumentos são passados para o script prepare-commit-msg:
1. O nome de um arquivo temporário que contém a mensagem. Você altera a mensagem de commit alterando esse arquivo no local.
2. O tipo de commit. Pode ser message (opção -m ou -F), template (opção -t), merge (se for um commit de merge) ou squash (caso combine outros commits por squash).
3. O hash SHA1 do commit relevante. Oferecido apenas se a opção -c, -C, ou --amend for dada.
Assim como na pre-commit, sair com um status diferente de zero aborta o commit.
Já vimos um exemplo simples que editou a mensagem de commit, mas vamos dar uma olhada em um script mais útil. Ao usar um rastreador de itens, uma convenção comum é abordar cada item em um branch separado. Se você incluir o número do item no nome do branch, vai poder escrever um hook prepare-commit-msg para incluí-lo com automação em cada mensagem de commit nesse branch.
#!/usr/bin/env python
import sys, os, re
from subprocess import check_output
# Collect the parameters
commit_msg_filepath = sys.argv[1]
if len(sys.argv) > 2:
commit_type = sys.argv[2]
else:
commit_type = ''
if len(sys.argv) > 3:
commit_hash = sys.argv[3]
else:
commit_hash = ''
print "prepare-commit-msg: File: %s\nType: %s\nHash: %s" % (commit_msg_filepath, commit_type, commit_hash)
# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()
print "prepare-commit-msg: On branch '%s'" % branch
# Populate the commit message with the issue #, if there is one
if branch.startswith('issue-'):
print "prepare-commit-msg: Oh hey, it's an issue branch."
result = re.match('issue-(.*)', branch)
issue_number = result.group(1)
with open(commit_msg_filepath, 'r+') as f:
content = f.read()
f.seek(0, 0)
f.write("ISSUE-%s %s" % (issue_number, content))Primeiro, o hook prepare-commit-msg acima mostra como coletar todos os parâmetros que são passados para o script. Em seguida, ele chama git symbolic-ref --short HEAD para obter o nome do branch que corresponde a HEAD. Se o nome do branch começar com issue-, ele vai reescrever o conteúdo do arquivo de mensagem de commit para incluir o número do item na primeira linha. Portanto, se o nome do branch for issue-224, a mensagem de commit a seguir vai ser gerada.
ISSUE-224
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch issue-224
# Changes to be committed:
# modified: test.txtAlgo para se ter em mente ao usar prepare-commit-msg é que ele é executado mesmo quando o usuário passa uma mensagem com a opção -m do git commit. Ou seja: o script acima vai inserir com automação a string ISSUE-[#] sem permitir que o usuário a edite. Você pode lidar com esse caso vendo se o segundo parâmetro (commit_type) é igual a message.
No entanto, sem a opção -m, o hook prepare-commit-msg permite que o usuário edite a mensagem após ela ser gerada, então essa opção é, na verdade, mais um script de conveniência do que uma maneira de impor uma política de mensagem de commit. Para conseguir esse resultado, você precisa do hook commit-msg discutido na próxima seção.
Mensagem de commit
O hook commit-msg é muito parecido com o hook prepare-commit-msg, mas é chamado depois do usuário inserir uma mensagem de commit. Esse é um local apropriado para avisar os desenvolvedores de que a mensagem deles não está de acordo com os padrões da sua equipe.
O único argumento passado para esse hook é o nome do arquivo que contém a mensagem. Se não gostar da mensagem que o usuário inseriu, ele pode alterar esse arquivo no local (assim como com prepare-commit-msg) ou pode abortar o commit inteiro saindo com um status diferente de zero.
Por exemplo, o script a seguir verifica se o usuário não excluiu a string ISSUE-[#] que foi gerada com automação pelo hook prepare-commit-msg na seção anterior.
#!/usr/bin/env python
import sys, os, re
from subprocess import check_output
# Collect the parameters
commit_msg_filepath = sys.argv[1]
# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()
print "commit-msg: On branch '%s'" % branch
# Check the commit message if we're on an issue branch
if branch.startswith('issue-'):
print "commit-msg: Oh hey, it's an issue branch."
result = re.match('issue-(.*)', branch)
issue_number = result.group(1)
required_message = "ISSUE-%s" % issue_number
with open(commit_msg_filepath, 'r') as f:
content = f.read()
if not content.startswith(required_message):
print "commit-msg: ERROR! The commit message must start with '%s'" % required_message
sys.exit(1)Embora esse script seja chamado toda vez que o usuário cria um commit, você deve evitar fazer muito além de verificar a mensagem de commit. Se você precisar notificar outros serviços de que um instantâneo passou por commit, use o hook post-commit.
Post-commit
O hook post-commit é chamado logo após o hook da mensagem de commit. Ele não pode alterar o resultado da operação git commit, então ele é usado, na maioria dos casos, para fins de notificação.
O script não usa parâmetros e o status de saída não afeta o commit mesmo. Para a maioria dos scripts post-commit, você vai querer acessar o commit que acabou de ser criado. Você pode usar git rev-parse HEAD para obter o hash SHA1 do novo commit, ou você pode usar git log -1 HEAD para obter tudo.
Por exemplo, se você quiser enviar um e-mail para seu chefe toda vez que fizer o commit de um instantâneo (é provável não ser a melhor ideia para a maioria dos fluxos de trabalho), você pode adicionar o seguinte hook post-commit.
#!/usr/bin/env python
import smtplib
from email.mime.text import MIMEText
from subprocess import check_output
# Get the git log --stat entry of the new commit
log = check_output(['git', 'log', '-1', '--stat', 'HEAD'])
# Create a plaintext email message
msg = MIMEText("Look, I'm actually doing some work:\n\n%s" % log)
msg['Subject'] = 'Git post-commit hook notification'
msg['From'] = 'mary@example.com'
msg['To'] = 'boss@example.com'
# Send the message
SMTP_SERVER = 'smtp.example.com'
SMTP_PORT = 587
session = smtplib.SMTP(SMTP_SERVER, SMTP_PORT)
session.ehlo()
session.starttls()
session.ehlo()
session.login(msg['From'], 'secretPassword')
session.sendmail(msg['From'], msg['To'], msg.as_string())
session.quit()É possível usar o post-commit para acionar um sistema de integração contínua local, mas na maioria das vezes você vai querer que seja no hook post-receive. Ele é executado no servidor em vez de na máquina local do usuário e também é executado toda vez que qualquer desenvolvedor envia o código. Assim, ele é um local muito mais apropriado para realizar a integração contínua.
Post-checkout
O hook post-checkout tem um funcionamento muito parecido com o do hook post-commit, mas é chamado sempre que você verifica com sucesso uma referência com o git checkout. Ele é bom para limpar o diretório de trabalho dos arquivos gerados que, de outra forma, causariam confusão.
Esse hook aceita três parâmetros e o status de saída não afeta o comando git checkout.
1. O ref do HEAD anterior
2. O ref do novo HEAD
3. Uma marcação informando se foi um checkout de ramificação ou um checkout de arquivo. A marcação vai ser 1 e 0, respectivamente.
Um problema comum com desenvolvedores Python ocorre quando os arquivos .pyc gerados ficam por aí depois de trocar de branch. O intérprete às vezes usa esses .pyc em vez do arquivo de origem .py . Para evitar qualquer confusão, você pode excluir todos os arquivos .pyc sempre que você fizer checkout de um novo branch usando o seguinte script post-checkout:
#!/usr/bin/env python
import sys, os, re
from subprocess import check_output
# Collect the parameters
previous_head = sys.argv[1]
new_head = sys.argv[2]
is_branch_checkout = sys.argv[3]
if is_branch_checkout == "0":
print "post-checkout: This is a file checkout. Nothing to do."
sys.exit(0)
print "post-checkout: Deleting all '.pyc' files in working directory"
for root, dirs, files in os.walk('.'):
for filename in files:
ext = os.path.splitext(filename)[1]
if ext == '.pyc':
os.unlink(os.path.join(root, filename))O diretório de trabalho atual para scripts de hook é sempre definido como a raiz do repositório, então a chamada os.walk('.') itera em todos os arquivos no repositório. Em seguida, verificamos a extensão e excluímos ela se for o arquivo .pyc .
Você também pode usar o hook post-checkout para alterar o diretório de trabalho de acordo com em qual branch você fez checkout. Por exemplo, você pode usar um branch de plugins para armazenar todos os plug-ins fora da base de código principal. Se esses plugins exigirem muitos binários que outros branches não exigem, você pode fazer uma compilação seletiva deles apenas quando estiver no branch de plugins.
Pre-rebase
O hook pre-rebase é chamado antes que o git rebase altere qualquer coisa, tornando ele um bom lugar para garantir que algo terrível não esteja prestes a acontecer.
Esse hook usa 2 parâmetros: o branch upstream do qual a série foi bifurcada e o branch passando por rebase. O segundo parâmetro fica vazio ao fazer o rebase do branch atual. Para abortar o rebase, saia com um status diferente de zero.
Por exemplo, se você quiser proibir por completo o rebase no repositório, você pode usar o seguinte script de pre-rebase:
#!/bin/sh
# Disallow all rebasing
echo "pre-rebase: Rebasing is dangerous. Don't do it."
exit 1Agora, toda vez que você executar o git rebase, você vai ver esta mensagem:
pre-rebase: Rebasing is dangerous. Don't do it.
The pre-rebase hook refused to rebase.Para um exemplo mais aprofundado, dê uma olhada no script pre-rebase.sample incluído. Esse script é um pouco mais inteligente sobre quando não permitir o rebase. Ele verifica se o branch do tópico de que você está tentando fazer o rebase já passou por merge para o branch next (que é considerado o branch da linha principal). Se tiver, é provável que você tenha problemas ao fazer o rebase, então o script aborta o rebase.
Ganchos do servidor
Os hooks do lado do servidor funcionam com exatidão como os locais, exceto que residem em repositórios do lado do servidor (por exemplo, um repositório central ou um repositório público do desenvolvedor). Quando anexados ao repositório oficial, alguns deles podem servir como uma forma de impor a política rejeitando certos commits.
Existem 3 hooks do lado do servidor que vamos discutir no restante deste artigo:
pre-receiveAtualizarpost-receive
Todos esses hooks permitem que você reaja a diferentes estágios do processo git push.
A saída dos hooks do lado do servidor é feita em pipes para o console do cliente, então é muito fácil enviar mensagens de volta para o desenvolvedor. Mas você também deve lembrar que esses scripts não retornam o controle do terminal até que eles terminem a execução, portanto, você deve ter cuidado ao executar operações de longa duração.
Pre-receive
O hook pre-receive é executado toda vez que alguém usa o git push para enviar commits para o repositório. Ele sempre deve residir no repositório remote que é o destino do push, não no repositório de origem.
O hook é executado antes que qualquer referência seja atualizada, então é um bom lugar para aplicar qualquer tipo de política de desenvolvimento que você queira. Se você não gosta de quem está fazendo o push, como a mensagem de commit está sendo formatada ou as alterações contidas no commit, você pode apenas rejeitá-la. Embora você não possa impedir que os desenvolvedores façam commits malformados, você pode impedir que esses commits entrem na base de código oficial rejeitando esses commits com pre-receive.
O script não usa parâmetros, mas cada referência que está sendo enviada é passada para o script em uma linha separada na entrada padrão no seguinte formato:
<old-value> <new-value> <ref-name>Você pode ver como esse hook funciona usando um script de pre-receive muito básico que lê, com simplicidade, as referências enviadas e as imprime.
#!/usr/bin/env python
import sys
import fileinput
# Read in each ref that the user is trying to update
for line in fileinput.input():
print "pre-receive: Trying to push ref: %s" % line
# Abort the push
# sys.exit(1)De novo, é um pouco diferente dos outros hooks porque as informações são passadas para o script via entrada padrão em vez de como argumentos de linha de comando. Depois de colocar o script acima no diretório .git/hooks de um repositório remoto e enviar o branch main, você vai ver algo parecido com o seguinte no console:
b6b36c697eb2d24302f89aa22d9170dfe609855b 85baa88c22b52ddd24d71f05db31f4e46d579095 refs/heads/mainVocê pode usar esses hashes SHA1, junto com alguns comandos Git de nível inferior, para verificar as alterações que vão ser introduzidas. Alguns casos de usos comuns são:
- Rejeitar alterações que envolvem um rebase upstream
- Evitar merges de avanço não rápido
- Verificar se o usuário tem as permissões corretas para fazer as alterações pretendidas (usado, na maioria dos casos, para fluxos de trabalho centralizados do Git)
Se várias referências forem enviadas, retornar um status diferente de zero do pre-receive vai abortar todas elas. Se você quiser aceitar ou rejeitar branches caso a caso, vai ser necessário usar o hook de update.
Atualização
O hook de update é chamado após o pre-receive e funciona da mesma maneira. Ele ainda é chamado antes que qualquer coisa seja atualizada de verdade, mas é chamado em separado para cada referência que foi enviada. Ou seja: se o usuário tentar enviar 4 branches, update vai ser executado 4 vezes. Ao contrário do pre-receive, esse hook não precisa ler a partir da entrada padrão. Em vez disso, ele aceita os 3 argumentos a seguir:
1. O nome da referência que está sendo atualizada
2. O nome do objeto antigo armazenado na referência
3. O novo nome de objeto armazenado na referência
Essas são as mesmas informações passadas para o pre-receive, mas como o update é trazido em separado para cada referência, você pode rejeitar algumas referências enquanto permite outras.
#!/usr/bin/env python
import sys
branch = sys.argv[1]
old_commit = sys.argv[2]
new_commit = sys.argv[3]
print "Moving '%s' from %s to %s" % (branch, old_commit, new_commit)
# Abort pushing only this branch
# sys.exit(1)O hook de update acima simplesmente gera o branch e os hashes de commit antigos/novos. Ao enviar mais de um branch para o repositório remoto, você vai ver a instrução print ser executada para cada branch.
Post-receive
O hook post-receive é chamado após uma operação de envio bem-sucedida, tornando-o um bom lugar para realizar notificações. Para muitos fluxos de trabalho, esse é um lugar melhor para acionar notificações do que a post-commit, porque as alterações estão disponíveis em um servidor público em vez de estar apenas na máquina local do usuário. Enviar e-mail para outros desenvolvedores e acionar um sistema de integração contínua são casos de uso comuns para post-receive.
O script não usa parâmetros, mas recebe as mesmas informações que o pre-receive via entrada padrão.
Resumo
Neste artigo, aprendemos como os hooks do Git podem ser usados para alterar o comportamento interno e receber notificações quando determinados eventos ocorrem em um repositório. Hooks são scripts comuns que estão no repositório .git/hooks, o que os torna muito fáceis de instalar e personalizar.
Também analisamos alguns dos hooks locais e do lado do servidor mais comuns. Assim é possível ter uma conexão com todo o ciclo de vida do desenvolvimento. Agora sabemos como realizar ações personalizáveis em cada estágio do processo de criação do commit, bem como o processo git push. Assim você pode fazer quase qualquer coisa que você possa imaginar com um repositório do Git com um pouco de conhecimento de script.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Blog do Bitbucket
Caminho de aprendizagem de DevOps
