Escrito por: Thanoshan MV

O que é Git?

O Git é um software de controle de versão gratuito e de código aberto. Foi criado por Linus Torvalds em 2005. Essa ferramenta é um sistema de controle de versão que foi inicialmente desenvolvido para trabalhar com vários desenvolvedores no kernel do Linux.

Basicamente, isso significa que o Git é um rastreador de conteúdo. Então, o Git pode ser usado para armazenar conteúdo — e é principalmente usado para armazenar código por causa das outras funcionalidades que ele fornece.

Projetos da vida real geralmente têm diversos desenvolvedores trabalhando em paralelo. Assim, eles precisam de um sistema de controle de versão como o Git para garantir que não ocorram conflitos de código entre eles.

Além disso, os requisitos de tais projetos mudam frequentemente. Por isso, um sistema de controle de versão permite que os desenvolvedores revertam e voltem a uma versão anterior do seu código.

O sistema de branches no Git permite que os desenvolvedores trabalhem individualmente em uma tarefa (por exemplo: uma branch -> uma tarefa OU uma branch -> um desenvolvedor). Basicamente, pense no Git como uma pequena aplicação de software que controla sua base de código, se você for um desenvolvedor.

Repositórios do Git

Se quisermos começar a usar o Git, precisamos saber onde hospedar nossos repositórios.

Um repositório (ou "repo", para abreviar) é um projeto que contém diversos arquivos. No nosso caso, um repositório conterá arquivos baseados em código.

Existem duas maneiras de hospedar seus repositórios. Uma é on-line (na nuvem) e a outra é off-line (instalado no seu servidor).

Existem três serviços populares de hospedagem do Git: GitHub (pertencente à Microsoft), GitLab (pertencente ao GitLab) e BitBucket. Usaremos o GitHub como nosso serviço de hospedagem.

Antes de usar o Git, devemos saber por que precisamos dele

O Git facilita a contribuição para projetos de código aberto

Quase todos os projetos de código aberto usam o GitHub para gerenciar seus projetos. Usar o GitHub é gratuito se o seu projeto for de código aberto, e inclui uma wiki e um rastreador de problemas que facilita a inclusão de documentação mais detalhada e o recebimento de feedback sobre seu projeto.

Se você quiser contribuir, você apenas faz o fork (uma cópia) de um projeto, faz suas alterações e, em seguida, envia ao projeto um pull request usando a interface da web do GitHub. Esse pull request é sua maneira de dizer ao projeto que você está pronto para que revisem suas alterações.

Documentação

Ao usar o GitHub, você facilita a obtenção de excelente documentação. A seção de ajuda e os guias deles têm artigos sobre praticamente qualquer tópico relacionado ao Git que você possa imaginar.

Opções de integração

O GitHub pode se integrar com plataformas comuns como Amazon e Google Cloud, com serviços como Code Climate para acompanhar seu feedback, e pode realçar a sintaxe em mais de 200 linguagens de programação diferentes.

Acompanhe as alterações no seu código entre versões

Quando várias pessoas colaboram em um projeto, é difícil acompanhar as revisões — quem mudou o que, quando e onde esses arquivos estão armazenados.

O GitHub cuida desse problema ao acompanhar todas as alterações que foram enviadas ao repositório.

Muito parecido com o uso do Microsoft Word ou do Google Drive, você pode ter um histórico de versões do seu código para que versões anteriores não sejam perdidas a cada iteração. É fácil voltar à versão anterior e contribuir com seu trabalho.

Exibir seu trabalho

Você é um desenvolvedor que deseja atrair recrutadores? O GitHub é a melhor ferramenta em que você pode confiar para isso.

Hoje, ao procurarem por novos recrutas para seus projetos, a maioria das empresas olha para perfis do GitHub. Se o seu perfil estiver disponível, você terá uma maior chance de ser recrutado, mesmo se não for de uma universidade ou faculdade renomada.

Aprendendo a usar o Git e o GitHub

Criação de conta no GitHub

Para criar sua conta, você precisa ir ao site do GitHub e preencher o formulário de registro.

Instalação do Git

Agora, precisamos instalar as ferramentas do Git em nosso computador. Usaremos a CLI (interface de linha de comando) para nos comunicarmos com o GitHub.

Para o Linux:

1. Primeiro, atualize seus pacotes.

sudo apt update

1. Em seguida, instale o Git e o GitHub com apt-get

sudo apt-get install git

1. Finalmente, verifique se o Git está instalado corretamente

git --version

1. Execute os seguintes comandos com suas informações para definir um nome de usuário e e-mail padrão quando você for salvar seu trabalho.

git config --global user.name "seu_nome_de_usuario_aqui"
git config --global user.email "exemplo@e-mail.com"

Trabalhando com projetos no GitHub

Trabalharemos com projetos no GitHub de dois modos.

Modo 1: crie o repositório, clone-o para o seu PC e trabalhe nele. (recomendado)

O modo 1 envolve criar um repositório do zero no GitHub, cloná-lo para o nosso computador, trabalhar em nosso projeto e enviá-lo de volta.

Crie um repositório clicando no botão "New repository" na página da web do GitHub.

Perfeito! Seu primeiro repositório no GitHub foi criado.

Sua primeira missão é obter uma cópia do repositório no seu computador. Para fazer isso, você precisa "clonar" o repositório no seu computador.

Clonar um repositório significa que você está pegando um repositório que está no servidor e clonando-o para o seu computador - assim como baixá-lo. Na página do repositório, você precisa obter o endereço "HTTPS".

Depois de obter o endereço do repositório, você precisa usar seu terminal. Utilize o seguinte comando no terminal. Quando estiver pronto, você pode inserir isto:

git clone [ENDEREÇO HTTPS]

Esse comando fará uma cópia local do repositório hospedado no endereço fornecido.

Agora, o repositório está no seu computador. Você precisa entrar nele com o seguinte comando.

cd [NOME DO REPOSITÓRIO]

Como você pode ver na imagem acima, o nome do meu repositório é "My-GitHub-Project" e esse comando me fez ir para esse diretório específico.

OBSERVAÇÃO: quando você clona, o Git criará um repositório no seu computador. Se quiser, você pode acessar seu projeto com a interface do usuário do computador em vez de usar o comando 'cd' no terminal.

Agora, naquela pasta, podemos criar arquivos, trabalhar neles e salvá-los localmente. Para salvá-los remotamente — como no GitHub — temos que fazer um processo chamado "commit". Para fazer isso, volte ao seu terminal. Se o tiver fechado, como mencionei anteriormente, use o comando 'cd'.

cd [NOME DO REPOSITÓRIO]

Agora, no terminal, você está no diretório do seu repositório. Existem 4 etapas em um commit: 'status', 'add', 'commit' e 'push'. Todos os passos seguintes devem ser realizados dentro do seu projeto. Vamos passar por eles um por um.

"status": a primeira coisa que você precisa fazer é verificar os arquivos que você modificou. Para fazer isso, você pode digitar o seguinte comando para exibir uma lista de mudanças.

git status

"add": com a ajuda da lista de mudanças, você pode adicionar todos os arquivos que deseja enviar com o seguinte comando,

git add [NOME DO ARQUIVO] [NOME DO ARQUIVO] [...]

No nosso caso, vamos adicionar um arquivo HTML simples.

git add sample.html

"commit": agora que adicionamos os arquivos da nossa escolha, precisamos escrever uma mensagem para explicar o que fizemos. Essa mensagem pode ser útil mais tarde se quisermos verificar o histórico de alterações. Aqui está um exemplo do que podemos colocar no nosso caso.

git commit -m "Adicionado arquivo HTML de amostra que contém sintaxe básica"

1. "push": agora podemos colocar nosso trabalho no GitHub. Para fazer isso, temos que fazer o 'push' de nossos arquivos para remote. remote é uma instância duplicada do nosso repositório que vive em algum lugar em um servidor remoto. Para fazer isso, devemos saber o nome do remote (na maioria das vezes o remote é chamado de origin). Para descobrir esse nome, digite o seguinte comando.

git remote

Como você pode ver na imagem acima, é dito que o nome do nosso remote é origin. Agora, podemos fazer o 'push' do nosso trabalho com segurança pelo seguinte comando.

git push origin master

Agora, se formos ao nosso repositório na página web do GitHub, podemos ver o arquivo sample.html que enviamos para o remoto — que é o GitHub!

OBSERVAÇÃO: às vezes, quando você está usando comandos Git no terminal, isso pode levar você ao editor de texto VIM (um editor de texto baseado em CLI). Para se livrar dele, você tem que digitar

:q

e ENTER.

Fazer o 'pull' é o ato de receber do GitHub.

Fazer o 'push' é o ato de enviar para o GitHub.

Modo 2: trabalhe no seu projeto localmente e depois crie o repositório no GitHub e envie-o para o remoto.

O modo 2 permite que você crie um repositório a partir de uma pasta existente no seu computador e o envie para o GitHub. Em muitos casos, você pode já ter criado algo no seu computador que deseja, de repente, transformar em um repositório no GitHub.

Vou explicar isso para você com um projeto de formulário de pesquisa que fiz anteriormente que não foi adicionado ao GitHub.

Como já mencionei, ao executar quaisquer comandos do Git, temos que garantir que estamos no diretório correto no terminal.

Por padrão, qualquer diretório no nosso computador não é um repositório do Git – mas podemos transformá-lo em um repositório do Git executando o seguinte comando no terminal.

Após converter nosso diretório para um repositório do Git, a primeira coisa que precisamos fazer é verificar os arquivos que temos usando o seguinte comando.

git status

Então, há dois arquivos nesse diretório que precisamos "adicionar" ao nosso repositório.

git add [NOME_DO_ARQUIVO] [NOME_DO_ARQUIVO] [...]

OBSERVAÇÃO: para "adicionar" todos os arquivos no nosso repositório, podemos usar o seguinte comando:

git add .

Após a área de stage (o processo de adição) estar completa, podemos verificar se os arquivos foram adicionados com sucesso executando o git status.

Se esses arquivos específicos estiverem em verde, como na imagem abaixo, você fez seu trabalho!

Então, temos que fazer o "commit" com uma descrição.

git commit -m "Adicionando formulário de pesquisa web"

Se meu repositório começou no GitHub e se eu o clonar para meu computador, um remote já estará anexado a ele (modo 1). Se, no entanto, eu estiver começando o repositório no meu computador, ele não tem um remote associado a ele, então eu preciso adicionar esse remote (modo 2).

Para adicionar esse remote, precisamos ir ao GitHub primeiro. Crie um repositório e nomeie-o como quiser para armazená-lo no GitHub. Em seguida, clique no botão "Create repository".

OBSERVAÇÃO: no modo 2, não inicialize o repositório com um arquivo README ao criar um repositório na página web do GitHub.

Depois de clicar no botão "Create repository", você verá a imagem abaixo como uma página da web.

Copie o endereço HTTPS. Agora, vamos criar o remote para nosso repositório.

git remote add origin [ENDEREÇO HTTPS]

Após executar esse comando, podemos verificar se adicionamos o remote com sucesso usando o seguinte comando:

git remote

Se ele exibir "origin", você adicionou o remote ao seu projeto.

OBSERVAÇÃO: lembre-se de que podemos indicar qualquer nome para o remote alterando o nome "origin". Por exemplo:

git remote add [NOME_DO_REMOTO] [ENDEREÇO HTTPS]

Agora, podemos enviar nosso projeto para o GitHub sem problemas!

git push origin master

Após completar essas etapas uma por uma, se você for ao GitHub, encontrará seu repositório com os arquivos!

Conclusão

Obrigado a todos por lerem. Expliquei apenas o básico de Git e GitHub. Recomendo fortemente que todos leiam mais artigos relacionados a Git e GitHub. Espero que este artigo tenha ajudado.

Confira o artigo original (em inglês) no Medium.

Boa programação para você!

Já pensou em como programadores guardam as diferentes versões do código que escrevem? É aí que entra o "controle de versão", uma ferramenta que salva o histórico do seu código, como se fosse um "control + z" turbinado.

Com ele, você e sua equipe podem voltar atrás em qualquer mudança, como se fosse uma máquina do tempo para o seu código!

Existem três tipos principais de sistemas de controle de versão:

• Sistemas locais: salvam as versões do código na sua própria máquina. É simples, mas se o computador der problema, já era!
• Sistemas centralizados: guardam tudo em um servidor central. É bom para colaboração, mas, se o servidor cair, ninguém trabalha!
• Sistemas distribuídos: cada desenvolvedor tem uma cópia completa do código. É o mais seguro e moderno.

Certo, e o que isso tem a ver com o Git?

O Git é um sistema de controle de versão distribuído, gratuito e muito popular. Com ele, você salva "instantâneos" do seu código (chamados de commits) e pode voltar para qualquer um deles quando quiser.

Pense no Git como um álbum de figurinhas do seu código, onde cada figurinha representa uma mudança.

O que é o GitHub?

O GitHub é como se fosse uma rede social para o seu código do Git. É lá que você guarda seus projetos (chamados de repositórios) e mostra para o mundo (ou não, você escolhe!).

No GitHub, você pode:

• Trabalhar em equipe em um projeto, cada um com sua cópia, sem confusões.
• "Clonar" o código de outros projetos e aprender com eles.
• Mostrar seus projetos para futuros empregadores.

Por que usar o GitHub?

• Organização: chega de pastas com nomes "projeto_final_versao_5_final_mesmo.zip"!
• Trabalho em equipe: programe junto com seus amigos sem dor de cabeça.
• Portfólio: mostre seus projetos para o mundo e impressione os recrutadores.

Mãos à obra: configurando o Git

1. Baixe o Git: vá no site oficial https://git-scm.com/ e baixe a versão para o seu sistema operacional (Windows, Mac ou Linux).
2. Instale o Git: é só seguir as instruções do instalador.
3. Configure o Git: abra o terminal (ou o Git Bash) e digite:

git config --global user.name "Seu Nome"
git config --global user.email "seu_e-mail@exemplo.com"

Substitua "Seu Nome" e "seu_e-mail@exemplo.com" por suas informações.

Criando sua conta no GitHub

1. Acesse o site https://github.com/.
2. Clique em "Sign up" (inscrever-se) no canto superior direito.
3. Preencha o formulário com seu e-mail, senha e nome de usuário.
4. Pronto! Você já faz parte da comunidade GitHub!

Comandos básicos do Git

• git init: cria um novo repositório Git na pasta atual.
• git add: adiciona suas mudanças na "área de preparação" (em inglês, staging area).
• git commit -m "mensagem": salva suas mudanças com uma mensagem descrevendo o que você fez.
• git clone [link do repositório]: copia um repositório do GitHub para sua máquina.
• git push: envia suas mudanças para o GitHub.

Conclusão

Este guia é uma introdução ao mundo do Git e GitHub. Agora, é hora de você colocar a mão na massa e começar a fazer o versionamento de seus projetos!

Lembre-se: errar faz parte do aprendizado. Não tenha medo de experimentar e explorar as funcionalidades do Git e do GitHub.

Boa programação para você!

Escrito por: Bruno Pedro

No passado, vi muita gente usar repositórios do Git para armazenar informações confidenciais relacionadas a seus projetos.

Ultimamente, tenho visto algumas pessoas anunciarem que estão armazenando chaves de API em seus repositórios privados do GitHub. Estou escrevendo este artigo porque as pessoas devem entender os riscos de armazenar chaves de API com seu código.

Este artigo não se destina a ser uma solução permanente para os problemas que você pode ter com o armazenamento de chaves de API. Em vez disso, é minha própria análise do problema e minhas sugestões sobre como corrigi-lo.

Então, qual é exatamente o problema de armazenar informações confidenciais com seu código em um repositório do Git?

Por que você não deve armazenar chaves de API em repositórios do Git

Armazenar chaves de API, ou qualquer outra informação confidencial, em um repositório do git é algo a ser evitado a todo custo. Mesmo que o repositório seja privado, você não deve vê-lo como um local seguro para armazenar informações confidenciais.

Vamos começar analisando por que é uma má ideia armazenar chaves de API em repositórios públicos do git.

Por natureza, um repositório público do git pode ser acessado por qualquer pessoa.

Em outras palavras, qualquer pessoa com uma conexão com a internet pode acessar o conteúdo de um repositório público do git. Não é só isso. Eles também podem navegar por todo o código dentro do repositório e possivelmente até executá-lo. Se você armazenar uma chave de API em um repositório público, estará publicando a céu aberto para que qualquer pessoa possa vê-la.

Uma pesquisa recente por client_secret no GitHub revelou que há mais de 30.000 confirmações que potencialmente expõem uma chave de API e um segredo. Em alguns casos, você só copia e cola o código para acessar imediatamente a API.

Esse problema está se tornando tão sério que algumas empresas investem em recursos para garantir que não haja chaves de API e segredos vazados.

No ano passado, o Slack começou a procurar por tokens de API expostos e a invalidá-los proativamente. Essa ação impede o acesso malicioso às contas do Slack, mas não é possível encontrar todos os tokens vazados.

Então, isso está acontecendo em repositórios públicos do git. Será que também acontece com os repositórios privados? Por que isso é um problema?

Repositórios privados do Git hospedados em serviços como GitHub, GitLab e Bitbucket estão expostos a um tipo diferente de risco. Quando você integra uma aplicação de terceiros com um dos serviços mencionados, você pode estar abrindo seus repositórios privados para esses terceiros. Essas aplicações poderão acessar seus repositórios privados e ler as informações contidas neles.

Embora isso por si só não crie um risco, imagine se uma dessas aplicações se tornar vulnerável a invasores. Ao obter acesso não autorizado a uma dessas aplicações de terceiros, os invasores podem obter acesso aos seus dados confidenciais, incluindo chaves de API e segredos.

Onde, então, devemos armazenar as chaves de API?

Existem muitas alternativas para armazenar chaves de API e segredos com segurança. Algumas delas permitem que você use seu repositório do Git e criptografe os dados confidenciais. Outras ferramentas são mais sofisticadas e descriptografam informações confidenciais como parte de um fluxo de trabalho de implantação. Vejamos algumas das soluções disponíveis.

git-remote-gcrypt

A primeira solução permite criptografar um repositório do Git inteiro. O git-remote-gcrypt faz isso adicionando funcionalidade aos auxiliares remotos do Git para que uma nova camada de transporte criptografada fique disponível. Os usuários só precisam configurar um novo controle remoto criptografado e enviar o código para ele.

Continue lendo se estiver procurando uma solução mais refinada que permita criptografar arquivos individuais.

git-secret

O git-secret é uma ferramenta que funciona em sua máquina local e criptografa arquivos específicos antes de enviá-los para seu repositório. Internamente, o git-secret é um script de shell que usa a GNU Privacy Guard (GPG) para criptografar e descriptografar arquivos que podem ter informações confidenciais.

git-crypt

Outra solução é o git-crypt. É bastante parecido com o git-secret na maneira de operar, mas com algumas diferenças interessantes.

A primeira coisa a se perceber sobre o git-crypt é o fato de ele ser um executável binário, não um script de shell, como o git-secret. Por ser um executável binário, para usá-lo, é preciso primeiro compilá-lo ou encontrar uma distribuição binária para sua máquina.

Se estiver usando um Mac, você está com sorte, pois o HomeBrew oferece um pacote do git-crypt, pronto para ser instalado. Você precisa apenas executar brew install git-crypt em um terminal.

BlackBox

O BlackBox é uma ferramenta criada pelo Stack Overflow. Essa é a empresa por trás das conhecidas comunidades de perguntas e respostas como o próprio Stack Overflow, o Server Fault e o Super User. O BlackBox é uma ferramenta robusta, que funciona com o Git e com outros sistemas de controle de versão, como o Mercurial e o Subversion.

Ele também suporta a criptografia de pequenas cadeias de caracteres e não apenas arquivos inteiros. Ele faz isso ao trabalhar com o Puppet e usa o Hiera, uma ferramenta de busca de chave-valor do Puppet para dados de configuração.

Por ter a capacidade de criptografar e descriptografar strings individuais, o BlackBox é uma ótima solução para garantir a segurança de chaves e segredos de API.

Configuração do Heroku e variáveis de configuração

Se estiver trabalhando com o Heroku, você não deve armazenar informações confidenciais, como chaves e segredos de API, em seus repositórios do Git. O Heroku oferece uma solução que permite que você defina as variáveis de configuração.

Sua aplicação pode acessar o conteúdo dessas variáveis de configuração durante o tempo de execução, acessando as variáveis de ambiente correspondentes. Mesmo que os valores não sejam criptografados, essa solução permite que você evite usar seu repositório do Git para armazenar chaves de API.

O Dokku, uma solução de código aberto, como o Heroku, oferece as mesmas capacidades.

Segredos do Docker

Ao final do espectro de soluções possíveis, temos os segredos do Docker (em inglês, Docker secrets). Essa solução foi apresentada pelo Docker em fevereiro de 2017, tendo ganhado popularidade desde então.

Os segredos do Docker permitem que você defina variáveis criptografadas e que as disponibilize para serviços específicos durante o tempo de execução. Os segredos são criptografados durante o trânsito e em repouso.

Essa abordagem torna os segredos do Docker a solução perfeita para armazenar e usar chaves de API e segredos de maneira segura e criptografada.

Resumo

Agora, você deve estar ciente dos perigos de armazenar informações confidenciais, como chaves de API e segredos em repositórios públicos e privados do Git.

Entender as possíveis maneiras pelas quais seus repositórios podem ser expostos é fundamental para avaliar e reduzir os riscos associados a vazamentos de informações.

Este artigo também propõe algumas soluções diferentes, que permitem criptografar chaves de API e segredos para que você possa usar com segurança seus repositórios de código.

Tenho certeza de que existem mais soluções por aí que podem ajudá-lo a alcançar os mesmos resultados.

Quando comecei a enviar ativamente conteúdo para o GitHub usando os push, não fiz isso para contribuir com o código aberto (em inglês, Open Source), não enviei componentes nem nada parecido – eu enviei poemas. Fiz isso por ser o que eu mais amo depois de programar. Desde então, tenho seguido muito feliz por ter tido a iniciativa de fazer meu primeiro git commit.

Quero mostrar o meu processo passo a passo para que novos programadores (e, espero eu, poetas), possam também se sentir à vontade trabalhando com o GitHub. Detalharei as várias maneiras de enviar conteúdo para o GitHub por push. Para fins deste artigo, assumirei que os leitores tenham alguma familiaridade com o uso do Terminal (seja o GitBash ou em algum outro formato).

Enviando conteúdo por push para um novo repositório com um arquivo README

É preciso passar por alguns passos essenciais para fazer isso:

• Clicar no botão Clone or download na página do repositório.

• Usar a opção Clone with HTTPS, copiando o link fornecido.

• Executar git clone https://github.com/PerfilDoUsuario/repositorio.git no terminal. Aqui, PerfilDoUsuario e repositorio serão substituídos pelos valores fornecidos no link copiado.
• Executar git init no terminal. Isso inicializará a pasta/repositório que você quer ter no sistema local do computador.
• Executar git add . no terminal. Isso fará o rastreamento das alterações feitas na pasta em seu sistema desde o último commit. Se for a primeira vez que você estiver fazendo o commit de conteúdo para a pasta, tudo o que estiver nela será adicionado.
• Execute git commit -m "coloque uma mensagem aqui". Isso preparará as alterações adicionadas/rastreadas à pasta no sistema para fazer o push para o GitHub. Substitua coloque uma mensagem aqui por uma mensagem de commit relevante à sua escolha.
• Execute git push origin master. Observe que a última palavra no comando, master, não é um nome fixo ao executar o git push. Esse nome pode ser substituído por qualquer "nome_de_branch" relevante.

Como fazer o push de código para um novo repositório do GitHub

"Programar é algo lindo. Todo mundo pode aprender a programar!"

O que você precisa fazer:

• Copiar o link de HTTPS fornecido.

• Executar git init no terminal. Isso inicializará a pasta/repositório que você quer ter no sistema local do computador.
• Executar git add . no terminal. Isso fará o rastreamento das alterações feitas na pasta em seu sistema desde o último commit. Se for a primeira vez que você estiver fazendo o commit de conteúdo para a pasta, tudo o que estiver nela será adicionado.
• Execute git commit -m "coloque uma mensagem aqui". Isso preparará as alterações adicionadas/rastreadas à pasta no sistema para fazer o push para o GitHub. Substitua coloque uma mensagem aqui por uma mensagem de commit relevante à sua escolha.
• Execute git remote add origin https://github.com/PerfilDoUsuario/exemplo.git no terminal. Aqui, PerfilDoUsuario e exemplo serão substituídos pelos valores fornecidos no link copiado. Isso fará o push da pasta existente para o seu sistema local do computador para o repositório do GitHub recém-criado.
• Execute git remote -v. Isso realiza um pouco da mágica do git pull e do git push garantindo que o conteúdo do novo repositório do GitHub, assim como da pasta no sistema, seja o mesmo.
• Execute git push origin master. Observe que a última palavra no comando, master, não é um nome fixo ao executar o git push. Esse nome pode ser substituído por qualquer "nome_de_branch" relevante.

É isso! Acredito honestamente que qualquer um pode aprender a programar. Passei o último ano ensinando alunos de graduação na Nigéria sobre Desenvolvimento de Software. Em breve, iniciarei minha própria jornada como "Empreendedor em treinamento" na Meltwater Entrepreneurial School of Technology.

Comece a programar hoje mesmo!

Tags permitem que os desenvolvedores marquem pontos de verificação importantes no decorrer do desenvolvimento de seus projetos. Por exemplo, as versões de lançamento de software podem receber tags. (por exemplo, v1.3.2). Elas, essencialmente, permitem que você dê a um commit um nome especial (uma tag).

Para exibir todas as tags criadas em ordem alfabética:

git tag

Para obter mais informações sobre uma tag:

git show v1.4

Existem dois tipos de tags:

Com anotações

git tag -a v1.2 -m "minha versão 1.4"

Leve

git tag v1.2

Elas diferem no modo como são armazenadas. Elas criam tags em seu commit atual.

Caso você queira colocar uma tag em um commit anterior, especifique a ID do commit que deseja marcar:

git tag -a v1.2 9fceb02

Os nomes das tags podem ser usados em vez de IDs do commit durante o check-out e o push dos commits para um repositório remoto.

Para mais informações (em inglês):

• Documentação do Git
• Capítulo sobre tags no Git

Você pode listar todas as tags disponíveis em um projeto com o comando git tag (note que elas aparecerão em ordem alfabética):

$ git tag
v1.0
v2.0
v3.0

Essa maneira de listar tags é ótima para projetos pequenos, mas projetos maiores podem ter centenas de tags. Assim, talvez seja necessário filtrá-las ao procurar um ponto importante no histórico. Você pode encontrar tags contendo caracteres específicos adicionando um -l ao comando git tag:

$ git tag -l "v2.0*"
v2.0.1
v2.0.2
v2.0.3
v2.0.4

Crie uma tag

Você pode criar dois tipos de tags: anotadas e leves. Elas são objetos concorrentes no banco de dados do GIT: elas recebem um checksum, solicitam uma mensagem (como os commits) e armazenam outros dados importantes, como nome, e-mail e data. Por outro lado, as tags leves não exigem uma mensagem nem armazenam outros dados, funcionando apenas como um ponteiro para um ponto específico no projeto.

Crie uma tag com anotações

Para criar uma tag com anotações, adicione -a nome_da_tag -m "mensagem" ao comando git tag:

$ git tag -a v4.0 -m "versão 4.0"
$ git tag
v1.0
v2.0
v3.0
v4.0

Como você pode ver, o -a especifica que você está criando uma tag com anotações, depois vem o nome_da_tag e, finalmente, o -m, seguido pela mensagem a ser armazenada no banco de dados Git.

Crie uma tag leve

As tags leves contêm apenas o checksum (nenhuma outra informação é armazenada). Para criar um, basta executar o comando git tag sem outras opções (os caracteres -lw no final do nome são usados para indicar tags leves, mas você pode marcá-los como quiser):

$ git tag v4.1-lw
$ git tag
v1.0
v2.0
v3.0
v4.0
v4.1-lw

Dessa vez, você não especificou uma mensagem ou outros dados relevantes. Portanto, a tag contém apenas o checksum referido.

Veja os dados da tag

Você pode executar o comando git show para exibir os dados armazenados em uma tag. No caso de tags com anotações, você verá os dados da tag e os dados do commit:

$ git show v4.0
tag v4.0
Tagger: John Cash <john@cash.com>
Date:   Mon Sat 28 15:00:25 2017 -0700

release version 4.0

commit da43a5fss745av88d47839247990022a98419093
Author: John Cash <john@cash.com>
Date:   Fri Feb 20 20:30:05 2015 -0700

  finished details

Se a tag que você está procurando for uma tag leve, você verá apenas os dados do commit referido:

$ git show v1.4-lw
commit da43a5f7389adcb9201ab0a289c389ed022a910b
Author: John Cash <john@cash.com>
Date:   Fri Feb 20 20:30:05 2015 -0700

  finished details

Colocando tags em commits antigos

Você também pode marcar commits passados usando git tag commit. Para fazer isso, você precisará especificar o checksum (ou pelo menos uma parte dele) na linha de comando.

Primeiro, execute git log para descobrir o checksum necessário:

$ git log --pretty=oneline
ac2998acf289102dba00823821bee04276aad9ca added products section
d09034bdea0097726fd8383c0393faa0072829a7 refactorization
a029ac120245ab012bed1ca771349eb9cca01c0b modified styles
da43a5f7389adcb9201ab0a289c389ed022a910b finished details
0adb03ca013901c1e02174924486a08cea9293a2 small fix in search textarea styles

Quando tiver o checksum de que precisa, adicione-o ao final da linha de criação da tag:

$ git tag -a v3.5 a029ac

Você verá que a tag foi adicionada corretamente ao executar git tag:

$ git tag
v1.0
v2.0
v3.0
v3.5
v4.0
v4.1-lw

Faça o push das tags

O Git não faz o push das tags por padrão ao executar o comando git push. Assim, para fazer o push das tags para um servidor, use o comando git push origin:

$ git push origin v4.0
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 3.15 KiB | 0 bytes/s, done.
Total 18 (delta 4), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
 * [new tag]         v4.0 -> v4.0

Você também pode usar a opção --tags para adicionar diversas tags ao mesmo tempo com o comando git push origin:

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
 * [new tag]         v4.0 -> v4.0
 * [new tag]         v4.1-lw -> v4.1-lw

Faça o check-out das tags

Você pode usar o comando git checkout para fazer o check-out de uma tag como você normalmente faz. É necessário, porém, lembrar que isso resultará em um estado HEAD separado.

$ git checkout v0.0.3
Note: checking out 'v0.0.3'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

Exclua uma tag

Você se verá em situações onde vai querer excluir tags. Existe um comando muito útil para esses casos:

$ git tag --delete v0.0.2
$ git tag
v0.0.1
v0.0.3
v0.0.4

Para mais informações (em inglês):

• Git Pro - o básico sobre tags
• Git Pro - documentação
• Git HowTo
• Dicas de Git: Tags
• Criando uma tag

Fontes (em inglês):

Documentação do Git: tags

O que significa fork?

Fork, ou bifurcação, é quando gostamos tanto do repositório de alguém e gostaríamos de tê-lo em nossa conta do GitHub, nós o copiamos para que possamos trabalhar com ele separadamente.

Quando copiamos um repositório, obtemos uma versão desse repositório inteiro com todo o seu histórico. Após a cópia, podemos fazer o que quisermos sem afetar a versão original.

O que é um pull request?

O pull request (algo como 'solicitação de envio', em português) é a maneira como contribuímos para projetos de grupo ou projetos de código aberto (open source).

Por exemplo, um usuário Harry copia um repositório de ThanoshanMV e faz alterações nesse repositório. Agora, Harry pode fazer um pull request para ThanoshanMV, mas cabe a ThanoshanMV aceitá-lo ou recusá-lo. É como dizer: "ThanoshanMV, você poderia aceitar minhas alterações, por favor?"

O que significa contribuir

Podemos contribuir para um projeto open source de diversas maneiras, além do código. Algumas dessas maneiras são descritas abaixo.

Como diz o guia inicial de hacktitude da empresa de tecnologia 99xtechnology, podemos contribuir para um projeto open source das seguintes maneiras:

1. Design: você pode criar os layouts de um projeto para melhorar sua usabilidade, melhorar a navegação e o menu do projeto com base em programas de pesquisa do usuário, criar arte para logotipos ou camisetas e fornecer guias de estilo para o projeto.
2. Redação: você pode escrever e melhorar a documentação do projeto ou traduzir a documentação, iniciar um boletim informativo (newsletter) para o projeto ou escrever tutoriais para ele, selecionar destaques da lista de discussão ou analisar uma pasta de exemplos mostrando como os projetos são usados.
3. Organização: você pode vincular issues duplicadas, sugerir novos labels para as issues, sugerir o fechamento de issues antigas abertas e fazer perguntas sobre issues abertas recentemente para levar a discussão adiante.
4. Ajude os outros: responda a perguntas sobre issues em aberto, revise o código nos envios de outras pessoas e ofereça-se para orientar outro colaborador.
5. Código: ajude a resolver issues em aberto, pergunte se você pode fornecer novos recursos e melhorar ferramentas e testes.

Vamos fazer nosso primeiro pull request!

Se você não está muito familiarizado com o Git e o GitHub, revise o seguinte material: The beginner’s guide to Git & GitHub (texto em inglês).

1. Faça uma cópia do repositório

Primeiro, copie o (faça o fork do) repositório. Basta clicar no botão Fork no topo da página. Isso vai criar uma versão de todo o repositório na sua conta.

2. Clone o repositório

Quando o repositório estiver na sua conta, clone-o em sua máquina para trabalhar com ele localmente.

Para clonar, clique no botão Clone e copie o link.

Abra o terminal e execute o seguinte comando. Ele clonará o repositório localmente.

$ git clone [link do github]

Agora, configuramos uma cópia da branch master do repositório principal no projeto on-line.

Precisamos ir para esse diretório clonado. Para isso, executamos este comando:

$ cd [NOME DO REPOSITORIO]

3. Crie uma branch

É uma boa prática criar uma outra branch ao trabalhar com repositórios, seja em um pequeno projeto ou contribuindo para o trabalho de um grupo.

O nome da branch deve ser curto e deve refletir o trabalho que estamos fazendo

Agora crie uma branch usando o comando git checkout:

$ git checkout -b [Nome da branch]

4. Faça mudanças e faça o commit delas

Faça alterações essenciais no projeto e salve-o.

Em seguida, execute  git status e você verá as alterações.

Adicione essas alterações na branch que você acabou de criar usando o comando  git add:

$ git add .

Agora, confirme essas alterações usando o comando git commit :

$ git commit -m "Adicionando um artigo à semana 02 dos artigos da semana."

5. Faça o push das mudanças para o GitHub

Para enviar as alterações para o GitHub, precisamos identificar o nome do repositório remoto.

$ git remote

O nome deste repositório remoto é "origin".

Depois de identificar o nome do repositório remoto, podemos enviar/fazer um push com segurança essas alterações para o GitHub.

git push origin [Nome da branch]

6. Criando o pull request

Vá para o seu repositório no GitHub e você verá um botão dizendo "Compare & pull request". Clique nele.

Forneça os detalhes necessários sobre o que você fez (você pode fazer referência às issues usando "#"). Agora, envie o pull request.

Parabéns! Você acaba de fazer o seu primeiro pull request.🎉

Se seu pull request for aceito, você receberá um e-mail.

7. Sincronize a sua versão com a branch master

Antes de enviar qualquer pull request para o repositório original, você deve sincronizar seu repositório com o original.

Mesmo se você não enviar um pull request para o repositório original, é melhor sincronizar seu repositório com o original, pois alguns recursos adicionais e correções de bugs podem ter sido feitos desde que você o copiou.

Siga estas etapas para atualizar/sincronizar essas alterações em sua branch master:

1. Primeiro, verifique em qual branch você está.

$ git branch

Ele listará todas as branches e indicará a branch atual ou ativa em verde.

2. Alterne para a branch master.

$ git checkout master

3. Adicione o repositório original como um repositório upstream.

Para extrair as alterações do repositório original para sua versão copiada, você precisa adicionar o repositório Git original como um repositório upstream.

$ git remote add upstream [HTTPS]

Aqui, [HTTPS] é o URL que você deve copiar do repositório do proprietário.

4. Faça o fetch/obtenha o repositório.

Busque todas as alterações do repositório original. Os commits para o repositório original serão armazenados em uma branch local chamada upstream/master.

$ git fetch upstream

5. Faça o merge/mescle as branches.

Mescle as alterações do upstream/master em sua branch master local. Isso fará com que a branch master do seu fork seja sincronizada com o repositório upstream sem perder suas alterações locais.

$ git merge upstream/master

6. Faça o push/envie mudanças ao GitHub

Neste ponto, sua branch local é sincronizada com a branch master do repositório original. Se você deseja atualizar o repositório do GitHub, precisa enviar suas alterações.

$ git push origin master

Observação: depois de sincronizar o fork da sua branch master copiada, você pode remover esse repositório remoto, se desejar, mas você também precisará atualizar/sincronizar seu repositório no futuro, então é melhor mantê-lo.

$ git remote rm [Nome remoto]

8. Delete a branch desnecessária

As branches são criadas para um propósito especial. Uma vez que esse objetivo é alcançado, essas branches não são necessárias, então você pode excluí-las.

$ git branch -d [Nome da branch]

Você também pode excluir a versão dele no GitHub.

git push origin --delete [Nome da branch]

Conclusão

O GitHub é uma ferramenta poderosa para controlar o histórico de versões. Todos podem contribuir com projetos open source fazendo pull requests. Contribuições nem sempre são código – existem outras maneiras de contribuir também.

Por fim, devo dizer que você não deve se preocupar se seus pull requests forem rejeitados. Os mantenedores gastam muito tempo melhorando seus projetos e sabem muito mais sobre seus projetos do que nós. Portanto, não se preocupe se sua solicitação não for mesclada.

Mantenha-se forte, mantenha-se positivo e nunca desista.
― Roy T. Bennett, The Light in the Heart

Este artigo foi publicado originalmente no Medium.

Você pode entrar em contato com o autor e se conectar com ele pelo Twitter.
Continue contribuindo com o mundo open source!

Se você é um desenvolvedor e usa o Git em um de seus projetos, pode ser que queira compartilhar com seus usuários as alterações que fez, mas não sabe como fazer isso. Bem, este artigo é para você.

Em outro momento em minha série de artigos, compartilhei como escrever uma boa mensagem de commit (texto em inglês).

Já mostrei os benefícios de se escrever uma boa mensagem de commit, bem como já havia mencionado a possibilidade de gerar um changelog (em português, algo como um registro das alterações).

Neste artigo, você saberá o que é um changelog e verá duas maneiras de gerá-lo – uma simples e outra um pouco mais sofisticada.

O que é um changelog?

Um changelog é um arquivo que compartilha uma lista cronologicamente ordenada das alterações qu você realizou em seu projeto. Ele geralmente é organizado por versão, com a data seguida de uma lista de recursos adicionados, melhorados ou removidos.

Em geral, há duas maneiras de se escrever um changelog:

• a maneira comum: criar um arquivo de texto e começar a enumerar todas as alterações com uma data específica
• a escolha do desenvolvedor (também conhecida como o modo fácil): gerar automaticamente o changelog a partir de suas mensagens de commit. A boa notícia é que será exatamente essa a maneira que você aprenderá neste artigo!

"Um changelog é um relato ou registro de todas as alterações importantes feitas em um projeto. O projeto geralmente é um site da web ou um projeto de software. O changelog frequentemente inclui registros de alterações como consertos de bugs, novos recursos e assim por diante." – Wikipédia

Por que ele é essencial?

Imagino que, nesse momento, você esteja se perguntando o porquê de ele ser essencial e por que dedicar um tempo para sua criação.

Um changelog é uma espécie de resumo de todas as suas alterações. Ele deve ser fácil de entender para os usuários de seu projeto e para os desenvolvedores que trabalharem nele.

Em um mundo onde tudo se desenvolve rapidamente, o usuário precisa saber se o site da web/software que ele está usando passou por alterações. Você pode se surpreender por isso, mas há quem adore ler publicações em blogs ou páginas de atualizações dos sites da web.

Para um desenvolvedor, por exemplo, se o projeto for grande, pode ser interessante saber como o software no qual ele está trabalhando vem evoluindo.

Se, em contrapartida, você estiver trabalhando em um projeto de código aberto (do inglês, open-source), você poderá encontrar um arquivo "CHANGELOG.md" no repositório do GitHub. O objetivo desse arquivo é informar os colaboradores sobre as atualizações mais recentes do projeto.

Onde eu posso encontrá-lo?

Você verá changelogs em todo o lugar! Claro, eles, frequentemente, têm estilos diferentes e se encontram em locais diferentes, mas eles estão (ou deveriam estar), literalmente, em todos os projetos.

Criei aqui uma lista com alguns lugares onde você pode encontrar um changelog.

• Uma publicação em blog: um changelog pode ser entregue como um artigo compartilhando os últimos recursos, ponto a ponto.
• Um arquivo "CHANGELOG.md" no repositório do GitHub.
• Uma seção de Changelog no seu site da web/software favorito. Aqui temos um exemplo com uma ferramenta de gerenciamento de tarefas, o TickTick.
• Na seção "What's new" (em português, novidades) nas lojas do Android e do IOS.

Geração automática do changelog

Nesta parte, vamos gerar juntos nosso primeiro changelog.

Ao fazer isso, você entenderá a razão pela qual pode ser útil fazer os commits e suas mensagens seguindo algumas regras.

Um commit excelente e explícito não precisa ser modificado e pode ser adicionado diretamente ao changelog.

Se estiver interessado em gerar um arquivo necessário sem o personalizar ou estilizar, recomendo a primeira maneira. Do contrário, a segunda é melhor.

Observação: alguns sites da web, como o Keep A Changelog, explicam que você não deve fazer um changelog simplesmente copiando e colando as mensagens de commit do Git (veja a maneira simples). De fato, eu recomendo tentar evitar essa maneira se estiver trabalhando em um produto profissional.

No entanto, hoje em dia, existem alguns geradores avançados que permitem que você transforme seus logs do Git em changelogs (veja a maneira sofisticada).

Como gerar um changelog (a maneira simples)

Se você usar a primeira maneira, não há pré-requisitos a cumprir. Tudo o que você precisa fazer é digitar alguns comandos no repositório do Git.

Apenas para lembrar, ao digitar "git log", uma lista de todos os seus commits é exibida.

$ git log

// Resultado
commit f6986f8e52c1f889c8649ec75c5abac003102999 (HEAD -> master, origin/master, origin/HEAD)
Author: Sam Katakouzinos <sam.katakouzinos@gmail.com>
Date:   Tue Mar 10 11:41:18 2020 +1100

    docs(developers): commit message format typo
    
    Any line of the commit message cannot be longer *than* 100 characters!
    
    Closes #17006

commit ff963de73ab8913bce27a1e75ac01f53e8ece1d9
Author: Chives <chivesrs@gmail.com>
Date:   Thu Feb 6 19:05:57 2020 -0500

    docs($aria): get the docs working for the service
    
    Closes #16945

commit 2b28c540ad7ebf4a9c3a6f108a9cb5b673d3712d
Author: comet <hjung524@gmail.com>
Date:   Mon Jan 27 19:49:55 2020 -0600

    docs(*): fix spelling errors
    
    Closes #16942

Esse comando pode receber alguns parâmetros. Usaremos esses parâmetros para alterar o resultado e para obter uma versão melhorada para gerar nosso changelog.

Ao digitar o comando a seguir, você terá como resultado um commit por linha.

$ git log --oneline --decorate

// Resultado
f6986f8e5 (HEAD -> master, origin/master, origin/HEAD) docs(developers): commit message format typo
ff963de73 docs($aria): get the docs working for the service
2b28c540a docs(*): fix spelling errors
68701efb9 chore(*): fix serving of URI-encoded files on code.angularjs.org
c8a6e8450 chore(package): fix scripts for latest Node 10.x on Windows
0cd592f49 docs(angular.errorHandlingConfig): fix typo (wether --> whether)
a4daf1f76 docs(angular.copy): fix `getter`/`setter` formatting
be6a6d80e chore(*): update copyright year to 2020
36f17c926 docs: add mention to changelog
ff5f782b2 docs: add mention to changelog
27460db1d docs: release notes for 1.7.9
add78e620 fix(angular.merge): do not merge __proto__ property

Já ficou melhor, mas vamos ver o que podemos fazer além disso.

$ git log --pretty="%s"

// Resultado
docs(developers): commit message format typo
docs($aria): get the docs working for the service
docs(*): fix spelling errors
chore(*): fix serving of URI-encoded files on code.angularjs.org
chore(package): fix scripts for latest Node 10.x on Windows
docs(angular.errorHandlingConfig): fix typo (wether --> whether)
docs(angular.copy): fix `getter`/`setter` formatting
chore(*): update copyright year to 2020
docs: add mention to changelog
docs: add mention to changelog
docs: release notes for 1.7.9
fix(angular.merge): do not merge __proto__ property

Com ele, você pode imprimir a lista dos commits no estilo que você quiser.

O "%s" corresponde ao próprio título do commit. Você pode modificar a string para estilizar seu commit como quiser.

Em nosso caso, queremos criar uma lista.

$ git log --pretty="- %s"

// Resultado
- docs(developers): commit message format typo
- docs($aria): get the docs working for the service
- docs(*): fix spelling errors
- chore(*): fix serving of URI-encoded files on code.angularjs.org
- chore(package): fix scripts for latest Node 10.x on Windows
- docs(angular.errorHandlingConfig): fix typo (wether --> whether)
- docs(angular.copy): fix `getter`/`setter` formatting
- chore(*): update copyright year to 2020
- docs: add mention to changelog
- docs: add mention to changelog
- docs: release notes for 1.7.9
- fix(angular.merge): do not merge __proto__ property

Você conseguiu! Acaba de criar um changelog simples.

Observação: se ainda quiser ir mais longe e salvar seu changelog mais rapidamente, em vez de copiar e colar o resultado em um arquivo, redirecione o resultado para um arquivo em seu terminal, digitando git log --pretty="- %s" > CHANGELOG.md

Como gerar um changelog (a maneira sofisticada)

Pré-requisitos

Agora, trataremos de uma maneira sofisticada de gerar um changelog. A ideia por trás do processo segue a mesma, mas, desta vez, usaremos outras ferramentas para nos ajudar.

Na parte anterior desta série que mencionei previamente, eu escrevi sobre diretrizes do Git.

Observação: as diretrizes do Git são um conjunto de regras para escrever mensagens de commit melhores. Essas diretrizes ajudarão você a adicionar um pouco de estrutura aos commits.

Ao usar uma diretriz para o seu projeto, você pode usar ferramentas para gerar um changelog. Na maioria das vezes, essas ferramentas são melhores, pois permitem que você crie um changelog formatado em markdown.

Neste exemplo, usaremos um gerador simples, que funciona com a maioria das diretrizes. Seu nome é "generate-changelog" e ele está disponível no NPM (o gerenciador de pacotes do Node).

Essa ferramenta criará um changelog estilizado, mas não é a ferramenta com o maior número de recursos. Decidi usá-la, pois é um exemplo excelente para um iniciante. Se quiser se aprofundar, consulte a lista de ferramentas de changelog abaixo:

Aqui temos algumas ferramentas que você pode usar:

• Github Changelog Generator
• Git Chglog
• Auto Changelog
• Conventional Changelog

Observação: antes de instalar a ferramenta, você precisa ter o NPM instalado em seu computador. Se ainda não o tem, convido você a visitar o site oficial da web (ele ajudará na instalação do Node e do NPM).

Para instalar o pacote em seu computador, digite o comando a seguir no seu terminal:

$ npm install generate-changelog -g 

Ao fazer isso, ele será instalado!

Como usar

Para fazer com que o pacote funcione, você precisa seguir as diretrizes de uso neste padrão – "tipo(categoria): descrição [flags]". Neste exemplo, usarei o repositório do Angular.js no GitHub.

Agora, você pode digitar o comando generate no seu terminal dentro do repositório do GitHub.

$ changelog generate

Um arquivo "CHANGELOG.md" será criado automaticamente e preenchido com seus logs em formato markdown.

Veja aqui um exemplo de resultado (com um leitor de markdown, como o GitHub).

Conclusão

Espero que você tenha gostado deste guia e que, agora, entenda como criar um changelog para o seu projeto. Acho uma boa maneira de demonstrar por que devemos escrever boas mensagens de commit.

Fique à vontade para experimentar outros geradores de changelog!

Se quiser mais conteúdo deste tipo, siga o autor no Twitter, onde ele escreve sobre desenvolvimento para a web, melhoramento pessoal e sobre sua jornada como desenvolvedor full-stack!

O Git é um sistema de controle de versão distribuído que ajuda desenvolvedores a colaborar em projetos de qualquer dimensão.

Linus Torvalds, criador do Linux, criou o Git em 2005 para ajudar no controle do desenvolvimento do núcleo do Linux.

O que é o controle de versão distribuído?

Um sistema de controle de versão distribuído é um sistema que ajuda você a acompanhar as alterações feitas nos arquivos do seu projeto.

Esse histórico de alterações fica na sua máquina local e permite reverter para uma versão anterior do seu projeto de maneira fácil caso algo dê errado.

O Git facilita a colaboração. Todas as pessoas da equipe podem manter uma cópia completa dos repositórios em que estão trabalhando em sua máquina local. Então, graças a um servidor externo, como BitBucket, GitHub ou GitLab, eles podem armazenar o repositório em um único lugar.

Desse modo, diferentes membros do time podem fazer uma cópia local e todos têm uma visão geral de quaisquer alterações feitas por todos.

O Git possui diversos comandos que você pode usar. Percebi que esses cinquenta são os que uso com mais frequência (portanto, são os mais úteis de se lembrar).

Então, eu escrevi este artigo e pensei que seria interessante compartilhá-lo com a comunidade. Espero que você o ache útil – aproveite.

Como verificar sua configuração do Git:

O comando abaixo retorna uma lista de informações sobre sua configuração do Git, incluindo nome de usuário e e-mail:

git config -l

Como configurar seu nome de usuário do Git:

Com o comando abaixo você pode configurar seu nome de usuário:

git config --global user.name "Fabio"

Como configurar seu e-mail de usuário do Git:

Este comando permite configurar o endereço de e-mail utilizado em seus commits:

git config --global user.email "signups@fabiopacifici.com"

Como armazenar em cache suas credenciais de acesso do Git:

Você pode armazenar suas credenciais de acesso no cache para não precisar digitá-las sempre. Basta usar este comando:

git config --global credential.helper cache

Como inicializar um repositório Git:

Tudo começa aqui. O primeiro passo é inicializar um novo repositório do Git localmente na raiz do seu projeto. Você pode fazer isso com o comando abaixo:

git init

Como adicionar um arquivo à área de preparação (staging) no Git:

O comando abaixo adicionará um arquivo à área de preparação. Basta substituir nome_do_arquivo pelo nome do arquivo que você deseja adicionar à área de preparação.

git add nome_do_arquivo

Como adicionar todos os arquivos à área de preparação no Git:

Se você quiser adicionar todos os arquivos do seu projeto à área de preparação, você pode usar o caractere curinga . e todos os arquivos serão adicionados para você.

git add .

Como adicionar apenas arquivos específicos à área de preparação no Git:

Com o asterisco no comando abaixo, você pode adicionar todos os arquivos que se iniciam com 'arq' à área de preparação.

git add arq*

Como verificar a situação de um repositório no Git:

Este comando mostrará a situação do repositório atual, incluindo arquivos na área de preparação, fora da área de preparação e não monitorados.

git status

Como enviar alterações usando o editor no Git:

Este comando abrirá um editor de texto no terminal, onde você pode escrever uma mensagem de commit completa.

Uma mensagem de commit é composta por um pequeno resumo das mudanças, uma linha vazia e uma descrição completa das alterações depois dela.

git commit

Como enviar alterações com uma mensagem no Git:

Você pode adicionar uma mensagem de commit sem abrir o editor. Este comando permite que você especifique apenas um pequeno resumo para sua mensagem de commit.

git commit -m "sua mensagem para o commit vai aqui"

Como enviar alterações (e pular a área de preparação) no Git:

Você pode adicionar e submeter arquivos rastreados com um único comando utilizando as opções -a e -m.

git commit -a -m "sua mensagem para o commit vai aqui"

Como ver seu histórico de commits no Git:

Este comando mostra o histórico de commits do repositório atual:

git log

Como ver seu histórico de commits e alterações no Git:

Este comando mostra o histórico de commits incluindo todos os arquivos e suas alterações:

git log -p

Como ver um commit específico no Git:

Esse comando mostra um commit específico.

Substitua commit-id pelo id do commit que você encontra no registro depois da palavra commit.

git show commit-id

Como ver estatísticas do registro no Git:

Este comando fará com que o registro do Git mostre algumas estatísticas das alterações de cada commit, incluindo linha(s) alterada(s) e nomes de arquivo.

git log --stat

Como ver as alterações feitas antes de enviá-las usando "diff" no Git:

Você pode passar um arquivo como parâmetro para ver apenas as alterações de um arquivo específico. git diff, por padrão, mostra apenas alterações fora da área de preparação.

Podemos usar "diff" com a opção --staged para ver quaisquer mudanças na área de preparação.

git diff
git diff all_checks.py
git diff --staged

Como ver as alterações usando "git add -p":

Este comando abre um prompt e pergunta se você quer colocar as alterações na área de preparação ou não, entre outras opções.

git add -p

Como remover arquivos rastreados da árvore de trabalho atual no Git:

Este comando espera uma mensagem de commit que explique por que o arquivo foi excluído.

git rm nome_do_arquivo

Como renomear arquivos no Git:

Este comando adiciona a alteração na área de preparação e, em seguida, espera uma mensagem de commit.

git mv nome_antigo_do_arquivo novo_nome_de_arquivo

Como ignorar arquivos no Git:

Crie um arquivo .gitignore e faça o commit desse arquivo.

Como reverter alterações em arquivos fora da área de preparação do Git:

git checkout nome_do_arquivo

Como reverter alterações em arquivos na área de preparação do Git:

Você pode utilizar a opção -p para especificar as mudanças que gostaria de redefinir.

git reset HEAD nome_do_arquivo
git reset HEAD -p

Como modificar o commit mais recente no Git:

git commit --amend permite que você modifique e faça alterações no commit mais recente.

git commit --amend

OBSERVAÇÃO: corrigir um commit local com --amend  é ótimo e você pode enviá-lo para um repositório compartilhado após a correção. Você, no entanto, deve evitar alterações em commits que já se tornaram públicos ou que já foram enviados ao repositório remoto.

Como reverter o último commit no Git:

git revert criará um commit que reverterá tudo o que foi feito no commit em questão.  Podemos reverter o commit mais recente usando a expressão HEAD, assim:

git revert HEAD

Como reverter um commit antigo no Git:

Você pode reverter um commit antigo usando a id desse commit. Isso abre um editor onde você pode adicionar uma mensagem nova de commit.

git revert comit_id_aqui

Como criar uma nova branch no Git:

Por padrão, você tem uma branch, a main. Com este comando, você pode criar uma nova branch. Após a criação, o Git não muda para ela automaticamente – você deverá fazer isso manualmente com o próximo comando.

git branch nome_da_branch

Como mudar para uma branch recém-criada no Git:

Quando quiser usar uma branch diferente da atual ou a branch recém-criada, você pode usar este comando:

git checkout nome_da_branch

Como listar as branches no Git:

Você pode visualizar todas as branches criadas usando o comando git branch . Ele mostrará uma lista com todas as branches e marcará a branch atual com um asterisco e em destaque na cor verde.

git branch

Como criar uma branch no Git e mudar para ela imediatamente:

Em um comando único, você pode criar e mudar para uma nova branch imediatamente.

git checkout -b nome_da_branch

Como excluir uma branch no Git:

Após terminar o trabalho em uma branch e depois de ter feito o merge, você pode excluí-la usando o comando abaixo:

git branch -d nome_da_branch

Como fazer o merge (junção) de duas branches no Git:

Para fazer o merge do histórico da branch atual com o da branch nome_da_branch, você precisará usar o comando abaixo:

git merge nome_da_branch

Como mostrar o registro de commits como um gráfico no Git:

Podemos usar --graph para mostrar o registro de commits como um gráfico. Além disso, --oneline serve para limitar as mensagens de commit em uma única linha.

git log --graph --oneline

Como mostrar o registro de commits de todas as branches como um gráfico no Git:

Faz o mesmo que o comando acima, porém para todas as branches.

git log --graph --oneline --all

Como interromper um merge em conflito no Git:

Se você quiser se desfazer de um merge e começar de novo, você pode executar o seguinte comando:

git merge --abort

Como adicionar um repositório remoto no Git:

Esse comando adiciona um repositório remoto ao local (basta substituir https://repositorio_aqui pelo URL do repositório remoto).

git add remote https://repositorio_aqui

Como ver os URLs remotos no Git:

Você pode ver todos os repositórios remotos vinculados ao seu repositório local com este comando:

git remote -v

Como obter mais informações sobre um repositório remoto no Git:

Basta substituir origin pelo nome do repositório remoto obtido executando o comando git remote -v.

git remote show origin

Como enviar as alterações para um repositório remoto no Git:

Quando todo seu trabalho estiver pronto para ser salvo em um repositório remoto, você pode enviar todas as mudanças usando o comando abaixo:

git push

Como obter as mudanças de um repositório remoto no Git:

Se outros membros da equipe estiverem trabalhando no seu repositório, você pode obter as últimas mudanças feitas no repositório remoto com o comando abaixo:

git pull

Como verificar branches remotas rastreadas pelo Git:

Este comando mostra o nome de todas as branches do repositório local que o Git está rastreando:

git branch -r

Como buscar as mudanças em repositórios remotos no Git:

Este comando baixará as mudanças de um repositório mas não realizará o merge com a sua branch local (isso é o que git pull faz).

git fetch

Como verificar o registro de commits atual de um repositório remoto no Git:

Commit após commit, o Git cria um registro. Você pode descobrir o registro de um repositório remoto usando este comando:

git log origin/main

Como fazer o merge de um repositório remoto com seu repositório local no Git:

Se o repositório remoto tiver mudanças que você gostaria de mesclar ao repositório local, este comando fará isso para você:

git merge origin/main

Como obter o conteúdo das branches remotas no Git sem fazer o merge automático:

Isso permite que você atualize o remoto sem que nenhum conteúdo seja mesclado às branches locais. Você pode usar git merge ou git checkout para fazer o merge.

git remote update

Como enviar uma nova branch para um repositório remoto no Git:

Se você quiser enviar uma branch para um repositório remoto, você pode usar o comando abaixo. Basta lembrar de adicionar -u para criar a branch no repositório remoto:

git push -u origin nome_da_branch

Como remover uma branch remota no Git:

Se você não precisa mais de uma branch remota, você pode removê-la usando o comando abaixo:

git push --delete origin nome_da_branch_aqui

Como utilizar o Git rebase:

Você pode transferir o trabalho concluído de uma branch para outra utilizando o  git rebase.

git rebase nome_da_branch_aqui

O comando git rebase pode ficar desorientado se você não o fizer corretamente. Antes de usar esse comando, sugiro que você releia aqui a documentação oficial (em inglês).

Como executar o rebase de modo interativo no Git:

Você pode executar o rebase de modo interativo usando a opção -i.
Isso abrirá o editor com um conjunto de comandos que você pode usar.

git rebase -i master
# p, pick = usa o commit
# r, reword = usa o commit, mas edita a mensagem
# e, edit = usa o commit, mas interrompe para correção
# s, squash = usa o commit, mas funde em commits anteriores
# f, fixup = similar a "squash", mas descarta o registro de mensagem do commit em questão
# x, exec = executa o comando (o resto da linha) usando shell
# d, drop = remove o commit

Como forçar uma requisição de push no Git:

Este comando forçará uma requisição de push. Isso geralmente é bom para branches de pull request, pois ninguém mais deveria tê-las clonado.
Isso, porém, não deve ser feito em repositórios públicos.

git push -f

Conclusão

Esses comandos podem melhorar drasticamente sua produtividade no Git. Você não precisa se lembrar de todos eles – foi por isso que escrevi esta ficha informativa. Coloque essa página nos seus favoritos para referência futura ou imprima-a, se quiser.

Obrigado pela leitura!  O texto foi escrito por Fabio Pacifici, um desenvolvedor full-stack para a web, professor e profissional certificado em automação com Python. Se você achar esta ficha informativa útil, certamente encontrará algo interessante no canal do autor no YouTube. Você pode se inscrever aqui.

(Tradução realizada em português europeu)

O Git é um sistema de controlo de versões, distribuído e de código aberto. Ora, isto são muitas palavras para definir o Git.

Vamos decompor esta definição complexa e explicar cada um dos conceitos:

• Sistema de controlo: isto significa que o Git é, basicamente, um tracker de conteúdo. Portanto, o Git pode ser usado para guardar conteúdo – É usado, principalmente, para armazenar código, devido às outras funcionalidades que disponibiliza.
• Sistema de controlo de versões: O código que é guardado no Git está em constante mutação à medida que novo código é adicionado. Além disso, muitos programadores podem adicionar código em paralelo. O sistema de controlo de versões, ajuda a gerir tudo isto, mantendo um histórico das alterações que foram realizadas. Adicionalmente, o Git disponibiliza funcionalidades como branches e merges, que explicaremos mais tarde.
• Sistema distribuído de controlo de versões : O Git tem um repositório remoto que está alojado em um servidor e um repositório local que está alojado no computador de cada programador. Isto significa que o código não está apenas guardado num servidor central, mas também existe uma cópia integral em todos os computadores dos programadores. Assim, o Git é um sistema distribuído de controlo de versões porque está presente no computador de cada programador. Explicaremos o conceito de repositórios remotos e locais, posteriormente, neste artigo.

Por que precisamos de um Sistema de Controlo de Versões como o Git

Os projetos na vida real implicam a colaboração em paralelo de vários programadores. Por isso, é necessário um sistema de controlo de versões, como o Git, para garantir que não existem conflitos entre o código desenvolvido por diferentes pessoas.

Adicionalmente, os requisitos destes projectos são alterados com muita frequência. Um sistema de controlo de versões permite que os programadores possam reverter alterações e voltar a uma versão anterior do código.

Finalmente, por vezes, existem projetos que estão a decorrer em paralelo e que partilham o mesmo código base. Nestes casos, o conceito de criação de branches do Git é muito importante.

Agora, vamos começar a usar o Git.

Em vez de abordarmos os conceitos todos de uma só vez, vamos explicar cada um deles, através de um exemplo, para um entendimento mais fácil.

Download do Git

Esta ligação tem as instruções para instalação do Git em diversos sistemas operativos:
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Verifica que o Git está instalado, usando a seguinte instrução através da linha de comandos:

git --version

Criar o repositório local do Git

No teu computador, cria uma pasta para o teu projecto. Vamos dar-lhe o nome  simple-git-demo.

Entra na tua pasta do projecto e adiciona um repositório local do Git através dos seguintes comandos:

cd simple-git-demo
git init

O comandogit init adiciona um repositório local do Git ao teu projecto.

Agora, vamos adicionar algum código simples.

Agora vamos adicionar algum código

Cria um ficheiro com o nome demo.txt na pasta de projecto e adiciona-lhe o seguinte texto:

Initial Content

Aqui, vamos usar texto simples em vez de código, uma vez que o foco do artigo é o Sistema Git e não uma linguagem de programação específica.

Staging e committing do código.

Committing é o processo através do qual o código é adicionado ao repositório local. Antes de ser possível realizar o commit do código, ele tem de estar na área de staging. A área de staging existe para registar todas as alterações realizadas aos ficheiros e que serão posteriormente alvo de commit.

Qualquer ficheiro que não seja adicionado à área de staging, não poderá ser alvo de commit. Isso permite que o programador tenha controlo sobre quais os ficheiros que necessitam de ser alvo de commit.

Staging

Usa o seguinte commando para realizar o staging do ficheiro:

git add demo.txt

Caso pretendas realizar o staging de vários ficheiros, podes usar:

git add file1 file2 file3

Se quiseres adicionar, todos os ficheiros dentro da pasta de projecto, na área de staging, podes usar o seguinte comando:

git add .

Usa este comando com cuidado, porque ele adiciona, à área de staging, todos os ficheiros e pastas existentes no teu projecto.

Committing

Para realizar o commit do ficheiro, usa o seguinte comando:

git commit -m "Initial Commit"

"Initial Commit" é a mensagem de commit inicial. Deves sempre criar uma mensagem de commit que seja relevante e indicativa das alterações ao código que foram realizadas em cada commit.

Git Status e Git Log

Agora, vamos modificar o ficheiro demo.txt e adicionar o seguinte texto:

Initial Content Adding more Content

Status

Usa o comando git status para descobrires informação sobre que ficheiros foram modificados e quais estão na área de staging – é também apresentada informação adicional, que pode ser ignorada para já.

Usa o seguinte comando para veres o status:

git status

O status mostra que o ficheiro demo.txt foi modificado e ainda não está na área de staging.

Agora, vamos adicionar o ficheiro demo.txt para a área de staging e fazer o commit usando os seguintes comandos:

git add demo.txt git commit -m "demo.txt file is modified"

Log

Usa o comandogit log para obteres uma impressão de todos os commits realizados até ao momento.

O comando usado é: git log

O log mostra quem foi o autor, a data e a mensagem de cada commit

Branches

Até agora, não criamos branches no Git. Por definição, o Git realiza os commits na branch master.

O que é uma branch

Uma branch não é mais do que um ponteiro para o último commit no repositório Git. Portanto, actualmente, a nossa master branch é um ponteiro para o segundo commit  “demo.txt file is modified”.

Por que são necessárias várias branches?

As branches são necessárias para suportar vários desenvolvimentos em paralelo. No diagrama apresentado de seguida, temos uma representação do funcionamento das branches.

Inicialmente, o commit 1 e o commit 2 são realizados na branch master. Depois do commit 2, é criada uma branch com o nome "Test". O commit 3 e o commit 4 são adicionados à branch Test.

Ao mesmo tempo, outros commits,  commit 3 e commit 4 são adicionados à branch master. Aqui, conseguimos ver que, após o commit 2, estão a ser realizados dois desenvolvimentos em paralelo, em duas branches separadas.

A branch Test e a branch Master divergiram neste ponto e têm códigos diferentes – o código da branch Test pode ser mesclado (do inglês, merged) com a branch Master usando o comando git merge. Posteriormente, falaremos desse processo.

Criar uma branch no repositório local.

Cria uma branch chamada test usando o seguinte comando:

git branch test

Este comando cria a branch test.

Ainda estamos no contexto da branch master. Para mudarmos para a branch test, usamos o seguinte comando:

git checkout test

Agora estamos na branch test.

Podes obter uma lista de todas as branches existentes no repositório local usando o seguinte comando:

git branch

Executa alguns commits na nova branch

Modifica demo.txt adicionando o seguinte código:

Initial Content Adding more Content Adding some Content from test Branch

Agora executa o stage e o commit com os seguintes comandos:

git add demo.txt git commit -m "Test Branch Commit"

Este commit foi realizado na branch Test. Agora, a branch Test está avançada em relação à branch Master em 1 commit  — porque a branch Test também possui 2 commits da branch master.

Podes verificar o histórico de commits da branch Test com o comando:

git log

Merging

Neste momento, a branch Test está avançada em 1 commit em relação à branch Master. Vamos supor que agora precisamos que todo o código da branch Test seja colocado na branch Master. Esta é a situação em que o comando git merge é muito útil.

Para conseguirmos fazer o merge do código da branch test na branch master, basta seguir os seguintes passos:

Primeiro, voltar à branch master:

git checkout master

Depois, executar o comando merge:

git merge test

Depois de executar esses 2 comandos, o merge deverá estar concluído com sucesso. Neste exemplo, não existem conflitos.

Em projectos reais, contudo, é possível que existam conflitos quando se executa um merge. Para resolver estes conflitos, é necessária alguma experiência, algo que adquirirás à medida que a tua familiarização e que o tempo de trabalho com o Git aumente.

Agora, corre o comando git log e vais reparar que a branch master também possui 3 commits.

O repositório remoto do Git

Até agora, temos estado a trabalhar apenas no repositório local. Cada programador trabalhará no seu repositório local, mas, eventualmente, terão a necessidade de fazer push do seu código para o repositório remoto. Assim que o código estiver no repositório remoto, outros programadores serão capazes de ver e modificar esse código.

GitHub

Aqui, vamos passar a usar o GitHub para o repositório remoto.

Navega para o link: https://github.com/ e cria uma conta.

Depois do registo na homepage do GitHub, clica em Start a Project para criares um repositório Git. Dá um nome ao repositório e clica em "Create Repository"

Dá um nome como git-blog-demo.

Isto vai criar um repositório remoto no Github e, quando abrires o repositório, será aberta uma página idêntica à apresentada abaixo:

O URL do repositório é o texto destacado em cima.

https://github.com/aditya-sridhar/git-blog-demo.git

Para apontares o teu repositório local para o repositório remoto, usa este comando:

git remote add origin [url do repositório]

Git Push

Para fazermos push de todo o código do repositório local para o repositório remoto, usamos o seguinte comando:

git push -u origin master

Este comando realiza o push (actualização) do código da branch master no repositório local para a branch master do repositório remoto.

Comandos adicionais

Git Pull

git pull é usado para fazer pull das últimas alterações no repositório remoto para o teu repositório local. O código do repositório remoto é constantemente atualizado por vários programadores. Isso justifica a necessidade do comando git pull :

git pull origin master

Git Clone

git clone é usado para clonar um repositório remoto, já existente, para o teu computador. O comando a usar é:

git clone [repository url]

Parabéns

Agora que conheces os conceitos básicos necessários para usar o Git, aventura-te e explora mais!

Em breve, publicarei um novo artigo sobre conceitos um pouco mais avançados do Git. Mantém-te atento!

Sobre o autor

O autor adora tecnologia e segue atentamente todos os avanços. Ele também gosta de ajudar os outros com o seu conhecimento na área tecnológica.

Conecte-se ao autor em sua conta do LinkedIn

Também é possível seguir o autor no Twitter

Site do autor

Outras publicações do autor (em inglês)

How to use Git efficiently

Git e GitHub são duas tecnologias que todo desenvolvedor deve aprender, independentemente de sua área.

Se você é um desenvolvedor iniciante, pode pensar que esses dois termos significam a mesma coisa, mas são diferentes.

Este tutorial ajudará você a entender o que é Git e controle de versão, os comandos básicos do Git que você precisa conhecer, como você pode usar seus recursos para aumentar a eficiência do seu trabalho e como estender esses recursos usando o GitHub.

Este guia é voltado a iniciantes, pois os exemplos serão muito fáceis de entender. Também será um tutorial generalizado para que qualquer pessoa possa acompanhar, não importa qual seja sua linguagem de programação favorita.

Para nosso projeto, faremos uma lista de tarefas escrita em um arquivo de texto (txt). Você verá como podemos usar os recursos do Git para trabalhar e criar uma versão final da lista.

Pré-requisitos

Para concluir este tutorial, você precisará do seguinte:

• Uma interface de linha de comando, um terminal.
• Um editor de texto de sua escolha (usarei o VS Code).
• Uma conta no GitHub.

O que é Git?

O Git é um sistema de controle de versão que permite rastrear as alterações feitas em seus arquivos ao longo do tempo. Com o Git, você pode reverter para vários estados de seus arquivos (como se usasse uma máquina do tempo). Você também pode fazer uma cópia do arquivo, fazer alterações nessa cópia e mesclar essas alterações na versão original.

Por exemplo, você pode estar trabalhando na página de destino de um site e descobrir que não gosta da barra de navegação. Ao mesmo tempo, você pode ficar apreensivo em começar a alterar seus componentes, porque o resultado pode ser pior.

Com o Git, você pode criar uma cópia idêntica desse arquivo e mexer na barra de navegação. Então, quando estiver satisfeito com suas alterações, poderá mesclar a cópia ao arquivo original.

Você não está limitado a usar o Git apenas para arquivos de código-fonte – você também pode usá-lo para acompanhar arquivos de texto ou até imagens. Isso significa que o Git não é apenas para desenvolvedores – qualquer um pode achá-lo útil.

Como instalar o Git

Para usar o Git, você precisa instalá-lo em seu computador. Para fazer isso, você pode baixar a versão mais recente no site da web oficial. Você pode fazer o download para o seu sistema operacional a partir das opções fornecidas.

Você também pode instalar o Git usando a linha de comando, mas, como os comandos variam de acordo com cada sistema operacional, vamos nos concentrar na abordagem mais geral.

Como configurar o Git

Vou assumir que, neste ponto, você já instalou o Git. Para verificar isso, você pode executar este comando no terminal: git --version. Ele mostra a versão atual instalada no seu PC.

A próxima coisa que você precisa fazer é definir seu nome de usuário e endereço de e-mail. O Git usará essas informações para identificar quem fez alterações específicas nos arquivos.

Para definir seu nome de usuário, digite e execute estes comandos: git config --global user.name "SEU_NOME_DE_USUARIO" e git config --global user.email "SEU_E-MAIL". Apenas certifique-se de substituir "SEU_NOME_DE_USUARIO" e "SEU_E-MAIL" pelos valores que você escolher — ou seja, seu nome de usuário e seu e-mail reais.

Como criar e inicializar um projeto no Git

Após terminarmos de instalar e configurar o Git, agora é hora de criar nosso projeto.

Eu criei uma pasta, no meu desktop, chamada Git and GitHub tutorial. Usando a linha de comando, navegue até o local do seu novo projeto. Para mim, eu executaria os seguintes comandos:

cd desktop

cd Git and GitHub tutorial

Se você conhece a linha de comando há pouco e ainda está aprendendo a usá-la para navegar pelo seu PC, sugiro usar o Visual Studio Code da Microsoft. É um editor de código que possui um terminal embutido para executar comandos. Você pode baixá-lo aqui.

Depois de instalar o VS Code, abra seu projeto no editor e abra um novo terminal para seu projeto. Isso apontará automaticamente o terminal/linha de comando para o caminho do seu projeto.

Agora, para inicializar um repositório do seu projeto, basta executar git init. Isso dirá ao Git para começar a observar seus arquivos a cada alteração que ocorrer. Esta é a aparência na linha de comando/terminal:

A primeira linha tem informações sobre meu PC e o caminho para a pasta. A segunda linha é o comando git init e a terceira linha é a resposta enviada de volta me dizendo que meu repositório (ou repo) foi inicializado. Ele é considerado vazio porque não informamos ao Git quais arquivos rastrear.

Um repositório é apenas outra maneira de definir um projeto que está sendo monitorado/rastreado pelo Git.

Arquivos de projeto no Git

Eu criei apenas um arquivo chamado todo.txt. Essa é a aparência do arquivo:

MINHA LISTA DE TAREFAS

1. Escrever um artigo.
2. Programar.
3. Estudar pelos livros.
4. Chegar nas aulas a tempo.
5. Visitar minha tia.
6. Me candidatar a trabalhos remotos. 

Antes de continuarmos aprendendo outros comandos do Git, vamos falar sobre o GitHub.

O que é o GitHub?

O GitHub é um serviço de hospedagem on-line para repositórios do Git. Imagine trabalhar em um projeto em casa e, enquanto estiver fora – talvez na casa de um amigo, de repente – se dar conta da solução para um erro de código que o deixou inquieto por dias.

Você não pode fazer essas alterações porque seu PC não está com você. Se, contudo, você tiver seu projeto hospedado no GitHub, poderá acessar e baixar esse projeto com um comando em qualquer computador ao qual tenha acesso. Em seguida, você pode fazer suas alterações e enviar a versão mais recente de volta ao GitHub.

Em resumo, o GitHub permite que você armazene seu repositório em sua plataforma. Outro recurso incrível que vem com o GitHub é a capacidade de colaborar com outros desenvolvedores de qualquer local.

Agora que criamos e inicializamos nosso projeto localmente, vamos enviá-lo para o GitHub.

Se você é iniciante, encontrará alguns termos novos como push, commit, add e assim por diante – mas não se deixe assustar com eles. Com alguma prática, você será capaz de lembrar desses termos e do que eles fazem.

Como enviar um repositório para o GitHub

Vou dividir esta seção em etapas para ajudá-lo a entender o processo com mais clareza.

Passo 1 – Crie uma conta no GitHub

Para poder usar o GitHub, terá de criar uma conta primeiramente. Você pode fazer isso no site da web do GitHub.

Passo 2 – Crie um repositório

Você pode clicar no símbolo + no canto superior direito da página e escolher "New repository" (Novo repositório). Dê um nome ao seu repositório, role para baixo e clique no botão "Create repository" (Criar repositório).

Passo 3 – Adicionar e confirmar arquivos

Antes de "adicionar" e "confirmar" nossos arquivos, você precisa entender os estágios de um arquivo que está sendo rastreado pelo Git.

Estado confirmado (committed)

Um arquivo está no estado confirmado quando todas as alterações feitas no arquivo foram salvas no repositório local. Os arquivos no estágio confirmado são arquivos prontos para serem enviados para o repositório remoto (no GitHub).

Estado modificado (modified)

Um arquivo no estado modificado tem algumas alterações feitas nele, mas ainda não foi salvo. Isso significa que o estado do arquivo foi alterado de seu estado anterior no estado confirmado.

Estado preparado (staged)

Um arquivo no estado preparado significa que está pronto para ser confirmado. Nesse estado, todas as alterações necessárias foram feitas. Portanto, o próximo passo é mover o arquivo para o estado de confirmação.

Você pode entender isso melhor imaginando o Git como uma câmera. A câmera só tirará um instantâneo quando o arquivo atingir o estado de confirmação. Após este estado, a câmera começa a comparar as alterações feitas no mesmo arquivo com o último instantâneo (este é o estado modificado). Quando as alterações necessárias forem feitas, o arquivo é preparado e movido para o estado de confirmação para um novo instantâneo.

Isso pode ser muita informação para absorver no momento, mas não desanime – fica mais fácil com a prática.

Como adicionar arquivos ao Git

Quando inicializamos nosso projeto, o arquivo não estava sendo rastreado pelo Git. Para isso, usamos o comando git add . O ponto que vem depois de add representa todos os arquivos que existem no repositório. Se você quiser adicionar um arquivo específico (por exemplo, um arquivo chamado about.txt), use git add about.txt.

Agora, nosso arquivo está no estado preparado. Você não receberá uma resposta após este comando, mas, para saber em que estado seu arquivo está, você pode executar o comando git status.

Como confirmar (commit) arquivos no Git

O próximo estado de um arquivo após o estado preparado é o estado confirmado. Para confirmar nosso arquivo, usamos o comando git commit -m "first commit"

A primeira parte do comando git commit diz ao Git que todos os arquivos preparados estão prontos para serem confirmados. Então, é hora de tirar um instantâneo. A segunda parte, -m "first commit", é a mensagem de confirmação. -m é uma abreviação de mensagem enquanto o texto entre aspas é a mensagem de confirmação (que pode ser a mensagem que você quiser e no idioma que quiser).

Depois de executar este comando, você deve obter uma resposta semelhante a esta:

Agora, nosso arquivo está no estado confirmado.

Passo 4 – Envie o repositório para o GitHub

Depois de criar o repositório, você deve ser redirecionado para uma página que informa como criar um repositório localmente ou enviar um já existente.

No nosso caso, o projeto já existe localmente, então usaremos comandos na seção "… ou enviar um repositório existente a partir da linha de comando". Estes são os comandos:

git remote add origin https://github.com/ihechikara/git-and-github-tutorial.git
git branch -M main
git push -u origin main

O primeiro comando, git remote add origin https://github.com/ihechikara/git-and-github-tutorial.git, cria uma conexão entre seu repositório local e o repositório remoto no GitHub.

O URL do seu projeto remoto deve ser totalmente diferente do anterior. Portanto, para acompanhar, certifique-se de seguir as etapas e trabalhar com seu próprio repositório remoto. Normalmente, você não receberá uma resposta após executar este comando, mas certifique-se de ter uma conexão com a internet.

O segundo comando, git branch -M main, altera o nome do seu branch principal para "main". O branch padrão pode ser criada como "master", mas "main" é o nome padrão para este repositório agora. Geralmente, não há resposta aqui.

O último comando, git push -u origin main, envia seu repositório do seu dispositivo local para o GitHub. Você deve obter uma resposta semelhante a esta:

Para ajudá-lo a aprofundar sua compreensão dos estágios do arquivo, farei alterações no arquivo e, em seguida, enviarei a nova versão para o GitHub.

Lembre-se de que nosso arquivo agora está no estado confirmado. Vamos fazer alterações no arquivo e anotar os estados.

Vou adicionar uma nova tarefa à lista de tarefas:

MINHA LISTA DE TAREFAS

1. Escrever um artigo.
2. Programar.
3. Estudar pelos livros.
4. Chegar nas aulas a tempo.
5. Visitar minha tia.
6. Me candidatar a trabalhos remotos. 
7. Praticar programação

Depois de adicionar a nova tarefa, execute o comando git status. Isto é o que você deverá ver:

Depois de fazer alterações no arquivo, ele foi movido para o estado modificado, mas ainda não está preparado para confirmação. Então, você ainda não pode enviá-lo para o GitHub. O Git não tirou um instantâneo final desse estado atual, pois está apenas comparando as alterações que fizemos agora com o último instantâneo.

Agora vamos adicionar (preparar) este arquivo e, em seguida, confirmá-lo e enviá-lo. Isto é igual ao que fizemos na última seção.

Primeiro, adicionamos o arquivo usando git add ., que adiciona todos os arquivos na pasta (um único arquivo, no nosso caso). Em seguida, confirmamos o arquivo executando git commit -m "added new task" (a mensagem significa "nova tarefa adicionada") seguido de git push -u origin main.

Essas são as três etapas para enviar seus arquivos modificados para o GitHub. Você adiciona, confirma e, em seguida, envia. Espero que agora você entenda os estágios do arquivo e os comandos associados a eles.

Como usar branches no Git

Com branches, você pode criar uma cópia de um arquivo no qual gostaria de trabalhar sem estragar a cópia original. Você pode mesclar essas alterações com a cópia original ou apenas deixar o branch permanecer independente.

Antes de começarmos a usar branches, quero mostrar uma representação visual do nosso repositório, que se parece com isso:

A imagem acima mostra nosso branch principal com os dois últimos commits (o primeiro commit e o commit da nova tarefa adicionada).

Neste ponto, quero adicionar mais tarefas à lista, mas ainda não tenho certeza se as quero na minha lista principal. Então, vou criar um outro branch chamado  test para ver como ficaria minha lista com mais tarefas incluídas.

Para criar um outro branch, execute este comando: git checkout -b test. Vamos dividir isso em partes e explicar.

checkout diz ao Git que deve mudar para um outro branch. -b diz ao Git para criar esse outro branch. test é o nome do branch a ser criado e alterado. Aqui está a resposta que você deve obter:

Agora que criamos um outro branch, é assim que nosso repositório ficará:

Criamos o outro branch a partir do estado do nosso último commit. Vamos agora adicionar mais tarefas a esse novo branch.

MINHA LISTA DE TAREFAS

1. Escrever um artigo.
2. Programar.
3. Estudar pelos livros.
4. Chegar nas aulas a tempo.
5. Visitar minha tia.
6. Me candidatar a trabalhos remotos. 
7. Praticar programação
8. Completar a tarefa de estágio.
9. Praticar aberturas do xadrez.
10. Resolver quebra-cabeças do xadrez.
11. Verificar o cronograma dos testes. 

Eu adicionei quatro novas tarefas. Para mesclar o novo estado com o branch main, você deve primeiro preparar e confirmar esse branch. Não entrarei em detalhes sobre o assunto, pois fizemos isso duas vezes na última seção.

Você deve tentar fazer isso sozinho para entender como funciona. Como dica, adicione o arquivo e, em seguida, confirme com uma mensagem (consulte a seção anterior para obter detalhes de como fazer isso).

Depois de confirmar seu branch test, volte para o branch main executando este comando: git checkout main.

Você notou que não adicionamos o -b ? Isso ocorre porque não estamos criando um outro branch, mas mudando para um branch existente. Você pode verificar todos os branches que existem em seu repositório executando o comando git branch

Agora, podemos mesclar as alterações que fizemos no branch test no branch main executando git merge test. Neste ponto, você verá todas as alterações feitas no branch test refletidas no branch main. Você também deve receber uma resposta semelhante a esta:

Aqui está uma representação visual do nosso repositório:

Se você continuar a enviar seu repositório para o GitHub, verá que o branch test não será enviado. Ele permanecerá apenas em seu repositório local. Se você quiser enviar seu branch test, mude para ele usando git checkout test e execute o comando git push -u origin test.

Como extrair um repositório no Git

Fazer pull no Git significa clonar o estado atual de um repositório remoto em seu computador/repositório. Isso é útil quando você deseja trabalhar em seu repositório de um computador diferente ou quando está contribuindo para um projeto de código aberto on-line.

Para testar isso, não se preocupe em mudar para um novo computador. Basta executar cd .. para sair do diretório atual e voltar uma etapa. No meu caso, naveguei de volta para a minha área de trabalho.

Vá para o GitHub e, na página principal do seu repositório, você verá um botão verde que diz "Code". Ao clicar no botão, você deverá ver algumas opções em um menu suspenso. Vá em frente e copie o URL no formato HTTPS.

Depois disso, execute git clone SEU_URL_DE_HTTPS. Este comando puxa o repositório remoto para seu computador local em uma pasta chamada git-and-git-tutorial. Isto é o que você deverá ver em seu terminal:

Conclusão

Este artigo abordou os comandos básicos que ajudarão você a começar a usar o Git. Também começamos a aprender a usar o GitHub.

Se você seguiu até este ponto, parabéns. Você está pronto para seguir em frente. Agora, você pode usar o Git em seus projetos, independentemente da linguagem de programação que estiver usando.

Você deve saber que esses não são todos os comandos que existem no Git – portanto, sinta-se à vontade para fazer mais pesquisas para aprender mais comandos e seus usos. Este artigo e esta página de dicas (ambos em inglês) são boas fontes para se começar . Este é um ótimo lugar para ver uma lista detalhada de mais comandos do Git (em inglês).

Encontre o autor no Twitter. Feliz programação!

A ramificação é um conceito central no Git. Ela pode ajudá-lo a configurar um fluxo de trabalho distribuído para colaboração em equipe e tornar seu processo de desenvolvimento mais eficiente.

Quando você está usando o controle de versão e distribuindo recursos entre branches, há muita comunicação entre seu computador local e seu repositório on-line no GitHub. Durante esse processo, talvez seja necessário redefinir a cópia original do projeto.

Se redefinir uma ramificação (em inglês, branch) assusta você, não se preocupe – este artigo apresentará branches remotas, remote head e como você pode redefinir facilmente uma branch remota para remote head.

Pré-requisitos

• Conhecimento básico de como usar um terminal.
• Git instalado (aprenda como instalar Git aqui, caso ainda não o tenha instalado).
• Conhecimento básico de GitHub e repositórios.
• Um sorriso em seu rosto. 😉

O que é uma branch no Git?

Uma branch é um conceito central no Git e no GitHub que você usará o tempo todo. As branches ajudam você a gerenciar diferentes versões de um projeto.

A branch main  é sempre a branch padrão em um repositório e é considerada o "código de produção e implementável". Você pode criar novas branches como prod-staging ou prod-current a partir da branch main.

O que é uma branch remota no Git?

Uma branch remota é uma referência ao estado das branches em um repositório remoto (uma versão do seu projeto hospedada na internet ou em uma rede como o GitHub).

Quando você clona um repositório, você extrai dados de um repositório na Internet ou de um servidor interno conhecido como remote (algo como (remote)/(branch)).

O que é origin (ou remote head) no Git?

A palavra origin é um alias que o Git criou para substituir o URL remoto de um repositório remoto. Ele representa a branch padrão em um repositório remoto e é uma referência local que representa uma cópia local do HEAD no repositório remoto.

Em resumo, origin/HEAD representa a branch padrão no repositório remoto, que é definida automaticamente quando você clona um repositório da Internet.

Como redefinir uma branch remota para origin no Git

Agora que você tem conhecimento prévio de como os repositórios remotos e branches funcionam, vamos resolver nosso problema e redefinir uma branch remota para a origem usando o comando git reset --hard .

Antes de fazer isso (se for a primeira vez), certifique-se de fazer back-up de sua branch antes de redefini-la caso algo dê errado. Você pode fazer back-up assim:

git commit -a -m "Branch de back-up"
git branch branch-backup

Agora, execute o comando abaixo para redefinir sua branch remota para a origem. Se você tiver um nome de branch remota e padrão diferente (que não seja origin ou main, respectivamente), basta substituí-los pelo nome apropriado.

git fetch origin
git reset --hard origin/main

Se você criou alguns arquivos ou diretórios novos, eles ainda podem permanecer após a redefinição. Você pode usar o comando abaixo para limpar a árvore de trabalho removendo recursivamente os arquivos da ramificação anterior que não estão sob controle de versão.

git clean -xdf

• A flag -x   remove todos os arquivos não rastreados, incluindo diretórios de compilação ignorados.
• A flag -d  permite que o Git verifique recursivamente diretórios não rastreados quando nenhum caminho for especificado.
• A flag -f   substitui a configuração de limpeza padrão do Git e inicia a limpeza de arquivos e diretórios não rastreados.

Conclusão

Se o nome do seu repositório remoto não for "origin" e se a branch nomeada não for "main" no repositório remoto, não se esqueça de atualizar os comandos acima com os nomes apropriados. Você sempre pode executar  git remote show origin para verificar isso.

Espero que este artigo tenha deixado você mais à vontade para trabalhar com branches e redefini-las. Não se esqueça ingressar no novo servidor de bate-papo do freeCodeCamp para interagir com outros alunos e fazer perguntas. Obrigado pela leitura! 💙

Muitas vezes, é útil para os desenvolvedores visualizarem aspectos de seus projetos de código. Especialmente em sistemas de controle de versão como o Git, onde é essencial entender o fluxo de trabalho da equipe.

Uma maneira de abordar isso no Git é desenhar um grafo como o que você viu na imagem inicial.

Você, provavelmente, já encontrou imagens como essa quando estava aprendendo como usar o Git (texto em inglês).

Esse grafo mostra um exemplo de histórico de revisões em um repositório do Git.

No Git, o histórico de revisões é representado como um DAG, ou Directed Acyclic Graph (grafo acíclico direcionado), que é um tipo de grafo de rede. Cada revisão é exibida como um círculo e as revisões são encadeadas usando setas. Cada seta aponta de uma revisão para sua antecessora imediata.

Na maioria das vezes, se você desejar um grafo desses, precisa desenhá-lo (manual ou digitalmente) – o que leva tempo e esforço. Além disso, esses grafos são estáticos e, em certos casos, seria muito mais interessante animar a progressão das revisões em um vídeo.

Por esses motivos, criei o Git Story (texto em inglês), que permite gerar facilmente vídeos em mp4 apresentando o layout e a progressão do histórico do Git, com apenas um único comando: git-story.

Como visualizar o histórico de revisões do Git

No Git, uma revisão também é conhecida como commit. Ela representa um conjunto de alterações ao conteúdo feitas em um momento específico por uma pessoa específica.

Existem vários componentes adicionais que nos ajudam a entender visualmente nosso histórico do Git.

Propriedades dos commit

Ao fazer um commit no Git, a legibilidade é importante. Portanto, é uma prática recomendada deixar uma mensagem no commit (texto em inglês) de forma clara, descrevendo sua alteração. Isso ajuda outros desenvolvedores que visualizam o histórico de commits a entender o propósito de cada alteração.

O ID do commit é um identificador exclusivo para cada commit, gerado especificamente a partir de seu conteúdo. Como usuário do Git, você provavelmente já viu que muitos comandos dele aceitam como argumento um ID de commit total ou parcial. Por esse motivo, ter IDs de commit disponíveis nas visualizações do Git pode ser muito útil.

Referências: branches, HEAD e tags

Ao visualizar o histórico do Git, também é útil saber onde você está. E uma referência no Git te ajuda a entender como os commits estão organizados no seu repositório.

Referências são rótulos (labels) que o Git anexa a commits específicos. Nomes de branch, Git HEAD (texto em inglês) e tags são todos exemplos de referências. Você pode pensar em um referência como um nome legível para nós, humanos, que aponta para um commit específico.

Vídeo gerado pelo Git Story

O Git Story (texto em inglês) analisa todas essas informações para você – commits, relacionamentos e referências – e as anima em um vídeo .mp4. A melhor parte é que tudo o que você precisa fazer é navegar no terminal até o seu projeto e executar o comando git-story.

Abaixo temos um exemplo de uma animação de vídeo gerada pelo Git Story:

Por que escrevi o Git Story em Python

Eu escolhi escrever Git Story em Python, pois existem duas bibliotecas muito úteis que alimentam este projeto.

GitPython

A primeira é chamada GitPython (texto em inglês), que é um pacote Python que fornece acesso a dados de repositórios do Git através de um conjunto de métodos práticos. É assim que o Git Story acessa os dados do repositório local do Git para animá-lo:

import git

repo = git.Repo(search_parent_directories=True)

Isso cria um objeto do repositório na memória do programa em Python que permite acesso aos objetos subjacentes do Git, além de suas propriedades. Uma lista de commits pode ser acessada da seguinte forma:

commits = list(repo.iter_commits(REF))

# Isso puxa uma lista de commits, de trás para frente, de REF
# REF pode ser um nome de branch, tag, HEAD ou uma ID de um commit

A iteração na lista de commits permite o acesso às propriedades de cada commit, que são usadas na próxima etapa para gerar a animação.

Manim

A segunda dependência é chamada Manim (texto em inglês), que é usada para gerar vídeos de matemática animados usando uma API em Python. O Manim facilita muito a criação de objetos em Python que representam linhas, formas, textos e equações e a colocação desses objetos em uma animação.

O Git Story usa o Manim para desenhar os círculos, as setas, os textos, e os nomes de cada branch do Git (texto em inglês) e cada referência que representa o intervalo do seu histórico do Git obtido pelo GitPython.

Esse é um código que mostra como o Manim é usado para criar um círculo vermelho para cada commit:

circle = Circle(stroke_color=commitFill, fill_color=commitFill, fill_opacity=0.25)

Aqui vemos como o Manim é usado para criar as setas entre os commits:

arrow = Arrow(start=RIGHT, end=LEFT, color=self.fontColor).next_to(circle, LEFT, buff=0)

Por fim, aqui vemos como esses objetos são adicionados a uma animação:

self.play(Create(circle), Create(arrow))

Como instalar o Git Story

1. Instale o manim e suas dependências em seu sistema operacional
2. Instale o GitPython :$ pip3 install gitpython
3. Instale o git-story: $ pip3 install git-story

Como usar o Git Story

1. Abra um terminal de linha de comando
2. Navegue até a pasta raiz do seu projeto Git usando cd
3. Execute o comando: git-story

A execução deste comando gerará uma animação de vídeo .mp4 dos 8 commits mais recentes em seu repositório Git. O arquivo de vídeo será colocado no diretório atual, no caminho ./git-story_media/videos.

Como personalizar a animação do Git Story

O Git Story inclui várias formas de modificar como seu repositório do Git é representado no vídeo gerado. Você faz isso por meio de opções e flags da linha de comando.

Para especificar o número de commits para animar, por exemplo, use a opção --commits=X, onde X é o número de commits que você deseja mostrar.

Você também pode querer começar a animar a partir de um commit específico, que não o HEAD. Para isso, você pode usar a opção --commit-id=ref para selecionar o commit inicial pelo qual deseja começar, de trás para frente. Em vez de ref, você também pode substituir por um ID total ou parcial de um commit, nome de branch ou tag do Git (texto em inglês).

Você pode usar a flag --reverse para animar os commits do mais novo para o mais antigo, que é a ordem cronológica reversa, para corresponder melhor à saída de log do Git (texto em inglês).

Experimente a flag --low-quality para acelerar o tempo de geração da animação durante o teste. Quando estiver satisfeito com a aparência da sua animação, remova a flag e execute o comando novamente para obter uma versão final de melhor qualidade.

Se preferir um esquema de cores claras em vez do padrão escuro, você pode especificar a flag --light-mode.

Para fins de apresentação, você pode adicionar um título de introdução, logotipo e conclusão à sua animação. Você pode fazer isso com as seguintes opções:

$ git-story --show-intro --title "My Git Repo" --show-outro --outro-top-text "My Git Repo" --outro-bottom-text "Thanks for watching!" --logo path/to/logo.png

Use a opção --media-dir=path/to/output para definir o caminho do vídeo a ser gerado. Isso é útil se você não quiser que arquivos extras sejam criados dentro do seu projeto.

Finalmente, você pode querer testar a flag --invert-branches se o histórico de commits do Git tiver vários branches. Essa flag mudará a ordem em que as branches são analisadas, o que altera a orientação da branch no vídeo gerado. Algumas animações ficarão melhores com essa flag definida e outras não.

Aqui está um exemplo final que mostra a aparência do vídeo quando existem várias branches no intervalo de commits:

Resumo

Git Story é uma ferramenta de linha de comando que escrevi em Python para facilitar a criação de animações de vídeo do seu histórico de commits do Git. As dependências incluem Manim e GitPython.

A animação exibe o conjunto desejado de commits e seus relacionamentos, juntamente com os nomes das branches, o commit HEAD e as tags.

O Git Story tem uma variedade de flags e opções de linha de comando que permitem personalizar a animação. Execute o comando git-story -h para exibir a lista completa de opções disponíveis.

Sinta-se à vontade para enviar um e-mail para o autor deste artigo com comentários, perguntas ou sugestões: jacob@initialcommit.io.

Pull requests também são muito bem-vindos à página do Git Story no GitHub.

Obrigado pela ler e uma boa programação para você!

Escrito por: Vali Shah

Por sermos desenvolvedores, muitos de nós têm de escolher entre merge e rebase. Com todas as referências que pegamos da internet, todos acreditam em "Não usar o rebase, pois ele pode causar problemas sérios." Aqui, explicarei o que são o merge e o rebase, por que você deve (ou não) utilizá-los, e como fazer isso.

Git merge e git rebase servem ao mesmo propósito. Eles foram projetados para integrar as alterações de diversas branches em uma única. Embora o objetivo final seja o mesmo, esses dois métodos fazem isso de modos diferentes, sendo útil saber a diferença entre eles para auxiliar você a se tornar um desenvolvedor de software melhor.

Essa é uma pergunta que divide a comunidade do Git. Alguns creem que você deve sempre usar o rebase, enquanto outros acham que você deve sempre usar merge. Os dois lados apresentam benefícios convincentes.

Git merge

Fazer um merge é uma prática comum para desenvolvedores que usam sistemas de controle de versão. Sejam as branches criadas para testes ou reparos de bugs, seja por outros motivos, o merge faz o commit de alterações para outro local. Para ser mais específico, o merge leva o conteúdo de uma branch de origem e o integra à branch de destino. Nesse processo, somente a branch de destino é alterada. O histórico da branch de origem permanece o mesmo.

Vantagens

• Simples e conhecido
• Preserva o histórico completo e a ordem cronológica
• Mantém o contexto da branch

Desvantagens

• O histórico de commits pode ficar poluído com os diversos commits das ações de merge
• Depurar usando git bisect pode ser mais difícil

Como fazer

Fazer o merge da branch master na branch feature usando os comandos checkout e merge.

$ git checkout feature
$ git merge master

(ou)

$ git merge master feature

Isso criará um "commit de merge" na branch feature contendo o histórico das duas branches.

Git rebase

Rebase é a outra maneira de integrar alterações de uma branch em outra. Rebase comprima todas as alterações em um único "patch". Em seguida, ele integra o patch na branch de destino.

Diferente do merge, o rebase "achata" o histórico, pois transfere o trabalho completo de uma branch para outra. No processo, o histórico indesejado é eliminado.

Rebases são a maneira como as alterações devem passar do topo da hierarquia para baixo, enquanto os merges são como eles devem voltar para o topo

Vantagens

• Simplifica um histórico potencialmente complexo
• Manipular um único commit é fácil (por exemplo, revertê-lo)
• Evita o "ruído" dos commits de merge em repositórios de muito tráfego com branches de muito tráfego
• Limpa os commits intermediários, tornando-os um único commit, o que pode ser útil para as equipes de DevOps

Desvantagens

• Transformar a branch feature em apenas alguns commits pode ocultar o contexto
• Fazer o rebase de repositórios públicos pode ser perigoso ao trabalhar como uma equipe
• Dá mais trabalho usar o rebase para manter a branch feature sempre atualizada
• Fazer o rebase em branches remotas exige o uso de um force push. O maior problema que as pessoas enfrentam é fazerem um force push mas não terem definido um git push padrão. Isso resulta em atualizações a todas as branches que tenham o mesmo nome, seja local ou remotamente, e é um pavor ter de lidar com isso.

Se você fizer o rebase incorretamente e, acidentalmente, reescrever o histórico, isso pode levar a sérios problemas. Por isso, certifique-se de que sabe o que está fazendo!

Como fazer

Fazer o rebase da branch feature na branch master usando os seguintes comandos.

$ git checkout feature
$ git rebase master

Isso move toda a branch feature para a branch master. Isso ocorre ao reescrevermos o histórico do projeto, criando commits totalmente do zero para cada commit na branch (feature) original.

Rebase interativo

Ele permite alterar os commits quando eles são movidos para a nova branch. Ele é mais poderoso que o rebase automatizado, por oferecer controle completo sobre o histórico de commits da branch. Tipicamente, é usado para limpar um histórico bagunçado antes de fazer o merge da branch feature na branch master.

$ git checkout feature
$ git rebase -i master

Isso abrirá o editor, listando todos os commits que estão prestes a ser movidos.

pick 22d6d7c Mensagem do commit nº 1
pick 44e8a9b Mensagem do commit nº 2
pick 79f1d2h Mensagem do commit nº 3

Ele define com exatidão qual será a aparência da branch após a realização do rebase. Ao reordenar as entidades, você pode fazer com que o histórico tenha a aparência que você quiser. Por exemplo, você pode usar comandos como fixup, squash, edit e outros no lugar de pick.

Qual deles usar?

Então, qual deles é o melhor? O que recomendam os especialistas?

É difícil generalizar e decidir por um ou por outro, já que cada equipe é diferente. Temos, porém, de começar de algum lugar.

As equipes precisam considerar diversas questões ao definir suas políticas de uso de git rebase e de git merge. Acontece que uma estratégia de fluxo de trabalho não é melhor do que a outra. Tudo depende de sua equipe.

Considere o nível do rebase e a competência do Git dentro de sua organização. Determine o grau de avaliação da simplicidade do rebase em comparação com a rastreabilidade e o histórico do merge.

Por fim, as decisões sobre o merge e o rebase devem ser consideradas no contexto de uma estratégia clara de criação de branches. Uma estratégia de sucesso para a criação de branches é projetada em torno da organização de suas equipes.

O que eu recomendo?

À medida que a equipe cresce, se tornará mais difícil gerenciar o rastrear alterações no desenvolvimento com uma política de sempre usar merge. Para ter um histórico limpo e compreensível dos commits, o uso de rebase é razoável e eficaz.

Considerando as seguintes circunstâncias e diretrizes, você pode obter o melhor do rebase:

• Você está desenvolvendo no local: se você não tiver compartilhado seu trabalho com mais ninguém. pode preferir o rebase em vez do merge para manter limpo seu histórico. Se você tem um fork pessoal do repositório, que não é compartilhado com outros desenvolvedores, é seguro usar o rebase mesmo após ter feito o push para sua branch.
• Seu código está pronto para ser revisado: você criou uma pull request. Outras pessoas estão revisando seu trabalho e, potencialmente, fazendo o fetch dele em seus forks para uma revisão local. Neste ponto, você não deve fazer o rebase de seu trabalho. Você deve criar commits de "retrabalho" e atualizar sua branch feature. Isso ajuda na rastreabilidade no pull request e evita a quebra acidental do histórico.
• A revisão está concluída e pronta para ser integrada à branch de destino. Parabéns! Você está prestes a excluir sua branch feature. Dado que outros desenvolvedores não estarão fazendo o fetch e o merge destas alterações a partir daqui, essa é a sua chance de limpar o histórico. Neste ponto, você pode reescrever o histórico e encolher os commits originais e os commits de "retrabalho dos PRs" e de "merge" em um conjunto pequeno de commits focalizados. Criar um merge explícito para esses commits é opcional, mas tem seu valor. Ele registra quando o feature (recurso) foi passado oficialmente para a branch master.

Conclusão

Espero que essa explicação tenha dado algumas ideias sobre git merge e git rebase. As estratégias de merge e de rebase são sempre discutíveis. Talvez, porém, este artigo ajude você a clarear suas dúvidas e permita a você adotar uma abordagem que funcione para sua equipe.

Eu gostaria muito de escrever sobre fluxos de trabalho do Git e sobre conceitos do Git. Gostaria de saber de você sobre o que deseja que eu escreva a seguir.

Tudo de bom!

code = coffee + developer (código = café + desenvolvedor)

Microverse - escola de programação para desenvolvedores de software

Escrito por: Gowtham Venkatesan

Sim, o título é clickbait. Não tem como entender o básico da tecnologia do Git em apenas 10 minutos. Mas você pode chegar bem perto disso em cerca de 25 minutos. Esse é o objetivo deste artigo.

Se quer começar a aprender sobre a tecnologia do Git, você veio ao lugar certo. Este é um guia abrangente para iniciantes no Git. Existem muitos clients para Git. A tecnologia é a mesma, não importando o client. Neste guia, porém, usaremos o GitHub para entender o Git.

Vamos começar!

O que é o controle de versão?

O controle de versão é um sistema que registra alterações em um arquivo ou conjunto de arquivos ao longo do tempo para que você possa recuperar versões específicas posteriormente. Então, idealmente, podemos colocar qualquer arquivo que esteja no computador dentro do controle de versão.

Umm… certo… mas para que fazer isso?

Esse é o motivo:

Um Sistema de Controle de Versão (VCS) permite que você reverta arquivos de volta a um estado anterior, reverta todo o projeto de volta a um estado anterior, revise as alterações feitas ao longo do tempo, veja quem modificou pela última vez algo que possa estar causando um problema, quem introduziu um problema e quando e muito mais. Usar um VCS também significa que, se você estragar tudo ou perder arquivos, geralmente conseguirá recuperar tudo facilmente. Às vezes, você só quer saber "quem escreveu essa porcaria", e ter acesso a essa informação vale a pena.

O que é o Git?

Git é um sistema de controle de versão para rastrear alterações em arquivos de computador e coordenar o trabalho nesses arquivos entre várias pessoas. Git é um sistema de controle de versão distribuído. Portanto, ele não depende necessariamente de um servidor central para armazenar todas as versões dos arquivos de um projeto. Em vez disso, cada usuário "clona" uma cópia de um repositório (uma coleção de arquivos) e tem o histórico completo do projeto em seu próprio disco rígido. Esse clone tem todos os metadados do original enquanto o próprio original é armazenado em um servidor auto-hospedado ou em um serviço de hospedagem de terceiros, como o GitHub.

O Git ajuda você a acompanhar as alterações feitas em seu código. É basicamente a guia de histórico do seu editor de código (sem modo de navegação anônima). Se, a qualquer momento durante a codificação, você encontrar um erro fatal e não souber o que está causando isso, você sempre poderá voltar ao estado estável. Por isso, é muito útil para depuração (debugging). Ou você pode simplesmente ver quais alterações você fez no seu código ao longo do tempo.

No exemplo acima, os três cartões representam versões diferentes do mesmo arquivo. Podemos selecionar qual versão do arquivo queremos usar a qualquer momento. Assim, posso pular para qualquer versão do arquivo na linha do tempo do git.

O Git também ajuda a sincronizar o código entre várias pessoas. Então, imagine que você e seu amigo estão colaborando em um projeto. Vocês dois estão trabalhando nos mesmos arquivos do projeto. O Git pega essas alterações que você e seu amigo fizeram de forma independente e as mescla em um único repositório "master"/"main". Portanto, usando o Git, você pode garantir que ambos estejam trabalhando na versão mais recente do repositório. Assim, você não precisa se preocupar em enviar seus arquivos uns para os outros e trabalhar com um número absurdo de cópias do arquivo original. Colaborar à distância se torna tão fácil quanto escrever em HTML.

Fluxo de trabalho do Git:

Antes de começar a trabalhar com os comandos do Git, é preciso entender o que eles representam.

O que é um repositório do Git?

Um repositório (também conhecido por "repo") nada mais é do que uma coleção de código-fonte.

Existem quatro elementos fundamentais no fluxo de trabalho do Git.

Diretório de trabalho, área de "staging", repositorio local e repositório remoto.

Se você pensar em um arquivo no seu diretório de trabalho, ele pode estar em três estados diferentes.

1. Staged: significa que os arquivos com as alterações atualizadas estão marcados para serem confirmados no repositório local, mas ainda não foram confirmados.
2. Modificado: significa que os arquivos com as alterações atualizadas ainda não estão armazenados no repositório local.
3. Confirmado: significa que as alterações feitas em seu arquivo estão armazenadas com segurança no repositório local.

• git add é um comando usado para adicionar um arquivo que está no diretório de trabalho à área de teste (staging).
• git commit é um comando usado para adicionar todos os arquivos que estão na área de staging no repositório local.
• git push é um comando usado para adicionar todos os arquivos confirmados no repositório local ao repositório remoto. Portanto, no repositório remoto, todos os arquivos e alterações estarão visíveis para qualquer pessoa com acesso ao repositório remoto.
• git fetch é um comando usado para obter arquivos do repositório remoto para o repositório local, mas não para o diretório de trabalho.
• git merge é um comando usado para obter os arquivos do repositório local para o diretório de trabalho.
• git pull é o comando usado para obter arquivos do repositório remoto diretamente no diretório de trabalho. É equivalente a um git fetch e um git merge.

Agora que sabemos o que é o Git e suas terminologias básicas, vamos ver como podemos colocar um arquivo no Git.

Vamos fazer do jeito certo e do jeito difícil. Sem nenhuma aplicação de GUI.

Estou assumindo que você já tenha um arquivo que deseja colocar sob controle de versão. Caso não tenha nenhum arquivo, crie uma pasta de teste com o nome 'MuskCult' e adicione algum arquivo de código nele.

Passo 0: faça uma conta no GitHub. Dã.

Se você ainda não tem uma, você pode criar a sua aqui.

Passo 1: certifique-se que você tem o Git instalado na sua máquina.

Se você é usuário Mac, abra o terminal e digite o seguinte comando:

$ git --version

Isso solicitará a abertura de um instalador se você ainda não tiver o Git. Então, configure-o usando o instalador. Se você já tiver o Git, ele apenas mostrará qual versão do Git você instalou.

Se você é usuário Linux(deb), digite o seguinte comando no terminal:

$ sudo apt install git-all

Se você está no Windows:

$ compre um mac

Brincadeira… calma… a quantidade de gente brava comigo agora… poxa vida…
Vá nesse link ou nesse link para mais informações.

Passo 2: diga ao Git quem você é.

Apresente-se. Sério, mencione seu nome de usuário e endereço de e-mail ao Git, já que todo commit do Git usará essas informações para identificar você como autor.

$ git config --global user.name "SEU_NOME_DE_USUÁRIO"

$ git config --global user.email "seu_email@email.com"

$ git config --global --list # Para conferir as informações que você acaba de fornecer

Passo 3: gere/verifique se sua máquina tem chaves SSH pré-existentes. (Opcional)

Por quê? Ao usar o protocolo SSH, você pode se conectar e autenticar com servidores e serviços remotos. Com chaves SSH, você pode se conectar ao GitHub sem fornecer seu nome de usuário ou senha a cada visita.

Para aprender mais sobre SSH, clique neste link.
Clique aqui para checar se você tem uma chave SSH.
Clique aqui para gerar uma chave SSH.
Clique aqui para adicionar a chave SSH à sua conta GitHub.
Por fim, clique aqui para testar sua conexão.

Se você de fato configurou seu SSH, substitua todos os comandos git que tenham um link por:

Em vez de : https://github.com/nome_do_usuário/nome_do_repositório

Use       : git@github.com:nome_do_usuário/nome_do_repositório.git

           Obs, : você pode usar qualquer uma das maneiras. Você escolhe.

Eu usarei o protocolo SSH neste tutorial.

Passo 4: hora de usar o Git

Crie um novo repositório no GitHub. Siga este link. Agora, localize a pasta que você deseja colocar no Git no seu terminal.

$ cd Desktop/MuskCult

Inicialize o Git:

E para colocar algo no Git, digite:

$ touch README.md    # Para criar um arquivo README no repositório
$ git init           # Inicia um repositório do Git vazio

Agora, edite o arquivo README.md para fornecer informações sobre o repositório.

Adicione arquivos à área de staging para confirmação:

Para adicionar os arquivos ao repositório do Git para confirmação:

$ git add .  
# Adiciona todos os arquivos no repositório local na área de staging para o commit

OU se quiser adicionar um arquivo específico

$ git add README.md 
# Para adicionar o arquivo específico

Antes de confirmar, vamos ver quais arquivos estão em staging:

$ git status # Lista todos os arquivos novos ou modificados que farão parte do commit

Faça o commit das mudanças que você fez no seu repositório do Git:

Agora, para confirmar os arquivos que você adicionou ao repositório do Git:

$ git commit -m "Primeiro commit"
# A mensagem entre aspas (" ") é fornecida para que outros usuários possam lê-la e ver que mudanças você fez

Retirar de um commit as mudanças que você fez no seu repositório do Git:

Agora, imagine que você acabou de cometer algum erro no seu código ou colocou um arquivo indesejado dentro do repositório. Você pode remover os arquivos que acabou de adicionar usando:

$ git reset HEAD~1
# Remove o commit mais recente
# Faça o commit novamente depois de ajustar!

Adicione uma "origem" remota e faça um push:

Uma coisa importante: toda vez que você fizer alterações em seus arquivos e salvá-los, eles não serão atualizados automaticamente no GitHub. Todas as alterações que fizemos no arquivo são atualizadas no repositório local. Agora, para atualizar as alterações no repositório "master"/"main":

$ git remote add origin URL_do_repositório_remoto
# Define o novo repositório remoto

O comando git remote permite que você crie, visualize e exclua conexões com outros repositórios.

$ git remote -v
# Lista as conexões remotas que você tem com outros repositórios.

O comando git remote -v lista os URLs de conexões remotas que você tem com outros repositórios.

$ git push -u origin master # faz o push das alterações para "origin"

O comando git push envia as alterações em seu repositório local para o repositório remoto que você especificou como origem (em inglês, origin).

E agora, se formos verificar nossa página de repositório no GitHub, ela deve ser algo assim:

E é isso. Você acabou de adicionar os arquivos ao repositório que acabou de criar no GitHub.

Verifique as mudanças que você fez em seu arquivo:

Depois de começar a fazer alterações em seus arquivos e salvá-los, o arquivo não corresponderá à última versão que foi confirmada no Git por meio de um commit. Para ver as alterações que você acabou de fazer:

$ git diff # Mostra as alterações de arquivos que ainda não estão em staging

Revertendo para a última versão confirmada para o repositório do Git:

Agora, você pode optar por reverter para a última versão confirmada por commit digitando:

$ git checkout .

OU se quiser fazer isso para um arquivo específico

$ git checkout -- <nome_do_arquivo>

Visualizando o histórico de commits:

Você pode usar o comando git log para ver o histórico de commits que você fez nos seus arquivos:

$ git log

Cada vez que você faz mudanças que você deseja que estejam presentes no GitHub, o fluxo de comandos a seguir é o mais comum:

$ git add .
$ git status # Lista todos os arquivos novos ou modificados que farão parte do commit
$ git commit -m "Segundo commit"
$ git push -u origin master

Agora, se formos ver nosso repositório, podemos identificar se o commit foi bem-sucedido observando a mensagem de commit de cada arquivo.

Passo 5 : muito bem, mas... como eu faço o download e trabalho com outros repositórios do GitHub?

Clonando um repositório do Git:

Localize o diretório em que deseja clonar o repositório. Copie o link do repositório desejado e digite:

$ git clone URL_do_repositório_remoto

Sinta-se à vontade para clonar o repositório que criei acima usando: https://github.com/Gothamv/MuskCult

Fazendo o push das alterações para o repositório do Git:

Agora, você pode trabalhar nos arquivos que deseja e fazer o commit das alterações localmente. Se quiser enviar as mudanças para um repositório, precisa ser adicionado como  um colaborador do repositório ou criar algo conhecido como "pull request". Você pode verificar como elas são feitas aqui e me enviar um pull request com seu arquivo de código.

Colaborando:

Imagine que você e seu amigo estão colaborando em um projeto. Vocês dois estão trabalhando nos mesmos arquivos de projeto. Cada vez que você faz algumas alterações e as envia para o repositório master/main, seu amigo precisa extrair as alterações que você enviou para o repositório do Git. Ou seja, para garantir que vocês estarão trabalhando na versão mais recente do repositório do Git toda vez que você começar a trabalhar, um comando git pull será necessário.

Abaixo temos um exemplo de um projeto em que meu amigo e eu estamos colaborando:

Portanto, para garantir que essas alterações sejam refletidas na minha cópia local do repositório:

$ git pull origin master

Aqui estão mais dois comandos úteis do Git:

$ git fetch
    E
$ git merge

De forma simplificada, git fetch seguido por um git merge é igual a git pull. Mas, então, por que eles existem?

Quando você usa git pull, o Git tenta automaticamente fazer seu trabalho por você. Ele percebe o contexto, então o Git mesclará quaisquer commits cujo pull foi realizado na branch em que você está trabalhando no momento. git pull mescla automaticamente os commits sem que você precise revisá-los primeiro.

Quando você usa git fetch, o Git reúne todos os commits da branch de destino que não existem em sua branch atual e os armazena em seu repositório local. No entanto, ele não os mescla com sua branch atual. Isso é particularmente útil se você precisar manter seu repositório atualizado, mas estiver trabalhando em algo que pode quebrar se você atualizar seus arquivos. Para integrar os commits em sua branch master, use git merge.

Para concluir:

.gitignore

O que é isso?

O .gitignore diz ao Git quais arquivos (ou padrões) ele deve ignorar. Geralmente, ele é usado para evitar o commit de arquivos transitórios do seu diretório de trabalho que não são úteis para outros colaboradores, como produtos de compilação, arquivos temporários criados pelas IDEs, etc.

Assim, no exemplo acima, arquivos como __pycache__ e .DS_Store são usados ​​pelo sistema para armazenar informações para acesso mais rápido. Eles não são úteis para os outros colaboradores. Então, podemos dizer ao Git para ignorá-los adicionando-os a um  arquivo .gitignore.

Use o comando touch (no Linux ou no Mac) para criar o arquivo .gitignore:

$ touch .gitignore

Você pode adicionar ao .gitignore os seguintes padrões para dizer ao Git para ignorar esses arquivos.

/*.cmake
/*.DS_Store
/.user
/build
etc. dependendo dos arquivos que você quer que o Git não acompanhe

É basicamente isso que tínhamos sobre o básico do Git. Fique atento à parte 2, que se concentrará em branch, merge, stash, rebase e outros.

Se você gostou do artigo, não se esqueça de compartilhar com quem puder e quiser e de seguir o autor para saber quando chegar a parte 2.

Referências:

Adicionando o código localmente hospedado no GitHub - documentação do usuário
How to undo (almost) anything with Git (texto em inglês)
Git on the commandline - Don't be afraid to commit 0.3 documentation (texto em inglês)
Start using Git on the command line | GitLab (texto em inglês)
What is the difference between 'git pull' and 'git fetch'? (texto em inglês)

Escrito por: Sam Corcos

Como a maioria dos novatos, comecei procurando no StackOverflow por comandos do Git, copiando e colando as respostas, sem realmente entender o que eles faziam.

Lembro-me de pensar, "Não seria ótimo se houvesse uma lista dos comandos mais comuns do Git com uma explicação de para que eles são usados?"

Bem, anos depois, aqui estou eu compilando esta lista e apresentando algumas práticas recomendadas que até mesmo desenvolvedores intermediários e avançados devem achar úteis.

Para manter as coisas práticas, estou baseando esta lista em comandos reais do Git que usei na semana passada.

A maioria dos desenvolvedores hoje em dia usa o Git e, muito provavelmente, o GitHub também. Porém, um desenvolvedor intermediário provavelmente usa apenas esses três comandos 99% das vezes:

git add --all
git commit -am "<mensagem>"
git push origin master

Isso é ótimo quando você está trabalhando em um time de uma pessoa só, em um hackathon ou em um aplicativo "descartável". Mas quando a estabilidade e a manutenção começam a ser prioridade, fazer commits organizados, seguir uma estratégia de ramificação e escrever mensagens consistentes de commit se tornam muito importantes.

Vou começar com a lista de comandos comumente usados ​​para tornar mais fácil aos iniciantes entender o que é possível com o Git e, só depois, passar para recursos mais avançados e melhores práticas.

Os comandos mais usados

Se você não inicializar o Git, não poderá executar os outros comandos do Git nesse repositório. Por isso, para inicializar o Git em um repositório (ou repo, para os mais chegados, hehe), basta digitar o seguinte comando:

git init

Se você estiver usando o GitHub e enviando (também chamado de fazendo um push) o código para um repositório do GitHub on-line, você está usando um repositório remoto. O nome (também conhecido como alias) padrão para este repositório remoto é origin. Se, no entanto, você copiou esse projeto do Github, ele já tem um origin. Você pode ver a localização desse repositório usando o comando git remote -v, que exibe o URL do repositório remoto.

Se você inicializou seu próprio repo do Git e deseja vinculá-lo a um repo do GitHub, precisa primeiro criá-lo no GitHub, copiar o URL gerado e usar o comando git remote add origin <URL>, com o URL do GitHub substituindo o "<URL>". A partir daí, você pode adicionar arquivos, fazer os commits das alterações, além de enviá-los com o push para o seu repositório remoto.

Este último comando é utilizado também quando você precisa alterar algo do repo remoto. Por exemplo, suponhamos que você copiou o repo de outra pessoa e deseja alterar a origem do repositório remoto dela para o da sua própria conta do GitHub. É o mesmo procedimento do git remote add origin, porém você altera o URL no set-url para mudar de repositório remoto original.

git remote -v
git remote add origin <url>
git remote set-url origin <url>

Só tenha em mente que o repositório remoto será vinculado à conta de onde você o clonou. Portanto, se você clonou esse repo de outra pessoa, não conseguirá fazer o push para o GitHub até alterar a origin usando o comando acima.

A maneira mais comum de clonar um repositório é usar git clone, seguido do URL do repositório.

git clone <url>

Após isso, logo você estará usando branches (ramificações). Se você não entende o que elas são, existem outros tutoriais muito mais aprofundados, e você deve lê-los antes de prosseguir (aqui temos um, em inglês).

Se você quiser criar uma nova branch, você pode usar git branch <nome>, com <nome> representando o nome da branch, como, por exemplo, "master". Com o comando git branch, você lista todas as branches do repositório local.

Já o comando git checkout <name> alterna para outra branch existente. Você pode também usar o comando git checkout <name> para criar uma nova branch e imediatamente mudar para ela. A maioria das pessoas usa isso em vez de comandos separados de branch e checkout.

git branch
git branch <name>
git checkout <name>
git checkout -b <name>

Se você fez muitas mudanças em uma branch, que vamos chamar de "develop", e se quiser fazer o merge de seus arquivos da branch de volta ao master, você usa o comando git merge <branch>.  Você primeiro faz o checkout para a branch master e, em seguida, executa git merge develop para fazer o merge de develop na branch master .

git merge <branch>

Se você está trabalhando com muitas pessoas, e se estiver em uma posição onde o repo foi atualizado no GitHub, mas não mudou localmente, pode usar git pull origin <branch> para receber as mudanças mais recentes  da sua branch remota.

git pull origin <branch>

Se estiver curioso para ver quais arquivos foram alterados e quais o Git está monitorando, use git status. Já se quiser ver o quanto cada arquivo foi alterado, você pode usar o comando git diff para ver o número de linhas alteradas em cada arquivo.

git status
git diff --stat

Comandos avançados e práticas recomendadas

Em pouco tempo, você chegará ao patamar em que desejará que seus commits tenham uma boa aparência e permaneçam consistentes. Você também poderá ter de mexer no seu histórico de commits para torná-los mais fáceis de compreender ou, ainda, reverter uma alteração acidental.

Para isso, você vai precisar usar o comando git log, que permite a você ver o histórico de commits.

Ah, e seus commits sempre virão com mensagens e um hash, que é uma série aleatória de números e letras. Um hash pode ser assim: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Vamos dizer que você subiu algo para o GitHub que quebrou seu aplicativo. Em vez de corrigi-lo e enviar algo novo, você prefere apenas voltar um commit e tentar novamente.

Se você quiser voltar no tempo e fazer o checkout do seu aplicativo de um commit anterior, você pode fazer isso diretamente usando o hash como o nome da branch. Isso separará seu aplicativo da versão atual (porque você está editando um registro histórico, em vez da versão atual).

git checkout c3d88eaa1aa4e4d5f

Então, se você fizer alterações no histórico da sua branch e quiser fazer o push novamente, terá que fazer um push forçado.

Cuidado: fazer o push com esse método forçado é perigoso e só deve ser feito se for absolutamente necessário. Ele substituirá o histórico do seu aplicativo e você perderá o que veio depois.

git push -f origin master

Às vezes, também não é prático manter tudo em um commit só. Talvez você queira salvar seu progresso antes de tentar algo potencialmente arriscado, ou talvez tenha cometido um erro e queira se poupar do constrangimento de ter um erro no seu histórico de versões. Para isso, temos o git rebase.

Digamos que você tenha 4 commits em seu histórico local (não enviado para o GitHub) nos quais você foi e voltou. Seus commits agora parecem desarrumados e indecisos. Você pode usar o rebase para combinar todos esses commits em um único commit conciso.

git rebase -i HEAD~4

O comando acima abrirá o editor de texto padrão do seu computador (a menos que você o tenha configurado para outro editor, provavelmente será para o Vim), com várias opções de como você pode alterar seus commits. Será algo como o código abaixo:

pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message

Para combiná-los, precisamos alterar a opção “pick” para “fixup” para mesclar os commits e  descartar as mensagens de commit. Note que no Vim, você pressiona "a" ou "i" para poder editar o texto, salvá-lo e sair, você precisa digitar a tecla Esc seguida de "shift + z + z". Não me pergunte o motivo, apenas é assim.

pick 130deo9 mensagem de commit mais antiga
fixup 4209fei segunda mensagem de commit mais antiga
fixup 4390gne terceira mensagem de commit mais antiga
fixup bmo0dne mensagem de commit mais nova

Isso mesclará todos os seus commits em um só commit com a mensagem "mensagem de commit mais antiga".

O próximo passo é renomear sua mensagem de commit. Mas isso é só questão de opinião, pois desde que você siga um padrão consistente, tudo o que você fizer está bem. Eu recomendo usar as regras e diretrizes do Google feitas para o Angular.js (texto em inglês).

Para mudar a mensagem do commit, use a flag amend.

git commit --amend

Isso também abrirá o Vim, e as regras de salvamento e edição de texto são as mesmas de cima. Como exemplo de uma boa mensagem de commit, abaixo vemos uma mensagem que segue as diretrizes citadas anteriormente:

feat: add stripe checkout button to payments page

- add stripe checkout button
- write tests for checkout

Uma vantagem de manter os tipos listados na diretriz é que isso facilita a gravação de logs de alterações. Também é possível incluir informações no rodapé (novamente, especificadas na diretriz) que referenciam os problemas.

Nota: você deve evitar fazer o rebase ou compactar seus commits se estiver colaborando em um projeto e tiver código enviado para o GitHub. Se você começar a alterar o histórico de versões debaixo do nariz das pessoas, pode acabar dificultando a vida de todos com bugs difíceis de rastrear.

Há um número quase infinito de comandos possíveis com o Git, mas esses comandos apresentados são provavelmente os únicos que você precisará saber para seus primeiros anos de programação.

Sam Corcos é o principal desenvolvedor e cofundador do Sightline Maps, uma plataforma intuitiva para impressão 3D de mapas topográficos, e também do LearnPhoenix.io, um site de tutoriais intermediários-avançados para a criação de aplicativos de produção escaláveis ​​com Phoenix e React.