Já leu a primeira parte desse artigo?
No primeiro artigo aprendemos sobre como funciona o Git, como iniciar um projeto e como inserimos os arquivos que serão controlados pelo sistema.
Status
Antes de tudo você precisa entender em qual status os arquivos se encontram. Você pode modificar um arquivo, mas não commita-lo. Veja abaixo uma imagem direto do site do Git que mostra os diversos status dos arquivos.
Você já clonou ou iniciou seu projeto no Git e agora vai fazer modificações nos arquivos e enviar essas modificações para o repositório. Lembre-se que os arquivos em seu Work Directory podem estar traked ou untracked. Vou manter os termos em inglês para você se familiarizar melhor. Arquivos com status tracked são arquivos que já estão inseridos no repositório. Eles podem ser unmodified (que não foram modificados por você), modified (que foram modificados por você) ou staged (que são os arquivos que acabaram de ser mudados).
Esse ciclo é repetido diversas e diversas vezes. Veja abaixo um exemplo:
Commit
Suponha que você resolveu um bug no projeto. É hora de commitar suas modificações. Essas modificações serão inseridas no histórico do projeto e ficarão disponíveis para que os outros integrantes da equipe.
Ao commitar você escreve uma descrição sobre o que foi feito ali. Assim essa modificação não fica perdida e todo mundo sabe do que se trata aquela mudança. Você documenta essa mudança. É mais ou menos isso que é o commit.
Quando você commita uma modificação, os arquivos editados saem do status staged e voltam para o status unmodified. Claro, por que teoricamente aquela alteração já foi feita e agora os arquivos voltam com o status de sem modificações.
O comando é este:
Se você fizer um git log no projeto, você consegue visualizar uma lista de todos os commits enviados para o projeto, seus commits e commits de outros integrantes. Veja abaixo:
Pull
Não é só você que está fazendo modificações nos arquivos, mas também sua equipe. Por isso é importante que você deixe o projeto sempre atualizado. Para isso você precisa trazer as modificações que eles fizeram e commitaram para o seu repositório local. Você vai usar o comando pull para trazer essas modificações:
Feito isso vai até o servidor buscar todas as modificações a partir da versão do seu repositório local, ele vai baixar essas modificações e fará um merge automático nos arquivos necessários que foram modificados. Coisa linda… alguém deve ter modificado o mesmo arquivo que você, o Git vai entender isso e vai juntar seu código com o dele, automaticamente… Claro que pode ser que de conflitos caso vocês tenham modificado a mesma linha, mas aí é outra história, vemos mais pra frente como resolver isso. Se quiser se adiantar, procure sobre o comando diff.
Push
Você modificou os arquivos, commitou descrevendo o que fez exatamente naquela modificação e agora precisa enviar tudo isso para o servidor. O comando git push empurra as suas modificações para o servidor, incluido-as no histórico do projeto. Quando os outros integrantes da equipe fizerem um git pull, essas modificações serão baixadas e incluídas no repositório local da pessoa.
O Git Push só pode ser feito se você executou o git pull antes. Isso é uma forma de você ter o seu repositório atualizado e também para evitar possíveis conflitos no projeto. Quando você faz o pull, se der algum conflito de código, você deverá resolve-los para depois enviar o novo código novamente.
Há algumas outras opções tanto no Pull e no Push que podemos utilizar para especificar o branch para onde iremos empurrar ou buscar atualizações. Mas isso fica para outra hora.
A documentação do Git é muito fácil de ler e entender. É bem objetiva e não perde tempo blá blá blá… Recomendo que você leia e entenda melhor como utilizar o git nos seus projetos. Nada de FTP, SFTP e outras coisas… Isso é coisa do passado.
Veja um vídeo que mostra os comandos básicos do GIT: