Git para Iniciantes
O Git é um sistema de controle de versão. O Git é muito poderoso, mas também complexos. É preciso entender alguns conceitos básicos para conseguir trabalhar com ele. O Git é um sistema de controle de versão distribuído.
-
Arquitetura distribuída.
-
Cada desenvolvedor possui seu próprio repositório local.
-
Commit são operações locais que só afetam o seu repositório.
-
Branches são linhas evolutivas independentes do software
-
Merges são operações de união entre Branches
A sequência de trabalho é a seguinte:
Operação |
Explicação |
clone |
Importa o projeto |
edit |
Edita os arquivos |
difftool |
Visualiza suas alterações |
add |
Seleciona o que vai pro commit |
commit |
Salva no repositório local |
pull |
Baixa alterações do servidor |
mergetool |
Resolve conflitos |
push |
Envia alterações para o servidor |
O Git enxerga um repositório como um grafo de commits. Cada commit é identificado pelo hash de seu conteúdo. Por exemplo, um repositório que tem 5 commits no branch master e mais 2 commits no branch develop seria assim:
Os nomes em azul são '''hashs''' que identificam os commits. Os nomes em amarelo são '''refs''' que identificam os branches. '''HEAD''' é um ponteiro especial que indica em que lugar do repositório você está.
Os arquivos sob controle do Git podem estar em uma dessas áreas:
- Working Directory
-
Aqui estão os arquivos que você vê em seu disco. As alterações que você fizer, irão alterar os arquivos que estão aqui.
- Staging Area
-
Aqui estão as alterações selecionadas para o próximo commit. Sempre que você edita um arquivo e usa o commando add, as alterações feitas por você são escritas em um arquivo especial do Git chamado '''index'''. Mesmo que você perca ou apague o arquivo que você modificou do seu Working Directory, as alterações que você adicionou à Staging Area não são perdidas, pois já foram salvas no index usando um formato especial do Git. Sendo assim, você ainda poderá fazer commit dessas alterações.
- Local Repository
-
Essa área representa seu repositório. Quando você faz commit das suas alterações, é aqui que elas ficam salvas. Lembrando que seu repositório é um grafo e a ponta do grafo que você enxerga (e onde você faz commit) é determinada pelo ponteiro HEAD.
- Remote Repository
-
O seu repositório local pode conhecer outros repositórios com os quais ele conversa, são os '''remotes'''. Quando você faz clone de um projeto, seu repositório automaticamente lembrará do remote de onde ele clonou sob o nome de '''origin'''. Os branches de origin estarão disponíveis sob os refs origin/master e origin/develop (supondo que esse branch também existe em origin).
Aqui vamos explicar alguns dos comandos mais comuns do Git.
Após baixar e instalar o programa, você deve ajustar algumas configurações. Use o comando '''config''' para editar suas prefências. Configure seu nome e email como no exemplo abaixo, substituindo pelas suas informações.
$ git config --global user.name "Nome Sobrenome" $ git config --global user.email [email protected]
O Git usa os programas padrão para editar arquivos, fazer diff e merge no terminal. Caso você queira usar outros programas, pode trocá-los usando comandos como esses do exemplo:
$ git config --global core.editor nano $ git config --global diff.tool meld $ git config --global merge.tool meld
Se você não conseguir usar algum comando, peça ajuda ao Git. Para ver a ajuda do Git, use o comando '''help'''. Para obter ajuda para um comando específico use help + nome do comando. Exemplos:
$ git help ... $ git help reset ...
Para importar um projeto, usando o comando clone. O comando '''clone''' cria um repositório local a partir de um repositório remoto. Por exemplo, para clonar o projeto chamado bomberman, entre na pasta que deseja clonar o projeto com o comando cd, depois digite:
$ git clone https://github.com/ecsb/ecsbomberman.git Cloning into 'bomberman'... done.
Para ver os arquivos alterados, use o comando '''status'''.
$ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: file1 # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: file2 #
O Git vai lhe dizer em qual branch você está, as alterações que você tem na Staging Area e no Working Directory.
Para executar sua ferramenta de diff preferida, use o comando '''difftool'''.
$ git difftool -y ...
O git irá chamar o programa de diff configurado para cada arquivo modificado. Por padrão, o git pergunta para cada arquivo se você quer ver o diff, a opção '''-y''' evita tantas perguntas.
Use o comando '''add''' para incluir alterações do Working Directory para a Staging Area.
$ git add .
Note que o comando adiciona apenas um arquivo, mas opera de forma recursiva, portanto selecionando o diretório raiz do repositório seleciona todas as alterações.
Use o comando '''commit''' para salvar as alterações selecionadas no Local Repository. O editor que você configurou será aberto para que você escreva uma mensagem de commit.
$ git commit -a [master 7862799] Mostrando no tutorial. 2 files changed, 2 insertions(+)
Se você adicionou um arquivo na Staging Area e quer desfazer essa adição (o arquivo continuará modificado no Working Directory, mas não entrará no próximo commit), use o comando '''reset'''.
$ git reset -- .
O commando opera de forma recursiva (assim como add).
Mas se o que você quer é descartar completamente as alterações, fazendo com que os arquivos no Working Directory e na Staging Area fiquem iguais ao do repositório, use o comando '''checkout'''.
$ git checkout -- .
Mais um comando recursivo. Você pode fazer checkout de um único arquivo ou, estando na raiz do repositório, fazer checkout de '''.''' (o diretório atual), que irá desfazer todas as suas alterações. Os arquivos ficarão iguais aos de HEAD, caso HEAD aponte para master, por exemplo, eles ficarão iguais eram no último commit de master.
Note que isso irá reverter as alterações de todos os arquivos que existem no repositório. Se você criou um arquivo novo, o git não irá mexer nele.
Para descartar as alterações de arquivos que o git ainda não conhece utilize git clean.
$git clean
Limpa o working tree recursivamento removendo arquivos que não estão versionados. Normalmente apenas arquivos desconhecidos pelo Git são removidos, mas com a opção -x especificada, também arquivos ignorados serão removidos. Ao utilizar git clean -x arquivos do projeto Eclipse serão removidos.
Use o comando '''push''' para enviar os commits do seu repositório para um remote.
$ git push ... To /Users/fulano/server/myproj.git 7d2ca00..7862799 master -> master
Se você não especificar pra qual remote o push será enviado (como em: git push <remote>) o remote padrão (origin) será usado. O push sempre enviará o ref apontado por HEAD para o ref de mesmo nome em remote, repare na última linha onde diz "master → master".
Para baixar as alterações presentes em repositórios remotos, use o comando '''pull'''.
$ git pull Receiving objects: 100% (29/29), done. Resolving deltas: 100% (4/4), done.
Se você não especificar de qual remote baixar as alterações (como em: git pull <remote>), o remote padrão (origin) será usado.
Se você possui commits locais e há commits novo no repositório remoto, o git tentará fazer um merge automático das duas alterações. Em caso de sucesso, ele criará um novo commit com o resultado do merge. Esse novo commit aparecerá no grafo do git com dois commit "pais". Para evitar tantas bifurcações no grafo, você pode usar a versão '''pull --rebase'''.
$ git pull --rebase First, rewinding head to replay your work on top of it... Applying: little fix Applying: forgot to push this
O git irá voltar o branch atual para antes dos seus commits locais, receber todos os commits remotos (sem conflitos) e depois reaplicar seus commits. Assim, o grafo de commits ficará linear, sem conflitos e sem merges. Mas cuidado, '''use rebase apenas se suas alterações forem bem simples''', ter que resolver um rebase no qual o git não conseguiu aplicar suas mudanças é pior do que resolver um merge.
Quando você faz um pull, as alterações em seu repositório podem conflitar com as que você está baixando. O Git vai lhe informar com uma mensagem de conflito. Exemplo:
$ git pull ... CONFLICT (modify/delete): file3 deleted in 71aaadae7b93f00340962b307121f4a5c99d88a5 and modified in HEAD. Version HEAD of file3 left in tree. Auto-merging file2 CONFLICT (content): Merge conflict in file2 Automatic merge failed; fix conflicts and then commit the result.
Se você baixou um programa de merge e configurou seu Git conforme mostrado anteriormente, poderá usar o comando mergetool. O comando '''mergetool''' lhe perguntará o que fazer para cada arquivo com alterações conflitantes após um pull ou merge.
$ git mergetool -y
...
Normal merge conflict for 'file2':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (meld):
...
Deleted merge conflict for 'file3':
{local}: modified file
{remote}: deleted
Use (m)odified or (d)eleted file, or (a)bort? <font color="brown">m</font>
Não esqueça de fazer commit após o merge.
Sempre use a ajuda do Git: "git help"
Leia este excelente livro online: http://progit.org/book/
Procure mais documentação na página oficial: http://git-scm.com/documentation
Boa sorte.