diff --git a/cp_07.Rmd b/cp_07.Rmd index 9a8d68efe7c499525cdc30b901d7ae8e71fcc977..61aa847e67a1b7416f1b87b03d5652a1a8c68d8a 100644 --- a/cp_07.Rmd +++ b/cp_07.Rmd @@ -163,6 +163,51 @@ inicial do repositório ## 2.Modelos de fluxos de trabalho +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, Feature branch workflow, gitflow workflow e Forking workflow)* @@ -175,4 +220,30 @@ Diego G. Pasqualin</a> ## 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`. + + +### Esqueleto do tópico - *Funcionamento da elaboração da apostila* \ No newline at end of file diff --git a/cp_07.md b/cp_07.md index c40b66b190b56f9f01f77bb8d117a1e1584e452a..9e4027b4d7edff5afce9c380f81b076903226832 100644 --- a/cp_07.md +++ b/cp_07.md @@ -158,6 +158,51 @@ inicial do repositório ## 2.Modelos de fluxos de trabalho +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, Feature branch workflow, gitflow workflow e Forking workflow)* @@ -170,4 +215,30 @@ Diego G. Pasqualin</a> ## 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`. + + +### Esqueleto do tópico - *Funcionamento da elaboração da apostila*