Git e GitHub: guia rápido de controle de versões com Git

Git e GitHub: guia rápido de controle de versões com Git

Entenda os conceitos básicos de controle de versões com Git e a hospedagem de repositórios com GitHub. Aprenda sobre branches, commits, merges e pull requests de forma prática.

Por que usar Git e GitHub?

Em equipes de desenvolvimento, diferentes mudanças ocorrem simultaneamente. Git gerencia o histórico, facilita a colaboração e permite retornar a estados anteriores, além de permitir a combinação de alterações de diferentes ramos.

1. Resumo dos tópicos abordados

  • Conceito de controle de versões: registrar mudanças em programas e documentos ao longo do tempo.
  • Git: sistema de controle de versões distribuído e de código aberto; Rastreamento de alterações, histórico e ramificações.
  • GitHub: serviço de hospedagem de repositórios na nuvem para colaboração em equipe.
  • Estrutura do repositório local: diretório de trabalho, área de staging (index) e HEAD.
  • Fluxo básico: criar repositório local, adicionar arquivos, fazer commit com mensagens significativas.
  • Branches (ramificações): criar, alternar entre ramos e mesclar mudanças; gestão de conflitos.
  • Trabalho remoto: origin, push, pull, fetch, e pull requests para integração com o repositório principal.
  • GitHub Flow: colaborar via pull requests, revisar código, merge e sincronização entre repositório local e remoto.
  • Boas práticas: mensagens de commit significativas, organização de branches, revisões por pares.

2. Explicação detalhada de cada tópico

2.1 Controle de versões

Controle de versões é um conjunto de ferramentas que registra alterações em arquivos ao longo do tempo, permitindo reverter para estados anteriores, comparar mudanças entre versões e entender quem modificou o quê e quando.

Exemplo: você trabalha num projeto com código-fonte. Cada mudança é registrada, criando um histórico que facilita a rastreabilidade.

2.2 Git vs. GitHub

Git é o sistema de controle de versões (local), enquanto GitHub é um serviço de hospedagem de repositórios na nuvem que facilita colaboração, ainda mantendo o histórico no Git.

2.3 Estrutura de um repositório Git

- Diretório de Trabalho: onde você edita os arquivos.
- Área de Preparação (Index): onde você adiciona alterações que vão para o commit.
- HEAD: aponta para a última confirmação (commit) no branch atual.

Processos comuns: criar repositório, adicionar arquivos, verificar status, fazer commit com mensagens claras.

2.4 Fluxo básico de trabalho

Um fluxo típico é: 1) Criar repositório local (git init).
2) Adicionar arquivos (git add).
3) Confirmar mudanças (git commit -m "mensagem").
4) Criar um branch para desenvolver uma nova funcionalidade (git checkout -b meu-branch).
5) Alterar código, adicionar e commitar novamente.
6) Enviar alterações para o repositório remoto (git push origin meu-branch).
7) Abrir um pull request para mesclar com a branch principal.

2.5 Branches e merges

Branches permitem desenvolver em paralelo sem afetar a branch principal. É comum criar um branch por feature, corrigir bugs, etc. Mesclar (merge) reúne mudanças de um branch no outro. Conflitos podem ocorrer quando duas alterações conflitam; então, é preciso resolvê-los antes de finalizar o merge.

2.6 GitHub e pull requests

GitHub facilita a colaboração: você envia alterações para um branch remoto, cria um pull request para pedir a revisão e, após aprovação, o proprietário do repositório pode mesclar o branch no branch principal.

2.7 Boas práticas

- Mensagens de commit descritivas e significativas.
- Dividir grandes mudanças em commits menores e coerentes.
- Usar branches para cada tarefa ou feature.
- Revisão de código por pares via pull requests.

Exemplo prático

Suponha que você tenha iniciado um repositório, criado um arquivo test.py, fez commit e criou um branch "feature-x" para adicionar uma nova função. Em seguida, você enviou o branch para o GitHub e abriu um pull request para mesclar com a branch principal. A equipe revisa, comenta e, se tudo estiver ok, aceita o pull request, ocorrendo o merge.

3. Mapa mental (mermaid)

mindmap root((Git e GitHub)) local(Repositorio local) working(Diretório de Trabalho) index(Área de Preparação) head(HEAD) remoto(Remoto) origin(Origin) push(Push) fetch(Fetch) pull(Pull) branches(Branches) criar(Criar Branch) switch(Alternar Branch) merge(Merge) github(GitHub) repos(Repos na nuvem) colaboracao(Colaboração) pr(Pull Requests)

4. Questões sobre o assunto

Questão 1 (valor: 1.50) - Qual comando inicializa um repositório Git local?

Resposta correta: A) git init

O comando git init cria um repositório Git vazio em um diretório existente.

Questão 2 (valor: 2.50) - Qual comando envia alterações para o repositório remoto?

Resposta correta: C) git push

O git push envia commits do repositório local para o remoto.

Questão 3 (valor: 2.50) - Qual é a principal finalidade de um branch no Git?

Resposta correta: A) Manter uma linha de desenvolvimento paralela

Branches permitem desenvolver recursos separadamente sem impactar a branch principal.

Questão 4 (valor: 3.50) - Ao abrir um pull request, quem geralmente revisa e aceita as alterações?

Resposta correta: B) O proprietário do repositório

Normalmente, o dono ou mantenedor do repositório revisa o pull request antes de aceitar o merge.

Pontuação Total 0.00

Texto original

O texto original pode conter falhas de gramática ou de concordância, isso ocorre porque ele foi obtido por um processo de extração de texto automático.
Texto extraído do video Algoritmos e Programação de Computadores II - GIT e GitHub

O Lá pessoal, me enviamos novamente a nossa disciplina de algoritmos e programação de computadores 2 para o universo.
Esta é a videoaula de número 21, nossa última videoaula dessa disciplina.
Nesta aula, a gente vai ver alguns conceitos sobre Git and GitHub, que são ferramentas bastante úteis, bastante interessantes para fazer gerenciamento de versões de programas, de desenvolvimento de programas.
Então, o conceito bastante relacionado ao controle de versões, que são ferramentas que gerenciam mudanças em programas de computador, e até mesmo em outros documentos, como documentos textuais, o websites, entre outros tipos de documentos, que podem ser controlados ao longo do seu desenvolvimento, da sua criação e modificação.
Imagina que você trabalha num time de desenvolvedores que estão atuando no mesmo software, cada desenvolvedor realiza uma alteração de área no programa, e isso é feito em paralelo entre todo o time.
Então, como é feito o gerenciamento dessas mudanças? Então, por exemplo, se um desenvolvedor faz uma alteração que acarreta em conflito, com uma alteração de um outro desenvolvedor, como que você reverte essas alterações? Como você pode, por exemplo, a partir de uma versão atual, que está um defeito, retornar para uma versão anterior, ou seja, você obteu histórico de alterações que foram efeitas ao longo do desenvolvimento do programa, de você manter esse controle de alterações.
Então, com esses controles de versões, essas ferramentas, é possível rastrear as alterações do código, saber qual foi a alteração, em qual momento, por quem é em qual o arquivo.
Também é possível combinar diferentes atualizações.
Por exemplo, se você fez uma alteração e seu colega fez uma alteração, as duas alterações estão ok, elas não interferem em uma ou outra, então você pode atualizar e combinar essas mudanças numa versão nova.
Aqui, eu tenho nessa figura um exemplo de diferentes caminhos, que o desenvolvimento de um arquivo, de um programa pode tomar.
Por exemplo, imagina que eu tenho uma versão inicial de um programa, você pode fazer com que um determinado desenvolvedor faça alterações numa sequência de alterações que são feitas no seu programa.
E se essas alterações forem feitas com sucesso, se elas gerarem um resultado plausível, você pode, depois, incorporar essas alterações lá na versão principal do teu programa.
Você pode fazer diferentes caminhos desses, então, por exemplo, enquanto que uma um time trabalha numa alteração ou outra time trabalha numa outra alteração, e em cada caminho desse, a cada equipe dessa vai fazer suas devidas alterações lá no teu, no, no, em cada uma das visões, que esses xinis fazem.
E em algum momento, futuros essas alterações podem acabar combinadas, sendo, ser combinadas na versão final lá do teu software.
Em algum momento, também pode ser que uma determinada, um determinado caminho de desenvolvimento não gere resultados satisfatórios e você simplesmente descontinua aquelas alterações que foram feitas ao longo daquele caminho.
Bom, cada caminho desse é chamado de branch, que é um ramo, vamos dizer assim, e você pode ter diferentes ramos ou diferentes branches ao longo do teu repositorio.
E você pode fazer criar novos branches ou fazer a combinação de dois ou mais branches em um só entre várias outras coisas que podem ser realizadas.
Então, a partir daí, a gente vê que a gente pode falar sobre o Geet e o Geet RAM.
Qualquer diferença entre eles, tão Geet é um sistema de controle de versões que é código aberto, ele permite gerenciar e arrastrear o histórico de alterações no código, existem várias outras ferramentas parecidas com Geet, como o SVN entre várias outras, o Geet é apenas uma delas.
E o Geet RAM, pessoal, é um serviço de armazenamento de repositórios.
Isso é feito em armazenamento na nuvem, na internet, e permite fazer o armazenamento e gerenciamento de repositórios que foram criados por meio da ferramenta Geet.
Então, a gente vai ver um tutorial bem rápido de como a gente trabalha, faz as principais funcionalidades, tarefas, tanto no Geet como no Geet RAM.
Então, a primeira coisa que a gente tem que fazer é certificar que o Geet está instalado no nosso computador.
Então, para isso, existia esta página aqui de download da ferramenta Geet e aqui a gente tem o URL referente à criação de uma conta lá no Geet RAM.
Então, qualquer um pode criar uma conta no Geet RAM, você pode armazenar os seus repositórios lá livremente, a única requisito é que esses repositórios têm que estar disponíveis, têm que estar liberados para outras pessoas poderem acessar também.
Então, aqui eu tenho uma página do Geet, então você pode escolher o seu sistema operacional e fazer o download do Geet para poder instalar na sua máquina.
E aqui eu tenho a página de criação de uma conta no Geet RAM.
Uma vez que você cria a sua conta, você vai logo e você vai ter uma página parecida como um S.
Então, aqui eu tenho o meu nome de usuário, você pode ter aqui os seus repositórios, criar um novo repositório e assim por diante.
Então, primeiro passo que a gente vai fazer é criar um repositório Geet local na nossa máquina.
Então, isso ainda sem considerar nada sobre o Geet RAM.
Então, eu vou criar.
.
.
Vou abrir aqui o meu terminal.
Aqui dentro eu vou criar uma pasta que eu vou chamar aqui de Geet, exemplo.
Então, ali dentro eu vou entrar nesta pasta e dentro desta pasta eu vou especificar que eu quero que essa pasta seja um repositório local Geet.
Então, para isso eu chamo o comando Geet e Geet.
Então, aqui agora essa pasta acabou se tornando um repositório Geet local na minha máquina.
Bom, o segundo passo, pessoal, é a gente adicionar arquivos nesta pasta.
Então, são os arquivos do seu projeto, os códigos fontes, arquivos de documentação e assim por diante.
Então, eu vou criar um arquivos simples aqui, eu vou chamar de test.
pi.
Neste arquivo eu vou simplesmente declarar aqui uma variável A, igual a 2, B, E igual a 3, e vou mandar a imprimir a mais B.
Simplesmente isso, nada muito além.
É um arquivo de Python, que pode ser executado.
Então, aqui eu posso executar Python test, que vai retornar 5, 2, mais 3.
E a partir daí eu posso verificar os status do meu repositório.
Reparem que quando a gente chama esse comando Geet status, ele fala para a gente que o arquivo que existem arquivos que não estão rastreados.
E isso a gente altera por meio de um comando específico, que eu vou falar daqui a pouco.
Só que antes disso é importante a gente verificar como funciona o fluxo de trabalho desta ferramenta Geet.
Então, o repositório local consiste em três árvores que são mantidas pela ferramenta.
A primeira é o diretor de trabalho, que é aquele diretor que a gente acabou de criar.
A segunda é chamada de index, que funciona como uma área temporária.
E a terceira chamada de red é ela ponta para o último comite ou para a última conformação que você fez lá nas alterações do seu programa do seu projeto.
Para a gente poder transformar aquele arquivo que a gente acabou de criar, mandar ele para a área temporária, que daí a partir daí ele vai ser confirmado com uma alteração, a gente chama o comando GeetEd.
Então, no nosso nosso pasta aqui, eu vou chamar GeetEd e o nome do arquivo que ainda está não rastreado.
Fiz isso, agora eu chamo de novo os status do Geet.
Reparem que agora ele identifica o novo arquivo como novo e ele já está rastreável.
A gente já consegue fazer a conformação dele ou a inserção dele na árvore red do nosso repositório.
E para isso a gente chama o comando comite.
Então a gente chama GeetEd comite, menos M e uma mensagem indicando para que serve aquele comite ou qual for as principais alterações que foram feitas naquele.
.
.
naquela conformação.
Então eu posso fazer isso aqui, então vou chamar Geet comite, menos M, eu vou colocar aqui a criação do arquivo test.
pips.
É sempre importante a gente colocar mensagens que sejam significativas, porque outras pessoas vão poder acessar esse repositório e visualizar quais foram as alterações.
Que foram executadas com aquele comite.
Então o arquivo já foi comitado e aí a gente consegue verificar com os status que não há nada para comitar, para confirmar.
E a gente está, reparem que aqui a gente está no Brent Master.
O Master é o Brent principal que é criar automaticamente quando a gente inicializa o repositório.
A gente pode também criar outros branches, quer dizer, imagina que você está no repositório no Brent principal e o teu colega ele vai querer fazer alguma alteração no programa, sendo que pode ter algum conflito com o que você está fazendo.
Então o que você pode fazer? Você pode criar um novo Brent para ele e ele vai fazer as alterações que ele quiser lá naquele Brent.
E depois, dependendo, é possível você fazer o merge desses branches no final caso não exista nenhum conflito entre as duas versões.
Então para isso a gente vai executar o comando Geat Checkout, menos B e o nome do novo Brent.
Não por exemplo, Brent.
Então ele já criou o novo Brent e para a gente visualizar quantos brentes a gente tem, quais são os brentes que a gente tem, a gente executa Geat Brent.
E ele vai informar para a gente que existem dois brentes, o que a gente acabou de criar, que é o que estou atualmente e o Master que é o que eu tinha antes que é o principal.
D'aquí se eu fizer alguma alteração novamente no nosso arquivo test.
px, não reparem que estou no Brent, tá? Brent 1.
Então eu vou abrir novamente o arquivo.
Ali dentro eu vou fazer uma alteração, por exemplo, para, em vez de ser mais, eu vou colocar vezes.
Vou sair, vou verificar os status, reparem que foi feito uma modificação em test.
Aqui é necessário como a gente está no novo Brent, é necessário a gente adicionar também esse arquivo novamente para a área temporária.
Agora verificando e agora vou fazer o comit, mudança de soma para multiplicação.
Só que vejam pessoal, que eu estou no meu Brent 1, tá? Então se eu mudar para o Master, para eu vou fazer um check out.
E agora se eu abrir novamente o arquivo test.
px, reparem que o arquivo não foi alterado, tá? Então ao invés de ser vezes, ele continuou como mais aqui em cima.
Isso significa que alteração foi feita apenas no Brent 1, tá? Que é o que a gente fez aqui em cima, que a gente comitou, tá? E quando a gente voltou para o Master, o arquivo estava em alterado, tá? Legal? A gente vai criar um novo repositor no GitHub para poder colocar as alterações no repositor local, lá no serviço de armazenamento na nuvem.
Então para isso eu vou, na minha página principal do meu GitHub, vou clicar aqui em novo o repositor.
Aqui eu vou especificar o nome do meu repositor, vou chamar de test.
E aqui eu tenho algumas opções, por exemplo, eu quero adicionar um arquivos dados de um repositor local para esse repositor do GitHub.
Então eu vou executar essas instruções que estão aqui embaixo.
Então eu vou executar a git, remote, ad e a URL referente a esse repositor que foi informado para a gente quando a gente criou aqui o repositor lá no GitHub.
Aqui falta um origem.
Então depois disso a gente pode agora mandar os nossos dados lá para o repositor.
Repare aqui, eu estou no meu Master e a gente vai enviar as alterações deste brainter lá para o GitHub.
Então vou executar a git, push, quer dizer, eu vou enviar passando o meu usuário, origem e o nome do brainter que eu estou.
Então ele enviou os dados lá para o GitHub, tanto é que se eu vim aqui agora na minha página e atualizar a página, e agora aparece aqui o arquivo peste.
pips, e aqui eu tenho o brainter que eu estou, que é um Master.
Se eu quero enviar os dados do outro brainter, do brainter, que a gente já tinha, a gente faz a mesma coisa.
git, push, menos o origem e aqui o nome do brainter que a gente quer enviar.
Então atualizando, reparem que agora eu tenho dois branches, Master e o brainter um, aqui a gente consegue alterar entre os dois, reparem que no brainter um, se a gente clica no test.
pips, a gente consegue ter acesso ao arquivo.
E aqui veja que está a multiplicação, que é exatamente o que a gente fez anteriormente.
Existem outras funcionalidades, gente, de utilização do GitHub, como por exemplo criar um pull request, quer dizer, você pedir pro dono de um repositoro para incorporar algumas alterações que você fez.
Combinar um pull request, que é juntar as alterações de um pull request com o brainter principal, entre outras coisas também que são possíveis de ser realizadas usando o git e o git hook.
Bom, o básico é isso, com isso vocês já podem fazer bastante coisa e mais informações vocês podem olhar nas nossas referências.
Espero que vocês possam ter compreendido o funcionamento dessas ferramentas de controle de diversão.
Agradeço a atenção de vocês nessa disciplina e a gente se vê numa próxima oportunidade.
Muito obrigado e até lá!