1
resposta

Git Hands On kkk

Boa tarde colegas, alguém sabe me dizer?

Imagine que ao começar a trabalhar em um projeto eu vou lá e clono o repositório na minha máquina e outros programadores fazem o mesmo nas suas máquinas e começamos a trabalhar. Pelo que entendi o "git commit -m" grava as modificações no meu repositório (que foi clonado e está no meu disco) e os outros programadores fazem o mesmo nos deles. Pois bem, imagine que eu e mais dois programadores estamos mexendo no arquivo "valida_form.js"; Por ser um VCS distribuído, como o Git controla esse conflito? Como eu resolvia no Subversion: reunia as três versões do arquivo e replicava o código, via merge até unificar todos os código e então commitava.

Obrigado pela ajuda.

1 resposta

Oi Bruno, vou explicar mais ou menos como meu time e eu trabalhamos.

Tenha em mente que a master está no github, então quando alguém entra no time a primeira coisa que tem que fazer é um git clone do repositório para a máquina. Depois disso sempre que ele quiser atualizar a master é só fazer um git pull. Com isso ele sempre estará atualizando a master local.

Agora quando alguém vai desenvolver uma feature nova, a primeira coisa a fazer é criar uma branch local com o número e nome da feature que será desenvolvida naquele momento. A pessoa desenvolve e vai commitando suas alterações localmente, no final do dia (isso falo por mim e não pelo time) subo a branch local para o repositório remoto, dessa forma é criada uma branch remota.

O ideal é sempre atualizar a branch local com a branch remota, via git merge ou rebase, normalmente eu faço isso quando estou a muitos dias em um desenvolvimento ou quando já terminei e pretendo "entregar", dessa forma é possível pegar conflitos caso alguém altere alguma coisa em um arquivo, mais especificamente, em alguma linha, que eu modifiquei.

Ao finalizar e não ter nenhum conflito eu abro um pull-request para o time fazer um code review. Durante o período do code review pode acontecer de alguém alterar algo e conflitar com alguma alteração minha. Quando isso acontece o github não "libera" o merge. Aí tem que resolver os conflitos novamente e se uma certa flag do github estiver marcada... será necessário coletar os approves novamente...

Depois disso tudo é só fazer o merge e sua alteração vai para a master remota. Parece ser bem complicado mas é muito tranquilo, sério mesmo.

Não sei se eu fui claro na explicação... e pode não ser o melhor modelo do mercado mas é um que funciona muito bem com o time, mas gera algumas discussões as vezes, pois se eu não me engano esse modelo é um tipo de truck based... e há quem defende o git flow. Isso é algo que vai longe, vou deixar abaixo dois links um falando do git flow e outro comparando os dois modelos.

Utilizando o fluxo Git Flow

Trunk-based Development vs. Git Flow

Espero ter ajudado, trabalhei muito pouco com subversion então não sei como comparar e falar qual é melhor... mas o mercado diz que o git é melhor xD. Mas realmente não tenho base para defender o git frente a uma ferramenta que eu não conheço. Mas eu consigo defender quando o controlador de verão é o bloco de notas, isso eu já usei em uma empesa pela qual eu trabalhava e era lastimável...

Se ficou alguma dúvida ou algo que eu tenha escrito que não faça sentido me avisa que eu arrumo.