Muito inteligente para Git

A pior
parte do Git é o tutorial “Git-SVN Crash Course”, porque ele irá
convencer um novato de que eles entendem como o controle de fonte faz as
transferências de maneira sutil para o Git. Se você combinar isso com o fato de que a
maioria das pessoas inteligentes simplesmente se recusa a ler documentação e
irá apenas amassar as teclas do teclado até que ele pareça funcionar, isso
significa que as equipes que estiverem começando a usar o Git estão na estrada
dos tijolos amarelos de um mundo de dor.

O Git
segue a filosofia do Linux de recusar a se proteger contra ele mesmo. Bem
parecido com o Linux, o Git senta e assiste você ferrar com todas as suas
coisas, e então ri de você quando tenta colocar seu mundo novamente em pé. No
que diz respeito ao controle da fonte, nem todas as pessoas estão acostumadas
com esse amor livre.

Milo tem
usado o Git desde o seu início, e o push git pull/git com um repositório
central funciona bem o suficiente quando você tem poucos desenvolvedores.

Isso se
encaixa com a visão de mundo do Subversion de que um servidor central
benevolente nunca irá deixar você na mão. A primeira vez em que você tem um erro sobre não
poder fazer um push de commits non-fast-forward para o origin,
você meio que passa por cima dele, e um git pull conserta isso
rapidinho. Se você entender o Git da mesma maneira que você entende o SVN, pode facilmente confundir esse erro com algo do tipo “hum, eu só
terei que fazer um merge pois alguém fez commit antes de mim“. Bem, tecnicamente isso está certo,
mas pelos motivos errados. Ao usar esse modelo, se você pensar
em desenvolvedores como diferentes threads compartilhando o
respositório origin, então o Git está trancando todo o
repositório, em vez de arquivos individuais. Com tantas threads compartilhando uma fonte, sempre irá existir
contenção. No entanto, em uma equipe pequena o suficiente, é possível pensar dessa
maneira.

É aqui
que as pessoas inteligentes têm problemas. Sabemos que no fundo algo está um pouco errado naquela mensagem de erro non-fast-forward-commit,
mas tudo parece bem, então por que ler sobre o que está acontecendo? Eu
geralmente não sou fã de ler documentações até que eu esteja debugando um
problema, porque espero que o software se comporte como se tivesse sido eu que
o tenha escrito. Boa documentação é concisa de maneira condescendente, e a documentação do
Git é como um crítico de arte que ri de você (a descrição de git-rebase é “Forward-port local commits to the
updated upstream head”. Ah, sai fora.)

Recentemente, começamos a usar o Gerrit para revisão de código, e qualquer um que esteja usando Git apenas traduzindo os conceitos dos comandos
SVN está prestes a quebrar a cara.

O Gerrit
atua como um intermediário entre desenvolvedores e o repositório de origem.
Você envia commits para o Gerrit, e ele os segura em um purgatório até que a sessão seja encerrada por outro desenvolvedor. Então, se o commit aplicar claramente
ao branch, o Gerrit o aplica. Caso contrário, ele pede para que você carregue
um merge commit, que é quando a diversão realmente
começa.

O lado
positivo desse sistema é que ele previne que “bagunças git” de outras pessoas se
tornem suas “bagunças git”. O lado negativo é que, como os commits estão em um
estado transitório, é muito fácil deixar um caminho de destruição em seu
repositório local com rebase e merge se você não entender o que de fato está acontecendo.
Como velhas marcas de derrapagem na estrada, nosso codebase é apimentado com
merge commits e escolhas que são apenas os registros de uma série de momentos
ruins.

O
problema não é que o Git é muito difícil, é que desenvolvedores inteligentes
são impacientes e têm tolerância zero com comportamentos inesperados em suas
ferramentas. Enquanto o Git é a moda do momento, talvez algum dia você pode
encontrar um desenvolvedor grisalho que estará usando SVN, e quando você
perguntar a ele por quê, sua resposta não vai fazer sentido, porque será uma
coisa Zen.

?

Texto original disponível em http://teddziuba.com/2010/08/too-smart-for-git.html