Demo trabalhando com versionamento em seus projetos

󠁐Projeto com objetivo de mostrar de forma básica o funcionamento do sistemas de controle de versão com Git, seus comandos de inicialização de repositório local, commits, push, merge, pull e muitos outros. Vou também demonstrar a conecxão com github via chave SSH, para poder subir os projetos para github.

💬 Para trabalhar com controle de versão, você vai precisar:

Instalar o Git Criar uma conta no GitHub

💬 É importante nos identificarmos para o Git, Definindo nome de usuario e endereço de e-mail para os commits.

• git config --global user.name "Fulano da Silva"
• git config --global user.email [email protected]
• Pode verificar todos dados com comando git config –list.

💬 Iniciando repositório local

• O git init é o primeiro comando que devemos realizar para iniciar o controle de versão, pois é com este comando, que iniciamos o repositório local.
• O git status verifica o status atual do repositório criado para o projeto.
• O git log verifica e passa uma lista de todos commits realizado no repositório e com varios dados como hash do commit, autor, data branch.
• O git add coloca os arquivos não preparados, monitorados na área de preparação staging area. E o add pode ser arquivo por arquivo git add name.txt ou todos git add ..
• O git commit -m ":tada: Commit message" registra alterações no repositório git salvando uma mensagem de log junto com um id hash do commit.

    git init
    git status
    git log
    git add .
    git commit -m ":tada: first commit"

💬 Você pode usar SSH para realizar operações Git em repositórios em GitHub.com. Para obter mais informações, consulte Sobre SSH 🗝️ ou add ssh key. Se você tiver uma chave 🔑 SSH existente, poderá usá-la para autenticar operações do Git por SSH.

Com o Git Bash aberto execute:

    ssh-keygen -t ed25519 -C "[email protected]"

💬 Quando você for solicitado a Inserir um arquivo no qual salvar a chave, pressione Enter para aceitar o local padrão do arquivo.Observe que, se você criou chaves SSH anteriormente, o ssh-keygen pode solicitar que você reescreva outra chave; nesse caso, recomendo a criação de uma chave SSH com nome personalizado. Para fazer isso, digite o local padrão do arquivo e substitua id_ssh_keyname pelo nome de sua chave personalizada.

Por fim, precisa copiar a chave para depois ir em sua conta no github para criar a nova conexão SSH. Obs: O comando abaixo você precisa estar no diretório certo para fazer o copy.

    clip < ~/.ssh/id_ed25519.pub

💬 De acordo com a documentação do Conventional Commits, commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas. Esses commits auxiliarão você e sua equipe a entenderem de forma facilitada quais alterações foram realizadas no trecho de código que foi commitado.

💬 O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.

• feat- Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico).

• fix - Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico).

• docs - Commits do tipo docs indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código).

• test - Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código)

• build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.

• perf - Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

• style - Commits do tipo style indicam que houveram alterações referentes a formatações de código, semicolons, trailing spaces, lint... (Não inclui alterações em código).

• refactor - Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review.

• chore - Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes... como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código)

• ci - Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

💬 Adicionamos o comando git clone + ssh code do repositório github. Conforme abaixo, vamos baixar o projeto em um diretório.

    git clone [email protected]:RafaelBlum/demo-git-github.git

💬 Podemos também definir uma pasta ao clonar um repositório.

    git clone [email protected]:RafaelBlum/demo-git-github.git nomeDiretório

💬 Depois de cria a chave, basta criar um repositório no github e seguir os comandos abaixo.

    git remote add origin [email protected]:RafaelBlum/demo-git-github.git
    git branch -M main
    git push -u origin main

💬 Como enviar as alterações realizadas no seu projeto.

    git status
    git add .
    git commit -m "Alterações na feature x"
    git push

• ✔️ Untracked files Arquivos não rastreados no controle de vesão
• ✔️ Changes to be committed Arquivos rastreados no controle de versão
• ✔️ Changes not staged for committed Arquivos rastreados, mas com alterações

    git log
    git reflog
    git log --stat
    git log --oneline

• Definindo -m você pode editar a mensagem sem abrir o editor

git commit --amend -m "mensagem de correção aqui"

gif diff

gif diff --name-only

git checkout HEAD -- style.css

git reflog
git reset --hard id_commit

• É importante entender que git revert desfaz um único commit — ele não "reverte" ao estado anterior de um projeto removendo todos os commits subsequentes.
• No Git, isso é chamado de redefinição, não de reversão.

git revert id_commit

💬 Como podemos ver, trabalhar com git é como se estivessemos em uma máquina do tempo, onde podemos voltar na nossa linha do tempo, o que chamamos de commits, voltando no inicio do projeto ou em qulquer momento.

Agora vamos utilizar outro poder do tempo, o poder de criar uma linha do tempo em paralelo, o que chamamos de branchs. Estas linhas, branchs, usamos quando vamos desenvolver uma feature nova ou quando vamos trabalhar em equipe, pois assim todos podemos trabalhar em uma parte do projeto sem que haja problemas em nosso projeto que está funcionando corretamente.

Desta forma, podemos ter um desenvolvedor trabalhando na branch 2, na página de produtos e outro desenvolvedor trabalhando na branch 1, com a Home.

git branch

git branch new_feature

git checkout new_feature
git branch

git checkout -b new_feature

💬 Agora temos duas linhas do tempo main e new_feature. Podemos subir mais uma Branch para github (remoto).

Git push origin branch-name

Git push origin :branch-name

Git branch –D branch-name

💬 Antes de fazer o merge é importante fazer um pull no projeto remoto Github, puxando e atulizando para o projeto local, pois pode acontecer de outro desenvolvedor tenha modificado algo, então na branch main.

git pull origin branch-name
git push --set-upstream origin branch-name

Agora sim, podemos fazer o merge

git branch
git merge branch_name

Ex: Uma empresa pede para o desenvolvedor criar um sistema de login, mas ele não pode afetar o sistema principal ou o desenvolvimento dos outros desenvolvedores. E ao finalizar, ele deve passar seu código para um pull request.

Se você quiser criar um branch e fazer o checkout ao mesmo tempo, use o comando git checkout. O parâmetro -b especifica o nome do branch.

Criou um nova branch copiando a main

git checkout -b sistema-de-login main

Agora alteramos para a branch que queremos atualizar merge.

git checkout main
git pull
git merge sistema-de-login
git push

Depois de pronta a nova feature e enviada a branch nova para github, você no github, vai criar uma pull request que será aprovada ou não pela equipe.

💬 Algumas vezes podemos trabalhar na mesma branch e computadores dferentes ou com outros usuários e antes de iniciair, precisamos atualizar o código para o atual no github, conforme os commits forem sendo realizados.

O comando abaixo do git atualizar os arquivos do repositório remoto. Execute:

    git pull

Caso o git pull gere uma ❌mensagem❌

error:x:: Your local changes to the following files would be overwritten by merge ... Please commit your changes or stash them before you merge. Aborting

A ✔️ solução que pode ser feita: Utilizar um git stash para gravar o estado atual do seu repositório local, revertendo os arquivos para o estado atual do repositório remoto.

 git stash push --include-untracked

E agora sim o pull irá funcionar:

 git pull

Contatos 👇🏼 [[email protected]]

Adoro me conectar com pessoas diferentes, então se você quiser dizer oi, ficarei feliz em conhecê-lo mais! :)