Modelo de branches no GitLab - Histórico de revisão

Daniel.alves em 20h28min de 2 de junho de 2016

2016-06-02T20:28:00Z

Daniel.alves em 16h26min de 1 de junho de 2016

2016-06-01T16:26:20Z

Daniel.alves: /* Finalizando um hotfix branch */

2016-06-01T14:28:37Z

‎Finalizando um hotfix branch

Daniel.alves: /* Os branches de suporte */

2016-06-01T14:28:16Z

‎Os branches de suporte

Daniel.alves: /* Incorporando uma feature concluída no develop branch */

2016-05-31T21:07:20Z

‎Incorporando uma feature concluída no develop branch

Daniel.alves: /* Incorporando uma feature concluída no branch develop */

2016-05-31T21:06:40Z

‎Incorporando uma feature concluída no branch develop

Daniel.alves em 20h58min de 31 de maio de 2016

2016-05-31T20:58:01Z

Daniel.alves em 20h57min de 31 de maio de 2016

2016-05-31T20:57:04Z

Daniel.alves em 19h28min de 31 de maio de 2016

2016-05-31T19:28:32Z

Daniel.alves em 17h57min de 31 de maio de 2016

2016-05-31T17:57:46Z

@@ Linha 1: / Linha 1: @@
 [[Arquivo:Git-model.png|thumb]]
 O git mudou a forma com a qual os desenvolvedores pensam a respeito de merges e ''branches''. No mundo de código centralizado, merges e ''branches'' sempre foram considerados assustadores (cuidados com os conflitos do merge) e algo que era feito apenas uma vez em um longo tempo.
 Porém com o git essas ações são extremamente baratas e simples, e são consideradas o cerne do dia-a-dia de trabalho, de verdade. Como uma consequência de sua simplicidade e natureza repetitiva, criar ''branches'' e merges não é algo que se deva ter medo. As ferramentas de versionamento dispõem de toda a assistência necessária para realizar as tarefas de criação de ''branches'' e merges.
@@ Linha 5: / Linha 6: @@
 Após essa breve introdução sobre a ferramenta, vamos entrar de cabeça no modelo de desenvolvimento. O modelo aqui apresentado é essencialmente nada mais que um conjunto de procedimentos que cada membro da equipe tem que seguir a fim de chegar a um processo de desenvolvimento de software gerenciado.
 == Descentralizado, mas centralizado ==

← Edição anterior		Edição das 16h26min de 1 de junho de 2016
Linha 1:		Linha 1:
		+	[[Arquivo:Git-model.png\|thumb]]
	O git mudou a forma com a qual os desenvolvedores pensam a respeito de merges e ''branches''. No mundo de código centralizado, merges e ''branches'' sempre foram considerados assustadores (cuidados com os conflitos do merge) e algo que era feito apenas uma vez em um longo tempo.		O git mudou a forma com a qual os desenvolvedores pensam a respeito de merges e ''branches''. No mundo de código centralizado, merges e ''branches'' sempre foram considerados assustadores (cuidados com os conflitos do merge) e algo que era feito apenas uma vez em um longo tempo.
	Porém com o git essas ações são extremamente baratas e simples, e são consideradas o cerne do dia-a-dia de trabalho, de verdade. Como uma consequência de sua simplicidade e natureza repetitiva, criar ''branches'' e merges não é algo que se deva ter medo. As ferramentas de versionamento dispõem de toda a assistência necessária para realizar as tarefas de criação de ''branches'' e merges.		Porém com o git essas ações são extremamente baratas e simples, e são consideradas o cerne do dia-a-dia de trabalho, de verdade. Como uma consequência de sua simplicidade e natureza repetitiva, criar ''branches'' e merges não é algo que se deva ter medo. As ferramentas de versionamento dispõem de toda a assistência necessária para realizar as tarefas de criação de ''branches'' e merges.

@@ Linha 196: / Linha 196: @@
 (Summary of changes)
 </pre>
-Existe uma exceção a esta regra que é '''quando um ''release branch'' ainda existir as alterações realizadas no ''hotfix branch'' precisam ser ''merged'' no ''release branch'' ao invés do ''develop''. Ao efetuar o ''merge'' do ''bugfix'' no ''release branch'' pode causar eventualmente um ''merge'' do ''bugfix'' no ''develop'' também, quando o ''release branch'' for concluído.
+Existe uma exceção a esta regra que é '''quando um ''release branch'' ainda existir as alterações realizadas no ''hotfix branch'' precisam ser ''merged'' no ''release branch'' ao invés do ''develop'''''. Ao efetuar o ''merge'' do ''bugfix'' no ''release branch'' pode causar eventualmente um ''merge'' do ''bugfix'' no ''develop'' também, quando o ''release branch'' for concluído.
 Finalmente, remova o ''branch'' temporário:

@@ Linha 31: / Linha 31: @@
 * ''Feature branches''
 * ''Release branches''
 Cada um desses ramos têm um propósito específico e estão vinculados a regras restritas sobre quais ''branches'' podem ser seu ''branch'' de origem e quais ''branches'' devem ser considerados seu destino para receber o seu conteúdo por ''merge''.
@@ Linha 141: / Linha 142: @@
 $ git branch -d release-1.2
 Deleted branch release-1.2 (was ff452fe).
 </pre>

@@ Linha 70: / Linha 70: @@
 </pre>
-A flag <code> --no-ff </code> faz com que o processo de ''merge'' sempre crie um novo ''commit object'', mesmo que o ''merge'' pudesse ser feito no modelo ''fast-forward''. Isso evita a perda de informações sobre a existência histórica de um ''feature branch' e agrupa todos os ''commits'' que, juntos, criam a nova ''feature''. Compare:
+A flag <code> --no-ff </code> faz com que o processo de ''merge'' sempre crie um novo ''commit object'', mesmo que o ''merge'' pudesse ser feito no modelo ''fast-forward''. Isso evita a perda de informações sobre a existência histórica de um ''feature branch'' e agrupa todos os ''commits'' que, juntos, criam a nova ''feature''. Compare:
 [[Arquivo:Merge-feature-develop.png|100px]]

@@ Linha 56: / Linha 56: @@
 </pre>
-=====Incorporando uma ''feature'' concluída no ''branch develop''=====
+=====Incorporando uma ''feature'' concluída no ''develop branch''=====
 ''Features'' finalizadas devem ter seu ''merge'' realizado no ''branch develop'' para definitivamente serem incorporadas na próxima versão de ''release''.

@@ Linha 35: / Linha 35: @@
 De nenhuma maneira estes ''branches'' são considerados especiais do ponto de vista técnico. Os seus tipos são classificados pela forma como os mesmos são utilizados.
-===='''''Feature branches'''''====
+====''Feature branches''====
 [[Arquivo:Featurebranch-develop.png|thumb|100px]]
 * Pode ser um ''branch'' a partir de:
@@ Linha 91: / Linha 91: @@
 É exatamente no início de um ''release branch'' que é atribuído um número de versão, não antes disso. Até aquele momento, o ''delelop branch'' reflete as mudanças para a "próxima ''release''", mas não está claro se essa "próxima ''release''" acabará por se tornar 0.3 ou 1.0, até que o ''release branch'' seja iniciado. Essa decisão é feita no início do ''release branch'' e é realizado de acordo com regras definidas no projeto.
-====Criando um ''release branch''====
+=====Criando um ''release branch''=====
 ''Release branches'' são criados a partir do ''develop branch''. Por exemplo, digamos que a versão 1.1.5 é a versão de produção atual e temos um grande lançamento chegando. O estado do ''develop'' está pronto para o "próximo ''release''" e foi decidido que esta vai se tornar a versão 1.2 (em vez de 1.1.6 ou 2.0). Assim, removemos o ''branch'' e damos ao ''release branch'' um nome que reflita o número da versão:
@@ Linha 108: / Linha 108: @@
 Este novo ''branch'' pode existir lá por um tempo, até que a ''release'' seja implementada definitivamente. Durante esse tempo, correções de bugs podem ser aplicadas neste ''branch'' (ao invés do ''developer branch''). '''Adicionar grandes novas características aqui é estritamente proibido'''. Essas novas características devem ter ''merges'' no ''develop'' e, portanto, esperar pelo próximo grande ''release''.
-====Concluindo o ''release branch''====
+=====Concluindo o ''release branch''=====
 Quando o estado do ''release branch'' está pronto para se tornar um ''release'' real, algumas ações precisam ser realizadas. Em primeiro lugar, o ''release branch'' deve ter ''merge'' realizado no ''master'' (uma vez que cada ''commit'' no ''master'' é um novo lançamento por definição, lembre-se disso). Em seguida, o ''commit'' no ''master'' deve ser marcado para uma futura referência à esta versão histórica. Finalmente, as alterações feitas no ''release branch'' precisam ser ''merged'' de volta para o ''develop'', para que os futuros lançamentos também contênham estas correções de bugs.

← Edição anterior		Edição das 20h57min de 31 de maio de 2016
Linha 92:		Linha 92:

	====Criando um ''release branch''====		====Criando um ''release branch''====
		+	''Release branches'' são criados a partir do ''develop branch''. Por exemplo, digamos que a versão 1.1.5 é a versão de produção atual e temos um grande lançamento chegando. O estado do ''develop'' está pronto para o "próximo ''release''" e foi decidido que esta vai se tornar a versão 1.2 (em vez de 1.1.6 ou 2.0). Assim, removemos o ''branch'' e damos ao ''release branch'' um nome que reflita o número da versão:
		+
		+	<pre>
		+	$ git checkout -b release-1.2 develop
		+	Switched to a new branch "release-1.2"
		+	$ ./bump-version.sh 1.2
		+	Files modified successfully, version bumped to 1.2.
		+	$ git commit -a -m "Bumped version number to 1.2"
		+	[release-1.2 74d9424] Bumped version number to 1.2
		+	1 files changed, 1 insertions(+), 1 deletions(-)
		+	</pre>
		+
		+	Depois de criar um novo ''branch'' e mudar para ele, realiza-se um ''bump'' no número da versão. Aqui, ''bump-version.sh'' é um ''shell script'' fictício que muda alguns arquivos na cópia para refletir a nova versão (isto pode ser, obviamente, uma mudança manual). Em seguida, é realizado o ''commit'' do número da versão.
		+
		+	Este novo ''branch'' pode existir lá por um tempo, até que a ''release'' seja implementada definitivamente. Durante esse tempo, correções de bugs podem ser aplicadas neste ''branch'' (ao invés do ''developer branch''). '''Adicionar grandes novas características aqui é estritamente proibido'''. Essas novas características devem ter ''merges'' no ''develop'' e, portanto, esperar pelo próximo grande ''release''.
		+
		+	====Concluindo o ''release branch''====
		+	Quando o estado do ''release branch'' está pronto para se tornar um ''release'' real, algumas ações precisam ser realizadas. Em primeiro lugar, o ''release branch'' deve ter ''merge'' realizado no ''master'' (uma vez que cada ''commit'' no ''master'' é um novo lançamento por definição, lembre-se disso). Em seguida, o ''commit'' no ''master'' deve ser marcado para uma futura referência à esta versão histórica. Finalmente, as alterações feitas no ''release branch'' precisam ser ''merged'' de volta para o ''develop'', para que os futuros lançamentos também contênham estas correções de bugs.
		+
		+	As duas primeiras etapas em git:
		+
		+	<pre>
		+	$ git checkout master
		+	Switched to branch 'master'
		+	$ git merge --no-ff release-1.2
		+	Merge made by recursive.
		+	(Summary of changes)
		+	$ git tag -a 1.2
		+	</pre>
		+
		+
		+	O ''release'' agora está pronto e marcado para futuras referências.
		+	:Obs.: Você pode usar a opção -s ou -u <chave> para assinar com criptografia.
		+
		+	Para manter as alterações feitas no ''release branch'', precisamos realizar o ''merge'' de volta para o ''developer''. No git:
		+	<pre>
		+	$ git checkout develop
		+	Switched to branch 'develop'
		+	$ git merge --no-ff release-1.2
		+	Merge made by recursive.
		+	(Summary of changes)
		+	</pre>
		+
		+	Este passo pode muito bem levar a um conflito de ''merge'' (uma vez que mudaram o número da versão). Se assim for, corrija e submeta (''commit'').
		+
		+	Agora que está tudo pronto o ''release branch'' pode ser removido, uma vez que não é mais necessário:
		+	<pre>
		+	$ git branch -d release-1.2
		+	Deleted branch release-1.2 (was ff452fe).
		+	</pre>

@@ Linha 56: / Linha 56: @@
 </pre>
-=====Incorporando uma ''feature'' concluída no ''develop''=====
+=====Incorporando uma ''feature'' concluída no ''branch develop''=====
 ''Features'' finalizadas devem ter seu ''merge'' realizado no ''branch develop'' para definitivamente serem incorporadas na próxima versão de ''release''.
@@ Linha 76: / Linha 76: @@
 No caso da direita, é impossível ver o histórico de ''commits objects'' que juntos implementaram a nova ''feature'', você teria que manualmente ler todas as mensagens de ''commits''. Neste caso, reverter a implementação de uma "feature" (grupo de ''commits'') é uma verdadeira dor de cabeça, contudo, torna-se muito simples quando a ''flag'' <code> --no-ff </code> é usada.
 Sim, isto vai criar alguns ''commits objects'' vazios, mas o ganho é muito superior a este detalhe.

@@ Linha 6: / Linha 6: @@
 == Descentralizado, mas centralizado ==
 O modelo de repositório utilizado para o gerenciamento de ''branches'' considera que temos apenas um único, e verdadeiro, repositório central. Note que este repositório é apenas considerado central (pois como o git é uma ferramenta de controle descentralizado, não existe um repositório central a nível técnico). Vamos nos referir a este repositório principal como '''origin''', pois é um nome familiar a todos os usuários do git.
-Cada desenvolvedor efetua ''pull'' e ''pushes'' no ''origin''. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também efetuar um ''pull'' das modificações realizadas por outros desenvolvedores de outras equipes. Por exemplo, isto pode ser útil quando um ou mais desenvolvedores estão trabalhando em uma nova grande funcionalidade, antes de enviar as alterações em progresso diretamente para o repositório ''origin'' prematuramente. Na figura acima, existem equipes de Alice e Bob, Alice e David, e Clair e David.
+Cada desenvolvedor efetua ''pull'' e ''pushes'' no ''origin''. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também efetuar um ''pull'' das modificações realizadas por outros desenvolvedores de outras equipes. Por exemplo, isto pode ser útil quando um ou mais desenvolvedores estão trabalhando em uma nova grande funcionalidade, antes de enviar as alterações em progresso diretamente para o repositório ''origin'' prematuramente. Na figura ao lado, existem equipes de Alice e Bob, Alice e David, e Clair e David.
 Tecnicamente isto significa nada mais que Alice definiu um ''git remote'' (chamado bob) apontando para o repositório da equipe de Bob, e vice-versa.
 == O ''branch'' principal ==
@@ Linha 34: / Linha 36: @@
 ===='''''Feature branches'''''====
 * Pode ser um ''branch'' a partir de:
 ** ''developer''
@@ Linha 47: / Linha 50: @@
 =====Criando um ''feature branch''=====
 Quando começar a trabalhar em uma nova ''feature'', ramifica-se à partir do ''develop bracnh:''
-<code>
 $ git checkout -b myfeature develop
 Switched to a new branch "myfeature"
-</code>
+</pre>