GitHub

Comandos do Git que você precisa conhecer – Parte 2 – Repositórios Remotos

Olá Web Developers! Hoje trago aqui os comandos que você precisa conhecer ao se trabalhar com Git. A primeira parte deste post abordou os comandos do Git para repositórios locais. Agora veremos os comandos para repositórios remotos e também como criar um repositório na nossa rede local.

1 – Clonando um Repositório Remoto

Para fazer download de um projeto basta executar o comando $ git clone, passando o endereço do repositório. Pode ser Github, Gitlab, Bitbucket, etc.

Esse comando é bem conhecido, mas ele está aqui por um detalhe que muitas pessoas não sabem: por padrão será criada uma pasta com o nome do projeto, mas você também pode no final do comando indicar qual o nome da pasta que você quer que seja criada.

$ git clone https://meu-endereco.com/meu-projeto.git minha-pasta

2 – Repositórios Remotos

Repositórios Remotos são repositórios presentes em outra máquina para a qual nós podemos pegar ou enviar código. Todos esses comandos começam com $ git remote. Veja os principais comandos para gerenciá-los:

2.1 – Adicionar Repositórios Remotos

Para ligar o seu repositório local com um repositório remoto, utilize o comando remote add. Precisamos passar dois parâmetros para esse comando:

  1. nome: nome que daremos ao nosso repositório remoto, como se fosse um atalho para não precisarmos ficar escrevendo a URL toda hora. O padrão é usar o nome origin
  2. url: endereço do repositório remoto ao qual o nome passado anteriormente vai se referir
$ git remote add origin https://meu-endereco.com/meu-projeto.git

Caso você queira colocar outro nome ao invés de origin não tem problema. Isso pode ser muito útil caso você precise se conectar a mais de um repositório remoto. Mas se tiver apenas um, o recomendado é seguir o padrão e usar o nome origin.

Ao adicionar mais de um repositório remoto, as alterações serão enviadas para todos. Isso pode ser útil caso você queira armazenar seu código em mais de um lugar ao mesmo tempo.

2.2 – Visualizar Repositórios Remotos

Esse comando nos mostra o endereço do repositório remoto para o qual estamos enviando nossos códigos.

$ git remote -v

Teremos um retorno como:

> origin https://meu-endereco/meu-projeto.git (fetch)
> origin https://meu-endereco/meu-projeto.git (push)

2.3 – Remover Repositórios Remotos

Pode ser que você não queira mais o seu local repositório conectado a um repositório remoto. Esse comando não apaga o repositório, apenas desfaz a conexão criada com o comando $ git remote add

$ git remote rm origin

Nesse exemplo usamos o nome origin, mas lembre-se que ali pode ser o nome que você deu ao seu repositório remoto. Se você deu um nome diferente de origin, lembre-se de usar o comando anterior para listar os repositórios remotos.

2.4 – Renomear Repositórios Remotos

Pode ser que você não queira mais o nome que você deu ao seu repositório remoto com o comando $ git remote add. Há um comando bem simples para renomear.

$ git remote rename nome-atual novo-nome

2.5 – Alterar Endereço de Repositórios Remotos

Já escreveu o endereço de um repositório remoto errado ou migrou ele para outro serviço? Com o comando set-url você será capaz de apenas alterar o endereço sem precisar mexer em mais nada. Precisamos passar dois parâmetros para esse comando:

  1. nome: nome que demos ao nosso repositório remoto, como se fosse um atalho para não precisarmos ficar escrevendo a URL toda hora. O padrão é usar o nome origin
  2. url: novo endereço do repositório remoto
$ git remote set-url origin http://meu-novo-endereco/meu-projeto.git

3 – Branches Remotas

3.1 – Listando Branches

Esse comando lista todas as branches presentes no repositório do seu computador.

$ git branch

Caso você queira que ele liste também as branches que estão no repositório remoto, adicione -a:

$ git branch -a

3.2 – Criando Branches Remotas

Ao enviar o seu código para uma branch remota que ainda não existe, basta executar o push com a opção -u junto com o nome do repositório remoto e o nome da nova branch.

$ git push -u origin minha-branch

Após a branch remota estar criada, você poderá executar simplesmente $ git push.

3.3 – Apagando Branches Remotas

Para apagar uma branch remota nós fazemos um push e adicionamos o --delete. Entre o --delete indicamos o repositório remoto e o nome da branch a ser apagada.

$ git push origin -d minha-branch

Também podemos escrever assim:

$ git push origin :minha-branch

3.4 – Renomeando Branches Remotas

Vimos no post anterior que para renomear uma branch local executamos:

$ git branch -m nome-atual novo-nome

Após renomear a sua branch local, basta apagar a branch remota com o nome antigo e fazer um push com a branch com o novo nome:

$ git push origin :nome-atual novo-nome

Para terminar de ligar a branch local com a remota, entre na branch com o novo nome e execute:

$ git push origin -u novo-nome

4 – Achando o culpado

Deu problema e estão dizendo que foi você? Não mais! Com o comando blame você pode ver quem alterou cada linha de um arquivo. (a menos que realmente tenha sido você 😂)

git blame nome-do-arquivo

Para não ficar muito grande, podemos usar -w para ignorar espaços em branco e usar -L para indicar um intervalo de linhas a serem exibidas.

git blame -w -L 1,12 nome-do-arquivo

E ainda podemos usar -e para que seja exibido o email ao invés do nome do usuário.

5 – Compartilhamento Offline

Podemos ter repositórios remotos que não estão na nuvem, como Github, Gitlab, ou Bitbucket. Podemos fazer com que um computador em nossa rede seja o responsável por armazenar o código e receber o push de todos os usuários. Isso é útil principalmente em empresas que possuem uma política mais rígida com a segurança de suas informações e não permitem que seus códigos sejam armazenados fora de seus próprios servidores.

Outro uso para isso é quando adicionamos mais de um repositório remoto. Você pode continuar fazendo commits para o Github e ao mesmo tempo ir armazenando uma cópia em um pendrive.

Primeiro, no local onde teremos o nosso repositório “servidor” (que receberá os pushes), iniciamos um repositório junto com --bare. Neste repositório você não poderá editar arquivos ou fazer commits, ele só permite receber pushes.

$ git init --bare

Se você iniciou, por exemplo, um repositório em uma pasta dentro de um pendrive com o caminho E:\meu-projeto, basta clonar com o comando:

$ git clone E:\meu-projeto

Ou então, como já vimos, podemos adicionar esse repositório na nossa lista de repositórios remotos, permitindo que nossos commits sejam enviados para algum lugar como o Github e para o pendrive ao mesmo tempo:

$ git remote add usb E:\meu-projeto

Nesse exemplo demos o nome usb ao invés de origin. Lembre-se que você pode dar qualquer nome.

Do mesmo jeito que fizemos um repositório em um pendrive, você pode fazer o mesmo em um outro computador na sua rede. Assim todos os usuários em sua rede poderão usar este computador como repositório remoto.

Comandos do Git que você precisa conhecer – Parte 1

Olá Web Developers! Hoje trago aqui comandos muito úteis ao se trabalhar com Git que todo mundo precisa saber para facilitar o trabalho.
Nesse primeiro post veremos os comandos para repositórios locais. Na Parte 2 desse post veremos os comandos para você dominar Repositórios Remotos.

Se você ainda não trabalha com Git, veja nosso post sobre Primeiros passos com o Git.

1 – Iniciando um Repositório

Todo repositørio Git armazena as informações dentro de uma pasta oculta chamada “/.git”. Para que os arquivos de uma pasta possam ser versionados pelo Git, é preciso iniciar o repositório. Basta executar o comando abaixo:

$ git init

2 – Apagando um repositório

Há momentos em que não queremos apagar nossos arquivos, mas queremos remover as informações sobre aquele repositório criado com o $ git init (talvez criar um repositório novo com os mesmos arquivos).
Para isso não usamos o Git. Lembre-se que um repositório Git armazena as informações dentro de uma pasta oculta chamada /.git. Então basta apagar esta pasta oculta que o seu atual diretório deixará de ser um repositório.

$ rm -rf .git

3 -Listando Arquivos Modificados

Esse comando indica o estado do seu repositório. Em outras palavras, ele vai listar todos os arquivos que foram modificados desde o seu último commit.

$ git status

4 – Desfazendo Alterações

Poderíamos ter um post inteiro apenas falando sobre como desfazer alterações no Git, já que há vários cenários possíveis. Mas vamos resumir os principais:

4.1 – Arquivos não monitorados

Se o arquivo foi modificado mas você ainda não executou git add, um simples git checkout removerá as alterações, deixando o arquivo como ele estava no último commit. Passe o nome do arquivo a ter as alterações desfeitas ou . para desfazer as alterações em todos os arquivos modificados. Muito útil se você está apenas experimentando um código mas não quer que ele seja salvo.

git checkout .

Esse comando não apaga novos arquivos. Para apagar novos arquivos que ainda não foram adicionados ao Stage, execute:

git clean -df

4.2 – Removendo arquivos do Stage

Se você executou git add e quer desfazer, use o reset.

git reset

Para desfazer as modificações, após o reset use o checkout ou clean mostrados anteriormente.

4.3 – Desfazendo o último commit

Caso você tenha feito alterações e já tenha chegado a realizar um commit, para desfazer é necessário usar o revert.

git revert HEAD

Será criado um novo commit indicando que o último commit foi desfeito.

Esse comando apaga novos arquivos.

5 – Renomear Commit

Escreveu algo errado no último commit? Esse comando te permite renomear a mensagem do último commit feito:

$ git commit --amend

6 – Branches

Sempre é bom não trabalhar apenas na master para evitar problemas e ter um projeto mais flexível.

6.1 – Listando Branches

Esse comando lista todas as branches presentes no repositório do seu computador.

$ git branch

Caso você queira que ele liste também as branches que estão no repositório remoto, adicione -a:

$ git branch -a

6.2 – Indo para outra branch

Para mudar para uma outra branch basta usar o comando checkout, passando o nome da branch.

$ git checkout minha-branch

Se você adicionar -b, uma nova branch será criada.

$ git checkout -b minha-nova-branch

6.3 – Excluindo branches

Para excluir uma branch local basta executar o comando branch com -d ou -D, passando o nome da branch que você quer apagar.

git branch -d nome-da-branch
git branch -D nome-da-branch

A opção -d é mais segura, pois ela só apaga a branch se você já tiver feito merge ou enviado as alterações para seu repositório remoto, evitando perda de código.

A opção -D ignora o estado da sua branch, forçando a sua remoção.

Esse comando apaga apenas a branch local, não removendo branches remotas.

6.4 – Renomeando branches

Para renomear a sua atual branch local, execute o comando branch com a opção -m, passando o novo nome.

git branch -m novo-nome-da-branch

Se você estiver em uma branch e quiser renomear outra, você deve passar primeiro o nome atual da branch que quer renomear:

git branch -m nome-atual novo-nome

6.5 – Branch Órfã

Uma branch órfã tem esse nome porque ela não está ligada à branch principal, então seus históricos não são compartilhados.

          i---j---k     <== branch 'minha branch'
         /
a---b---c---d---h---l   <== branch 'master'
     \         /
      e---f---g         <== branch 'minha outra branch'

1---2---3---4           <== branch `órfã`

Isso pode ser útil quando você quer colocar mais de um projeto em um mesmo repositório. Um bom exemplo é quando você tem um projeto no Github e quer criar um site para divulgar o seu projeto. A aplicação e o site são coisas diferentes, portanto os códigos deles devem ser versionados separadamente. Ter ambos em um mesmo repositório simplifica o gerenciamento.

Nós já ensinamos aqui no blog da TreinaWeb como criar páginas para repositórios no Github.

Para criar uma branch órfã basta usar o comando:

git checkout --orphan minha-branch-orfa

7 – Visualizando o Histórico de Commits

Para visualizar o histórico de commits basta usar o seguinte comando:

$ git log

Você ainda pode adicionar mais parâmetros a esse comando, como:

7.1 – Histórico de um ou mais arquivos

$ git log -p meus-arquivos

Você pode indicar nomes de arquivo ou de um diretório para ver o histórico apenas de um grupo de arquivos ao invés do projeto inteiro

7.2 – Histórico de um autor

Mostra o histórico de commits feitos por uma única pessoa

$ git log --autor=nome-autor

7.3 – Histórico por Data

Mostra o histórico de commits feitos antes ou após uma data:

$ git log --after="MMM DD YYYY"
$ git log --before="MMM DD YYYY"

Exemplo do formato usado nas datas: “Jul 07 2019”

7.4 – Histórico Baseado em uma Mensagem

Mostra o histórico de commits filtrado por uma mensagem

$ git log --grep produtos

Com esse comando teremos o histórico de commits em que a mensagem do commit possua a palavra “produtos”. O que passamos pode ser uma expressão regular, e podemos passar mais de uma:

// procurar por "produtos" OU "usuarios"
$ git log --grep produtos --grep usuarios

// procurar por "produtos" E "usuarios"
$ git log --grep produtos --and --grep usuarios

8 – Exibir branches em um modo mais legível

É possível mandar imprimir o histórico exibindo as branches do repositório com algo mais legível e com cores com um comando. Teremos um resultado parecido com esse:

* a102055 (HEAD -> master) commit 8
| * 196d28e (branch-2) commit 7
| * 07e073c commit 3
| * 2b077ca new fie
| | * c1369d8 (branch-3) commit 6
| | * d11bdcd commit 5
| |/
|/|
* | 2b22b75 commit 2
|/
* d5a12b0 .gitignore
* 9535426 -- commit 1

O comando é um pouco comprido:

git log --all --decorate --oneline --graph

Para decorar tudo o que devemos escrever depois de log, lembre-se de A DOG
– —all
– —decorate
– —oneline
– —graph

9 – Atalhos Personalizados

Podemos criar atalhos para não ficar escrevendo comandos grandes como o do exempo anterior.

9.1 – Criando atalhos personalizados

Para criar atalhos personalizados, basta adicionar uma configuração, passando o nome que você quiser para o alias.

Por exemplo, se eu quiser que o comando ensinado anteriormente fosse chamado a partir do atalho dog:

//deixar o comando disponível apenas no repositório atual
git config alias.dog "log --all --decorate --oneline --graph"
//deixar o comando global em sua máquina, ficando disponível para qualquer repositório
git config --global alias.dog "log --all --decorate --oneline --graph"

Como os comandos serão do Git, não precisamos ficar chamando-o. Note que o comando passado para o atalho não inicia com git.

Para remover os atalhos basta executar:

//atalhos locais
git config --unset alias.dog
//atalhos globais
git config --global --unset alias.dog

Agora podemos ter o comando do exemplo anterior apenas executando $ git dog.

9.2 – Listando atalhos personalizados

Para exibir uma lista de atalhos personalizados, podemos executar o comando git config -l, que lista todas as configurações do seu Git. O problema é que esse simples comando vai listar todas as configurações. Podemos fazer um comando mais sofisticado para ele listar apenas os nossos atalhos personalizados e ainda organizá-los em ordem alfabética:

git config -l | grep ^alias\. | cut -c 7- | sort

O comando é grande, mas tudo bem, pois agora você sabe criar atalhos, não é mesmo? Podemos, por exemplo, criar um atalho com o nome alias:

git config alias.alias "! git config -l | grep ^alias\. | cut -c 7- | sort"

Por comandos como grep e sort não serem do Git, tivemos que iniciar a linha de comando com !. Perceba que por causa disso, nossa primeira instrução teve que chamar o Git.

O $ git config -l lista as configurações do Git. Pegamos o retorno e passamos ao comando $ grep, que serve para fazer busca de textos. Como queremos os atalhos, que vimos que começa com “alias”, mandamos o grep buscar por tudo que começa com alias.. Para termos uma lista mais limpa, usamos o comando cut para remover a parte “alias.” do nome dos atalhos. Por fim, usamos o comando sort para ordenar nossos atalhos em ordem alfabética.

10 – Trabalhando em mais de uma coisa sem fazer commit

Pode haver momentos em que você precisa parar o que está fazendo e começar a trabalhar em outra tarefa. Porém, pode não ser bom fazer o commit de algo que ainda não foi finalizado para depois voltar nele, resultando em um commit que ficará no histórico mas que possui um código que não funciona. Nós podemos salvar essas alterações feitas mesmo sem precisar realizar um commit para depois voltar a trabalhar nela, o que é chamado de Stash (algo como “esconder” ou “acumular”).

Ao fazer isso, seu repositório voltará ao estado do último commit, e as alterações feitas anteriormente estarão “escondidas”.

10.1 – Salvando modificações em um Stash

Simplesmente execute o comando stash

$ git stash

Você ainda pode colocar um nome nesse stash:

$ git stash push -m meu-novo-stash

10.2 – Listando Stashes

Você pode fazer vários stashes. Para listá-los, execute o comando:

$ git stash list

10.3 – Recuperando modificações

Se algo foi salvo no stash, basta executar o seguinte comando para recuperar as alterações que foram jogadas lá:

$ git stash apply

Isso vai recuperar o código do stash mais recente. Se quiser recuperar um stash mais antigo, basta ver o número do stash que aparece quando o listamos e passar para o seguinte comando:

$ git stash apply stash@{2}

10.4 – Removendo Stashes

Quando nós recuperamos alterações de um stash, ele continua guardado. Para apagá-lo da pilha, execute o comando drop junto ao nome do stash que você quer remover:

$ git stash drop stash@{5}

Se você quiser recuperar o código de um stash e já apagá-lo, pode usar o comando pop no lugar do apply.

11 – Juntando alguns pedaços do trabalho

Pode ser que você esteja trabalhando em uma branch e queira fazer o merge do código dela com outra branch, mas não quer juntar o trabalho inteiro, apenas um commit específico. Isso é possível com o Cherry Pick.

git cherry-pick id-do-commit

Como usar domínio personalizado no Github Pages

Já vimos aqui no blog um post sobre a utilização do Github Pages para criação de portfólio. Esse recurso por si só já é muito bom, pois evita a necessidade de um servidor pago para ter um site, mas ele fica ainda mais atraente com a utilização de domínios personalizados nessas páginas.

Por padrão, quando criamos um site no Github Pages o endereço utilizado para acessar a página possui o padrão: https://nome_do_usuario.github.io/nome_do_repositorio fica muito mais interessante se ao invés disso, usarmos por exemplo, para uma página pessoal o domínio relacionado ao seu perfil de desenvolvedor https://seunome.dev, no meu caso utilizo https://eltonfonseca.dev

Serviço de DNS

Quando compramos um domínio, precisamos de um serviço de DNS onde vamos criar as zonas. Alguns vendedores de domínio já possuem por padrão o serviço de DNS também, como é o caso do Google Domínio, dono dos domínios .dev, mas a maioria dos vendedores de domínio não possuem.

Primeiramente vamos ver como realizamos a configuração do domínio onde o vendedor não possui o serviço de DNS (como é o caso do registro.br, por exemplo). Nesse caso podemos usar a Cloudflare que possui plano gratuito. Acesse o link https://dash.cloudflare.com/sign-up para realizar o cadastro.

Depois de logado precisamos adicionar um novo site:

Informe o domínio do seu site:

Basta seguir os passos para terminar a adição, única coisa que precisa se atentar é o tipo de plano para selecionar gratuito.

Apontar o DNS no domínio

Agora precisa informar na empresa onde comprou o domínio qual é o servidor que será responsável pelos DNS. Acesse a página de Overview do seu site na Cloudflare, ele te apresentará quais nameservers deve usar:

Se o domínio foi comprado no registro.br, após logar basta clicar sobre ele e clicar no botão Alterar Servidores DNS. A configuração deve ficar conforme a imagem abaixo:

Se tiver comprado o domínio em outra empresa precisará verificar qual é o procedimento específico no sistema dela, geralmente isso é bem simples.

Adicionar zona de DNS na Cloudflare

Agora precisamos criar uma zona no Cloudflare que aponta para o IP do Github Pages, com isso toda vez que o usuário acessar no navegador https://eltonfonseca.dev ele retornará o caminho para a página. Vamos usar no nosso exemplo uma zona tipo A, mas poderíamos usar um ALIAS ou ANAME.

Acesse o menu DNS no painel do site no Cloudflare e em seguida adicione o seguinte registro:

Esse endereço de IP foi retirado da página da documentação do Github Pages. Ele ainda possui outros ips alternativos:

  • 185.199.108.153
  • 185.199.109.153
  • 185.199.110.153
  • 185.199.111.153

Basicamente terminamos a nossa configuração de DNS. Se a empresa onde comprou o domínio já possuir o gerenciador de DNS basta realizar esse último passo.

Veja no Google Domains como isso é feito:

Configurando o Github Pages

Precisamos configurar o Github para responder ao domínio personalizado que criamos. Depois de já ter o site funcionando com o endereço padrão (mostrado no post do início).

Acesse as configurações do repositório onde está o site:

Em seguida em GitHub Pages informe o seu domínio personalizado:

Depois de clicar em Save marque também a opção Enforce HTTPS para que os acessos aconteçam via HTTPS.

Podemos testar o site no navegador com o novo domínio:

Prontinho já temos o nosso site funcionando com domínio personalizado no Github Pages. Isso nos permite hospedar sites estáticos de forma extremamente simples sem ter que pagar um servidor de hospedagem ou realizar configurações complexas. O Github Pages possui algumas limitações e politicas de uso, antes de iniciar o seu uso pode ser interessante ler a documentação.

Hospedando o Portfólio criado com o Pingendo

No artigo anterior, Criando um Portfólio com o Pingendo, utilizamos a ferramenta para criar um Portfólio simples e rápido, para que você possa utilizá-lo para compartilhar suas experiências de maneira mais organizada na web.

Neste artigo estaremos hospedando este Portfólio de maneira gratuita.

Ferramenta utilizada

Utilizaremos o GitHub Pages para realizar esta hospedagem do nosso Portfólio.

O GitHub Pages é um website para que você possa hospedar seus projetos diretamente do seu repositório do GitHub.

Criando o repositório

O primeiro passo após logar em sua conta do GitHub é criar o repositório. Para isso, vamos até a página https://github.com/new e configuramos as preferências do repositório (nome, descrição e privacidade), como mostra a imagem abaixo:

Subindo a página

Neste passo será obrigatório o uso do Git instalado em sua máquina. Caso não o possua, você pode ver o processo de instalação e primeiros passos no seguinte artigo: Primeiros passos com Git.

Com o Git instalado e configurado, precisamos commitar o código-fonte da nossa página. Para isso, no GitBash e dentro da pasta do Portfólio, utilizamos os seguintes comandos:

git init
git remote add origin https://github.com/nome_do_usuario/nome_do_repositorio.git
git add .
git config --global user.email “seuemail@dominio.com”
git commit -m “Commit inicial”
git push -u origin master

Lembrando que você terá que alterar o nome do usuário e nome do repositório com base nas informações que foram obtidas no momento da criação do repositório, como mostra a imagem abaixo.

Ativando o GitHub Pages

Após commitar o código-fonte do Portfólio, vamos até a aba “Settings” e ao, final dela, ativaremos o GitHub Pages. Para isso, selecionamos a “Branch Master” como mostra as imagens abaixo:

Com isso, o Portfólio já está hospedado e disponível no seguinte endereço: https://nome_do_usuario.github.io/nome_do_repositorio/

Concluindo

Nesta série de artigos, vimos o quão fácil pode ser a criação e hospedagem de um Portfólio totalmente gratuito utilizando o GitHub Pages e Pingendo.

Git e GitHub: quais as diferenças?

Muitas pessoas pensam que Git e GitHub são a mesma coisa. Isso é uma dúvida comum principalmente de quem está começando. Entender cada um deles e como eles funcionam é importante, pois se não agora, uma hora você vai precisar.

O que é o Git?

O Git é um sistema de controle de versão de arquivos. É um software livre e muito utilizado no desenvolvimento de software onde diversas pessoas estão contribuindo simultaneamente, podendo criar e editar arquivos. Sempre quando alguém disponibiliza sua parte do projeto no Git, ele gerencia as alterações feitas e guarda um histórico. Isso é importante pois se houver algum problema você pode desfazer as alterações e voltar para a versão que estava estável.

O Git foi projetado e desenvolvido pelo Linus Torvalds para o desenvolvimento do Linux e foi adotado por muitos outros projetos.

Existem sites que provêm hospedagem gratuita de código fonte para repositório Git, um deles é o GitHub.

O que é o GitHub?

O GitHub é uma plataforma onde você pode armazenar seus projetos. É como se fosse uma rede social, só que de códigos, onde seus desenvolvedores podem disponibilizá-los para outras pessoas verem.

Quando seu projeto está no GitHub, você pode facilmente baixar uma cópia em outro computador. É uma plataforma gratuita e armazena milhões de projetos, tanto open source, pessoais e até mesmo comerciais. Alguns projetos bem conhecidos são o WordPress e o Linux. Hoje o GitHub pertence a Microsoft, que o adquiriu no ano de 2018.

Muitas pessoas utilizam o GitHub como portfólio de seu trabalho para que empresas possam vê-lo. Se você ainda não possui um GitHub e quer fazer parte, basta criar uma conta e um repositório.

O GitHub só suporta o Git, então para você subir seus projetos deve utilizá-lo, mas a integração entre eles é bem fácil. Agora caso queira utilizar somente o Git, não tem problema. Ao contrário do GitHub, o Git não depende do GitHub para ser utilizado.

Se você quiser aprofundar seus conhecimentos no Git e GitHub, conhecer os comandos e tudo mais, dá uma conferida no nosso curso 😊

Até mais!

As principais plataformas para armazenamento de código-fonte

Três grandes plataformas de controle de versão de código-fonte tem caído no gosto popular dos desenvolvedores. O GitHub, GitLab e BitBucket ganharam espaço com o passar do tempo e se tornaram aliados indispensáveis aos desenvolvedores para hospedarem seus códigos-fonte e disponibilizar seus projetos de forma simplificada.

Sendo assim, neste artigo veremos sobre cada um deles e suas características.

GitHub

O GitHub foi um dos pioneiros em hospedagem de repositórios Git, onde qualquer usuário que possua cadastro na plataforma pode contribuir com projetos privados ou Open Source. Possui grandes projetos hospedados, como por exemplo, WordPress, Atom, GNU/Linux, entre outros. Assim como consta em sua página inicial, todo desenvolvedor poderá hospedar, analisar, gerenciar projetos e construir softwares ao lado de 31 milhões de outros desenvolvedores e mais de 2,1 milhões de empresas e organizações que também utilizam o GitHub.

Em 4 de Julho de 2018 foi comprado pela Microsoft com valores estimados em cerca de US$ 7,5 bilhões.

Aqui no blog, possuímos um artigo bem legal sobre esta compra, que você pode conferir através do link:

https://www.treinaweb.com.br/blog/microsoft-compra-o-github-e-agora/

Mas, quais as maiores vantagens em se utilizar o GitHub?

A primeira delas é que a maioria dos projetos Open Source estão hospedados por lá, assim os desenvolvedores possuem uma grande quantidade de projetos para contribuir. Além disso, muitas empresas analisam seu histórico de contribuição em projetos, utilizando a ferramenta como meio de análise de perfil profissional.

Por seus quase 11 anos de existência e por ter sido o primeiro site de hospedagem de repositórios Git é, sem dúvida, o maior de todos eles, com diversos usuários e seus milhões de repositórios.

Além disso, caso você seja estudante, poderá usufruir de uma conta PRO do GitHub e ainda contar com diversas outras vantagens, como citado no artigo “Como obter uma licença para estudante no GitHub” que você pode conferir acessando o link abaixo:

https://www.treinaweb.com.br/blog/como-obter-uma-licenca-para-estudante-no-github/

GitLab

O GitLab, assim como o GitHub, também é uma plataforma para gerência e hospedagem de código fonte.

Possui uma interface simples e intuitiva e permite que qualquer usuário da plataforma possa criar repositórios privados e públicos de forma gratuita. Porém, os repositórios privados só podem ser contribuídos por uma quantidade limitada de usuários.

Diferente do GitHub, o GitLab é um projeto Open Source, mantido por toda comunidade. Além disso, permite que os desenvolvedores armazenem seus projetos em seus próprios servidores.

Possui múltiplos níveis de permissão (Convidado, Repórter, Desenvolvedor, Mestre e Dono), que serve para determinar os papéis de cada profissional no projeto, como podemos ver acessando o link abaixo:

https://docs.gitlab.com/ee/user/permissions.html

Possui também todo um conjunto de software para gerenciar seu projeto do início ao fim que, como eles se autodenominam, “A full DevOps tool”.

Aqui no blog, possuímos um artigo muito interessante sobre “O que é Devops” que você poderá conferir no link abaixo:

https://www.treinaweb.com.br/blog/afinal-o-que-e-devops/

Por fim, o GitLab permite que você desenvolva seus códigos online, utilizando um ambiente de desenvolvimento integrado (IDE) acoplado na ferramenta, fornecendo ao usuário colorização de sintaxe básica para uma variedade de linguagens de programação.

Além disso, possui IntelliSense e suporte de validação e formatação para as principais linguagens de script e marcação do mercado, como: TypeScript, JavaScript, CSS, LESS, SCSS, JSON e HTML.

BitBucket

O BitBucket, assim como o GitHub e o GitLab, é uma plataforma para hospedagem e gerência de código-fonte de projetos. Escrito em Python, o BitBucket é indicado para pequenas equipes com orçamento limitado, já que é uma opção mais barata e permite que sejam criados repositórios privados para até 5 desenvolvedores de forma gratuita.

Os preços do BitBucket são os mais acessíveis, se comparado ao GitHub e GitLab, possuindo três tipos de planos (Free, Standard e Premium) com os seguintes preços:

Possui integração com o Jira e o Trello, permitindo que os repositórios possam ser gerenciados a partir destas ferramentas.

O BitBucket possui suporte a integração contínua utilizando Pipelines, uma ferramenta que permite implantar, monitorar e confirmar seu código, para posteriormente, começar a planejar o próximo conjunto de modificações sem sair do BitBucket.

Concluindo

Vimos neste artigo, as três principais plataformas para gerenciamento e armazenamento de código-fonte, desta forma, cabe ao desenvolvedor escolher a que mais o agrada, levando em consideração suas características e particularidades.

Escolher um armazenador de código-fonte é uma forma simples e eficaz para que seus projetos sejam armazenados de forma organizada e que possam ser contribuídos por qualquer desenvolvedor, independente de sua localização.

Como obter uma licença para estudante no GitHub

O GitHub possui uma licença para estudantes que provê diversos recursos a alunos a partir dos 13 anos de idade que estejam devidamente matriculados em instituições de ensino. O Student Developer Pack tem como objetivo fornecer aos alunos o acesso gratuito às melhores ferramentas de desenvolvimento e neste artigo veremos como obter esta licença e quais as suas vantagens.

Criando uma conta

A partir do link https://education.github.com/pack é possível realizar seu cadastro sobre os seguintes passos:

Através do link do GitHub Education, você encontra uma breve descrição sobre o Student Developer Pack e motivos de sobra para concluir sua inscrição, como os serviços que serão disponibilizados para quem possuir esta licença. Ao clicar em “Get your Pack”, você será direcionado para a seguinte página:

É necessário para o GitHub saber se de fato você é estudante, já que a licença do Student Developer Pack é destinada exclusivamente para esta classe. Ao clicar no botão “Yes, I’m a student’, o próximo passo é preencher as informações, conforme cadastro mostrado abaixo.

O formulário acima possui dois tipos de cadastro: a partir do e-mail institucional e a partir de um comprovante de matrícula. Veremos abaixo como proceder em cada um dos casos.

E-mail institucional

Caso sua instituição de ensino forneça e-mail institucional clique no botão “Add an email address” e insira o endereço deste e-mail, informando o ano de sua graduação e como deseja utilizar o GitHub. Após isso, submeta as informações.

Algumas instituições de ensino fornecem de forma gratuita este tipo de e-mail, verifique se sua universidade se encaixa no fornecimento deste serviço, caso contrário, há uma segunda alternativa, na qual falaremos logo abaixo.

Comprovante de matrícula

A segunda opção é o upload do comprovante escolar atualizado ou qualquer documento que sua universidade/escola utiliza para comprovar sua matrícula ativa.

Ao clicar em “Upload proof of your academic status”, você poderá carregar o arquivo de comprovação escolar (o tipo de arquivo deverá ser gif, jpeg ou png), selecionar o e-mail da sua conta do GitHub, inserir o nome de sua escola, ano de graduação, como deseja utilizar GitHub e submeter seu pedido para análise.

Após envio, o GitHub fará uma análise das informações enviadas. O prazo estabelecido é de até 5 dias úteis, conforme exibido na página abaixo.

Vantagens

No total, 25 ferramentas fazem parte das vantagens oferecidas a partir da licença do Student Developer Pack.

Dentre as ferramentas temos: DigitalOcean, Heroku, Travis CI, Transifex, dentre outros. No link https://education.github.com/pack é possível visualizar todas estas ferramentas e o tipo do benefício, que poderá ser de 1 ano, 2 anos ou até o final do prazo da licença.

Após o prazo de 5 dias, você receberá um e-mail informando sobre o resultado do processo, conforme imagem abaixo.

Se este for positivo, sua conta já possuirá todos os privilégios de uma conta PRO do Github, com permissão para criar repositórios privados, além de todas as ferramentas disponíveis por seus parceiros.

Criando páginas para repositórios com o GitHub Pages

O GitHub é uma das maiores ferramentas para armazenamento e gestão dos nossos projetos. Ele possui um recurso bem interessante que facilita a divulgação e apresentação dos projetos lá hospedados. Este recurso é o GitHub Pages, que permite que criemos uma página web para nossos repositórios totalmente gratuita. Legal né? Então fica ligado que neste artigo veremos como criar uma página de apresentação para um repositório.

Criando o repositório:

A primeira coisa a se fazer é criar um repositório no GitHub para que consigamos gerar a página web para ele. Para isso, vamos até a rota https://github.com/new e configuramos todas as suas preferências:

Nesta página vamos informar o nome do repositório, sua descrição e o tipo de visibilidade (público ou privado). Feito isso, clicamos no botão verde “Create repository”.

Ativando o GitHub Pages:

Após isso, o repositório será criado e seremos redirecionados para sua tela inicial. Lá, clicamos no botão “Settings” no menu superior da tela. A partir disso, seremos redirecionados para a tela de configurações do repositório que, dentre diversas configurações, existe uma seção chamada “GitHub Pages”, conforme podemos ver abaixo:

Nesta seção há duas opções. Podemos criar uma página a partir de um código presente no próprio repositório ou por meio de um modelo disponibilizado pelo próprio GitHub. Caso você queira desenvolver sua própria página, selecione a branch que você quer salvar seu arquivo index.html e clique no botão save (primeira parte da seção).

Selecionando o tema

Para este artigo, vamos selecionar um modelo disponibilizado pelo próprio GitHub. Sendo assim, clicamos no botão “Choose a theme”. Feito isso, uma nova página será aberta onde podemos ver a lista de todos os temas disponíveis para uso:

Agora é só selecionar o que você prefere e clicar no botão verde “Select Theme”. Feito isso, uma janela para que possamos customizar a página do nosso repositório será aberta. Vale lembrar que as informações são escritas em Markdown, por isso precisamos seguir este formato.

Após editar o conteúdo da nossa página, vamos até o final da mesma e clicamos em “Commit Changes”. Isso irá gerar um novo commit com as mudanças feitas.

Finalmente, após todos estes passos, já podemos acessar a página do repositório através da rota:

https://treinaweb.github.io/repositorio_teste_github_pages/

Concluindo:

Com isso, notamos o quão fácil é criar uma página de apresentação para nossos repositórios de forma totalmente gratuita. Podemos, também, utilizar projetos um pouco mais complexos utilizando HTML, CSS e JavaScript, mas isso fica para um próximo artigo, ok? 🙂

Um abraço e até lá!

Microsoft compra o GitHub. E agora?

A segunda-feira começou com uma notícia que pode ter um grande impacto sob a comunidade de software global: a Microsoft comprou o GitHub em uma transação no valor de US$ 7,5 bilhões. Passado todo o frisson causado por essa notícia, chega a hora de fazermos uma análise mais lógica: quais serão os possíveis impactos para nós como desenvolvedores com relação a esta aquisição da Microsoft?

Antes de tudo: o que é o GitHub?

O GitHub é um dos mais populares serviços de hospedagem de código no mundo. Trata-se de um serviço baseado na web para hospedagem de código através do Git – uma ferramenta distribuída de controle de versão open source.

Aqui já entra um ponto que merece destaque e é fruto de confusão: o GitHub usa o Git por baixo dos panos para gerenciar os códigos que são enviados para ele. O GitHub não é o Git. Vários outros serviços oferecem serviços parecidos com o GitHub, sendo inclusive concorrentes entre si. Alguns destes serviços são o GitLab e o BitBucket. Todos estes são, assim como o GitHub, serviços web de hospedagem de código baseados no Git.

Basicamente, o GitHub pode ser usado em sua versão web de duas formas: através de repositórios públicos ou através de repositórios privados (quando falamos sobre repositórios, estamos falando sobre “locais” onde o nosso código pode ser armazenado e compartilhado entre desenvolvedores de qualquer lugar do mundo). A precificação varia de acordo com a tabela abaixo:

Plano Preço Informações
Gratuito Criação de repositórios públicos de maneira ilimitada
Desenvolvedor US$ 7/mês/desenvolvedor Criação de repositórios públicos e privados de maneira ilimitada
Time US$ 9/mês/desenvolvedor Criação de repositórios públicos e privados de maneira ilimitada, controle de acesso aos repositórios entre múltiplos usuários. Mínimo de 5 desenvolvedores no time.
Empresarial – hospedado no GitHub US$ 21/mês/desenvolvedor Criação de repositórios públicos e privados de maneira ilimitada, suporte 24/5, tempo de SLA de até 8h úteis.
Empresarial – hospedado em infraestrutura própria sob consulta Criação de repositórios públicos e privados de maneira ilimitada, suporte 24/7, suporte a múltiplas organizações.

No caso de repositórios públicos, nenhuma taxa é cobrada: a hospedagem do código é completamente gratuita. Porém, repositórios públicos (e, consequentemente, o código contido neles) podem ter seu conteúdo visualizado por qualquer pessoa (mesmo aquelas que não possuem uma conta no GitHub). É nessa modalidade de repositório onde os projetos open source acabam sendo hospedados, justamente para que o código fique exposto para a comunidade sem problemas.

E é justamente para a comunidade open source que o GitHub tem mais significado. O GitHub é uma plataforma estável e robusta, com mais de 10 anos de estrada e mais de 28 milhões de desenvolvedores e empresas como usuários. Entre essas empresas, nós incluímos os gigantes atuais da tecnologia: Google/Alphabet, Facebook, Amazon, Apple, Canonical e até mesmo a própria Microsoft.

Toda essa comunidade confiou hospedar seu código no GitHub justamente devido a sua robusteza e estabilidade, além de o GitHub ser uma plataforma fortemente comprometida com o open source desde suas origens.

E vem a Microsoft e… Compra o GitHub!

A Microsoft aceitou os termos de compra e iniciou o processo de absorção do GitHub em 4 de junho de 2018. O valor da compra foi especulado em cerca de US$ 7,5 bi. O interessante é que esse processo de compra não ocorreu do nada. Rumores apontam que as conversas sobre uma possível compra do GitHub por parte da Microsoft existiam desde 2017. Porém, o acordo de compra só foi finalizado de fato agora em 2018.

E isso desagradou uma parte da comunidade de desenvolvedores…

Uma parte da comunidade de desenvolvedores se revoltou com essa operação. Muito dessa revolta se deve ao fato da antiga postura da Microsoft, principalmente na década de 90 e até os anos 2000.

De fato, nesse tempo, a Microsoft não era uma empresa que apreciava muito o open source de maneira geral. Na verdade, ela tinha uma postura completamente adversa, sendo uma grande defensora do software proprietário em geral e até ignorando a existência de soluções open source de grande qualidade. De fato, a comunidade open source em geral via na Microsoft um grande demônio que procurava destruir as iniciativas open source para obter o monopólio do mercado .

E isso, de fato, seria motivo mais do que suficiente para assustar a todos os desenvolvedores e empresas com seus projetos open source hospedados no GitHub.

Mas o fato da Microsoft ter comprado o GitHub não é motivo de pânico e medo!

Acredito que não há motivo de pânico, mesmo com toda a história, no fato de a Microsoft ter comprado o GitHub. E acredito que isso seja devido a uma pessoa em especial: Satya Nadella.

Satya Nadella é um indiano que foi nomeado CEO da Microsoft em 2014, no lugar de Steve Ballmer (especialmente famoso pelo vídeo “Developers, Developers, Developers!” e pelas apresentações um pouco… extravagantes). E essa mudança de comando na Microsoft provocou uma série de mudanças no mindset da companhia.

Satya Nadella provocou uma revolução na maneira como a Microsoft encara o desenvolvimento de software: Nadella tornou a Microsoft uma adepta e grande incentivadora do software livre e das comunidades de desenvolvimento, ao mesmo tempo que convergiu as estratégias da Microsoft para ferramentas baseadas em nuvem, inteligência artificial e machine learning (tirando um pouco de foco dos lendários produtos da Microsoft – Windows e Office).

Hoje podemos ver uma série de resultados originados a partir dessa mudança de comportamento no mercado:

  • A Microsoft, em pouco mais de 4 anos, já se tornou a maior contribuidora de software open source no mundo, disponibilizando mais de 4000 profissionais diretos para a colaboração de projetos open source;
  • A grande maioria dos produtos da Microsoft hoje é completamente open source: ferramentas como o .NET Framework (Core), Visual Studio Code, TypeScript e o Xamarin hoje estão disponíveis no próprio GitHub para toda a comunidade. Isso também tornou a comunidade ativa e como parte importante no que diz respeito à evolução destas e outras tecnologias open source da Microsoft – ou seja, a comunidade tem voz ativa no desenvolvimento destas ferramentas;
  • Atualmente, a Microsoft está entre as cinco maiores contribuidoras do… kernel do Linux! Isso era algo simplesmente inimaginável há pouco tempo atrás. Então provavelmente você está usando algum código open source da Microsoft agora, mesmo que não utilize nenhuma ferramenta da empresa de Redmond. Ah, inclusive, a Microsoft lançou recentemente sua própria distribuição Linux, o Azure Sphere OS.

Estes são só alguns dos pontos que mostram que, nos últimos 4 anos, a Microsoft realmente mudou completamente seu pensamento com relação ao open source. Eu, particularmente, acredito nessa mudança, mesmo porque ela já se mostrou muito sólida e sem volta. Não vejo mais motivos de a Microsoft querer “quebrar” a comunidade open source.

Muitas pessoas citam os casos da Nokia e do Skype para justificar o pensamento de que a Microsoft irá “estragar” o GitHub. Eu acho esse pensamento muito raso por alguns motivos:

  • O Skype (2011) e a Nokia (2013) foram adquiridos ainda na época do Steve Ballmer. A empresa, como mostrado anteriormente, tinha uma filosofia completamente difernete da atual;
  • Não dá para compararmos a Nokia e o Skype com o GitHub. São produtos completamente diferentes, voltados para públicos completamente direrentes e que serão geridos por divisões da Microsoft completamente diferentes. São casos, em minha opinião, muito heterogêneos para serem comparados com propriedade e seriedade.

Por que a Microsoft comprou o GitHub?

O motivo exato ainda não está muito claro nem para quem trabalha dentro da própria Microsoft… Mas eu arrisco um palpite: acredito que a Microsoft tenha dois objetivos principais: se aproximar mais ainda da comunidade de desenvolvedores estando à frente de uma ferramenta que está entre as mais populares para desenvolvedores de software e fornecer uma integração mais sólida e prática com sua plataforma de nuvem, o Azure.

Estes dois objetivos parecem fazer muito sentido… Hoje, empresas de tecnologia conseguem compreender o poder que a comunidade de desenvolvimento tem e, por isso, estas empresas sabem que é necessário estar o mais próximo possível dos desenvolvedores, que são uma peça-chave na área de computação. E também parece bem coerente querer oferecer uma integração maior com o Azure a partir do local onde uma boa parte do código de aplicações está hospedada.

Para mim, isso ficou mais nítido ainda no comunicado oficial da Microsoft, no qual ela afirma que o GitHub responderá à Microsoft Cloud e ao vice-presidente da área de AI da empresa.

A Microsoft vai mudar o GitHub?

A Microsoft deixa claro em seu post oficial sobre o assunto que não vai mudar absolutamente nada no GitHub. E uma eventual mudança nem teria sentido, nem em questões tecnológicas, como em questões de negócio. Essas mudanças seriam inviáveis justamente por causa do tempo de estrada, estabilidade e reputação do GitHub. Não estamos falando de uma empresa de 3 anos, estamos falando de uma empresa com mais de 10 anos de estrada. E não é nem um pouco viável alterar os trilhos de 10 anos de história sob nenhuma ótica.

Para mostrar e deixar isso claro à comunidade, a Microsoft já nomeou Nat Friedman como o novo CEO do GitHub. Friedman é um dos fundadores da Xamarin e sempre deixou claro seu apoio ao open source, trabalhando com projetos da comunidade desde 2009.

Friedman, em um post de boas-vindas à integração Microsoft + GitHub, como novo CEO do GitHub, já deixou bem claro alguns pontos que preocupavam a comunidade:

  • O GitHub continuará com o modelo atual de negócios, ou seja: ele continuará aberto a comunidade e proverá serviços adicionais através dos valores citados. O foco do GitHub continuará a ser o desenvolvedor e suas comunidades. Nada irá mudar nesse sentido;
  • O GitHub irá operar de maneira 100% independente da Microsoft, como se fosse de fato uma subsidiária (em um modelo muito parecido com o que acontece com o .NET através da .NET Foundation).

Com estas afirmações (e são afirmações que não tem o porquê de não serem cumpridas), não há o menor motivo para preocupação com relação ao GitHub.

E agora?

Agora não há muito o que fazer, a não ser aguardar. Eu particularmente vejo que tanto a Microsoft como o GitHub podem crescer com essa junção. E se Microsoft e GitHub saírem ganhando, todos nós saímos ganhando também no final. Acredito que seria muito mais complicado se a Google (com suas políticas de privacidade duvidosas), o Facebook (com toda a complicação da licença do React) ou a Oracle (com sua mentalidade ainda mais voltada a software proprietário – vide o que aconteceu com o Java) tivessem comprado o GitHub. Mas, se tratando da nova Microsoft, acredito que isso possa ser interessante.

É importante também notar que esse tipo de transação no mercado é mais que comum… Não podemos esquecer que o GitHub também era uma empresa, tanto é que cobrava por determinados serviços. Empresas de sucesso no mercado estão suscetíveis a serem compradas por empresas maiores. Faz parte do mecanismo como um todo, e isso não precisa ser necessariamente ruim. E, provavelmente, ainda veremos situações como essa acontecerem mais vezes.

Vamos aguardar…

JUNTE-SE A MAIS DE 150.000 PROGRAMADORES