José Malcher Jr.

Eng. Software – Analista de Sistemas

Excelente curso grátis de git e github e é grátis!

Link: https://www.schoolofnet.com/curso-git-e-github/

abril 18th, 2017

Posted In: Assuntos Diversos, Caixa de Ferramentas, Cursos, Git

Tags:, ,

Leave a Comment

logo gitPrimeiro passo para criar um projeto git, é a definição da pasta de tralho, onde estão todos os arquivos e códigos fontes do projeto.

git init

É criado uma pasta oculta “.git”, verificação da pasta: “ls -a” ou “ls -la”. Tal pata é oculta pois contem todas as configurações do git do projeto, não sendo necessário, na maioria das vezes, usa-lo.

Documentação do comando git init

Gitignore

Sempre é bom ter o cuidado para versionar arquivos de códigos fontes, evitando arquivos executáveis por exemplo ou pastas que não fazem parte do projeto.

Exemplos/Artigos/repositórios sobre o assunto .gitignore:

Documentação oficial sobre gitignore

Gerador de Arquivos Gitignore  (muito útil, basta setar o tipo de projeto e baixar/copiar o texto gerado)

Some common .gitignore configurations

A collection of .gitignore templates (Repositório com coleção de .gitignore de vários tipos de projetos)

.gitignore excluir todas as pastas menos uma (Dúvida bastante relevante!)

Após o “git init” e depois ter criado o arquivo “.gitignore”, com a pasta vazia crie ou copie o primeiro arquivo do projeto.

Um bom exemplo é criar um arquivo .java, e adicionar no .gitignore uma linha “*.class”, assim poderemos ver o git não trabalhando com arquivo com final .class. ( ‘*’ é um coringa que significa todos os nomes com final .class)

Adicionando o conteúdo do arquivo para o índice “git add .” e Visualizando o Status do versionando dos arquivos “git status”.

Documentação git add  e a Documentação do git status

O ponto do comando “git add .” significa que todos os arquivos serão adicionados ao repositório, com exceção dos arquivos listados no .gitignore.

Gravando as mudanças no git: git commit

Documentação oficial do comando git commit

O parâmetro “-m” diz ao git armazenar a mensagem que vem em seguida. Tal mensagem serve como um guia/manual explicando o que o usuário fez. Quanto mais clara for a mensagem, melhor será o entendimento do próximo programador que for editar o código.

A parte da mensagem:

Mostra o Branch ou “galho/ramo” do projeto,  como é o primeiro, está posicionado como principal ou master. Em seguida tem o código do commit e a mensagem gravada. Nas outras linhas é exibido os arquivos adicionados.

Verificando  os commit do projeto: git log

Documentação do git log (bastante extensa, mas verifique os exemplos)

O comando mostra o código do commit em sua totalidade, assim como exibe o nome e email do usuário e data, ao final exibe a mensagem do commit.

Se houver muitos commit, é possivel filtrar usando alguns parâmetros, exemplo

No linux é possível digitar “git log –” e apertar a tecla TAB, que é exibido os possíveis parâmetros:

O parâmetro mais simples é : git log –oneline

O parâmetro que ajuda a encontrar palavras na mensagem: git log –grep=”Palavra pra buscar na mensagem”

Outros comandos em Visualizando o Histórico de Commits

Verificando o Status do Git depois do comando commit:

Não há mais arquivos para ser “gravado” no repositório.


 

Para facilitar mais a visualização dos commits há interfaces/programas gráficos que ajudam, usuários linux tem o programa “gitk”, basta instalar com o comando “sudo dnf install gitk” ou “sudo apt-get install gitk”.

Usando Interface Gráfica para Visualizar o Histórico No final desse artigo tem a demostração do programa.

Lembrando que é necessário estar na pasta do projeto para executar o “gitk”

exemplo gitk

 

 

OBS.: Esta postagem é apenas um guia pessoal de referência e estudos sobre o assunto tratado.

dezembro 30th, 2015

Posted In: Caixa de Ferramentas, Git

Tags:

One Comment

logo gitApós a instalação do sistema de controle de versão, é importante conhecer alguns comandos básicos:

Versão do Git:

Escopos de configuração do Git:

O texto da documentação deixa claro as três formas de configuração do Git:

  1. Sistema: arquivo /etc/gitconfig: Contém valores para todos usuários do sistema e todos os seus repositórios. Se você passar a opção –system para git config, ele lerá e escreverá a partir deste arquivo especificamente.
  2. Usuário: arquivo ~/.gitconfig: É específico para seu usuário. Você pode fazer o Git ler e escrever a partir deste arquivo especificamente passando a opção –global.
  3. Projeto: arquivo de configuração no diretório git (ou seja, .git/config) de qualquer repositório que você está utilizando no momento: Específico para aquele único repositório. Cada nível sobrepõem o valor do nível anterior, sendo assim valores em .git/config sobrepõem aqueles em /etc/gitconfig.

A ordem de prioridade de configuração é: PROJETO > GLOBAL > SISTEMA

Em sistemas Windows, Git procura pelo arquivo .gitconfig no diretório $HOME (C:\Documents and Settins\$USER para a maioria das pessoas).

Arquivos com ponto+nome “.gitconfig”, são arquivos ocultos do sistema Linux, no Windows para visualizar no shell, use o comando “ls -a” ou “ls -la”

Primeiras configurações no Git pós instalação:

Adicionar usuário e email:

Lembrabdo que o parâmetro (–global) serve para o USUÁRIO logado atualmente no sistema. Pode causar confusão com configurações do sistema(–system).

Para checar as configurações use o comando:

Checar configurações de forma individual:

Adicionar algum outro editor padrão:

No S.O. Windows, pode ser que tenha algumas outras configurações já adicionadas por padrão.

Para verificar as configurações, além do comando “$ git config –list”, é possível ver as configurações visualizando o arquivo “.gitconfig” dentro da pasta do usuário. Ou mesmo é possível edita-lo direto, adicionando os parâmetros corretos:

Lembrando de antes verificar a presença do arquivo .gitconfig no local de execução do comando!

Recomendação é: configurar via linha de comando, pois há um espaçamento/tabulação específicos no arquivo .gitconfig.

Artigos/Sites/Repositórios sobre Personalização do Git e outros ajustes:

Customize seu Git! .gitconfig

Definindo configurações do .gitconfig após a instalação do GIT

https://gist.github.com/pksunkara/988716 (um arquivo .gitconfig)

https://training.github.com/kit/downloads/pt/github-git-cheat-sheet.pdf (PDF Com os principais comandos do git)

Para Outros detalhes, tem o comando “–help”

Para saber mais de cada comando use: git help <comando>

No linux, a página abre diretamente no terminal, para sair tecle “q”. No windows é provável que abra uma página em html no navegador padrão.

 

OBS.: Esta postagem é apenas um guia pessoal de referência e estudos sobre o assunto tratado.

dezembro 30th, 2015

Posted In: Caixa de Ferramentas, Git

Tags:

2 Comments

 

Com essa postagem: Resumos e Artigos sobre Controle de Versão de Códigos vou deixar aqui algumas impressões para estudos futuros. Pegando vários sites como base.

O bom e velho Wikipédia tem o artigo sobre Sistema de controle de versão que dá um apanhado geral sobre o que vem a ser os sistemas de controle de versão e o que eles fazem:

Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões — histórico e desenvolvimento — dos códigos-fontes e também da documentação.

Um grande diferencial que tem nesse artigo do wikipédia e que ajuda muito quem esta iniciando no versionamento de códigos é uma lista de “vocabulário comum”, aprenda o termo sempre em inglês!

  • Atualização / Update – Atualiza na cópia local as novidades do Servidor, provavelmente as mudanças enviadas por outro desenvolvedor.
  • Baixar / Check-out ou checkout – Quando não existe cópia local e é necessário baixar todo o projeto do servidor. Nesse processo é guardado algum tipo de meta-dados (geralmente em pasta oculta) junto dos arquivos baixados.
  • Conflito / Conflict – É a alteração simultânea (entre um update e um commit) de um mesmo documento por usuários diferentes.
  • Cópia local / Working copy ou working area – É geralmente uma pasta no sistema operacional do desenvolvedor (do lado Cliente) que mantém a cópia da última versão do projeto. É através da cópia local que o Cliente compara com a última versão do Servidor e sabe exatamente o que foi modificado.
  • Efetivar ou submeter / Commit, submit ou check-in – Enviar as alterações da cópia local ao Servidor através do Cliente.
  • Exportar / Export – Semelhante ao checkout, mas não cria meta-dados junto da informação baixada. Esse processo é utilizado para gerar uma versão “distribuível” e impede (por não conter os meta-dados) que o desenvolvimento seja feito sobre ele.
  • Importar / Import – É o processo que envia uma árvore de diretórios ainda não controlada (sem meta-dados) para o repositório pela primeira vez.
    Marcação / Tag ou release – É dar um nome a um determinado “momento” do repositório, ou seja, é como uma “fotografia” de determinada data. Alguns sistemas, como o SVN, não diferenciam entre “marcação” e “ramificação”, pois é possível tratar uma ramificação com o conceito ou finalidade de marcação.
  • Mesclagem / Merge ou integration – Permite que mais de um utilizador modifique um mesmo documento ao mesmo tempo, comparando as diferenças e mesclando mantendo as duas alterações (se possível). A mesclagem geralmente é feita localmente (lado Cliente) na atualização de um documento quando há uma versão no Servidor mais recente que a sua.
  • Mesclagem inversa / Reverse integration – É quando um braço é mesclado à linha principal.
  • Modificação, diferença ou mudança (Change ou diff.) – Representa a diferença entre uma versão e outra de um mesmo documento.
  • Raiz, linha principal ou braço principal / Head, trunk, mainline – é o caminho de revisões que não se quebrou em um braço.
  • Ramificação ou braço / Branch – Quando a linha de desenvolvimento precisa ser dividida em duas ou mais.
  • Repositório / Repository – local no Sistema onde fica armazenado todas as versões, desde a primeira até a última. Cada sistema geralmente pode ter mais de um repositório.
  • Resolução de conflito / Conflict resolve ou Solve – Quando os desenvolvedores precisam analisar o que entrou em conflito e escolher qual alteração fará parte da versão final.
  • Revisão ou versão / Revision ou version – Representa um determinado “momento” (uma “fotografia”) de um repositório ou documento.
  • Travar / Lock – Em alguns sistemas é possível bloquear um arquivo e ninguém pode alterá-lo nesse momento. Isso é pouco usado e pouco recomendado pois impede o uso simultâneo do mesmo arquivo por mais de um desenvolvedor, mas pode ser bastante útil com arquivos binários e/ou difíceis ou impossíveis de serem mesclados.
  • Última versão / last revision – é a última versão enviada ao sistema no braço principal.
  • Versão atualizada / Up-to-date – É quando a versão local é idêntica à que está no servidor. Quando alguém submete um documento (que você também está trabalhando) antes de você, o sistema não permite que você envie a sua versão enquanto você não deixar sua versão local atualizada (up-to-date).
  • Versão estável / Stable version – Chama-se de “versão estável” uma determinada versão do sistema que está compilando normalmente e não possui nenhuma anomalia grave.
  • Versão instável / Unstable version – Chama-se de “versão instável” uma versão do sistema que não está compilando ou que possui alguma anomalia bastante visível e geralmente grave.

 

Um outro artigo muito bom e bem completo pode ser ser lido em: Conceitos Básicos de Controle de Versão de Software — Centralizado e Distribuído é um artigo mais prático que ajuda o entendimento mostrando desenhos como os processos funcionam.

  1. Alguém já sobrescreveu o código de outra pessoa por acidente e acabou perdendo as alterações?
  2. Tem dificuldades em saber quais as alterações efetuadas em um programa, quando foram feitas e quem fez?
  3. Tem dificuldade em recuperar o código de uma versão anterior que está em produção?
  4. Tem problemas em manter variações do sistema ao mesmo tempo?

Se alguma das perguntas acima teve um sim como resposta, então sua equipe necessita urgentemente de um sistema para controle de versão!

Torço para que esse artigo sempre continue no ar, ele é excelente para montar aulas sobre o assunto!

Recomendo salvar o artigo em seu Evernote, usando o componente de Captura do navegador Chrome ou Firefox


 

Pra fechar o assunto tem uma Monografia: Análise Comparativa entre Sistemas de Controle de Versões Daniel Tannure Menandro de Freitas. Tem um excelente conteúdo sobre o assunto. Com destaque para o fluxo entre os diversos tipos de Sistemas de controle de versão, o fluxo do git:

fluxo_git

 

 

 

dezembro 27th, 2015

Posted In: Caixa de Ferramentas, Desenvolvimento, Git

Tags:,

Leave a Comment

git_github

Vou deixar aqui neste post algumas referências para quem quer aprender a usar o Git e o GitHub. Não vou explicar nada aqui, e sim deixar os links para que você possa explorar. Muito provavelmente irei re-postar algum conteúdo sobre o assunto no futuro, mas por hora, pra quem está ou quer aprender a usar essas ferramentas fica essas dicas:

Site oficial: https://git-scm.com/

GitHub: https://github.com/

Livro em pt_BR: https://git-scm.com/book/pt-br/v1

Curso e Screencast:

Curso de controle de versão com Git : Uma coleção de 8 vídeos para iniciantes, ele é bem completo nas explicações e vai do Git ao Github.
Screencast: Git e Github para Iniciantes: Aqui tem um screencast da Loiane Groner, exelente abordagem inicial.

http://tableless.com.br/iniciando-no-git-parte-1/ – Por por

http://rogerdudler.github.io/git-guide/index.pt_BR.html – Git – Guia Prático

http://blog.da2k.com.br/categories/github/ – Do Fernando Daciuk, que o mesmo tem um excelente curso: Git e Github Ninja

Um vídeo bacana aqui no link: Contribuindo para um projeto open source no Github de Rogerio Prado de Jesus

Git Cheatsheet (comandos úteis resumidos)

https://training.github.com/kit/downloads/pt/github-git-cheat-sheet.pdf – PDF em pt_BR de resumo oficial

http://www.ndpsoftware.com/git-cheatsheet.html – Site bem ilustrativo dos comandos e onde cada comando “afeta” as áreas de trabalho do git.

Pretendo escrever/criar conteúdo sobre o assunto, não apenas mostrar de outros autores, produzir conteúdo e tão importante quanto consumir. Mas de ante mão é sempre bom ler sobre um assunto pegando de várias fontes!

Abraços

outubro 31st, 2015

Posted In: Caixa de Ferramentas, Git

Tags:,

One Comment