---
title: "Capítulo 7: Trabalhando em equipe"
author: "PET-Estatística UFPR"
output: 
  html_document: 
    keep_md: yes
---

O Git é uma ferramenta que aliada a outros serviços web, como GitLab ou 
GitHub, oferece funcionalidade e autonomia para se trabalhar. 
Contudo, com tantos recursos disponíveis, só serão bem aplicados quando 
todos os membros do grupo, além de conhecê-los, trabalham em harmonia.

## 1.Boas práticas de colaboração

Repositório é onde são armazenados os arquivos de um projeto. Existem 
três níveis de acesso permitidos:

- **Private**: é o repositório fechado, onde apenas o criador (Owner) tem 
permissão de leitura e escrita. Se um repositório privado for criado 
dentro de um grupo, todos do grupo terão permissão de leitura e escrita.


- **Internal**: é o repositório é fechado para usuários externos ao
grupo, mas qualquer usuário cadastrado no grupo terá permissão de leitura
e escrita no repositório.


- **Public**: é o repositório é aberto para qualquer pessoa, e fica
visível para qualquer um (usuário do grupo ou não). Usuários do grupo
tem permissão de leitura e escrita no repositório. Usuários sem conta 
no grupo podem clonar o repositório, mas não tem permissão para alterar 
o repositório (enviar merge requests por exemplo).

É possível adicionar usuários para colaborar em um repositório. Cada 
usuário pode ter um nível de acesso diferente: **Guest**, **Reporter**,
**Developer**, **Master**. Em <a href="https://gitlab.c3sl.ufpr.br/help/permissions/permissions">
permissões</a> é possível visualizar as habilidades concedidas para cada 
nível.

Logo após criar um novo repositório, é recomendável que se crie um arquivo
`README.md`. Independente da forma como o repositório foi configurado, 
é sempre fundamental que ele contenha o arquivo `README.md`. 
Este arquivo é sempre o primeiro a ser mostrado na página inicial 
de todo repositório. Por esse motivo, é importante que o `README.md` 
contenha no mínimo:

- Uma descrição geral do projeto;
- Os nomes dos autores do projeto;
- Instruções de instalação, no caso de softwares;
- A licença do projeto (especialmente para projetos públicos), ou uma 
orientação sobre o uso do projeto (permissão, citação, ...). 
Opcionalmente pode-se criar um arquivo *LICENSE* com a licença. 
Esse arquivo ficará disponível também em uma aba na página inicial do 
projeto.
- (**Opcional**): um guia de contribuição, se o projeto pretende que 
colaboradores externos colaborem e precisam de algumas orientações básicas
sobre como colaborar. Criando um arquivo `CONTRIBUTING.md` com este guia,
ele será automaticamente colocado em uma aba na página inicial do projeto.
- (**Opcional**) um *changelog* para que sejam registradas as modificações 
realizadas entre uma versão e outra (principalmente para softwares). 
Criando esse arquivo com estas informações, ele aparecerá automaticamente 
em uma aba na página inicial do projeto. 

Outra parte fundamental do git, são os **commits**. Além de salvarem as
alterações realizadas nos arquivos, também são responsáveis por documentar
as alterações feitas por qualquer usuário e em qualquer arquivo.
Por causa dessa importância, uma mensagem bem escrita é a melhor forma 
de se comunicar a alteração para os demais membros do grupo e para você 
mesmo. Essas mensagens também aparecerão no git log do projeto,
por isso é essencial que sejam bem escritas, de forma clara e sigam um 
padrão.

Algumas **regras de ouro** para que um projeto versionado com git 
seja bem sucedido são:

- Faça commits regularmente: isso faz com que as mudanças de código 
entre um commit e outro sejam menores, tornando mais fácil para todos 
acompanhar as alterações;
- Não faça commits de trabalhos pela metade: faça um commit apenas 
quando tiver finalizado o que estava propondo. Isso irá forçar você a 
deixar o trabalho em pedaços menores, e por consequência realizar
commits regularmente.
- Teste antes de fazer um commit: resista à tentação de fazer um commit 
que você pensa que está completo. Teste toda a sua realização para 
ter certeza de que não causará um efeito colateral no projeto.
- Escreva boas mensagens de commit: seja claro e objetivo ao escrever 
as mensagens de commit. No entanto, tome cuidado para não ser vago, ou 
escrever apenas `mudança`, `mais mudanças`, etc. Se uma mensagem curta for suficiente, use `git commit -m 'Mensagem'`, mas lembre-se de ser 
informativo sobre a alteração realizada, para ser útil para todos do 
projeto.


- **Repositórios: níveis de acesso, adicionar colaboradores, configuração 
inicial do repositório**

- **Commits: convenções gerais** e *específicas*


## 2.Modelos de fluxos de trabalho

- *Descrever os quatro principais tipos de workflow (Centralized workflow,
Feature branch workflow, gitflow workflow e Forking workflow)*

- *Materiais de apoio* <a href="http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md">
gitlab-rautu do Fernando Mayer</a> ; 
<a href="https://prezi.com/_lm8kozmii8n/git-workflow/"> apresentação do 
Diego G. Pasqualin</a>


## 3.Fluxo de trabalho PET no GitLab

- *Funcionamento da elaboração da apostila*