O git pull é ideal para gerenciar e controlar as versões de um arquivo em um projeto de desenvolvimento de forma colaborativa
Git pull é um comando útil para quem trabalha no desenvolvimento de projetos em equipe e precisa estar sempre com a última versão do arquivo. É um atalho que permite verificar os repositórios remotos (git fetch) e gerar um arquivo final atualizado localmente (git merge).
Na prática, o git branch é uma ramificação de código de um projeto usando git.
O VCS registra todas as alterações, revisões e atualizações realizadas a partir de dados como data e identidade do autor, por meio de códigos de letras ou números.
Essas informações permitem controlar as mudanças de um projeto e gerenciar a configuração de software de forma sistematizada.
Quando uma versão precisa de testes, o git pull mescla as alterações e consolida todas as atualizações do projeto no branch atual.
+ Certificado SSL: a segurança do seu site em suas mãos
Como usar o git pull?
O comando git pull serve para recuperar e baixar o conteúdo de um repositório remoto e atualizar o repositório local assim que ele for baixado. Isso é muito útil em fluxos de trabalho de colaboração que precisam mesclar alterações upstream remotas no repositório local.
Como dito, o git pull é uma combinação de dois comandos, git fetch seguido por git merge.
No primeiro estágio, é executado o git fetch, que baixa o conteúdo do repositório remoto necessário.
Em seguida, o comando git merge combina várias sequências de commits em uma única ramificação.
Confira cinco usos do git pull.
1. Integração
O git pull não apenas faz o download de novas alterações do repositório remoto como também os integra diretamente na filial HEAD local. Por padrão, essa integração acontece por meio de um “merge”, mas também pode ser realizada por um “rebase”: $ git pull origin master – rebase.
Se não é necessário integrar novas mudanças diretamente, então pode ser usado o git fetch.
Isso só fará o download de novas mudanças, deixando a ramificação HEAD e os arquivos de cópia de trabalho intocados.
$ git fetch origin
2. Comando simples
Na maioria dos casos, a filial HEAD local já tem uma conexão de rastreamento adequada configurada com uma filial remota.
Essa configuração fornece valores padrão para que o comando pull já saiba de onde extrair sem nenhuma opção adicional.
Isso significa que, se uma conexão de rastreamento foi configurada, a nomeação do repositório pode ser omitida, bem como a ramificação, usando o comando de forma simples: $ git pull.
3. Pull request
Um projeto que recebe diversas colaborações, algumas simultâneas, está mais suscetível a sofrer conflitos.
Por isso, o git tem uma válvula de segurança para garantir a consolidação mais estável das inúmeras contribuições.
O pull request coloca para avaliação um fork, uma ramificação do projeto principal que permite alterações sem modificar o código principal, que passa por uma revisão antes de ser incorporado ao arquivo principal.
Esse comando é realizado por meio da plataforma GitHub, e não direto no terminal. Para tanto, é preciso navegar até o repositório onde o fork foi realizado e clicar em “new pull request”.
O usuário pode escrever um comentário para explicar qual alteração está sendo solicitada e facilitar o trabalho dos revisores.
4. Alteração de pull request
Mesmo após fazer um pull request, a proposta de alteração no branch principal pode ser modificada. Isso permite que o desenvolvedor corrija algum erro ou aperfeiçoe o código antes de a solicitação ser avaliada.
Para tanto, ainda dentro da plataforma GitHub, logo abaixo do nome do repositório, é preciso selecionar “pull requests”.
Após escolher qual branch modificar, deve-se clicar em “edit”.
As alterações podem ser comparadas ao selecionar a branch base no menu suspenso.
Por fim, um alerta aparece para informar que alguns commits antigos poderão ser removidos.
Basta clicar em “change base” e realizar as modificações que desejar, as quais serão incorporadas ao pull request e enviadas para revisão.
5. Revisão de pull request
Após enviado, o pull request fica à disposição dos revisores, que avaliam o arquivo antes da aprovação e incorporação no branch principal, além de deixar comentários individuais e até solicitações de alterações adicionais.
Apenas membros selecionados de uma equipe podem fazer a revisão. Mesmo que o revisor reprove a proposta, um proprietário ou administrador pode aprovar um pull request; isso permite que o trabalho continue, mesmo que um revisor tenha deixado a equipe.
6. Aprovação e mescla de pull request
O revisor pode optar apenas por enviar comentários e recomendações sem, necessariamente, mesclar as alterações com o branch principal.
Dessa maneira, permite que outros revisores, administradores e proprietários possam analisar o pull request antes da aprovação. Em alguns casos, há um número mínimo de revisões antes da mesclagem.
Após realizada, a consolidação da proposta de pull request não pode ser desfeita; por isso, quem aprova e, por consequência, permite a mesclagem, deve analisar todas as revisões.
Se houver vários pull requests, apenas uma proposta poderá ser aprovada de cada vez, para evitar conflitos no arquivo final.
7. Atualização de repositório local
Depois de aprovar as alterações no branch principal, é necessário, mais uma vez, atualizar o repositório local. Isso pode ser realizado direto do terminal, com o comando simples: $ git pull.
Assim, fica garantido que as versões dos arquivos no repositório local serão as mesmas que as hospedadas remotamente.
Está precisando de ajuda para transformar seu negócio? Conheça o SSL LOCAWEB, um certificado https que garante aos visitantes e clientes uma navegação segura.
Clique aqui
