-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathGit_comandos_basicos.Rmd
91 lines (50 loc) · 8.85 KB
/
Git_comandos_basicos.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
---
title: "Comandos básicos do Git"
author: "Gabriel Nakamura"
date: "5/19/2021"
output: html_document
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE, fig.align = "center")
```
# Em cima, em baixo, *Push* e vai
Abre o computador, trabalha, modifica arquivo, salva o arquivo com um nome diferente do anterior, salva e atualiza a nuvem. Basicamente é isso que fazemos todos os dias, independente se você trabalha com taxonomia de bactérias ou com métodos quantitativos para taxonomia de bactérias. Basicamente, essa é a rotina de quem trabalha na frente do computador.
Todos esses passos são reproduzidos pelo Git de uma maneira muito mais eficiente, e ela pode ser resumida através dessas palavras: pull, diff, commit, push. Pronto, está completo o ciclo básico de operações necessárias para o controle eficiente de versões do seu projeto.
Apesar dessas ações apresentarem nomes próprios dentro do mundo do versionamento, quero que vejam que elas são bastante familiares, ou seja, fazemos operações de controle de versões quase todos os dias, porém de uma maneira menos eficiente e com menor controle. A grande diferença do uso de um sistema próprio de controle de versão, como o Git, é que ele permite que todos os passos destacados acima estejam sob o nosso controle, de maneira sistematizada e organizada. Em resumo, o Git não deixará você fazer nada que leve a uma cadeia de ações que leve o seu projeto ao caos como o dessa pasta, velha conhecida nossa, e que agora está fadada a ficar no passado:
Todos os documentos que aparecerão nessa aba são documentos que vivem na pasta monitorada pelo Git ([aprendemos como fazer isso na aula de introdução ao Git](https://gabrielnakamura.github.io/Curso_UFRGS_organizacao_de_dados/Intro_Git.html)) e que foram modificados. A partir desse monitoramento é que começa nossa via sacra do versionamento.
## A via sacra do versionamento
Como já comentado na [introdução ao Git](https://gabrielnakamura.github.io/Curso_UFRGS_organizacao_de_dados/Intro_Git.html), cada vez que um arquivo dentro de uma pasta observada pelo Git é modificada ele irá aparecer na aba *Git* do seu RStudio. A aba do Git no RStudio pode ser acessada facilmente, como mostrado nessa figura:
Precisamos aprender, basicamente, três funções básicas do Git para que possamos realizar o controle de versões em nossas pastas, [que nesse momento devem estar bem organizadas](https://gabrielnakamura.github.io/Curso_UFRGS_organizacao_de_dados/Organizacao_dir_local.html). São elas:
1 - **Pull** atualiza o seu repositório local com o que tem no seu repositório remoto (GitHub), ou seja, sincronizasua a pasta presente no seu computador com tudo que tem na nuvem;
Antes de começar a fazer qualquer modificação nos nossos arquivos a primeira coisa a ser feita é sincronizar nosso repositório remoto com nosso repositório local. Para isso acessaremos o Git a partir do RStudio presente na nossa pasta do projeto que estamos trabalhando, como mostrado na figura a seguir:
2 - **Stage** qualquer mudança realizada deve antes ser observada com cautela no nosso GitClient (RStudio), para que possasmos verificar as diferenças (diffs na linguagem do versionamento) entre a versão anterior e a atual, após as modificações realizadas. Fazer um stage significa selecionar o arquivo que fizemos as modificações, tal como mostrado na figura seguinte com um arquivo desse site que foi modificado em algum momento:
Ao fazermos isso podemos clicar na opção *Diff*, que irá abrir uma nova aba mostrando as diferenças entre a versão antiga e a nova versão do documento modificado
Olhar as diferenças é extremamente importante, pois são elas que possibilitarão indicar para o Git qual o commit que será feito, ou seja, dizer para o git o que foi modificado.
3 - **Commit** qualquer mudança realizada em qualquer arquivo, desde a menor vírgula até a mudança completa de seu repositório, deve ser acompanhada de um comentário breve destacando o que foi modificado, isso é o commit. Em outras palavras, é uma mensagem de texto para você mesmo, ou seus colaboradores, destacando o que foi modificado no repositório local observado pelo Git. O ideal é que o commit seja uma mensagem informativa e curta, não ultrapassando 40 palavras;
**Importante** Evite fazer commits que não sejam informativos, por exemplo, fazer commits só por fazer, tente nunca fazer isso. Mensagens como *modificação do arquivo*, *novo arquivo*, *arquivo_V1_novo*, *blablabla*, fazem com que o potencial de controle que o Git nos oferece perder completamente o sentido.
4 - **Push** as modificações realizadas em seus arquivos estão só na sua máquina, ou seja, o repositório remoto (seu GitHub) está desatualizado. Para atualizá-lo devemos fazer um *push*, que nada mais é que sincronizar o repositório local com o repositório remoto.
Esta é a sequência básica para que possamos realizar um versionamento eficiente em nosso projeto. De certa forma a sequência é simples, e toda ela pode ser feita usando os recursos da interface que o RStudio nos oferece. Porém, alguns probleminhas podem surgir no meio dessas etapas descritas, por exemplo:
## Fiz um commit, mas não deveria
O Git nos permite voltar no tempo de uma maneira muito eficiente
# Ignorando caminhos - o .gitignore
As vezes queremos que alguns documentos não sejam carregados na nuvem, por exemplo, aquele arquivo Word não finalizado e que você não quer tornar público ainda. Para isso podemos usar um arquivo com um nome bem intuitivo, na raiz do seu projeto, o **.gitignore**
Este arquivo, quando presente na raiz do projeto observado pelo Git, é primeiro lido e os padrões de extensões ou pastas nele presente são ignorados pelo Git, ou seja, eles não vão ser observados. Qualquer mudança feita neles não vai ser monitorada, logo, você não vai precisar subi-los para o GitHub. Por exemplo, um projeto onde quero ignorar arquivos de extensão `.Rproj`, `.Rhistory`, `.RData` e uma pasta inteira de Figuras (Figs_presentation/), irá apresentar o seguinte formato:
Para informações detalhadas de como usar esse recurso acesse essa [Referência](http://git-scm.com/docs/gitignore)
## Arquivos grandes - Git LFS
O GitHub não foi projetado pensando em hospedar arquivos que não são binários, por exemplo, Figuras em extensões como .png, .tiff, .jpeg. Sua principal função sempre foi, e ainda é, hospedar códigos em arquivos simples de texto, tal como nossos scripts em R. Porém, em alguns momentos não tem como fugir, e alguns arquivos pesados (>25Gb), como imagens de satélite, ou de elevado processamento, precisam ser hospedadas no nosso repositório, como fazemos? Para resolver isso precisamos utilizar uma extensão do Git chamado [Git LFS (Large File Storage)](https://qifengzhou.github.io/2018/04/29/Upload%20files%20bigger%20than%2025%20MB%20to%20Github/). Essa extenção funciona como um pacote, ela permite que o Git faça coisas que não estão na sua programação básica.
Para utiizar o Git LFS precisamos primeiro instalar esta extensão em nosso computador, sua instalação pode ser feita direta no [site do Git](https://git-lfs.github.com/), primeiro fazendo o download da versão adequada ao sistema operacional de sua máquina e depois seguindo os passos necessários para instalação.
Após instalado abra a linha de comando a partir da pasta do diretório que deseja que os arquivos grandes sejam upados para o GitHub e digite:
```{r echo=TRUE, eval=FALSE}
git lfs track "*.extensao"
```
Ao fazer isso estamos dizendo para o git permitir fazer o push de todos os arquivos que apresentam aquela extensao desejada, mesmo que eles sejam maiores que o tamanho máximo permitido.
**Em construção**
