6.3 GitHub - Mantendo um Projeto

Alguém chega, faz uma alteração no seu código e lhe envia um Pull Request. Você deve receber um e-mail notificando-o sobre o novo Pull Request e ele deve se parecer com Notificação por e-mail de um novo Pull Request.

Existem algumas coisas a serem notadas sobre este e-mail. Ele lhe dará um pequeno diffstat — uma lista de arquivos que foram alterados no Pull Request e em que quantidade. Ele lhe dá um link para o Pull Request no GitHub. Ele também lhe dá algumas URLs que você pode usar a partir da linha de comando.

Se você notar a linha que diz git pull <url> patch-1, esta é uma forma simples de mesclar (merge) um branch remoto sem ter que adicionar um remoto. Nós analisamos isso rapidamente em Fazendo Checkout de Branches Remotos. Se desejar, você pode criar e mudar para um branch de tópico e, em seguida, executar este comando para mesclar as alterações do Pull Request.

As outras URLs interessantes são as URLs .diff e .patch, que, como você pode adivinhar, fornecem versões diff unificadas e patch do Pull Request. Você poderia tecnicamente mesclar o trabalho do Pull Request com algo como isto:

Como abordamos em O Fluxo do GitHub (GitHub Flow), agora você pode ter uma conversa com a pessoa que abriu o Pull Request. Você pode comentar em linhas de código específicas, comentar em commits inteiros ou comentar no Pull Request inteiro em si, usando o GitHub Flavored Markdown em toda parte.

Toda vez que alguém comenta no Pull Request, você continuará a receber notificações por e-mail, para saber que há atividade acontecendo. Cada um deles terá um link para o Pull Request onde a atividade está acontecendo e você também pode responder diretamente ao e-mail para comentar na thread do Pull Request.

Uma vez que o código esteja de uma forma que você goste e queira mesclá-lo, você pode fazer o pull do código e mesclá-lo localmente, seja com a sintaxe git pull <url> <branch> que vimos anteriormente, ou adicionando o fork como um remoto e fazendo fetch e merge.

Se o merge for trivial, você também pode simplesmente clicar no botão “Merge” no site do GitHub. Isso fará um merge “non-fast-forward”, criando um commit de merge mesmo que um merge fast-forward fosse possível. Isso significa que, aconteça o que acontecer, toda vez que você clica no botão de merge, um commit de merge é criado. Como você pode ver em Botão Merge e instruções para fazer o merge de um Pull Request manualmente, o GitHub lhe dá todas essas informações se você clicar no link de dica.

Se você decidir que não quer mesclá-lo, você também pode simplesmente fechar o Pull Request e a pessoa que o abriu será notificada.

Se você estiver lidando com um monte de Pull Requests e não quiser adicionar um monte de remotos ou fazer pulls pontuais toda vez, há um truque bacana que o GitHub permite que você faça. Este é um truque um pouco avançado e vamos analisar os detalhes disso um pouco mais em Refspec, mas ele pode ser bastante útil.

Na verdade, o GitHub anuncia (advertises) os branches de Pull Request de um repositório como uma espécie de pseudo-branches no servidor. Por padrão, você não os obtém quando clona, mas eles estão lá de forma obscura e você pode acessá-los com bastante facilidade.

Para demonstrar isso, usaremos um comando de baixo nível (frequentemente referido como um comando de “plumbing” ou encanamento, sobre o qual leremos mais em Encanamento e Porcelana (Plumbing and Porcelain)) chamado ls-remote. Esse comando geralmente não é usado em operações do dia a dia no Git, mas é útil para nos mostrar quais referências estão presentes no servidor.

Se executarmos esse comando no repositório “blink” que estávamos usando antes, obteremos uma lista de todos os branches, tags e outras referências no repositório.

É claro, se você estiver em seu repositório e executar git ls-remote origin ou qualquer remoto que deseje verificar, ele mostrará algo semelhante a isso.

Se o repositório estiver no GitHub e você tiver Pull Requests abertos, você obterá essas referências prefixadas com refs/pull/. Estas são basicamente branches, mas como elas não estão sob refs/heads/, você normalmente não as obtém ao clonar ou fazer fetch do servidor — o processo de fetch normalmente as ignora.

Existem duas referências por Pull Request - a que termina em /head aponta exatamente para o mesmo commit que o último commit no branch do Pull Request. Então, se alguém abrir um Pull Request no nosso repositório e seu branch for nomeado bug-fix apontando para o commit a5a775, em nosso repositório não teremos um branch bug-fix (já que está no fork deles), mas teremos pull/<pr#>/head apontando para a5a775. Isso significa que podemos muito facilmente baixar todo branch de Pull Request de uma só vez sem ter que adicionar um monte de remotos.

Agora, você poderia fazer algo como o fetch da referência diretamente.

Isto diz ao Git: “Conecte-se ao remoto origin e baixe o ref chamado refs/pull/958/head.” O Git obedece de bom grado e baixa tudo o que você precisa para construir esse ref, e coloca um ponteiro para o commit que você deseja sob .git/FETCH_HEAD. Você pode seguir isso com git merge FETCH_HEAD no branch onde deseja testar a alteração, mas a mensagem do commit de merge parecerá um pouco estranha. Além disso, se você estiver revisando um monte de pull requests, isso se torna entediante.

Há também uma forma de fazer fetch de todos os pull requests e mantê-los atualizados sempre que você se conectar ao remoto. Abra o .git/config em seu editor favorito e procure pelo remoto origin. Deve se parecer um pouco com isto:

A linha que começa com fetch = é um “refspec”. É uma forma de mapear nomes no remoto com nomes no seu diretório .git local. Esse em particular diz ao Git: "as coisas no remoto que estão sob refs/heads devem ir para o meu repositório local sob refs/remotes/origin." Você pode modificar esta seção para adicionar outro refspec:

Essa última linha diz ao Git: “Todos os refs que se parecem com refs/pull/123/head devem ser armazenados localmente como refs/remotes/origin/pr/123.” Agora, se você salvar esse arquivo e fizer um git fetch:

Agora, todos os pull requests remotos são representados localmente com refs que atuam de forma muito parecida com as branches de rastreamento (tracking branches); eles são somente leitura e são atualizados quando você faz um fetch. Isso torna super fácil testar o código de um pull request localmente:

Os mais observadores entre vocês devem ter notado o head no final da porção remota do refspec. Há também um ref refs/pull/#/merge no lado do GitHub, que representa o commit que resultaria se você clicasse no botão “merge” no site. Isso pode permitir que você teste o merge antes mesmo de apertar o botão.

Você não apenas pode abrir Pull Requests que visam o branch principal ou master, como na verdade pode abrir um Pull Request visando qualquer branch na rede. De fato, você pode até mesmo visar outro Pull Request.

Se você vir um Pull Request que está indo na direção certa e tiver uma ideia para uma alteração que dependa dele ou sobre a qual não tenha certeza se é uma boa ideia, ou simplesmente não tiver acesso de push ao branch de destino, você pode abrir um Pull Request diretamente para ele.

Quando você vai abrir um Pull Request, há uma caixa na parte superior da página que especifica de qual branch você está solicitando fazer o pull e para qual branch você está solicitando fazer o pull. Se você clicar no botão “Edit” (Editar) à direita dessa caixa, poderá alterar não apenas os branches, mas também de qual fork.

Aqui, você pode facilmente especificar o merge do seu novo branch em outro Pull Request ou outro fork do projeto.

Quando mencionamos “notificações” aqui em relação ao GitHub, queremos dizer uma maneira específica que o GitHub tenta entrar em contato com você quando ocorrem eventos e há algumas maneiras diferentes de configurá-las. Se você for para a guia “Notification center” (Centro de notificações) na página de configurações, poderá ver algumas das opções que você tem.

As duas opções são receber notificações por “Email” e pela “Web” e você pode escolher uma, nenhuma ou ambas para quando participar ativamente de coisas e para atividades em repositórios que você está observando.

Se você estiver usando um branch diferente de “master” como seu branch padrão, no qual você quer que as pessoas abram Pull Requests ou vejam por padrão, você pode alterar isso na página de configurações do seu repositório, na guia “Options” (Opções).

Basta alterar o branch padrão no menu suspenso e ele será o padrão para todas as principais operações a partir de então, incluindo qual branch é feito o checkout por padrão quando alguém clona o repositório.

Se você quiser transferir um projeto para outro usuário ou para uma organização no GitHub, há uma opção “Transfer ownership” (Transferir propriedade) na parte inferior da mesma guia “Options” (Opções) da página de configurações do seu repositório que permite fazer isso.

Isso é útil se você estiver abandonando um projeto e alguém quiser assumi-lo, ou se o seu projeto estiver crescendo e você quiser movê-lo para uma organização.

Isso não apenas move o repositório, juntamente com todos os seus observadores (watchers) e estrelas (stars), para outro lugar, mas também configura um redirecionamento da sua URL para o novo lugar. Ele também redirecionará clones e fetches do Git, não apenas solicitações da web.