Faz um tempo que pretendo migrar os projetos da empresa do SVN para o Git.
O modelo distribuído, velocidade nas operações, branches leves e merges (sem conflitos) automatizados são as vantagens óbvias.
Fiz alguns testes em projetos pequenos em 2010 mas o plugin do eclipse na época era impraticável. E a equipe não se adaptou muito bem na linha de comando. Principalmente na hora do diff tool que teria que fazer por fora do eclipse.
O que me motivou (ou obrigou) a tentar de novo foi o Attlassian On Demand migrar a hospedagem do código para o Git. E daqui alguns meses se quisermos continuar no ótimo On Demand seremos obrigados a migrar para o Git.
Instalei o Eclipse Juno (4.2) e agora parece que o EGit está estável suficiente e fui tentar migrar um projeto bem pequeno como piloto do Git.
Primeiro tentei um modelo parecido com o SVN:
As duas pessoas envolvidas trabalharam na branch master (ligada na remota).
Cada commit ja fazia push pro repositório remoto central (o plugin agora tem um botão “commit and push”)
Cada programador antes de commitar (e push) faz um Team > Synchronize no projeto, que basicamente é um “git fetch” mostrando as alterações. Com isso o programador pode ver se tem coisas pra baixar… caso esteja tudo certo, faz o Team > Pull e depois commit (e push).
Os problemas dessa abordagem:
não é possível dar push se eu não estiver 100% sincronizado com a branch remota (ter dado pull antes)
ser obrigado dar pull antes vai te obrigar a usar uma versão que talvez o programador não queria usar - algumas vezes só precisamos baixar um único arquivo de um outro programador pra continuar nosso trabalho, mas não queremos ainda baixar tudo.
esse modelo de todos trabalhando na branch remota gera mais conflitos
Ok. De fato é ruim esse modelo.
A segunda opção foi cada programador ter sua própria branch (algo como “desenvolvimento” originada da master local).
Cada programador faz commits locais (e se desejar push na sua branch remota) e de tempos em tempos ou quando precisar envia as alterações para a branch master remota.
Os problemas dessa abordagem:
o processo fica muito burocrático para uma coisa simples. Por exemplo:
O programador “A” precisa de uma única alteração do programador “B”. O programador B então faz:
a) commit na branch local
b) checkout para a master local
c) merge com squash (sem commit automático na master local)
d) commit local só do arquivo desejado
e) push
f) checkout de volta na sua branch local de desenvolvimento
O programador “A” para baixar esta única alteração faz:
a) checkout na master
b) pull (pode acabar pegando mais alterações de outros programadores)
c) checkout na branch local
d) merge com a master local (sem commit automático das possíveis outras alterações não desejada no momento)
e) commit local só das alterações que quis baixar do repo remoto
são 6 passos do programador “A” e 5 do programador “B”. 11 no total… achei muito. Além disso pode sobrar uns arquivos no estado de stage.
Comparando com SVN:
Programador B:
a) commit só do arquivo necessário
Programador A:
a) update só do arquivo necessário
Existe algum modelo de usar git sem aumentar e muito a burocracia para coisas simples?
Sim, basta você parar de tentar colocar um processo numa atividade intelectual e deixar os desenvolvedores trabalhar. Libere eles para escolherem os seus próprios melhores fluxos de trabalho.
BTW, a pessoa não é obrigada a usar o EGit, há softwares especializados que são melhores e com mais opções, como o TortoiseGit e o SourceTree. Não precisa usar somente o Eclipse para desenvolver tudo.
[quote=Bruno Laturner][quote=dbdbdb] Existe algum modelo de usar git sem aumentar e muito a burocracia para coisas simples?
[/quote]
Sim, basta você parar de tentar colocar um processo numa atividade intelectual e deixar os desenvolvedores trabalhar. Libere eles para escolherem os seus próprios melhores fluxos de trabalho.
BTW, a pessoa não é obrigada a usar o EGit, há softwares especializados que são melhores e com mais opções, como o TortoiseGit e o SourceTree. Não precisa usar somente o Eclipse para desenvolver tudo.[/quote]
boa idéia, um benefício desse modelo é que reduziria conflitos porque os “fluxos de trabalho” de cada um seriam diferentes.
Cara, entendo seu ponto de vista e já fi muito isso, mas esqueça isso pra sua vida. Podem haver Ns razões para que você precise fazer isso, mas nenhuma delas será benéfica para o futuro do seu software.
Perceba que, se alguma coisa está madura o suficiente para estar na master, essa coisa deve ser totalmente confiável de ser baixada por todos os desenvolvedores antes de iniciar o turno de trabalho.
Integração contínua prevê isso e embora seja um pouco difícil de se adaptar no início, vai melhorar o fluxo de trabalho de sua equipe em 100% em um futuro próximo.
Qualquer trabalho pela metade, não vai pra master, vai pra uma branch separada de desenvolvimento, que só deve ser integrada com a master, quando estiver “100%” (e aqui é desenv + testes).
Enfim, não estou com a verdade absoluta e você pode estar em um ambiente caótico, todavia, se não der pra mudar o fluxo de trabalho, não mude também de ferramenta, pois a filosofia é outra, no mais, só vejo vantagens em mudar um pouco a estrutura das coisas, pois embora haja a resistência no início, só haverão benefícios no longo prazo.
Aqui onde trabalho costumamos fazer duas coisas. Um é que cada branch é criado com base no ID da tarefa no Jira. A vantagem disso é que você cria branchs menores. Branchs pequenos dão menos problemas com merge.
A outra coisa que usamos são os scripts de workflow. São alguns shell scripts que fazem algumas coisas básicas. Eu costumo usar três, o hack, o ship e o branch.
Esse script serve para atualizar o branch com o master. Como você pode ver, ele vai para o master, faz um pull, volta para o branch que tava e faz um rebase com o master. Com isso você pegou tudo o que estava no master e levou para o seu branch.
O intuito desse script é jogar o conteúdo do branch atual no master. Ele vai para o master, faz um merge com o branch, faz um push no master e depois volta para o branch.
Por último temos o branch.sh:
#!/bin/sh -x
git checkout master
git pull origin master
git checkout -b $1
Esse script servre pra criar branchs. Na verdade é um script bem preguiçoso. Ele vai pro master, faz um pull , cria o branch e troca para o mesmo.
Você pode escrever outros scripts que ajudem a automatizar certos fluxos. Acho isso bem produtivo.
O ambiente SVN aqui é um pouco caótico sim… por isso a minha vontade de reorganizar… e nessa reorganização aproveitar e migrar de ferramenta.
concordo que para o código ir para o master, é pq já está completo e estável o suficiente.
o difícil vai ser mudar a cultura do fluxo de trabalho. depois disso mudar de ferramente vai ser tranquilo
gostei da ideia de uma branch por ID do jira!
no caso com uma pendência mais trabalhosa, com sub-pendencias no jira, e o trabalho ser compartilhado com mais de um programador? vcs colocam esta branch no repositório remoto e cada desenvolvedor faz outra branch partindo dessa pendência pai?
gostei da ideia de uma branch por ID do jira!
no caso com uma pendência mais trabalhosa, com sub-pendencias no jira, e o trabalho ser compartilhado com mais de um programador? vcs colocam esta branch no repositório remoto e cada desenvolvedor faz outra branch partindo dessa pendência pai?
obrigado!
abraços[/quote]
A gente costuma criar um branch com o id da tarefa pai. Se for preciso compartilhar com mais de um programador, vocês devem subir o branch para o remoto. O único cuidado que deve haver é que o branch seja atualizado constamente com o remoto. Se um programador A fez uma alteração, sobe logo essa alteração pro remoto e o programador B já faz logo um pull e pega essa alteração. Isso evita problemas com conflito.
