Resumo GIT e GITHUB
Resumo compilado das aulas de GIT e GITHUB da DIO e StartSe
O formato usará o resumo das aulas da StartSe, porém como a DIO abordou questões importantes de segurança, então esse conteúdo será acrescentado. StartSe Aula 1 Introdução
Principais controladores de versão
Apache Subversion"Enterprise-class centralized version control for the masses" Welcome to subversion.apache.org, the online home of the Apache® Subversion® software project. Subversion is an open source version control system. Founded in 2000 by CollabNet, Inc., the Subversion project and software have seen incredible success over the past decade.https://subversion.apache.org/
Mercurial SCMMercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface. It is fast and powerful Mercurial efficiently handles projects of any size and kind. Every clone contains the whole project history, so most actions are local, fast and convenient.https://www.mercurial-scm.org/
Controle de versão
- Nos dá uma linha do tempo do projeto (Timeline).
- Trabalha com alteração de estados do arquivo.
- Cada estado, chamamos de snapshot.
- Cada mudança realizada em um arquivo aumenta a sua versão.
- Podemos ter modificações paralelas.
- Possibilita recuperação para qualquer estado anterior.
- Podemos comparar documentos com características diferentes.
Aula 2 Configuração do ambiente
Instalação e documentação :
DocumentationThe entire Pro Git book written by Scott Chacon and Ben Straub is available to read online for free. Dead tree versions are available on Amazon.com.https://git-scm.com/doc
DownloadsGit comes with built-in GUI tools ( git-gui, gitk), but there are several third-party tools for users looking for a platform-specific experience. View GUI Clients → Various Git logos in PNG (bitmap) and EPS (vector) formats are available for use in online and print projects.https://git-scm.com/downloads
GitHub DesktopCheckout branches with pull requests and view CI statuses See all open pull requests for your repositories and check them out as if they were a local branch, even if they're from upstream branches or forks. See which pull requests pass commit status checks, too!https://desktop.github.com/
PDF e material
Para ver se o git está instalado e a versão:
git version
Vamos realizar a configuração do git bash
#Vamos abrir o git bash
#Para configurar o nosso nome:
git config --global user.name "Hugo"
#Para configurar o email:
git config --global user.email "hugodiscord@outlook.com"
#Por configurar a branch
git config --global init.defaultBranch main
#OBS
#->Para saber se as configurações estão setadas use:
git config --list
Após abrir o diretório que queremos, vamos controlar a versão com git
#O comando para iniciar o git a partir do diretório é:
git init
Aula 3 Aula Ciclo de vida dos arquivos, commits e branches
Git possui 4 status (ciclos) para arquivos
- Untracked → O git não conhece a existência do arquivo em nenhuma versão (Default).
- Staged → Arquivos que estão prontos para serem inseridos em um novo estado da aplicação (Novo Snapshot).
- Unmodified → Indica arquivo que não sofreu nenhuma modificação em relação a ultima versão.
- Modified → Indica arquivos que sofreram alteração em relação a ultima versão.
Comando para ver o status dos arquivos
#Num primeiro momento todos os arquivos estarão como untraked
git status
Comando para adicionar o arquivo para estado 2 Staged
#Para subir arquivo especifico:
git add nome_do_arquivo
#Caso a intenção seja adicionar todos, vamos usar o *
git add *
#OBS
#Podemos voltar o arquivo para o estado anterior com:
git reset nome_do_arquivo
Comando para adicionar para o estado 3 Unmodified
#Vamos fazer um comentario indicando a mudança realizada com:
git commit -m "comentario_entre_as_aspas"
Para verificar os commits realizados no nosso código vamos usar:
#Comando para verificar quantidade de commits e as branchs utilizadas.
git log
Branch
Para criar nova branch:
git branch nome_da_branch
Para alterar a nossa branch de trabalho usaremos
git checkout nome_da_branch
Para associar o trabalho da branch que criamos a linha do tempo principal usamos:
git merge nome_da_branch
Aula 4 Branches na prática
Observações:
- Quando criamos uma branch o projeto será salvo na posição que estamos.
- Todas as modificações geradas numa branch são ignoradas por outras.
Para sabermos em qual branch estamos usamos :
#Esse comando vai mostrar a branch que estamos trabalhando.
#Também demostra todas as oturas banchs criadas no projeto.
git branch
Para subirmos a modificação da branch para a principal vamos usar:
git merge Nome_da_branch
#OBS:
#Quando fazermos um merge o git gera um commit automático informando a mudança.
#O commit será aberto no editor de texto para editarmos.
#Caso a nossa mudança impact alguma funcionalidade, o git irá nos informar.
#Em caso de impacto, teremos a opção de escolher o que será mantido/descartado.
Para deletar uma branch vamos usar:
git branch -d nome_da_branch
#OBS
#Geralmente depois de cumprida a finalidade, deletamos a branch
#Geralmente não fazemos commits da branch main diretamente.
Aula 5 Reset e diff na prática
DIFF
- Vai mostrar a diferença entre o arquivo atual e o estado anterior.
Lembrando que o comando funciona em arquivos em staged (Quando foi feito o “git add”).
Para vermos a diff entre arquivos usamos:
#Nesse caso vamos ver todas as diferenças realizadas (Multiplos arquivos).
git diff
#Neste outro caso vamos ver as modificações de apenas um arquivo.
git diff nome_do_arquivo
Para voltarmos ao estado anterior a modificação vamos usar:
#Iremos indicar o nome do arquivo para voltarmos ao ponto anterior a mudança.
git checkout nome_do_arquivo
Reset
- Usado para voltar para o estagio anterior
- Pode ser usado de forma diferente dependendo do estado do arquivo.
Uso do reset na fase “staged” (Depois do “git add”)
#Caso tenhamos deixado passar mudança para staged vamos ter de resetar o estado
#O comando para reset para estado anterior é:
git reset nome_do_arquivogit reset nome_do_arquivo
Uso do reset na fase “unmodified” (Depois do “git commit”)
1° - Termos que copiar o id do commit anterior antes de realizar o reset.
#Vamos pegar o id do commit anterior com:
git log
#Depois de aparecer todos os IDs, vamos copiar o que queremos voltar.
Aqui vamos ter 3 formas diferentes de reset:
- Reset soft (Podemos fazer commit novo)
#Volta po arquivo para fase de staged git reset --soft nome_do_commit_anterior
- Reset mixed (Podemos fazer novo git add)
#Volta o arquivo para fase de modified git reset --mixed nome_do_commit_anterior #Podemos fazer a diff da modificação com o conteúdo anterior #Antes de fazer o "git add"
- Reset hard (Desfaz tudo e volta ao estado do commit anterior)
#Vai desfazer qualquer mudança realizada desde o commit anterior. git reset --hard nome_do_commit_anterior
Aula 6 GitHub, Gitlab e bitbucket
Páginas úteis
GitHub: Where the world builds softwareGitHub is where over 83 million developers shape the future of software, together. Contribute to the open source community, manage your Git repositories, review code like a pro, track bugs and features, power your CI/CD and DevOps workflows, and secure code before you commit it.https://github.com/
The One DevOps Platform | GitLabKeep everyone synchronized with powerful planning tools, regardless of your process. Whether your methodology is Waterfall or DevOps, GitLab's simple and flexible approach to planning helps you stay organized and track progress. Now you can ensure teams are working on the right things at the right time, and maintain end-to-end visibility and traceability of issues throughout the delivery lifecycle - from idea to production.https://about.gitlab.com/
Bitbucket | Git solution for teams using JiraBitbucket Cloud is a Git-based code and CI/CD tool optimized for teams using Jira.https://bitbucket.org/
Podemos mandar nossas modificações locais para um repositório na nuvem
![](https://i.imgur.com/VGCtWWg.jpg)
Aula 7 GitHub na Prática
Aqui vamos criar um repositório no GitHub para trabalharmos com o projeto na nuvem.
Para conferir se inserimos corretamente o repositório
#Para apenas ver os repositórios remotos adicionados usamos:
git remote
#Para verificar o caminho dos repositórios adicionados vamos usar:
git remote -v
Agora vamos enviar nossos arquivos locais para o repositório GitHub
#Vamos usar o comando abaixo:
git push nome_do caminho branch_que_queremos_mandar
#No nosso caso fica:
git push origin main
#OBS
#Temos a opção de salvar o caminho automaticamente
git push -u origin main
#Após salvar, apenas com o push já enviaremos os arquivos automáticamente.
Caso a gente queira pegar os arquivos do projeto da nuvem
#Lembrando que temos que pegar a URL do projeto na guia "code" no GitHub.
git clone url_do_projeto
#Todos os commits e branchs irão ser carregados também.
Aula 8 Pull e Push na Prática
Git push
- Usado para enviar arquivos para o repositório do projeto
#Relembrando a forma de subir os arquivos
git push caminho_do_repositório branc_que_queremos_mandar
Git pull
- Usado para pegar atualizações feitas no projeto (de todas as branches)
#Para pegarmos atualizações futuras feitas no código vamos usar o pull
git pull caminho_do_repositório branc_que_vamos_receber
#Vamos receber as alterações, todas as branchs e commits feitos no repositório.
Aula 9 Git Merge e Rebase
Observação:
Merge e rebase são usados para unir branches
Merge
Aula 10 Merge e Rebase na Prática
Para trabalhar com as branches
#Para criar
git branch nome_da_branch_nova
#para trocar de branch
git checkout nome_da_branch
#Para visualizar a branch que estamos trabalhando
git branch
#Para voltar para a branch anterior
git checkout -
#Para criar uma branch e já mudar para ela vamos usar:
git checkout -b nome_da_branch
Para visualizarmos o fluxo dos merges e rebase vamos usar:
#Esse comando ira mostrar um log mais completo com linha do tempo na esquerda.
git log --graph
Merge
- Acaba criando novo commit para nos informar que foi feito mudança e que ela foi enviada para nossa linha do tempo principal.
#Lembrando o comando para mergiar
git merge nome_da_outra_branch
Rebase
- Após criar uma nova branch, fazemos um rebase com a branch “main” para atualizar a nossa time line. Vai trazer tudo na ordem cronológica.
- Rebase é mais usado em branches separadas (Não usar na nossa main)
#Para fazer um rebase de informações para a branch que estamos vamos fazer:
git rebase nome_da_outra_branch
Aula 11 Stash na Prática
Observações:
- Usado para salvar o estado do nosso projeto na area temporária.
- O stash será salvo na branch que realizamos a modificação.
Exemplo de uso do stash
#Salvará as alterações na area temporária.
git stash
#OBS:
#Também podemos incluir arquivos untracked no nosso stash. Ficaria:
git stash --include-untracked
Para consultar a lista com conteúdo stash salvos usaremos:
#Aqui teremos acesso a todas os "stash" salvos.
git stash list
Para incorporar as alterações temporárias vamos usar:
#Pegando as modificações da area temporaria
git stash aply
Para limpar a lista temporária vamos usar:
#Limpando lista dos "stash's"
git stash clear
Aula 12 Conhecendo o .gitignore
Paginas úteis
GitHub - github/gitignore: A collection of useful .gitignore templatesThis is GitHub's collection of file templates. We use this list to populate the .gitignore template choosers available in the GitHub.com interface when creating new repositories and files.https://github.com/github/gitignore
Git - gitignore DocumentationA gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details. Each line in a gitignore file specifies a pattern.https://git-scm.com/docs/gitignore
Observações:
- Delimita arquivos que não serão enviados para o repositório do nosso projeto
- O nome do arquivo deve ser posto dentro do documento “.gitignore” para ser ignorado.
Primeiro vamos ter de criar um arquivo dentro da pasta que estamos
#O nome do arquivo vai ser ".gitignore" (Sem apastas)
#No terminal fica:
touch .gitignore
#Também podemos criar direto do VS code com botão direito "new file".
Agora é só adicionar o nome do arquivo dentro do arquivo criado anteriormente.
#Se for pelo terminal fica:
vim .gitignore
#Também podemos fazer isso de forma facilitada pelo VSCode
Aula 13 - Git Revert na Prática
Observações:
- Desfaz a alteração na time line principal.
- Mantem a alteração na branch de origem.
- Geralmente usamos para desfazer algo na branch main.
Podemos visualizar os commits com:
#Revisando
git log
Para visualizar a mudança realizada em detalhes pelo commit vamos:
#Depois de copiar o commit no git log, iremos usar:
git show nome_do_commit
#Será mostrada toda modificação que foi gerada.
Para reverter vamos fazer
#Pegamos o id do commit que queremos reverter
git revert nome_do_commit_para_reverter
Aula 14 Workflows com Git
Observações:
Possibilita rotina de trabalho mais consistente e produtiva.
Temos 3 fluxos de trabalho diferentes
1 - Centralized
2 - Feature branch
Aula 15 - Workflow Centralizado na Prática
Observação:
- Neste modelo de trabalho, precisamos sempre prezar pela organização da timeline.
- Antes de fazermos push, vamos ter de fazer um pull pra organizar a cronologia do nosso trabalho (Importante !).
Primeiro vamos organizar a nossa timeline
#Nosso commit vai ficar no topo sempre.
git pull orgin main --rebase
Depois de organizada, vamos fazer o push dos nossos commits
#Lembrando o comando visto anteriormente:
git push origin main
Aula 16 Pull Request e Feature Branch na Prática
Pull requests (PR)
- Solicitação de merge de uma branch em outra branch.
- Geralmente usada para passar conteúdo de uma branch nossa para a main do nosso repositório remoto.
- O processo de solicitação request permite que a modificação do código passe por uma avaliação antes do merge.
Fases até o pull request
- Vamos criar uma branch da funcionalidade e fazer as mudanças.
- Vamos fazer o git add e depois fazer o commit da mudança.
- Vamos fazer o pull para o repositório remoto informando a branch
git push nome_do_rep_remoto nome_da_branch_que_queremos_enviar
- Agora vamos ir na página do projeto e clicar no pool request
- Na página de request, vamos informar pra qual branch estamos querendo mandar o conteúdo.
- Podemos fazer uma descrição do request e comentar o que foi feito
- Podemos marcar os revisores do código (Na opção a direita).
- Podemos fazer sugestão para melhoria dos requests
Aula 17 Resolvendo Conflitos na Prática
No conflito temos 3 opções:
Accept both changes
- Vai incluir as 2 modificações paralelamente.
Accept incoming changes
- Vai aceitar a melhoria proposta pela outra branch.
Accept current changes
- Vai aceitar a melhoria proposta pela branch que estamos.
Após fazer a escolha da melhor opção vamos ter de fazer o git continuar
#Se for rebase vamos usar
git status
- Precisamos adicionar o conflito no staged antes de prosseguir
#Adicionando arquivo git add nome_do_arquivo_com_conflito
Depois de adicionar, vamos ter de continuar com o rebase ou merge
Se o conflito for no rebase vamos usar:
git rebase --continue
Se o conflito foi no merge vamos usar
git merge --continue
- O código do conflito pode ser analisado separadamente e reincorporado caso necessário.
Aula 18 Adicionando o site no Github Pages
Observações:
- Podemos hospedar nosso projeto para gerar link externo.
- Só consigo hospedar projetos que contem HTML, CSS e JavaScript
A base do link fica: id_do_usuário_+.github.io+nome_do_projeto
DIO
Tópicos fundamentais para entender o funcionamento do Git
- Entendendo como o Git funciona por baixo dos panos.
Sha1
A sigla SHA significa Secure Hash Algorithm, que é um conjunto de funcões hash criptográficas projetadas pela NSA (Agência Nacional de Segurança dos EUA) Essa encriptação gera um conjunto de caracteres identificadores com 40 dígitos.
![](https://i.imgur.com/PpMbpLh.png)
- Exemplos práticos de Sha1 Vamos criar um bloco de notas com o nome texto. E dentro desse desse bloco de notas, vamos escrever “Olá, meu nome é Hugo”
Agora vamos gerar a chave criptográfica do bloco de notas com o comando “openssl sha1” O comando será escrito da seguinte forma:
Então é gerado uma chave criptografada do arquivo de texto no estado atual.
E se mudarmos o arquivo? Vamos adicionar uma excalamação no final, deixando “Olá, meu nome é Hugo!”
Vamos usar novamente o comando:
openssl sha1 texto.txt
Com isso podemos ver que uma chave diferente foi gerada. devido ao ponto de exclamação no final que alterou o estado do arquivo.
Novamente gera uma chave diferente.
![](https://i.imgur.com/nE24Op4.png)
Então se eu mudar de volta para o estado inicial do primeiro exemplo, a chave de identificação volta ao mesmo estado também.
Gerando chaves SSH e Token
- Chave SSH A chave SSH é a autenticação da sua máquina no Github, você gera uma chave SSH para declarar a sua máquina para o seu perfil no Github como máquina confiável. Ideal para maquinas pessoais ou máquinas que somente você usa em uma empresa, pois não pede autenticações de senha durante o uso do Git e Github em conjunto. Tornando o processo mais fácil e até mais seguro do que digitando a senha durante o uso. Como gerar a chave?
ssh-keygen -t ed25519 -C hugodiscord@outlook.com
Observações: O ed25519 é o tipo de criptografia de segurança usada na chave, há outros tipos criptografias usados como o ed448 por exemplo, mas a mais usada, mais atual e considerada mais segura é a ed25519. O Email é o do Github. E o -C é usado maiúsculo mesmo.
![](https://i.imgur.com/gNkO39B.png)
Essa parte será digitavel, é onde você poderá escolher o local/repositório onde a sua chave vai ficar armazenada. Caso aperte Enter sem digitar nada, ela irá para o repositório padrão conforme o ilustrado na imagem.
Se for mudar o diretório, é ideal que saiba o que está fazendo. Por enquanto faremos o procedimento na pasta padrão mesmo.
O .ssh com espaço e ponto antes do nome “ssh” simboliza uma pasta oculta.
![](https://i.imgur.com/EelrINv.png)
Aqui vai pedir para digitar uma senha e depois confirmar essa senha. Observação: Essa senha é a senha de acesso do arquivo da chave e não a senha do Github. Após as confirmações, irá para a tela da imagem logo a seguir:
![](https://i.imgur.com/87YTmZH.png)
A suas chaves públicas e privadas foram geradas e salvas no diretório especificado acima. (/c/Users…. ) O SHA256 é a criptografia da sua chave SSH E a arte aleatória criptográfica da sua chave.
Então agora vamos ver a chave nos diretórios
![](https://i.imgur.com/WoLZrCg.png)
Usaremos o cd para ir no diretório da chave e o ls para vermos as chaves salvas no diretório. Lembrando que será a chave publica que vamos expor no Github. Então usaremos um comando para pegarmos o código na chave pública.
cat id_ed25519.pub
![](https://i.imgur.com/tuadSEi.png)
Você receberá esse desde o ssh-ed25519, , código enorme e com o email no final, você copiará tudo, incluindo o e-mail e será usado no Github.
![](https://i.imgur.com/ArogskO.png)
Ok, agora vamos ao Github. E faremos o seguinte caminho: Clique na sua foto no canto superior direto > Settings > e na parte esquerda selecione SSH and GPG Keys.
![](https://i.imgur.com/u1yd7Po.png)
No Titile você vai dar um nome para o seu PC E no Key você vai usar o código copiado.
![](https://i.imgur.com/wggmdWs.png)
E aqui você terá a confirmação da sua chave salva. E por fim os últimos passos no Git. Primeiro você vai usar o comando
eval $(ssh-agent -s)
Sera gerado um Agent Pid de alguns algarismos que é o começo do processo. E por fim o comando:
ssh-add id_ed25519
- Token Por fim o Token de acesso pessoal, que é a sua chave da conta por Token. Faça o seguinte caminho: Developer Settings > Personal acess tokens > Generate new token Então na opção Note, você dará o nome da sua Token, escolherá a data de Expiração para essa Token e terá outras opções de segurança da Token. Por enquanto só é necessário marcar a opção repo Você cria a chave e você receberá um código dessa chave. Observação: O Github só te vai mostrar essa chave uma ÚNICA vez, então tenha certeza de guardar em um local bem seguro.