Eu particularmente uso o rebase quando estou trabalhando na minha feature. Além também de utilizar amend para evitar criar vários commits. Pois aí está uma sugestão para vocês, um vídeo explicando como aplicar o squash para aqueles que fazem inúmeros commits e como complemento, o amend. Também existe o cherry pick para outro vídeo. Parabéns pelo vídeo! Abraço
@@ursochurrasqueira confesso que utilizei poucas vezes, porém já me salvou em momentos específicos. No es tão difícil, simplesmente pensa que tu vai aplicar um commit específico a tu rama.
@@alexanlp o cherry pick se utiliza para aplicar um commit específico e suas modificações a tu rama (feature). Detalhe que isso não te isenta de que ter que solucionar conflitos. Primeiro necessitas saber o ID (hash commit) do commit e depois executar git cherry-pick . Para saber o hash execute: git log -online.
Perfeito! Um exemplo bastante real usado aqui onde trabalho. Tive problemas já com atualizações de main e staging enquanto codava e outros devs já tinham mergeado novas atualizações na main e essa solução me ajudou muito a evitar várias dores de cabeça que eu fazia de forma bastante manual e não tão inteligente. Muito obrigado pelos conteúdos incríveis!
Muitas vezes acabo fazendo o merge com a master de dentro da feature branch e depois fazendo o merge lá na master (por meio de PR). Fica bem mais clean assim, acho que vou adotar.
TNice tutorials is by far the best soft soft basic tutorial, I rember when I just started learning, tNice tutorials was so helpful!! I’ve now been releasing edm
Muitos parabéns pelo video. Ajudou bastante. Por coincidência estava a ter algumas dificuldades em utilizar o rebase e este video veio no momento certo. Abraço de Portugal 🙂
Vocês podem trazer um video de como trabalhar como repositórios remotos? Ou se vocês já tem um video explicando como trabalhar dessa forma? Estou participando de um projeto que de uma maneira muito democrática fui nomeado líder do projeto kkkkk, como não tenho experiencia queria conhecer boas práticas para trabalhar com repositórios remotos
Atualmente eu faço merge da develop para a branch da feature para sincronizar as alterações e depois faço o merge da PR para a develop com as alterações da feature, mas não sei se isso é a melhor forma.
Cara, me lembro de ter começado a usar rebase por causa de um vídeo do canal... Até perceber o estrago que poderia causar e logo restringir a branch's exclusivamente locais 😎
Prezados, Como poderíamos fazer um rebase na mesma branch de forma a "deletar" algum subconjunto de commits, mas de forma a manter o último commit desta mesma branch?
To com um cenario e gostaria da opniao de voces sobre qual o melhor caminho a seguir. Tenho uma master em PRD, com uma versao 1.18 E tenho em HML uma versao 1.25 Sendo que algumas mudanças nao podem subir pra master. Como retirar essas mudanças e subir somente o q preciso? Exemplo. as mudanças das tags 1.20 e 1.21 nao podem subir. Obrigado!
Se usa rebase quando vc n deseja manter historico do branch. O merge funciona sim se o branch base estiver avançado em alguns commits. A unica diferença entre merge e rebase é a questão do historico.
Opa .. boa tarde, reproduzi o exemplo e aqui depois de resolver o conflito do rebase .. fazer o continue deu um erro .. que tive que setar o 'git config pull.rebase false' e depois ele me pediu para resolver novamente o conflito, porque isso ocorre?
Eu quando vejo que o Main está tendo muitas alterações em relação ao meu branch, eu faço um merge em cima do meu branch com as alterações do Main e ajusto. O Rebase pelo que eu entendi faz a mesma coisa, então qual seria a diferença?
Uma coisa que achei estranha foi falar que perde o histórico, o que não é verdade. Ele refaz a timeline da branch mas os commits ainda continuam lá o histórico não é perdido. Eu considero muito mais intuitivo assim pois deixa uma linha só, se ficar só fazendo Merge começam a ter mais de 2 timeline deixando o histórico difícil de ler
perde o histórico no sentido de ter ocorrido uma manipulação da linha do tempo. isso pode ser catastrófico para um projeto grande caso um desenvolvedor iniciante ou desatento faça errado. o merge costuma manter a linha do tempo anterior, sendo assim mais fácil de reverter em caso de erro humano.
N tem nenhum problema em fazer commit no master desde que n seja feito push pra o repositorio principal. Vc sempre tem chance de corrigir o erro no seu clone.
@@heraldo623 sou meio Noob ainda, mas lá eu teria que commitar na branch da minha feature e eles que fazem o merge com a main. Lá fui eu, um pobre estagiário fazer caca
Putz, um vídeo sobre as diferentes estratégias de merge seria interessantíssimo
Eu particularmente uso o rebase quando estou trabalhando na minha feature.
Além também de utilizar amend para evitar criar vários commits.
Pois aí está uma sugestão para vocês, um vídeo explicando como aplicar o squash para aqueles que fazem inúmeros commits e como complemento, o amend.
Também existe o cherry pick para outro vídeo.
Parabéns pelo vídeo!
Abraço
cherry pick é difícil de entender mas é muito útil
@@ursochurrasqueira cherry pick é praticamente um extintor de incêndio, kkkk É o último recurso na hora de subir uma feature num projeto extenso.
@@ursochurrasqueira confesso que utilizei poucas vezes, porém já me salvou em momentos específicos.
No es tão difícil, simplesmente pensa que tu vai aplicar um commit específico a tu rama.
@@brunojunqueira737 o cherry pick seria para "subir" um commit específico? seria isso? estou perguntando porque não entendo ele muito bem ainda.
@@alexanlp o cherry pick se utiliza para aplicar um commit específico e suas modificações a tu rama (feature).
Detalhe que isso não te isenta de que ter que solucionar conflitos.
Primeiro necessitas saber o ID (hash commit) do commit e depois executar git cherry-pick .
Para saber o hash execute: git log -online.
Uma das melhores e mais simples explicações sobre o rebase que eu já vi, parabéns
Achei q nunca ia ficar a vontade com esse rebase. Obrigado!
Esse vídeo veio em boa hora, estou me familiarizando a trabalhar com o git e o que sei até o momento é bem basico.
bah, por favor, façam mais desses videos, sempre é bom ter uma prática dos comando do GIT e principalmento as tecnicas de utilização
Gostei sim. Quanto mais git melhor. E menos linha de comando. Cansei de ficar decorando comandos de tecnologias que estão sempre mudando.
Melhor explicação de rebase que já vi. Parabéns pelo vídeo!
Perfeito! Um exemplo bastante real usado aqui onde trabalho. Tive problemas já com atualizações de main e staging enquanto codava e outros devs já tinham mergeado novas atualizações na main e essa solução me ajudou muito a evitar várias dores de cabeça que eu fazia de forma bastante manual e não tão inteligente. Muito obrigado pelos conteúdos incríveis!
Muitas vezes acabo fazendo o merge com a master de dentro da feature branch e depois fazendo o merge lá na master (por meio de PR).
Fica bem mais clean assim, acho que vou adotar.
Muito bom, uma das maiores dificuldades que tinha quando entrei na empresa que to atualmente era entender o rebase
Só peguei o bizu do drawio no vscode, adorei
TNice tutorials is by far the best soft soft basic tutorial, I rember when I just started learning, tNice tutorials was so helpful!! I’ve now been releasing edm
Muito boa a explicação, só não dá pra perdoar o commit direto na main,hahaha. Sempre aprendendo com vocês, obrigado!!!
Muitos parabéns pelo video. Ajudou bastante. Por coincidência estava a ter algumas dificuldades em utilizar o rebase e este video veio no momento certo. Abraço de Portugal 🙂
Vocês podem trazer um video de como trabalhar como repositórios remotos? Ou se vocês já tem um video explicando como trabalhar dessa forma? Estou participando de um projeto que de uma maneira muito democrática fui nomeado líder do projeto kkkkk, como não tenho experiencia queria conhecer boas práticas para trabalhar com repositórios remotos
Finalmente eu entendi esse conceito. Vlw pessoal, vcs são demais!
Gostaria de ver um exemplo completo com várias PRs e como lidar com os conflitos (não sendo API pública)
Atualmente eu faço merge da develop para a branch da feature para sincronizar as alterações e depois faço o merge da PR para a develop com as alterações da feature, mas não sei se isso é a melhor forma.
Por favor, façam mais vídeos sobre estratégias com o GIT.
Simples e objetivo ... bão demais!!! 👏
Obrigado, por essa excelente aula
Cara, me lembro de ter começado a usar rebase por causa de um vídeo do canal... Até perceber o estrago que poderia causar e logo restringir a branch's exclusivamente locais 😎
Melhor video sobre o assunto
Bah, o rebase é muito bom!
I checked - everything is clean
Didática muito boa!
Dica muito boa, seria ótimo mais conteudos sobre git, principalmente os comandos mais usados por uma equipe de devs
Fala sobre o rebase -i
Squash e fixups são muito importantes para o uso do git em produtos reais. Meus 2c para um próximo vídeo aprofundando em git.
gostei desse deno aí 👀
git merge e boa, resolve sem os riscos do rebase
Prezados,
Como poderíamos fazer um rebase na mesma branch de forma a "deletar" algum subconjunto de commits, mas de forma a manter o último commit desta mesma branch?
Faz com repositório remoto, por favor
voces sao otimos
To com um cenario e gostaria da opniao de voces sobre qual o melhor caminho a seguir.
Tenho uma master em PRD, com uma versao 1.18
E tenho em HML uma versao 1.25
Sendo que algumas mudanças nao podem subir pra master.
Como retirar essas mudanças e subir somente o q preciso?
Exemplo. as mudanças das tags 1.20 e 1.21 nao podem subir.
Obrigado!
Se usa rebase quando vc n deseja manter historico do branch. O merge funciona sim se o branch base estiver avançado em alguns commits. A unica diferença entre merge e rebase é a questão do historico.
muito obrigado!
queremos squash!
queremos squash!
Parabéns pelo excelente conteúdo, como de costume.
Vídeo top dms 👏🏼👏🏼
git pull origin main --rebase tem o mesm o efeito?
Como faz para utilizar o formato antigo de resolução de conflito? Não me adaptei a esse editor
thank u helped me a lotNice tutorial.... Very helpful
squash merge sim, por favor! :D
Agora entendi ! kkk
Ótimo vídeo 👍
Tão essencial como respirar
Pq não fazer um merge da main into feature antes de voltar a feature into main?
É verdade, poderia facilmente ser um merge. 👍
@@codigofontetv caras, sou muito fã de vcs! Obrigado pela força e pela luz nesse "incrível" mundo da programação!
it work on my pc thx bro vеry much
Eu dei o like já na hora do esbudegar ... me ganhou ali. kkkkkkkkkkkkkkkk
Opa .. boa tarde, reproduzi o exemplo e aqui depois de resolver o conflito do rebase .. fazer o continue deu um erro .. que tive que setar o 'git config pull.rebase false' e depois ele me pediu para resolver novamente o conflito, porque isso ocorre?
Eu quando vejo que o Main está tendo muitas alterações em relação ao meu branch, eu faço um merge em cima do meu branch com as alterações do Main e ajusto. O Rebase pelo que eu entendi faz a mesma coisa, então qual seria a diferença?
faço o mesmo. Não entendi também esse problema com o commit do merge dizendo que não serve pra nada.
@@andrepintodev é porque acho que vai gerar um commit específico dizendo que foi feito um merge, por isso ele "não tem" utilidade
@@alexanlp sakei. Eu gosto dele. Pra saber o que rolou no merge
Uma coisa que achei estranha foi falar que perde o histórico, o que não é verdade. Ele refaz a timeline da branch mas os commits ainda continuam lá o histórico não é perdido. Eu considero muito mais intuitivo assim pois deixa uma linha só, se ficar só fazendo Merge começam a ter mais de 2 timeline deixando o histórico difícil de ler
perde o histórico no sentido de ter ocorrido uma manipulação da linha do tempo. isso pode ser catastrófico para um projeto grande caso um desenvolvedor iniciante ou desatento faça errado. o merge costuma manter a linha do tempo anterior, sendo assim mais fácil de reverter em caso de erro humano.
Muito bom
Salvou a pele!
Quase o meu salário essa Alura, dá não kkkkk
topzera!
Top
Bacana!
Sempre achei mais facil fazer o pull de main
Só não achei legal vocês terem rodado rebase na branch main. Já estava tudo certinho. Após isso é abrir pr da feature pra main que tava lindo
É verdade, não havia necessidade mesmo. Obrigado pelo feedback.
Ensina como não commita direto na Master kkkkkkk. Errei o commit e mandei lá pra branch principal do projeto da empresa :(
N tem nenhum problema em fazer commit no master desde que n seja feito push pra o repositorio principal. Vc sempre tem chance de corrigir o erro no seu clone.
@@heraldo623 kkkk em um ambiente corporativo sim. Meu gestor quase ranca minha orelha
@@heraldo623 sou meio Noob ainda, mas lá eu teria que commitar na branch da minha feature e eles que fazem o merge com a main. Lá fui eu, um pobre estagiário fazer caca
Diz aqui quem nunca fez caca com o rebase?
Eu não faço rebase.
I did
Não dei um tapa não! Apena cliquei no like. Pode ser? kkkkkkk....
Só eu que achei estranho o "cômiti"?
Há 15 anos tralhando com desenvolvimento sempre falamos "comíti"
No mais o vídeo foi legal.
First Commit!
pô, até entendi o "como", mas não ficou muito claro sobre o "quando" ou "porquê" usar ou não usar o rebase.