# Implantando código

Valide as verificações de pré-implantação, escolha estratégias de mesclagem e gerencie as ramificações com eficiência ao fazer a implantação do código.

A etapa final de um pull request é integrar o trabalho concluído à ramificação de implantação. Isso geralmente significa mesclar suas alterações na ramificação de release ou na ramificação principal. Antes que isso aconteça, você precisará confirmar se a alteração atende aos requisitos do projeto.

## Validando as verificações de pré-implantação

Antes de mesclar, você confirmará que a alteração é segura para implantar.
**As verificações de status** mostram se as confirmações atendem às condições definidas para o repositório, como builds de integração contínua, testes, verificação de código ou verificações de implantação. Eles ajudam você e os revisores a entender se uma solicitação de pull está pronta para mesclar.

Os repositórios geralmente exigem determinadas condições antes que uma solicitação de pull possa se mesclar, incluindo:

* Verificações de status obrigatórias que devem ser aprovadas, como verificações de integridade e prontidão do aplicativo executadas pelo seu pipeline de implantação.
* Revisões obrigatórias ou aprovações do proprietário do código.
* Conflitos de mesclagem devem ser resolvidos.

As ramificações protegidas impõem esses requisitos para que as ramificações de implantação permaneçam estáveis.

Nem todas as verificações são iguais. Verificações avançadas criadas por produtos como GitHub Actions podem gerar logs e anotações detalhadas, enquanto status de commit mais simples podem ser publicados por diversos sistemas conectados. Entender isso ajuda você a interpretar por que uma solicitação de pull está ou não pronta.

## Mesclar o código na ramificação de release ou na ramificação principal.

Quando os requisitos forem atendidos, você mescla o pull request para incorporar seus commits à ramificação base. Você também pode automatizar a mesclagem para que uma solicitação de pull seja mesclada assim que seus requisitos forem atendidos. Pull requests oferecem diferentes estratégias de mesclagem, dependendo de como você deseja que o histórico do repositório fique:

* ```
            **Mesclar commit** preserva todos os commits da ramificação do pull request e adiciona um ponto de mesclagem explícito.
  ```
* **Squash and merge** combina todos os commits em um único commit para manter um histórico conciso.
* ```
            **Rebase e mesclagem** adiciona cada commit à ramificação base para um histórico linear sem um commit de mesclagem.
  ```

A melhor estratégia depende de quantos detalhes sua equipe deseja preservar.

## Impor requisitos em escala

À medida que a mesclagem fica mais movimentada, as equipes adicionam controles para manter as mesclagens seguras e previsíveis:

* ```
            **Conjuntos de regras e proteções de ramificação** podem exigir uma ramificação atualizada, commits assinados, histórico linear ou verificações de status específicas antes da mesclagem. 
  ```
* Uma **fila de mesclagem** permite que uma ramificação protegida com alto tráfego aceite muitas solicitações de pull sem quebrar. Ela testa cada uma em relação à versão mais recente da ramificação base e as mescla em ordem assim que as verificações forem aprovadas. Quando um branch usa uma fila de mesclagem, as opções de mesclagem disponíveis diferem de uma mesclagem padrão.

> \[!NOTE]
>
> As filas de merge de pull requests estão disponíveis em qualquer repositório pertencente à organização no GitHub Enterprise Server.

## Vinculando mesclagens à implantação

A mesclagem geralmente é o gatilho que inicia a distribuição do código.               GitHub Actions pode executar fluxos de trabalho de implantação quando uma pull request é mesclada em uma ramificação de lançamento ou principal.
**Os ambientes de implantação** adicionam outra camada de segurança de pré-implantação: você pode exigir revisores específicos, temporizadores de espera ou restrições de ramificação antes que uma implantação prossiga e elas sejam exibidas junto com suas outras verificações.

## Recuperando após uma mesclagem

Mesmo com as verificações em vigor, algumas mesclagens precisam ser desfeitas. Você pode reverter uma solicitação de pull mesclada para criar uma nova solicitação de pull que reverta as alterações. Esteja ciente de que uma pull request pode ser marcada como mesclada *indiretamente* em raras ocasiões, se seus commits alcançarem a ramificação base por outro caminho. Isso pode ignorar as proteções nessa solicitação de pull específica. Confira [Reverter uma pull request](/pt/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/reverting-a-pull-request) e [Fusão de Pull Requests](/pt/enterprise-server@3.18/pull-requests/reference/pull-request-merges#indirect-merges).

## Fechando solicitações de pull que não serão mescladas

Nem todas as solicitações de pull devem se mesclar. Se uma alteração não for mais necessária ou for substituída por outro trabalho, você poderá fechar a solicitação de pull sem mesclá-la. Encerrar mantém a discussão e o histórico para referência, ao mesmo tempo que sinaliza que a mudança não seguirá adiante.

Depois que uma solicitação de pull é mesclada ou fechada, sua ramificação principal geralmente não é mais necessária. Excluir ramificações não utilizadas mantém o repositório mais fácil de navegar.

## Leitura adicional

* [Mesclar uma solicitação de pull](/pt/enterprise-server@3.18/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request)
* [Status checks](/pt/enterprise-server@3.18/pull-requests/reference/status-checks)
* [Gerenciar ambientes para implantação](/pt/enterprise-server@3.18/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)