Continuando a sequência de artigos sobre como tornar a linha de desenvolvimento do Git mais amigável, este documento apresenta informações sobre como coser um nó final de branch na linha do tempo de desenvolvimento, reintegrando-o.
Índice
- Alfaiate Git: Branches
- Alfaiate Git: Merges
Merges
Swicegood (2008) define merge como capturar dois ou mais branches e combinar suas histórias numa só. Sink (2011) complementa que a convergência de branches é feita através de merges, tornando a operação simples, automatizando-a.
Basicamente, a reintegração de uma história divergente à linha de tempo principal é efetuada através de um merge, onde o nó final desta deve ser cosido de forma que a linha permaneça coerente.
A figura acima apresenta a estrutura de exemplo criada no artigo anterior, possuindo três branches que devem ser reintegrados: issue-1, issue-2 e issue-3. Nota-se, ainda, que todos os branches possuem o mesmo nó base, apontado pelo branch master.
Reintegrando Nós
A partir da estrutura anterior, deve-se integrar os branches issue-3, issue-1 e issue-2, nesta ordem, no branch develop, exemplificando assim, a ação de merges em branches divergentes. Para tanto, os seguintes comandos devem ser executados.
$ git checkout develop
$ git merge --no-ff issue-3
$ git merge --no-ff issue-1
$ git merge --no-ff issue-2
O parâmetro --no-ff (no fast forward, sem avanço rápido, em tradução livre), é utilizado para criar um nó adicional na linha do tempo, facilitando buscas posteriores para o ponto exato onde determinado branch foi reintegrado, informando, assim, que naquele ponto, aplicou-se um merge.
Observa-se o avanço na linha do tempo do branch develop, onde este recebe as alterações pertinentes aos branches reintegrados. Ainda, cada merge contém uma mensagem, adicionada automaticamente pelo Git, informando que o nó foi incluído a partir de um merge de determinado branch.
Costura Impecável
As linhas de nós secundários foram, portanto, cosidas na linha do tempo de desenvolvimento. Dessa maneira, sabe-se quais os branches foram costurados em determinada linha, devido à nomenclatura de branches com números de issues e à mensagem padrão adicionada pelo Git durante o merge.
Todos os branches saem do mesmo ponto e entram sequencialmente no branch develop. O branch master não deve ser utilizado diretamente, pois representa a versão estável do sistema, sendo sincronizado com o branch develop somente durante a publicação de novas versões.
Histórico
O comando abaixo apresenta a ordem com que os nós foram criados e reintegrados no branch develop, apresentando os nós adicionais sequencialmente.
$ git log --oneline
0394c22 Merge branch 'issue-2' into develop
8a5798f Merge branch 'issue-1' into develop
c3ba031 Merge branch 'issue-3' into develop
86175fc Fecha documento
3eb7c60 Adiciona conteúdo de teste
3c90a79 Começa um novo documento
d10490d Inclui novos conteúdos
7794b88 Adiciona a primeira linha
c287efc Adiciona conteúdo de exemplo
bdf5275 Inicializa o repositório
O próximo artigo explicará como sincronizar o branch principal master com o branch de desenvolvimento develop, criando uma nova versão no repositório através de tags.
Referências
- SWICEGOOD, T. Pragmatic Version Control Using Git. Pragmatic Bookshelf (2008).
- SINK, E. Version Control by Example. Pyrenean Gold Press (2011).