HTML-код
- Опубликовано: 29 сен 2024
- ✅Será que dominar a linguagem JavaScript não é o que está faltando para você trabalhar naquele lugar que sempre sonhou? Uma coisa eu posso garantir, o JavaScript Masterclass vai ser uma experiência que você nunca mais vai esquecer! Saiba mais em www.javascript...
Confira outras séries do canal:
🔥Quer ficar por dentro de tudo sobre linguagens de programação, frameworks, automação de testes, padrões de projeto, segurança, escalabilidade, arquitetura e muito mais? Fique ligado nas nossas lives em • Live
🔥Escrever código com baixa qualidade, de forma ilegível e bagunçada pode até funcionar! No entanto, esse tipo de atitude, seja ela consciente ou não, resulta na contração de uma dívida que cobra juros altos, pagos com a perda constante de produtividade. Quer saber mais sobre qualidade de código? Então assista a nossa série este assunto em • Clean Code
🔥Você não pode deixar de ficar por dentro deste que é o software de controle de versão mais utilizado do mundo! Acompanhe esta série em • Git
Acompanhe nossas redes sociais:
➡️Instagram: / rodrigobranas
➡️Twitter: / rodrigobranas
➡️GitHub: github.com/rod...
➡️LinkedIn: / rodrigobranas
➡️Facebook: / canalrodrigobranas
Conheça todos os nossos treinamentos:
🚀AgileCode: www.agilecode....
Quer me conhecer melhor:
🎙️Entrevista no DEVNAESTRADA: bit.ly/dne-79-r...
Outras informações:
🇧🇷Idioma: PT/BR
Muito boa a explicação, direto ao ponto.
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.
Incrível, estava procurando algo com esse tema.
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?
tu usa angular js ou angular ?
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
hehehehe eu também... E quando o arquivo não liberava no processo de checkin?
Cara eu estava pesquisando sobre isso esses dias, veio muito a calhar.
Você é o melhor professor do Brasil nessa área de TI. Comunicação limpa, clara e no ponto certo.
Obrigado Julian!
Fala mais sobre versionamento sequencial
Também fiquei interessado nesse tema!
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
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.
Deve dar um certo trabalho, mas faz parte! Abraços!
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 ?
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.
Show.. era exatamente isso que tava procurando para melhor entendimento
Nossa me ferrei muito no starteam ... Época Borland
Gitflow é sensacional
cara, que aula!
Muito bom!
Top a explicação, ajudo muito Parabéns!
Cara, conteúdo de qualidade vc nos proporcionou. Muito Obrigado!
Valeu!!
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?
estou com a mesma duvida, já descobriu a resposta?
@@juannunes5946 nem procurei mais, uso o git normal, sem ficar criando isso, creio que só vou descobrir quando entrar em uma empresa mesmo...
Você que decide
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.
Qual a diferença da Master e stable?
Muito obrigado Rodrigo!
Excelente explanação.
Muito bom
Posso assistir 50 horas do Rodrigo explicando qualquer coisa.
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!