@@ -153,71 +153,149 @@ 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
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.
- **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`.
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`).
**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
- **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`.
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.
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`.
### Esqueleto do tópico
- *Descrever os quatro principais tipos de workflow (Centralized workflow,
Feature branch workflow, gitflow workflow e Forking workflow)*
@@ -148,71 +148,149 @@ 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
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.
-**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`.
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`).
**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
-**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`.
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.
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`.
### Esqueleto do tópico
-*Descrever os quatro principais tipos de workflow (Centralized workflow,
Feature branch workflow, gitflow workflow e Forking workflow)*
