Olá sejam todos muito bem-vindos à estreia da série sobre Git meu nome é Rodrigo branas e hoje no primeiro Episódio da série nós vamos fazer uma introdução ao Git e abordar os seus conceitos fundamentais bom o Git vem se tornando cada vez mais popular se a gente for analisar um gráfico de 2005 até hoje né e 2005 foi quando o Git foi e eh lançado então a gente vê uma crescente evolução Olha só em azul aqui no gráfico até hoje né então passando inclusive e eh o seu concorrente mais direto que é o apach subversion ou svn né que vem eh eh caindo aí nos últimos anos né a gente pode também ver outros concorrentes também de peso como cvs mas que também já vem ficando né para trás a um bom tempo né e o Mercurial que tá aqui em amarelo bom pessoal eh pesquisas revelam também a gente vai analisar duas aqui uma fornecida pelo Eclipse community que é de 2014 e vem aí a apontando o Git né com 33. 3 por contra 30. 7 do subversion e tem uma mais recente que é desse ano né feita pelo stack overflow que entrevistou ao redor do mundo né mais de 20.
000 desenvolvedores né e desses 20. 000 aí quase 17. 000 responderam essa pesquisa sobre e e Sistema de Controle de versão e 69.
3 tão apontando aqui o Git né como a sua opção para controlar né a a versão versão dos seus softwares em segundo vem o svn com 36. 9 e seguido por tfs mercuri ou cvs perforce entre outros tá um dado interessante é que quase 10% falaram que não usam nada então a gente começa a se questionar pô mas E por que que a gente precisa desse tipo de ferramenta né então eu vou mostrar alguns motivos pelos quais as pessoas recorrem a esse tipo de ferramenta um deles é simplesmente uma questão de armazenamento todo mundo quer tirar o código da sua máquina né para evitar qualquer tipo de desastre por isso Confiam aí num sistema de controle de versão para simplesmente e levar esse código para outro lugar tá certo bom só isso não basta né senão bastaria a gente ter um drive de rede compartilhado usar um FTP ou qualquer coisa que eu vha bom outras coisas interessantes É permitir que a gente trabalhe simultaneamente então todas essas ferramentas trazem formas de resolver conflitos bem como versionar arquivos caso eu tenha introduzido uma regressão no meu software ou queira por qualquer acessar uma versão do passado de um determinado arquivo né em todas essas ferramentas eu consigo fazer isso outra coisa legal também mas que muitas vezes é deixado de lado é contar a história do projeto então isso tá diretamente relacionado à maneira como a gente faz os nossos comites se eu comito com bastante frequência tentando agrupar esses comites em unidades lógicas que façam sentido que indiquem evolução de uma nova feature ou que indique uma correção eu consigo ter uma noção exata do que veio acontecendo no projeto Tá certo Em contrapartida se a gente deixar para comitar uma vez por semana essa história vai ficar né meio pela metade Então essa é um esse é um aspecto que envolve né até o nosso processo de desenvolvimento aí do dia a dia tá bom Por fim é muito usado para xingar quando a gente vê aquele código de baixa qualidade já vai correndo faz um show History Tenta ver quem foi o responsável né todo mundo já fez isso então esses são aí e e e fatores né que nos levam a usar esse tipo de ferr e a gente se questiona pô mas se todas essas ferramentas fazem isso de algum jeito o que que o Git tem de tão especial por que que o Git vem Ganhando esse mercado todo nos últimos anos e a resposta não tá no que ele faz mas sim como ele faz aqui vem a principal diferença Então vamos entender um pouco Quem é esse Git bom é um sistema de controle de versão foi criado pelo Linux toval então isso já traz um pouco de peso já que Como você sabe o Linus é o criador do Linux né e vem é já há bastante tempo e é conduzindo o desenvolvimento do Kernel né então ele foi criado lá em 2005 pelo seguinte havia uma disputa porque olha só até 2002 o a condução do desenvolvimento do Kernel era feita por meio de pets arquivos né E essa troca ia acontecendo em 2002 e se decidiram usar o bitkeeper Muita gente deve conhecer o bitkeeper o bitkeeper é um um sistema de controle de versão distribuído comercial muito bom diga-se de passagem E aí eles começaram a utilizar só que aconteceu o seguinte né e isso é contado Nesse artigo da pcw que fala dos motivos pelos quais né a a Beat Keeper revogou a licença né para os desenvolvedores do Kernel basicamente tinha um cara chamado Andrew Tig que é esse cara que você tá vendo aí que ele decidiu criar uma ferramenta chamada sce que interopera com Beat Keeper então com isso ele acabou entendendo em como é que o bitkeeper funcionava E isso não agradou muito a bit mover que é a fabricante que decidiu revogar essa licença então né pros desenvolvedores de Linux e tinha uma outra questão né num mercado em que você tá lutando pelo open source não faz sentido usar uma ferramenta comercial enfim com isso o Linus decide iniciar o desenvolvimento do Git tá pessoal então isso aconteceu lá em 2005 e aí desde então o Linux vem utilizando o Git tá bom bom vamos entender um pouquinho então o que que faz o Git ser tão especial Bom o primeiro ponto é que ele é um sistema de controle de versão distribuído ele não é o único né se você vê o bitkeeper Mercurial todos eles são distribuídos só que o Git Vai um pouco além tá vamos entender o que que é essa questão da distribuição vou fazer um comparativo com svn Tá mas poderia ser com cvs também ou com qualquer outro que seja Centralizado Bom basicamente as operações que você tá vendo aqui à esquerda como ah criação de um comit um merge um Branch tudo isso acontece né por meio da rede então qualquer operação que eu queira fazer acontece por meio da rede e o que eu tenho na minha máquina é só né um SnapShot é uma cópia de uma parte desse repositório então todo o histórico do repositório tá armazenado num servidor Central tá E aí eu por meio da rede faço operações de comit update entre outras tá a diferença né pro Git é que eu tenho um clone Então eu tenho uma cópia completa desse repositório remoto diga-se de passagem você não é obrigado a a necessariamente trabalhar com repositório remoto Aliás a gente só vai falar em repositório remoto em episódios posteriores Tá certo então isso faz com que eu tenha a cópia inteira local qual é a grande vantagem bom todas as operações mais utilizadas ou seja vou fazer um it né eu vou fazer um dif entre duas versões de arquivo né eu vou buscar uma alteração no passado vou fazer um log tudo isso acontece local Então eu tenho uma velocidade muito alta Tá certo eu só uso a rede no momento em que eu vou fazer por exemplo um push ou um pull que são operações que a gente vai ver em episódios posteriores né E que essas sim envolvem a rede agora A grande maioria Não envolve bom pessoal com isso o que que a gente tem de bom eu tenho um grau de segurança maior já que eu tenho Clones desse repositório espalhado em vários lugares por exemplo cada desenvolvedor da minha equipe tem um clone do repositório se alguma coisa de errado acontecer com ele eu simplesmente pego né um desses Clones e restauro o meu repositório oficial né remoto e até um servidor de integração contínua por exemplo pode est atuando como uma fonte confiável de backup já que ele constantemente faz um clone cada vez que ele vai e eh integrar cóigo ele tá sendo atualizado Então eu tenho uma outra fonte confiável então ele é seguro ele é rápido aqui tá a grande sacada né já que todas as operações que eu uso no dia a dia não envolvem necessariamente a rede isso desburocratiza bastante o processo já que por exemplo se eu trabalho num projeto open source se eu trabalho constantemente viajando ou fora do meu escritório né eu tenho muito mais tranquilidade em tá comit constantemente criando branchs fazendo merges sem envolver a rede E aí no momento em que eu tenha esse acesso aí sim eu posso fazer essa operação de push que a gente vai falar depois que é eu vou enviar minhas alterações todas pro servidor remoto pro meu repositório remoto oficial Tá certo então isso traz bastante velocidade e um outro aspecto é que ele se torna mais colaborativo já que eu posso ter múltiplos repositórios remotos não só um então eu posso trabalhar com um grupo de desenvolvedores numa feature com outro grupo de desenvolvedores em outra tudo isso sem afetar por exemplo o repositório oficial tá então isso é uma grande vantagem para projetos open source e o próprio kerno do Linux né Isso é é Dito pelo Linux em muitas palestras eh trabalha com uma ideia de rede de confiança Então você na verdade tem e os níveis mais altos dessa rede que em geral envolvem o Linux e e confiando em três em quatro outras fontes né que é de onde ele integra novas funcionalidades correções essas três quatro Fontes né tem a as suas 67 essas 67 tem as suas 89 e assim por diante montando uma espécie de árvore de confiança né uma rede toda interligada em que uns apontam PR os repositórios dos outros tá bom então o Git é extremamente colaborativo e por isso que vem sendo é é cada vez mais usado principalmente para open source né se você olhar o github é um grande exemplo disso bom agora você pode pensar pô mas clonar esse repositório inteiro será que não vai aumentar muito o meu tráfego já que e e você vai fazer um checkout às vezes de um projeto usando svn você já vê que demora um pouco imagina se eu fosse eh pegar todas as versões de todos os arquivos bom tem um caso interessante amplamente difundido que é o caso da Mozilla né então eh todo esse repositório da Mozilla incluindo branchs tags né e assim por diante tava ocupando 12 GB com svn né 3 GB com cvs contam que quando foi migrado para Git passou ocupar apenas 300 m bom eh Isso mostra que o Git é extremamente xuto tá ele e é tem várias características tá E e que o tornam enxuto se a gente for analisar os branchs as tags são apenas referências tá pro grafo então é é realmente ISO não são cópias como acontecem em outros concorrentes Tá certo isso torna mais enxuto tem também processos aí de garbage collector etc que vão contribuir ainda mais para reduzir esse espaço ocupado isso a gente vai descobrir ao longo aqui dessa série tá bom pessoal legal como é que a gente instala o Git basicamente Você vai no site baixa a versão pra sua plataforma e segue o processo com isso você vai fazer um Git version no seu terminal Favorito E aí ele vai te mostrar no meu caso aqui eu tô com a 2 32 né e e a gente vai usar bastante o terminal essa é uma parte bem interessante aqui dessa série tá bom pessoal Olha só vamos começar com a criação então de um repositório local como eu falei repositório remoto a gente vai abordar mais pra frente então a gente vai trabalhar totalmente local por enquanto tá bom já que a maior parte dos Comandos do Git são locais né não tem problema quanto a isso então eu vou começar com Git init o que que o Git init faz ele cria um repositório vazio dentro da pasta que você escolher então não importa se ela tá vazia ou se você já tem um projeto acontecendo ali simplesmente vai lá digita Git nit E aí o Git vai colocar um repositório vazio para você e você vai conseguir começar a utilizar Tá certo ele armazena essas informações dentro da pasta pon Git se eu escrever 3. Git após fazer o Git nit né Vale lembrar que essa ferramenta tem que ser instalada né ele vai te mostrar a estrutura de pastas Então olha só head branches config aqui eu tenho objects que é um diretório importante pra gente hefs então esses diretórios aqui são os diretórios onde o Git vai passar a armazenar todos os arquivos aí do seu projeto tá bom pessoal então ah mas eu quero tirar o Git do meu projeto ok deleto pon Git tá é um pouquinho diferente do svn que já coloca aqueles aquelas pastas P svn em vários diretórios aqui a gente tem isso tudo Centralizado tá bom legal agora vem o ponto fundamental bom o Git ele armazena conteúdo de um jeito muito diferente enquanto os outros pensam em arquivos né muitos fazem arquivo arquivo o Git armazena o conteúdo de uma só vez vamos entender isso da seguinte forma eu chamo isso de chaves do Castelo bom as chaves do Castelo do Git são os conceitos fundamentais por trás dos Comandos tá então a ideia não é a gente decorar Ah eu tenho que fazer um Git um Git comit depois um Git push E aí um Git status não vamos entender Qual é o impacto de cada comando e o que isso representa pro Git E assim a gente vai ter uma tranquilidade muito maior em saber exatamente o que tá acontecendo tá bom sem isso a gente não consegue entender profundamente a ferramenta a gente vai ter dificuldade aí na primeira vez que acontecer algum problema né eu vou ter que chamar o exper init da empresa para vir aí resolver né não é isso que a gente quer bom vamos entender que o Git representa evolução do código fonte por meio agora vem um ponto importante de um grafo de comites Tá certo pessoal então É como se eu tivesse aqui ó o comite a o comite b o comite c e aí você vê que é é o pai do B é o a o pai do c é o b e assim por diante então tô montando um grafo tá sequencialmente eu tô montando um grafo de comits aqui a gente vê que houve a criação de um Branch e assim por diante então o que eu quero que a gente entenda é justamente a formação desse grafo tá então passo a passo a gente vai formar esse grafo por meio dos Comandos que a gente vai aprender Tá certo vamos criar o nosso primeiro comite então juntos tá bom tô fazendo Eco a ATX Eco B BT XT você sabe que isso aí vai criar esses dois arquivos né um com a e outro com b e aí se eu fizer um Git commit tá dentro daquela pasta em que a gente fez Git nit ele vai dizer o seguinte Olha é infelizmente a.
TXT e b. txt eu não conheço então é não tem nada para comitar aí você vai começar a ficar preocupado pô Como assim você não tem nada para comitar né isso nos leva a entender uma coisa muito importante que diferencia o Git o Git tem essa área em amarelo chamada staging area tá pessoal então a a as coisas que serão comitados sempre que eu quiser comitar alguma coisa antes eu tenho que colocar essas coisas dentro do contêiner que eu tô chamando aqui de Stage in area tem chama tem gente chama de index bom vamos entender então que para colocar as coisas no contêiner eu vou usar um comando tá chamado Git ads Tá certo então eu criei arquivos modifiquei arquivos apaguei arquivos eu faço um Git ads e coloco isso dentro do contêiner para posteriormente vou fazer um Git commit tá como é que como é que eu olho dentro do contêiner tem um comando muito usado chamado Git status tá certo o Git status ele vai mostrar essas diferenças ele vai mostrar assim ó isso aqui tá fora do contêiner tá só no teu working Director isso aqui já está no seu staging area está pronto para ser comit então quando eu faço um Git status né que foi o que apareceu Antes quando eu fiz o Git commit ele não deu certo ele vai dizer olha a. txt e b.
estão em vermelho estão fora do contêiner Então você vai ter que usar Git ADS aqui ó tá vendo aqui escrito para prepará-los né para e eh um posterior comit Tá certo então Eh para que a gente não precise ficar fazendo Git ads a. txt Git AD b. txt posso fazer Git AD menos a ou menos All tá tem gente que bota ponto Então esse menos a pega todos os arquivos né que porventura estejam no teu working directory vale a pena dizer que working directory é a sua passa de trabalho é o diretório onde você se encontra tá bom E aí quando eu faço esse guit admin usar ele coloca tudo lá dentro ah mas eu não quero e e mandar um arquivo específico tudo bem você pode criar um Git Ignore para não trá-lo mais ou você pode colocar um a um e depois eu vou fazer um Git status para te mostrar o resultado então que legal fiz aqui um Git - a quando eu fiz o Git status Olha só como eles já estão em verde aqui ó e ele tá te indicando ó New file at TXT New file B TXT tá bom pessoal então eles já estão prontos pro comit e vamos entender Aonde esse negócio tá sendo armazenado né porque eu fiz um Git Eder deve ter parar em algum canto né bom se eu fizer um Trip P Git você vai ver um negócio diferente tá vendo aqui nessa pasta objects Olha só eu tenho lá 61 E aí o arquivo 7807 98 assim por diante eu tenho outra passa 78 E aí o arquivo 98 19 22 e assim por diante o Git tá trando esses arquivos tá por meio da geração de um hash tá ele usa x um para isso então ele aplicou tá esse algoritmo identificou esse hash criou o diretório armazenou e ele chama isso de um blob ele chama o Git tem diversos tipos de objetos né de controle interno do Git esse se chama blob então você vê que eu tenho dois objetos agora um com conteúdo a outro com conteúdo B um deles é 7898 o outro é meia 178 é exatamente aquilo que ele guardou a diferença é que ele crce diretórios né para melhorar a sua indexação tá bom pessoal então fiz o Git AD Agora eu tenho já a criação desses dois blobs aqui que estão gerenciados bom vamos pra frente como é que eu comito então bom eu faço então agora Git commit E aí para que você não tenha que entrar no editor para digitar mensagem você já pode emendar e fazer um menos m de message abre aspas digita mensagem de comit fecha aspas tá bom se eu fizer isso Ó que leg ó o Git falou ó beleza né então fiz o comit o comit é o A9 ae né então esses hash são importantes porque é assim que a gente vai montar esse nosso grafo tá bom e ele falou que fez a inserção dos dois arquivos at TXT e btx beleza pessoal Olha o que que mudou eu tenho agora um commit que não tem pai já que ele é o comit Inicial ele é o comit A9 ae e como é que ele se relaciona com esses dois blobs que eu acabei de criar que foi o a e o b bom Aqui tá a sacada né então a gente viu que eu tenho o objeto chamado blob eu tenho objeto chamado comit para ligar os dois eu tenho um objeto chamado Tree então todo comit aponta para uma Tree nesse caso F4 B3 você consegue ver tudo isso aí tá e com alguns comandos E aí nessa Tree eu tenho a descrição de qual é o estado tá do meu projeto naquele momento então Como se eu tivesse tirado uma foto você vê que eu não tô Traque arquivo arquivo eu tenho uma foto de tudo então ó at TXT B TXT e eles apontam aqui para esses dois blobs tá vendo Então eu tô montando esse grafo Tá bom então comit A9 ae aponta pra árvore F4 B3 que aponta para o blob 7898 que aponta para o blob 6178 assim eu monto o meu primeiro comit é assim que o Git gerencia essa informação tá bom Beleza se eu fizer um Git status agora você vai ver que não tem mais nada ele vai dizer olha não tem nada para comitar tá tudo certo tá bom então vamos seguir né e ver o comando Git log Git log é muito útil também tá então a gente viu o Git status Git status tá mostrando essas diferenças aí né de working directory staging area Git log já vai te mostrar a lista de commits já realizados então você vê que eu só tenho um que é o nosso A9 ae tá bom pessoal e eu fiz o commit esse hash aqui foi calculado levando em consideração informações do autor data de comite mensagem então é bem difícil de você reproduzir esse hash aqui tá certo isso torna o Git extremamente íntegro Tá bom vamos criar mais um comit então para fortalecer esse conceito olha só que legal Eco C ctxt então tô criando um novo arquivo chamado c.
txt vou te mostrar um Git status vou fazer um Git - a e um commit Men m tá bom vamos lá tudo junto então criei o arquivo fiz Git status você já sabe apareceu em vermelho dizendo Olha esse arquivo não está no contêiner esse arquivo não está na Stage a Então faça um Git AD - a poderia ter sido Git AD c. TXT Tá certo poderia ter sido Git AD men men all poderia ter sido Git AD ponto e aí Git commit Men M ele fez mais um comit te falou ó Legal tem agora um novo arquivo chamado c. txt né esse aqui é o 37 2D Tá comit bom vamos entender fui pra frente Olha que Fantástico então quando eu fiz esse novo comit você vê que o 37 2D que é esse último aponta para a 9ae Tá certo então assim eu vou montando esse grafo ele tem uma árvore de 1b e aqui vem a grande sacada apesar de a e b não terem sido comitados dessa vez eles estão lá então eu tirei uma nova foto e você repara que agora eu tenho at TXT B TXT e ctxt dos quais a é o 7898 que já tá lá tá apontando aqui na Linha Azul 6178 aponta para B já tava lá então tá vendo que até aqui é igual o primeiro e o segundo commit A novidade é o c.
txt que agora eu tô apontando Então por meio desses três tipos de objetos commit 3 e blob eu tô gerenciando todo o estado no meu código fonte perfeito pessoal irritantemente didático né olha só se eu fizer um Git log você vai ver que tem agora um novo commit chamado 37 2D que a gente acabou de ver e que aponta para a 9ae que é o anterior Tá bom vamos lá e se eu alterar né um arquivo vamos ver o que acontece fiz agora um Eco C2 ctxt porque basicamente eu tô modificando o seu conteúdo pra gente ver o que que acontece e fortalecer ainda mais esse conceito bom se eu fizer um Git status Você já sabe o que vai acontecer ele vai dizer Olha acho que você modificou aí o c. txt mas você não botou no contêiner não vamos lá então Git Ed - a coloquei no contêiner Git status de novo ficou em verde já tá dizendo ó tá pronto para ser comit fiz um Git commit os m alterando c. txt ele falou ó você criou o comit 7 f64 beleza vamos olhar o que aconteceu Ó lá tá lá em verde Então 7 f64 aponta para o p 37 2D ó o grafo aqui dos comits tem uma árvore chamada 6300 que tá aqui e olha que coisa legal at TXT B TXT e ctxt igual árvore em azul anterior só que repara no blob Olha só o blob anterior c.
txt era o F2 AD que tá aqui esse aqui já é 6 F9 então é esse de cima então repara como eu tirei uma nova fotografia o nome dos arquivos permanecer igual é apenas uma referência e o blob mudou então se eu quisesse voltar no tempo ó no comite anterior né você vê que seria bem fácil restaurar o estado do meu projeto naquele comite já que eu tenho a fotografia de tudo então é diferente de fazer tracking por arquivo eu tô fazendo tracking por conteúdo Tá certo então isso diferencia bastante o Git aí de outros concorrentes Tá certo então tô aqui com o meu terceiro commit né aqui no meu grafo tá se eu fizer um Git log você já sabe vai aparecer três commits Então esse último que é o 7 f64 né alterando c. txt bom mas e se eu mudar só o nome do arquivo né a gente tá vendo vários cenários né do que que vai acontecer se eu mudar só o nome né então eu vou fazer um MV c. txt para C2 TXT né até existem comandos né como Git MV Mas a gente pode fazer desse jeito também já sabe Git status vai dizer Olha você deletou Um criou outro tá untracked então faz Git AD Men A para botar no contêiner né Ir para staging area Git status pra gente ver o que aconteceu e faça um Git commit Bom vamos lá fiz o status ele falou olha como ele já detectou cara é rename porque já ten um blob com exatamente aqueles bytes eu tenho xa um eu sei exatamente que hash é aquele Então eu tenho 100% de certeza que você fez rename não é m difícil saber né Aí você vai dizer assim pô mas será que esse chá um é confiável né ó extremamente né tem o Scott sheon que é um dos caras aí do github que tem bastante palestra bastante treinamento no no YouTube e escreveu o livro chamado prit ele tem uma sacada muito legal que ele fala o seguinte né Pela estatística né da probabilidade de colisão né no algoritmo xa um ele disse o seguinte olha se todos os habitantes da terra né prograss e criassem um código fonte equivalente ao kerna do Linux por segundo em do anos essa chance seria de 50% então ele conclui dizendo que olha mais fácil que toda a sua equipe seja morta né em ataques por Lobos né ataques não relacionados na mesma noite do que haver uma colisão desses índices tá bom pessoal então ele deu 100% aqui tá show de bola então Ó que legal novo comite aqui em rosa você tá vendo Então que é o b2 74 tá bom esse B2 74 aponta para a 7f 64 que é o anterior Olha o grafo aqui dos comites e no Tree ele tem o mesmo blob do anterior tá vendo em verde aqui eu tenho 16 F9 e agora eu continuo tendo 16 F9 é o mesmo só que o que que mudou a referência o nome do arquivo Tá certo então quando você fizer né e e e um checkout aqui desse código do repositório você vai ver que ele vai botar C2 P TXT se você pegasse o comite anterior ele botar c.
