Em nossos tutoriais anteriores para o software de controle de versão git, aprendemos os comandos básicos essenciais para usar o git, como bem como como trabalhar com o Github.com para estabelecer um repositório e enviar o código do nosso projeto para o site.
Agora é hora de começar a trabalhar com o GitHub (e o git) da maneira que deveriam ser usado: fazer alterações no projeto com segurança de um lado e mesclá-las de volta ao projeto original, uma vez que se provaram estar corretas. Ou pelo menos não desastroso.
Agora você entende que o git salva cada versão do seu projeto como um instantâneo do código exatamente como estava no momento em que você o comprometeu. Basicamente, criando uma linha do tempo de versões de um projeto conforme ele progride, para que você possa reverter para uma versão anterior no caso de ocorrer um desastre.
A forma como git e GitHub gerenciam essa linha do tempo – especialmente quando mais do que uma pessoa está trabalhando no projeto e fazendo alterações – usando branches. Um branch é essencialmente um conjunto exclusivo de alterações de código com um nome exclusivo. Cada repositório pode ter um ou mais branches. O branch principal – aquele em que todas as alterações eventualmente são mescladas de volta e é chamado de master. Esta é a versão oficial de trabalho do seu projeto e a que você vê quando visita o repositório do projeto em github.com/yourname/projectname.
Não mexa com o mestre. Se você fizer alterações no branch master de um projeto de grupo enquanto outras pessoas também estão trabalhando nele, suas mudanças imediatas irão se espalhar para afetar todos os outros e muito rapidamente haverá conflitos de fusão, choro, rasgamento de roupas, e pragas de gafanhotos. É tão sério.
Por que o mestre é tão importante para não mexer? Uma palavra: o branch master é implantável. É o seu código de produção, pronto para ser lançado no mundo. O branch master deve ser estável, e é o contrato social do software de código aberto nunca, jamais forçar qualquer coisa para master que não seja testado ou que interrompa a compilação. Todo o motivo pelo qual o GitHub funciona é que é sempre seguro trabalhar a partir do mestre.
Ramificação
Em vez disso, todos usam branches criados do mestre ao experimento, fazem edições, adições e alterações , antes de eventualmente reverter esse branch para o mestre, uma vez que tenham sido aprovados e estejam funcionando. O mestre então é atualizado para conter todas as coisas novas.
Para começar a trabalhar em qualquer coisa nova em um projeto, ou para mudar as coisas existentes, você cria um branch fora do branch mestre estável. Vamos continuar trabalhando com o projeto de amostra criado para nosso tutorial anterior, o bom e velho studious_octo_carnival. Agora abra sua versão em seu computador e faça cd no diretório.
Etapa 1: Faça um inventário.
Antes de criar novos branches, queremos verificar se há outros branches existentes . Nós sabemos sobre o mestre, mas quem sabe o que nossos colaboradores do projeto podem fazer, aqueles macacos travessos? Portanto, podemos ver todos os branches existentes digitando “git branch -a” no terminal, o que diz ao git que queremos ver TODOS os branches neste projeto, mesmo aqueles que não estão em nosso espaço de trabalho local.
Isso retorna a saída que você vê no exemplo de código abaixo. Sua aparência pode variar um pouco dependendo do seu sistema operacional e do aplicativo de terminal, mas as informações são basicamente as mesmas. O asterisco próximo a “mestre” na primeira linha da saída indica que estamos atualmente nesse ramo. A segunda linha nos diz que em nossa origem remota, denominada, existe uma única ramificação, também chamada de mestre. (Lembre-se de que nosso controle remoto é o repositório GitHub para este projeto).
Etapa 2: Criar um novo branch
Agora que sabemos como visualizar branches, vamos fazer um! Tenha em mente, à medida que avançamos, que temos nosso branch master, nosso projeto original. Agora vamos criar uma nova versão do projeto, um branch, para brincar e fazer alterações localmente em nosso computador – enquanto a versão original do projeto, o master, permanece com segurança sem ser molestada lá no GitHub. Damos à nova ramificação um nome descritivo para nos lembrar o que pretendemos fazer enquanto trabalhamos nela. Neste caso, será um simples “Hello World”, então vamos chamá-lo de hello_octo.
Para criar este novo branch, digite “git checkout -b branchNameHere” (então, em nosso caso, “git checkout -b hello_octo”).
Supondo que ninguém mais tenha feito um branch chamado “hello_octo”, git retorna “Alternado para um novo branch ‘hello_octo’.” (No caso em que já existe um branch com esse nome, git nos diria “fatal: Um branch chamado ‘hello_octo’ já existe.” Não é grande coisa, apenas faça git checkout -b novamente com uma nova variação de nome). / p>
Também podemos usar o comando git checkout para alternar para frente e para trás entre nossos dois ramos. Digite “git checkout branchName” para alternar para esse branch.Portanto, “git checkout master” leva você ao master, enquanto “git checkout hello_octo” leva você de volta ao branch hello_octo.
Se você tentar mudar para um branch que não existe, como “git checkout hello_kitty”, git irá informá-lo de que é proibido:
Como o git sabe em qual branch você está? O Git está sempre observando o que você faz e mantém um ponteiro especial chamado HEAD. Como a agulha em uma bússola sempre aponta para o norte, HEAD sempre indica o branch local em que você está atualmente.
(Também poderíamos ter criado nosso branch usando o comando git “git branch branchNameHere” e, em seguida, alternar para ele com git checkout. No entanto, o atalho bacana com o “-b” em “git checkout -b branchNameHere” cria o branch E alterna para ele. Não posso dizer quantos programadores iniciantes no git geram mensagens de erro e frustração porque eles simplesmente não se lembraram de mudar para o novo branch depois de criar i t. Portanto, estamos nos mantendo com git checkout -b, mmmkay?)
Fazendo alterações em nosso branch de trabalho
Agora que temos vários branches – nosso branch de trabalho para fazer alterações, e nosso branch master permanecendo sem ser molestado – podemos começar a trabalhar. Em nosso cenário, vamos usar nosso branch “hello_octo” para fazer e testar nossas alterações e, em seguida, enviá-los de volta ao branch master no GitHub.
Lembre-se de ter certeza de que está no seu branch funcional, e não master, com o bom e velho branch git -a.
Etapa 3. Crie um novo arquivo em branco, chamado “hello_octo_world”:
(Este arquivo em branco é apenas para fins de demonstração, então não se preocupe que não haja nenhum nome / tipo de extensão de arquivo).
Uma vez que é novo, certo agora este arquivo está apenas em seu branch. Use o comando “ls” para visualizá-lo:
No entanto, lembre-se de que estamos em nosso ramo de trabalho, hello_octo, onde criamos esta coisa nova. O mestre não sabe nada sobre nenhum hello_octo, porque ele é isolado com segurança de qualquer mudança que queira ou não que estejamos fazendo aqui no branch de trabalho. Ainda é o mesmo mestre serenamente inalterado com o qual começamos:
Etapa 4: Prepare e envie nosso novo arquivo para o branch de trabalho.
Agora é a hora para preparar (adicionar) e enviar nosso novo arquivo no branch de trabalho. (Parece familiar?). Isso irá anexar esta nova entidade ao branch de trabalho em preparação para movê-lo eventualmente para o mestre. Este arquivo agora existe no branch hello_octo; como vimos acima, ele não existe atualmente no branch master.
Neste ponto, você acabou de fazer um instantâneo das mudanças no branch. Em um projeto do mundo real, provavelmente há mais mudanças e trabalho a ser feito. Agora é quando você faria isso, fazendo commits ao longo do caminho em pontos lógicos. Lembre-se de que, no GitHub, os commits representam seus salvamentos consecutivos. Cada commit tem uma mensagem de commit associada, que é uma descrição explicando especificamente o que você fez lá e por quê. As mensagens de confirmação capturam o histórico de suas alterações, para que, no futuro, você, assim como outros colaboradores do projeto, possam entender o que você fez e por quê.
Mesclando código entre ramos
Assim que estão finalmente concluídas com todas as alterações e adições – e tudo funciona * – é hora de fundir. A parte interessante vem depois que voltamos para nosso branch master (que – diga comigo! – fazemos com “git checkout master”). “Hello_octo_world” parece estar faltando, mas não está – atualmente, ele existe em nosso trabalho ramo e estamos em nosso ramo mestre. Estou mostrando isso novamente porque é o cerne da compreensão dos branches no git:
Agora: neste exercício , “hello_octo_world” representa qualquer alteração em qualquer arquivo (ou a adição de um novo arquivo) que passou em todos os testes em nosso branch de desenvolvimento e está pronto para entrar em produção. O processo de mover o código entre os branches (frequentemente do desenvolvimento para produção) é conhecido como fusão.
Muito importante: ao fazer a fusão, precisamos estar no branch para o qual queremos fazer a fusão. Basicamente, estaremos dizendo ao git: “Viu aquela coisa nova? Está tudo bem trazê-lo aqui agora. ”
Etapa 5: Mesclar as alterações do branch de trabalho
Neste caso, já que queremos mesclar do nosso branch de trabalho, onde o” hello_octo_world ” existe um arquivo, para o nosso branch master, precisamos estar no master.
Uma vez no branch master, tudo o que precisamos fazer é executar o comando merge. A melhor maneira de fazer isso é digitar ” git merge –no-ff ”- o adicional” –no-ff “diz ao git que queremos reter todas as mensagens de commit antes da fusão. Isso tornará o rastreamento de alterações mais fácil no futuro:
Voltando ao GitHub
A última coisa que precisamos fazer agora é informar ao GitHub que estamos mexendo com mestre aqui em nosso ambiente de desenvolvimento local.
Em outras palavras, é hora de git push. Você conseguiu!
A saída do git confirma que a fusão de seu branch de desenvolvimento com o branch master em seu ambiente local, agora foi copiado para o servidor remoto: “master → master.”
E é isso! Nós criamos com sucesso um branch de trabalho separado do master. Fizemos alterações nele. Preparamos e consolidamos essas alterações. Em seguida, as mesclamos de volta ao mestre em nosso ambiente de trabalho local. Então, finalmente, enviei tudo para o GitHub para que todas as versões do nosso projeto sejam iguais, em todos os lugares!
Uma nota final
Alguma limpeza está em ordem agora: uma vez que fundimos com sucesso nosso branch hello_octo, não precisamos mais dele. Para excluir um branch fundido, simplesmente digite “git branch -d branchName”:
Não se preocupe: se você acidentalmente tentar deletar um branch que ainda não foi mesclado, o git irá gerar um erro.
Então! Até agora estivemos usando um projeto de amostra extremamente simplificado, porque neste ponto o mais importante é entender e assimilar o fluxo de trabalho do git. A fusão é muito mais do que isso no mundo real – por exemplo, o que acontece se você receber mensagens de erro porque a fusão tem conflitos? Não se preocupe, novo git-ster, chegaremos lá.
Seu dever de casa: crie (“toque”) mais alguns arquivos novos no projeto de exemplo e pratique fazendo alterações, testando, confirmando e, finalmente, mesclando-os de volta. Tome cuidado para entender para onde seu HEAD está apontando – ou seja, qual é o seu branch atual. Somente envie alterações para o seu branch de trabalho.
Porque, lembre-se: Não. Suje. Com. O. Master .