MDM Studio | Responsive Design
Compartilhe esta notícia no Facebook

Entendendo o GIT - Uma breve introdução ao mundo do controle de versão

Após estudar um pouco sobre o GIT, achei que seria legal criar um artigo contendo os principais assuntos relacionados ao tema.

Entendendo o GIT: uma breve introdução ao mundo do controle de versão

Como, no momento, usamos Mac, não vamos fazer grandes abordagens para o pessoal de Linux e Windows, mas acreditamos que grande parte do processo possui o mesmo funcionamento. Basta a pessoa possuir algum conhecimento em seu sistema operacional favorito, e tudo deve se resolver!

VCS: Version Control System

Antes de iniciar o tema 'GIT', precisamos mencionar sua finalidade: controle de versão. Um sistema de controle de versão, em sua maior parte (99%) é utilizado para manutenção de código fonte, portanto podemos chamar os VCS de ferramenta de código fonte (ou SCM - Source Code Management), que, no fundo significam basicamente a mesma coisa.

Aquele 1% safadão: Algumas situações em que o controle de versão é aplicado (que não seja em código fonte):

  • Nomeação de arquivo: orcamento_v1.xls, logo_2.gif
  • No Microsoft Word: histórico de alterações
  • Histórico de alterações do Photoshop
  • Wikis: Wikipedia, por exemplo, mantém uma relação de alterações feitas nos artigos no decorrer do tempo
  • Desfazer (CMD + Z): Todos os comandos de “desfazer” - usados em computador, são exemplos de controle de versão

Ou seja, um controlador de versão mapeia as modificações feitas em arquivos (textos) e permite voltar ou avançar nestas modificações (voltar ou avançar o tempo). Alguns de forma mais primitiva, outros bastante complexos.

História dos controles de versão (antes do GIT)

Alguns não eram tão funcionais, mas pioneiros em controle de versão.

História dos controles de versão (antes do GIT)
  • SCCS (source code control system): 1972, código fechado (vinha nos Unix)
  • RCS (Revision control system): 1982, open source
  • CVS (concurrent versions system): 1986-1990, open source
  • Apache subversion (SVN): 2000, open source (o mais popular durante muito tempo até o GIT aparecer)
  • BitKeeper SCM: 2000, código fechado, privado, pago a nível de empresa e livre para a comunidade, porém, depois de alguns anos passou a ser cobrado (2005) - perdendo popularidade.
  • Foi quando o GIT apareceu, na tentativa de ser um substituto melhor ao BitKeeper e gratuito. Totalmente reformulado e com uma nova proposta. Compatível com Linux, Mac OS X, Solaris e Windows

Quem deve usar o GIT?

  • Qualquer um que deseje:
    • Revisar históricos de mudanças realizadas
    • Verificar diferenças entre versões
    • Recuperar versões antigas
  • Qualquer um que precise compartilhar trabalhos com uma equipe
  • Pessoas que não tem medo de “codar na unha”
  • Programadores e desenvolvedores

Quem não deve usar o GIT?

Quem deseja controlar arquivos que não possuem texto puro (non-text files): Imagens, filmes, musicas, fontes

Mesmo nestes casos, o GIT funciona, porém você não vai consegue rastrear diferenças internas nos arquivos, só em seus nomes. O GIT não consegue acessar o arquivo e comparar diferenças internas.

Porque usar um sistema de controle de versão? O controle de versão é um sistema que registra as mudanças feitas em um arquivo ou um conjunto de arquivos ao longo do tempo de forma que você possa recuperar versões específicas. Se você é um designer gráfico ou um web designer e quer manter todas as versões de uma imagem ou layout (o que você certamente gostaria), usar um Sistema de Controle de Versão (Version Control System ou VCS) é uma decisão sábia. Ele permite reverter arquivos para um estado anterior, reverter um projeto inteiro para um estado anterior, comparar mudanças feitas ao decorrer do tempo, ver quem foi o último a modificar algo que pode estar causando problemas, quem introduziu um bug (e quando), e muito mais. Usar um VCS normalmente significa que se você estragou algo ou perdeu arquivos, poderá facilmente reavê-los. Além disso, você pode controlar tudo sem grandes esforços.

Diferença entre o GIT e os outros controladores de versão

Pacotes de mudanças: o GIT se concentra nisso. Pega os pacotes de mudanças e une-os transformando em um arquivo único e atualizado. Numa equipe, é muito importante trabalhar com o GIT, cada um fazerdo o seu papel e, no fim, todos possuem os arquivos mais atualizados e documentados.

E você não precisa, necessariamente, estar conectado à internet. Pode ir criando pacotes GIT de seus projetos e recuperando localmente e, quando desejar, enviar tudo para um repositório remoto (servidor)

Conhecendo um pouco da história do GIT e controladores de versão, veremos como fazer tudo funcionar

Instalando o GIT no MacOS

  1. http://git-scm.com/download/mac
  2. Faça o download do software, abra e instale em sua máquina
  3. Abra o terminal (CMD + Space digite Terminal)
  4. No terminal: which git (deve retornar o caminho onde o GIT está instalado)
  5. No terminal: git --version (deve retornar a versão instalada do GIT)
Funcionou? Então você tem o GIT instalado.

Configuração inicial do GIT (basicão, mas necessário)

É possível fazer configurações em até 3 níveis no GIT: nível de sistema (/etc/GITconfig), nível de usuário (~/.GITconfig), nível de projeto (projeto/.GIT/config). Elas vão determinar como o GIT vai se comportar em cada nível.

Os arquivos e pastas do GIT, geralmente, são escondidos (dot files). Você precisa habilitar o seu sistema operacional para exibir arquivos e pastas ocultas.

Após fazer o download e testar o GIT, devemos inicia-lo.
Todos os comandos GIT devem ser escritos depois que o GIT foi iniciado (GIT init)

  1. No terminal: git config --global user.name "seu_nome" (Configura o GIT com seu nome)
  2. No terminal: git config --global user.email "seu_email" (Configura o GIT com seu e-mail)
  3. No terminal: git config --list (Verifica as alterações salvas de uma forma geral)
  4. No terminal: git config user.email (Verifica as alterações salvas em uma propriedade específica, no caso "email")
  5. No terminal vá até a raiz de seu sistema
  6. No terminal: ls -la (Localiza o arquivo .gitconfig - que armazenou as alterações que você acabou de fazer)

[plus] Coisas legais que melhoram sua experiência em utilizar o GIT

  1. Definir qual é o editor / software padrão que vai exibir os arquivos GIT
  2. Colorir o código GIT, separando melhor as informações
    • No terminal: git config --global color.ui true
  3. Auto Completar códigos GIT (usuários do windows já possuem esta funcionalidade)
    • Faça o download do Patch
    • No terminal: cd ~ (para acessar a raiz)
    • No terminal: curl -OL https://github.com/git/git/raw/master/contrib/completion/git-completion.bash (baixa o patch)
    • No terminal: mv ~/git-completion.bash ~/.git-completion.bash (renomeia o arquivo, tornando-o um "dot file")
    • No terminal: nano ~/.bash_profile (abre o arquivo em modo de edição)
    • Adicione o código: if [ -f ~/.git-completion.bash ]; then source ~/.git-completion.bash fi (comando Shell)
    • Salve: ^O [WriteOut] e feche: ^X [Exit]

Alguns termos utilizados em GIT

  • Repository: local onde ficam os arquivos, versões e históricos (sua máquina, servidor remoto etc)
  • Commit: Coleção de alterações realizadas (transforma as alterações recentes que vc fez em um projeto num pacote que pode ser acessado quando necessário, voltando no tempo. Alguns comparam com um “checkpoint” - que faz muito sentido para quem joga video games)
  • Branch: são as "partições" do projeto - cada branch pode conter features separadas do projeto (e podem ser unidas futuramente)
  • Fork: Quando vc pega os arquivos disponíveis (a última versão, por exemplo) e inicia uma nova coisa com ela. Um projeto que pode ser utilizado em outras situações, com um novo nível de detalhamento (que pode ser iniciado de uma branch, de um pacote).
  • Merge: Junta todos as branchs e/ou commits (todos os pacotes versionados até então) num único arquivo master. Mas mantém o controle de versão (históricos) e permite voltar atrás.
  • O Rebase faz a mesma coisa que o "merge" faz, porém, unifica tudo num único arquivo master e finalizado e inicia o processo de versionamento novamente.
  • Pull Request: Você avisa, via admin (no GitHub, por exemplo) que tem alguma coisa a colaborar no projeto e aguarda até que alguém te conceda acesso ao código.

Iniciando um repositório GIT

Agora que as configurações estão corretas e você instalou uns extras, vamos colocar o GIT para funcionar.

  1. Crie um projeto qualquer, onde você desejar
  2. No terminal vá até a pasta de seu projeto (exemplo: cd/documentos/projetos/novo_projeto
  3. No terminal: git init (inicia o GIT em seu projeto)
    • Sendo assim, tudo o que for enviado para o GIT, vai ficar listado e documentado nessa pasta .git (oculta) que acabou de ser criada na pasta do projeto.
    • Importante: A pasta .git é uma pasta de sistema e você não deve alterar sua estrutura e os arquivos la dentro. A única coisa que pode ser ajustada é a pasta config (que são as configurações git a nível de projeto).
  4. Crie um arquivo dentro de seu projeto (de preferência texto, html, js, css, php)
  5. No terminal: git status (Verifica o status dos arquivos antes de adiciona-los ao staging index)
  6. No terminal: git add . (adiciona todos os arquivos novos a um estágio chamado staging index)
    • O staging index é uma espécie de nível intermediário entre o sua máquina e o que deve entrar no pacote de versão GIT
    • O git add . adiciona todos os novos arquivos ao staging index
    • O git add arquivo.html adiciona somente "arquivo.html" ao staging index
  7. No terminal: git status (Verifica o status dos arquivos após de adiciona-los ao staging index)
  8. No terminal: git commit -m "titulo_do_commit" -m "descricao_completa_do_commit" (Versiona/cria snapshots/manda pro repositório o que está no staging index)
    • Cada commit gera um checksum: número/ID que identifica o commit. Fundamental para localizar e manter todo o ambiente funcionando.
    • Geralmente o GIT utiliza o algoritmo SHA-1 para criar esses números.
  9. Ao aplicar o commit, você criou um pacote de versão. Ou seja, criou uma espécie de "nó" que permite separar os arquivos que estão neste commit, dos arquivos que estavam no commit anterior)
  10. No terminal: git log (Exibe o log dos commits realizados, suas IDs e títulos)

A arte de escrever mensagens de commit.

Há boas práticas para isto, afinal, as pessoas precisam entender direitinho o que cada pacote representa em relação ao projeto. São elas:

  • Tente fazer commits agrupados, de assuntos relacionados.
  • Mantenha o título pequeno (menos de 50 caracteres)
    • É possível complementar com uma mensagem maior, mais detalhada (72 caracteres), mas o título deve ser pequeno
  • Escreva no tempo verbal “presente”, não no passado
    • Escreva, por exemplo, “Correção de Bug” ao invés de “Bug Corrigido”
  • Se for necessário escrever itens em lista, utilize hífens ou asterisco
  • Adicione “track points”, caso a correção venha de um chamado (ticket de suporte)
    • Escreva, por exemplo, “[#3456] Correção de Bug”
    • Também é conveniente especificar arquivos e tipo de linguagem quando a correção é muito específica: “[CSS] Correção de Bug na Responsividade”
  • Crie padrão de títulos fáceis para sua equipe entender. Seja claro e auto explicativo
    • Exemplo de titulo ruim: “Atualização no código de login”
    • Exemplo de titulo bom: “Troca da autenticação padrão para Facebook Connect”
  • Não escreva orientações para determinada pessoa ou equipe no título. Deixe isto para uma mensagem de e-mail.

Branches

Branches

Uma branch representa uma linha de desenvolvimento independente, por isto, criar "branches" usando o GIT facilita a compreensão do projeto de um modo geral. Ao desenvolver uma nova feature, é uma boa prática criar uma nova branch. Ela, basicamente, separa em partes o que cada pessoa está desenvolvendo e, futuramente, permite que tudo se junte na branch principal

Branches são democráticas! Não necessitam muito espaço em disco, não exigem recurso top em infra estrutura, são leves, são fáceis de gerenciar (apagar, criar, atualizar), são flexíveis e permitem que façamos testes nos arquivos sem perder o projeto (caso algo dê errado). Para adicionar uma nova branch, no terminal git branch nome_da_branch Veja mais comandos relacionados a branches

Gitignore

Ignora arquivos que você não quer que sejam trackeáveis ou incluídos no projeto para todos da equipe

Gitignore

Os arquivos fonts, documentos, pdfs, imagens, pasta de uploads, pasta de registros automáticos, arquivos de sistema, exe e outros arquivos que fazem parte do projeto mas não sofrem atualizações constantes e não necessitam estar nas branches / commits. É necessário atualizar um arquivo chamado .gitignore (que pode ser criado a nível de projeto ou a nível global)

  • Crie o arquivo, no terminal: nano .gitignore (em nível de projeto) ou no terminal vá até a raiz e digite nano .gitignore_global (em nível global, para todos os projetos)
  • No terminal: vá até a pasta raiz do GIT: nano .GITignore_global (a nível global)
    • A nível global é necessário executar mais um passo:
    • No terminal: git config --global core.excludesfile ~/.gitignore_global
  • No arquivo que se abriu, digite os arquivos que você deseja ignorar (salve e feche)
  • Obs: não ignore o arquivo .gitignore (ele precisa fazer parte dos commits)

Dicas de como utilizar o .gitignore

  • *.txt (ignora tudo que tem a extensão txt)
  • # é um comentário (a linha é ignorada)
  • .DS_Store (arquivo padrão do MacOS)
  • pasta/*.zip (ignora os zips de uma determinada pasta)
  • pasta/videos (ignora tudo dentro desta pasta)
  • !pasta/videos/video_*.mp4 (ignora tudo dentro da pasta, menos os arquivos com nome “video_” + qualquer coisa + “.mp4”)
  • log/*.log[0-9] (ignora os arquivos de log terminados com “log” + números de 0 a 9)

Usando o GIT remotamente (repositório remoto)

Usando o GIT remotamente (repositório remoto)

É possível trabalhar normalmente em seu computador, sem estar conectado a uma rede ou enviar os arquivos do projeto para um servidor, porém, esse controle de versão se torna ainda mais poderoso e eficaz quando subimos os arquivos para a rede (um servidor GIT) e compartilhamos com outras pessoas (outros membros da equipe, ou como você mesmo, em forma de backup)

O que você precisa saber:

  • O processo de subir os arquivos para os servidor chama-se push
  • O processo de recuperar arquivos do servidor para a máquina chama-se fetch
  • O processo de colocar o arquivo (que antes estava no servidor), em sua master branch local (mesclar/unir) chama-se merge

Para aproveitar dos benefícios de usar um repositório remoto, é necessário criar uma conta em um servidor GIT (GitHub, GitLab, Bitbucket)

  • Criar uma conta no GitHub (o mais conhecido servidor GIT)
  • Grátis e os upgrades para planos com mais benefícios são baratos
  • Os planos gratuitos são abertos para todos, ou seja, qualquer um pode recuperar arquivos postados nestes repositórios gratuitos
  • Se desejar um repositório privado, basta assinar um plano (individual ou empresarial) de acordo com sua necessidade
  • Possui uma série de recursos bacanas para quem trabalha com GIT
  • Faça o cadastro no website, escolha o plano desejado e crie um repositório

Enviando seus commits / branches a um repositório remoto

Em sua página GitHub (clicando em seu repositório), recupere a URL do arquivo em: Clone or Download copie a URL informada.

  • Criando um repositório remoto
    • Exibe os repositórios remotos (previamente configurados), no terminal: git remote
    • Adicione um repositório, no terminal: git remote add nome_dado_ao_servidor url_do_repositorio_remoto
    • Consulte o novo repositório, no terminal: git remote
    • Exibe mais detalhes do repositório, no terminal: git remote -v
    • Remover um repositório, no terminal: git remote rm nome_dado_ao_servidor
  • Enviando os arquivos
    • No terminal: git push -u nome_dado_ao_servidor nome_da_branch
      • Se solicitar, informe usuário e senha da sua conta no servidor
      • Se der algum erro, pode ser que você tenha que fazer o download do seu repositório atual hospedado (no exemplo o GitHub) e depois fazer um novo commit.
      • Para fazer o download do repositório atual, no terminal: git pull nome_dado_ao_servidor nome_da_branch
      • Faça o commit, no terminal: git commit -m "mensagem"
      • Tente enviar novamente para o servidor, no terminal: git push -u nome_dado_ao_servidor nome_da_branch
  • Clonando um repositório: Quando alguém já tiver iniciado um projeto e hospedado um repositório. Nós não temos o projeto localmente, e vamos iniciar a colaboração em um projeto ou trabalhar em um projeto open source.
    • No terminal: git clone url_do_repositorio nome_da_pasta_do_projeto
    • Agora vc tem uma cópia de um projeto e pode escrever nele, atualizar, enviar novamente para os servidor etc.
  • Incorporando repositórios no seu projeto em "working directory": Principalmente se você tiver feito atualizações em seu projeto que ainda não estão incorporadas remotamente.
    • No terminal: git merge nome_dado_ao_servidor/nome_da_branch
  • Liberando / habilitando colaboradores
    • No GitHub (servidor utilizado em nosso exemplo), vá em Admin Collaborators Nome do colaborador add (precisa ser um usuário cadastrado no GitHub)
    • Uma vez que vc adicionar alguém como colaborador, ele vai receber uma mensagem e receberá acesso para ler e alterar o projeto.

Principais comandos GIT

  • Iniciar o GIT num projeto
    • No terminal: git init
  • Criar uma tag em seu repositório
    • No terminal: git tag -a nome_da_tag -m "mensagem"
  • Listar todas as tags
    • No terminal: git tag
  • Verificando os commits e diferenças entre eles:
    • No terminal: git show id_do_commit
  • Adicionando arquivos ao status "staging index"
    • Todos os arquivos modificados: No terminal: git add .
    • Um arquivo específico: No terminal: git add arquivo.txt
  • Adicionando arquivos e aplicando commit ao mesmo tempo
    • No terminal: git commit -ma
  • Consultando o status (arquivos com status "staging index"), modificados, excluídos etc
    • No terminal: git status
  • Consultando as modificações entre a versão antiga e nova de um arquivo
    • Em seu "working directory", no terminal: git diff
    • Em seu "staging index", no terminal: git diff --staged
  • Consultando as modificações entre duas branches
    • No terminal: git diff nome_da_branch nome_da_outra_branch
  • Consultando as modificações entre uma branch remota e uma branch local
    • No terminal: git diff nome_da_conexao/nome_da_branch_remota..nome_da_branch_local
  • Removendo arquivos do projeto
    • No terminal: git rm arquivo.txt
  • Renomeando arquivos do projeto via linha de comando
    • No terminal: git mv arquivo-original.txt arquivo-renomeado.txt
  • Descartar alterações nos arquivos ("working directory") ou voltar no tempo (recuperar uma branch ou versão antiga) - não substitui seu "working directory" pelo que vc recuperou no checkout.
    • No terminal: git checkout
    • Para recuperar um arquivo específico da branch atual, no terminal: git checkout -- arquivo.txt
  • Tirar arquivos do status de "staging index"
    • No terminal: git reset HEAD arquivo.txt
    • HEAD aponta para a branch atual e aplica um unstage no arquivo.txt
  • Refazer um commit (o mais recente)
    • No terminal: git commit --amend -m "titulo do commit"
  • Recuperar arquivos ou pastas de uma branch / commit antigo (troca seu arquivo atual pelo antigo recuperado)
    • Recupere o ID do commit desejado, no terminal: git log
    • No terminal: git checkout id_do_commit -- arquivo.txt
    • Veja as diferenças entre os arquivos, no terminal: git diff --staged
  • Reverter pequenas atualizações em commits
    • No terminal: git revert id_do_commit
  • Reset: Desfazer múltiplos commits (desfazer muitas atualizações em muitos arquivos)
    • Soft: Sem afetar o "staging index" ou "working directory". Mais seguro (apenas volta no tempo, mantendo as atualizações mais recentes de seu "working directory" e compara com o ID restaurado).
    • Mixed (default): retira algum arquivo que estava no estágio de "staging index" mas não altera o arquivo modificado a nível do "working directory".
    • Hard: altera tudo, o ID do "staging index" e o "working directory". Usar o Hard Reset é aconselhável quando vc não quer mais ter um histórico das alterações e deseja seguir numa nova linha daqui pra frente. Apaga tudo relacionado ao commit informado até o presente momento (incluindo as alterações atuais dos arquivos na máquina) e inicia uma nova branch.
    • No terminal: git reset -- soft (mixed ou hard) id_do_commit
  • Remover permanentemente arquivos do “rastreamento” e, também, da máquina:
    • Remover tudo que não esteja no "staging index", no terminal: git clean -f
  • Remover arquivos que foram adicionados à lista de não trackeáveis, mas estão no "staging index":
    • No terminal: git rm --cached arquivo.txt
  • Visualizando os logs:
    • Exibir todos os logs do projeto, no terminal: git log
    • Exibir últimos 5 logs do projeto, no terminal: git log -n 5
    • Exibir logs do projeto por data (da data informada até a atual), no terminal: git log --since=2016-12-31 (ano-mes-dia)
    • Exibir logs do projeto por data (até a data informada), no terminal: git log --until=2016-12-31 (ano-mes-dia)
    • Exibir logs do projeto por autor, no terminal: git log --author=nome_da_pessoa
    • Exibir logs do projeto por título ou conteúdo, no terminal: git log --grep=palara_chave_ou_frase
  • Comandos relacionados à branches
    • Listar branches locais, no terminal: git branch
    • Listar branches remotas, no terminal: git branch -r
    • Listar branches (locais e remotas), no terminal: git branch -a
    • Criar uma nova branch, no terminal: git branch nome_da_branch
    • Trocar de branch, no terminal: git checkout nome_da_branch
    • Checar trilha da branch (HEAD): cat .git/HEAD
    • Criar uma nova branch e faz o checkout nela, no terminal: git checkout -b nome_da_branch
      • Obs: se estiver fora da branch master, ele cria a branch e ainda atribui o commit da branch anterior.
    • Renomear uma branch, no terminal: git branch -m nome_da_branch novo_nome_da_branch
    • Removendo uma branch (faça o checkout da branch antes), no terminal: git branch -d nome_da_branch
    • Removendo uma branch do repositório online, no terminal: git push conexao_remota :nome_da_branch
    • Outra maneira de remover branches do repositório online, no terminal: git push conexao_remota --delete nome_da_branch
    • Juntando branches com o método "fast-forward" (faça o checkout na branch, vá até a master), no terminal: git merge nome_da_branch
      • Neste método não necessitamos fazer o commit destas alterações e a master branch incorpora a nova branch paralela.
    • Juntando branches com o método "only fast-forward" (faça o checkout na branch), no terminal: git merge --ff-only nome_da_branch
      • Faz a junção das branches apenas se for possível aplicar o método fast-forward, caso contrário, aborta.
    • Juntando branches com o método "true merge" (faça o checkout na branch), no terminal: git merge --no-ff nome_da_branch
      • Faz a junção das branches de maneira documentada.

Obtendo ajuda com GIT

É possível obter ajuda no site do GIT ou via linha de comando. Para ajuda de uma forma geral, no terminal: git help ou, para ajuda referente a algum tópico específico (ex. log), no terminal: git help log

Lendo arquivos, logs ou diferenças no GIT (via Nano): Durante a exibição do arquivo de ajuda pressione: F para seguir (forward), B para voltar (backward) ou Q para fechar (quit).

Extensões e dicas

  • Inserir -- nos comandos, significa que você está referenciando a branch atual.
  • Adicionando arquivos ao status "staging index"
    • Todos os arquivos modificados: No terminal: git add .
    • Um arquivo específico: No terminal: git add arquivo.txt
  • Adicionando arquivos e aplicando commit ao mesmo tempo
    • No terminal: git commit -ma
  • Consultando as modificações entre a versão antiga e nova destacando em cores
    • No terminal: git diff --color-words
  • Consultando as modificações entre branches destacando em cores
    • No terminal: git diff --color-words nome_da_branch..nome_da_outra_branch
  • Se você remover algum arquivo do projeto, pode ser que não consiga aplicar o commit. É necessário antes remove-lo do status do GIT ("working directory")
    • Obs: Quando você aplicar o commit, é interessante avisar que arquivos foram removidos.
  • Se você renomear algum arquivo do projeto (via sistema operacional, interface), pode ser que não consiga aplicar o commit. O status vai acusar um arquivo deletado e outro arquivo na fila.
    • Obs: É necessário antes remover o arquivo antigo (vai acusar o nome antigo) do status do GIT ("working directory"). Depois disso o GIT saberá que o arquivo foi, de fato, renomeado e atualiza o status.
  • Existe um HEAD na branch atual e PARENT ID (para branches anteriores, que fazem referência ao último commit). Se você aplicou um commit, e precisa reorganizar o projeto, adicionando novos arquivos ou atualizações para a mesma branch, use o comando amend - que funciona, mais ou menos, como uma atualização de commit (do último que está no topo da trilha - HEAD) reorganizando os indexes (IDs)
  • Exibindo logs em uma linha só
    • No terminal: git log --oneline
  • Exibindo várias características de log
    • No terminal: git log --graph --oneline --decorate --all
  • Melhores práticas:
    • Sempre que sentar-se no computador, ao iniciar a manhã, de um fetch no repositório GIT. Assim vc sincroniza o projeto de outras pessoas, com o seu. Recuperando todas as novidades e garantindo que estará trabalhando com versões mais recentes do código.
    • Aplique o fetch antes de dar o push para o servidor GIT.
    • Aplique o fetch com freqüência!
  • Alias (short commands) do GIT
    • No terminal: git config --global alias.atalho_qualquer comando_git_que_deve_ser_acionado
    • Ex. git config --global alias.st status (faz com que “st” seja a mesma coisa que “status”) na linha de comando. Você pode fazer isto com qualquer outro comando. Use com moderação e sabedoria!
  • Melhorando o aspecto do seu prompt (ao invés de exibir o $ padrão, exibe o nome da pasta e o nome da branch) - Necessita de uma extensão "git-completion.bash"
    • Baixe a dependência (se você não possuir), no terminal: curl -o ~/.git-prompt.sh \ https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh
    • Edite o arquivo do profile, no terminal: nano ~/.bash_profile
    • Adicione esta linha em seu bash_profile: source ~/.git-prompt.sh (salve e feche)
    • Para alterar a nível de sessão (até fechar o terminal), no terminal: export PS1='$(__GIT_ps1 ["%s"]) \W > '
    • Para alterar a nível geral (sempre que você utilizar o terminal), no terminal: nano ~/.bash_profile
    • Adicione a linha (dentro o IF, se houver): export PS1='$(__GIT_ps1 ["%s"]) \W > ' (salve e feche)

Merge e seus (possíveis) conflitos

Os conflitos ocorrem, basicamente, quando existem mudanças exatamente no mesmo local e no mesmo arquivo em branches diferentes. Como resolver? como saber quais mudanças são as oficiais?

Quando se aplica um merge que resulta em conflito, o GIT entra numa pasta intermediária entre a master branch e a outra que está sendo mesclada. Sendo assim, torna-se necessário consultar quais são as diferenças entre os arquivos e corrigi-las.

  • Consulte o status, no terminal: git status (você receberá uma lista de arquivos com problemas)
  • Abrindo o arquivo em seu "working directory" você verá que o código agora está marcado com o erro a ser corrigido. Existem duas opções:
    • Abortar, no terminal: git merge --abort
    • Resolver o conflito: Abra o arquivo, edite e salve!
    • Caso tenha atualizado, adicione novamente ao commit, no terminal: git add arquivo.txt
    • Com todos os conflitos resolvidos, faça o commit novamente

Como reduzir conflitos na hora de aplicar o merge:

  • Mantenha o código pequeno e fácil de ler.
  • Faça pequenos commits e bem orientados. Não deixe acumular muita coisa pra depois fazer o commit.
  • Não altere muito o espaçamento (espaçamentos desnecessários).
  • Faça merges com freqüência, sempre que possível. Não deixe as branches paradas, esperando para fazer o merge “definitivo”.
  • Mantenha sua branch paralela sempre sincronizada com a master branch.

Adicionando arquivos problemáticos ao Stash

É um ambiente temporário, paralelo, onde vc insere arquivos (muitas vezes com conteúdo duplicado, que gera algum tipo de conflito num merge) e deixa-o em stand by.

  • Se detectou algum arquivo problemático com o "status" e não quer resolver o conflito agora, no terminal: git stash save “texto qualquer que identifica esse stash”
  • Exibindo stashes armazenados
    • No terminal: git stash list
  • Consultar detalhes de um stash
    • No terminal: git stash show stash@{id_do_stash}
  • Consultar, ainda mais, detalhes de um stash
    • No terminal: git stash show -p stash@{id_do_stash}
  • Recuperar as mudanças armazenadas em um stash
    • No terminal: git stash pop stash@{id_do_stash}
  • Apagar todos os stashes
    • No terminal: git stash clear
  • Apagar um stash determinado
    • No terminal: git stash clear stash@{id_do_stash}
Interação padrão no Git

Extra: Workflow padrão quando trabalhamos com colaboradores

Um exemplo de como seria uma interação padrão no Git quando estamos num projeto com colaboradores

  1. git checkout master (vá até sua master branch)
  2. git fetch (após trabalhar algumas horas, aplique o fetch em seu projeto)
  3. git merge origin/master (atualiza o repositório local com o remoto)
  4. git checkout -b nome_da_branch (para novas atualizações, crie novas branches)
  5. git add
  6. git commit -m “mensagem”
  7. git fetch (verifica se tem mais atualizações no repositório remoto)
  8. git push -u nome_da_conexao_remota nome_da_branch (sobe suas atualizações para o servidor)
  9. Avise seus colaboradores via e-mail
  10. Seus colaboradores vão fazer a mesma coisa
  11. git checkout master (irão até sua master branch)
  12. git fetch (aplicarão fetch em todo o projeto)
  13. git merge nome_da_conexao_remota/master (atualizarão o repositório local com o remoto)
  14. git checkout -b nome_da_branch nome_da_conexao_remota/nome_da_branch (irão conferir seu código)
  15. git log (para verificar o que foi feito)
  16. git show TRACK ID (para consultar ainda mais detalhes do que foi feito)
  17. git commit -am “mensagem” (talvez eles atualizem alguma coisa)
  18. git fetch
  19. git push
  20. Eu vou verificar que minha atualização foi aprovada (inicio novamente o processo)
  21. git fetch
  22. git log -p nome_da_branch..nome_da_conexao_remota/nome_da_branch (para consultar as diferenças entre a minha branch e a que está online)
  23. git merge nome_da_conexao_remota/branch (agora eu tenho exatamente o que está online, assim como meus colaboradores)
  24. git checkout master
  25. git fetch (verifica se não há nenhuma atualização enquanto estive consultando outras coisas)
  26. git merge nome_da_conexao_remota/master
  27. git merge nome_da_branch
  28. git push (para subir novamente alguma atualização que tenha sido feita)
  29. E assim vai...

Referências

04 de Janeiro de 2017 [14:31:37]

CEO da MDM Studio, Marcelo Motta participa ativamente do processo de produção de websites, tendo em seu portfólio mais de 130 trabalhos finalizados, entre marcas, websites e sistemas web. Os projetos mais recentes contam com a estrutura do HTML 5, combinados com CSS3 e versões mobile através de media queries.
 

TechNews

Informativos MDM Studio, Games e Tecnologia

Assine nosso Feed RSS