From c6322798037a57d15492335cfa2d8551ae65c85c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=82ngela=20Legey?= <angelalegey@gmail.com> Date: Thu, 5 Nov 2015 17:22:31 -0200 Subject: [PATCH] =?UTF-8?q?Adiciona=20ilustra=C3=A7=C3=B5es=20dos=20modelo?= =?UTF-8?q?s=20de=20workflow?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cap07.Rmd | 186 +++++++++++++++++++++++++++++++++++++++--------------- cap07.md | 186 +++++++++++++++++++++++++++++++++++++++--------------- 2 files changed, 270 insertions(+), 102 deletions(-) diff --git a/cap07.Rmd b/cap07.Rmd index 61aa847..0b79751 100644 --- a/cap07.Rmd +++ b/cap07.Rmd @@ -153,70 +153,148 @@ deixar de fora como você fez as modificações, pois o código alterado já deverá ser auto-explicativo. -### Esqueleto do tópico +## 2.Modelos de fluxos de trabalho -- Repositórios: nÃveis de acesso, adicionar colaboradores, configuração -inicial do repositório +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: -- Commits: convenções gerais especÃficas +- #### **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. -## 2.Modelos de fluxos de trabalho + **Exemplo** -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: + Após iniciar um repositório central, os colaboradores devem clonar + o repositório. + +  + + FIGURA: Colaboradores clonando o repositório central + + Depois de um colaborador terminar seu trabalho remotamente, ele + publica as modificações para o repositório central, para que os + demais membros possam ter acesso. + +  + + FIGURA: Colaborador publicando as modificações no repositório central -- **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`. + Outro membro também termina seu trabalho e resolve publicar no + repositório central, porém não irá conseguir. O repositório central + está diferente do seu repositório local. + +  + + FIGURA: Colaborador não conseguindo publicar as modificações no + repositório central + + Para conseguir enviar as modificações realizadas, o colaborador + precisa puxar as atualizações feitas para o seu repositório, + integrá-los com as suas alterações locais, e em seguida, tentar + novamente. + +  + + FIGURA: Colaborador puxando as modificações do repositório central + + Após feito isso, será possÃvel o colaborador fazer as modificações. + +  + + FIGURA: Colaborador publica modificações do repositório central + +- #### **Feature branch workflow**: +recomendado para projetos pequenos e grandes que envolvam mais de um +colaborador. O projeto principal é mantido nobranch 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`. + **Exemplo** + + Antes de começar a desenvolver um recurso, é preciso de criar um + ramo isolado para trabalhar + +  + + FIGURA: Criando um novo ramo para o trabalho -### Esqueleto do tópico -- *Descrever os quatro principais tipos de workflow (Centralized workflow, -Feature branch workflow, gitflow workflow e Forking workflow)* + Com isso, o membro poderá iniciar o seu trabalho, e realizar o que + for necessário nesse ramo (brach). Após finalizar o projeto, o colaborador + envia suas modificações, irá requirir um `merge request` para que + as alterações feitas nesse branch, sejam incorporadas no `master`. Os + demais membros, poderão avaliar se tais modificações são pertinentes + para o projeto. -- *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> +  + FIGURA: Colaborador solicita merge, e aguarda revisão dos demais + colaboradores + + Quando as alterações sugeridas para o colaborador forem incorporadas + o branch poderá ser movido para o `master`. + +  + + FIGURA: Movendo ramo para o master + +- #### **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`). + + **Exemplo** + + São criados branches com funções especÃficas, como no exemplo `Hotfix`, + `Release` e `Develop`. + +  + + FIGURA: Ilustração dos branches especÃficos + + *Develop* é semelhante ao master do feature branch workflow. *Release* + serve "lançar" possÃveis bugs gerados no código. *Hotfix* contém as + correções dos bugs do release que não podem aguardar o lançamento + do mesmo. + + +- #### **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`. + + **Exemplo** + + Criado o repositório central, os colaboradores fazem um `fork` + poderão trabalhar de maneira independente. + +  + + FIGURA: Ilustração dos forks de um projeto + + 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`. ## 3.Fluxo de trabalho PET no GitLab @@ -245,5 +323,11 @@ Após o `git push`, a próxima etapa é a requisição de `merge`. Com esse 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 +### Referências +https://git-scm.com/book/pt-br/v1/Git-Distribu%C3%ADdo-Contribuindo-Para-Um-Projeto + +https://prezi.com/_lm8kozmii8n/git-workflow/ + +https://www.atlassian.com/zh/git/workflows\#!workflow-overview + +http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md diff --git a/cap07.md b/cap07.md index 9e4027b..c79b711 100644 --- a/cap07.md +++ b/cap07.md @@ -148,70 +148,148 @@ deixar de fora como você fez as modificações, pois o código alterado já deverá ser auto-explicativo. -### Esqueleto do tópico +## 2.Modelos de fluxos de trabalho -- Repositórios: nÃveis de acesso, adicionar colaboradores, configuração -inicial do repositório +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: -- Commits: convenções gerais especÃficas +- #### **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. -## 2.Modelos de fluxos de trabalho + **Exemplo** -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: + Após iniciar um repositório central, os colaboradores devem clonar + o repositório. + +  + + FIGURA: Colaboradores clonando o repositório central + + Depois de um colaborador terminar seu trabalho remotamente, ele + publica as modificações para o repositório central, para que os + demais membros possam ter acesso. + +  + + FIGURA: Colaborador publicando as modificações no repositório central -- **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`. + Outro membro também termina seu trabalho e resolve publicar no + repositório central, porém não irá conseguir. O repositório central + está diferente do seu repositório local. + +  + + FIGURA: Colaborador não conseguindo publicar as modificações no + repositório central + + Para conseguir enviar as modificações realizadas, o colaborador + precisa puxar as atualizações feitas para o seu repositório, + integrá-los com as suas alterações locais, e em seguida, tentar + novamente. + +  + + FIGURA: Colaborador puxando as modificações do repositório central + + Após feito isso, será possÃvel o colaborador fazer as modificações. + +  + + FIGURA: Colaborador publica modificações do repositório central + +- #### **Feature branch workflow**: +recomendado para projetos pequenos e grandes que envolvam mais de um +colaborador. O projeto principal é mantido nobranch 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`. + **Exemplo** + + Antes de começar a desenvolver um recurso, é preciso de criar um + ramo isolado para trabalhar + +  + + FIGURA: Criando um novo ramo para o trabalho -### Esqueleto do tópico -- *Descrever os quatro principais tipos de workflow (Centralized workflow, -Feature branch workflow, gitflow workflow e Forking workflow)* + Com isso, o membro poderá iniciar o seu trabalho, e realizar o que + for necessário nesse ramo (brach). Após finalizar o projeto, o colaborador + envia suas modificações, irá requirir um `merge request` para que + as alterações feitas nesse branch, sejam incorporadas no `master`. Os + demais membros, poderão avaliar se tais modificações são pertinentes + para o projeto. -- *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> +  + FIGURA: Colaborador solicita merge, e aguarda revisão dos demais + colaboradores + + Quando as alterações sugeridas para o colaborador forem incorporadas + o branch poderá ser movido para o `master`. + +  + + FIGURA: Movendo ramo para o master + +- #### **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`). + + **Exemplo** + + São criados branches com funções especÃficas, como no exemplo `Hotfix`, + `Release` e `Develop`. + +  + + FIGURA: Ilustração dos branches especÃficos + + *Develop* é semelhante ao master do feature branch workflow. *Release* + serve "lançar" possÃveis bugs gerados no código. *Hotfix* contém as + correções dos bugs do release que não podem aguardar o lançamento + do mesmo. + + +- #### **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`. + + **Exemplo** + + Criado o repositório central, os colaboradores fazem um `fork` + poderão trabalhar de maneira independente. + +  + + FIGURA: Ilustração dos forks de um projeto + + 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`. ## 3.Fluxo de trabalho PET no GitLab @@ -240,5 +318,11 @@ Após o `git push`, a próxima etapa é a requisição de `merge`. Com esse certeza dessa contribuição, era movida para o ramo `master`. -### Esqueleto do tópico -- *Funcionamento da elaboração da apostila* +### Referências +https://git-scm.com/book/pt-br/v1/Git-Distribu%C3%ADdo-Contribuindo-Para-Um-Projeto + +https://prezi.com/_lm8kozmii8n/git-workflow/ + +https://www.atlassian.com/zh/git/workflows\#!workflow-overview + +http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md -- GitLab