10 Things I hate about Git

Assuntos Gerais
#6

Interessante o texto, também já passei pela maioria dos problemas citados. Mas a maioria é coisa contornável. Por exemplo, sobre o workflow que demanda o uso de vários comandos para, por exemplo, subir a implementação de uma feature para o master e a ausência de shortcuts para coisas simples, eu uso alguns shell scripts que me ajudam no dia-a-dia nas tarefas rotineiras, como atualizar um branch com o master, subir uma alteração de um branch para um master e outras coisas.

Na minha opinião o Git é uma ferramenta bastante poderosa e flexível. Por exemplo, eu posso usar o esquema de hooks do git para chamar o servidor de integração contínua e fazer ele rodar todos os testes unitários da minha aplicação quando eu mandar alguma coisa pro master. Fora outras possibilidades interessantes, como o comando bisect que permite procurar qual commit inseriu determinado problema no sistema.

O problema que eu vejo é que o git é uma coisa muito complicada pra aprender a curto prazo. Eu mesmo levei alguns meses para me acostumar com a forma de trabalho com o git, entender o uso de cada comando, entender aquele monte de conceitos, como o index, o branch, o stash e outras coisas. Mas depois que você aprende se torna bem mais produtivo do que com o SVN.

Bom, essa é apenas minha opinião.

#7

rogelgarcia

Acho que tem uma complexidade desnecessária. Concordo muito com o item 1 do artigo.

Essa semana tivemos vários problemas com alguns merges e não encontramos o culpado, pode ter sido alguém na equipe que tenha feito besteira.

Fora código que já tive que ficar recuperando do histórico local por não ter feito commit antes do update. Isso foi por falta de conhecimento meu sobre a ferramenta, mas concordando mais uma vez com o artigo, faltou abstração.

A única vantagem que vejo é poder trabalhar offline.

#8

matheuslmota

Para integração contínua nosso querido Maven resolve muito bem.

Como tenho pouco tempo de trabalho com ele ainda não tive tempo para estudar mais a fundo. Li apenas alguns artigos e uma apostila de uma escola de treinamento. Vamos ver se com o tempo mudo de ideia.

#9

[quote=fredericomaia10]matheuslmota

Para integração contínua nosso querido Maven resolve muito bem.

Como tenho pouco tempo de trabalho com ele ainda não tive tempo para estudar mais a fundo. Li apenas alguns artigos e uma apostila de uma escola de treinamento. Vamos ver se com o tempo mudo de ideia.[/quote]

Quem vem do SVN geralmente torce o nariz um pouco. Comigo foi assim. Comecei a usar Git na empresa por exigência do nosso cliente. No começo é meio dolorido migrar do SVN pro Git porque são mundos totalmente diferentes.

O git é um bocado complicado de aprender no começo mas depois que se pega a prática a produtividade aumenta muito. Ele é ótimo para gerenciar merges, tem ferramentas para recuperar commits quebrados acidentalmente (por exemplo, vai que eu peguei algo do master que sobrescreveu o que eu fiz e eu perdi meu trabalho, posso recuperar com o uso do git reflog e do git reset). Fora que o fato de o git ser um controle de versão distribuído permite criar coisas como o github, que permitem facilmente decentralizar o versionamento de código da infra-estrutura da empresa.

O único problema que vejo no git é a complexidade mesmo. Se o time todo não souber o que tá fazendo pode dar problema mesmo.

#10

Realmente é um atente a simplicidade. Custa fazer um revert descente?

git revert Blah.java

#11

Tópico movido para Ferramentas Frameworks e Utilitários.

#12

O Git no inicil é realmente complexo… apanhei muito para entender ele…

mas ele na minha opinião é o melhor versionador e o mais robusto do mercado…
mas requer muito tempo para se entender a sua filosofia

#13

Achei o cara um bocado dramático. Você não precisa entender cada detalhe do git para usa-lo. Dá sim, para usar quase como o SVN. Você vai precisar entender mais, claro, se quiser usar mais recursos. E aí, ele vai te dar muito mais recursos do que o svn dá. E, obvio, isso tem lá seu custo em complexidade.

Acho um tanto infantil comparar o git com o svn. O svn é extremamente capado. Uma comparação mais justa seria com o mercurial, ou com o sourcesafe.

Sem falar que você já tem softwares ótimos, que te afastam da linha de comando. Há integração do git com Eclipse, por exemplo.

#14

[quote=ViniGodoy]Achei o cara um bocado dramático. Você não precisa entender cada detalhe do git para usa-lo. Dá sim, para usar quase como o SVN. Você vai precisar entender mais, claro, se quiser usar mais recursos. E aí, ele vai te dar muito mais recursos do que o svn dá. E, obvio, isso tem lá seu custo em complexidade.

Acho um tanto infantil comparar o git com o svn. O svn é extremamente capado. Uma comparação mais justa seria com o mercurial, ou com o sourcesafe.

Sem falar que você já tem softwares ótimos, que te afastam da linha de comando. Há integração do git com Eclipse, por exemplo. [/quote]

Outra ferramenta legal é o TortoiseGit, que tem integração com o windows explorer e facilita um bocado o trabalho com o git. Gostava também do Smart Git, mas o mesmo ficou um pouco bugado nas últimas versões.

O que eu tenho achado mais prático é o uso de shell script mesmo para fazer determinados workflows, mas aí já vai do gosto do desenvolvedor.

#15

Nah, ele nem odeia o Git, hehhehe.

Do próprio artigo:

Para quem ainda está indeciso, só para constar, estou usando o git e o gitlab
há algum tempo e nunca mais quero botar a mão em cvs ou svn.

http://gitlabhq.com/

E nada melhor do que assitir a esse video para saber o que pensa o cara
que criou o git, principalmente suas opiniões sobre o cvs e svn (engraçado).

http://www.youtube.com/watch?v=4XpnKHJAok8

#16

Tenho usado GIT no livro que estou escrevendo.

Nunca usei e me acho o maior idiota usando. Sei apenas fazer pull ou commit + push.

Ainda não parei para estudá0lo pois se não eu não continuo meus outros estudos.

Realmente ainda prefiro o svn. =/

#17

Provavelmente o cara não entendeu de fato o propósito do Git. É estranho querer comparar git-svn levando em conta facilidade de comando, estado dos arquivos, estrutura de indice. WTF?

Dá pra usar git sim da forma simples como se usa o svn.
E se quiser dominar mais ainda a ferramenta e entendê-la a fundo, basta pensar como grafo. Git são grafos.

http://think-like-a-git.net/
http://git-scm.com/book

#18

Aprendi o GIT por esse Screencast do Akita:

Vale muito a pena assistir e entender que Git - SVN e CVS são coisas completamente distintas… Subversion é um emaranhado de confusão que funciona bem pra 90% do que as pessoas precisam de um SCM que faça commits e updates.

Quero destacar aqui alguns pontos fortes do Git:

  • Para fazer backup do seu projeto, copie a pasta .git e você consegue abrir qualquer commit de 10 anos atrás dado em seu projeto.
  • GitK que faz com que você visualize rapidamente a timeline do seu projeto.
  • Uso de hashes que indentificam o seu commit, permitindo que alguns comandos consigam facilmente desfazer seu commit anterior.
  • Github, que embora não seja nativo do git, é algo realmente fora do comum quando você usa todos os recursos que o mesmo disponibiliza.

Minha dica é, use o Git. No primeiro mês, você vai querer enforcar o Linus por ter criado algo tão complexo, ao final do segundo mês, você vai estar querendo escrever uma carta pra ele, pedindo desculpas e agradecendo grandemente por tão bem prestado à humanidade (ia escrever comunidade, mas humanidade ficou mais dramático).

Agora um detalhe importante. Se você tem projetos pessoais já funcionando no SVN e tudo para o que você usa são commits e updates, fique no SVN mesmo, ele lhe atende bem.

Mas se trabalha com Ns tarefas ao mesmo tempo, de forma que precisa trabalhar com multiplas branchs em paralelo, se gostaria de criar tags próprias sem depender “do cara” da infra, se precisa fazer backup de todo o histórico do seu projeto em menos de 10 segundos (ou retirar seu projeto de um versionador em menos de 5 segundos tbm) e quem sabe até compartilhar seu Notebook como um Server remoto sem precisar de um git-server + git-client, use o Git… Só Git, pura e simplesmente Git. Sem server, client, commons, blá, blá blá…

Enfim, dependendo do que você precisar, Git pode ser sua salvação, minha experiência é a seguinte “Como consegui viver (em paz) sem o Git até hoje? Ah é, não viví, meus SCM sempre tratavam de acabar comigo.” Rsrsrsrsrsrs :smiley: Brincadeira…

Abs []

#19

Só o fato do git ter private local branch e não ficar espalhando arquivos .svn pelo seu projeto já basta pra eu preferir usar git.

#20

Mas aí você está batendo em uma tecla que o próprio autor do artigo citou: os erros do SVN não fazem acertos do git.

[]'s

#21

Mas aí você está batendo em uma tecla que o próprio autor do artigo citou: os erros do SVN não fazem acertos do git.

[]'s[/quote]

Verdade. É fato que o GIT tem muita coisa que poderia ser melhorada.

O artigo realmente trás algumas bem pertinentes. O grande problema, é que artigos dessa espécie deve ter um público alvo específico. Qualquer um que não seja capaz de abstrair o que interessa do que não interessa transforma a coisa em uma guerrinha de ferramentas.

Como o Vinny falou, a comparação GIT - SVN é até injusta, pois ambos possuem propostas diferentes. Tem gente que usa Git, quando um SVN já resolve os seus problemas, e aí detona a ferramenta como se não prestasse… Assim como outros que usam SVN quando na verdade precisavam de um GIT para resolver seus entraves.

Só que o Rubem deu uma opinião pessoal que eu concordo, pois a conversa estava indo para esse lado, quando alguns amigos manifestaram o sentimento de “ainda bem que não usei”. Eu expliquei que usei, mostrei algumas coisas que foram vantagens pra mim e recomendo fortemente o screencast do Akita sobre o assunto.

Enfim, no final das contas, o próprio Subversion nasceu com o Slogan de ser “um CVS melhorado”…

#22

FATO:

Nunca, jamais, em momento algum use GIT num projeto sem que nenhum membro da equipe REALMENTE o domine…

Sem dúvida é poderoso e completíssimo, botando o SVN no chinelo em funcionalidades, porém é MAIS UMA FERRAMENTA e com grande curva de aprendizado que vamos ter que passar meses (conforme o relatos dos defensores aqui) para aprender, como se já não bastasse as 2 dúzias de ferramentas que temos que saber para projetos novos e legados :frowning:

GIT, só com um “coach”, pois até aprender sozinho terá feito umas 50x o clone do mesmo projeto após desistir de tentar fazer simples operações de trocar arquivos com o repositório remoto. Eu mesmo já perdi a conta de vezes que não tive alternativa a não ser fazer outro “clone” do mesmo projeto após desistir de tanto do comando após conflitos que só o GIT enxergava. Talvez eu não tenha QI suficiente para usar o GIT (não é ironia, eu realmente acho que para usar GIT no dia-a-dia você deve ter um QI bem acima da média).

Talvez se o GIT tivesse plugins para Eclipse e Netbeans realmente funcionais como existem para SVN e cia… Mas realmente ainda não é o caso. Por isso torço pela evolução desses plugins para que o GIT possa ser mais fácil de aprender e usar.

#23

[quote=jyoshiriro]FATO:

Nunca, jamais, em momento algum use GIT num projeto sem que nenhum membro da equipe REALMENTE o domine…

Sem dúvida é poderoso e completíssimo, botando o SVN no chinelo em funcionalidades, porém é MAIS UMA FERRAMENTA e com grande curva de aprendizado que vamos ter que passar meses (conforme o relatos dos defensores aqui) para aprender, como se já não bastasse as 2 dúzias de ferramentas que temos que saber para projetos novos e legados :frowning:

GIT, só com um “coach”, pois até aprender sozinho terá feito umas 50x o clone do mesmo projeto após desistir de tentar fazer simples operações de trocar arquivos com o repositório remoto. Eu mesmo já perdi a conta de vezes que não tive alternativa a não ser fazer outro “clone” do mesmo projeto após desistir de tanto do comando após conflitos que só o GIT enxergava. Talvez eu não tenha QI suficiente para usar o GIT (não é ironia, eu realmente acho que para usar GIT no dia-a-dia você deve ter um QI bem acima da média).

Talvez se o GIT tivesse plugins para Eclipse e Netbeans realmente funcionais como existem para SVN e cia… Mas realmente ainda não é o caso. Por isso torço pela evolução desses plugins para que o GIT possa ser mais fácil de aprender e usar.[/quote]

Veja este screencast do Akita On Rails de 3hs SCREENCAST GIT, veja tudo, depois experimente novamente alguns dias, ENTENDENDO o que esta fazendo, como funciona o HEAD e tudo mais, depois se ainda tiver achando muito dificil, vou concordar vou vc na questão do QI :wink:

#24

Olá, fred.

Todo mundo que lê/ouve uma reclamação minha me passa esse vídeo hehehehe

Amigo, já o vi, já entendi como o GIT funciona e já sei boa parte dos comandos. A questão é que não levei “dias” (e todo mundo sempre me fala “meses” pra aprender). Não estou aqui dizendo “mimimi não sei e não aprendi a usar o GIT” e sim que ele é muuuuuito mais difícil de aprender e usar que SVN e cia. Já sei que serva pra 100000 de coisas a mais, mas me refiro a simplicidade de controle de versão.

Todo mundo me passa esse mesmo vídeo aí e me fala em “meses” de aprendizado (você é o primeiro que me fala em “dias”). SVN e cia a pessoa vê o colega CLICAR em menus na IDE, fazer merges de forma VISUAL na IDE e talvez nunca mais pergunte pra ninguém como fazer as coisas. Entendeu o que eu quis dizer?

Vejo colegas dizendo que há plugins visuais de GIT pra Eclipse e Netbeans. Realmente há mas são muito bugados (usei ambos esses meses agora)… Passam a anos luz dos similares pra SVN e cia. Sei que isso não é culpa da equipe do GIT e nem um defeito do GIT, mas que plugins visuais para as IDEs free que realmente ajudassem seriam uma mão na roda, não concorda?

Enfim, reconheço o potencial e o grande valor do GIT, mas que ele tem uma grande curva de aprendizado e é bem trabalhoso de usar se comparado com SVN e cia, disso eu não tenho dúvida.

#25

[quote=jyoshiriro]Olá, fred.

Todo mundo que lê/ouve uma reclamação minha me passa esse vídeo hehehehe

Amigo, já o vi, já entendi como o GIT funciona e já sei boa parte dos comandos. A questão é que não levei “dias” (e todo mundo sempre me fala “meses” pra aprender). Não estou aqui dizendo “mimimi não sei e não aprendi a usar o GIT” e sim que ele é muuuuuito mais difícil de aprender e usar que SVN e cia. Já sei que serva pra 100000 de coisas a mais, mas me refiro a simplicidade de controle de versão.

Todo mundo me passa esse mesmo vídeo aí e me fala em “meses” de aprendizado (você é o primeiro que me fala em “dias”). SVN e cia a pessoa vê o colega CLICAR em menus na IDE, fazer merges de forma VISUAL na IDE e talvez nunca mais pergunte pra ninguém como fazer as coisas. Entendeu o que eu quis dizer?

Vejo colegas dizendo que há plugins visuais de GIT pra Eclipse e Netbeans. Realmente há mas são muito bugados (usei ambos esses meses agora)… Passam a anos luz dos similares pra SVN e cia. Sei que isso não é culpa da equipe do GIT e nem um defeito do GIT, mas que plugins visuais para as IDEs free que realmente ajudassem seriam uma mão na roda, não concorda?

Enfim, reconheço o potencial e o grande valor do GIT, mas que ele tem uma grande curva de aprendizado e é bem trabalhoso de usar se comparado com SVN e cia, disso eu não tenho dúvida.[/quote]

Pra ser sincero nunca usei muito os plugins das IDE’s, o pouco que vi do e-git no eclipse parece que ele até abstrai e fica meio parecido com cvs/svn, no IDEA achei tranquilo tambem, mas eu realmente me acostumei a fazer os comandos na console mesmo, depois q acostuma tu nem sente falta de interface grafica, quando preciso enxergar melhor visualmente o que esta havendo uso o gitk.

Olha eu tambem tive que apagar tudo umas 3 vezes aqui, e isto depois que vi o video do Akita, dei até comando git aninhado com find do linux pra tentar consertar a coisa, mas no fim vi que eu tinha feito caca.

O segredo é ter varios branchs, e pequenos, e em cada um dos pequenos branchs ter varios commits, porque ai vc consegue ir voltando se fizer coisa errada. Um dos grandes diferenciais não é tanto o que o git pode fazer, mas a cultura de aprender a trabalhar com branchs pra todo lado, que, ao menos em svn/cvs nao é tao comum.

eu gosto de fazer um branch pra cada issue/ticket/feature
-master - código de produção
–develop - um passo antes da producao, onde todas as issue se reunem
----issue_10 - e aqui um branch pra cada feature/bug/issue, e dentro de cada nao tenho apenas um commit grande com tudo que fiz, mas varios
----issue_11
----issue_12