Você é o melhor professor do Brasil nessa área de TI. Comunicação limpa, clara e no ponto certo.

@RodrigoBranas

3 жыл бұрын

Obrigado Julian!

Incrível, estava procurando algo com esse tema.

Show.. era exatamente isso que tava procurando para melhor entendimento

Muito boa a explicação, direto ao ponto.

Gitflow é sensacional

Top a explicação, ajudo muito Parabéns!

Muito obrigado Rodrigo!

cara, que aula!

Cara eu estava pesquisando sobre isso esses dias, veio muito a calhar.

Cara, conteúdo de qualidade vc nos proporcionou. Muito Obrigado!

@RodrigoBranas

4 жыл бұрын

Valeu!!

Excelente explanação.

Muito bom!

Na empresa onde trabalho temos para cada versão (release) do software uma branch específica. A empresa tem clientes em variadas versões, quando surge um defeito fazemos commits na produção, e cherrypick nas últimas 3 e na da cliente.

@RodrigoBranas

4 жыл бұрын

Deve dar um certo trabalho, mas faz parte! Abraços!

Muito bom

Existe, no.GIT, uma forma de evitar a alteração de commits passados? Alguma configuração que impeça alguém de "mudar a história" de um arquivo?

Nossa me ferrei muito no starteam ... Época Borland

Muito bem observado Branas. Tenho a mesma impressão, sempre temos que analisar o tamanho da equipe e a quantidade de entregas em produção tb. Em alguns casos faz sentido em outros não. Trabalhei muito tempo no TFS e depois svn e realmente quanndo mudamos pro Git a cabeça da uma estalada. Um grande abraço!

Fala mais sobre versionamento sequencial

@andersonq

4 жыл бұрын

Também fiquei interessado nesse tema!

@RodrigoBranas

4 жыл бұрын

Quando pensamos no versionamento de um produto, que diferente de um framework ou biblioteca, onde não existe dependência direta do código-fonte, não vejo necessidade de utilizar Semantic Versioning com 3 números X.Y.Z, onde X é considerado major, ou seja, utilizado para alterações maiores e que podem quebrar compatibilidade, Y para minor, alterações no produto que mudam funcionalidades mas não quebram a compatibilidade e Z para patches, ou seja, apenas atualizações e correções que não são consideradas funcionalidades. Nessa situação prefiro utilizar o versionamento sequencial, similar ao Chrome ou Firefox, onde a cada nova versão apenas incrementamos o número dela independente do que foi alterado. Isso simplifica ao mesmo tempo que não requer interpretações a respeito do que mudou e se acaba sendo X, Y ou Z. Depois falo sobre isso em alguma live futura e deixo o link por aqui! Abraços

Usava VSS no Delphi mais de 10 anos atrás e quando fazia o checkout no arquivo fazia esse lock.. o cara ficava puto quando precisava trabalhar em um arquivo que estava "Checkout to ...." hehhhe

@renatospaka

3 жыл бұрын

hehehehe eu também... E quando o arquivo não liberava no processo de checkin?

Qual a diferença da Master e stable?

Fiquei com uma dúvida sobre o branch develop, caso eu crie uma branch feature implemente a funcionalidade que preciso, mas ao longo desse implementação, houve outros commits de outras funcionalidades que foram finalizadas primeiro por outro desenvolvedor, quando eu finalizar a minha vou precisar fazer merge com a develop e ela vai pegar todas as funcionalidades, mas e se eu quiser gerar uma release so com minha funcionalidade e a versão de produção não vai funcionar, pq ao gerar a partir da develop ja vai ter outras funcionalidades incluidas. Como o gitflow resolve isso? Pelo que vi esse modelo é limitado nisso.

A versão que vai para produção sempre deve ser gerada a partir do master ? Por exemplo, pode-se gerar um deploy para produção a partir de uma hotfix ?

@pedrokorb

3 жыл бұрын

A branch hotfix serve para voce não precisar criar uma nova branch para corrigir o erro em produção que venha a aparecer. O fluxo nesse caso vai ser: master (com erro) -> hotfix (correção do erro) -> master (já corrigida) Por isso não faz sentido tu fazer um deploy da tua brach hotfix. As vezes alguns times até fazem deploy da branch Dev, mas com o intuito de criar um ambiente de testes interno.

tu usa angular js ou angular ?

sobre versionamento xyz eu estou treinando o git usando em sites simples mesmo, me orientaram a usar a branch master, develop e as features, a pergunta é, quando eu botar meu site no ar eu vou lançar uma release dele de 1.0.0 correto? mas digamos q eu to la trabalhando em 3 features e dou merge nas 3 com a develop e depois de revisado tudo eu vou dar o push pra master, essas 3 features correspondem a 1.3.0 no meu release ou a 1.1.0? oq conta eh o push ou a quantidade de features implementadas? deu pra entender oq estou pensando?

@juannunes5946

3 жыл бұрын

estou com a mesma duvida, já descobriu a resposta?

@ricardogava3494

3 жыл бұрын

@@juannunes5946 nem procurei mais, uso o git normal, sem ficar criando isso, creio que só vou descobrir quando entrar em uma empresa mesmo...

@alison.aguiar

3 жыл бұрын

Você que decide

@TheArrowster

Жыл бұрын

vc gera primeiro a release das tres funcionalidades, se for a primeira release pode ser 1.0.0, faz os testes nela se tiver erro corrige direto na release e faz o merge com a develop, quando finalizar os testes na release e ela estiver pronta, vc faz o merge dela na master e na develop.

Posso assistir 50 horas do Rodrigo explicando qualquer coisa.