github tutorial developers how use github
Este tutorial do GitHub explica o que é GitHub e como criar um repositório, uma ramificação e uma solicitação de pull. Inclui regras de proteção de filiais e resolução de conflitos:
O que é GitHub?
GitHub é um serviço de nuvem que ajuda os desenvolvedores a armazenar e gerenciar seu código-fonte, bem como rastrear e controlar todas as alterações no código-fonte.
Em termos simples, GitHub é destinado a desenvolvedores onde eles podem gerenciar o projeto, hospedar o código-fonte e revisá-lo também. Exploraremos tudo isso nesta série.
Lista de tutoriais nesta série GitHub:
Tutorial # 1: Tutorial do GitHub para desenvolvedores | Como usar o GitHub (Este tutorial)
Tutorial # 2: Projetos, equipes, fork e wiki do GitHub para documentar projetos
Tutorial nº 3: Comandos Git avançados e tutorial de integração com GitHub
Tutorial nº 4: Tutorial da API REST do GitHub - Suporte à API REST no GitHub
Tutorial # 5: Tutorial do GitHub Desktop - Colabore com o GitHub a partir do seu desktop
Tutorial # 6: Tutorial do TortoiseGit - Como usar o TortoiseGit para controle de versão
O que você aprenderá:
O que é Git?
Git é um sistema de controle de versão Open Source onde todo o código-fonte está disponível na máquina do desenvolvedor. Git também é um Cliente e Sistema de Controle de Versão Distribuída (DVCS) onde você pode fazer ramificações e mesclagens.
Primeiros passos com GitHub
Para começar a usar o GitHub, realizaremos as seguintes etapas.
- Crie um Repositório para organizar projetos.
- Criar uma filial
- Faça alterações no arquivo e confirme.
- Crie uma solicitação pull para mesclar o conteúdo.
- Proteger Filial
Na segunda parte da série, também examinaremos os outros recursos do GitHub como Criação de Organização, Equipes, Problemas, Marcos, Forks, Releases e Wikis.
Crie um repositório GitHub
Um Repositório GitHub contém os artefatos do projeto, como código-fonte, documentos, imagens, etc. Criaremos e usaremos um repositório de demonstração para realizar todas as etapas acima.
Faça login em Github.com e Criar um Novo Repositório . Clique no Novo botão.
Adicione os detalhes do repo abaixo conforme mostrado e clique em Criar repositório . Defina o acesso como Privado ou Público. É melhor defini-lo como público, pois poucos recursos dependem desse acesso.
Nota: O usuário que cria o repositório é o proprietário do Repositório GitHub.
O Repositório é criado com um arquivo README.
Adicionando colaboradores ao repositório GitHub
Gostaríamos que a equipe trabalhasse neste repositório. Para isso, teremos que convidar os colaboradores para trabalhar no repositório. Para adicionar colaboradores, acesse a página principal do Repositório e clique no botão Configurações ícone.
Clique em Colaboradores no painel esquerdo e adicione os colaboradores que possuem conta Github. Um convite seria enviado e os colaboradores precisariam aceitar o convite.
Os colaboradores são adicionados conforme mostrado abaixo. Posteriormente, neste tutorial, veremos como os Colaboradores serão adicionados como revisores da solicitação pull criada para mesclar o código.
Executando um C básico omitir
Abra o arquivo README e execute um commit básico. Clique no Ícone de edição para começar a modificar o arquivo.
Modifique o arquivo, adicione um comentário e clique em Comprometer-se .
O arquivo é confirmado (alterações salvas) no Repositório Github.
Poucas operações para criar pastas e arquivos dentro do Repositório serão vistas.
Para criar a pasta e um arquivo em: Clique no Criar novo arquivo botão no nível do Repositório. Digite o nome do diretório seguido por / e o nome do arquivo conforme mostrado abaixo.
Clique em Comprometer-se no fundo. A pasta e o arquivo são criados conforme mostrado. Assim, os arquivos e pastas são criados no mestre branch que é o principal branch de integração e principalmente onde as versões de software podem ser construídas.
Os desenvolvedores normalmente trabalham na tarefa atribuída a eles em um branch separado e mesclam as alterações no branch master. Por exemplo, branches podem ser criados para desenvolvimento de recursos ou resolução de bugs ou trabalho em melhorias, etc. Assim, ao criar um branch, o trabalho é isolado sem perturbar os outros branches.
Na próxima etapa, podemos ver como os branches podem ser criados e as solicitações pull podem ser definidas para revisar e mesclar o código no branch master.
Movendo um arquivo
Para mover um arquivo para outra pasta, execute as seguintes etapas. Por exemplo, para mover o arquivo rules.txt para uma pasta doc. Clique no arquivo.
Clique no ícone para editar o arquivo.
Adicione o caminho doc / antes do arquivo rules.txt . Clique em Confirmar as alterações.
O caminho agora está atualizado.
Criação de um branch GitHub
Vá para a página principal do Repositório e digite para criar um recurso ramificar como mostrado. Clique em Crie uma filial.
Estamos agora no recurso filial. Os arquivos são os mesmos. Faremos agora algumas alterações nos arquivos do recurso branch e criar uma solicitação pull para revisar as alterações e mesclar o código no mestre filial.
Faça alterações nos arquivos na ramificação do recurso.
Abra o arquivo Java na pasta Src, adicione algum código e confirme a mudança.
Criar uma solicitação pull do GitHub
Na seção anterior, criamos um branch recurso e fez algumas alterações em um arquivo. As mudanças não estão no mestre filial. Para isso, precisamos criar um Pull Request pelo qual o usuário está propondo certas alterações a serem revisadas e integradas ao mestre filial.
A criação de solicitação pull mostrará as diferenças entre a ramificação de origem e de destino e será necessária para resolver conflitos, se houver.
Clique em Comparar e solicitar solicitação na página principal do repositório.
Você pode ver que as alterações em ambas as ramificações podem ser mescladas. Clique em Criar solicitação de pull.
Clique em Merge Pull Request e confirme para concluir a fusão.
As alterações foram mescladas com sucesso no mestre filial. Nossa primeira solicitação de pull foi concluída com sucesso.
Atribuir revisores com solicitações pull e revisão de código
O Github tem um bom recurso de usar um arquivo CODEOWNERS onde podemos selecionar as pessoas responsáveis pelo código-fonte no repositório. Os proprietários do repositório podem criar este arquivo e quaisquer usuários definidos no arquivo são solicitados por padrão para a revisão durante a criação da solicitação pull.
Para usar este recurso, você deve usar a versão GitHub Pro ou tornar o Repositório Público.
Na raiz do repositório, crie este arquivo no seguinte formato e confirme o arquivo.
* @username ou @orgname ou @teamname
* significa principalmente todos os arquivos no repo. Você também pode especificar extensões específicas como * .java ou * .js etc. Os usuários definidos no arquivo receberão uma solicitação de revisão automaticamente. Com o arquivo CODEOWNERS definido, não há necessidade de adicionar revisores explicitamente de forma manual e tem um pouco mais de flexibilidade para escolher quais arquivos serão revisados.
De volta ao recurso branch faz uma pequena mudança no arquivo Java e cria um Pull Request. Na tela Pull Request, atribua um revisor no lado direito. Clique em Criar solicitação de pull.
Você pode ver na tela acima que os revisores podem ser atribuídos manualmente, mas os revisores são definidos no arquivo CODEOWNERS que receberão automaticamente uma solicitação para revisar as alterações do código.
Enfim, por enquanto, vamos Conecte-se como revisor e aprovar as alterações. Efetue login como o usuário vniranjan2512 para aprovar as alterações.
Há um pedido de aprovação / rejeição das alterações, em Solicitação de pull.
Clique em Pull Request e Adicione seu comentário.
Você pode clicar no + assine e adicione comentários de revisão para a linha de código Adicionado / Modificado / Excluído, na tela que aparecer.
Clique em Comece uma revisão.
Clique em Conclua sua revisão. Aprovar como mostrado e Enviar revisão .
De volta ao usuário original que levantou uma solicitação pull, você pode adicionar um comentário e resolver ou encerrar a conversa.
A solicitação de pull de mesclagem agora pode ser concluída.
As alterações foram mescladas com sucesso no mestre filial postar a revisão e mesclar a solicitação pull.
Então, para resumir neste estágio, vimos que os desenvolvedores trabalham no recurso ramificar e, em seguida, gerar uma solicitação pull para mesclar as alterações ao mestre filial. O acima foi um cenário onde os conflitos não existiam. Na próxima seção, veremos as maneiras de resolver conflitos manualmente se os arquivos forem alterados em vários ramos.
Resolvendo Conflitos
É possível que os mesmos arquivos em várias ramificações sejam alterados. Nesse caso, haveria conflitos e devem ser resolvidos por meio do Pull Request levantado.
Por exemplo, fazer alterações no arquivo Java em ambos os mestre e recurso branches e gerar uma solicitação de pull.
A mensagem de solicitação de pull mostrada é que as alterações não podem ser mescladas automaticamente. Portanto, os conflitos devem ser resolvidos. Prossiga para criar uma solicitação pull.
Assim que a solicitação pull for gerada, os conflitos precisarão ser resolvidos clicando no Resolver conflitos botão.
Remova as marcações que estão essencialmente resolvendo conflitos manualmente e clique em Marcar como resolvido e Confirme a mesclagem.
A vista final do arquivo após as marcações serem removidas.
A solicitação de mesclagem de pull pode ser concluída. O mestre e recurso os ramos agora serão idênticos.
Você ainda pode ver na tela acima que a revisão é solicitada, mas não obrigatória. Na próxima seção, veremos sobre as regras de proteção de Branch em que o proprietário do repositório pode obrigatoriamente solicitar uma revisão e também proteger o mestre branch de se comprometer diretamente com ele, mas apenas por meio de uma solicitação pull.
Regras de proteção de filial
Nas seções anteriores, vimos sobre solicitações de pull do Github e também sobre solicitações de revisões que não eram obrigatórias ou opcionais. No código de cenários de projeto típicos, as revisões são uma obrigação e uma parte do processo de desenvolvimento.
Vamos ver como fazer isso.
Em github.com, esse recurso pode ser definido apenas para repositórios públicos ou usando a versão pro Github. Na página principal do Repositório vá para Configurações e clique no Galhos categoria à esquerda.
Clique em Adicionar regra debaixo de Regras de proteção de ramos. A regra adicionou solicitações para revisões obrigatórias de solicitação pull dos proprietários do código antes de mesclar para o mestre filial.
Isso também irá garantir que o ramo mestre está protegido e nenhuma confirmação direta pode ser feita neste branch e só pode ser confirmada por meio de solicitações pull após uma revisão completa. Esta configuração é definida pelo proprietário do repositório.
De fato, um ótimo recurso !!!
Clique em Crio Uma vez feito. Para testar este cenário, faça uma alteração em um arquivo no recurso ramificar e criar uma solicitação pull.
A tela a seguir mostra que uma revisão é obrigatoriamente exigida pelos proprietários do código.
Publique a revisão dos Proprietários do código, a solicitação pull pode ser mesclada.
Como um colaborador do repositório, se você fizer alterações em qualquer um dos arquivos, devido às regras dos branches protegidos criados, você não poderá se comprometer diretamente com o branch master, mas apenas através de um Pull Request após criar um branch como mostrado abaixo de.
Transferindo um repositório para outra conta de usuário
Normalmente, um repositório de usuário pessoal tem um único proprietário e todos os outros são colaboradores. Portanto, de certa forma, você não pode ter vários proprietários em um repositório de contas de usuário. Mas a propriedade pode ser transferida para outra conta de usuário. Quando terminar, o proprietário do repositório original se torna automaticamente um colaborador no novo repositório de conta do usuário.
O novo proprietário pode, então, começar a administrar o artefato, problemas, solicitações pull, projetos, liberações e configurações.
Normalmente, quando comandos como ‘git clone’ ou ‘git push’ são executados no repositório local, os comandos redirecionarão para o novo repositório. Mas quando você executa o comando ‘git remote -v’, ele ainda mostra a URL do repositório original. Para evitar confusão ao mudar para o novo URL remoto, poste a transferência do repositório usando o comando ‘git remote set-url’.
Para transferir um repositório, vá para a guia Configurações do repositório e em Opções? Zona de perigo clique em Transferir
Insira o nome do repositório e a nova conta de usuário para a qual a propriedade deve ser transferida.
Clique em Eu entendo, transferir este repositório
Você deverá ver uma mensagem informando que o repositório foi transferido para o novo proprietário.
Um e-mail será enviado ao proprietário do repositório original para aprovar a transferência. Assim que a transferência for aprovada, o repositório será transferido para o novo proprietário e o proprietário do repositório original será adicionado como um colaborador.
Agora defina a nova URL do repositório na máquina onde o antigo repositório foi clonado. Os comandos a seguir devem ser definidos em todas as máquinas onde o antigo repositório foi clonado.
Todas as solicitações de pull, problemas, wiki serão transferidos. As atribuições de problemas permanecerão intactas.
Alguns comandos úteis do Git
Existem alguns dos comandos Git básicos a serem configurados inicialmente em sua máquina local, uma vez que o cliente Git é instalado em sua máquina Linux ou Windows. Os desenvolvedores trabalham localmente, sem conexão com o repositório no GitHub, na cópia completa do código-fonte disponível no GitHub e sincronizam com ele.
Em primeiro lugar, defina seu nome de usuário e endereço de e-mail para garantir que todos os commits que você fizer usem essas informações.
git config –global user.name “UserName”
git config –global user.email “myemail@myemail.com”
Quando você precisa adicionar uma mensagem durante os commits, você também pode configurar o editor necessário para o mesmo.
sites de teste de produto que enviam coisas
git config –global core.editor notepad
Obtenha uma lista de todos os valores de configuração definidos.
git config –list
Às vezes, as organizações têm servidores proxy para se conectar à Internet. Nesse caso, você precisará especificar um servidor proxy e o número da porta para acessar todos os repositórios no GitHub.
git config –global http.proxyhttp: // Nome de usuário: Senha @ proxyserver: porta
Clone ou faça uma cópia local do Repositório. Obtenha o URL clone do repositório no GitHub e execute o comando git.
Conclusão
Neste tutorial, vimos como um desenvolvedor pode começar a trabalhar no GitHub, desde Criando um Repositório GitHub, Ramificação, Solicitação de pull, Protegendo uma ramificação e alguns comandos básicos do Git.
Em nosso próximo tutorial, veremos os outros recursos do GitHub principalmente sobre como criar organizações, equipes, bifurcar um repositório, criar problemas, marcos e associação com solicitações pull, wiki e seus usos e alguns outros comandos avançados do Git que serão úteis para os desenvolvedores.
Leitura recomendada
- Tutorial de reflexão Java com exemplos
- Git vs GitHub: explore as diferenças com exemplos
- Tutorial Python DateTime com exemplos
- Integração do Selenium com GitHub usando Eclipse
- Um guia rápido SoapUI para armazenar dados de solicitação e resposta em um arquivo - Tutorial # 15 do SoapUI
- Tutorial do Bugzilla: Tutorial prático da ferramenta de gerenciamento de defeitos
- 20+ Tutorial do MongoDB para iniciantes: Curso gratuito do MongoDB
- Tutorial de fragmentação do MongoDB com exemplo