O objetivo deste canal é tornar o entendimento sobre tecnologia mais acessível e descomplicado para todos. Prepare-se para mergulhar em vídeos envolventes, repletos de explicações claras e práticas, que visam simplificar conceitos complexos.
Se você é um entusiasta da tecnologia em busca de aprendizado e aprimoramento, este é o lugar certo para você. Junte-se a nós nessa jornada de descobertas e aprofunde seus conhecimentos em programação e inovação tecnológica.
Inscreva-se agora para não perder nenhum conteúdo e faça parte da nossa comunidade de aprendizado!
Sobre o "}" que faltou na parte do conflito, e precisou ser adicionado manualmente, como os dois commits terminam iguais, essa parte não conflitou e foi resolvida automaticamente pelo git. Porém ele infelizmente não reconhece o código que foi escrito e não percebeu que precisaria repetir isso para aceitar as duas alterações.
Tenho uma pergunta: Uma branch pode referenciar a pessoa que está fazendo a alteração? Se não, como posso saber quem realizou a alteração naquela branch específica?
@@guilhermetostes9528 No Git, uma branch em si não referencia diretamente quem está fazendo as alterações. Porém, o histórico de commits dentro de uma branch contém essas informações. Cada commit no Git registra quem realizou aquela alteração através dos metadados do commit, como o nome e o e-mail do autor e do committer.
Na verdade, o git pull roda um fetch + merge ou fetch + rebase. Isso é configurável com "git config pull.rebase true", por exemplo. Falando nisso, um vídeo sobre rebase, diferenças para o merge, formas de fazer um merge do PR (merge, rebase, squash and merge), seria legal.
Um ponto a se destacar é que é possível existir uma "origin/algumacoisa", mas não ser possível fazer o push da branch "algumacoisa", principalmente se o push foi feito sem o parâmetro --set-upstream (ou -u que é seu atalho). Ou ainda que uma branch local tenha outro nome no GitHub, por exemplo, para verificar isso basta executar o comando "git config branch.minhabranch.remote" para verificar para qual servidor o commit será enviado, e "git config branch.minhabranch.merge" para ver qual o nome da branch remota.
Uma coisa a se observar é que deve-se utilizar "git init" ou "git clone", mas nunca os dois. É bem comum iniciantes fazer "git init" depois "git clone" dentro do repositório que já haviam criado, isso gera uma confusão de um repositório tentar versionar o outro (o de fora tenta versionar o de dentro), e hora faz o commit num repositório, hora no outro, ai o commit "some" porque está olhando o histório de um, mas o commit foi feito no outro...
Excelente observação! Isso realmente é um erro comum entre iniciantes. Usar git init e depois git clone no mesmo diretório pode causar uma confusão enorme, como você explicou. O ideal é usar apenas um dos dois: git clone para copiar um repositório existente ou git init para iniciar um repositório do zero. Obrigado por compartilhar essa dica importante! 👏
@@rsantanatech isso é bem comum por iniciantes só irem copiando e colando os comandos sem ler a explicação direito, ai no final acha que precisa executar todos os comandos que o material mostrou.
Embora o git não tenha trocado o nome da branch padrão, foi criado uma configuração para isso, então se quiser, basta executar "git config --global init.defaultBranch main", assim novos repositórios serão criados com main em vez de master.
Uma coisa interessante desse comando é que ele desfaz todas as alterações que aquele commit fez, e só aquelas alterações. Se teve alterações depois do commit que desejamos desfazer, essas mudanças posteriores não serão desfeitas, continuando lá, apenas o que foi feito naquele commit será desfeito.
Exatamente! Isso é uma das grandes vantagens do git revert. Ele garante que apenas as alterações daquele commit específico sejam desfeitas, sem interferir no que veio depois. É uma ótima maneira de corrigir erros sem prejudicar o progresso que já foi feito no projeto. Valeu por complementar com essa explicação! 👏
Eu acho interessante os + desse diff, que cria uma coluna para cada arquivo, então da para facilmente visualizar se uma linha veio de um commits, de outro, ou foi uma linha nova resolvendo o conflito no commit de merge, que nesse caso seria "++".
Uma opção legal para verificar as diferenças nas branches é "git hist master roles" onde o git mostrará o grafo do histórico das duas branches juntas. Ou ainda "git hist master...roles" que dessa forma o git ocultara a parte comum, só mostrando os commits de diferentes.
Uma coisa para se destacar é que os alias criados dessa forma se referem a um comando git. Então tento o comando usado no terminal, para se criar um alias para ele, basta remover o git da frente do comando e passar ele nesse comando do alias. E esse alias continua sendo o comando original, nesse caso do alias hist, ele é um git log, podendo receber outros parâmetros, como "git hist --all" para listar todas as branches e não apenas a atual. Porém isso é para um único comando do git. Se precisar executar outros comandos que não são git, ou quiser executar mais de um comando git, é possível criar o alias começando com "!", mas nesse caso é necessário informar o comando completo, exemplo: git config --global alias.pullmain '!git fetch origin main && git merge origin/main'
