Integração da equipe de Devs com o Git

Prévia do material em texto

Integração da equipe de Devs com o 
Git
Apresentação
O trabalho em equipe no desenvolvimento de aplicações é uma realidade cada vez mais presente 
no mundo corporativo, mesmo em cenários em que o profissional trabalha remotamente. É muito 
comum que o profissional seja responsável por parte de um código, uma função, uma tela, um 
microsserviço ou um módulo. Nesse cenário de colaboração, é necessário dominar as boas 
práticas de trabalho com o Git, para diminuir as chances de conflito, e saber como lidar com os 
conflitos que podem ocorrer quando seu trabalho se juntar ao de outros profissionais.
Nesta Unidade de Aprendizagem, você vai aprender a trabalhar em equipe com o Git, fazendo uso 
de um fluxo de trabalho adotado amplamente por equipes no mundo todo: o Gitflow. Também vai 
aprender como o código-fonte que está desenvolvendo será versionado, além de lidar com 
situações de conflito ao juntar seu código ao de outros desenvolvedores.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Identificar a estratégia de organização do versionamento do código-fonte por meio do 
Gitflow.
•
Ilustrar o método de trabalho conjunto de uma equipe com o versionamento de código-fonte. •
Demonstrar a resolução de conflitos de versionamento.•
Desafio
O Gitflow foi proposto por Vincent Driessen em 2010 como uma estratégia de ramificação e um 
modelo de versionamento de projetos e tem sido amplamente adotado por equipes de usam o Git. 
A imagem a seguir resume a estratégia de ramificação do Gitflow:
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para 
acessar.
A adoção do padrão proposto pelo Gitflow visa à melhora da qualidade do trabalho de codificação, 
mas não isenta um desenvolvedor dos conflitos de versionamento.
Imagine que você trabalha em uma equipe de desenvolvedores de sistemas juntamente com outros 
dois desenvolvedores, DEV_A e DEV_B. Juntos, vocês fazem parte de uma equipe internacional de 
desenvolvedores.
Neste momento, vocês estão trabalhando em uma nova implementação, chamada feature-15. Cada 
desenvolvedor de sua equipe é responsável por codificar sua parte em seu repositório local do Git, 
seguindo o padrão do Gitflow.
O desenvolvedor DEV_B parece estar com problemas em sua tarefa, e você precisa ajudá-lo.
Observe as instruções que o desenvolvedor DEV_B está executando:
https://statics-marketplace.plataforma.grupoa.education/sagah/5cfa6573-14ad-4e62-8d40-05aeb0d6794b/f843f2ea-9872-47a7-a032-0f9fccb4c1fc.png
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/5cfa6573-14ad-4e62-8d40-05aeb0d6794b/a9b30f22-5ee7-437a-bc95-20fcf7cbb8a2.png
Com base nas saídas dos comandos emitidos pelo desenvolvedor DEV_B:
a) identifique qual cuidado ele poderia ter tomado para evitar esse conflito;
b) proponha uma solução para ajudá-lo a resolver esse conflito de versionamento.
Infográfico
O trabalho de um desenvolvedor é parte essencial no fluxo de produção de um software. O 
Gitflow conduzirá as etapas de versionamento para garantir a colaboração entre as equipes 
envolvidas no processo de produção.
Acompanhe, no Infográfico, a estratégia de ramificação do Gitflow.
Conteúdo interativo disponível na plataforma de ensino!
Conteúdo do Livro
O trabalho de desenvolvimento e versionamento de código é facilitado com o uso do sistema de 
controle de versionamento distribuído Git. Seu modelo de controle de versionamento incentiva o 
trabalho em equipe, mas não oferece um fluxo que organize o trabalho cooperativo dos 
desenvolvedores. A estratégia de ramificação e o modelo de gerenciamento de versão do Gitflow 
apresentam um modelo de trabalho produtivo para equipes de desenvolvedores, estejam eles no 
mesmo departamento ou em continentes diferentes.
No capítulo Integração da equipe de Devs com o Git, da obra DevOps, base teórica desta Unidade 
de Aprendizagem, você vai compreender como adotar o Gitflow em seus projetos.
Boa leitura.
DEVOPS
Renê de Ávila Mendes
Integração da equipe 
de Devs com o Git
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar a estratégia de organização do versionamento do código-
-fonte por meio do Gitflow.
 � Ilustrar o método de trabalho conjunto de uma equipe com o versio-
namento de código-fonte.
 � Demonstrar a resolução de conflitos de versionamento.
Introdução
A realidade de trabalho de um desenvolvedor de software requer cons-
tante cooperação, seja com profissionais de infraestrutura e de projeto, 
seja com seus pares de desenvolvimento. São comuns as situações em 
que um desenvolvedor é contratado para atuar em uma equipe que está 
fisicamente separada, exigindo desse profissional que seu código-fonte 
se encaixe perfeitamente ao dos demais desenvolvedores, como se todos 
estivessem trabalhando lado a lado.
Neste capítulo, você verá como organizar a estrutura de versiona-
mento do código-fonte de uma aplicação. Além disso, verá como uma 
equipe de trabalho pode atuar nessa estrutura. Por fim, conhecerá os 
principais problemas que podem ocorrer no versionamento de código-
-fonte quando se trabalha em equipe. 
1 Gitflow: organizando o versionamento de 
código-fonte
O desenvolvimento de um software, de um website ou mesmo de uma aplicação 
para smartphones é uma atividade complexa, pois envolve pessoas, tecnologias 
e processos. Ao mesmo tempo que cria oportunidades para o surgimento de 
novos sistemas e aplicativos, o avanço da ciência computacional aumenta a 
variedade de linguagens e de tecnologias envolvidas no desenvolvimento 
desses sistemas.
Metodologias de desenvolvimento de software começaram a surgir na 
década de 1960 para estruturar o desenvolvimento de software, organizando 
a formação do time de desenvolvimento, o planejamento e a execução da 
fase de desenvolvimento, bem como a organização da comunicação entre os 
desenvolvedores e com os times externos. Dependendo da metodologia apli-
cada no desenvolvimento de um software, a quantidade e os nomes das etapas 
podem variar, mas ainda assim seguirão uma sequência lógica e organizada. 
Em um contexto de desenvolvimento de aplicações, é provável se deparar com 
nomes como metodologia em cascata, metodologia de prototipação, desenvol-
vimento rápido, DSDM (dynamic system development model; ou metodologia 
de desenvolvimento de sistemas dinâmicos, em português), metodologia ágil, 
modelo em espiral, XP (extreme programming; ou programação extrema, em 
português), RUP (rational unified process; ou processe unificado rational), 
Scrum, Lean, entre outros (WAZLAWICK, 2013). 
No entanto, em todas as metodologias, é comum a preocupação com o 
desenvolvimento e a integração do código-fonte, gerado por equipes que podem 
estar em um mesmo departamento ou até mesmo em continentes diferentes. 
A metodologia de desenvolvimento de software adotada organiza o que será 
desenvolvido e quando será desenvolvido. Mas como desenvolver uma apli-
cação em equipe sem que seu trabalho sobreponha o do seu par, cumprindo 
os prazos e os objetivos da entrega?
O sistema de controle de versionamento distribuído Git fornece recursos 
tecnológicos que permitem a codificação e o versionamento por equipes; 
no entanto, por si só, ele não garante a organização do trabalho dessas equipes. 
Assim, faz-se necessário um fluxo de trabalho simples, bem estabelecido e que 
seja facilmente compreendido pela equipe de desenvolvimento. Além disso, 
esse fluxo deve atender às demandas por integração contínua, presentes nas 
práticas DevOps (MUNIZ et al., 2020). 
Integração da equipe de Devs com o Git2
Controlando versões no processo de 
integração contínua
O processo de integração contínua é fundamental na filosofia DevOps, e pode 
ser entendido como a prática de submeter pequenas peças de código para o uso 
em produção. A ideia da integração contínua é parte dametodologia de de-
senvolvimento XP, proposta inicialmente por Kent Beck (COPELAND, 2001).
 No processo de integração contínua, os códigos desenvolvidos individual e 
localmente por cada desenvolvedor são testados automaticamente e validados 
antes de serem disponibilizados para o uso. Esse processo de integração requer 
liberações de código com frequências diárias, a fim de evitar grandes pacotes 
de atualização que causem maiores impactos na aplicação e que requeiram 
uma grande janela de tempo para a sua implantação em produção. 
Segundo Muniz et al. (2020), existem três conceitos principais do processo 
de integração de versões:
 � Linha principal, trunk ou master: local onde ficará armazenado o 
código principal da aplicação, a ser posteriormente disponibilizado 
para produção.
 � Ramificação (branching): os ramos (branchs) são as cópias do trunk 
em um determinado momento, os quais permitem que linhas indepen-
dentes de desenvolvimento sejam mantidas e, posteriormente, fundidas 
(merging) com a linha principal.
 � Marcação (tagging): o estado de um código deve ser identificado por 
uma marca (tag), que geralmente identifica a versão do código. Por 
exemplo: a tag v1.1.14.
A Figura 1, a seguir, ilustra o controle de versionamento de um código.
Ao concluir um desenvolvimento realizado em um ramo (branch), um de-
senvolvedor precisará integrá-lo ao restante do código. Esse processo consiste 
na sincronização das modificações realizadas em um determinado ramo com 
o código fonte do ramo principal. Essa ação é chamada de fusão, integração 
ou merge, e é muito comum em projetos com muitos branches. 
A complexidade do processo de merge dependerá, entre outras variáveis, 
do tempo que o código não está sendo integrado ao ramo principal. A quanti-
dade de alterações sendo simultaneamente desenvolvidas, em ramos distintos, 
aumentará a complexidade do processo de merge, com a ocorrência de conflitos 
de versionamento e a possibilidade da introdução de bugs (MUNIZ et al., 2020). 
3Integração da equipe de Devs com o Git
Figura 1. Controle de versionamento, com destaque para master, branches e tag. 
Fonte: Adaptada de Muniz et al. (2020). 
Últimos ajustesmaster
novo-branch
hot�x/1.0.1 1.0.1
1.0.0
Continuação desenvolvimento...
Tentando resolver problema 1.0.1
Melhorias para a próxima versão
Primeira versão para reprodução
Primeiro commit
Bug 1.0.0 �nalmente resolvido
Commit de um novo branch em paralelo
O modelo Gitflow
Para responder ao questionamento de como desenvolver em equipe com o 
Git, Driessen (2010) apresentou uma estratégia de ramificação (branching) 
e um modelo de gerenciamento de versão, chamado posteriormente de Gitflow, 
amplamente adotado por equipes locais ou distribuídas. O Gitflow baseia-
-se nos conceitos de repositório, ramificação (branching) e fusão (merging) 
apresentados no Git (CHACON; STRAUB, 2014), definindo uma convenção 
para nomes de ramos (branchs) e estabelecendo regras para a ramificação e a 
fusão entre eles. O Quadro 1, a seguir, apresenta os tipos de ramos e as regras 
definidas no Gitflow.
Integração da equipe de Devs com o Git4
Ra
m
os
 
m
a
s
t
e
r
h
o
t
f
i
x
r
e
l
e
a
s
e
d
e
v
e
l
o
p
f
e
a
t
u
r
e
Em
 q
ua
l r
ep
os
itó
-
rio
 e
st
á
or
ig
in
 (c
en
tr
al
)
 lo
ca
l
or
ig
in
 (c
en
tr
al
)
or
ig
in
 (c
en
tr
al
)
Lo
ca
l
O
 q
ue
 c
on
té
m
O
 q
ue
 e
st
á 
em
 
pr
od
uç
ão
. T
am
-
bé
m
 c
on
he
ci
do
 
po
r t
ro
nc
o 
(tr
un
k)
Co
rr
eç
ão
 d
e 
um
 b
ug
 
cr
íti
co
, q
ue
 n
ão
 p
od
e 
es
pe
ra
r p
el
a 
pr
óx
im
a 
re
le
as
e
O
 q
ue
 ir
á 
pa
ra
 
pr
od
uç
ão
O
 q
ue
 ir
á 
pa
ra
 a
 
pr
óx
im
a 
re
le
as
e
U
m
a 
no
va
 
im
pl
em
en
ta
çã
o,
 p
ar
a 
a 
pr
óx
im
a 
ou
 p
ar
a 
um
a 
re
le
as
e 
fu
tu
ra
Pa
dr
ão
 d
e 
no
m
e
–
h
o
t
f
i
x
-
*
r
e
l
e
a
s
e
-
*
–
Li
vr
e,
 e
xc
et
o 
m
a
s
t
e
r
, d
e
v
e
l
o
p
, 
r
e
l
e
a
s
e
-
*
, 
h
o
t
f
i
x
-
*
Te
m
po
 d
e 
vi
da
In
fin
ito
At
é 
qu
e 
es
te
ja
 p
ro
nt
o 
pa
ra
 s
er
 li
be
ra
do
 p
ar
a 
pr
od
uç
ão
At
é 
qu
e 
es
te
ja
 p
ro
nt
o 
pa
ra
 s
er
 li
be
ra
do
 p
ar
a 
pr
od
uç
ão
In
fin
ito
En
qu
an
to
 e
st
iv
er
 e
m
 
de
se
nv
ol
vi
m
en
to
Po
de
 s
e 
ra
m
ifi
ca
r 
do
 ra
m
o
– 
m
a
s
t
e
r
d
e
v
e
l
o
p
m
a
s
t
e
r
d
e
v
e
l
o
p
Q
ua
dr
o 
1.
 T
ip
os
 d
e 
ra
m
os
 e
 re
gr
as
 e
st
ab
el
ec
id
as
 n
o 
G
itf
lo
w
(C
on
tin
ua
)
5Integração da equipe de Devs com o Git
Fo
nt
e:
 A
da
pt
ad
o 
de
 D
rie
ss
en
 (2
01
0)
.
Ra
m
os
 
m
a
s
t
e
r
h
o
t
f
i
x
r
e
l
e
a
s
e
d
e
v
e
l
o
p
f
e
a
t
u
r
e
Po
de
 s
er
 fu
nd
id
o 
co
m
 o
 ra
m
o
–
m
a
s
t
e
r
, d
e
v
e
l
o
p
 e
 
r
e
l
e
a
s
e
m
a
s
t
e
r
 e
 d
e
v
e
l
o
p
f
e
a
t
u
r
e
, 
d
e
v
e
l
o
p
 e
 
r
e
l
e
a
s
e
d
e
v
e
l
o
p
Ex
em
pl
o 
de
 ta
g
1.1
.14
1.1
.15
1.
2
–
–
O
bs
er
va
çã
o
Ca
da
 fu
sã
o 
ge
ra
rá
 
um
a 
no
va
 v
er
sã
o
D
ev
e 
se
r f
un
di
do
 p
rim
ei
ro
 
co
m
 m
a
s
t
e
r
 e
, e
nt
ão
, 
co
m
 d
e
v
e
l
o
p
D
ev
e 
se
r f
un
di
do
 
pr
im
ei
ro
 c
om
 
m
a
s
t
e
r
 e
, e
nt
ão
, c
om
 
d
e
v
e
l
o
p
–
U
m
 ra
m
o 
pa
ra
 c
ad
a 
no
va
 im
pl
em
en
ta
çã
o 
(fe
at
ur
e)
Q
ua
dr
o 
1.
 T
ip
os
 d
e 
ra
m
os
 e
 re
gr
as
 e
st
ab
el
ec
id
as
 n
o 
G
itf
lo
w
(C
on
tin
ua
çã
o)
Integração da equipe de Devs com o Git6
2 Trabalhando em equipe: versionando 
o código-fonte
Após conhecer os tipos de ramos e as regras que limitam o seu uso, pode-se 
pensar em como o desenvolvimento do código-fonte se organiza no Gitflow. 
Os tipos de ramos apresentados no Quadro 1 não são diferentes ou especiais, 
mas se diferenciam pela forma como são utilizados. A seguir, cada tipo de 
ramo é apresentado em mais detalhes.
Ramos fundamentais
No padrão Gitflow, os ramos fundamentais são apenas dois: master e de-
velop. O ramo master existe apenas no repositório central, identificado 
por origin (consulte o comando git remote, na documentação do Git), 
e sempre conterá o código-fonte que foi liberado para uso em produção. 
A versão disponível no ramo master é necessariamente identificada por uma 
tag, que define em qual versão (release) o código-fonte está. Por exemplo, 
a release do código-fonte do ramo master pode ser 1.1.14. Sempre que o 
ramo master for fundido com mudanças que vierem dos ramos release 
ou hotfix, a sua versão necessariamente deverá ser alterada. Por exemplo, 
a versão do ramo master é alterada para 1.1.15 ao receber um hotfix, ao passo 
que é alterada para 1.2 ao receber a release identificada por release-1.2.
O ramo develop, por sua vez, é criado inicialmente como um ramo 
(branch) do ramo master, e receberá daí em diante os códigos-fonte dos 
desenvolvimentos e as correções dos bugs que forem produzidos nos ramos 
feature. Todas as implementações e correções de bug que estiverem no 
ramo develop farão parte da próxima release a ser liberada para produção.
O ramo develop é limpo após o seu conteúdo ser liberado para o ramo 
release, e não receberá códigos-fonte dos ramos feature até que o conte-
údo do ramo release seja liberado para produção, isto é, seja fundido com o 
ramo master. É importante ressaltar que, antes de começar a receber as novas 
implementações e correções de bug, o ramo develop deve receber (merge) 
o conteúdo do ramo release, para que as implementações que acabaram 
de ser liberadas para produção se reflitam nos próximos desenvolvimentos e 
correções de bug (DRIESSEN, 2010).
7Integração da equipe de Devs com o Git
Para adotar o Gitflow, comece pela criação do ramo develop, a partir do ramo 
master, no repositório origin:
$ git checkout -b develop master
Switched to a new branch 'develop'
Ramo feature
É um tipo de ramo criado a partir do ramo develop, com a finalidade especí-
fica de receber o desenvolvimento de uma nova funcionalidade para o software 
ou aplicação, a ser incorporadaà próxima versão (release) específica, ou a uma 
versão futura. Esse tipo de ramo é utilizado também para o desenvolvimento 
de correções de erros (bugs) previamente documentados, cuja liberação para 
produção possa ocorrer em uma release futura (DRIESSEN, 2010).
Uma característica que diferencia o ramo feature dos demais é o fato 
de que podem existir diversos ramos desse tipo simultaneamente, um para 
cada nova funcionalidade ou para cada bug a ser corrigido. Cada ramo recebe 
o código-fonte sendo produzido por um desenvolvedor ou por uma equipe de 
desenvolvedores. O nome do ramo deve seguir um padrão de nomenclatura 
que identifique unicamente a funcionalidade ou bug, e jamais pode receber 
o nome dos ramos fundamentais (master e develop) ou adotar o nome 
de uma release ou de um hotfix. Por exemplo, um ramo (branch) do tipo 
feature pode ter o nome feature-7, ao passo que outro ramo pode se 
chamar bug-10.
Se uma equipe de desenvolvedores trabalhar na mesma funcionalidade ou no mesmo 
bug, os desenvolvedores devem configurar seu Git para apontar para o repositório de 
seus pares, a fim de acompanhar o desenvolvimento. 
Integração da equipe de Devs com o Git8
Um ramo do tipo feature durará enquanto a funcionalidade ou correção 
de bug estiver em desenvolvimento, sendo excluído após ser fundido com o 
ramo develop ou se for rejeitado por ser reprovado em testes (DRIESSEN, 
2010).
Ramo release
Assim como os ramos do tipo feature, os ramos do tipo release são 
criados a partir do ramo develop, mas com finalidade e efeitos diferentes. 
Ao contrário de um ramo feature, um ramo release é um tipo de ramo 
utilizado especificamente para preparar uma nova versão da aplicação ou do 
software a ser liberada para produção (DRIESSEN, 2010).
Quando um ramo do tipo release é criado, ele recebe uma tag que 
identifica a sua versão (release). No momento de criação desse ramo, 
o ramo develop deve ser limpo, para que não receba novas funcionalidades. 
As funcionalidades ou correções de bug que ainda estejam em desenvolvimento 
e que não fazem parte do ramo release atual devem aguardar a liberação 
do ramo develop.
O ramo release é identificado pelo padrão release-*, em que o * 
corresponde à sua versão, a mesma atribuída pela tag. Por exemplo, um ramo 
do tipo release pode ser criado com o nome release-1.2 e receber a 
tag v1.2. O ramo release é excluído após ser fundido aos ramos master 
e develop, para que futuros desenvolvimentos incluam o que já foi liberado 
para produção.
Ramo hotfix
Criado exclusivamente a partir do ramo master, esse tipo de ramo não é 
planejado, pois é criado para conter código-fonte de correção de um bug crítico 
do software que está em produção. Um bug crítico em produção não pode 
esperar a liberação de um novo release, pois requer ação de correção imediata.
De maneira semelhante a um ramo do tipo feature, mais de um ramo 
de hotfix pode ser criado simultaneamente, cada um para conter códigos-
-fonte em desenvolvimento para a correção de um bug crítico específico. Para 
diferenciar entre os ramos do tipo hotfix, adota-se o padrão de nomenclatura 
hotfix-*, identificando unicamente o hotfix. Por exemplo, um ramo hotfix 
pode se chamar hotfix-05.
9Integração da equipe de Devs com o Git
O ramo hotfix é excluído após ser fundido (merge) aos ramos master 
e develop, para garantir que a correção esteja também na próxima release 
(DRIESSEN, 2010).
Quando um ramo release é fundido ao ramo master, um novo commit é gerado 
no ramo master, e uma tag de versão é atribuída a ele:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.1
Merge made by the 'recursive' strategy.
 arquivo3.c | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 arquivo3.c
$ git tag -a v1.1 -m "Versao v1.1"
3 Trabalhando em equipe: resolvendo conflitos
O desenvolvedor deverá adotar alguns cuidados ao trabalhar em equipe, 
os quais, quando respeitados, diminuirão a chance de problemas com seus pares 
de desenvolvimento. Como boas práticas de versionamento, o desenvolvedor 
deve (CHACON; STRAUB, 2014):
 � Garantir que suas submissões não contenham erros de espaço em branco 
(trailing whitespace). Esses erros ocorrem quando o código-fonte contém 
linhas compostas apenas de espaços em branco, ou quando a indentação 
de uma linha contém um espaço em branco antes de um caractere TAB. 
Assim, deve-se utilizar o comando git diff --check antes de 
um comando commit para identificar a presença de erros de espaço 
em branco.
Integração da equipe de Devs com o Git10
 � Garantir que cada commit contenha uma unidade logicamente separá-
vel, isto é, contenha apenas uma nova funcionalidade ou apenas uma 
correção de bug.
 � Adotar o hábito de incluir mensagens de qualidade para um commit. 
Recomenda-se que a mensagem inicie com uma linha de, no máximo, 
50 caracteres que descreva a implementação de maneira concisa, 
seguida por uma linha em branco e, então, por um texto mais completo 
sobre a implementação. Nesse texto, deve-se incluir a motivação para o 
desenvolvimento e descrever em que essa implementação se diferencia 
da anterior.
A adoção de boas práticas de versionamento melhora o relacionamento entre 
os desenvolvedores e aumenta a qualidade do trabalho, mas não os poupa dos 
conflitos de versionamento. Esse tipo de conflito ocorrerá frequentemente ao 
se submeter um objeto a um repositório compartilhado (origin ou repositório 
do par) ou ao se fundir (merge) um desenvolvimento a um ramo.
Fowler (2006) já apontava para a ocorrência de conflitos de versão de 
código-fonte ao apresentar seus princípios de integração contínua. O autor não 
somente cita a possibilidade desses conflitos, mas também delineia o método 
a ser utilizado no Git em caso de conflitos:
Com uma boa compilação, posso pensar em confirmar minhas alterações no 
repositório. A reviravolta, é claro, é que outras pessoas podem, e geralmente 
fizeram, alterações na linha principal antes que eu tenha chance de confir-
mar. Então, primeiro atualizo minha cópia de trabalho com as alterações e 
reconstruo. Se as alterações deles colidirem com as minhas alterações, ele 
se manifestará como uma falha na compilação ou nos testes. Nesse caso, 
é minha responsabilidade corrigir isso e repetir até que eu possa criar uma 
cópia de trabalho que esteja sincronizada corretamente com a linha principal. 
(FOWLER, 2006, documento on-line).
Para ilustrar o procedimento básico de resolução de conflitos de versio-
namento, confira, a seguir, a adaptação de um dos cenários propostos por 
Chacon e Straub (2014).
11Integração da equipe de Devs com o Git
Exemplo 1
Nesse cenário, dois desenvolvedores, DEV_A e DEV_B, trabalharão separada-
mente no desenvolvimento de uma nova implementação, seguindo o padrão do 
Gitflow. Essa nova implementação requererá a inclusão de dois novos arquivos 
e receberá o nome de feature-15. Cada arquivo dessa implementação será 
codificado por um desenvolvedor em seu repositório local do Git. Observe que, 
inicialmente, cada desenvolvedor clonará para a sua máquina (DEV_A_LOCAL 
e DEV_B_LOCAL) o repositório central (REPOSITORIO): 
DEV _ A -------------------------------------
$ git clone REPOSITORIO DEV _ A _ LOCAL
Cloning into 'DEV _ A _ LOCAL'...
done.
DEV _ B -------------------------------------
$ git clone REPOSITORIO DEV _ B _ LOCAL
Cloning into 'DEV _ B _ LOCAL'...
done.
Ao clonar o repositório central, o ramo develop também foi clonado, 
incluindo todos os arquivos que faziam parte desse ramo no momento do clone. 
Os arquivos que foram clonados do ramo develop do repositório central 
devem existir também no ramo develop do repositório local do desenvolve-
dor, para que ele possa codificar e testar a sua parte da nova funcionalidade. 
No próximo passo, o desenvolvedor A (DEV_A) criará um novo ramo a 
partir do ramo local develop, para, então, codificar a sua parte da nova 
implementação, que consistirá no arquivo arquivo2.c. Confira esses passos 
a seguir:$ git branch feature-15
$ git checkout feature-15
Switched to branch 'feature-15'
$ vi arquivo2.c
$ git add arquivo2.c
warning: LF will be replaced by CRLF in arquivo2.c.
Integração da equipe de Devs com o Git12
The file will have its original line endings in your working 
directory
$ git commit -a -m "feature-15 - adiciona arquivo2.c"
[feature-15 c87847f] feature-15 - adiciona arquivo2.c
 1 file changed, 1 insertion(+) create mode 100644 arquivo2.c
Observe que, após criar a sua parte da nova implementação, o desenvolvedor 
A (DEV_A) adiciona o novo arquivo ao Git (git add) e cria um novo commit. 
Da mesma forma, o desenvolvedor B (DEV_B) trabalhará em sua parte da 
implementação, criando um arquivo com seu código-fonte (arquivo3.c). 
Para isso, o desenvolvedor criará um ramo a partir do ramo develop do seu 
repositório local e, então, criará e adicionará (git add) o novo arquivo ao 
repositório Git. Confira esses passos a seguir:
$ git branch feature-15
$ git checkout feature-15
Switched to branch 'feature-15'
$ vi arquivo3.c
$ git add arquivo3.c
warning: LF will be replaced by CRLF in arquivo3.c.
The file will have its original line endings in your working 
directory
$ git commit -a -m "feature-15 - adiciona arquivo3.c"
[feature-15 aa12e87] feature-15 - adiciona arquivo3.c
 1 file changed, 1 insertion(+)
 create mode 100644 arquivo3.c
$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
$ git merge feature-15
Updating 845cfd9..aa12e87
Fast-forward
13Integração da equipe de Devs com o Git
 arquivo3.c | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arquivo3.c
$ git push origin develop
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 333 bytes | 333.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To /REPOSITORIO
 845cfd9..aa12e87 develop -> develop
Observe que, após fazer o commit do que foi desenvolvido, o desenvolve-
dor B faz o check out para o ramo develop local e funde (merge) o ramo 
feature-15 ao ramo develop. Então, a sua versão do ramo develop é 
movida (push) para o ramo develop do repositório central (representado pela 
conexão remota origin). Essa ação finaliza a atividade de desenvolvimento 
do desenvolvedor B.
Quando o desenvolvedor A considera o seu desenvolvimento concluído, 
ele segue os mesmos passos do desenvolvedor B: faz o check out para o ramo 
develop local e funde (merge) o ramo feature-15 ao ramo develop. 
Confira, a seguir, essa ação e observe atentamente o que ocorrerá ao tentar 
mover (push) o ramo develop para o repositório central:
$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
$ git merge feature-15
Updating 845cfd9..c87847f
Fast-forward
 arquivo2.c | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arquivo2.c
$ git push origin develop
To /REPOSITORIO
Integração da equipe de Devs com o Git14
 ! [rejected] develop -> develop (fetch first)
error: failed to push some refs to '/REPOSITORIO'
hint: Updates were rejected because the remote contains work 
that you do
hint: not have locally. This is usually caused by another re-
pository pushing
hint: to the same ref. You may want to first integrate the 
remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' 
for details.
Quando o desenvolvedor A tentou mover (push) o seu ramo develop para 
o repositório central, a sua ação foi rejeitada. Essa situação ocorreu porque o 
ramo develop do repositório central contém objetos que não foram encon-
trados no ramo develop do repositório local do desenvolvedor A (observe 
os hints apresentados abaixo do retorno de rejeição do push). 
Uma das ações que o desenvolvedor A pode tomar é baixar os objetos do 
ramo develop do repositório central que não estejam no ramo develop de 
seu repositório local. Uma vez que estejam em seu ramo develop local, os 
objetos novos devem ser analisados e, se não prejudicarem o arquivo produzido 
pelo desenvolvedor A, incorporados (merge) ao ramo develop local. Confira 
essas ações a seguir:
$ git fetch origin
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 313 bytes | 2.00 KiB/s, done.
From /REPOSITORIO
 845cfd9..aa12e87 develop -> origin/develop
$ git merge origin/develop
Merge made by the 'recursive' strategy.
 arquivo3.c | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arquivo3.c
15Integração da equipe de Devs com o Git
$ git push origin develop
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 522 bytes | 522.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
To /REPOSITORIO
 aa12e87..3c7cbb2 develop -> develop
Com essa ação, o desenvolvedor A pode considerar o seu trabalho concluído.
Fowler (2020) propõe uma série de padrões para grupos de desenvolvedores criarem 
ramos que possam ser melhor integrados e organizados.
Ao aprender a trabalhar com o Gitflow, a produzir e versionar corretamente 
o seu código-fonte e a lidar com os conflitos na publicação de código-fonte, se 
estará preparado para atender ao requisito de integração contínua do DevOps.
CHACON, S.; STRAUB, B. Pro Git: everything you need to know about git. 2nd. ed. New 
York: Apress, 2014.
COPELAND, L. Extreme programming. In: COMPUTERWORLD. [S. l.: s. n.], 2001. Disponível 
em: https://www.computerworld.com/article/2585634/extreme-programming.html. 
Acesso em: 11 ago. 2020.
DRIESSEN, V. A successful Git branching model. In: NVIE. [S. l.: s. n.], 2010. Disponível em: 
http://nvie.com/posts/a-successful-git-branching-model. Acesso em: 12 ago. 2020.
FOWLER, M. Continuous integration. In: MARTIN FOWLER. [S. l.: s. n.], 2006. Disponível em: 
https://martinfowler.com/articles/continuousIntegration.html. Acesso em: 12 ago. 2020.
Integração da equipe de Devs com o Git16
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
FOWLER, M. Patterns for Managing Source Code Branches. In: MARTIN FOWLER. [S. l.: 
s. n.], 2020. Disponível em: https://martinfowler.com/articles/branching-patterns.html. 
Acesso em: 12 ago. 2020.
MUNIZ, A. et al. Jornada DevOps: unindo cultura ágil, Lean e tecnologia para entregar 
software com qualidade. 2. ed. Rio de Janeiro: Brasport, 2020.
WAZLAWICK, R. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.
17Integração da equipe de Devs com o Git
Dica do Professor
O Git é um sistema distribuído de controle de versionamento muito aplicado por desenvolvedores 
do mundo todo. No entanto, sua aplicação vai além do desenvolvimento de código-fonte. Quando 
aliado à estratégia de ramificação do Gitflow e à presença mundial do Github, a gestão de 
versionamento pode ser aplicada a praticamente qualquer produção técnica.
Nesta Dica do Professor, veja um exemplo de como usar o potencial dessas ferramentas para 
controlar versionamentos de outros tipos de arquivos. 
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://fast.player.liquidplatform.com/pApiv2/embed/cee29914fad5b594d8f5918df1e801fd/60afa69263c0b3cf5ea8154a9d7ba446
Exercícios
1) O Gitflow apresenta uma estratégia deramificação (branching) e um modelo de 
gerenciamento de versão. 
Com relação à estratégia de ramificação do Gitflow, é correto afirmar que:
A) o ramo master do repositório central conterá as implementações que ainda serão testadas.
B) as correções de bugs críticos devem aguardar a liberação de uma nova release para seguirem 
para produção.
C) novas implementações e correções de bugs ainda em desenvolvimento estão no ramo 
develop.
D) o ramo feature não deve ser usado para correções de bugs não críticos.
E) mais de um ramo hotfix pode existir ao mesmo tempo.
2) O modelo de gerenciamento de versão no Gitflow propõe a duração da existência de cada 
ramo. 
Com relação à duração da existência dos ramos no Gitflow, é correto afirmar que:
A) o ramo feature é excluído após a implementação ou correção de bugs se fundir ao ramo 
develop.
B) o ramo develop é excluído quando seu conteúdo é liberado para o ramo release.
C) o ramo release é mantido para receber as implementações da próxima release.
D) o ramo master é o único que sempre existe.
E) o ramo hotfix deve ser mantido para o caso de haver uma correção no ramo master.
3) O modelo de gerenciamento de versão proposto no Gitflow é aplicado com o uso de 
instruções (comandos) do Git. 
Com relação ao modelo de gerenciamento de versão proposto no Gitflow e ao uso 
de instruções (comandos) Git na aplicação desse modelo, é correto afirmar que:
A) o comando git tag cria um novo ramo para uma nova release.
B) o comando git branch faz a fusão do ramo especificado no comando com o ramo do contexto 
atual.
C) um ramo do tipo feature é identificado por uma tag de versão.
D) em um modelo de trabalho em equipe, o repositório local do desenvolvedor armazena o ramo 
master central.
E) a versão do ramo master é alterada sempre que se funde com um ramo release ou hotfix.
4) Em um trabaho colaborativo com o Git, são comuns as ocorrências de conflitos de 
versionamento. 
A respeito dos conflitos de versionamento, é correto afirmar que:
A) boas práticas de versionamento evitam conflitos de versionamento.
B) os conflitos de versionamento ocorrem ao criar um novo ramo a partir do ramo master.
C) conflitos de versionamento podem ocorrer ao submeter um objeto a um repositório 
compartilhado.
D) a adoção do Gitflow elimina os conflitos de versionamento.
E) conflitos de versionamento podem ser corrigidos com a estratégia de ramificação proposta no 
Gitflow.
As instruções a seguir refletem a tentativa de um desenvolvedor de submeter seu 
desenvolvimento ao repositório central do Git:
5) 
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/f4622065-7ab1-47f1-8cf5-119675734bf7/73059bc5-b824-4cd4-8a97-742ac8a84fc1.png
Quanto a essas instruções, é correto afirmar que:
A) a instrução git checkout verificou as pendências antes de enviar as modificações para o 
repositório remoto origin.
B) o arquivo "arquivo2.c" não estava no ramo develop do repositório local.
C) a instrução git push origin develop trouxe os objetos divergentes para o ramo develop local.
D) o arquivo "arquivo3.c" não estava no ramo develop do repositório local.
E) a instrução git merge origin/develop foi necessária para fundir a origem ao ramo develop.
Na prática
Uma das vantagens de um sistema de controle de versionamento distribuído, como o Git, é permitir 
o trabalho em um repositório local sem a necessidade de se estar conectado a um repositório 
central. Adotando o Gitflow como estratégia de ramificação e modelo de gerenciamento de versão, 
um desenvolvedor pode manter um ramo develop em sua máquina e desenvolver códigos-fonte de 
implementações ou correções de bug.
No entanto, o trabalho colaborativo requer que, em algum momento, os códigos-fonte produzidos 
por diferentes desenvolvedores de uma mesma equipe sejam compartilhados entre eles. Ao 
compartilhar suas implementações e correções de bug, um desenvolvedor permitirá que outro 
desenvolvedor adicione uma nova funcionalidade a seu código ou mesmo descubra uma falha.
Veja, Na Prática, como esse compartilhamento ocorre.
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/9dc9bbce-5943-40f2-9426-18a73609591b/dcec5e84-711c-4de5-913d-d898b6c44edb.png
Saiba mais
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
Gerenciamento de configuração e mudança com Git + Eclipse
Acompanhe este minicurso sobre gerenciamento de configuração e mudança com Git e Eclipse, 
preparado por Jadson Santos e Amador Pahim, para saber como usar funcionalidades de gestão de 
versionamento do Git no Eclipse.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Git-flow na prática (tutorial)
Assista a este vídeo de Anderson Almeida, que mostra uma aplicação prática do uso do git-flow.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Cheatsheet do git-flow
Veja, neste cheatsheet, como usar as funções da extensão git-flow para o Git, que implementam o 
modelo de ramificação do Gitflow.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
http://publica.sagah.com.br/publicador/objects/attachment/1874900612/minicursogerenciamentodeconfiguracaoemudanca-iiiworkshopsinfoufrn.pdf?v=1155284929
https://www.youtube.com/embed/p1VAghNq-qg
https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html
Git, Gitflow, Github/GitLab explicados e aplicados
Acompanhe os passos de planejamento, projeto e implementação de uma aplicação seguindo 
práticas de DevOps.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://www.bdm.unb.br/bitstream/10483/21588/1/2018_LuanGuimaraesLacerda_tcc.pdf