./adote-um-dev.sh
Nível: n00b
Agenda
Antes de mais nada...
Configuração
Para configurar a ferramenta, precisamos colocar seu nome e email que aparecerão nos commits. Mas antes de configurar localmente na máquina, crie uma conta no https://github.com/ para definir o nome e email.
Colocou uma fotinha de perfil? Massa! Agora coloca uma descrição e as demais informações, é importante manter seu repositório apresentável.
Bom, já temos o que precisamos. Segue pra baixo aí!
Configuração
Vamos configurar o git localmente. Abra teu terminal aí e digita os seguintes comandos:
git config --global user.name "SEU NOME"
git config --glboal user.email seu_email@aqui.com
Pra gente ver que deu tudo certo, confere digitando:
git config --list
Com o git configurado e a conta no GitHub criada, vamos criar nosso primeiro repositório.
Meu primeiro repositório
Abra seu terminal e crie uma pasta chamada "repos" em algum local de fácil acesso via terminal.
*Dica: eu utilizo o desktop
mkdir repos
cd repos
Agora, no GitHub, vá na página inicial e clique no local abaixo:
Meu primeiro repositório
Você será direcionado para essa página:
Siga as informações e vai dar tudo certo :)
Meu primeiro repositório
Nosso repositório foi criado! E recebemos algumas instruções:
Meu primeiro repositório
Vamos analisar cada uma das opções. Opção 1:
Nessa primeira, ele cria um arquivo README, inicia o repositório git e adiciona o link remoto no repositório que acabamos de criar. Normalmente, essa é a melhor opção para iniciar um projeto do zero, e é a que vamos utilizar agora.
Antes, vamos entender as outras...
Meu primeiro repositório
Opção 2:
Percebeu alguma semelhança com o anterior? Os últimos comandos são os mesmos! Ele apenas adiciona o link do nosso repositório remoto como referência. Essa é a opção para um projeto que já existe e que já possui um repositório local funcionando.
*Dica: criamos repositórios locais, sem referência, através do comando "git init"..faremos isso na prática.
Meu primeiro repositório
E, opção 3:
E essa última opção serve para "migrar" um repositório Subversion, Mercurial ou TFS para o Git. Nunca utilizei e espero que nem precise hahaha
Meu primeiro repositório
Voltando pra primeira:
Antes de digitar esses comandos, crie uma nova pasta com o mesmo nome do repositório (é uma boa prática). Depois, siga o passo a passo e atualize sua página no GitHub.
Meu primeiro repositório
Olha quem apareceu!
Parabéns! Você criou seu primeiro repositório local e remoto!
Link do meu: https://github.com/cicatrizwp/meu-repositorio
Meu primeiro commit
Você pode não ter percebido, mas também deu seu primeiro commit e seu primeiro push. Porém, vamos fazer novamente, sem ser de forma automática.
Crie um diretório, dentro da sua pasta com o repositório do git, chamada "pasta-commit" e em seguida adicione um arquivo de texto no formato .md com o título "arquivo-commit.md" contendo a frase "eu fiz um commit".
mkdir pasta-commit
cd pasta-commit
echo "eu fiz um commit" >> arquivo-commit.md
Meu primeiro commit
Você deve ter recebido uma mensagem como a minha, e vamos entender o que isso significa. Continua pra baixo :D
cd ..
git status
Meu primeiro commit
O git trabalha com nossos arquivos em 3 fases:
Resumindo, o fluxo de um push seria:
git add <arquivos ou . para todos>
git commit -m "mensagem"
git push
Meu primeiro commit
Quando damos o "git status" e os arquivos aparecem na cor vermelha (no caso acima), significa que esses arquivos não estão sendo observados pelo git e se quisermos que eles sejam, precisamos digitar o "git add".
Fazendo isso no nosso repositório:
A cor e a mensagem mudaram...
Meu primeiro commit
Agora, nossos arquivos estão sendo observados pelo git e podem ser commitados. Vamos commitar! Utilize:
Commit criado! Agora ele diz que nossa branch local está 1 commit na frente da branch remota, e para utilizarmos o "git push" para publicar as alterações.
git commit -m "estou fazendo um commit"
Meu primeiro push
Se não tiver mais trabalho a ser feito, podemos fazer nosso push e atualizar a branch remota com a nossa local
Deu tudo certo. Vamos verificar no GitHub?
git push origin master
Meu primeiro push
Tá lá nossa pasta e nosso novo commit!
Minha primeira branch
Criamos nossa branch e reparem: o terminal alterou onde estava o (master) para o título da nossa branch (minha-branch).
Essa branch só existe localmente. Vamos dar um push nela para refletir no nosso repositório remoto.
Opa! Parece que ela foi criada com sucesso.
Minha primeira branch
Atualizando o GitHub:
Minha primeira branch
Agora temos uma branch paralela a branch master, onde podemos fazer quantas alterações quisermos que ela não vai refletir na nossa master.
Vamos começar criando uma nova pasta chamada "pasta-branch", contendo um arquivo "arquivo-branch" no formato .md e com a frase "essa arquivo veio da branch" dentro dele.
mkdir pasta-branch
cd pasta-branch
echo "esse arquivo veio da branch" >> arquivo-branch.md
Volta uma pasta, e faz o commit disso tudo e dá um push pra "minha-branch".
cd ..
git add .
git commit -m "commit na branch"
git push origin minha-branch
Meu primeiro merge
Fizemos o push na branch, voltamos no GitHub:
Meu primeiro merge
Apareceu uma opção para fazermos um "compare & pull request". Além disso, repare que estamos visualizando a branch "master" e lá nossa pasta "pasta-branch não existe.
Trocando a master pela minha-branch, conseguimos visualizar. Vamos agora colocar o conteúdo da "minha-branch" dentro da "master".
Meu primeiro merge
Para submeter um Merge/Pull Request, volte para a página principal do seu repositório no GitHub e clique na aba "Pull Request". Depois, procure pelo botão "New Pull Request".
Meu primeiro merge
O fluxo do pull request no GitHub é um pouco diferente dos outros serviços. A branch da ESQUERDA é a branch de destino e a DIREITA é a branch com as alterações. Seguindo essa lógica, vamos selecionar a "master" como destino e a "minha-branch" como a de alterações.
Meu primeiro merge
Ao selecionar nossa branch com as alterações, repare que a página atualizou. É possível visualizar e revisar as alterações que fizemos, antes de submeter o request.
Meu primeiro merge
Se estiver tudo certo, clique no botão "Create pull request". Ele te levará para a página final, onde você tem algumas opções como uma caixa descrição para resumir o que foi feito, colocar label na alteração, atribuir a alguém, dentre outras coisas.
Meu primeiro merge
Agora, clique no botão "Create pull request" para abrir o request. Na nova página que será aberta, é possível visualizar se houve algum conflito ou comentário de algum outro dev sobre as alterações. Para submeter o request, clique em "Merge request" e as alterações serão integradas na branch master.
Meu primeiro merge
Extra: o merge nos permite escolher 3 modos de integrar as alterações.
1. Commit de merge;
2. Squash diretamente na branch destino;
3. Rebase na branch destino;
A escolha deles depende do seu padrão de projeto. Por padrão, vamos ficar com a primeira que cria um novo commit de merge.
Meu primeiro merge
Depois do merge, tudo fica bonito e azul. As alterações agora estão na nossa branch master remota.
Mantendo o repositório atualizado
Mais importante que submeter as alterações, é manter o repositório local e remoto sincronizados. Nesse momento nós fizemos o merge para nossa branch "master" REMOTA, mas a nossa local ainda está desatualizada. Veja:
Mantendo o repositório atualizado
Para atualizar os dados do nosso repositório remoto, utilizamos o comando "git fetch".
Mas o fetch sozinho só atualiza as referências, ele não atualiza os arquivos. Falta alguma coisa...
Mantendo o repositório atualizado
Com as referências atualizadas, agora podemos pegar os arquivos. Existem algumas formas de fazer isso:
Você vai obter o resultado desejado com qualquer um daqueles comandos. Cada um funciona de uma forma, e por questões de segurança vamos ficar com o primeiro deles.
git pull --all
git rebase origin/<nome-da-branch>
git reset --hard origin/<nome-da-branch>
Mantendo o repositório atualizado
Algumas pessoas podem falar que o "git pull" já faz o fetch e ao mesmo tempo atualiza os arquivos. Sim, e realmente é isso que acontece. Mas por questões de segurança, eu gosto de rodar o fetch separado para evitar CONFLITOS de arquivo durante um pull.
Conclusão
Hoje nós brincamos um pouco com git, configuramos, vimos os principais comandos e ainda fizemos um exemplo do ZERO, com direito a merge request.