4. Material extra

1. Gitignore

O arquivo .gitignore é usado no Git para especificar quais arquivos e diretórios devem ser ignorados pelo controle de versão. Assim evitamos que arquivos desnecessários sejam incluídos no repositório.

Estrutura do .gitignore:

O arquivo .gitignore é um simples arquivo de texto que lista padrões de nomes de arquivos e diretórios que o Git deve ignorar. Cada linha no arquivo representa um padrão a ser ignorado. Os padrões podem incluir curingas para coincidir com vários arquivos ou diretórios.

Exemplo de um arquivo .gitignore básico:

# Comentários começam com #
# Ignorar arquivos temporários
*.tmp

# Ignorar arquivos de log
*.log

# Ignorar diretório de compilação
/build/

# Ignorar arquivos de configuração local
config.local

Como criar um arquivo .gitignore:

1. Crie o arquivo: Você pode criar o arquivo manualmente usando um editor de texto simples ou através do terminal usando comandos como touch .gitignore (no Linux/Unix) ou New-Item .gitignore -type file (no PowerShell do Windows).
2. Edite o arquivo: Adicione os padrões de arquivos e diretórios que você deseja ignorar, como no exemplo acima.

Padrões de Ignoração:

• *: Corresponde a qualquer sequência de caracteres.
• ?: Corresponde a qualquer caractere individual.
• /: Indica uma barra como separador de diretório (use para ignorar diretórios específicos).
• #: Indica um comentário.

Exemplos Práticos:

1. Ignorar todos os arquivos .class:

*.class

2. Ignorar um diretório chamado dist:

dist/

3. Ignorar arquivos de configuração específicos:

config.local
config.dev

Integração com Repositórios Existente:

Se você já iniciou um repositório Git e deseja adicionar um .gitignore posteriormente, faça o seguinte:

1. Crie o arquivo .gitignore.
2. Abra o terminal na raiz do seu repositório e execute

    git add .gitignore
    git commit -m "Adicionar arquivo .gitignore"

3. O arquivo .gitignore agora está no controle de versão e será aplicado aos arquivos e diretórios correspondentes.

Pessoal, o uso do .gitignore é uma prática importante para manter nosso repositório limpo e evitar a inclusão de arquivos desnecessários ou até mesmo dados sensíveis.

Por fim... Certifique-se de adaptar o conteúdo do .gitignore de acordo com os requisitos específicos do seu projeto.

2. Conflitos gitignore

Em alguns momentos podemos nos deparar com alguns conflitos no git e github. Então, deixo algumas dicas, comandos e explicações que podem ajuda-los.

Lista de Problemas:

>> GITIGNORE:

Ao trabalhar em meu projeto Angular, onde há muitas pastas e arquivos de instalação passei por um conflito, onde: >> Eu estava tentando fazer um push para o meu repositório no GitHub, mas recebi um erro. Devido a alguns arquivos com nomes extensos, o GitHub tem um limite de tamanho de arquivo de 100 MB, e se você 'assim como eu' tentar fazer push de um arquivo maior que isso, receberá um erro. Esses arquivos que estavam causando o problema estavam no diretório .angular/cache/. Este diretório é usado pelo Angular para armazenar arquivos de cache que podem se tornar muito grandes. Normalmente, não queremos incluir esses arquivos em nosso repositório Git, então devemos adicioná-los ao nosso arquivo .gitignore.

Solução:

A solução foi adicionar o diretório .angular/cache/ ao arquivo .gitignore e, em seguida, limpar o cache do Git. Isso deve fazer com que o Git ignore os arquivos grandes no diretório .angular/cache/. Passo a Passo:

Podemos tentar remover o diretório .angular/cache/ do histórico do Git. Para isso, podemos usar o comando filter-branch ou a ferramenta BFG Repo-Cleaner.

Aqui estão os passos para usar o comando filter-branch:

1. Pessoal, primeiro de tudo, faça backup do seu repositório, pois este comando alterará o histórico do Git. Então, atenção!
2. Depois, Podemos executar o seguinte comando no terminal:

git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch .angular/cache/*" \
  --prune-empty --tag-name-filter cat -- --all

Este comando irá percorrer todo o histórico do seu repositório e remover os arquivos no diretório .angular/cache/.

1. Depois de executar o comando, você precisa forçar o push para o GitHub:

git push origin --force --all

ATENÇÃO: Note que forçar o push (--force) para o GitHub pode ser perigoso se outras pessoas estiverem trabalhando no mesmo repositório. Certifique-se de comunicar suas ações com sua equipe antes de executar esses comandos.

---

>> Erro ao fazer Push

fatal: credential-cache unavailable; no unix socket support
To https://github.com/meu-usuario/meu-repositorio.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/meu-usuario/meu-repositorio.git'  
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,        
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

Este erro ocorre quando você tenta fazer um push para um repositório remoto que tem commits que você ainda não tem em seu repositório local. Em outras palavras, seu branch local está atrasado em relação ao branch remoto.

Aqui estão as etapas para resolver este problema:

1. Primeiro, faça um pull para obter as alterações mais recentes do repositório remoto:

git pull origin main

2. Se você tiver conflitos de merge após o pull, você precisará resolvê-los. Depois de resolver os conflitos, faça um commit das alterações.
3. Agora você deve ser capaz de fazer o push para o repositório remoto:

git push origin main

A mensagem de erro fatal: credential-cache unavailable; no unix socket support é específica para sistemas Unix e geralmente pode ser ignorada em sistemas Windows. Se você estiver tendo problemas para autenticar, pode ser necessário verificar suas credenciais de Git.

>>> AHHH, NÃO FUNCIONOU - E AGORA? <<

Se o comando git pull origin main não está funcionando e você está recebendo a mensagem de erro que o branch local está atrás do branch remoto, você pode tentar o seguinte:

1. Primeiro, certifique-se de que todos os seus trabalhos locais estejam commitados. Se você tiver alterações não commitadas, você pode perdê-las com os próximos passos.
2. Em seguida, você pode tentar resetar seu branch local para corresponder ao branch remoto com o seguinte comando:

git reset --hard origin/main

Este comando irá resetar seu branch local main para corresponder exatamente ao estado do branch main no repositório remoto. Isso significa que quaisquer commits que você tenha em seu branch local que não estejam no remoto serão perdidos.

1. Depois de resetar seu branch local, você deve ser capaz de fazer o push para o repositório remoto:

git push origin main

Por favor, tenha cuidado ao usar o comando git reset --hard, pois ele irá descartar quaisquer alterações não commitadas em seu repositório local.

---

>> Erro de Credencial:

git push origin main
fatal: credential-cache unavailable; no unix socket support
Everything up-to-date

A mensagem "Everything up-to-date" significa que todas as alterações locais já foram enviadas para o repositório remoto. Não há nada para enviar, então o Git não faz nada.

A mensagem de erro "fatal: credential-cache unavailable; no unix socket support" é um erro que ocorre quando o Git tenta usar um método de armazenamento de credenciais que não é suportado no seu sistema. No Windows, o Git normalmente usa o Gerenciador de Credenciais do Windows para armazenar credenciais.

Você pode configurar o Git para usar o Gerenciador de Credenciais do Windows com o seguinte comando:

git config --global credential.helper wincred

Depois de executar este comando, o Git deve ser capaz de armazenar suas credenciais corretamente. Se você ainda estiver tendo problemas, pode ser necessário verificar suas credenciais de Git

Mas porque erros, se estava tudo certo?

A mensagem de erro que você está vendo geralmente ocorre quando há uma discrepância entre o seu repositório local e o repositório remoto. Isso pode acontecer por várias razões, como commits feitos no repositório remoto que ainda não foram puxados para o local, ou se você reescreveu o histórico do Git localmente.

---

>> Meus Arquivos não estão sendo ignorados no Github:

Se os arquivos listados no seu .gitignore não estão sendo ignorados, pode ser que eles já tenham sido rastreados pelo Git antes de serem adicionados ao .gitignore.

Para resolver isso, você precisa remover esses arquivos do índice do Git. Isso pode ser feito com o comando git rm --cached.

Por exemplo, para o arquivo angular.json, você usaria:

git rm --cached angular.json

E para o arquivo package-lock.json, você usaria:

git rm --cached package-lock.json

Depois de executar esses comandos, os arquivos serão ignorados como esperado. Lembre-se de fazer commit das alterações após executar esses comandos.

Se isso não resolver o problema, verifique se o arquivo .gitignore está na raiz do seu repositório e se os nomes dos arquivos estão corretos. Se os arquivos estiverem em subdiretórios, você precisará incluir o caminho do diretório no .gitignore, como subdirectory/angular.json.

E como fazer isso para todos arquivos dentro do meu repositório?

Se você deseja remover todos os arquivos rastreados do seu repositório Git e começar a ignorá-los, você pode usar o comando git rm --cached com um . para indicar todos os arquivos no diretório atual e subdiretórios.

Primeiro, certifique-se de que o arquivo .gitignore está configurado corretamente para ignorar os arquivos que você deseja ignorar.

Em seguida, execute o seguinte comando:

git rm --cached -r .

Este comando remove todos os arquivos do índice do Git, mas não os exclui do seu diretório de trabalho.

Depois disso, você pode fazer um commit para salvar essas alterações:

git add .
git commit -m "Remove all files from Git tracking"

Agora, todos os arquivos que estão listados no seu .gitignore serão ignorados pelo Git.

Por favor, tenha cuidado ao usar esses comandos, pois eles irão remover todos os arquivos do rastreamento do Git. Certifique-se de ter um backup de todos os seus arquivos antes de executar esses comandos.

3. Resumão sobre Github

Nesta aula, recordaremos as noções básicas do Github para que possamos compreender melhor seus recursos e produtos fundamentais.

Atenção:

Lembrando que iremos apenas recapitular os conceitos já visto no curso de Introdução ao Git e ao Github.

Github

Como já vimos anteriormente, o Github é uma plataforma em nuvem que utiliza o Git como núcleo. Ela possibilita que nosso processo de colaboração de projetos seja mais simples e nos fornece ferramentas de linha de comando, além de outras funcionalidade que permitem que devs e usuários colaborem juntos.

O Github também oferece uma plataforma de desenvolvimento com IA para a criação, escala e entregas de softwares seguros.

Github e a IA

A IA generativa está se interligando a várias áreas e ferramentas, possibilitando uma melhor produtividade em vários ramos e claro, no desenvolvimento de software não seria diferente.

A plataforma do Github também utiliza a IA e está cada vez mais aprimorando a colaboração por meio de problemas e pull requests da plataforma AI, além da melhoria na produtividade com o Copilot e a segurança com automatização de verificações de segurança de forma mais rápida.

Colaboração

Como percebemos o Github tem como principal característica a colaboração e com as ferramentas disponibilizadas essa colaboração torna-se mais simples e ocorrendo sem muito esforço. Como os repositórios e pull requests, possibilitam que diversas pessoas (sejam devs, gerenciadores de projeto, lideres, etc) possam trabalhar mais rapidamente, reduzindo assim, o tempo de aprovação. Resultando em entregas eficientes e de forma mais rápida.

Produtividade

Com ferramentas internas de CI/CD que são integradas ao fluxo de trabalho, a produtividade passa a ser acelerada com essa automação. O Github oferece um cuidado com a administração das rotinas e acelera o trabalho diário.

Segurança

A plataforma oferece recursos de segurança nativos e internos minimizando o risco de segurança com soluções criadas internamente. Ele permite que nossos códigos fiquem privados até mesmo dentro das nossas organizações

Escala

O Github é a MAIOR comunidade de Devs, com isso a plataforma compreende bem as necessidades de melhorias/mudanças com isso é feito alterações essenciais no produto. A plataforma possui compreensão que alteram o setor, funcionalidades de colaboração, ferramentas para ampliar a produtividade, segurança e a IA para ampliar toda essa gama de funcionalidades oferecidas.

---

O que é um repositório?

Um repositório é o local onde contém todos os arquivos do nosso projeto. Seria como uma pastinha que guarda todos esses arquivos de nossos projeto, como os nossos projetos de software. É com eles que podemos colaborar, gerenciar nosso trabalho, acompanhar as alterações, armazenar o histórico de alterações, etc...

O que são Branches?

Branches são pontos seguros em nosso código, onde podemos criar várias branches(pontos/ramos) com copias ou partes do nosso código, nessas branches podemos fazer alterações de bugs e features de forma segura, sem alterar a branche principal. Dessa forma, podemos fazer as alterações/correções de bugs e outras implementações sem alterar nosso código padrão. Podemos então depois, mesclar as alterações estáveis na nossa branche principal.

O que são os Commits?

Quando adicionamos um arquivo em nosso repositório é precisamos adicionar um commit via push, com um texto breve informando do que se trata aquele alteração. Sempre que um commit for criado, ele recebe um ID próprio e é acompanhado juntamente com o tempo e quem realizou o commit (o colaborador). Os commits nos possibilitam um melhor acompanhamento de forma clara para qualquer pessoa que esteja revisando o histórico de um arquivo ou até mesmo um item vinculado, como um problema ou uma solicitação de pull.

Já dentro de um repositório Git, um arquivo pode existir com vários estados válidos. Os estados primários são:

1. Não rastreado: O arquivo é rastreado, mas não foi modificado desde a última confirmação;
2. Rastreado: O Rastreado é aquele que o Git está monitorando ativamente, a "imagem" então pode está em um dos subestados a seguir:
   • Não modificado: O arquivo é rastreado, mas não foi modificado desde a última confirmação;
   • Modificado em: O arquivo foi alterado desde o ultimo commit, no entanto, essas alterações não foram preparadas para o próximo commit;
   • Preparado: O arquivo foi modificado e as alterações foram adicionadas à área de preparo;
   • Confirmado: O arquivo está no banco de dados do repositório

E as solicitações de Pull - Pull Request?

A solicitação de pull é basicamente um pedido para que outras pessoas vejam suas mudanças e decidam se elas devem ser adicionadas ao projeto principal ou não. Ao passar pelos revisores do projeto, eles podem comentar, fazer sugestões de correções e até mesmo discutir sobre as alterações. Quando todos concordam que as mudanças são validas é feito então a mesclagem no projeto principal. Em resumo, uma solicitação de pull é um pedido de permissão para que seja adicionados as alterações ao projeto, passando por revisão para garantir que tudo esteja correto antes da mesclagem.

Gists

Os gists assemelham-se aos repositórios, sendo uma forma mais simples de compartilhar trechos de códigos com outras pessoas. Já que eles se assemelham aos repositórios podemos criar fork e clona-los, podendo ser publico ou privado. Onde os públicos ficam disponíveis para outras pessoas e os privados não podem ser pesquisados e outras pessoas não podem visualiza-los.

Link do Gists: https://gist.github.com/

Wikis

As wikis fazem parte dos repositórios e há uma sessão onde podemos hospedar as documentações. Podemos usar o wiki do repositório para compartilhar conteúdos ao decorrer do nosso projeto. Com as wikis podemos fornecer documentação adicional.