A escolha do *workflow* (fluxo de trabalho) depende de cada projeto e das preferências pessoais. Podemos utilizar as informações sobre cada *workflow*, e decidir qual é mais adequado para cada projeto. Existem quatro maneiras
principais de trabalhar em colaboração com o git e o GitLab:
- **Centralized workflow**: recomendado para projetos pequenos, e/ou que
não necessitam de muitas alterações. Nesse workflow, o repositório possui
apenas um brach (`master`) e as alterações são feitas nesse branch. As
revisões só poderão ser realizadas depois que tudo foi enviado para o
servidor remoto. Com isso, há uma grande chance de ocorrerem conflitos.
- **Feature branch workflow**: recomendado para projetos pequenos e grandes
que envolvam mais de um colaborador. O projeto principal é mantido no
branch master. Se um membro quiser realizar alguma alteração, deverá criar
um novo branch `feature`, e fazer as alterações nesse branch e sugerir um
`merge request`. Com isso, os demais colaboradores poderão revisar
as alterações sugeridas e discutir as modificações, até que uma pessoa
habilitada faça o merge desse branch `freature` para o branch `master`.
Dessa forma, evita-se os possíveis conflitos e garante que tais alterações
não causaram algum problema. Esse workflow é altamente recomendado por
ser simples de gerenciar, evitar grandes conflitos, e ser relativamente
fácil para usuários novos do git.
- **Gitflow workflow**: indicado para projetos maiores e/ou com um grande
número de colaboradores. Esse workflow envolve a criação de alguns branches
com funções específicas. Todo o desenvolvimento é realizado no branch
`develop`. Quando uma versão está pronta, ela é movida para o branch
`release`, onde é testada e finalmente incorporada ao ramo master,
que contém apenas versões finais (estáveis). É extremamente recomendado
esse workflow para desenvolvimento de softwares, porém exige de mais
familiaridade com o git. Permite, por exemplo, que os usuários de um
software, instalem tanto uma versão estável (do branch `master`) quanto
uma versão em desenvolvimento (do branch `develop`).
- **Forking workflow**: recomendado para projetos abertos, onde se espera
usuários externos façam contribuições. Esse workflow consiste de um repositório oficial, de onde os colaboradores fazem um `fork` desse repositório, e passam
a desenvolver o projeto de maneira independente. Assim, cada colaborador
poderá adotar o workflow de preferência, e não precisará ter acesso ao
repositório oficial, apenas colaborar enviando `merge`.
Independente da escolha do workflow para cada projeto é importante sempre
informar o método que está sendo utilizado para seus colaboradores,
para que eles possam seguir o mesmo padrão. Essas informações poderão ser
descritas em `README.md` ou no `CONTRIBUTING.md`.
### Esqueleto do tópico
- *Descrever os quatro principais tipos de workflow (Centralized workflow,
- *Descrever os quatro principais tipos de workflow (Centralized workflow,
Feature branch workflow, gitflow workflow e Forking workflow)*
Feature branch workflow, gitflow workflow e Forking workflow)*
...
@@ -175,4 +220,30 @@ Diego G. Pasqualin</a>
...
@@ -175,4 +220,30 @@ Diego G. Pasqualin</a>
## 3.Fluxo de trabalho PET no GitLab
## 3.Fluxo de trabalho PET no GitLab
O PET-Estatística UFPR possui um grupo no git para o desenvolvimento de
projetos. Um desses, é a apostila do git. Esse projeto teve como finalidade
melhorar o conhecimento sobre o Git, e documentar em forma de apostila
para outros usuários do git.
Para esse projeto, tivemos dois ramos:
- `devel`: recebeu as contribuições dos membros, e após avaliação,
a contribuição foi movida para o ramo `master`.
- `master`: recebeu a versão estável do projeto.
Esses ramos só receberam conteúdo provenientes de `merge` dos ramos de
demanda (*issue*)
Os membros criaram `issue` para adicionarem suas contribuições.
Por exemplo, para adicionar um capítulo sobre o uso do programa,
foi criado um ramo para isso, depois de adicionar as contribuições, foi
submetido esse ramo para o repositório remoto.
Após o `git push`, a próxima etapa é a requisição de `merge`. Com esse
`merge`, era feita as discussões a respeito da contribuição. Após da
certeza dessa contribuição, era movida para o ramo `master`.
A escolha do *workflow* (fluxo de trabalho) depende de cada projeto e das preferências pessoais. Podemos utilizar as informações sobre cada *workflow*, e decidir qual é mais adequado para cada projeto. Existem quatro maneiras
principais de trabalhar em colaboração com o git e o GitLab:
-**Centralized workflow**: recomendado para projetos pequenos, e/ou que
não necessitam de muitas alterações. Nesse workflow, o repositório possui
apenas um brach (`master`) e as alterações são feitas nesse branch. As
revisões só poderão ser realizadas depois que tudo foi enviado para o
servidor remoto. Com isso, há uma grande chance de ocorrerem conflitos.
-**Feature branch workflow**: recomendado para projetos pequenos e grandes
que envolvam mais de um colaborador. O projeto principal é mantido no
branch master. Se um membro quiser realizar alguma alteração, deverá criar
um novo branch `feature`, e fazer as alterações nesse branch e sugerir um
`merge request`. Com isso, os demais colaboradores poderão revisar
as alterações sugeridas e discutir as modificações, até que uma pessoa
habilitada faça o merge desse branch `freature` para o branch `master`.
Dessa forma, evita-se os possíveis conflitos e garante que tais alterações
não causaram algum problema. Esse workflow é altamente recomendado por
ser simples de gerenciar, evitar grandes conflitos, e ser relativamente
fácil para usuários novos do git.
-**Gitflow workflow**: indicado para projetos maiores e/ou com um grande
número de colaboradores. Esse workflow envolve a criação de alguns branches
com funções específicas. Todo o desenvolvimento é realizado no branch
`develop`. Quando uma versão está pronta, ela é movida para o branch
`release`, onde é testada e finalmente incorporada ao ramo master,
que contém apenas versões finais (estáveis). É extremamente recomendado
esse workflow para desenvolvimento de softwares, porém exige de mais
familiaridade com o git. Permite, por exemplo, que os usuários de um
software, instalem tanto uma versão estável (do branch `master`) quanto
uma versão em desenvolvimento (do branch `develop`).
-**Forking workflow**: recomendado para projetos abertos, onde se espera
usuários externos façam contribuições. Esse workflow consiste de um repositório oficial, de onde os colaboradores fazem um `fork` desse repositório, e passam
a desenvolver o projeto de maneira independente. Assim, cada colaborador
poderá adotar o workflow de preferência, e não precisará ter acesso ao
repositório oficial, apenas colaborar enviando `merge`.
Independente da escolha do workflow para cada projeto é importante sempre
informar o método que está sendo utilizado para seus colaboradores,
para que eles possam seguir o mesmo padrão. Essas informações poderão ser
descritas em `README.md` ou no `CONTRIBUTING.md`.
### Esqueleto do tópico
-*Descrever os quatro principais tipos de workflow (Centralized workflow,
-*Descrever os quatro principais tipos de workflow (Centralized workflow,
Feature branch workflow, gitflow workflow e Forking workflow)*
Feature branch workflow, gitflow workflow e Forking workflow)*
...
@@ -170,4 +215,30 @@ Diego G. Pasqualin</a>
...
@@ -170,4 +215,30 @@ Diego G. Pasqualin</a>
## 3.Fluxo de trabalho PET no GitLab
## 3.Fluxo de trabalho PET no GitLab
O PET-Estatística UFPR possui um grupo no git para o desenvolvimento de
projetos. Um desses, é a apostila do git. Esse projeto teve como finalidade
melhorar o conhecimento sobre o Git, e documentar em forma de apostila
para outros usuários do git.
Para esse projeto, tivemos dois ramos:
-`devel`: recebeu as contribuições dos membros, e após avaliação,
a contribuição foi movida para o ramo `master`.
-`master`: recebeu a versão estável do projeto.
Esses ramos só receberam conteúdo provenientes de `merge` dos ramos de
demanda (*issue*)
Os membros criaram `issue` para adicionarem suas contribuições.
Por exemplo, para adicionar um capítulo sobre o uso do programa,
foi criado um ramo para isso, depois de adicionar as contribuições, foi
submetido esse ramo para o repositório remoto.
Após o `git push`, a próxima etapa é a requisição de `merge`. Com esse
`merge`, era feita as discussões a respeito da contribuição. Após da
certeza dessa contribuição, era movida para o ramo `master`.
