Ai Fê, esse título aí já diz tanta coisa...
Pois é, não só diz muita coisa como também me vem o seguinte questionamento:
GitHub é para todo mundo?
Na minha opinião (que fique claro que é minha opinião), o uso do GitHub não é para todo mundo. E quando eu falo todo mundo, falo das pessoas que são da área da tecnologia, mas que não atuam em organizações que utilizam dessa ferramenta. Versionamento de código é utilizado para se ter o histórico das alterações e, de uma certa forma, fazer com que o time de desenvolvedores alcancem uma harmonia no trabalho em equipe.
E cai entre nós...
Não são todas as organizações que tem um time de dados e um projeto que demanda esse controle. O meu caso é um desses. Apesar de ter um time de dados, o uso do GitHub ou do vizinho mais novo GitLab, não foi necessário e, mesmo quando eu atuava como Cientista de Dados na Accenture, alguma dessas ferramentas sequer foram mencionadas como pré-requisito de vaga ou pelo time após a contratação. A real é que o time não precisava de versionamento de código naquele projeto e tudo deu certo. Mas veja que é por isso (também) que há muitos repositórios públicos em que as pessoas utilizam para disseminar conhecimentos gerais, versionamento de material de TCC, mestrado ou doutorado, resultados de competições ou simplesmente estudos de cases para construção de portfólio.
E Fê, você, atualmente, utiliza alguma ferramenta de versionamento de código?
Sim! Mas utilizo (ou deveria usar com mais frequência) o GitHub como portfólio e porque hospedamos os códigos dos cursos da R-Ladies Goiânia na plataforma. Pretendo também hospedar os códigos da minha dissertação por lá, mas por enquanto me aventuro nas boas práticas de versionar códigos de cases e cursos que vou fazendo ao longo da minha carreira. E, se você for ver o meu quadro de atividade, vai se deparar com uma calamidade. Quase nada verdinho.
Como assim quadro de atividade verdinho?
Outra coisa legal de comunicar é que assim que você abre a visão geral da sua conta, você se depara com os quadradinhos verdes da imagem abaixo e é óbvio que esse quadro de atividade aí não é o meu, esse aí é apenas ilustrativo. Eles medem pela tonalidade de sua cor o nível de atividade que você teve durante os dias de cada mês. Ao longo do ano há premiações para quem tá mais verdinho e contribuiu com repositórios, um bem conhecido é o GitHub Star.
Mas Fê, isso importa?
Eu acredito que o nível de atividade no GitHub não seja um decisor em entrevistas ou que seja uma métrica para avaliar o seu nível de conhecimento, então sem pressa de deixar tudo na tonalidade verdinho escuro, vamos aprender um pouco mais sobre essa ferramenta que brilha MUITO com a linguagem R e, aos poucos, os verdinhos vão aparecendo na sua conta.
Agora vem uma pergunta essencial...
Você tem o hábito de usar projetos no R?
Usar projetos no R é uma forma de não se perder em códigos, pastas e, consequentemente, caminhos de pastas e, particularmente, gosto de dizer que utilizar projetos também é se preocupar com a reprodutibilidade, principalmente se você pretende versionar com o GitHub. E claro, o hábito de usar projetos no R não deixa de ser uma forma de boas práticas, assim como nomear o pacote ao utilizar alguma função deste (Exemplo: tidyverse::tidyverse_packages()). Então, se você não utiliza projetos no R, hoje é um ótimo dia para iniciar esse hábito.
Vamos juntes e já abre o R aí...
Para criar um projeto, vai no canto superior direito do R que você vai encontrar a opção New Project como na imagem abaixo. Veja que no momento desse print eu não estava em algum projeto (Project: (None).
A partir disso, teremos as seguintes opções:
(1) New Directory: É a nossa primeira opção e a mais utilizada, mas através dela nós só vamos conseguir conectar com o sistema Git, que tem a mesma finalidade de versionamento, só que não estará conectado com o GitHub que é onde gostaríamos de compartilhar nossos códigos. Mas vamos devagar e operante que as coisas vão ir se encaixando. O interessante é que a partir daqui tudo pode ficar um pouco mais interessante.
Vamos se aventurar?
A primeira opção que nós vamos fazer é conectar o R com o Git. A partir daqui vou considerar que você já tem uma conta no GitHub e sabe criar um repositório, se você não tem, clica aí que o cadastro é rapidinho e gratuito e, para criar um repositório você pode utilizar a opção de acordo com a imagem a seguir.
Partindo do R sem algum código e, ao criar um repositório, nos deparamos com essa primeira opção de conexão.
Com a opção Create a git repository conseguimos versionar somente com o Git. Nesse caso há um pré-requisito que é a instalação do Software Git em nossa máquina. Você pode fazer isso através do link. Atualmente utilizo o sistema operacional Linux em sua versão Pop!OS e, conforme a ajuda do querido Ricardo, não é necessário instalar o Git, visto que este já vem no Pop!OS. Em todos os outros casos o Git deve ser instalado e é bem tranquila a sua instalação.
Git instalado?
Inicialmente a única configuração que vamos fazer no Git é em relação ao user e ao e-mail que vamos utilizar. Vai no terminal do RStudio e digite os passos 1 e 2.
(1) git config --global user.name "Seu nome"
(2) git config -- global user.email "Seu e-mail válido"
Vamos lá então...
Assim que você criar o projeto no seu canto direito você vai ver os arquivos de acordo com a imagem abaixo. No meu print temos o Step_Git.R e, já aproveitando, crie um arquivo .R (Atalho: CTRL + SHIFT + N) aí também pra gente brincar juntes com o Git.
Após a criação desse arquivo, no canto superior direito você vai observar que o arquivo Step_Git é novo no pedaço e, por isso, temos essa dupla "??" em Status. E agora chegou o grande momento...
Vamos "comitar"?
Mas pera lá, primeiro preciso entender o que é um commit. No contexto de ciência da computação, gerenciamento de dados e controle de versão, commit refere-se ao processo de tornar permanente um conjunto de alterações, ou seja, de efetivar as alterações. Um uso comum é a conclusão de uma transação. E agora que já sabemos o que é, vamos clicar em commit. Uma nova janela denominada por RStudio: Review Changes vai aparecer e com ela muitas informações.
Particularmente falando, eu acho lindo toda a possibilidade que o Git nos traz para entender cada passo a ser feito durante o versionamento. Nós temos a opção de observar as changes (mudanças), revert (reverter) e ignore (ignorar). No nosso caso, queremos dar commit em nossas alterações e, por isso, clica no Stage que automaticamente ele vai demarcar o arquivo Step_Git.R com um A na cor verde conforme imagem abaixo. Agora sim escreva o que você fez de alteração na Commit message e, em seguida, clica em Commit. É válido ressaltar que a mensagem não é obrigatória, mas é bom né?
Após o commit, a janela Git Commit irá aparecer e com ela você terá a algumas informações bem interessantes. Conforme as suas alterações são feitas, ele vai te ensinando a fazer as alterações direto do terminal. É bem comum que a comunidade utilize o terminal, mas nós podemos ir devagar e ir entendendo cada comando do Git através desses pequenos informativos.
Tá feliz com o seu commit?
Eu realmente espero que sim...
Agora vamos dar mais um passo.
Vamos falar de Branch?
Confesso que essa nomeação não me ajudou muito a entender o conceito, mas no final as ideias vão se encaixando. A tradução literal de Branch é "ramo" e, se você voltar nas imagens anteriores, você vai perceber que estamos trabalhando na branch master. Ou seja, temos um ramo principal e podemos criar ramos secundários.
Mas por que eu iria criar branch secundárias?
Essa pergunta ecoou na minha cabeça por muito tempo e quando fui pesquisar um pouco mais sobre os tais ramos, vi que não passa da ideia básica de se ter um time de desenvolvedores e cada um deles ter sua própria branch. É por isso que se fala tanto em conflitos de merge de commit e, com toda certeza, deve ser um pepino resolver esses conflitos. Veja que na imagem de mensagem do commit o Git nos informa que é possível fixar um usuário para tal também, mas vamos nos atentar aos ramos.
Agora...
Criar uma seria legal, né?
Let's bora criar uma branch. No canto superior direito você vai ver um ponto clicável denominado por New Branch na cor roxa. Clica nele aí.
Eu vou dar o nome de "Estrela", afinal é a minha primeira branch criada e quero dar uma estrela para ela. Se você observou bem, temos a opção de adicionar essa branch remotamente e nós vamos descobrir o que ela é juntes.
Você tentou finalizar esse acesso remoto?
Se sim, você viu que ele foi descontinuado em Agosto de 2021. Então vamos focar na branch local e seguir o roteiro. Quando criamos a nova branch, no meu caso a Estrela, temos a possibilidade de navegar entre a branch master e a nova que criamos. Se assim como eu, você foi criando ramos e agora deseja excluir, vamos trabalhar um pouco no terminal. Primeiramente, mova-se para o ramo master e execute no terminal os seguintes comandos:
sudo apt instal rheolef: Instala os pacotes necessários do Git
git branch -d Nome da Branch: exclui de fato a branch desejada
Aprendemos a criar uma branch através do RStudio e a excluir pelo terminal. Para criar uma branch pelo terminal basta executar o seguinte comando:
git checkout -b Nome da Nova Branch
Na imagem abaixo você consegue ter acesso as mais variadas formas de trabalhar com branch. E vale lembrar que estamos fazendo tudo localmente.
Vamos fazer um merge commit?
Esse é o temido das sextas do proletariado, mas agora a nossa intenção é criar uma situação que dê conflito no merge. Como você já aprendeu a criar ramos, cria mais um além daquele que acabamos de criar. Em ambos escreva algo e, em apenas um ponto, faça algo de diferente. O que fiz está abaixo.
Branch Estrela: # Vendo como funciona o commit em uma nova branch!
Branch Teste: # Vendo como funciona o commit em uma nova branch;
A diferença é no ! e ; de cada branch. Ao executar os seguintes comandos no terminal,
git checkout Estrela
git merge Teste
você terá como resposta a mensagem conforme imagem abaixo.
Conflitamos?
Conflitamos! Agora é resolver esse BO da melhor forma possível.
Vamos lá?
O R nos traz essa mensagem linda, com o apontamento da linha que está diferente, afinal o conflito é referente a coisas diferentes na mesma linha e posição. O Git sabe em qual branch nós fizemos o checkout usando um ponteiro especial chamado HEAD e, por isso, na mensagem retornada nós recebemos o HEAD e o Teste, conforme imagem abaixo. Para solucionar esse conflito, basta alterar o HEAD ou o Teste da forma que desejamos e, após essa alteração, que elas fiquem idênticas. Eu vou escolher o ponto de exclamação como o "correto".
Após a alteração, faça o commit e depois o merge.
Você verá que não há mais conflitos entre as branch com a mensagem de Already up to date. E claro, o que não falta são formas de resolver BO, mas o básicão acabamos de entender como funciona e fizemos o merge rodar no R corretamente.
E o que mais podemos fazer, Fê?
Todos os comandos via terminal do Git vocês podem utilizar e, para quem não sabe, o R é tão incrível que você consegue programar em C++, Python, JavaScript, CSS, HTML e conectar com a maioria das variantes de gerenciadores de banco de dados.
Mas agora vamos pensar em GitHub...
Veja na imagem abaixo que as opções de Pull e Push não estão aptas para uso, mas todas outras funções sim e que, inclusive, foram as funções que usamos até o momento. Porém, as funções Pull e Push são funções utilizadas somente com o GitHub conectado e essa não foi a forma com que abrimos esse projeto, lembra? Nós abrimos um git repository e estamos trabalhando com ele desde então.
Agora imagina que nesse projeto você já fez muita coisa e gostaria que tudo que estivesse nele fosse versionado com o GitHub, mas você não conectou lá no início e para versionar você vai ter que baixar tudo e fazer upload no repositório.
Bateu aquela preguiça, né?
Mas, tenho uma boa notícia para você: essa trabalheira é desnecessária. Em 2018, Hadley Wickham, Jennifer Bryan e companhia, criaram um pacote que mudaria toda a dinâmica entre RStudio, Git e GitHub. Juntos eles criaram o pacote usethis que automatiza tarefas de configuração de pacotes e projetos que seriam executadas manualmente. Isso inclui a configuração de testes unitários, cobertura de testes, integração contínua, Git, 'GitHub', licenças, projetos 'Rcpp', 'RStudio' e muito mais.
E é óbvio que a gente vai utilizar essa belezura de pacote. Já vai instalando e carregando o pacote aí no seu RStudio.
install.packages("usethis")
library(usethis)Instalou?
O processo a partir daqui é um pouquinho chato, mas não é nada impossível e nem precisa de desespero. Sabe aquela CONTA no GitHub que pedi pra você fazer? Você fez? Tô de olho em você hein... Se não fez vai lá fazer que agora é o M O M E N T O. Nós vamos precisar de um token de acesso. O token é utilizado para autenticação e autorização, um token é um objeto digital que contém informações sobre a identidade do principal que faz a solicitação e para que tipo de acesso ele está autorizado.
Você não achou que qualquer um poderia acessar seu GitHub na maciota, né?
No RStudio, solicite um token através do comando abaixo.
usethis::create_github_token()Você vai logar na sua conta e a seguinte janela vai aparecer. Vá até o final e clique em Gerar Token.
Outra janela vai abrir já com o seu token de acesso. Geralmente ele inicia com ghp_. Copia e cola em algum lugar ele aí.
Para usar esse token de acesso, nós precisamos de um arquivo chamado de .Renviron. O arquivo Renviron contém listas de variáveis ambientais a serem definidas. Este não é um código R, ele usa um formato semelhante ao usado no shell da linha de comando e, a maneira mais fácil de edita-lo, é executando executando usethis::edit_r_environ() . É nesse arquivo que nós vamos inserir o nosso token.
usethis::edit_r_environ()No arquivo .Renviron você vai digitar GITHUB_PAT e entre aspas vai colar seu token gerado anteriormente.
Vamos ver como está a nossa situação com essa conexão?
Mete o louco na linha de código com o comando usethis::git_sitrep() que tem a finalidade de entregar um relatório de situação sobre o nosso status atual do Git/GitHub. Ele é útil para diagnosticar problemas e o padrão desse comando é reportar todos os valores.
usethis::git_sitrep()O início do resultado a partir desse comando é esse abaixo.
Aqui no meu rodou liso e espero que aí também, mas se não rodou, comenta aí que eu te ajudou ou entra em contato comigo lá no linkedin que juntes a gente faz esse negócio funcionar.
Se tudo foi liso,
Bora fazer funcionar?
Antes de T U D O... É importante dizer sobre a minha experiência em tentar fazer essa conexão com o GitHub em um projeto que eu tinha mais de uma branch além da branch main. A questão é que simplesmente não deu certo. Só após excluir as branch secundárias que consegui fazer essa conexão. Atualmente não sei lhe explicar o porque desse empate, mas estou aqui lhe dizendo que ele existe. Então, se aí deu ruim, provavelmente foi devido as branch secundárias que criamos para simular um conflito. Exclui elas pelo terminal que tudo vai dar certo.
Agora é a hora da verdade. Com apenas dois comandinhos e desde já agradecemos MUITO os idealizadores desse pacote incrível, tudo se ajeita lindamente. O Git a gente já estava utilizando, mas é bom se precaver e rodar os dois comandos abaixo e esperar a mágica (que de mágica não tem nada) acontecer.
usethis::use_git()
usethis::use_github()E aí, deu certo?
Se deu, uma página do GitHub aparecerá conforme imagem abaixo.
Veja que o arquivo Step_Git.R está ali e é nesse momento que vamos iniciar a aventuras do Pull e do Push. Esses nomes são para os mais íntimos, na real é Pull Request e o outro é Git Push mesmo. Perceba que depois que nós conectamos com o GitHub, o RStudio habilita essas duas funções para uso.
As setinhas são bem intuitivas. Push é para enviar o que temos de novo em nosso código e o Pull para trazer algo novo, mas é agora que você me pergunta:
Nera' o commit que enviava as alterações feitas no arquivo?
As solicitações de Pull permitem que você informe outras pessoas sobre as alterações por Push feitas em uma branch de um repositório no GitHub. Após a abertura de uma solicitação de Pull, você poderá discutir e revisar as possíveis alterações com colaboradores e adicionar confirmações de acompanhamento antes que as alterações sejam mescladas na branch base. É interessante ressaltar que as páginas de comparação (commit) e Pull Request usam métodos diferentes para calcular o diff para os arquivos alterados:
As páginas de comparação mostram a diferença entre a ponta do ref principal e o ancestral comum atual (ou seja, a base de merge) do ref principal e de base.
As páginas de Pull Request mostram a diferença entre a ponta do ref principal e o ancestral comum do ref principal e de base no momento em que o Pull Request foi criado. Consequentemente, a base de merge utilizada para a comparação pode ser diferente.
Tudo isso é para dizer que existe diferença entre as funções commit, Push e Pull Request.
Dito tudo isso, se você tentar fazer um commit, você verá que não há alguma alteração a ser enviada, mas se você for fazer um Push...
Chegou a hora do Push, né?
Chegou! E aqui a gente precisa trocar uma ideia sobre um possível erro. Desde 2021, O GitHub deixou de fazer autenticação remota através de user e senha da nossa conta GitHub. Agora, em vez de usar a nossa senha, nós vamos utilizar um token. Nós podemos utilizar o mesmo token que utilizamos para fazer a conexão, mas lembre-se que ao criar o token nós temos a opção de inserir a quantidade dias que esse token irá existir e o nosso tem duração de 24 horas. Mas não se assuste, você pode gerar um direto do GitHub indo em configurações -> configurações do desenvolvedor -> Tokens de acesso pessoal e seguir lindamente com o seu novo token. E agora mais uma noticia chatinha,
Toda vez que você for fazer um Push, o RStudio irá te solicitar user e token.E vou te dizer, isso é um saco. Mas é claro que não é em todo momento que vamos fazer um Push, o que nós vamos fazer muitas vezes ao longo dos nossos projetos são commit e isso já dá uma aliviada.
Tá, e o que mais tem de bom nisso aí?
A questão é que até o momento nós saímos de um projeto que estava em máquina e subimos para o GitHub, mas e quando nós temos um projeto dentro de um repositório do GitHub e queremos trazer para a máquina? É nessa situação que temos que fazer uma conexão via Version Control.
Nesse caso temos que criar um novo projeto com essa opção. E cai entre nós, é mais clonar um repositório do que criar.
(2) Version Control: Clique em New Project como fizemos no início desse post e você terá as seguintes opções como na imagem abaixo. No primeiro momento nós escolhemos New Directory, mas agora vamos escolher Version Control.
A segunda janela a ser aberta é a seguinte:
Você vai escolher a opção Git (Clone a project from a Git repository). A frase já é bem clara, nós vamos clonar um repositório para a nossa máquina, como eu havia dito anteriormente.
O que isso significa?
Significa que vamos ter um espelho daquele repositório em nossa máquina. E é bem tranquilo de fazer.
Ao clicar na opção Git (Clone a project from a Git repository), você terá como resultado a seguinte janela:
Aqui você precisa da URL do repositório. Vai lá no repositório que você vai clonar e clique em Code, copia o HTTPS e seja feliz.
E quantos projetos ou repositórios eu posso ter? Tem algum limite?
Para a nossa felicidade, NÃO tem limites se você tiver utilizando o R na sua máquina, mas se você tiver utilizando o Posit Cloud gratuito, esse sim te dá uma limitação de 10 projetos e, se no seu trabalho você utiliza alguma Cloud, provavelmente te limitaram a somente um projeto, até porque Cloud é um serviço caro. E olha só, você não é abrigade a criar um projeto para fazer a conexão do R com o Git ou do GitHub com o R, isso fica a seu critério.
E olha só, se você tem interesse em estudar algum repositório que não é seu, o primeiro passo é fazer um Fork do repositório alheio e assim trazer ele para a sua máquina com essa conexão que acabamos de aprender.
Muita informação, né?
Eu acho que paramos por aqui. Pelo menos através desse post eu acho que você já consegue dar brincada por aí e dizer que sabe o básico dessa ferramenta e já fazer seu quadro de atividade um pouco mais verdinho que o meu (rs). Mas olha só, vou deixar aqui o link do curso de Introdução ao Git e GitHub que a Beatriz Milz deu na R-Ladies Goiânia e também vou deixar o link do curso de GitHub Actions que ela e o Julio Trecenti deram juntos também na R-Ladies Goiânia. E claro, o que não falta são materiais e coisa para estudar e, por isso, quero deixar também o link do Happy Git e GitHub for the useR.
Espero que você tenha gostado e que passe a utilizar e estudar mais sobre esse universo de versionamento. Até mais!
Fernanda Kelly R. Silva | Estatística