---
tags: Apresentações, RPGTools, git
---

# RPGTools - Git

## Tecnologia para melhorar seu RPG

## Episódio 2 - `git` , `github` e `gitlab`

---

# O que é `git`?

----

+ Ferramenta de controle de versão de arquivos
+ Controle de alteração dos arquivos
+ Permite o retorno a versões antigas em caso de problemas

----

Muito usado em desenvolvimento de software

----

Criador: _Linus Torvalds_ (criador do Linux)

----


----

## Distribuído

Permite que várias pessoas editem localmente suas coisas e depois compartilhe suas alterações

---

# Pequeno dicionário `git`

----

## Repositório (`repo`)

O seu projeto (ou uma cópia dele). Pode ser local e/ou remoto

----

## Diretório de Trabalho

É onde você está trabalhando... Pode ___ou não___ estar modificado

----

## _Stage Area_

É o "estado atual estável" do seu projeto

----

## _Commit_

Ao terminar de manipular os arquivos, você deve realizar o _commit_ (ou _commitar_) para realizar a gravação das alterações dos seus arquivos para a _stage area_. Será pela _stage area_ que você irá pegar suas alterações e as sincronizar com ambientes remotos

----

## Remoto

De maneira geral, um _remoto_ é um repositório que contem os mesmos conteúdos do seu repositório em outro local. Um remoto pode estar hospedado em um servidor público ou privado e pode ser acessado por várias pessoas. Após um _commit_, o `git` permite que vários repositórios remotos possam ser adicionados

----

## _Push_ e _Pull_

Sincronizar seu repositório enviando para (_push_ - empurrar) ou trazendo do (_pull_ - puxar) remoto as informações de/para um repositório remoto.

----

## Conflitos

Em um ambiente em que vários usuários estão utilizando o mesmo repositório remoto, pode acontecer de várias pessoas trabalharem em arquivos localmente e modificar trechos nos mesmos arquivos. Quando isso ocorre, pode acontecer conflitos quando trechos similares são alterados. O `git` pode tentar resolver os conflitos, mas pode acontecer de necessitar intervenção humana.

----

## _Merge_

Caso ocorra conflitos, antes de poder realizar o _commit_, deve-se resolver os conflitos e realizar o _merge_ para indicar que esse conflito deve ser considerado resolvido por outros repositórios. De outro modo, nenhum _commit_ será aceito.

----

## _Log_

Toda vez que um _commit_ for realizado, o 'git' exige que seja publicado uma nota sobre o que foi alterado como registro. Esse _log_ também é incluído como parte do _commit_, com data e informação de quem realizou tais alterações, além de uma _hash_ relacionada ao _commit_ que permite realizar o _reset_

----

## _diff_

De _difference_ (diferença). Permite rastrear as alterações realizadas, como forma de corrigir falhas ou realizar o _rollback_ (retroceder) a versões anteriores

----

## _Reset_

Quando você volta atrás a uma versão anterior de um arquivo ou de um repositório. Potencialmente destrutivo!

----

## _Branch_

Um _branch_ permite criar uma "versão estável" do repositório. Pode ser usado tanto para manter uma "versão antiga congelada" do repositório quanto um local onde você pode trabalhar tranquilamente sem correr risco de estragar seu projeto principal (_master_).

----

## _Checkout_

Para alternar entre _branch_, você deve realizar o _checkout_, que vai tornar o seu diretório de trabalho com os conteúdos do _branch_ em questão.

É possível dar _merge_ de conteúdo de um _branch_ para outro à vontade

----

## _Master_

É o _branch_ principal do repositório e é criado automaticamente, seja pela _inicialização_ quanto pela _clonagem_

----

## Inicializar

Criar um ambiente inicial, criando o _Stage Area_

----

## Clonar

Realizar a cópia de um repositório remoto de um servidor para seu computador. Ele já prepara também a estrutura para sincronizar o repositório remoto com as alterações locais.

---

# Instalando o `git`

----

Versões para todas as plataformas principais (Windows, Linux, Mac...)

----

## Linux

É incluído em todas as principais distribuições

+ `apt install git`
+ `yum install git`
+ `pacman -S git`
+ `emerge git`
+ ...

----

## Windows

Baixe e instale o executável de:

<http://msysgit.github.com>

----

Existem clientes para celular também

---

# Primeiros passos

---

## Configuração padrão

----

Importante para facilitar o gerenciamento do repositório

+ `git --global user.name` - Nome que irá aparecer em seus _commits_
+ `git --global user.email` - Seu email

Você pode modificar esses parâmetros dentro de outros repositórios

---

## Inicializando

Você pode inicializar um repositório zerado ou _clonar_ um remoto com conteúdo já existente

----

## Inicializando do Zero

`git init`

Você pode transformar qualquer diretório do seu computador em um repositório `git`. Esse comando não é destrutivo e vai criar todos os arquivos necessários para seu _stage area_ em um diretório especial dentro chamado `.git`

----

## Clonando

`git clone <URL>`

Esse comando irá copiar todo o conteúdo do repositório remoto, mais toda a estrutura necessária para o _stage area_ em um diretório abaixo de onde você está, com o nome igual a URL. Você pode renomear ele normalmente.

----

## Diretório especial - `.git`

+ Contem as informações sobre os _updates_ do _stage area_
+ Apagar o mesmo acaba "matando" a funcionalidade do _git_.
+ Informação principalmente em estado binário: melhor operar via comandos git

----

## Arquivo `.gitigonore`

+ Permite configurar arquivos/pastas a não serem monitorados no diretório de trabalho.
+ Em geral, arquivos temporários e afins

---

## Adicionando arquivos

`git add`

Usando esse comando, você irá adicionar os arquivos ao _stage area_. Esses arquivos passam a ser "monitorados" pelo `git` (qualquer alteração será alertada no momento de um _commit_). Arquivos que não sejam monitorados (_untracked_) podem provocar alertas.

----

`git add -A`

adiciona todos os arquivos (_diretórios inclusos_) dentro do diretório do projeto ao _stage area_

---

## Registrando as modificações

`git commit`

Esse comando registra todas as alterações dos arquivos monitorado no `git`. Ao realizar o _commit_, um editor será aberto para que você registre as motivações da alteração (para fim de auditoria).

----

`git commit -am '<motivo>'`

evita a abertura do editor, registrando a alteração com o motivo marcado]

---

## Criando e alternando entre _branches_

`git checkout <branch>`

Esse comando permite alterar entre _branches_ dentro de um repositório `git`

----

`git checkout -b <novo_branch>`

cria um novo _branch_ e alterna automaticamente para o mesmo

---

# Primeira Prática

---

## _Logs_, _Diffs_ e _Reset_

----

_Logs_ são úteis para verificar ___quem___ fez ___o que, quando___ e ___porquê___

----

_Diffs_ permitem analisar o que foi modificado entre você e a última atualização do _stage_

----

_Resets_ permitem devolver o seu ambiente à última versão

---

## Verificando o registro

`git log`

----

Normalmente é bem _verboso_ (completo). Algumas opções podem tornar a saída _one-liner_

---

## Apresentando as diferenças

`git diff`

----

Mostra as alterações entre o que você fez e o que está no _stage_

---

## Desfazendo as burradas

`git reset`

----

Devolve o ambiente ao último _commit_ realizado

---

# Segunda Prática

---

## Branches

----

Às vezes, queremos fazer alterações que não interfiram no que já fizemos...

----

...ou queremos salvar um "ponto de retorno" para caso realize _muita_ besteira.

---

_Branches_ são a a solução

----

"Galhos" que servem como ponto de modificação segura.

---

## Criando Branches

`git branch add <branch>`

----

Cria um _branch_ novo

---

## Mudando de _Branch_

`git checkout`

----

Reconfigura seu ambiente para representar aquele _branch_

----

Usando a opção `-b` cria automaticamente um novo _branch_

----

___Master:___ _Branch_ especial

---

## Fundindo as modificações entre _branchs_

`git merge <origem> <destino>`

----

Permite que você traga todas as alterações de um _branch_ em outro

----

_Git_ possui uma certa capacidade de _resolução de conflitos_

----

Caso não seja possível, procedimento é:

1. _Resolver os conflitos_ (editar os arquivos e remover os trechos que não serão adotados)
2. realizar o _commit_ da correção

----

### NUNCA DÊ COMMIT SEM RESOLVER CONFLITOS!!!!

Em caso de dúvidas: `reset`

---

# Terceira prática

---

## Remotos

----

Desenvolvimento distribuido: problema sério em sistemas de controle de versão antigo

----

Usuário A mexia no código em `a.prog`...

... onde Usuário B também estava mexendo.

----

Soluções variadas:

1. Trancamento do arquivo (apenas um usuário podia editar por vez)
2. Resolução automática (o sistema resolvia por si só conflitos)
3. Duplo _commit_ (o sistema exigia que todos os envolvidos no conflito realizassem _commit_)
4. ...

---

## Distribuição

----

Faz todas as modificações localmente

----

Puxa (`pull`) novas atualizações de um repositório remoto confiável

----

Empurra (`push`) alterações

---

## Eficiência comprovada

----

O Código pode ser auditado, verificado e assinado para garantir que um usuário qualquer não modifique partes importantes do projeto

---

## Múltiplos remotos

----

Pode-se configurar o `git` para puxar/empurrar alterações de múltiplos repositórios remotos

----

Minha máquina, um remoto no _github_, um remoto do _Linux.org_, ...

---

### `git remote`

Comando base para tudo que lida com remotos

---

## `Github.com`

----

Serviço colaborativo de versionamento de código

----

Funciona como um _frontend_ para uma série de funções do _github_

----

Extremamente popular

----

Adquirido pela Microsoft em 2018

---

## `gitlab.com`

----

Serviço similar ao _github_, com maior número de funcionalidades

----

Código disponível no próprio _gitlab_ como repositório remoto

----

Possui versões pagas e que podem ser produzidas em sua corporação

---

## Adicionando um remoto

----

`git remote add <nome> <url>`

----

"Conecta" seu repositório local ao repositório remoto

---

## "Empurrando" as atualizações

----

`git push <nome> <branch>`

----

Empurra para o repositório remoto `nome` todas as modificações no _branch_

----

Se utilizar o comando sem um _branch_, o comportamento vai ser errático...

---

## "Clonando" um repositório remoto

----

`git clone <url>`

----

Clona um repositório remoto em um diretório igual ao nome do repositório remoto.

----

Se colocar `-o <nome_remoto>` após `git clone`, coloca outro nome para o remoto ao invés de `origin`

---

## "Puxando" novas alterações

----

`git pull <remoto>`

----

Atualiza seu _stage_ e seu diretório de trabalho com as novas modificações no repositório remoto

----

Não pode ser feito com o _stage_ "sujo" (com modificações não comitadas)

----

Irá informar em caso de conflitos que não possam ser resolvidos

---

# Terceira Prática

---

## Para que posso usar isso?

----

Qualquer documento texto pode ser gerenciado

----

Outros formatos também, mas fica mais complexo e perde funcionalidades

----

Compartilhamento de informações com rastreabilidade

----

Fichas de personagem, Registros de Campanha, Controle de Mesa, etc...

----

Somado com _Markdown_ se torna muito poderoso

---

## Alguns repositórios curiosos de RPG

----

<https://github.com/amazingrando/fate-srd-content>

SRD do Fate em Formatação _Markdown_

----

<https://github.com/openadventure/Open-Adventure>

Jogo _Old School_ totalmente aberto

----

<https://github.com/brunobord/the-black-hack>

Repositório com várias traduções do jogo _Black Hack_

----

<https://github.com/capheind/ACKS_SRD>

SRD do sistema Old School _Adventurer Conqueror King_

---

# Perguntas?

---

Apenas o Começo...

... Milhões de tutoriais na Internet

----

Uma boa opção (em inglês)

<https://www.codecademy.com/learn/learn-git>

---

# Referências

+ _Pro Git_ - <https://git-scm.com/book/en/v2>

---

# Obrigado!