hugoszd.github.io Open in urlscan Pro
2606:50c0:8001::153 Public Scan

Back to summary

URL:
https://hugoszd.github.io/resumogit-hub/
Submission: On August 24 via api (August 24th 2023, 1:43:53 pm UTC) from US — Scanned from US

Form analysis
0 forms found in the DOM

Text Content

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

* PDF
1-modulo-vi-introducao-ao-git.pdf
https://drive.google.com/file/d/1nlUJXoRw4wEMEw1ofrxKlwhG_MOlKNVG/view?usp=drivesdk

* 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 SCM
Mercurial 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.

* Exemplo de linha do tempo

--------------------------------------------------------------------------------

AULA 2 CONFIGURAÇÃO DO AMBIENTE

* Instalação e documentação :
Documentation
The 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
Downloads
Git 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 Desktop
Checkout 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
2-modulo-vi-configuracao-do-ambiente.pdf
https://drive.google.com/file/d/1W1qSXrOLw46RYU6JJZ9kr3PMjMEw8uUj/view?usp=drivesdk
2-tutorial-instalacao-gitbash-no-windows.docx
https://docs.google.com/document/d/1hYS2fetQr8bNLBGGuzCiNo0dSoPnzn49/edit?usp=drivesdk&ouid=110778513751742556754&rtpof=true&sd=true

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

* PDF
3-modulo-vi-ciclo-de-vida-dos-arquivos-commits-e-branches.pdf
https://drive.google.com/file/d/1EYzO0aVLmWLNEKp1AsH1e06slN20HXlo/view?usp=drivesdk

GIT POSSUI 4 STATUS (CICLOS) PARA ARQUIVOS

1. Untracked → O git não conhece a existência do arquivo em nenhuma versão
(Default).

2. Staged → Arquivos que estão prontos para serem inseridos em um novo estado
da aplicação (Novo Snapshot).

3. Unmodified → Indica arquivo que não sofreu nenhuma modificação em relação a
ultima versão.

4. 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

* Gera ramificações do fluxo principal de trabalho.

* As ramificações geradas podem ser trabalhadas isoladamente.

* Após modificações faremos um merge para associar a linha do tempo principal.

* Exemplo

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

* PDF
4-modulo-vi-branches-na-pratica.pdf
https://drive.google.com/file/d/1IwPBK3wmF0OdjEBemn5IBfwg3D1MzMal/view?usp=drivesdk

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

* PDF
5-modulo-vi-reset-na-pratica.pdf
https://drive.google.com/file/d/1wtUUKWh5vzOuEV0Ca5xMOwRUhe9ftzwz/view?usp=drivesdk

DIFF

* Vai mostrar a diferença entre o arquivo atual e o estado anterior.

💡
OBS:

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”)

💡
OBS:

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

* PDF
6-modulo-vi-github-gitlab-e-bitbucket.pdf
https://drive.google.com/file/d/10AR0yT12jvO2YmZ9GE6UhcUIJTenK4LH/view?usp=drivesdk

* Páginas úteis
GitHub: Where the world builds software
GitHub 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 | GitLab
Keep 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 Jira
Bitbucket 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

--------------------------------------------------------------------------------

AULA 7 GITHUB NA PRÁTICA

* PDF
7-modulo-vi-github-na-pratica.pdf
https://drive.google.com/file/d/1VWxp8-GlCassn-aSm-PjmYybUdwlPNrI/view?usp=drivesdk

AQUI VAMOS CRIAR UM REPOSITÓRIO NO GITHUB PARA TRABALHARMOS COM O PROJETO NA
NUVEM.

* Pegando o código do repositório da nuvem:

* Inserindo o código no repositório local

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 PRÁTICA

* PDF
8-modulo-vi-pull-e-push-na-pratica.pdf
https://drive.google.com/file/d/1eSbxkXNNrp5a1pCP7P4MTHcwlO9ZrLdm/view?usp=drivesdk

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

* PDF
9-modulo-vi-git-merge-e-rebase.pdf
https://drive.google.com/file/d/1SL3-yZsMJDE4W9CQ3HLcMtaSBQ6bAsJV/view?usp=drivesdk

OBSERVAÇÃO:

Merge e rebase são usados para unir branches

MERGE

* Adiciona novo commit na time line principal indicando a junção das branches

* Gera fork do merge pra frente.

* Visualização

REBASE

* Deixa a linha do tempo linear.

* Vai gerar impacto a linhas de tempo alternativas

* Visualização

--------------------------------------------------------------------------------

AULA 10 MERGE E REBASE NA PRÁTICA

* PDF
10-modulo-vi-merge-e-rebase-na-pratica.pdf
https://drive.google.com/file/d/1IWuOX40yMFILJy_siwGxP2whXzD86k2l/view?usp=drivesdk

* Extensão para ver git log no vscode
Git History - Visual Studio Marketplace
View and search git log along with the graph and details. View a previous
copy of the file. View and search the history View the history of one or all
branches (git log) View the history of a file View the history of a line in a
file (Git Blame).
https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory

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 PRÁTICA

* PDF
11-modulo-vi-stash-na-pratica.pdf
https://drive.google.com/file/d/1zOzmKMxilGwYj-y68lo_ILMXI5tGm_ZV/view?usp=drivesdk

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

* PDF
12-modulo-vi-conhecendo-o-.gitignore.pdf
https://drive.google.com/file/d/1MoKBA6-CgcPmWhMA2Hl6oQm9kQMlgsY0/view?usp=drivesdk

* Paginas úteis
GitHub - github/gitignore: A collection of useful .gitignore templates
This 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 Documentation
A 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 PRÁTICA

* PDF
13-modulo-vi-git-revert-na-pratica.pdf
https://drive.google.com/file/d/1-Rq-QA6UsZp04Qrg-YgAKPINyvox0-Qc/view?usp=drivesdk

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

* PDF
14-modulo-vi-workflows-com-git.pdf
https://drive.google.com/file/d/1DD4zQMVqx2hI_kq0SeGcAn4pyEme47Zx/view?usp=drivesdk

Observações:

Possibilita rotina de trabalho mais consistente e produtiva.

TEMOS 3 FLUXOS DE TRABALHO DIFERENTES

1 - CENTRALIZED

* Todos os desenvolvedores trabalham na mesma branch main.

* Facilita para ter organização na ordem de commits.

* Geralmente usado em times muito pequenos.

* Modelo exemplo:

2 - FEATURE BRANCH

* Cada nova funcionalidade terá uma branch especifica.

* Geralmente mais usada em times grandes.

* Nesse modelo nenhum push é feito na branch main.

* Modelo exemplo:

3 - GITFLOW

* Cada dev vai usar um modelo estrito de branch projetada em torno do projeto.

* Modelo

--------------------------------------------------------------------------------

AULA 15 - WORKFLOW CENTRALIZADO NA PRÁTICA

* PDF
15-modulo-vi-workflow-centralizado-na-pratica.pdf
https://drive.google.com/file/d/19KSFV_9Mu8LN2tYPfSNlnVupaAr9BElf/view?usp=drivesdk

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 PRÁTICA

* PDF
16-modulo-vi-pull-request-e-feature-branch-na-pratica.pdf
https://drive.google.com/file/d/1LwnGQ12sWDixg65ZKc2YM7OELr4ScNWz/view?usp=drivesdk

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

1. Vamos criar uma branch da funcionalidade e fazer as mudanças.

2. Vamos fazer o git add e depois fazer o commit da mudança.

3. Vamos fazer o pull para o repositório remoto informando a branch

git push nome_do_rep_remoto nome_da_branch_que_queremos_enviar

4. Agora vamos ir na página do projeto e clicar no pool request

5. 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 PRÁTICA

* PDF
17-modulo-vi-resolvendo-conflitos-na-pratica.pdf
https://drive.google.com/file/d/1stg7FLs5-ALuAuGiHFWnBJLHvsdy6uWC/view?usp=drivesdk

* Exemplo de conflito

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

💡
Lembrando que o git vai salvar o conflito e isso precisa ser enviado para a time
line.

#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 git irá criar um commit informando o conflito.
* O código do conflito pode ser analisado separadamente e reincorporado caso
necessário.

--------------------------------------------------------------------------------

AULA 18 ADICIONANDO O SITE NO GITHUB PAGES

* PDF
18-modulo-vi-adicionando-o-site-no-github-pages.pdf
https://drive.google.com/file/d/1VreNQeMhLBlUvWBTA4ca9o6yk0QvPv8Y/view?usp=drivesdk

OBSERVAÇÕES:

* Podemos hospedar nosso projeto para gerar link externo.

* Só consigo hospedar projetos que contem HTML, CSS e JavaScript

* Para hospedarmos temos que fazer:

💡
Após a hospedagem sera gerado um link que podemos compartilhar.

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.

* 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.

E se mudarmos o arquivo mais uma vez?

Novamente gera uma chave diferente.

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.

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.

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:

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

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

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.

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.

No Titile você vai dar um nome para o seu PC E no Key você vai usar o código
copiado.

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.

hugoszd.github.io Open in urlscan Pro 2606:50c0:8001::153 Public Scan

Form analysis 0 forms found in the DOM

Text Content

hugoszd.github.io Open in urlscan Pro
2606:50c0:8001::153 Public Scan

Form analysis
0 forms found in the DOM