Como aproveitar as vantagens do Git sem o trabalho extra que ele impõe?

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.

Qual o problema com a linha de comando galera?

Bruno Laturner:

dbdbdb:

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.

boa idéia, um benefício desse modelo é que reduziria conflitos porque os “fluxos de trabalho” de cada um seriam diferentes.

pra mim problema nenhum… mas nem todos da equipe ve com naturalidade e tem uma certa resistencia

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.

Abs [] e sucesso na mudnça.

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.

#!/bin/sh -x
# git name-rev is fail
CURRENT=`git branch | grep '\*' | awk '{print $2}'`
git checkout master
git pull origin master
git checkout ${CURRENT}
git rebase master

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.

#!/bin/sh -x
# git name-rev is fail
CURRENT=`git branch | grep '\*' | awk '{print $2}'`
git checkout master
git merge ${CURRENT}
git push origin master
git checkout ${CURRENT}

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.

#!/bin/sh -x
git checkout master
git pull origin master
git checkout -b $1

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

obrigado!
abraços

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

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

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.

dbdbdb:

pra mim problema nenhum… mas nem todos da equipe ve com naturalidade e tem uma certa resistencia

Entendo. Neste caso uma ferramenta pode ajudar na hora de lidar com conflitos que surgem na hora do merge sim.