Git e Github: um guia do iniciante para iniciantes completos

Apesar do que a televisão e os filmes nos dizem, a vida como desenvolvedor de software não inclui sentar em uma sala escura, nosso teclado iluminado apenas pelo brilho do monitor, a ideia de interagir com outro ser humano é repulsiva. Não, a vida como desenvolvedor de software é social e colaborativa - às vezes ao ponto da frustração. É por isso que temos git e Github.

Git é um software de controle de versão que torna a colaboração com colegas de equipe super simples ... assim que você ultrapassar a curva de aprendizado inicial. Pode ser intimidante, mas é por isso que estou aqui!

O que é Git?

Bem, não é apenas a maneira como nós, sulistas, expulsamos os patifes de nossas varandas, vou lhe dizer isso.

Como eu disse acima, Git é um software de controle de versão. Foi criado por Linus Torvalds, o cara que inventou o Linux. Você não precisa estar executando o Linux para usar o git - você também pode usá-lo no Windows e no Mac.

O Git permite que você acompanhe facilmente todas as revisões feitas por você e sua equipe durante o desenvolvimento de seu software. Todos vocês compartilham um repositório de código que é trabalhado de forma independente e, em seguida, mesclado novamente. Você também não precisa estar conectado o tempo todo porque o projeto é salvo localmente em cada máquina e remotamente (provavelmente no Github).

Git é especial (e praticamente obrigatório) porque você pode reverter para qualquer versão anterior do seu código, ramificar e desenvolver um recurso específico sem afetar nada ou ninguém e manter a segurança contra corrupção de dados devido à sua natureza distribuída.

Ele também fornece criptografia facilmente implementada e compatibilidade entre sistemas operacionais, bem como fluxos de trabalho assíncronos e não lineares para que, não importa onde você esteja, você possa trabalhar em algum aspecto do seu projeto.

Basicamente, se você não estiver usando o git, estará codificando com uma das mãos amarrada nas costas.

Vocabulário Requerido

Quando você está começando a usar o git, pode ser intimidante. Comandos e conceitos podem parecer totalmente estranhos se você nunca usou nenhuma forma de controle de versão no passado. Você vai pegá-los super rápido, no entanto.

Repositório:

Freqüentemente chamado de repo . Um repositório é a coleção de arquivos e pastas que você está usando o git para rastrear. O repositório consiste em todo o histórico das mudanças de sua equipe no projeto. É a grande caixa na qual você e sua equipe jogam seu código.

Github:

A solução de armazenamento remoto mais popular para repositórios git. Ele também permite que você defina permissões de acesso para projetos, rastreie e envie bugs, aceite solicitações de recursos, assine notificações de repositório e utilize uma interface gráfica, em vez de usar a linha de comando. O padrão dos repos é público, mas as contas pagas podem ter contas privadas.

Comprometer-se:

Pense nisso como salvar seu trabalho. Quando você efetua um commit em um repositório, é como se estivesse reunindo os arquivos como eles existem naquele momento e os colocando em uma cápsula do tempo. O commit existirá apenas em sua máquina local até que seja enviado a um repositório remoto.

Empurre:

Empurrar é o pão para a manteiga de comprometimento. A confirmação lança seus arquivos na cápsula de tempo, e o envio é o que lança a cápsula no espaço. Empurrar é essencialmente sincronizar seus commits para a nuvem (novamente, provavelmente Github). Você também pode enviar vários commits de uma vez. Você pode trabalhar offline, cometer muito trabalho e, em seguida, enviar tudo para o Github quando estiver de volta à civilização com aquele doce wi-fi doce.

Filial:

Você pode pensar em seu repositório git como uma árvore. O tronco da árvore, o software que entra no ar, é chamado de Master Branch. Esse é o que vai ao vivo. Os galhos dessa árvore são, bem, chamados de galhos. Essas são instâncias separadas do código que se ramifica da base de código principal. Você pode ramificar para um único recurso ou um patch experimental. Ao ramificar, você pode preservar a integridade do software e ter uma maneira de reverter se você fizer algo totalmente maluco. Ele também permite que você trabalhe em sua tarefa sem tropeçar no caminho de sua equipe (ou eles no seu).

Unir:

Quando um branch é polido, livre de bugs (pelo menos até onde você pode dizer), e pronto para se tornar parte da base de código primária, ele será mesclado no branch master. Mesclar é exatamente o que parece: integrar duas ramificações. Qualquer código novo ou atualizado se tornará uma parte oficial da base de código. Qualquer pessoa que ramificar a partir do ponto de fusão também terá esse código em sua ramificação.

Clone:

A clonagem de um repo é exatamente o que parece. Ele pega todo o repositório online e faz uma cópia exata dele em sua máquina local. Você precisará fazer isso por uma série de razões, não menos das quais começar no meio de um projeto com uma nova equipe, trocar estações de trabalho ou reiniciar a partir de um repositório corrompido.

Garfo:

A bifurcação é muito parecida com a clonagem, só que em vez de duplicar um repositório existente em sua máquina local, você obtém um repositório inteiramente novo desse código com seu próprio nome. Esse recurso é usado principalmente para pegar uma base de código existente e seguir uma direção totalmente nova com ela, o que acontece muito em software de código aberto; os desenvolvedores veem uma ideia básica que funciona, mas desejam seguir um caminho diferente com ela. A bifurcação permite que isso aconteça. Você também pode jogar no repositório de outro desenvolvedor como se fosse sua própria sandbox pessoal. E se você fizer algo que acha que eles podem gostar, você pode fazer uma solicitação de pull para que seja mesclado.

Solicitação de pull:

Uma solicitação pull é quando você envia uma solicitação para as alterações feitas (em uma ramificação ou bifurcação) para serem puxadas (ou mescladas) na Ramificação mestre do repositório. Este é o grande momento. É aqui que a mágica acontece. Se a solicitação pull for aprovada, você terá contribuído oficialmente para o software e o Github mostrará para sempre exatamente o que você fez. No entanto, se a solicitação pull for negada por qualquer motivo, o negador poderá dar feedback sobre o motivo da rejeição da solicitação e o que você pode fazer para que seja aceita.

Comandos iniciais e necessários

Isso não foi tão ruim, foi?

Direito. Agora que você tem uma ideia clara do que é git, é hora de se aprofundar e sujar as mãos.

Devo aproveitar esta oportunidade para observar, entretanto, que presumo que você esteja usando a linha de comando para interagir com o git. Claro que existem clientes git gráficos (e o Github até permite que você faça quase tudo por meio de sua interface web), mas para os propósitos desta postagem, não vamos nos preocupar com eles. Você fará um punhado de coisas fora do terminal, mas a linha de comando será sua nova melhor amiga. Então é isso que vamos fazer também.

Como instalar o Git

O Git (provavelmente) não veio instalado no seu computador, então temos que colocá-lo lá. Felizmente, instalar o git é muito fácil, esteja você no Linux, Mac ou Windows.

Para Linux, abra o terminal e digite sudo apt-get install git-all (se você estiver no Ubuntu. Caso contrário, há uma lista de todos os comandos de instalação do pacote Linux para qualquer outra distro em que você estiver.)

No Windows, é tão simples. Você baixa o instalador e o executa.

No Mac, você só precisa abrir o terminal e digitar git . Se o git não estiver instalado, você verá o seguinte:

Depois de clicar em Instalar, você está pronto para prosseguir.

Ver? Super fácil!

Usando Git

É aqui que começa a diversão. Agora que você instalou o git, é hora de ... git-r-done! Hah! Mas é realmente hora de se aprofundar e aprender a começar a usar essa pequena e incrível peça de magia da linha de comando. E que melhor lugar para começar do que o Github?

Então vá em frente e registre sua nova conta no Github (ou faça o login se você já tiver uma, e eu estarei com você em um segundo).

O Github é gratuito para repositórios públicos e você pode ter repositórios privados por um preço. (Para sua informação: você pode obter repositórios privados gratuitos no Bitbucket, que é um lugar menos conhecido, mas incrível). Na maioria das vezes, a opção gratuita no Github é adequada para a maioria das pessoas (e também funciona como um currículo vivo!), Mas alguns clientes e empregadores exigirão privacidade e segurança, por isso é bom ter opções.

Depois disso, você está pronto para configurar seu primeiro repositório! Depois de verificar seu e-mail e todas essas coisas divertidas.

Você vai querer configurar o repositório no Github primeiro. Você pode fazer isso no seu computador e depois carregá-lo também, mas é mais simples apenas fazer na web primeiro.

Observe que não estou preocupado com uma licença ou .gitignore neste repo. Como este não é um software real, não preciso me preocupar com eles, mas em casos de produção, .gitignore permite que você, obviamente, ignore os arquivos dentro do diretório do seu repo. E você pode ler sobre quais licenças seu software precisa aqui.

Estou, no entanto, inicializando o repo com um arquivo README, que você deve usar para manter a documentação básica do projeto. Costumo usá-los como um rastreador para grandes mudanças, listas de tarefas e diferentes tipos de notas enquanto trabalho. Mas isso é em projetos pessoais. Líderes de equipe diferentes terão expectativas diferentes.

Agora que o repositório existe no Github, é hora de colocá-lo em sua máquina local por meio de clonagem. À direita do seu repo, logo acima da lista de arquivos, você verá um botão verde que diz “Clonar ou fazer download”. Clique e você verá isto:

Como estamos clonando, podemos ignorar tudo, exceto a parte sobre clonagem com HTTPS. Você não terá que configurar nada. Você só precisará inserir seu nome de usuário e senha ao pressionar.

Primeiro, porém, você precisa configurar onde deseja que seu repo fique em sua máquina local. Abra seu terminal. (Usuários do Windows, procurem e abram um programa chamado Windows Powershell. Também sugiro que você clique com o botão direito e selecione “Executar como Administrador”.)

O primeiro comando que você precisa aprender é ls . Isso listará tudo no diretório atual. Para manter as coisas simples, vamos apenas fazer nossa pasta dev viver no diretório inicial do computador. Você pode usar mkdir dev para criar um diretório chamado dev . Muito simples, certo? Se você lsar novamente, verá a nova pasta listada.

Então você deseja mover para o seu novo diretório usando cd dev , que é o comando para alterar o diretório . Veja, a linha de comando não é nem um pouco assustadora! Se precisar voltar ao diretório anterior, basta usar cd ...

Uma vez que você está dentro de sua pasta nova dev, que é hora de git esta festa. Heh heh heh.

Comece copiando a URL que aparece depois de clicar no botão verde “Clonar ou Baixar” no Github. Será algo assim: https://github.com/bjk1337/myfirstrepo.git

Comandos para clonar um repositório Git do Github

• git clone https://github.com/bjk1337/myfirstrepo.git
• ls
• cd myfirstrepo - ou qualquer que seja o nome do seu repo
• ls

Depois disso, seu terminal deve ser algo assim, mostrando seu arquivo README que você configurou no Github. Parabéns! Você acabou de usar o Git pela primeira vez e agora está pronto para começar a desenvolver.

The Nitty Gitty Corajoso

Agora que você tem um repositório em sua máquina, precisa aprender a usá-lo. Então, vamos avançar um pouco e dizer que você está trabalhando há algum tempo em um projeto legal e tem alguns arquivos no diretório. É hora de se comprometer e enviá-los para o Github.

Adicionando e comprometendo-se a um repositório Git

• git status - Este comando mostrará quais arquivos não foram adicionados à lista para o próximo commit. Na maioria dos aplicativos de terminal, os arquivos não adicionados / adicionados serão vermelho / verde, respectivamente.
• git add. - adicionando um. no final do comando, você está dizendo ao git para incluir tudo no diretório. Se você quiser adicionar um único arquivo, basta usar o nome do arquivo. Como functions.php .
• git status - Dependendo se você usou o. ou o nome do arquivo, tudo o que você adicionou deve estar verde agora.
• git commit -m “adicionar três arquivos vazios” - Ao enviar esses arquivos, você também deve deixar uma mensagem rápida para que seus companheiros de equipe (ou seu futuro eu) saibam exatamente o que estava naquele commit. As convenções padrão do git dizem que você deve ser o mais conciso e específico possível e iniciar a mensagem usando o presente do verbo.

Seu terminal terá muito texto agora, e deve ser parecido com isto. Mas agora você sabe o que tudo isso significa!

Empurrando para um Repositório Git Remoto como o Github

Enviar para um repo é ainda mais fácil do que isso.

• git status - Você deve sempre verificar como as coisas parecem e ter certeza de que está no branch correto.
• git push
• Digite seu nome de usuário e senha para Github - Esteja ciente, o campo de senha permanecerá vazio, mesmo enquanto você digita. Tudo bem. Basta digitar e apertar enter. Se você usou SSH, pule esta etapa.

Você pode acessar sua conta no Github e verificar o repositório, e seus arquivos estarão lá, cometer mensagens e tudo!

Ramificação e fusão

Os dois comandos finais com os quais você precisará se familiarizar lidam com ramificações e mesclagens. Como eu disse acima, trabalhar em um branch mantém a base de código principal segura e, uma vez que todas as suas alterações estiverem ótimas, você poderá mesclar tudo novamente.

Eles podem ser um pouco complicados, então pode ser preciso apenas alguns estímulos para fazê-los jogar bem.

• git checkout -b “branch1” - Este comando criará um novo branch que você designará e mudará para ele como seu branch de trabalho. Ele combina os comandos git checkout e git branch em uma linha de código acessível.
• touch awesome.html - este é apenas um comando de preenchimento para criar um novo arquivo html que irei mesclar de volta ao mestre.
• E como antes, você obterá status, git add awesome.html, git commit -m “create awesome.html”
• git status novamente permitirá que você veja se tudo está como deveria ser.

Se você tentar empurrá-lo antes de mesclar, receberá uma mensagem de que precisa definir a origem do repo. Origem é uma convenção de nomenclatura estranha para o que seu computador considera o repositório remoto. Então, basicamente, você está apenas dizendo que, sim, não há problema em enviar esse branch para o Github como fez com o master. Aqui está um bom tópico sobre a origem do git do Stack Overflow.

Com isso resolvido, ele dirá que foi para branch1 -> branch1.

Você pode voltar para o branch master com git checkout master (não há checkout -b desta vez porque você só usa isso na criação de um novo branch, não na troca. Misturei meus comandos na imagem abaixo e tentei git branch master . Não teve sucesso porque o mestre já existia.

• git status - como sempre.
• git merge branch1 - Como tudo naquele branch está bem, podemos prosseguir e mesclar.
• Se obtivermos status novamente, veremos que estamos à frente de origin / master em 1 commit. Isso significa que não enviamos todas as alterações que fizemos ao Github.
• git push para sincronizar as coisas!

Verifique sua conta do Github - você verá que tudo o que você fez está refletido nela. Você pode ver as diferentes mensagens de commit, número de branches e commits que fizemos, bem como quaisquer contribuidores para o repo e o que eles fizeram também.

E é isso! Parabéns! Você acabou de balançar seu fluxo de trabalho básico do git. Você pode fazer muito, muito, muito material mais complexo do que isso com git, mas isso é muito perto do que você provavelmente vai usar em uma base diária quando você é apenas ... gitting começou.

Oh, mais uma coisa!

O Github Repo, myfirstrepo , que usei para este artigo ainda está ativo . Sinta-se à vontade para conferir, brincar com ele, fazer um fork, clonar ou o que você achar que vai fazer você se acostumar a usar o git. Divirta-se! (E obrigado por ter paciência comigo e todos os meus trocadilhos idiotas.)

Imagem em miniatura do artigo por MchlSkhrv / shutterstock.com