GIT Branching – Source Code Management

GIT Branching – Source Code Management

   11:24       Keep Linux World

---

Fala Galera !
Demorou um tempo para fazermos esse "overview" de branching, que provavelmente está errado, mas saiu !
Acredito que este artigo dê para termos uma noção básica de como é o fluxo do git com um modelo de branches que apliquei em alguns projetos que participei. Este modelo se mostrou muito eficiente e ágil, mesmo que com muitas branches.

Por que Git ?

Simplesmente por ser mais aderido no mercado e proporcionar esta  utilização de branches de forma simples e rápida. Não estou tentando "puxar sardinha" (de onde veio esse bordão ?) para o GIT, simplesmente ele é mais aceito. 

Para qualquer dúvida ou "treta" veja alguns sites de comparação entre git e outras ferramentas de versionamento de código aqui por exemplo.

Os antigos (eu no caso) tinham um certo "receio" de utilizar Git, o lema era o seguinte: 

"Cuidado com os conflitos de merge, eles vão dar xabu !"

 Mas conforme você vai deixando a "cabeça dura" de lado, percebe que a simplicidade do Git é algo à se dar valor.
Originalmente, eu "nasci" dev, (literalmente mesmo, meu pai era programador de Clipper e DBASE) mas com o tempo sai da área e me tornei sysadmin, de todas as ferramentas que já experienciei, o Git foi uma das que revolucionou a agilidade e segurança do meu trabalho.
Pra galera que gosta de indicações, seguem uns sites com livros interessantes:
Pro Git -> Free para leitura online
Pragmatic Version Control Using Git

Branching

O ato de separarmos nossos códigos em branches no GIT se deve ao fato de segregarmos a natureza do código, como por exemplo, a branch hotfix é utilizada para corrigir bugs em produção na branch master e replicar as correções para a branch develop.

    • Feature
    • Develop
    • Release
    • Hotfix
    • Master

TAGs

    • Gera tags para definir até onde vai a versão 1, 2…. na branch master, release e hotfix    • Se aplica às branches: master, hotfixes, release    • Define versões, releases na timeline do código    • Facilita a identificação do código e rollback de versões

Main Branches

A principais branches dentro do Git são: a branch develop e master.

Algumas empresas praticam o caos e utilizam somente a branch master, todos comitam e corrigem e testam na branch master, dá medo, mas funciona. Quem somos nós para criticar se esta ação resolve o problema da empresa não é ?!

• Cada Merge/Pull Request da branch develop para a master significa 1 nova release/versão no modelo de apenas duas branches
• Este modelo é destinado à projetos pequenos e sem muito controle de versões
• Aceita no máximo 3 dev’s trabalhando na branch develop diretamente.

Explicando o Git, a branch master nós consideramos como sendo a branch principal, origin/master, onde o código da HEAD reflete a master com sempre o código como estando em "production ready state".

A branch origin/develop nós consideramos sendo uma fork(clone) da branch master, onde é a branch principal de desenvolvimento, a HEAD reflete sempre o código com as features mais atuais e correções no código do desenvolvimento do projeto para a próxima release.

Algumas pessoas chamam este tipo de branch de "branch integradora", é nesta branch onde as builds "nightly" são geradas. 

Quando o código da branch develop atinge um nível de estabilidade/meta é necessário aplicar as alterações na branch master (Pull/Merge Request) para que seja gerada uma nova versão do software (TAG). Neste momento, a branch develop continua existindo, e tudo o que foi trabalhado até o momento também, a diferença é que a branch master se torna mais próxima do desenvolvimento atual e estável, enquanto isto, a branch develop continua recebendo commits dos desenvolvedores com novas features para uma próxima versão.

Branches de Suporte (BUFFA DRUIDA !)

Aliado às branches principais, nosso modelo de desenvolvimento utiliza de algumas branches de suporte, que auxiliam no desenvolvimento paralelo entre os membros dos times, melhoram na rastreabilidade dos commits que compõem uma feature e ajudam na rápida manutenção em código que está em produção (sabe aquela velha "batida de água", onde seu gerente fica em cima pra você resolver ? Pois é, essas branches podem te ajudar.).
Uma característica destas branches é que elas podem ser deletadas após atingirem sua proposta.
As branches de suporte, basicamente são:

• Feature branches
• Release branches
• Hotfix branches

Feature Branches

As feature branches são branches derivadas da branch develop, onde realmente são desenvolvidas features novas para serem inseridas no código da branch develop. O desenvolvedor realiza commit diretamente nesta branch, e esta branch, ao final da programação da feature nova, sofre um merge/pull request para a branch develop (preferencialmente com a opção --no-ff) e deixa de existir logo em seguida. (Com a opção --no-ff o grupo de commits que compõem a feature são agrupados e então, não se perde o histórico de commits desta feature).

• Devem ser derivadas da branch:
• develop
• Deve realizar merge de volta na branch:
• develop
• Nomes desta branch na literatura:
• Qualquer coisa exceto: 
• master, develop, release-*, or hotfix-*

Geralmente estas branches não existem no repositório origin/, elas vão existir geralmente em repositórios do tipo feature/ mesmo ou em algum repositório do próprio desenvolvedor.

Merging Feature Branches

git merge --no-ff

• Desabilita Fast-Foward Merging    • Evita perder histórico dos commits que compõem a feature
• Transforma o grupo de commits na feature branch em 1 única “ feature” dentro da branch develop
• Mais fácil de realizar um rollback através do “git history”

Criando uma Feature Branch 

Quando houver uma nova feature/funcionalidade no software, crie uma feature branch derivada de origin/develop.

# Trocando de branch para a branch "myfeature"
# caso não exista, o comando cria automaticamente
$ git checkout -b myfeature develop

Incorporando uma feature branch na branch develop

Features finalizadas devem sofrer merge para origin/develop para que a feature possa ser testada e seguir o fluxo das branches:

# Trocando de branch ativa para a branch "develop"
$ git checkout develop
$ git merge --no-ff myfeature
Updating ex2b36a..06f4474
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 06f4474).
$ git push origin develop

Release Branches

As branches release são branches que são utilizadas para homologar e passar por testes finais (Q&A) antes de se tornar uma versão dentro da branch master enquanto a branch develop pode continuar seguindo seu curso natural após a branch release ter sido derivada para atingir uma nova versão caso aprovada.Quaisquer ajustes realizados nesta branch, devem ser replicados para as branches develop e consequentemente, master.

• Pode derivar da branch:
• develop
• Deve efetuar merge nas branches:
• develop
• master
• Nomes da branch na literatura:
• release-*

Criando uma Release Branch

As branches release são derivadas da branch develop, vamos supor que temos a versão em produção número 1.1.5 e vamos ter uma nova versão com correções e novas funcionalidades. A branch develop já está próxima do ideal para o release da nova versão, digamos que vamos atualizar para a versão 1.2 (nem versão 1.1.6 e nem 2.0 devido ao grande número de correções existentes), então nós criamos uma derivação da branch develop e nomeamos a branch nova levando em consideração a nova versão. No exemplo abaixo, iremos apenas trocar o arquivo que define a versão do software, supondo que a equipe de Q&A já deu o OK para o deploy.

# Trocando de branch ativa para a branch "release-1.2"
$ git checkout -b release-1.2 develop
 Switched to a new branch "release-1.2"
$ ./troca_ver.sh 1.2
 Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Trocada versão para 1.2"
 [release-1.2 32c4451] Trocada versão para 1.2
 1 files changed, 1 insertions(+), 1 deletions(-)

Esta branch continuará a existir por um tempo até que a versão seja aplicada de fato e esteja em produção.

Adicionar novas funcionalidades nesta branch é estritamente proibido, caso tenham alguma, adicionem na branch feature->develop e as funcionalidades terão de aguardar uma nova release.

Finalizando uma Release Branch

Quando a branch release está pronta para se tornar uma versão de produção, ela precisa sofrer um merge para a branch master e chegar ao seu fim. 

Adicionalmente, é necessário colocar uma TAG na branch master para facilitar a identificação de releases historicamente e rollbacks. Além das TAGs, é necessário realizar um merge dos bugs corrigidos na branch develop para que as novas versões tenham as correções aplicadas nesta release.

# Trocando de branch ativa para a branch "master"
$ 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

Pronto ! A release está feita e com tag.

Para assinatura da tag com criptografia, você talvez queira utiliza -s ou -u  

Para mantermos as correções que foram realizadas na branch release, precisamos adicioná-las na branch develop

# Trocando de branch ativa para a branch "develop"
$ git checkout develop
 Switched to branch 'develop'
$ git merge --no-ff release-1.2
 Merge made by recursive.
 (Summary of changes)

Muito possivelmente este procedimento irá gerar conflitos de merge, resolva-os e realize o merge nvoamente.

 Após realizadas as correções e merge's, basta deletar a releasse branch.

# Excluindo branch 'release-1.2'
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix branches 

As branches do tipo hotfix são destinadas à correção de bugs quando o código já está em produção.Geralmente estas branches são derivadas da branch master, corrigindo o bug e realizando merge nas branchs master e develop para replicar a correção. Lembrando que a branch master, quando recebe um merge, o deploy automático no ambiente de produção deve ocorrer.

Adicionalmente, ao se ter um bug corrigido e realizado o merge na branch master, é necessário criar uma TAG com uma nova versão de correção, conforme exemplo da imagem abaixo.

Quando uma branch release existir, será necessário realizar um merge na branch release também, além da branch develop e master.     • Pode derivar da branch:        ◦ master    • Deve efetuar merge nas branches:        ◦ develop E master     • Nomes da branch na literatura:        ◦ hotfix-*

Galera, por hoje é só.
Vlw !