GitHub é uma plataforma popular para hospedagem e colaboração em projetos de programação, permitindo que desenvolvedores trabalhem juntos de forma eficaz, para iniciar o seu uso, crie uma Conta. O GitHub foi criado em 2008 para hospedar projetos Git e agora é uma subsidiária da Microsoft. O GitHub não se limita a projetos de código aberto; empresas e desenvolvedores individuais podem criar repositórios privados acessíveis somente a eles.

Como o Git e o GitHub funcionam juntos?¶

GitHub hospeda repositórios do Git e fornece aos desenvolvedores ferramentas para enviar um código melhor por meio das funcionalidades de linha de comando, problemas(discussões encadeadas), pull requests, revisão de código ou o uso de uma coleção de aplicativos grátis e para compra em GitHub Marketplace.

Ao enviar arquivos para o GitHub, você os armazenará em um "repositório Git". Isso significa que quando você fizer alterações (ou "commits") nos seus arquivos no GitHub, o Git começará automaticamente a rastrear e gerenciar suas alterações.

Os principais recursos fornecidos pelo GitHub incluem:

Configuração Básica - GitHub¶

Você pode acessar Repositórios Remotos no GitHub a partir da linha de comando de duas maneiras: HTTPS e SSH. O HTTPS usa nome de usuário e PAT (Personal Access Token) como uma abordagem de verificação de conta.

• HTTPS é considerado mais rápido que SSH e você geralmente pode trabalhar com todos os repositórios no GitHub via HTTPS, mesmo se estiver atrás de um firewall ou proxy.
• O SSH usa um par de chaves secretas e públicas. Você precisa gerar um par de chaves e carregar a chave pública no site da conta do GitHub.

SSH (Secure Shell)¶

• Gerar e Adicionar Chaves SSH: Crie um par de chaves SSH (pública e privada) e adicione a chave pública ao seu perfil no GitHub.
• Isso permite uma conexão segura sem precisar inserir sua senha a cada operação1
• Proteger a Chave Privada: Mantenha sua chave privada em segredo e protegida por uma senha adicional1
• Não compartilhe sua chave privada com ninguém1
• Usar SSH Agent: Adicione sua chave SSH ao SSH agent para facilitar a gestão das chaves e evitar a necessidade de inserir a senha manualmente.
• Para estabelecer uma conexão SSH, você precisa de um par de chaves SSH (uma chave privada e uma chave pública) e carregar a chave pública na plataforma GitHub.
• ssh-keygen -t ed25519 -C "seu endereço de e-mail"(GitHub recomaneda)
• ssh-keygen -t rsa -b 4096 -C "seu endereço de e-mail"
• Quando o comando é executado, os arquivos das chaves pública e privada são gerados sob o diretório .ssh sob seu diretório home de usuário.
• Imagem → Settings → SSH and GPG keys
• Para testar a conexão, use: ssh -T git@github.com

The authenticity of host 'github.com (20.201.28.151)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Hi horaciovasconcellos! You've successfully authenticated, but GitHub does not provide shell access.

GPG (GNU Privacy Guard)¶

• Gerar e Adicionar Chaves GPG: Crie um par de chaves GPG (pública e privada) e adicione a chave pública ao seu perfil no GitHub;
• Assinar Commits e Tags: Configure seu Git para assinar commits e tags com sua chave GPG;
• Isso garante a integridade e autenticidade dos seus commits;
• Proteger a Chave Privada: Assim como com SSH, mantenha sua chave privada em segredo e protegida por uma senha adicional;
• O GPG usa o método de chaves pública e privada (secreta) para assegurar a transferência de informações entre pares.

gpg --list-keys
gpg --delete-secret-keys 9866D9A3416A4D889A5AC9F7D408E252533D5692
gpg --delete-keys 9866D9A3416A4D889A5AC9F7D408E252533D5692
gpg --default-new-key-algo rsa4096 --gen-key
gpg --list-secret-keys --keyid-format=long
gpg --armor --export C67812FF37F0AD86
git config --global gpg.program gpg2

• Imagem → Settings → SSH and GPG keys

Personal Access Tokens (PATs)¶

Existem dois tipos de PAT: Tokens (clássico) e tokens refinados (versão beta em setembro de 2023).

• Imagem → Settings → Developer Settings → Tokens (Use token refinados)

PAT é usado quando você estabelece uma conexão HTTPS com seu Repositório Remoto. Através dos comandos: git clone, git remote, git push e git pull.

• Criar e Usar PATs: Crie tokens de acesso pessoal no GitHub para substituir senhas ao autenticar-se em APIs e na linha de comando;
• Defina permissões mínimas necessárias para a tarefa em questão;
• Tratar PATs como Senhas: Sempre trate seus PATs como senhas e nunca compartilhe com ninguém;
• Rotacione regularmente e remova tokens que não são mais necessários.
• GitHub possuoi dois tipos de PATs:
  • Tokens clássicos: Eles são menos seguros e não são mais recomendados para uso. Clientes com sistemas legados podem ainda estar usando token clássico
  • Tokens de acesso pessoal refinados: Concederam permissões específicas. Deve ter uma data de expiração, pode acessar apenas repositórios específicos, pode acessar apenas recursos de propriedade de um único usuário ou organização.

Criação das Chaves¶

Navegação Básica.¶

Dentro de um repositório do Github, você terá uma barra de navegação para os vários recursos do seu repositório do GitHub:

• Código: A aba principal onde o código-fonte, arquivos e pastas do repositório estão localizados.
• Problemas: Rastreia problemas ou ideias para o projeto, permitindo colaboração e discussão.
• Solicitações de pull: Usadas para gerenciar contribuições de outros usuários, permitindo revisão de código e discussão antes de mesclar alterações.
• Discussões: É um fórum aberto para conversa entre mantenedores e a comunidade de um projeto no GitHub.
• Ações: Gerencia fluxos de trabalho de integração contínua e implantação contínua (CI/CD).
• Projetos: Um quadro para organizar e priorizar o trabalho, semelhante ao kanban ou quadros de gerenciamento de tarefas. (Table, Board ou Roadmap)
• Wiki: Um espaço para a documentação do projeto.
• Segurança: Apresenta recursos relacionados à segurança, incluindo políticas de segurança e relatórios de vulnerabilidade.
• Insights: Fornece estatísticas e insights sobre a atividade e as contribuições do projeto.
• Configurações: Contém configurações do repositório, incluindo controles de acesso, webhooks e outras configurações

Ferramentas GitHub¶

Inspiração GitHub¶

Explore o GitHub para encontrar: repositórios, tópicos, códigos, pessoas e organizações.

Permissões de acesso¶

Uma permissão é a capacidade de executar uma ação específica.

FunçÕes da Organização¶

• All-repository read....: Conceder acesso de leitura a todos os repositórios da organização.
• All-repository write...: Conceder acesso de gravação a todos os repositórios da organização.
• All-repository triage..: Conceder acesso de triagem a todos os repositórios da organização.
• All-repository maintain: Conceder acesso de manutenção a todos os repositórios da organização.
• All-repository admin...: Conceder acesso de administrador a todos os repositórios da organização.

Funções de repositório para organizações¶

• Read : Recomendado para contribuidores não codificados que desejam visualizar ou discutir seu projeto
• Triage : recomendado para colaboradores que precisam gerenciar proativamente problemas, discussões e solicitações de pull sem acesso de gravação
• Write: Recomendado para colaboradores que contribuem ativamente para o seu projeto
• Maintain: Recomendado para gerentes de projeto que precisam gerenciar o repositório sem acesso a ações sensíveis ou destrutivas
• Admin: Recomendado para pessoas que precisam de acesso total ao projeto, incluindo ações sensíveis e destrutivas, como gerenciar a segurança ou excluir um repositório.

Comunicação¶

GitHub fornece ferramentas de comunicação colaborativa embutidas que permitem que você interaja de perto com sua comunidade.

Exemplos:

• O usuário criou um problema no repositório, sugerindo correção, uma discussão se inicia e há um consenso a aplicar.Um colaborador pode então solicitação de pull com a correção. (Issues)
• Você pode marcar problemas com rótulos para uma busca mais rápida e criar modelos de problemas para ajudar os colaboradores
• O usuário percebe erro, cria uma solicitação de pull , mantenedor do repositório analisa a solicitação de pull, comenta e a mescla. (PR)
• Você pode criar solicitações de pull de rascunho se suas alterações propostas ainda estiverem em andamento.
• O mantenedor da comunidade iniciou uma discussão para dar boas-vindas à comunidade e pedir que os membros se apresentem. (Discussions)
• Você pode configurar um código de conduta e fixar discussões que contenham informações importantes para sua comunidade

Lançamentos¶

Você pode usar a visualização de recursos para ver produtos ou recursos que estão disponíveis na visualização pública e para habilitar ou desabilitar cada recurso para sua conta pessoal.

• Prévia privada: O recurso está disponível para fins de demonstração e teste, mas pode não estar documentado.
• Prévia pública: Os lançamentos de pré-visualização pública podem ser públicos ou privados, são documentados.
• Disponibilidade geral (GA): As versões do GA estão prontas para uso em produção.

Problemas de Conexão¶

O GitHub possui uma ferramenta de teste de validação de rede, chamada GitHub Debug

GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1 clone git https://github.com/github/debug-repo /tmp/debug-repo-http
GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1 clone do git git@github.com:github/debug-repo /tmp/debug-repo-ssh          
ping -c 10 github.com
traceroute github.com
curl -s -o/dev/null -w "velocidade de download: %{speed_download} | dnslookup: %{time_namelookup} | conexão: %{time_connect} | conexão de aplicativo: %{time_appconnect} | pré-transferência: %{time_pretransfer} | transferência inicial: %{time_starttransfer} | total: %{time_total} | tamanho: %{size_download}\n" https://github.com

GitHub Advanced Security¶

O GitHub Advanced Security está disponível para contas corporativas no GitHub Enterprise Cloud e GitHub Enterprise Server. Alguns recursos do GitHub Advanced Security também estão disponíveis para repositórios públicos no GitHub.

• Alguns deles estão incluídos em todos os planos, como gráfico de dependência e alertas do Dependabot.

• O GitHub limita o número de pessoas que podem ser convidadas para um repositório dentro de um período de 24 horas.

  • Settings → Colaboradores → Adicionar pessoas

• GitHub Advanced Security:

  • Code scanning: Potenciais vulnerabilidades de segurança e erros de codificação em seu código
  • CodeQL CLI: Localmente em projetos de software ou para gerar resultados de varredura de código para upload no GitHub Enterprise Cloud.
  • Secret scanning: Detecte segredos, por exemplo, chaves e tokens, que foram verificados no repositório.
  • Regras de triagem automática personalizadas (Custom auto-triage rules): gerenciar seus alertas do Dependabot em escala.
  • Revisão de dependência (Dependency review): Mostre o impacto total das alterações nas dependências e veja detalhes de quaisquer versões vulneráveis ​​antes de mesclar uma solicitação de pull.
• Os recursos do GitHub Advanced Security estão habilitados para todos os repositórios públicos no GitHub.com. Organizações que usam o GitHub Enterprise Cloud com Advanced Security podem habilitar adicionalmente esses recursos para repositórios privados e internos.
• Com uma licença do GitHub Copilot Enterprise, você também pode pedir ajuda ao GitHub Copilot Chat para entender melhor os alertas de segurança em repositórios na sua organização

Fase 1: Alinhe sua estratégia de implementação e metas¶

Fase 2: Preparação para habilitar em escala¶

Preparar os desenvolvedores e coletar dados sobre seus repositórios para garantir que suas equipes estejam prontas e que você tenha tudo o que precisa para programas piloto e implementação de varredura de código e varredura secreta.

• Treinamento para varredura de código;
• Habilitar Secret scanning, cada novo repositório e ir tratando o legado.
  • Cria um alerta na aba Segurança do repositório;
  • Adiciona o evento de bypass ao log de auditoria;
  • Envia um alerta por e-mail gerentes de segurança;

Fase 3: Programas piloto¶

Isso permite que um grupo inicial dentro da sua empresa se familiarize e construa uma base sólida antes de implementá-lo para o restante da sua empresa.

Fase 4: Criar documentação interna¶

Você deve criar uma documentação interna que defina processos para as equipes seguirem.

• precisam saber o que fazer quando recebem um alerta de segurança;
• use as experiências e o feedback das equipes envolvidas nesses pilotos para influenciar sua documentação.
• A educação é provavelmente a parte mais crucial da implementação, pois ensina aos desenvolvedores o que fazer em diferentes situações.

Fase 5: Implementação e digitalização de código em escala¶

Fase 6: Implementação e dimensionamento da varredura secreta¶

• Concentre-se nos segredos recentemente revelados
  • Notificar : Use webhooks para garantir que quaisquer novos alertas secretos sejam vistos pelas equipes certas o mais rápido possível.
  • Acompanhamento : Crie um processo de correção de alto nível que funcione para todos os tipos de segredo.
  • Educar : Crie um documento de treinamento interno atribuído ao desenvolvedor que cometeu o segredo.
• Habilitar proteção push: A varredura secreta verifica os pushs para segredos suportados e bloqueia os pushs para o GitHub antes que os segredos sejam expostos a outros usuários.
  • Fornecer orientação : configure um link personalizado na mensagem que os colaboradores verão se o push deles for bloqueado por varredura secreta.
  • Notificar : Defina um webhook que rastreie especificamente alertas de varredura secreta criados quando alguém ignora a proteção push usando a propriedade alerta.
  • Monitor : Use a visão geral de segurança para visualizar métricas sobre o desempenho da proteção por push em repositórios em sua organização.
• Corrija os segredos previamente comprometidos, começando pelos mais críticos
• Expanda o programa para incluir mais tipos secretos e padrões personalizados

Escrevendo no GitHub¶

Markdown é uma linguagem fácil de ler e escrever para formatar texto simples. Você pode usar a sintaxe Markdown, junto com algumas tags HTML adicionais, para formatar sua escrita no GitHub, em lugares como READMEs de repositórios e comentários em pull requests e issues.

Sessões¶

<details>
<summary>Tips for collapsed sections</summary>
### You can add a header
You can add text within a collapsed section. 
You can add an image or a code block, too.
</details>

Blocos¶

```
Blocos
```

Diagramas¶

Você pode criar diagramas em Markdown usando quatro sintaxes diferentes: mermaid, geoJSON, topoJSON e ASCII STL.

Expressões Matemáticas¶

Escrevendo expressões matemáticas: GitHub Enterprise Cloud oferece suporte à matemática formatada em LaTeX. Para adicionar uma expressão matemática como um bloco, inicie uma nova linha e delimite a expressão com dois símbolos de cifrão `$$` ou usando o bloco: ```math```.

Referências e URLs autolinkadas¶

Etiquetas (Labels)¶

É possivel no texto - Issues, Discussions, PR, Wikis, Markdown, inserir o rótulo, colocando apenas a sua URL. A URL de um rótulo pode ser encontrada navegando até a página de rótulos e clicando em um rótulo. (https://github.com/60pportunities/documentacao/labels/enhancement)

Commits¶

Ao hash SHA de um commit são automaticamente convertidas em links encurtados para o commit no GitHub Enterprise Cloud. o SHA do commit só será abreviado se pelo menos um dos autores ou committers do commit tiver pelo menos acesso de leitura ao commit referenciado.

Anexando Arquivos¶

Folhas de dicas, exames práticos e flash cards. O tamanho máximo do arquivo é:

• 10 MB para imagens e gifs;
• 10 MB para vídeos enviados para um repositório de propriedade de um usuário ou organização em um plano gratuito do GitHub;
• 100 MB para vídeos enviados para um repositório de propriedade de um usuário ou organização em um plano pago do GitHub;
• 25 MB para todos os outros arquivos;

Arquivos suportados:

Você consegue enviar para copiando e colando as imagens.

Sobre listas de tarefas¶

• Você não pode criar itens de lista de tarefas em problemas fechados ou problemas com solicitações de pull vinculadas.
• Você pode reorganizar a lista de tarefas.

Vinculando ao código¶

Esse tipo de link permanente será renderizado como um trecho de código somente no repositório em que foi originado.

Trabalhando com arquivos não codificados¶

O GitHub Enterprise Cloud pode exibir vários formatos de imagem comuns, incluindo PNG, JPG, GIF, PSD e SVG.

Arquivos grandes no GitHub¶

O GitHub Enterprise Cloud tenta fornecer armazenamento abundante para todos os repositórios Git, embora haja limites rígidos para tamanhos de arquivo e repositório.

Limites de tamanho de arquivo¶

• O GitHub Enterprise Cloud limita o tamanho dos arquivos permitidos em repositórios.
• O github possui uma ferramenta para verificar o tamanho do repositorio, chamado: git-sizer.
• Para evitar o preenchimento de um repositório com dependências externas, recomenda-se o uso de um gerenciador de pacotes.
• Idealmente inferior a 1 GB, e o tamanho inferior a 1 GB é altamente recomendado.
• Diferentes limites de tamanho máximo para o Git LFS se aplicam conforme o seu plano do GitHub.
• Limites de diff 20 mil linhas ou 500 KB de dados de comparação brutos.
• O número máximo de arquivos em uma só comparação é limitado a 300.
• O número máximo de arquivos renderizáveis (como imagens, PDFs e arquivos GeoJSON) em uma só comparação é limitado a 25.
• Limites de listas de commits: são limitadas a 250 commits.
• Arquivos
  • Um arquivo a um repositório por meio de um navegador, o arquivo não poderá ser maior que 25 MiB.
  • Um arquivo adicionado ou atualizado um arquivo maior do que 50 MiB, você receberá um aviso do Git.
  • O GitHub Enterprise Cloud bloqueia arquivos maiores que 100 MiB.
  • GitHub bloqueia arquivos maiores que 100 MiB. Para rastrear arquivos além desse limite, você deverá usar Git Large File Storage (Git LFS).
• Distribuindo binários grandes: Se você precisar distribuir arquivos grandes dentro do seu repositório, você pode criar releases no GitHub.com.
  • Não limitamos o tamanho total dos arquivos binários na versão ou a largura de banda usada para entregá-los. No entanto, cada arquivo individual deve ser menor que 2 GiB.

• Quando você excede o limite por arquivo de 5 GB, o arquivo é rejeitado pelo Git LFS com uma mensagem de erro.

• O Git LFS está disponível para cada repositório do GitHub, sua conta ou organização tendo ou não uma assinatura paga.

• Largura de banda e uso de armazenamento contam apenas na conta do proprietário do repositório. Na bifurcação, largura de banda e o uso do armazenamento contam contra a raiz da rede do repositório.

• Qualquer pessoa com acesso para gravação a um repositório pode fazer push de arquivos para o Git LFS sem afetar suas compras de pacotes de dados ou cotas de bandwidth e armazenamento pessoais
• Dependências externas podem fazer com que os repositórios Git fiquem muito grandes. Para evitar encher um repositório com dependências externas, recomendamos que você use um gerenciador de pacotes.
• O Git não foi projetado para servir como uma ferramenta de backup.

Removendo arquivos do histórico de um repositório¶

Antes de Envia-lo para o principal¶

$ git rm --cached GIANT_FILE
$ git commit --amend -CHEAD
$ git push

Antes de Enviado para o principal¶

Se você adicionou um arquivo em um commit anterior, você precisa removê-lo do histórico do repositório, para recriar o histórico e o DAG do commit. você pode usar o BFG Repo-Cleaner ou o git filter-repocomando.

git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
cd YOUR-REPOSITORY
git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore
git add .gitignore
git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore"
git remote add origin https://github.com/OWNER/REPOSITORY.git
git push origin --force --all
git push origin --force --tags

OU

bfg --strip-blobs-bigger-than 100M --replace-text banned.txt repo.git

GitHub Roadmap¶

Cada item no roteiro é um problema, com um rótulo que indica cada um dos seguintes:

• Fase de lançamento, Área de recurso, Rótulos de SKU de produto, Modelos de implantação, preview ou GA.

GitHub Móvel¶

O GitHub Mobile está disponível como um aplicativo para Android e iOS:

• Gerenciar Notificações, problemas e solicitações de pull, interaja com usuários, repositórios e organizações, receba uma notificação push quando alguém mencionar seu nome de usuário,Pesquisar código, proteja sua conta GitHub.com com autenticação de dois fatores,verifique suas tentativas de login em dispositivos não reconhecidos e Use o GitHub Copilot Chat para fazer e receber respostas sobre questões relacionadas à codificação.

GitHub Dev¶

O editor baseado na web `github.dev` é uma experiência de edição leve que roda inteiramente no seu navegador.É uma maneira rápida de editar e navegar no código.

É especialmente útil se você quiser editar vários arquivos ao mesmo tempo ou aproveitar todos os poderosos recursos de edição de código do `Visual Studio Code` ao fazer uma alteração rápida. Para obter mais informações, consulte nossa documentação.Você pode abrir qualquer repositório GitHub em github.dev de uma das seguintes maneiras:

• Para abrir o repositório na mesma aba do navegador, pressione ., enquanto navega em qualquer repositório ou pull request no GitHub.
• Para abrir o repositório em uma nova aba do navegador, pressione >.
• Altere a URL de "github.com" para "github.dev".
• Ao visualizar um arquivo, selecione o menu suspenso e clique em github.dev ..

GitHub Codespace¶

Um codespace é um ambiente de desenvolvimento hospedado na nuvem. Personalize seu projeto para o GitHub Codespaces configurando arquivos de contêiner dev para seu repositório (geralmente conhecido como configuração como código), o que cria uma configuração de codespace repetível para todos os usuários do seu projeto.

Codespaces é um ambiente de desenvolvimento instantâneo e baseado em nuvem que usa um contêiner para fornecer linguagens, ferramentas e utilitários de desenvolvimento comuns. Permitindo que você crie um ambiente de desenvolvimento personalizado para seu projeto. O ciclo de vida de um Codespace começa quando você cria um Codespace e termina quando você o exclui.

Você pode criar um Codespace no GitHub.com, no Visual Studio Code ou usando a CLI do GitHub:

• O período de tempo limite de inatividade padrão é de 30 minutos.
• Você pode definir sua configuração de tempo limite pessoal para os Codespaces que criar, mas isso pode ser anulado por uma política de tempo limite da organização.

Codespaces versus editor GitHub.dev¶

Você pode usar GitHub.dev para navegar por arquivos e repositórios de código-fonte do GitHub e fazer e confirmar alterações de código. Você pode abrir qualquer repositório, bifurcação ou PR no editor GitHub.dev.

• Inicialização: GitHub.dev abre instantaneamente com o pressionar de uma tecla e você pode começar a usá-lo imediatamente, sem ter que esperar pela configuração ou instalação.
• Inicialização: Quando você cria ou retoma um Codespace, uma VM é atribuída ao Codespace. O contêiner é então configurado com base no conteúdo de um arquivo devcontainer.json. Essa configuração leva alguns minutos para criar o ambiente de desenvolvimento.
• Computação: Não há recursos de computação associados, portanto você não pode criar e executar seu código ou usar o terminal integrado.
• Computação: Com o GitHub Codespaces, você tem a potência de uma VM dedicada para executar e depurar seu aplicativo.
• Acesso ao terminal: Nenhum
• Acesso ao terminal: O GitHub Codespaces fornece um conjunto comum de ferramentas por padrão, o que significa que você pode usar o Terminal exatamente como faria no ambiente local.
• Extensões: Apenas um subconjunto de extensões que podem ser executadas na Web aparecerão na visualização de extensões e poderão ser instaladas
• Extensões: Com o GitHub Codespaces, você pode usar a maioria das extensões do Marketplace do Visual Studio Code.

Gists¶

Os gists são uma forma simplificada de compartilhar trechos de código com outras pessoas. Se você enviar a URL de um gist de segredo para um amigo, ele poderá vê-lo. Os Gists fornecem uma maneira simples de compartilhar trechos de código com outras pessoas. https://gist.github.com/

• Cada gists é um repositorio git. O gists podem ser publicos ou secretos, secret gists, não são privados.
• Não pode converter publico para privado, mas pode privado para publico. Os gists ficam associados a conta pessoal.
• Você pode incorporar gists, clonar e compartilhar, por ele ser um repositório.
• Você pode favoritar os gists, https://gist.github.com/YOUR_USERNAME/starred.
• São uma característica do GitHub, que os define como "uma maneira simples de compartilhar trechos e pastas com os outros". Este estudo de três partes explora como os usuários estão usando o Gists.
• A primeira parte é uma análise quantitativa de metadados e conteúdos de Gist.
• A segunda parte investiga as informações contidas em um Gist: Amostramos 750 mil usuários e seus Gists (totalizando 762k Gists), depois categorizamos manualmente o conteúdo de 398.
• A terceira parte do estudo investiga o que os usuários estão dizendo que Gists são para leitura do conteúdo de páginas da web e feeds do Twitter.
• Os resultados indicam que os Gists são usados por uma pequena porção dos usuários do GitHub, e aqueles que os usam normalmente têm apenas alguns.

• Gists fornecem uma maneira simples de compartilhar trechos de código com outras pessoas. Cada gist é um repositório Git, o que significa que pode ser bifurcado e clonado. https://gist.github.com

Um gist público em gist.github.com

• Gists públicos são pesquisáveis
• Gists públicos aparecem no Discover - https://gist.github.com/discover
• Gists secretos não são pesquisáveis ​​e não aparecem no discovery Gists secretos não são privados
• Você pode compartilhar a URL com amigos
• Gists secretos podem ser alterados para público
• Gists públicos não podem ser alterados para privados
• Você pode fixar Gists em seu perfil para que outros os encontrem facilmente
• Gists permitem que outros usuários comentem
• Gists permitem que você navegue facilmente pelas revisões

Se um Gist for um arquivo markdown, ele renderizará o HTML. Esta é uma ótima maneira de compartilhar documentação única:

InnerSource¶

• InnerSource é a organização e as melhores práticas de desenvolvimento de software não open-source e/ou proprietário.
• InnerSource não é uma diretriz rígida, mas uma estratégia flexível para estabelecer uma cultura de código aberto dentro das organizações.
• O InnerSourceCommons fornece vários recursos estruturados gratuitos para ajudar a entender como adotar InnerSource.

Fork¶

Os repositórios de bifurcação permitem que você crie uma cópia de um repositório. A bifurcação permite que você:

• Pegue um repositório de código aberto ou de código disponível e siga seu próprio caminho;
• Aplique rapidamente bugs e correções de patches;
• Um repositório bifurcado é indicado abaixo do nome do repositório;
• Você pode preferir usar um repositório bifurcado em vez do original;
• Você pode encontrar projetos originais abandonados e uma bifurcação se tornando o repositório de referência para o projeto;
• A bifurcação ajuda a manter os projetos públicos vivos, no limite e colaborativos;
• Um repositório separado para trabalhar nas contribuições da comunidade;
• Você pode criar solicitações de pull entre repositórios para ser aceito no repositório original;
• Usando o Network Graph em Repo Insights, você pode frequentemente encontrar soluções da comunidade para bugs ou recursos ausentes.

Descobrindo Repositorios¶

• O Github Repos pode ser definido como público, tornando os repositórios facilmente pesquisáveis ​​no GitHub e por meio de mecanismos de busca.
• Os repositórios públicos atendem a um propósito comunitário para compartilhamento de conhecimento, recursos educacionais e projetos de código aberto.
• Além de apenas pesquisar, o Github seleciona conteúdo por meio de suas páginas da comunidade:
  • https://github.com/explore
  • https://github.com/trending

Respostas salvas¶

• Profile → Settings → Code, planning, and automation → Saved Replies
• As respostas salvas permitem criar uma resposta reutilizável para problemas e pull requests. Uma resposta salva é adicionada, ela pode ser usada em problemas, solicitações de pull e discussões.
• As respostas salvas são associadas a sua conta pessoal no máximo, 100 respostas salvas.
• Saved Replies: Propósito: Criar respostas reutilizáveis para problemas e solicitações de pull.
• Templates: Propósito: Criar modelos de mensagens que podem ser usados em diferentes contextos.

Permissões e funções da organização¶

• A função de membro é o padrão, e você pode atribuir funções de proprietário e de gerente de cobrança, bem como permissões de "mantenedor da equipe".
• Os membros da organização podem enviar notificações para uma equipe ou solicitar revisões, e as equipes podem ser visíveis ou secretas. Para obter mais informações, confira "Sobre equipes".

Contribuiçoes¶

• A história do seu trabalho por meio dos repositórios e dos gists que você fixou, as associações à organização que você optou por divulgar, as contribuições que você fez e os projetos que você criou.
• Você pode aplicar o rótulo good first issue aos problemas no seu repositório público para que as pessoas possam encontrá-los ao pesquisar rótulos.

Time¶

No GitHub, um Time (ou "Equipe") é uma forma de organizar e gerenciar grupos de colaboradores dentro de uma organização. As equipes são usadas para agrupar membros de uma organização com base em suas funções, responsabilidades ou projetos, permitindo uma gestão mais eficiente de permissões, tarefas e colaboração dentro de repositórios. Cada time pode ter funções (roles) atribuídas aos seus membros, como "Membro" ou "Líder de equipe" (Team Maintainer).

Preparando seu projeto¶

• Facilite o uso do seu projeto para alguém. Um README amigável e exemplos de código claros facilitarão o início para qualquer um que acessar seu projeto.
• Explique claramente como contribuir , usando seu arquivo CONTRIBUTING e mantendo seus problemas atualizados.
• Bons primeiros problemas : para ajudar novos colaboradores a começar, considere rotular explicitamente os problemas que são simples o suficiente para iniciantes resolverem.
• Uma boa documentação convida as pessoas a interagir com seu projeto. Eventualmente, alguém abrirá um problema ou pull request. Use essas interações como oportunidades para movê-los para baixo no funil.
• Quando alguém novo chega ao seu projeto, agradeça pelo interesse!
• Seja responsivo. Se você não responder ao problema deles por um mês, é provável que eles já tenham esquecido do seu projeto.
• Tenha a mente aberta sobre os tipos de contribuições que você aceitará. Muitos colaboradores começam com um relatório de bug ou uma pequena correção. Há muitas maneiras de contribuir para um projeto. Deixe as pessoas ajudarem como quiserem.
• Se houver alguma contribuição com a qual você não concorda, agradeça pela ideia e explique por que ela não se encaixa no escopo do projeto, vinculando-a à documentação relevante, se houver.

Atalhos de teclado¶

Perfil¶

Informações pessoais sobre si mesmo na bio, como locais em que trabalhou, os projetos com os quais contribuiu ou interesses que você tem que outras pessoas talvez gostem de saber. Você pode ocultar em Achievements e inibir a visualização.

• Repositórios e gists que você possui ou com os quais contribui.
• Repositórios que você marcou com estrela e organizou em listas.
• Visão Geral das atividades (vc pode ocultar).

Recursos no perfil do usuário¶

Para usar um arquivo CODEOWNERS, crie um arquivo chamado CODEOWNERS na raiz, em .github/ ou no diretório docs/ do repositório, no branch em que deseja adicionar os proprietários de código.

.github ├── CODEOWNERS ├── FUNDING.yml ├── ISSUE_TEMPLATE │ ├── bug_report.md │ ├── feature_request.md ├── PULL_REQUEST_TEMPLATE.md ├── SECURITY.md └── workflows ├── ci.yml └── cd.yml

Exemplo de Templates¶

---
nome: Solicitação de recurso
sobre: ​​Sugira uma ideia para este projeto
título: ''
rótulos: ''
destinatários: ''
---

**Sua solicitação de recurso está relacionada a um problema? Descreva.**
Uma descrição clara e concisa do problema. Ex. Fico sempre frustrado quando [...]

**Descreva a solução que você gostaria**
Uma descrição clara e concisa do que você quer que aconteça.

**Descreva as alternativas que você considerou**
Uma descrição clara e concisa de quaisquer soluções ou recursos alternativos que você tenha considerado.

**Contexto adicional**
Adicione qualquer outro contexto ou capturas de tela sobre a solicitação de recurso aqui.

blank_issues_enabled: true
contact_links:
  - name: Contact GitHub Support
    url: https://support.github.com/request
    about: Contact Suppor

version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    reviewers:
      - "github/codeql-production-shield"
    schedule:
      interval: weekly
    labels:
      - Update dependencies
    # Ignore incompatible dependency updates
    ignore:
      # There is a type incompatibility issue between v0.0.9 and our other dependencies.
      - dependency-name: "@octokit/plugin-retry"
        versions: ["~6.0.0"]
      # v7 requires ESM
      - dependency-name: "del"
        versions: ["^7.0.0"]
      # This is broken due to the way configuration files have changed. 
      # This might be fixed when we move to eslint v9.
      - dependency-name: "eslint-plugin-import"
        versions: [">=2.30.0"]
    groups:
      npm:
        patterns:
          - "*"
  - package-ecosystem: github-actions
    directory: "/"
    reviewers:
      - "github/codeql-production-shield"
    schedule:
      interval: weekly
    groups:
      actions:
        patterns:
          - "*"
  - package-ecosystem: github-actions
    directory: "/.github/actions/setup-swift/" # All subdirectories outside of "/.github/workflows" must be explicitly included.
    reviewers:
      - "github/codeql-production-shield"
    schedule:
      interval: weekly
    groups:
      actions-setup-swift:
        patterns:
          - "*"

### Merge / deployment checklist

- [ ] Confirm this change is backwards compatible with existing workflows.
- [ ] Confirm the [readme](https://github.com/github/codeql-action/blob/main/README.md) has been updated if necessary.
- [ ] Confirm the [changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) has been updated if necessary.

name: Check Code-Scanning Config
description: |
    Checks the code scanning configuration file generated by the
    action to ensure it contains the expected contents
inputs:
  languages:
    required: false
    description: The languages field passed to the init action.

  packs:
    required: false
    description: The packs field passed to the init action.

  queries:
    required: false
    description: The queries field passed to the init action.

  config-file-test:
    required: false
    description: |
      The location of the config file to use. If empty,
      then no config file is used.

  expected-config-file-contents:
    required: true
    description: |
      A JSON string containing the exact contents of the config file.

  tools:
    required: true
    description: |
      The version of CodeQL passed to the `tools` input of the init action.
      This can be any of the following:

      - A local path to a tarball containing the CodeQL tools, or
      - A URL to a GitHub release assets containing the CodeQL tools, or
      - A special value `linked` which is forcing the use of the CodeQL tools
        that the action has been bundled with.

      If not specified, the Action will check in several places until it finds
      the CodeQL tools.

runs:
  using: composite
  steps:
    - uses: ./../action/init
      with:
        languages: ${{ inputs.languages }}
        config-file: ${{ inputs.config-file-test }}
        queries: ${{ inputs.queries }}
        packs: ${{ inputs.packs }}
        tools: ${{ inputs.tools }}
        db-location: ${{ runner.temp }}/codescanning-config-cli-test
      env:
        CODEQL_ACTION_TEST_MODE: 'true'

    - name: Install dependencies
      shell: bash
      run: npm install --location=global ts-node js-yaml

    - name: Check config
      working-directory: ${{ github.action_path }}
      shell: bash
      run: ts-node ./index.ts "${{ runner.temp }}/user-config.yaml" '${{ inputs.expected-config-file-contents }}'

    - name: Clean up
      shell: bash
      if: always()
      run: |
        rm -rf ${{ runner.temp }}/codescanning-config-cli-test
        rm -rf ${{ runner.temp }}/user-config.yaml

name: 'Release branches'
description: 'Determine branches for release & backport'
inputs:
  major_version:
    description: 'The version as extracted from the package.json file'
    required: true
  latest_tag:
    description: 'The most recent tag published to the repository'
    required: true
outputs:
  backport_source_branch:
    description: "The release branch for the given tag"
    value: ${{ steps.branches.outputs.backport_source_branch }}
  backport_target_branches:
    description: "JSON encoded list of branches to target with backports"
    value: ${{ steps.branches.outputs.backport_target_branches }}
runs:
  using: "composite"
  steps:
    - id: branches
      run: |
        python ${{ github.action_path }}/release-branches.py \
            --major-version ${{ inputs.major_version }} \
            --latest-tag ${{ inputs.latest_tag }}
      shell: bash

Contas Usuário¶

Não é possível criar contas pessoais em nome de outra pessoa. Depois que você tiver nomes de usuário para cada pessoa que deseja adicionar à sua organização, você poderá adicionar os usuários às equipes. As organizações que usam o GitHub Enterprise Cloud podem usar o logon único do SAML para gerenciar centralmente o acesso que as contas pessoais têm aos recursos da organização por meio de um IdP (provedor de identidade).

• Contas Pessoais: se você se inscreveu para sua própria conta no GitHub.com, você está usando uma conta pessoal.
• Contas usuários Gerenciadas: se sua conta foi criada para você por uma empresa no GitHub Enterprise Nuvem, você está usando uma conta de usuário gerenciada.

Contas Organizações¶

Organizações são contas compartilhadas onde empresas e projetos de código aberto podem colaborar em muitos projetos ao mesmo tempo, com recursos sofisticados de segurança e administrativos. Organizações são contas compartilhadas onde um grande número de pessoas pode colaborar em muitos projetos ao mesmo tempo. Todas as organizações podem possuir um número ilimitado de repositórios públicos e privados. Cada pessoa faz login em uma conta pessoal, e várias contas pessoais podem colaborar em projetos compartilhados ao ingressar na mesma conta da organização. Pessoas recebem FUNÇÕES dentro da Organização (read,write,triage,maintain, admin e CI/CD). Se uma organização exceder 100.000 pode ter um problema de performance UI. Para simplificar o gerenciamento de acesso e aprimorar a colaboração, é possível criar equipes aninhadas que reflitam a estrutura do grupo, com permissões e menções de acesso em cascata.

Painel da sua organização¶

Atividade recentes(feed de notícias,Alguém fez um comentário,um problema ou pull request,roblema ou pull request foi reaberto,revisão foi solicitada em uma pull request.Você foi atribuído a um problema ou uma pull request,referenciou um problema ou uma pull request por meio de um commit, fez comentários em um problema ou em uma pull request.)

Organizações e contas corporativas¶

As contas corporativas são um recurso do GitHub Enterprise Cloud que permitem que os proprietários gerenciem centralmente a política e a cobrança para várias organizações. o GitHub Enterprise Cloud e o GitHub Enterprise Server incluem contas corporativas, que permitem que os administradores gerenciem centralmente as políticas e o faturamento de várias organizações e possibilitem o internalsourcing entre as organizações

Melhores práticas para organizações¶

• Atribua a pelo menos duas pessoas em cada organização a função de proprietário.
• Uso de equipes para facilitar a colaboração na organização.
  • Recomenda-se manter as equipes visíveis sempre que possível e reservar equipes secretas para situações confidenciais.

Perfil da Organização¶

Exibição member ou public dos repositórios fixados e do LEIAME quando visitarem a página de perfil da sua organização. A exibição usa member como padrão se um LEIAME ou repositórios fixados somente para membros estiverem presentes, e usa public caso contrário. Os usuários que não são membros da sua organização verão uma exibição public. - [x] Somente os proprietários da organização podem fixar repositórios.

Personalizando o perfil da sua organização¶

Público: Crie um repositório .github e adicione um arquivo no diretório: profile/README.md Membros: Crire um repositorio .github-private e adicione um arquivo no diretório: profile/README.md

Feed de notícias¶

O feed de notícias de uma organização mostra a atividade de outras pessoas nos repositórios que pertencem a essa organização.

Visualizando métricas do GitHub Actions para sua organização ()¶

As métricas do GitHub Actions fornecem insights sobre como seus fluxos de trabalho e tarefas estão se saindo nos níveis de organização e repositório. - [x] Métricas de uso do GitHub Actions : as métricas de uso ajudam você a rastrear quantos minutos seus fluxos de trabalho e trabalhos consomem. - [x] Métricas de desempenho do GitHub Actions (Actions Performance Metrics): as métricas de desempenho focam na eficiência e confiabilidade dos seus fluxos de trabalho e trabalhos.

Você pode exibir informações de uso relacionadas a: Workflows, Jobs, Repositórios, RunTime OS e Runner Type.

Gerenciar a associação¶

Os integrantes removidos perderão o acesso às bifurcações privadas dos repositórios privados da sua organização, mas ainda poderão ter cópias locais. No entanto, eles não conseguem sincronizar as cópias locais com os repositórios da organização. Quando repositórios privados são bifurcados para outras organizações, elas são capazes de controlar o acesso à rede de bifurcação.

O SSO (logon único) do SAML¶

Proporciona aos proprietários da organização e da empresa que usam o GitHub Enterprise Cloud uma forma de controlar e proteger o acesso aos recursos da organização, como repositórios, problemas e solicitações de pull. Os membros de sua organização continuarão fazendo logon nas respectivas contas pessoais do GitHub.com. o GitHub o redireciona para seu IdP a fim de realizar a autenticação. SAML e SCIM disponíveis para GitHub Enterprise Cloud e GitHub Enterprise Server. o GitHub cria automaticamente um registro que vincula sua organização, a conta do membro no GitHub e a conta do membro no seu IdP. Se os integrantes estiverem conectados com uma sessão SAML SSO, ao criarem um novo repositório, a visibilidade-padrão desse repositório será privada.

Sistema para gerenciamento de identidades entre domínios (SCIM, System for Cross-domain Identity Management),¶

Se organização usa o SSO do SAML, você pode implementar o SCIM para adicionar, gerenciar e remover o acesso dos membros da organização ao GitHub Enterprise Cloud.

Funções¶

Uma função é um conjunto de permissões que você pode atribuir a indivíduos ou equipes. Os proprietários da organização podem atribuir funções a indivíduos e equipes, dando-lhes diferentes conjuntos de permissões na organização. Uma permissão é a capacidade de executar uma ação específica.

Nível de repositório:¶

Proprietário: Possui plenos direitos administrativos Admin: Pode gerenciar as configurações do repositório Mantenedor: um mantenedor normalmente gerencia o acesso Colaborador: Pode contribuir para o repositório Contribuidor: Não é uma função oficial, mas geralmente se refere aos usuários que contribuem

Nível de organização:¶

Proprietário: Tem controle total sobre a organização Gerente de faturamento: gerencia o faturamento, mas não tem acesso ao repositório Membro: Tem acesso padrão com base na política da organização

• Proprietários de organizações: Os proprietários da organização têm acesso administrativo completo à sua organização.
• Membros da organização: Têm uma série de permissões, incluindo a capacidade de criar repositórios e projetos.
• Moderadores da organização: Podem bloquear e desbloquear contribuidores não membros.
• Gerentes de cobrança: usuários que podem gerenciar as configurações de cobrança da sua organização, como informações de pagamento.
• Gerentes de segurança: função de nível de organização que os proprietários da organização podem atribuir a qualquer equipe em uma organização.
• Colaboradores externos: é uma pessoa que tem acesso a um ou mais repositórios da organização, mas não é explicitamente um membro da organização, como um consultor ou funcionário temporário.

Funções de repositório para uma organização¶

Você pode conceder aos integrantes da organização, colaboradores externos, e equipes de pessoas de diferentes níveis de acesso a repositórios pertencentes a uma organização, atribuindo-lhes funções.

• Leitura: recomendado para colaboradores que não modificam o código e que desejam ver ou discutir o projeto
• Triagem: recomendado para colaboradores que precisam gerenciar proativamente problemas, discussões e PRs sem acesso de gravação
• Gravação: recomendado para colaboradores que efetuam push ativamente para o projeto
• Manutenção: recomendado para gerentes de projetos que precisam gerenciar o repositório sem acesso a ações confidenciais ou destrutivas

• Administrador: recomendado para aqueles que precisam ter acesso completo ao projeto, incluindo ações confidenciais e destrutivas como gerenciar a segurança ou excluir um repositório

• Se a sua organização usar o GitHub Enterprise Cloud, você poderá criar funções de repositórios personalizadas.

• Os proprietários da organização têm acesso de administrador a todos os repositórios pertencentes à organização.

Funções predefinidas¶

• Leitura de todos os repositórios : concede acesso de leitura a todos os repositórios da organização.
• Gravação em todos os repositórios : concede acesso de gravação a todos os repositórios da organização.
• Triagem de todos os repositórios : concede acesso de triagem a todos os repositórios da organização.
• Manutenção de todos os repositórios : concede acesso de manutenção a todos os repositórios da organização.
• Administrador de todos os repositórios : concede acesso de administrador a todos os repositórios da organização.
• Administrador de CI/CD : concede acesso de administrador para gerenciar políticas de ações, executores, grupos de executores, configurações de rede de computação hospedada, segredos, variáveis ​​e métricas de uso para uma organização.

Resumo dos Planos¶

Times/Equipes¶

As equipes são grupos de membros da organização que refletem a estrutura da sua empresa ou do grupo com menções e permissões de acesso em cascata. Os proprietários da organização e os mantenedores da equipe podem conceder às equipes acesso de administrador, de leitura ou de gravação aos repositórios da organização. As equipes só podem ser compostas por membros da sua organização. Colaboradores externos não podem estar em uma equipe.

Tipos de Repositórios¶

Um repositório contém todos os arquivos do seu projeto e o histórico de revisão de cada arquivo. Um repositório contém todos os arquivos do seu projeto e o histórico de revisão de cada arquivo. Ao criar um repositório, você pode definir um proprietário, normalmente é o da conta.

• Os repositórios públicos são acessíveis a todos na Internet;
• Os repositórios privados só podem ser acessados por você, por pessoas com quem você compartilha explicitamente o acesso no caso de repositórios de organizações, por determinados membros da organização.

Uma vez que sua conta estiver ativa, você poderá criar repositórios. Existem dois tipos principais:

• Repositórios Públicos: Qualquer pessoa pode ver e contribuir. Ideal para projetos open source ou quando você deseja compartilhar seu trabalho com a comunidade.
• Repositórios Privados: Apenas você e as pessoas que você convidar poderão ver o conteúdo. Útil para projetos que requerem confidencialidade.

Repositórios¶

Comparação de Funcionalidades¶

• GitHub Exemplo
• Você pode atribuir proprietários de código diferentes para diferentes branches, como octo-org/codeowners-team para uma base de código no branch padrão e @octocat para um site do GitHub Pages no branch gh-pages.
• Para proteger totalmente um repositório contra alterações não autorizadas, você também precisa definir um proprietário para o próprio arquivo CODEOWNERS. O método mais seguro é definir um arquivo CODEOWNERS no diretório .github do repositório e definir o proprietário do repositório como o proprietário do arquivo CODEOWNERS (/.github/CODEOWNERS @owner_username) ou de todo o diretório (/.github/ @owner_username).
• Você pode criar um repositório especial, colocando o mesmo nome da conta: s60pportunities.

**/logs @octocat
/apps/ @octocat
/apps/* @octocat
/scripts/ @doctocat @octocat

• IA: a produtividade por meio do Copilot e a segurança automatizando verificações de segurança mais rapidamente. Colaboração: Repositórios, Problemas, Pull Requests e outras ferramentas ajudam a habilitar desenvolvedores, gerentes de projeto, líderes de operações e outros na mesma empresa.
• Produtividade: a plataforma oferece aos usuários a capacidade de configurar tarefas e esquecê-las, cuidando da administração rotineira e acelerando o trabalho diário.
• Segurança: recursos de segurança nativos e internos que minimizam o risco de segurança com uma solução de segurança criada internamente.seu código permanece privado dentro da sua organização. usufruir da visão geral de segurança e o Dependabot. Escala:

Na sua página de repositório do Github você pode:

• Commit: Um commit no Git é como uma captura de tela do seu repositório em um momento específico. Quando você faz um commit, está salvando o estado atual do seu projeto, incluindo todas as alterações feitas nos arquivos. Cada commit tem um identificador único (um hash SHA) e geralmente inclui uma mensagem de commit que descreve as alterações realizadas.
• Branching: Branching permite que você se desvie da linha principal de desenvolvimento e continue trabalhando sem afetar essa linha principal. Você pode criar um branch para trabalhar em uma nova funcionalidade, corrigir um bug ou experimentar novas ideias. Uma vez que seu trabalho no branch esteja completo, você pode mesclá-lo de volta ao branch principal (geralmente chamado de main ou master).
• Remote: Um remote no Git é uma versão do seu projeto que está hospedada na internet ou em outra rede. Ele permite que você colabore com outras pessoas, enviando seus commits para o repositório remoto e puxando alterações dele. Repositórios remotos comuns incluem GitHub, GitLab e Bitbucket.

• GitHub Flow: O GitHub Flow é um fluxo de trabalho leve, baseado em branches, que suporta equipes e projetos onde os deploys são feitos regularmente. Aqui está uma versão simplificada dos passos envolvidos:

  • Criar um branch: Comece criando um novo branch a partir do branch main para o seu trabalho.
  • Adicionar commits: Faça alterações e faça commits no seu branch.
  • Abrir um pull request: Quando seu trabalho estiver pronto, abra um pull request para mesclar suas alterações no branch main.
  • Discutir e revisar: Os membros da equipe revisam o pull request, discutem as alterações e fazem as atualizações necessárias.
  • Mesclar: Após a aprovação, mescle o pull request no branch main.
  • Deploy: Faça o deploy das alterações para a produção.

Danger Zone¶

A Danger Zone contém ações que você precisa pensar duas vezes porque elas não podem ser desfeitas. - [x] Alterar a visibilidade do repositório - [x] Quando você torna um repositório privado privado para público: - [x] O código ficará visível para todos que podem visitar - [x] Qualquer um pode bifurcar seu repositório. - [x] Todos os conjuntos de regras de push serão desabilitados. - [x] Suas alterações serão publicadas como atividade. - [x] Desabilitar regras de proteção de branch - [x] As regras de proteção de branch são regras rígidas de fluxo de trabalho, como proibir qualquer pessoa de fazer push para o principal. - [x] Você pode desabilitar todas as proteções temporariamente, por exemplo. Para correções rápidas - [x] Transferir propriedade - [x] Quando você quer que outra pessoa seja a proprietária do repositório. Danger Zone - [x] Alterar a visibilidade do repositório - [x] Este repositório é público no momento. - [x] Desabilitar regras de proteção de branch - [x] Desabilitar a aplicação de regras de proteção de branch e APIs - [x] Transferir propriedade - [x] Alterar a visibilidade - [x] Desabilitar regras de proteção de branch

Como criar um modelo de repositório¶

• Crie um repositório: comece criando um novo repositório ou usando um existente que você deseja transformar em um modelo. Marcar como modelo: vá para as configurações do repositório e marque a caixa rotulada "Repositório de modelo". Use o modelo: ao criar um novo repositório, você pode selecionar o repositório de modelo para copiar sua estrutura e arquivos.

• Quando você cria um novo repositório a partir de um modelo, o GitHub copia os arquivos e diretórios do modelo para o novo repositório. Isso inclui:

  • Todos os arquivos e diretórios: toda a estrutura do arquivo é replicada.
  • Ramificações: todas as ramificações do modelo são copiadas.
  • Commits: O histórico de commits não é copiado, garantindo que o novo repositório comece com um histórico limpo.

• Iniciadores de projeto: Crie modelos para diferentes tipos de projetos (por exemplo, aplicativos da web, bibliotecas, documentação) para garantir consistência.

• Integração: Novos membros da equipe podem se atualizar rapidamente começando com uma configuração de projeto padronizada.

• Melhores práticas: Incorpore as melhores práticas e as configurações necessárias no modelo para garantir que todos os projetos as sigam.

• Os modelos de repositório são uma ótima maneira de otimizar seu fluxo de trabalho e manter a consistência em vários projetos. Se você tiver alguma dúvida específica sobre o uso de modelos de repositório, sinta-se à vontade para perguntar!

Repositório Especial do Perfil¶

Crie um repositório com o MESMO nome do usuario e adicione o arquivo README.md, ele sempre aparecerá no perfil do usuário logado, não sendo apenas um BIO e podendo escrever mais sobre você.

Arquivos Comuns¶

Repositórios¶

Um repositório é o elemento mais básico do GitHub.

Práticas Recomendadas¶

• Um README, junto com uma licença de repositório, um arquivo de citação, diretrizes de contribuição e um código de conduta, comunica as expectativas do projeto e ajuda você a gerenciar contribuições.
• Os arquivos README são um ótimo lugar para descrever o projeto com mais detalhes ou adicionar alguma documentação (por exemplo, como instalar ou usar o projeto). O conteúdo do arquivo README é mostrado automaticamente na página inicial do repositório.
• Recomenda-se que os colaboradores regulares trabalhem em um único repositório, criando solicitações de pull entre branches em vez de entre repositórios.
• O uso de fork é mais adequado para aceitar contribuições de pessoas não afiliadas a um projeto, como colaboradores de código aberto.
• Para otimizar o desempenho recomenda-se usar o Git Large File Storage (Git LFS).
• Você pode criar um repositório através de uma URL, por exemplo: https://github.com/new?name=sabado&owner=xxxxx&description=sabado+manha&visibility=private

Repositórios de modelos¶

Você pode criar um modelo a partir de um repositório existente. Qualquer pessoa com acesso ao repositório de modelos pode criar um novo repositório baseado no modelo com a mesma estrutura de diretórios, branchs e arquivos.

• Criar um repositório a partir de um modelo é semelhante a bifurcar um repositório, porem um modelo começa com um único commit, um repositório criado de um modelo aparecem no gráfico de contribuição.
• Em ma bifurcação pode ser uma maneira temporária de contribuir com código em um projeto existente, enquanto criar um repositório de um modelo inicia um novo projeto rapidamente.

Repositório somente com problemas¶

O GitHub não fornece permissões de acesso somente a problemas. Para contornar isso, sugere-se que seja criado um repositório privado para o projeto e outro segundo repositório com as permissões que deseja para hospedar o rastreador de problema. Se você efetuar push de um commit para o branch padrão do repositório privado com a mensagem Fixes organization/public-repo#12, o problema será fechado, mas apenas os usuários com as permissões adequadas verão a referência entre repositórios indicando o commit que fechou o problema. Sem as permissões, uma referência continua aparecendo, mas os detalhes são omitidos.

Duplicar um repositório¶

Para manter um espelho de um repositório sem a bifurcação, é possível executar um comando especial de clone e, em seguida, fazer push do espelho para o novo repositório.

git clone --bare https://github.com/EXAMPLE-USER/OLD-REPOSITORY.git
cd OLD-REPOSITORY
git push --mirror https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git
cd ..
rm -rf OLD-REPOSITORY
OU
cd REPOSITORY-TO-MIRROR
git remote set-url --push origin https://github.com/EXAMPLE-USER/MIRRORED
git fetch -p origin
git push --mirror

Clonar um repositório¶

Ao clonar um repositório, ele é copiado do GitHub.com para seu computador local.

gh repo clone REPOSITORY
gh repo clone https://github.com/PATH-TO/REPOSITORY

Renomear um repositório¶

Você poderá renomear um repositório se for proprietário da organização ou tiver permissões de administrador no repositório. Quando você renomear um repositório, todas as informações existentes, com exceção das URLs do site do projeto, serão automaticamente redirecionadas para o novo nome, incluindo: Problemas, Wikis,Estrelas e Seguidores. Se você planeja renomear um repositório que tenha um site do GitHub Pages , recomendamos usar um domínio personalizado para o seu site. Caso seja necessário ajuste: git remote set-url origin NEW_URL

Transferir um repositório¶

É possível transferir repositórios para outros usuários ou contas da organização. Para transferir um repositório, você deve ter acesso de administrador ao repositório. Para transferir um repositório que você possui para uma organização, é preciso ter permissão para criar um repositório na organização de destino. O proprietário original do repositório é adicionado como colaborador no repositório transferido. Outros colaboradores do repositório transferido ficam intactos.

O que é transferido com um repositório?¶

Quando você transfere um repositório, também são transferidos problemas, pull requests, wiki, estrelas e inspetores. Quando você transfere um repositório de uma organização para uma conta pessoal, os colaboradores somente leitura do repositório não serão transferidos.

Transferências de repositório e organizações¶

Para transferir repositórios para uma organização, é preciso ter permissões de criação de repositórios na organização recebedora.

Transferir um repositório pertencente à sua conta pessoal¶

Quando um repositório é transferido entre duas contas pessoais, o proprietário e os colaboradores do repositório original são automaticamente adicionados como colaboradores ao novo repositório.

Excluir um repositório¶

Você poderá excluir qualquer repositório ou bifurcação se for proprietário da organização ou tiver permissões de administrador para o repositório ou a bifurcação. A exclusão de um repositório bifurcado não elimina o repositório upstream. Alguns repositórios excluídos podem ser restaurados dentro de 90 dias de exclusão.

Gerenciar configurações do repositório¶

README¶

Adicionar um arquivo README a um repositório para comunicar informações importantes sobre o seu projeto. Os arquivos README geralmente incluem informações sobre: - [x] O que o projeto faz - [x] Por que o projeto é útil - [x] Como os usuários podem começar a usar o projeto - [x] Onde os usuários podem obter ajuda com seu projeto - [x] Quem mantém e contribui com o projeto

• Se um repositório contiver mais de um arquivo README, o arquivo mostrado nos links será escolhido nos locais na seguinte ordem: o diretório .github, o diretório raiz do repositório e, por fim, o diretório docs.
• README for visualizado no GitHub, qualquer conteúdo além de 500 KiB será truncado.

Stars Repo¶

Semelhante ao bookmarking, é uma maneira de marcar um repositório como interessante ou de acompanhá-lo para referência. As estrelas são públicas e podem ser vistas por todos, geralmente usadas como uma medida da popularidade de um projeto. Você encontra facilmente as páginas que marcou com estrela em: https://github.com/stars

Watch Repo¶

Observar um repositório permite que você fique informado sobre as atividades que ocorrem dentro de um repositório. Na sua conta do Github, você pode especificar como deseja ser notificado: On Github ou e-mail.

Features Preview¶

As visualizações de recursos permitem que você habilite ou desabilite recursos que estão em beta na sua conta pessoal.

Tags¶

A marcação(tag) é usada para capturar um ponto no histórico para marcar o lançamento da versão da sua base de código. O GitHub facilita a exploração de versões marcadas do repositório Git. Versões são iterações de software implementáveis que você pode empacotar e disponibilizar para um público mais amplo para baixar e usar. As versões são baseadas em tags do Git, que marcam um ponto específico no histórico do repositório. Qualquer pessoa com acesso de leitura a um repositório pode ver e comparar versões, mas somente pessoas com permissões de gravação a um repositório podem gerenciar versões. Se uma versão consertar uma vulnerabilidade de segurança, você deverá publicar uma consultoria de segurança no seu repositório, pode enviar notificação aos repositórios através dependabot alert.

Gerenciar versões em repositórios¶

criar versões com notas sobre a versão, @mentions de colaboradores e links para arquivos binários, além de editar ou excluir as versões existentes. O GitHub incluirá automaticamente links para baixar um arquivo zip e um tarball contendo o conteúdo do repositório no ponto de criação da tag.

gh release create TAG
gh release create v1.3.2 --title "v1.3.2 (beta)" --notes "this is a versão prévia pública release" --prerelease
gh release edit TAG -t "NEW-TITLE"
gh release delete TAG -y

Pesquisar sintaxe para versões em um repositório¶

• draft:true
• draft:false
• prerelease:true
• prerelease:false
• tag:TAG
• created:DATE

Vincular versões¶

Você pode compartilhar um link para a versão mais recente de um repositório adicionando releases/latest ao final da URL de um repositório. Por exemplo, o URL da versão mais recente do octo-org/octo-repo é https://github.com/octo-org/octo-repo/releases/latest. Para vincular diretamente a um download do seu ativo de versão mais recente que foi carregado manualmente, o sufixo é /releases/latest/download/asset-name.zip

Comparando versões¶

Você pode comparar as tags de versão para ver as alterações no seu repositório entre diferentes versões.

Gerenciando equipes e pessoas¶

Na visão geral, você também pode convidar novas equipes ou pessoas, alterar a função de cada equipe ou pessoa para o repositório ou remover o acesso ao repositório.

Gerenciando a política de bifurcação para seu repositório¶

Você pode permitir ou impedir a criação de fork de um repositório particular pertencente a uma organização.

Gerenciando avaliações de pull request no seu repositório¶

Por padrão, em repositórios públicos, qualquer usuário pode enviar análises que aprovem ou solicitem alterações em um pull request. Você pode limitar os usuários que podem enviar análises que aprovem ou solicitem alterações em pull requests no seu repositório público.

Ao habilitar os limites de revisão de código, qualquer pessoa pode comentar sobre pull requests no seu repositório público, mas apenas as pessoas com acesso de leitura ou superior podem aprovar pull requests ou solicitar alterações.

Gerenciar a política de aprovação de confirmação para seu repositório¶

As aprovações de commit permitem que os usuários afirmem que um commix t está em conformidade com as regras e o licenciamento que regem um repositório.

Gerenciar a política de push do repositório¶

É possível limitar o número de branches e marcas que podem ser atualizados em um único push para bloquear pushes potencialmente destrutivos. Isso pode evitar ou limitar a perda de dados. O default é 5. O valor mínimo é 2 porque o Git requer duas atualizações de branch para renomear um branch em um único push: excluir branch e criar branch.

Gerenciando objetos LFS do Git¶

Por padrão, os objetos Git LFS não estão incluídos nesses arquivos, apenas os arquivos de ponteiro para esses objetos. Para serem incluídos, os objetos Git LFS devem ser cobertos por regras de rastreamento em um arquivo .gitattributes com commit no repositório. Cada download desses arquivos contará para o uso de largura de banda de sua conta.

Cota de largura de banda¶

Se você usar mais de 1 GiB de largura de banda por mês sem comprar um pacote de dados, o suporte do Git LFS será desabilitado na sua conta até o próximo mês.

Notificações de e-mail para pushes no seu repositório¶

Você pode optar por enviar notificações por email automaticamente para um endereço de email específico quando alguém fizer push para o repositório.

links automáticos para fazer referência a recursos externos¶

Os links automáticos estão disponíveis em repositórios com o GitHub Pro, o GitHub Team, o GitHub Enterprise Cloud e o GitHub Enterprise Server

Arquivar repositórios¶

Arquivar um repositório a fim de torná-lo somente leitura para todos os usuários e indicar que ele não está mais sendo mantido ativamente. Quando um repositório é arquivado, seus problemas, pull requests, código, etiquetas, marcos, projetos, wiki, versões, commits, tags, branches, reações, alertas de varredura de código, comentários e permissões tornam-se somente leitura.

Referenciar e citar conteúdo¶

Você pode usar ferramentas de terceiros para citar e referenciar conteúdo no GitHub.

• Use a ferramenta de arquivamento de dados Zenodo para arquivar um repositório no GitHub e emitir um DOI para os arquivos.
• Os projetos de pesquisa acadêmica podem usar o serviço de gerenciamento de dados Figshare

Branches e Mesclagem¶

Você pode É possível renomear um branch em um repositório ou através do comando.

git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
git fetch origin
git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
git remote set-head origin -a
git remote prune origin

Alterar o branch-padrão¶

O branch-padrão é o branch de base para pull requests e commits de código.

Configurar PR¶

Você pode permitir que os contribuidores com acesso push no repositório mesclem as pull requests com diferentes opções de mesclagem ou apliquem um método de mesclagem específico a todas as pull requests do repositório.

Para mesclar as solicitações de pull, você precisa ter permissões de gravação no repositório. O método de merge padrão cria um commit de mesclagem.

Combinar por squash os commits de merge¶

Combinar por squash e mesclar em uma solicitação de pull, os commits da solicitação de pull são combinados por squash em um só commit.

Para mesclar por squash e mesclar solicitações de pull, você precisa ter permissões de gravação no repositório, e o repositório precisa permitir a mesclagem squash.

Fazer rebase e merge de seus commits¶

Quando você seleciona a opção Troca de base e mesclagem em uma solicitação de pull, todos os commits da ramificação do tópico (ou da ramificação principal) são adicionados à ramificação base individualmente, sem um commit de mesclagem.

Como gerenciar uma fila de mesclagem¶

Uma fila de mesclagem ajuda a aumentar a velocidade automatizando mesclagens de solicitação de pull em um branch ocupado e garantindo que o branch nunca seja interrompido por alterações incompatíveis.

Uma fila de mesclagem pode usar GitHub Actions ou o próprio provedor de CI para executar as verificações necessárias nas solicitações de pull em uma fila de mesclagem. Para obter mais informações, confira "Documentação do GitHub Actions".

Notas de versão geradas automaticamente¶

# .github/release.yml
changelog:
  exclude:
    labels:
      - ignore-for-release
    authors:
      - octocat
  categories:
    - title: Mudanças Importantes 🛠
      labels:
        - Semver-Major
        - breaking-change
    - title: Novas Funcionalidades 🎉
      labels:
        - Semver-Minor
        - enhancement
    - title: Outras Mudanças
      labels:
        - "*"

Licenciar (LICENSE.md)¶

Uma licença de software descreve o que pode e não pode ser feito com seu código-fonte, assim é importante tomar uma decisão fundamentada.

Alguns projetos incluem as informações sobre a licença no README.

Botão de patrocinador no repositório¶

Pode adicionar um botão do patrocinador no repositório para aumentar a visibilidade das opções de financiamento do seu projeto de código aberto. Configure o botão de patrocinador editando um arquivo FUNDING.yml na pasta .github do repositório, no branch padrão.

Classificando seu repositório com tópicos¶

Para ajudar outras pessoas a encontrar e contribuir com seu projeto, você pode adicionar tópicos ao seu repositório relacionados à finalidade pretendida do seu projeto, área de assunto, grupos de afinidade ou outras qualidades importantes. Os administradores do repositório podem adicionar quaisquer tópicos que desejarem a um repositório. Repositórios públicos e privados podem ter tópicos, embora você só verá repositórios privados aos quais você tem acesso nos resultados da pesquisa de tópicos. Você pode contribuir para o conjunto de tópicos em destaque do GitHub no repositório github/explore. Os administradores de repositório podem adicionar qualquer tópico que desejarem a um repositório. Os repositórios público e privado podem ter tópicos, embora você veja apenas repositórios privados aos quais você tem acesso nos resultados de pesquisa de tópicos.x`

CODEOWNERS¶

Para definir indivíduos ou equipes responsáveis ​​pelo código em um repositório. As pessoas que você escolher como donos do código devem ter permissões de gravação para o repositório. Pessoas com permissões de administrador ou proprietário podem exigir que as solicitações de pull sejam aprovadas pelos donos do código antes que possam ser mescladas. Os proprietários do código são automaticamente solicitados para revisão quando alguém abre uma solicitação de pull que modifica o código que eles possuem. Quando você marca uma solicitação de pull de rascunho como pronta para revisão, os proprietários do código são automaticamente notificados. Se você converter uma solicitação de pull em um Crie um arquivo chamado CODEOWNERS na raiz, em .github/ ou no diretório docs/ do repositório, no branch em que deseja adicionar os proprietários de código. Para que os proprietários do código recebam solicitações de revisão, o arquivo CODEOWNERS deve estar no branch base da pull request. O usuário receberá solicitações de revisão quando uma solicitação de pull com alterações em arquivos .js for aberta entre o branch principal e gh-pages.

Tamanho do arquivo CODEOWNERS¶

Os arquivos CODEOWNERS devem ter menos de 3 MB. Para reduzir o tamanho do seu arquivo CODEOWNERS, considere o uso de padrões curinga para consolidar múltiplas entradas em uma única entrada. usa um padrão que segue a maioria das mesmas regras usadas em arquivos .gitignore. O padrão é seguido por um ou mais nomes de usuário ou nomes de equipes do GitHub usando o padrão @username ou o formato org/team-name ou user@example.com.Não é possível usar um endereço de email para se referir a um conta de usuário gerenciada. Quando houver MAIS proprietários de código precisam estar na mesma linha. Os usuários e as equipes precisam ter acesso write explícito ao repositório, mesmo se os membros da equipe já têm acesso. Os caminhos dos CODEOWNERS diferenciam maiúsculas de minúsculas, porque GitHub usa um sistema de arquivos que diferencia maiúsculas e minúsculas.

O método mais seguro é definir um arquivo CODEOWNERS no diretório .github do repositório e definir o proprietário do repositório como o proprietário do arquivo CODEOWNERS (/.github/CODEOWNERS @owner_username) ou de todo o diretório (/.github/ @owner_username).

Proteger seu repositório¶

Proprietários de código¶

As pessoas que você escolhe como proprietários do código devem ter permissões de gravação para o repositório. Quando o proprietário do código é uma equipe, essa equipe deverá ser visível e ter permissões de gravação, ainda que todos os membros individuais da equipe já tenham permissões de gravação diretamente, por meio da associação da organização ou por meio de outra associação à equipe.

Local do arquivo CODEOWNERS¶

Para usar um arquivo CODEOWNERS, crie um arquivo chamado CODEOWNERS na raiz, em .github/ ou no diretório docs/ do repositório, no branch em que deseja adicionar os proprietários de código.

Se arquivos CODEOWNERS existirem em mais de um desses locais, o GitHub os procurará nessa ordem e usará o primeiro que encontrar. Cada arquivo CODEOWNERS atribui os proprietários do código para um único branch no repositório. Os arquivos CODEOWNERS devem ter menos de 3 MB. Um arquivo CODEOWNERS acima deste limite não será carregado, o que significa que as informações do proprietário do código não serão mostradas e não será solicitado que os proprietários do código apropriado revise as alterações em um pull request.

Os caminhos dos CODEOWNERS diferenciam maiúsculas de minúsculas. Se contiver uma sintaxe inválida, essa linha será ignorada.

Para reduzir o tamanho do seu arquivo CODEOWNERS, considere o uso de padrões curinga para consolidar múltiplas entradas em uma única entrada.

Proteção de branch e de CODEOWNERS¶

Para proteger totalmente um repositório contra alterações não autorizadas, você também precisa definir um proprietário para o próprio arquivo CODEOWNERS. O método mais seguro é definir um arquivo CODEOWNERS no diretório .github do repositório e definir o proprietário do repositório como o proprietário do arquivo CODEOWNERS (/.github/CODEOWNERS @owner_username) ou de todo o diretório (/.github/ @owner_username).

Linguagens do repositório¶

O GitHub usa a biblioteca Linguist de código aberto para determinar as linguagens do arquivo para realce de sintaxe e estatísticas de repositório. O GitHub usa a biblioteca Linguist de código aberto para determinar as linguagens do arquivo para realce de sintaxe e estatísticas de repositório. Linguist só funciona nos repositórios com menos de 100 mil arquivos.

Linguagens markup¶

Arquivos de CITATION¶

Você pode adicionar um arquivo CITATION.cff à raiz de um repositório para que outras pessoas saibam como você deseja que elas citem seu trabalho. O formato do arquivo de citação é um texto simples com informações de citação legíveis por pessoas e máquinas.

Desabilitar problemas¶

Se você não aceita contribuições ou relatórios de erros, convém desativar problemas do seu repositório. Configurações → "Recursos", desmarque Problemas.

Desabilitar projetos em um repositório¶

Os administradores do repositório poderão desativar projects para um repositório se você ou sua equipe tiverem optado por não usar projetos.

Gerenciando as configurações do GitHub Actions para um repositório¶

Por padrão, o GitHub Actions é habilitado em todos os repositórios e organizações.

GitHub Discussions¶

Como GitHub Discussions é um fórum aberto, há a oportunidade de trazer uma colaboração que não seja de código para o repositório ou a organização de um projeto e coletar diversos comentários e ideias mais rapidamente.

Pessoas com permissões de administrador para um repositório podem habilitar as Discussões do GitHub para o repositório. Você também pode usar discussões de organização para facilitar conversas que abrangem vários repositórios em sua organização.

• Você deseja manter correções de erros, solicitações de recursos e conversas gerais separadas
• Você quer medir o interesse em novas ideias e avaliar a opinião da comunidade usando votações
• Discussões da organização OU REPOSITÓRIO.
• Verifique se o repositório tem diretrizes de colaboração - CONTRIBUTING.md
• É possível acessar facilmente todas as discussões que você criou ou participou. (home → Discussions)
• Contribuidores mais úteis dos últimos 30 dias são destacados;
• Fechar uma discussão quando a discussão foi resolvida, não é mais relevante ou é uma duplicata.
• Se um administrador de repositório ou mantenedor do projeto habilitar GitHub Discussions para um repositório, qualquer pessoa que tiver acesso ao repositório poderá criar e participar de discussões do repositório.
• Os administradores de repositório e mantenedores de projetos podem gerenciar as discussões e categorias de discussão em um repositório e fixar discussões para aumentar a visibilidade da discussão.
• Pessoas com acesso de leitura* a um repositório podem participar de discussões e enquetes no repositório. - - [ ] Pessoas com acesso de leitura ao repositório de origem para discussões da organização podem participar de discussões e enquetes naquela organização.
• Você pode bloquear usuários e reportar conteúdo disruptivo para manter um ambiente seguro e agradável para você mesmo em GitHub.
• Administradores de repositório e pessoas com triagem ou maior acesso a um repositório podem gerenciar discussões no repositório.
• Administradores de repositório e pessoas com triagem ou maior acesso ao repositório de origem para discussões da organização podem gerenciar discussões na organização.
• Os proprietários da organização podem escolher as permissões necessárias para criar uma discussão em repositórios pertencentes à organização.

Práticas recomendadas para GitHub Discussions¶

• Como integrante ou mantenedor da comunidade, inicie uma discussão para fazer uma pergunta ou discutir informações que afetem a comunidade.
• Se um problema for uma pergunta ou conversa aberta em vez de um item de trabalho para rastrear e priorizar, você poderá converter o problema em uma discussão.
• você pode criar um novo problema a partir de uma discussão.

Configurações de segurança e análise do repositório¶

Pessoas com permissões de administrador para um repositório podem gerenciar as configurações de segurança e análise do repositório. Os alertas de segurança de um repositório são visíveis para pessoas com acesso de gravação, manutenção ou administração ao repositório e, quando o repositório pertencer a uma organização, para os proprietários da organização.

Gerenciar configurações do repositório¶

Tornar um repositório privado¶

• GitHub desanexará os forks públicos do repositório público e os colocará em uma nova rede.(Bifurcações públicas não se tornam privadas).
• Alguns recursos não estarão disponíveis no repositório depois de alterar a visibilidade para privada. (Free vs Pro)
• Qualquer site publicado do GitHub Pages terá sua publicação cancelada automaticamente.
• Code scanning, irão parar de funcionar Para obter mais informações.

Tornar um repositório público¶

• Receberá acesso aos recursos de GitHub Advanced Security;
• O histórico e logs do Actions ficarão visíveis para todos.

Entenda as Consequencias¶

Alterar de público para privado¶

• Estrelas e observadores deste repositório serão apagados permanentemente, o que afetará as classificações do repositório.
• regras de alerta personalizadas de Dependabot serão desabilitadas;
• A verificação de código ficará indisponível.

Alterar de privado para público¶

• O código ficará visível para todos
• Qualquer pessoa pode bifurcar seu repositório.
• Suas alterações serão publicadas como atividade.
• O histórico e os logs do Actions ficarão visíveis para todos.
• Estrelas e observadores deste repositório serão apagados permanentemente.

Alterar de privado para interno¶

• Todos os membros da empresa terão acesso de leitura.
• Colaboradores externos não podem mais ser adicionados a bifurcações, a menos que sejam adicionados à raiz.
• Estrelas e observadores deste repositório serão apagados permanentemente.

Alterar de interno para privado¶

• Estrelas e observadores deste repositório serão apagados permanentemente,
• As regras de alerta personalizadas Dependabot serão desabilitadas,
• Verificação de código ficará indisponível.

Alterar de interno para público¶

• Estrelas e observadores deste repositório serão apagados permanentemente.
• O histórico e os logs do Actions ficarão visíveis para todos

Equipes e pessoas com acesso ao seu repositório¶

Política de aprovação de confirmação para seu repositório¶

Proprietários de organizações e administradores de repositórios podem exigir que todos os commits em um repositório sejam assinados pelo autor do commit.

Política de push do repositório¶

É possível limitar quantos branches e marcas podem ser atualizados em um único push.

Gerenciando objetos LFS do Git em arquivos do seu repositório¶

Estão incluídos nos arquivos de código-fonte, como arquivos ZIP e tarballs que GitHub cria para seu repositório.

Notificações de e-mail para pushes no seu repositório¶

Pessoas com permissões de administrador em um repositório podem habilitar notificações por e-mail para envios para seu repositório. Cada notificação de e-mail para um push no repositório lista os novos commits e os vincula a um diff contendo apenas esses commits.

Pesquisa no GitHub¶

É possível criar consultas que correspondam a palavras e números específicos. Com qualificadores de código especializados, expressões regulares e operações boolianas.

Repositórios¶

• Good First Issue : Identificar problemas que são adequados para novos contribuidores ou aqueles que não têm muita experiência com o projeto. Use este rótulo quando você tiver problemas que deseja que novos contribuidores abordem.
• Help Wanted : Indicar que um projeto precisa de ajuda em geral, podendo ser para uma variedade de tarefas. Use este rótulo quando precisar de ajuda adicional no projeto, seja para problemas mais complexos ou tarefas que ainda não foram atribuídas a ninguém.

Topicos¶

Problemas e Pull Request¶

Ordenações¶

Excluir resultados que correspondam a um qualificador¶

Excluir resultados com palavras-chave específicas¶

Limitações no tamanho da consulta¶

Há alguns limites no tamanho das consultas ao pesquisar no GitHub:

• Não são aceitas consultas com mais de 256 caracteres;
• Não é possível construir uma consulta usando mais de cinco operadores AND, OR ou NOT;

Palavras chaves no PR¶

Você pode utilizar as palavras chaves no PR e terá ação, quando este for executado para a branch principal.

Criando um link permanente para um snippet de código¶

No GitHub, navegue até a página principal do repositório. Localize o código que você gostaria de vincular: Escolha se deseja selecionar uma única linha ou um intervalo. À esquerda da linha ou intervalo de linhas, clique em .... No menu suspenso, clique em Copiar permalink. Navegue até a conversa onde você deseja criar um link para o snippet de código. Cole seu permalink em um comentário e clique em Comentar . Acrescente #Lo número da linha ou números no final da url. Por exemplo, github.com///blob//README.md?plain=1#L14

Usando palavras-chave em problemas e solicitações de pull¶

Para vincular uma solicitação de pull a um problema para mostrar que uma correção está em andamento e para fechar o problema automaticamente quando alguém mesclar a solicitação de pull, digite uma das seguintes palavras-chave seguidas por uma referência ao problema. Por exemplo, Closes #10ou Fixes octo-org/octo-repo#100.

Comandos Barra¶

Os comandos de barra "/" em qualquer campo de descrição ou de comentário em problemas, solicitações de pull ou discussões em que há suporte para o comando de barra "/".

Comandos de Barra¶

Os comandos Slash (dentro das caixas de comentários) no GitHub.com fornecem recursos convenientes, como formatação de markdown. Os comandos de barra facilitam a digitação de Markdown mais complexos, como tabelas, listas de tarefas e blocos de código.

Github FLow¶

• Comece criando uma ramificação para que as alterações, recursos e correções que você criar não afetem a ramificação principal.
• Em seguida, faça suas alterações. Recomendamos implantar alterações no branch do recurso antes de mesclar no branch principal. Fazer isso garante que as alterações sejam válidas em um ambiente de produção.
• Agora, crie uma solicitação de pull para pedir feedback aos colaboradores. A revisão de pull request é tão valiosa que alguns repositórios exigem uma revisão de aprovação antes que os pull requests possam ser mesclados.
• Em seguida, revise e implemente o feedback dos seus colaboradores.
• Quando você se sentir satisfeito com suas alterações, é hora de aprovar sua solicitação de pull e mesclá-la ao branch principal.
• Por fim, você pode excluir sua ramificação. Excluir sua ramificação sinaliza que seu trabalho nela foi concluído e evita que você ou outras pessoas usem ramificações antigas acidentalmente. O fluxo de GitHub é um fluxo de trabalho leve e baseado no branch. Por meio de plataformas como GitHub, o Git também oferece mais oportunidades para transparência e colaboração do projeto. Repositórios públicos ajudam as equipes a trabalhar juntas para criar o melhor produto final possível.

Desenvolvimento Colaborativo¶

Existem duas formas principais por meio das quais as pessoas colaboram em GitHub: - [x] Repositório compartilhado: os indivíduos e as equipes são explicitamente designados como contribuidores com acesso de leitura, gravação ou administrador - [x] Bifurcação e pull

Comparações¶

Trabalhar com Arquivos¶

Maneiras de contribuir¶

Acesse github.com/topics/. Por exemplo, se você estiver interessado em machine learning, encontre projetos relevantes e bons primeiros problemas acessando https://github.com/topics/machine-learning.

Se você já souber em qual projeto deseja trabalhar, encontre problemas para iniciantes nesse repositório acessando github.com///contribute. Por exemplo, você pode encontrar maneiras de fazer sua primeira contribuição com electron/electron em https://github.com/electron/electron/contribute.

Abrir um problema: Verifique se o problema já não esta aberto. Testando um pull request Você pode contribuir para um projeto de código aberto, fazendo o merge de um pull request na sua cópia local do projeto e testando as alterações. Adicione o resultado do seu teste em um comentário no pull request.

Opcionalmente, selecione Copiar somente o branch PADRÃO. Para muitos cenários de bifurcação, como contribuir para projetos de código aberto, você só precisa copiar o branch padrão. Se você não selecionar essa opção, todos os branches serão copiados para o novo fork.

Para fazer isso, acesse o repositório GitHub onde seu projeto encontra-se. Neste exemplo, ele estará em https://github.com//Spoon-Knife. Você verá uma notificação indicando que o branch está um commit à frente de octocat:main. Clique em Contribuir e em Abrir uma solicitação de pull.

O GitHub levará você para uma página que mostra as diferenças entre o fork e o repositório octocat/Spoon-Knife. Clique em Criar solicitação de pull.

GitHub levará você a uma página onde você pode inserir um título e uma descrição das suas alterações. É importante fornecer tantas informações úteis e uma razão para o motivo de você estar fazendo este pull request. O proprietário do projeto deve poder determinar se a sua alteração é tão útil para todos quanto você pensa. Por fim, clique em Criar solicitação de pull.

O proprietário do projeto deve poder determinar se a sua alteração é tão útil para todos quanto você pensa. Por fim, clique em Criar solicitação de pull.

Não se ofenda se o proprietário do projeto peça mais informaçõees,

Salvar repositórios como favoritos¶

A estrela facilita a localização posterior de um repositório ou tópico. Você pode ver todos os repositórios e tópicos marcados com estrelas acessando sua página de estrelas.

https://github.com/USERNAME?tab=stars

Organizar repositórios favoritos com listas¶

Se você adicionar um repositório privado a uma lista, o repositório privado só será exibido na sua lista para as pessoas com acesso read no repositório.

Seguir pessoas¶

É possível seguir pessoas no GitHub para receber notificações sobre as atividades delas e descobrir projetos nas comunidades em que estão inseridas. você verá as atividades públicas delas em seu painel pessoal.

Como seguir organizações¶

Ao seguir as organizações em GitHub, você verá a atividade pública no painel pessoal. Essa atividade inclui novas discussões, patrocínios e repositórios. Para obter mais informações, confira "Sobre seu painel pessoal".

Issues (Problemas)¶

Os problemas do GitHub foram criados para acompanhar ideias, comentários, tarefas ou bugs relacionados ao trabalho no GitHub. Se você for um mantenedor de projeto, poderá atribuir o problema a alguém, adicioná-lo a um quadro de projetos, associá-lo a um marco ou aplicar um rótulo.

Para a criação de Milestone e Lables, tenho que ir nos repositorios e depois issues.¶

Controlar a visibilidade do seu projeto - [x] Projeto será público ou privado. - [ ] Quando seu projeto é público, todos na Internet podem exibi-lo. - [ ] Quando o projeto é privado, somente os usuários que receberam pelo menos acesso de leitura podem vê-lo.

Você verá uma barra de progresso no topo da página do marco. Esta barra de progresso indica quantas issues já foram fechadas em comparação com o total de issues associadas ao marco. Essa barra de progresso fornece uma visão rápida do percentual de conclusão.

Issues vs Discussions vs Pull Requests¶

Issue Template¶

Os Issues Templates são modelos de markdown que são pré-carregados para novos Issues. Eles ajudam a garantir que os usuários que criam issues forneçam todas as informações relevantes e esperadas.

Você pode criar vários modelos de problemas para melhorar o contexto dos problemas:

Etapas para reproduzir¶

<!-- (Diretrizes para criar um relatório de bug estão [disponíveis
aqui] (https://edgeguides.rubyonrails.org/contributing_to_ruby_on_ra
<!-- Cole seu caso de teste executável criado a partir de um dos scripts (https://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.ht

# Seu script de reprodução vai aqui
Relatório de bug
Crie um relatório para nos ajudar a melhorar
Solicitação de recurso
Sugira uma ideia para este projeto
### Comportamento esperado
<!-- Diga-nos o que deve acontecer -->
### Comportamento real
<!-- Diga-nos o que acontece em vez disso -->
### Configuração do sistema
**Versão do Rails**:
**Versão do Ruby**:
Reportar uma vulnerabilidade de segurança Reportar uma vulnerabilidade de segurança.
Reportar uma vulnerabilidade

Issues Forms¶

Issues Forms is the evolution of Issues Templates. You use a YAML formatted file to create Issue forms for stricter entry of issue information.

name: Bug Report
description: File a bug report
title: "[Bug]:
labels: ["bug", "triage"]
projects: ["octo-org/1", "octo-org/44"]
assignees:
-
body:
octocat
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out
- type: input
id: contact
attributes:
label: Contact Details
description: How can we get in touch with
email@example.com
placeholde5:409:54:07 GitHub Issues >
validations:
Issue: Bug Report
File a bug report. If this doesn't look right, choose a different type.
[Bug]:
Thanks for taking the time to fill out this bug report!
Contact Details
How can we get in touch with you if we need more info?
ex. email@example.com
What happened?
Also tell us, what did you expect to happen?
A bug happened!
Version
BETA
HD
||
What version of our software are you running?

Pinning Issue¶

Até 3 problemas podem ser fixados para que apareçam no topo da página do problema.

Create Branch from a Issue¶

De um Issue, você pode criar uma ramificação associada. Criar uma ramificação para esta issue ou vincular uma solicitação de pull. Criar uma ramificação para esta issue

Um fluxo de trabalho comum é criar branches de Recurso ou Bug. Ao definir seus Problemas antecipadamente, você cria rapidamente esses branches:

• Definir Recurso ou Bug como Problema
• Criar Branch de Recurso/Bug

Label¶

GitHub Labels are used to categorize issues, pull requests, and discussions enhancement You can manage your labels or create new labels on the Labels page for your repo https://github.com///labels

Creating a label as simple as providing a: Name Description Colour

Github CLI provides commands for labels:

gh label clone
gh label create
gh label delete
gh label edit
gh label list
gh label create bug  --description "Something isn't working" --color E99695

Milestones¶

Permite que você agrupe vários problemas em uma meta final que mostre a conclusão em direção à meta para cada problema fechado.

Pull Request¶

Um Pull Request (PR) é um processo formal para apresentar alterações, que podem ser revisadas manual ou automaticamente antes de serem aceitas em sua ramificação base (principal).

• Benefícios de um Pull Request
• Revisão Colaborativa: Melhora a qualidade do código por meio de discussões em equipe e feedback de colegas.
• Rastreamento de Alterações: Fornece um registro de alterações de código e discussões relacionadas.
• Teste Automatizado: Permite a integração com ferramentas para verificações e testes automatizados.
• Integração Controlada: Gerencia a mesclagem segura e revisada de alterações de código.
• Amigável com Código Aberto: Simplifica as contribuições e a colaboração em projetos de código aberto.
• Um pull request não é um recurso do git, mas um fluxo de trabalho. Serviços como o GitHub podem automatizar o fluxo de trabalho do Pull Request

Podemos usar o Github CLI para criar uma solicitação de pull de uma ramificação.

git checkout -b cool-feature-branch git commit -am "Your commit message"
git push -u origin cool-feature-branch
gh pr create --base main --head cool-feature-branch

Definimos: - [x] Base - quem iremos fundir - [x] Cabeça - as mudanças a serem puxadas

Base e Compare¶

• Base e Compare determinam a direção da mesclagem para uma solicitação de pull
• Base é quem você quer mesclar
• Isso geralmente é o branch principal ou um branch específico do ambiente
• Compare é o que será mesclado no Base
• Compare é escolher uma referência de Head
• Isso geralmente é um branch de bug ou recurso

Você também pode comparar entre forks, é assim que um fork se mantém atualizado, ou como forks podem sugerir que você aceite suas alterações. Escolha dois branches para ver o que mudou ou para iniciar uma nova solicitação de pull. Se precisar, você também pode comparar entre forks ou aprender

Base e Compare determinam a direção da mesclagem para uma solicitação de pull Base é quem você quer mesclar: Este é geralmente o branch principal ou um Compare é o que será mesclado no Base Compare está escolhendo um Head ref ramificação específica do ambiente

Você também pode comparar entre forks, é assim que um fork se mantém atualizado, ou como forks podem sugerir que você aceite suas alterações. Escolha dois branches para ver o que mudou ou para iniciar uma nova solicitação de pull. Se precisar, você também pode comparar entre forks ou aprender repositório base: omenking/github-dump base: main▾ repositório head: omenking/github-dump Capaz de mesclar. Esses branches podem ser mesclados automaticamente. Agora você poderá escolher repositórios de forks compare: my-feature

Draft Pull Request¶

Um Draft Pull Request no GitHub é um recurso que permite que você abra um pull request, mas o marque como um trabalho em andamento (WIP).

Equipe Aprenda a abrir um rascunho de pull request sem pedir revisão formal ou correr o risco de mesclagens indesejadas:

• Indicando Work-in-Progress: Comunica que o pull request não está pronto para revisão ou mesclagem.
• Impedindo mesclagem prematura: Garante que o trabalho incompleto não seja mesclado acidentalmente.
• Facilitando o feedback e a colaboração antecipados: Permite o compartilhamento e a discussão antecipados de alterações de código.
• Teste de integração contínua: Habilita testes de Cl durante o processo de desenvolvimento.
• Transição para um estado pronto: Fácil troca de rascunho para pronto para revisão final e mesclagem.
• Organizando trabalho e prioridades: Ajuda a gerenciar e rastrear o trabalho em andamento em grandes projetos.

Draft Pull Requests é um recurso somente para Github Organizations Teams Os rascunhos de solicitações de pull não podem ser mesclados Os proprietários do código não são solicitados automaticamente a revisar os rascunhos de solicitações de pull

Status de Um Pull Request¶

Ao comentar, você está enviando uma revisão para ser considerada antes que um Pull Request seja aceito. Se você não for o autor, mas também um revisor designado, você pode solicitar alterações ou marcar o Pull Request como Aprovado para que ele possa ser considerado para mesclagem.

Commentando Pull Request¶

Ao mesclar uma solicitação de pull, há algumas opções 1. Criar um commit de mesclagem: Todos os commits serão adicionados Mesclar solicitação de pull 2. Esmagar e mesclar 1 commit será adicionado 3. Rebasear e mesclar 1 commit será adicionado e rebaseado

Criar um commit de mesclagem Todos os commits desta ramificação serão adicionados à ramificação base por meio de um commit de mesclagem. Esmagar e mesclar O 1 commit desta ramificação será adicionado à ramificação base.

Rebasear e mesclar O 1 commit desta ramificação será rebaseado e adicionado à ramificação base. O caso de uso depende do fluxo de trabalho da sua equipe. Eles podem preferir que apenas um único commit seja adicionado para manter a árvore git da ramificação base limpa e legível.

Merge Commit Descrição: Esta opção cria um novo commit de merge que une as branches. Comando Git: Após fazer o pull request e quando estiver pronto para fazer o merge, você pode usar:

bash
# Certifique-se de estar na branch de destino
git checkout main
# Puxe as alterações mais recentes da branch de destino
git pull origin main
# Faça o merge da branch de origem (ex: feature/nova-funcionalidade)
git merge feature/nova-funcionalidade
# Resolva quaisquer conflitos, se necessário
# Faça o push das alterações
git push origin main

Squash and Merge¶

Descrição: Combina todos os commits da branch de origem em um único commit. Comando Git: Para realizar um squash localmente antes de enviar, você pode usar:

bash
# Certifique-se de estar na branch de destino
git checkout main
# Puxe as alterações mais recentes da branch de destino
git pull origin main
# Faça o merge com squash
git merge --squash feature/nova-funcionalidade
# Isso prepara as alterações para um único commit
# Adicione as alterações
git add .
# Crie um único commit
git commit -m "Adiciona nova funcionalidade (squash)"
# Faça o push das alterações
git push origin main

Rebase and Merge¶

Descrição: Reaplica os commits da branch de origem sobre a branch de destino, criando um histórico linear. Comando Git: Para realizar um rebase localmente, você pode usar:

bash
# Certifique-se de estar na branch de destino
git checkout main
# Puxe as alterações mais recentes da branch de destino
git pull origin main
# Faça o rebase da branch de origem
git rebase feature/nova-funcionalidade
# Resolva quaisquer conflitos, se necessário
# Depois do rebase, faça o push das alterações
git push origin main

Resumo¶

Merge Commit: git merge feature/nova-funcionalidade
Squash and Merge: git merge --squash feature/nova-funcionalidade seguido de git commit
Rebase and Merge: git rebase feature/nova-funcionalidade

Pull Request Template¶

Os modelos de solicitação de pull são semelhantes aos modelos de problema. Eles preencherão a área de texto da solicitação de pull com o modelo especificado:

.github/pull_request_template.md

• Pull Request Template: .github/pull_request_template.md
• Issue Templates: .github/ISSUE_TEMPLATE/bug_report.md, .github/ISSUE_TEMPLATE/feature_request.md

• Múltiplas Opções de Issue Template: .github/ISSUE_TEMPLATE/config.yml

• Pull Request Template : .github/pull_request_template.md

• Issue Template : .github/ISSUE_TEMPLATE/bug_report.md e .github/ISSUE_TEMPLATE/feature_request.md
• Issue Template com múltiplas opções : .github/ISSUE_TEMPLATE/

Solicitação de pull é o mecanismo usado para sinalizar que as confirmações de um branch estão prontas para serem mescladas em outro branch. Uma pull request é uma proposta para mesclar as alterações de um branch em outro. Os colaboradores podem revisar e discutir o conjunto de alterações proposto antes de integrá-las à base de código principal.

É possível criar solicitações de pull no GitHub.com, com o GitHub Desktop, em GitHub Codespaces, no GitHub Mobile e por meio da CLI do GitHub.

Diferenças entre commits em páginas de comparação e pull request¶

• As páginas de comparação mostram a diferença entre a ponta do ref principal e o ancestral comum atual (ou seja, a base de merge) do ref principal e de base.

• As páginas de pull request mostram a diferença entre a ponta do ref principal e o ancestral comum do ref principal e de base no momento em que o pull request foi criado. Consequentemente, a base de merge utilizada para a comparação pode ser diferente.

Depois de realizar o merge do seu pull request, exclua o branch. Isso indica que o trabalho no branch foi concluído e impede que você ou outras pessoas de usar os branches antigos acidentalmente.

Discussões¶

Se destinam a conversas que precisam ser acessíveis a todos e não estão relacionadas ao código. GitHub Discussions é uma ferramenta de comunicação da comunidade para seus repositórios públicos ou privados do GitHub.

Quando alguém cria uma discussão, precisa escolher uma categoria. O GitHub fornece algumas categorias, mas os proprietários do repositório do GitHub podem criar as suas próprias. Ao criar uma nova categoria, você escolherá um formato de discussão: discussão aberta, sem votação da melhor resposta, apenas discussões abertas/

Você pode "converter" uma Discussão em um Problema

Na discussão, escolha criar problema. Ele preencherá previamente um Problema e colocará um link de Discussão na descrição

Notification Filters Options¶

You can filter notifications using a filter syntax: Filter notifications

repo: filter by repository
is: filter by status or discussion type
reason: filter by notification reason 
author: filter by notification author 
org: filter by organization

Filter inbox by...
Assigned
Participating
Mentioned

Menções em Tópicos¶

Se alguém menciona você em um tópico, você pode encontrar essas menções nos Filtros de Menção. Uma menção é quando alguém usa um @ seguido do seu @nome de usuário.

Caixa de entrada de notificações¶

A caixa de entrada de notificações fornece uma lista cronológica de tópicos de notificações. Isso permite que você fique por dentro de todas as atividades assinadas com repositórios GitHub associados. https://github.com/notifications

Notification Watching¶

Você pode assistir repositórios para ser notificado sobre atividades. Seus próprios repositórios que você já definiu como assistindo. Você pode ver uma lista de assistindo em notificações https://github.com/watching

Assinaturas de Notificação¶

As assinaturas permitem que você acompanhe atividades para um Pull Request ou Issue específico. Você pode ver todas as suas assinaturas em Notificações. https://github.com/notifications/subscriptions

Habilitar uma discussão em seu repositório¶

Os proprietários do repositório e as pessoas com acesso de gravação podem habilitar o GitHub Discussions. Configurações → Recursos e, em Discussões, selecione Configurar as discussões.

Criar uma nova discussão¶

Qualquer usuário autenticado que possa visualizar um repositório pode criar uma discussão nesse repositório.

Como gerenciar assinaturas e notificações¶

Uma conversa em um problema específico, pull request ou gist, atividade de CI, como o status de fluxos,Problemas de repositório, solicitações de pull, versões, alertas de segurança ou discussões (se habilitados) e Todas as atividades em um repositório.

Integrações¶

Integrações são ferramentas que estendem os recursos de GitHub. As integrações podem realizar tarefas em GitHub como abrir problemas, fazer comentários sobre solicitações de pull e gerenciar projetos.

Integrações do GitHub em destaque¶

Com o GitHub para a extensão do Visual Studio, você pode trabalhar em repositórios do GitHub sem sair do Visual Studio.

Integração com o Microsoft Teams e GitHub¶

O aplicativo GitHub para Teams permite que você assine seus repositórios ou organizações e obtenha atualizações em tempo real sobre a atividade para os recursos a seguir em sua GitHub.com.

CI/CD and DevOps¶

GitHub Actions¶

O GitHub Actions é uma plataforma de integração e entrega contínua (CI/CD) que permite automatizar seu pipeline de build, teste e implantação. O GitHub Actions vai além do DevOps e permite que você execute fluxos de trabalho quando outros eventos acontecem no seu repositório.

O GitHub fornece máquinas virtuais Linux, Windows e macOS para executar seus fluxos de trabalho, ou você pode hospedar seus próprios executores auto-hospedados em seu próprio data center ou infraestrutura de nuvem.

Github Actions permite automatizar: - [x] Executar suítes de teste - [x] Construir imagens - [x] Compilar sites estáticos - [x] Implantar código em servidores e mais...

Você pode configurar um fluxo de trabalho do GitHub Actions para ser acionado quando um evento ocorrer no seu repositório, como uma solicitação de pull sendo aberta ou um problema sendo criado.

Fluxos de Trabalho (Workflow)¶

Um fluxo de trabalho é um processo automatizado configurável que executará um ou mais trabalhos. Definidos por um arquivo YAML; Os fluxos de trabalho são definidos no .github/workflows. Reutilizar fluxos de trabalho evita duplicação. Um fluxo de trabalho que usa outro fluxo de trabalho é chamado de fluxo de trabalho "chamador".

O GitHub Actions é uma ferramenta de automação e integração contínua (CI/CD) oferecida pelo GitHub. Ele permite que você crie, teste e implemente (deploy) seu código automaticamente, através de workflows (fluxos de trabalho) baseados em eventos no repositório, como push, pull requests, ou agendamentos.

Estrutura Básica do GitHub Actions¶

• Workflows: São arquivos YAML (localizados na pasta .github/workflows do repositório) que definem uma sequência de tarefas para automatizar.
• Jobs: São as etapas que compõem um workflow e rodam de forma paralela ou sequencial. Cada job roda em um ambiente isolado, que pode ser uma máquina virtual ou container.
• Steps: São as ações individuais dentro de um job, como instalar dependências, executar testes ou fazer deploy. Os steps podem usar comandos shell ou ações pré-configuradas.
• Actions: São scripts reutilizáveis que realizam tarefas específicas. Você pode usar ações da comunidade, da GitHub Marketplace, ou criar ações personalizadas para seu projeto.

Exemplo Simples de Workflow¶

Este exemplo básico executa testes sempre que um push é feito para a branch main.

name: CI Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
      uses: actions/checkout@v3
    - name: Run tests
      run: npm test

Principais Vantagens¶

Automação: Facilita a automação de processos repetitivos, como testes e deploy. Personalização: Workflows altamente customizáveis, ajustando para o pipeline específico. Integração com GitHub: Totalmente integrado ao repositório GitHub, simplificando a automação sem configurações complexas. O GitHub Actions é especialmente útil para integrar e testar mudanças no código de maneira rápida, antes de ir para produção.

Exemplos de ações comuns do GitHub que podem ser acionadas: - [x] Pushes: acione uma ação em qualquer push para o repositório. - [x] Pull Requests: execute ações quando pull requests forem abertas, atualizadas ou mescladas. - [x] Issues: execute ações com base em atividades de problemas, como criação ou rotulagem. - [x] Releases: automatize fluxos de trabalho quando uma nova versão for publicada. - [x] Scheduled Events: agende ações para serem executadas em horários específicos. - [x] Manual Triggers: permita o acionamento manual de ações por meio da interface do usuário do GitHub

Olhar:

• O GitHub Actions é habilitado em todos os repositórios e organizações.
• O GitHub Actions é uma plataforma de integração e entrega contínua (CI/CD) que permite automatizar seu pipeline de construção, teste e - [x]implantação.
• Você pode configurar um fluxo de trabalho do GitHub Actions para ser acionado quando um evento ocorrer em seuAÇÕES DO GITHUB repositório, como uma solicitação de pull sendo aberta ou um problema sendo criado.

Workflows e Events¶

Um fluxo de trabalho é um processo automatizado configurável que executará um ou mais trabalhos. Fluxos de trabalho são definidos por um arquivo YAML registrado em seu repositório e serão executados quando acionados por um evento no seu repositório, ou eles podem ser acionados manualmente ou em um cronograma definido.

Os fluxos de trabalho são definidos no diretório .github/workflows em um repositório. Um repositório pode ter vários fluxos de trabalho.

Evento¶

Um evento é uma atividade específica em um repositório que aciona uma execução de fluxo de trabalho. Por exemplo, uma atividade pode se originar do GitHub quando alguém cria uma solicitação de pull, abre um problema ou envia um commit para um repositório.

Eventos que acionam fluxos de trabalho

Job¶

Um job é um conjunto de etapas em um fluxo de trabalho que é executado no mesmo runner. Cada etapa é um script de shell que será executado ou uma ação que será executada.

Ações¶

Uma ação é um aplicativo personalizado para a plataforma GitHub Actions que executa uma tarefa complexa, mas frequentemente repetida. Uma ação pode extrair seu repositório Git do GitHub, configurar a cadeia de ferramentas correta para seu ambiente de build ou configurar a autenticação para seu provedor de nuvem.

Runners¶

Um runner é um servidor que executa seus fluxos de trabalho quando eles são acionados. Cada runner pode executar um único trabalho de cada vez. O GitHub fornece runners do Ubuntu Linux, Microsoft Windows e macOS para executar seus fluxos de trabalho .
Os executores criam e testam automaticamente as alterações de código em resposta a eventos como pushes, pull solicitações ou gatilhos agendados, garantindo que o novo código não interrompa a funcionalidade existente. Os corredores também podem lidar com a implantação de aplicativos para ambientes de preparação ou produção. No seu arquivo de fluxo de trabalho do GitHub Actions, especifique runner na chave runs-on: runs-on: [self-hosted, linux, x64, gpu]

Gerenciando as configurações de segurança e análise do repositório¶

Role para baixo até a seção "Recursos" e selecione Discussões. Para desabilitar discussões, em "Recursos", desmarque Discussões.

GitHub Packages¶

GitHub Packages é uma plataforma para hospedar e gerenciar pacotes, incluindo contêineres e outras dependências. Enviando contêiner Docker para GitHub Packages

GH_USERNAME="andrew-wc-brown" IMAGE_NAME="hello-world"
VER="1.0.0"
# Entre no docker
echo $GH_TOKEN | docker login ghcr.io -u $GH_USERNAME --password-stdin # Tag docker container
docker tag $IMAGE_NAME: $VER ghcr.io/$GH_USERNAME/$IMAGE_NAME: $VER # Enviar para pacotes do Docker
docker push ghcr.io/$GH_USERNAME/$IMAGE_NAME: $VER

Registro de pacotes suportados:

Javascript (pacote npm)
Ruby (gems)
Java (pacotes maven e gradle) .Net (não faça net de pacotes)
Imagens do Docker

GitHub Pages¶

GitHub Pages permite que você hospede diretamente um site estático por meio de um repositório GitHub. Você precisa criar um repositório público com o nome do repositório sendo .github.io

• jekylly
• Você simplesmente adiciona arquivos HTML e ativos ao seu repositório.
• Jekyll é um gerador de site estático que permite que você crie sites estáticos complexos ou blogs com facilidade.
• Jekyll usa arquivos yaml com formato frontmatter.
• Jekyll utiliza arquivos markdown
• Jekyll integra-se diretamente com GitHub Pages e é um projeto GitHub

GitHub Pages oferece duas opções principais para sites¶

• Site de usuário ou organização (username.github.io ou organization.github.io): Esse tipo de site está associado ao nome de usuário ou à organização no GitHub.
  • Criar um repositório com o nome da organização, seguido por .github.io (exemplo: organization.github.io).
• Site de repositório (username.github.io/repository-name): Esse tipo de site é associado a um repositório específico no GitHub e é usado para hospedar um site para um único projeto ou produto.

GitHub Copilot¶

O GitHub Copilot é uma ferramenta de desenvolvedor AI que pode ser usada com vários IDEs por meio de uma extensão Conclusão de código Bate-papo no IDE e no celular Assistência CLI Referência de código Filtro de código público Indenização de IP

Você pode experimentar o GitHub Copilot gratuitamente com um teste único de 30 dias. AVALIAÇÃO O GitHub Copilot é gratuito para uso por alunos, professores e mantenedores verificados de projetos populares de código aberto.

GitHub Copilot¶

Ferramenta de desenvolvedor de IA em escala do mundo que pode ajudar você a escrever código mais rapidamente com menos trabalho. O OpenAI criou modelo de linguagem pré-treinado generativo do GitHub Copilot, da plataforma OpenAI Codex. A extensão está disponível para Visual Studio Code, Visual Studio, Neovim e o pacote JetBrains de IDEs (ambientes de desenvolvimento integrados).

O GitHub Copilot é um serviço que fornece um programador em pares de IA que funciona com todas as linguagens de programação populares e acelera drasticamente a produtividade geral do desenvolvedor.

GitHub Copilot Business¶

• Foco em equipes : Destinado a equipes de desenvolvimento em empresas de médio a grande porte.
• Recursos de colaboração : Inclui funcionalidades para gerenciamento de usuários e permissões, permitindo que as equipes trabalhem de forma integrada.
• Integração com ferramentas: Funciona bem com diversas ferramentas de desenvolvimento e CI/CD.

GitHub Copilot Enterprise¶

• Soluções personalizadas : Focado em organizações maiores ou que têm necessidades específicas de segurança e conformidade.
• Gerenciamento avançado : Oferece controle mais rigoroso sobre a implementação e uso do Copilot, com suporte a políticas corporativas.
• Segurança e conformidade: Pode incluir opções de segurança adicionais, como integração com sistemas de autenticação empresarial e conformidade com regulamentos específicos.

Desde ler documentos a escrever código até enviar solicitações de pull e além, o GitHub está trabalhando para personalizar o GitHub Copilot para cada equipe, projeto e repositório em que ele é usado, criando um ciclo de vida de desenvolvimento de software radicalmente aprimorado.

Projetos¶

Embora nem todos os projetos tenham os documentos CONTRIBUTING e CODE_OF_CONDUCT, a presença deles é uma boa indicação do quanto um projeto é amigável e acolhedor. - [x] Uma boa maneira de se familiarizar com a comunidade é ler alguns destes canais de comunicação: - [x] Issue tracker: local em que as pessoas discutem problemas e tarefas relacionados ao projeto. Para encontrar os problemas no GitHub, você pode ir até a página principal do repositório no GitHub e adicionar /issues ao final da URL, por exemplo, https://github.com/jupyter/notebook/issues. - [x] Pull request: local em que as pessoas discutem e examinam as alterações do projeto. Encontre-a no GitHub adicionando pulls à URL do projeto, por exemplo, https://github.com/jupyter/notebook/pulls. Char channels and forums: alguns projetos usam canais de chat, como Slack, Gitter e IRC, ou fóruns, como o Discourse, para conversas e discussões.

Gerenciar seu trabalho com projetos do GitHub¶

Projetos versus Projetos Clássicos

Tabelas e Quadros¶

• Planejar e controlar o trabalho em uma exibição de tabela ou quadro
• Classificar, priorizar e agrupar dentro de uma tabela por qualquer campo personalizado
• Crie esboços de problemas com descrições e metadados detalhados
• Materialize qualquer perspectiva com filtragem tokenizada e visualizações salvas
• Personalizar cartões e agrupar por em quadros de projeto
• Atualizações de projeto em tempo real e indicadores de presença do usuário

Automação¶

• API do GraphQL ProjectsV2
• Escopos do projeto do aplicativo GitHub
• Eventos de webhooks para atualizações de metadados de itens do * projeto
• GitHub Action para automatizar a adição de problemas a projetos

Projeto no nível da organização¶

• Sem acesso: Somente os proprietários e usuários da organização que receberam acesso individual podem ver o projeto.
• Os proprietários da organização também são administradores do projeto.
  • Ler: Todos na organização podem ver o projeto. Os proprietários da organização também são administradores do projeto.
  • Gravação: Todos na organização podem ver e editar o projeto. Os proprietários da organização também são administradores do projeto.
  • Administrador: Todos na organização são administradores do projeto.

Projeto no nível pessoal/de usuário¶

• Ler: O indivíduo pode ver o projeto.
• Gravação: O indivíduo pode ver e editar o projeto.
• Administrador: O indivíduo pode ver, editar e adicionar novos colaboradores ao projeto.

Para vincular um projeto a um repositório, entre no repositório e projetos e vinvule.

Adicionando um campo de iteração¶

Coloque na visualização de tabela, no cabeçalho do campo mais à direita, clique em +:

Fixando um problema no seu repositório¶

navegue até a página principal do repositório. → Problemas (Issues) → Fixar problema.

Marcando problemas ou solicitações de pull como duplicados¶

Para marcar um problema ou solicitação de pull como duplicado, digite "Duplicate of #nnn"

Desmarcando duplicatas¶

Você pode desmarcar problemas duplicados e solicitações de pull clicando em Desfazer na linha do tempo.

Transferindo um problema aberto para outro repositório¶

principal do repositório → Problemas → Escolha o Problema → Problema de transferência → Repositório para o qual deseja transferir o problema. → Transferir problema .

Fechando um problema¶

Problemas → Opcionalmente, para alterar o motivo do encerramento do problema, ao lado de "Fechar problema", selecione e clique em um motivo → Fechar Problema

Excluir Problemas¶

o problema que você deseja excluir. → "Notificações", clique em Excluir problema → clique em Excluir este problema.

Desabilitar projetos em um repositório¶

Quando você desabilitar projects em um repositório, os projetos vinculados não estarão mais disponíveis na guia Projetos do repositório. Os projetos vinculados permanecerão acessíveis no nível de organização ou de usuário.

Insights¶

O Insights com Projetos permite que você visualiza, crie e personalize gráficos que usam itens adicionados ao seu projeto como dados de origem. Ao criar um gráfico, você define os filtros, o tipo de gráfico e as informações exibidas. Para um repositório do Github na aba Insights, você pode obter muitos gráficos estatísticos sobre o repositório. Insights contém:

• Pulse: Visão geral da atividade recente (problemas, solicitações de pull). Fornece uma visão geral das atividades recentes no repositório, incluindo pull requests, issues e commits.
  • Pull requests open/close ratio Issues open/close ratio Summary of activity
  • Graph of top contributors
  • List of merged pull requests List of issues closed
  • List of issues opened
  • List of unresolved conversations
• Contribuidores: Lista os contribuidores e suas estatísticas de atividade.Lista os principais contribuidores do repositório e a quantidade de commits feitos por cada um.
  • Gráfico de todos os commits em um período de tempo;
  • Gráfico de commits de colaboradores específicos em um período de tempo;
• Padrões da comunidade: Verifica arquivos essenciais de saúde da comunidade. Exibe dados sobre a atividade da comunidade no repositório, como issues abertas, pull requests, interações e comentários.
  • Este gráfico só será exibido para repositórios que tenham perfis de comunidade.
  • Perfis de comunidade são para projetos de código aberto no GitHub.
  • Uma lista de verificação dos padrões recomendados da comunidade e o quanto um perfil da comunidade concluiu;
• Traffic: Mostra o tráfego de visitantes e clones no repositório, incluindo origens de referência e arquivos mais visualizados.
• Commits: Histórico de todos os commits no repositório.
  • Número de commits por semana nas últimas 52 semanas. (por um ano)
  • O número médio de commits por dia da semana para a semana selecionada
• Frequência do código: Gráfico de adições e exclusões de código ao longo do tempo.
  • A quantidade de adições e exclusões de código em um relatório por mês.
• Gráfico de dependência: Visualiza dependências de código.
  • Lista de dependências
  • Lista de dependentes Exportar listas de materiais de software (SBOMs)
  • As equipes de segurança e conformidade solicitam cada vez mais listas de materiais de software (SBOMS) para identificar os componentes de código aberto de seus projetos de software, avaliar sua vulnerabilidade a ameaças emergentes e verificar o alinhamento com as políticas de licença.
• Rede: Mostra relacionamentos e variações de bifurcação.
  • 100 forks mais recentemente enviados;
  • Você pode ler os commits para determinar a diferença entre esses forks.
• Bifurcações (Forks): Número e links para bifurcações do repositório.
  • Contém uma lista de forks filtráveis
• Actions Performance Metrics: Analisa o desempenho dos workflows configurados no GitHub Actions, incluindo o tempo médio de execução e falhas ocorridas.
• People: Exibe a lista de colaboradores e membros da organização que têm acesso ao repositório, com seus respectivos níveis de permissão (admin, write, read, etc.).

Insigghts Usuario¶

• Actions Performance Metrics: Métricas de desempenho que avaliam a eficiência e a velocidade dos workflows do GitHub Actions no repositório.
• Actions Usage Metrics: Métricas de uso que monitoram o consumo dos recursos do GitHub Actions, especialmente útil para gerenciar os custos e limites de execução.

Gráficos atuais¶

Você pode criar gráficos atuais para visualizar itens do projeto.

Gráficos históricos¶

Os gráficos históricos estão disponíveis com o GitHub Team e o GitHub Enterprise Cloud para organizações.

Automação com projetos¶

Há três maneiras diferentes possibilitando você a fazer isso:

• Fluxos de trabalho automatizados internos
• API GraphQL
• GitHub Actions com fluxos de trabalho

Wiki¶

Um README deve conter apenas as informações necessárias para desenvolvedores começarem a usar e a contribuir para o seu projeto. A documentação mais longa é mais adequada para wikis. A documentação mais longa é mais adequada para wikis. GitHub.com vem equipado com uma seção para hospedagem da documentação, chamada wiki. Você pode clonar o repositório da Wiki, observando https://github.com/username/repository.wiki.git.

• Um Wiki é uma forma colaborativa de criar documentação rapidamente com várias páginas aninhadas
• Um wiki serviria como uma base de conhecimento para seu repositório ou organização.
• Ative o recurso Wiki para seu repositório do GitHub.
• Recursos
• Vá para a página Wiki do seu repositório
• Crie sua primeira página!
• Wikis hospedam documentação para seu repositório.
• ✓ Restringir edição somente para colaboradores Wikis públicos ainda poderão ser lidos por todos.
• Wiki
• mapa do seu projeto, mostre o
• Crie a primeira página
• Você pode escolher qual o markup language.
• Se você criar um wiki em um repositório público, o wiki estará disponível ao público.
• https://github.com/USERNAME/REPOSITORIO/wiki
• https://github.com/usuario/meu-projeto.wiki
  • Além disso, pode clonar esse repositório para trabalhar localmente e sincronizar as alterações com a versão online.
• Se você criar um wiki em um repositório privado, somente pessoas com acesso ao repositório poderão acessar o wiki.

Segurança¶

2FA: Exija que todos os colaboradores habilitem a autenticação de dois fatores para aumentar a segurança da conta RBAC: Atribuir permissões com base em funções para limitar o acesso Regras de proteção: configure a proteção de branch para impor revisões e evitar confirmações diretas Visibilidade: Mantenha os repositórios privados e exponha apenas o necessário ao público. Auditoria: Revise regularmente os registros de acesso para monitorar atividades suspeitas ou não autorizadas Revisões de código: exija solicitações de pull e revisões de código antes da mesclagem, garantindo que o código qualidade e supervisão.

CodeQL (O que é varredura de código)¶

Sua empresa acabou de adquirir uma licença do GitHub Advanced Security que ajuda a economizar tempo e esforço, permitindo que você use a varredura de código. CodeQL para analisar o código em um repositório GitHub para encontrar vulnerabilidades de segurança e erros de codificação. Varredura de código está disponível para todos os repositórios públicos e para repositórios privados pertencentes a organizações em que a Segurança Avançada do GitHub está habilitada.

Você pode agendar varreduras para determinados dias e horas ou disparar varreduras quando ocorre um evento específico no repositório como um push.

name: "CodeQL config"
queries: 
  - name: Run custom queries
    uses: ./queries
  - uses: security-experimental
  - uses: security-extended
  - uses: security-and-quality
paths-ignore:
  - tests
  - lib

O CodeQL trata o código como dados, permitindo que você encontre possíveis vulnerabilidades em seu código com maior confiança do que os analisadores estáticos tradicionais.

Segurança → Code Scan Alerts

Habilitar a verificação de código com ferramentas de Terceiros¶

Você pode carregar arquivos SARIF (Static Analysis Results Interchange Format - Formato de Intercâmbio de Resultados de Análise Estáticos) gerados fora do GitHub ou com GitHub Actions para ver alertas de verificação de código de ferramentas de terceiros em seu repositório.

Por padrão, somente os alertas com o nível de gravidade Error ou o nível de gravidade de segurança Critical ou High causam uma falha de verificação de pull request.

API de Verificação de Código¶

curl -L  -H "Accept: application/vnd.github+json"  -H "Authorization: Bearer <YOUR-TOKEN>" -H "X-GitHub-Api-Version: 2022-11-28"  https://api.github.com/orgs/ORG/code-scanning/alerts
ou
https://api.github.com
ou
https://docs.github.com/pt/rest/code-scanning/code-scanning?apiVersion=2022-11-28

CLI do CodeQL¶

brew install codeql https://docs.github.com/pt/code-security/codeql-cli

codeql database create /codeql-dbs/example-repo --language=javascript-typescript --source-root /checkouts/example-repo A CLI do CodeQL é um produto autônomo que você pode usar para analisar o código.

codeql database create codeql-js --source-root=. --no-run-unnecessary-builds --language=javascript-typescript 
codeql database analyze codeql-dbs/python python-code-scanning.qls   --format=sarif-latest --sarif-category=python --output=python-results.sarif
codeql database create codeql-dbs --source-root=src --db-cluster     --language=java,python --command=./myBuildScript
codeql database analyze codeql-dbs/java java-code-scanning.qls       --format=sarif-latest --sarif-category=java --output=java-results.sarif
codeql database analyze codeql-dbs/python python-code-scanning.qls   --format=sarif-latest --sarif-category=python --output=python-results.sarif
# Upload the SARIF file with the Java results: 'java-results.sarif'
# The GitHub App or personal access token created for authentication
# with GitHub's REST API is available in the `GITHUB_TOKEN` environment variable.
codeql github upload-results \
    --repository=my-org/example-repo \
    --ref=refs/heads/main --commit=deb275d2d5fe9a522a0b7bd8b6b6a1c939552718 \
    --sarif=java-results.sarif
# Upload the SARIF file with the Python results: 'python-results.sarif'
codeql github upload-results \
    --repository=my-org/example-repo \
    --ref=refs/heads/main --commit=deb275d2d5fe9a522a0b7bd8b6b6a1c939552718 \
    --sarif=python-results.sarif

Dependabot alerts. Com regras de triagem automática personalizadas você tem controle sobre os alertas que deseja ignorar, adiar ou acionar uma atualização de segurança para.

Dependabot¶

É uma ferramenta de automação integrada ao GitHub que ajuda a manter as dependências de projetos de código-fonte atualizadas e seguras. Principais Funcionalidades: Atualizações de Dependências, Segurança de Dependências, Compatibilidade de versões, Suporte a múltiplos ecossistemas (linguagens) Arquivo de configuração do Dependabot (dependabot.yml): O arquivo dependabot.yml permite personalizar como o Dependabot funcionará no seu repositório. Esse arquivo é colocado no diretório .github do seu repositório e permite definir aspectos: Frequência das verificações de dependência (diária, semanal, mensal), versões, Excluir determinados pacotes de serem atualizados. o Dependabot cria um pull request com a atualização necessária. O pull request inclui informações sobre o que foi alterado, links para a documentação relevante e, se for o caso, detalhes sobre a correção de segurança.

consiste em três recursos: - [x] Dependabot alerts: informam você sobre vulnerabilidades nas dependências usadas em um repositório. - [x] Dependabot security updates: geram automaticamente solicitações de pull para atualizar as dependências usadas que possuem vulnerabilidades de segurança conhecidas. - [x] Dependabot version updates: geram automaticamente solicitações de pull para manter as dependências atualizadas.

Regras na Branch¶

Branches → Branch protection rules → Add rule → Branch name pattern"

Exigir confirmações assinadas: Usando GPG, SSH ou S/MIME,

Insights¶

Settings¶

Client apps¶

GitHub CLI¶

O GitHub CLI (gh) é uma ferramenta de linha de comando oficial do GitHub que permite interagir com o GitHub diretamente do seu terminal. Aqui estão alguns pontos principais sobre o GitHub CLI:

• Instalação: brew install gh
• Exemplo:
  • gh auth login
  • gh repo create nome_do_repositorio --public
  • gh issue create --title "Issue title" --body "Issue body"
  • gh pr review --comment -b "interesting"

Você pode instalar rapidamente a CLI para GitHub Codespaces por meio de Recursos: "features": {"ghcr.io/devcontainers/features/github-cli:1": {} }

Diretório Seguro: `git config --global --add safe.directory /caminho/para/seu/diretorio`, garantir que você possa trabalhar no repositório sem enfrentar problemas de permissão.

#!/bin/bash
clear screen
gh auth login
gh repo fork firstcontributions/first-contributions
git switch -c add-john-doe
git push origin -u your-branch-name
gh pr create --repo firstcontributions/first-contributions
gh repo create "60pportunities" --add-readme --public --license "Apache-2.0" --description "Paginas de Documentação da 60pportunities"
GITHUB_SHA=$(gh api repos/s60pportunities/60pportunities/commits/main | jq -r '.sha')
echo "SHA= ${GITHUB_SHA}"
gh api -X POST /repos/s60pportunities/60pportunities/git/refs -f ref=refs/heads/gh-pages -f sha="${GITHUB_SHA}"
gh repo edit --enable-pages
gh repo edit --pages-branch gh-pages --pages-folder /
#gh repo edit --set-pages-domain "60pportunities.com.br"
gh repo view --web
gh label create "documentação" --color "0099cc" --description "Para questões relacionadas à criação ou atualização de documentos."
gh label create "documentação" --color "0099cc" --description "Para questões relacionadas à criação ou atualização de documentos."
gh label create "documentação" --color "0099cc" --description "Para questões relacionadas à criação ou atualização de documentos."
gh label create "documentação" --color "0099cc" --description "Para questões relacionadas à criação ou atualização de documentos."
gh label create "melhoria" --color "0099cc" --description "Para sugestões de melhorias na documentação existente.
gh label create "novo recurso" --color "0099cc" --description "Para a documentação de novas funcionalidades ou recursos."
gh label create "atualização" --color "0099cc" --description "Para tarefas que envolvem a atualização de informações já existentes."
gh label create "exemplo" --color "0099cc" --description "Para questões que envolvem a adição ou revisão de exemplos de código ou uso."
gh label create "tradução" --color "0099cc" --description "Para questões relacionadas à tradução da documentação para outros idiomas."
gh label create "urgente" --color "0099cc" --description "Para problemas que precisam de atenção imediata."
gh label create "feedback" --color "0099cc" --description "Para sugestões ou comentários gerais sobre a documentação."
gh label create "formatação" --color "0099cc" --description "Para problemas relacionados à formatação ou estilo da documentação."

GitHub Mobile¶

GitHub Desktop¶

O GitHub Desktop é um aplicativo independente para interagir com repositórios do GitHub sem o navegador ou via código. Operações comuns do Git e do Github podem ser realizadas via GUI para uma experiência fácil de usar. Os desktops do GitHub são compatíveis com:

• MacOS;
• Windows;
• Linux;

Mobile vs Desktop¶

O GitHub para Dispositivos Móveis é uma maneira segura e protegida de acessar seus dados no GitHub por meio de um aplicativo cliente confiável, criado pela própria plataforma, com :

• Gerencie, faça triagem e limpe notificações
• Ler, revisar e colaborar em problemas e solicitações de pull
• Editar arquivos em solicitações de pull
• Pesquisar, navegar e interagir com usuários, repositórios e organizações
• Receber uma notificação push quando alguém menciona seu nome de usuário
• Pesquisar por código em um repositório específico
• Proteger sua conta GitHub.com com autenticação de dois fatores

O GitHub para Desktop é um aplicativo autônomo de código aberto, facilita a colaboração entre você e sua equipe e o compartilhamento de boas práticas do Git e do GitHub dentro da sua equipe.

Github.dev¶

Use o editor baseado na Web do github.dev para editar arquivos e fazer commit das alterações. O editor do github.dev apresenta uma experiência leve de edição, que é executada inteiramente no navegador. O editor do github.dev é executado inteiramente na área restrita do navegador. - [x] Para chama-lo, basta ir para o repositório e digitar . ou https://github.dev/USERNAME/repositorio.

GitHub Codespaces¶

Um codespace é um ambiente de desenvolvimento hospedado na nuvem. Cada codespace criado é hospedado por GitHub em um contêiner do Docker em execução em uma máquina virtual. Não há suporte para sistemas operacionais Windows e macOS para o contêiner de desenvolvimento remoto. Você pode trabalhar em um codespace usando seu navegador, Visual Studio Code, um IDE JetBrains ou um shell de comando. Você pode verificar os seus codespaces em : https://github.com/codespaces

O GitHub Codespaces é uma plataforma que oferece um ambiente de desenvolvimento na nuvem, permitindo que você trabalhe em seus projetos diretamente do seu navegador. Aqui estão algumas das principais funções e benefícios do Codespaces: Principais Funções:

Ambiente Pré-configurado: Você pode iniciar rapidamente um espaço de trabalho com todas as dependências e ferramentas necessárias para o seu projeto, sem precisar configurar nada localmente.

Colaboração em Tempo Real: É possível compartilhar seu espaço de trabalho com outros desenvolvedores, facilitando a colaboração em projetos.

Acesso de Qualquer Lugar: Como é uma solução baseada na nuvem, você pode acessar seus projetos de qualquer dispositivo com conexão à internet.

Integração com o GitHub: Codespaces se integra perfeitamente com os repositórios do GitHub, permitindo que você faça push, pull e gerencie suas alterações facilmente.

Personalização: Você pode personalizar o ambiente de desenvolvimento usando o arquivo devcontainer.json, onde pode definir configurações específicas para seu projeto.

Benefícios:

Agilidade: Reduz o tempo de configuração e permite que você comece a codificar rapidamente.
Menos Dependências Locais: Minimiza a necessidade de instalar software e gerenciar ambientes localmente.
Experiência Consistente: Oferece uma experiência uniforme para todos os desenvolvedores, independentemente do sistema operacional que utilizam.

GitHub Codespaces é um Cloud Developer Environment (CDE) integrado ao seu repositório GitHub. Um ambiente é conhecido como codespace. Um codespace é executado: ⚫no contêiner docker do Ubuntu Linux ⚫em uma máquina virtual ⚫hospedado e gerenciado pelo GitHub

Ao criar um novo codespace, você escolhe:

• O repositório
• A ramificação
• A região
• Tipo de máquina

Região¶

Seu codespace será executado na região selecionada. As regiões que você pode escolher:

• Leste dos EUA
• Oeste dos EUA
• Oeste da Europa
• Sudeste da Ásia

You can start a Codespace via your GitHub repo via the Code button

You can also use the GitHub CLI to create an open a codespace

gh codespace create
gh codespace open

Há um limite de codespaces simultâneos permitidos para executar. Se você atingir o limite, pode ser necessário interromper outros codespaces

Você escolhe criar um codespace ou reabrir um existente (Criar, Reabrir) O trabalho persistirá na máquina virtual, desde que não seja excluído. Para garantir que não haja perda de dados, você precisa confirmar seu trabalho no repositório para realmente salvá-lo. (Salvando)

VS Code Browser: salvamento automático ativado por padrão e VS Code Desktop: o salvamento automático precisa ser ativado (salvamento automático)

parar congela o estado do seu workspace para que você possa usá-lo novamente mais tarde. (Parar)

Quando você exclui seu codespace e o trabalho não confirmado em seu repositório também será excluído. (Excluindo)

Se você fez alterações na configuração do seu contêiner de desenvolvimento. Você precisa reconstruir seu codespace para que elas tenham efeito (Reconstruir)

O codespace por padrão expirará após 30 minutos de atividade. O codespace será interrompido para conservar os gastos. Suas alterações persistirão na máquina virtual. (Tempos limite)

Quando você cria um codespace, ele recebe um nome de exibição gerado automaticamente, por exemplo: shiny-space-chainsaw-jjgx4w5r3q9xj

Você pode renomear o nome gerado automaticamente no caso de ter vários codespaces para identificar facilmente o propósito ou estado do seu codespace.

Você pode ver todos os seus codespaces em: https://github.com/codespaces Os GitHub Codespaces também são configuráveis, o que permite criar um ambiente de desenvolvimento personalizado para o projeto. Você pode se conectar aos seus codespaces por meio do navegador, por meio do Visual Studio Code, do aplicativo JetBrains Gateway ou usando a GitHub CLI, você pode: Você pode criar um codespace no GitHub, no Visual Studio Code, ou usando a GitHub CLI. A clonagem é feita no diretório /workspaces da VM e, posteriormente, montada no contêiner de desenvolvimento.

• Escolha seu editor
  • Visual Studio Code (aplicativo da área de trabalho - Editor padrão)
  • Visual Studio Code (aplicativo Web cliente)
  • JetBrains Gateway – Para abrir codespaces em um IDE do JetBrains
  • JupyterLab – A interface Web do Project Jupyter;
  • GitHub CLI
• Trabalhe em vários projetos
• Se você trabalhar em um codespace do VS Code, poderá usar o Live Share

• Reduz o tempo de instalação;

• npm install -g devcontainers/cli

Observação:

• Você não pode excluir um codespace de dentro do JetBrains Gateway ou do aplicativo cliente do JetBrains nem de dentro do JupyterLab.
• Em configuração vc pode modificar o período de retenção, timeout e a região.
• Você pode adicionar o endereço desta página aos favoritos caso deseje voltar a ela rapidamente para retomar seu codespace. Como alternativa, você pode usar o endereço em um link para fornecer a outras pessoas uma forma rápida de criar e retomar os respectivos codespaces desse repositório.
• O Visual Studio Live Share permite fazer edição e depuração colaborativamente com outras pessoas em tempo real, dentro de um codespace. Você pode compartilhar com segurança o codespace atual ou acessar um codespace criado por outra pessoa.
• Todas as tarefas do git ou comandos do VSCode, são os mesmos.
• Por padrão, GitHub Codespaces usa o protocolo HTTPS para transferir dados de e para um repositório remoto e autentica com um GITHUB_TOKEN;
• Você não precisa bifurcar o repositório antes de criar o codespace.
• gh codespace stop - Interrompe o codespace
• gh codespace code ou gh codespace open --web - Reinicializa
• gh codespace create -b main -l EastUs --repo "60pportunities/documentacao" --web
• gh codespace ports forward CODESPACE-PORT:LOCAL-PORT

Ciclo de vida do codespace¶

O ciclo de vida de um codespace começa quando você cria um código e termina quando você o exclui. Você pode desconectar-se e reconectar-se, parar e reiniciar.

• Há limites de codespaces.
• Você pode e deve, trabalhar com o codespace em branchs diferentes da main.
• No entanto, se você excluir um codespace não publicado ou ele for excluído automaticamente por não ser usado durante o período de retenção, seu trabalho também será excluído. Para manter seu trabalho e permitir que outras pessoas trabalhem no projeto, publique o codespace em um repositório no GitHub.

Limites de tempo¶

30 minutos de inatividade.

Interrompendo um codespace: o histórico do terminal será mantido.

// .devcontainer/devcontainer.json

{
    "name": "MkDocs Material editor",
    "dockerFile": "Dockerfile",
    "workspaceMount": "source=${localWorkspaceFolder},target=/docs,type=bind",
    "workspaceFolder": "/docs",
    "settings": {
        "terminal.integrated.shell.linux": "/bin/sh"
    },
    "extensions": [
        "davidanson.vscode-markdownlint",
    ],
    "forwardPorts": [
        8000
    ]
}

Recompilar um contêiner¶

Quando você trabalha em um codespace, seu ambiente de desenvolvimento é um contêiner do Docker executado em uma máquina virtual. Se você fizer alterações na configuração do contêiner de desenvolvimento de dentro de um codespace e quiser aplicar essas alterações ao codespace atual, precisará recompilar o contêiner.

• GitHub Codespaces pode reutilizar imagens em seu cache em vez de reposicioná-las de registros de contêiner.
• Entre no VSCode e peça: rebuild container.
• gh codespace rebuild

Versionamento Semantivo¶

Variáveis Padronizadas¶

Variáveis de ambiente persistentes e arquivos temporários¶

• Variável de ambiente no arquivo ~/.bashrc, ou em um arquivo de configuração equivalente se não estiver usando o shell do Bash. Por exemplo, adicione a instrução VARNAME=value.
• Você pode editar o arquivo de configuração devcontainer.json do repositório.
• {"remoteEnv": { "VARNAME": "value"}}
• Você pode usar um Dockerfile personalizado.
• ENV VARNAME=value
• É possível usar segredos do ambiente de desenvolvimento.

Como impedir que arquivos temporários sejam excluídos automaticamente¶

Se você tiver arquivos temporários que deseja que estejam disponíveis da próxima vez que iniciar o codespace, não os salve no diretório /tmp.

Conectando-se a uma rede privada¶

Você pode usar uma VPN para acessar recursos por trás de uma rede privada de dentro do seu codespace. Recomendamos o uso de ferramentas de VPN como o OpenVPN para acessar recursos em uma rede privada.

Aprendizado de máquina¶

Você vai criar um classificador de imagens simples, aprender mais sobre algumas das ferramentas que vêm pré-instaladas no GitHub Codespaces e descobrir como abrir seu codespace no Jupyter. Acesse o repositório de modelos github/codespaces-jupyter, escolha uma template: Open in codespace,

Visual Studio Code¶

Instalar e efetuar o login na extensão dos GitHub Codespaces com as suas credenciais do GitHub.

Renomear um codespace¶

• Shift + Command + P: Codespaces: detalhes
• Comandos gh-cli
  • [x[ gh codespace list
  • gh codespace edit -c PERMANENT-CODESPACE-NAME -d 'NEW-DISPLAY-NAME'
• Através da página https://github.com/codespaces

Configuração¶

• Alterar o Shell do Codespace : "terminal.integrated.profiles.linux": {"csh": {"path": "csh"}}
• "terminal.integrated.defaultProfile.OPERATING-SYSTEM": "SHELL"

Contêineres de desenvolvimento¶

Podemos configurar o contêiner de desenvolvimento para um repositório para que os codespaces criados para esse repositório forneçam um ambiente de desenvolvimento personalizado, completo com todas as ferramentas e runtimes necessários para trabalhar em um projeto específico.

• devcontainer.json: O arquivo principal em uma configuração de contêiner de desenvolvimento. NORMALMENTE, ele fica no diretório .devcontainer do repositório.
  • Opções de configurações devem estar localizadas em seu subdiretório no caminho .devcontainer/SUBDIRECTORY/devcontainer.json..
  • .devcontainer/database-dev/devcontainer.json ou .devcontainer/gui-dev/devcontainer.json
  • Configuração: https://containers.dev/implementors/spec/
• Dockerfile
• O Dockerfile para um contêiner de desenvolvimento geralmente está localizado na pasta .devcontainer, ao lado do devcontainer.json ao qual ele faz referência.
  • Para usar um Dockerfile como parte de uma configuração de contêiner de desenvolvimento, faça referência a ele em seu arquivo devcontainer.json usando a propriedade dockerfile. - [ ] {"build": { "dockerfile": "Dockerfile" },}
• Definindo uma especificação mínima de máquina: "hostRequirements":`
• Podemos adicionar mais recursos utilizando o editor do codespaces no guia Marketplace,, ou "features": {"ghcr.io/devcontainers/features/terraform:1": {"version": "1.1","tflint": "latest"}, }
• Configurar arquivos para serem abertos automaticamente: "customizations": {codespaces": {"openFiles": ["README.md","scripts/tsconfig.json","docs/main/CODING_STANDARDS.md"]}}
  • O valor da propriedade openFiles é uma matriz de um ou mais arquivos do seu repositório.
• Adicionando Chaves/Segredos: Se um projeto precisar de segredos específicos do usuário para ser configurado, você poderá solicitar que as pessoas façam isso ao criar um codespace. No botão CODE, clicando na guia Codespaces, selecionando e clicando em Novo com opções, posteriormente segredos recomendados.
  • Após informado os segredos, configure o arquivo .devcontainer.json, para recuperar os segredos: "secrets": {"NAME_OF_SECRET_1": {"description": "This is the description of the secret.","documentationUrl": "https://example.com/link/to/info"},"NAME_OF_SECRET_2": { }}

• Facilitando a criação rápida e a retomada de codespaces:Você pode facilitar para as pessoas trabalharem no seu repositório em um codespace fornecendo um link para a página de criação do codespace. Faça isso no Arquivo README.md.

  • Crie um codespace para o branch padrão do repositório: https://codespaces.new/OWNER/REPO-NAME
  • Crie um codespace para um branch específico do repositório: https://codespaces.new/OWNER/REPO-NAME/tree/BRANCH-NAME
  • Crie um codespace para o branch do tópico de uma solicitação de pull: https://codespaces.new/OWNER/REPO-NAME/pull/PR-SHA

• Gias

GitHub Markdown¶

É uma linguagem de marcação que oferece uma abordagem enxuta para edição de conteúdo, fornece uma sintaxe abreviada para formatar informações em HTML, protegendo os criadores de conteúdo da sobrecarga do HTML. Extensão .md e .markdown.

Um caso de uso comum para uma linguagem de marcação é apresentar dados em HTML. Também abordaremos recursos do GFM (GitHub-Flavored Markdown), que são extensões de sintaxe que permitem integrar recursos do GitHub ao conteúdo.

GitHub Flavored Markdown¶

Github Flavoured Markdown (GFM) é o dialeto do Markdown que atualmente é suportado para conteúdo de usuário no GitHub.com e GitHub Enterprise. O GFM fornece funcionalidade poderosa:

• Seções recolhíveis;
• Incorporar expressões matemáticas
• Incorporar diagramas
• Caminhos relativos ou vinculação a arquivos no mesmo repositório
• Listas de tarefas podem ser convertidas em problemas
• Formatação estendida para tabelas
• Abreviações para vinculação automática a problemas, solicitações de pull e repositórios
• Renderizar trechos de código de outra base de código por meio de vinculação

A especificação detalhada do GFM está localizada aqui: GFM Preliminaries - Characters and lines - Tabs - Insecure characters Blocks and inlines - Precedence - Leaf blocks ATX headings Setext headings Indented code blocks HTML blocks

• <details><summary></sumary></details>
• Mermaid
• GeoJson
• Ascii Stl
• Expressões Matemáticasl ($$)
• APONTAR PARA UM COMMIT

• CONSULTE O MARKDOWN

GitHub APIs¶

GitHub has two APIs REST API and GraphQL API

• GitHub Rest API
• GitHub GraphQL API documentation
• Chatgpt - Escreva um GraphQL que retornará o nome do repositório público ruby para a API GraphQL do Github?

GitHub SDKs¶

Atualmente, o GitHub mantém SDKs para os seguintes idiomas/frameworks/plataformas:

• JavaScript / TypeScript
• C# / .NET
• Ruby
• Terraform provider

Também temos 2 SDKs que são gerados a partir das descrições do OpenAPI do GitHub!

• C# / .NET
• Go

Docmentação: - [x] https://github.com/octokit

terraform {
  required_providers {
    github = {
      source = "integrations/github"
      version = "5.44.0"
    }
  }
}
provider "github" {
}
resource "github_branch" "development" {
  repository = "documentacao"
  branch     = "sdks"
}

Features GHAS¶

Há recursos adicionais disponíveis para as empresas que usam o GitHub Advanced Security (GHAS). (Para comprar uma licença do GitHub Advanced Security você precisa usar o GitHub Enterprise). GitHub Advanced Security fornece os seguintes recursos adicionais: - [x] Code scanning: Procure possíveis vulnerabilidades de segurança e erros de codificação no código usando CodeQL ou uma ferramenta de terceiro. Análise de código-fonte que verifica automaticamente o código em busca de vulnerabilidades de segurança e outros problemas de qualidade. pode ser configurado para rodar automaticamente em todos os pushs e pull requests no repositório.Totalmente automatizado dentro do GitHub. Code Scanning é ideal para equipes que querem uma solução simples, rápida e integrada ao GitHub. - [ ] CodeQL CLI - Execute processos do CodeQL localmente em projetos de software ou para gerar resultados da code scanning para upload no GitHub. (CodeQL CLI permite que você faça uma análise estática de código). CodeQL CLI é melhor para quem precisa de análises mais profundas e personalizadas, ou para projetos que exigem uma abordagem de análise fora do GitHub, como projetos privados ou repositórios que não são hospedados no GitHub, ou quem deseja escrever consultas específicas para tipos de vulnerabilidade particulares. - [x] Secret scanning - Detectar segredos, por exemplo, chaves e tokens, que foram verificados em repositórios privados. Se a proteção por push estiver habilitada, GitHub também detectará segredos quando eles forem enviados por push para o repositório. Estão disponíveis e são gratuitos para todos os repositórios públicos em GitHub.com - [ ] Regras de triagem automática personalizadas: Ajudar a gerenciar em escala seus dados

• Dependency review with Dependabot
• Code Scanning
• CodeQL scans from the command line
• Scret Scanning
• Triage Rules for Dependabot alerts
• Implementando Devops

Disponível com GitHub Advanced Security¶

Os recursos a seguir do GitHub Advanced Security estão disponíveis e são gratuitos para repositórios públicos no GitHub. - [x] Code scanning: Detectar automaticamente vulnerabilidades de segurança e erros de codificação em códigos novos ou modificados. - [ ] Alertas de verificação de segredo para usuários: Detectar automaticamente tokens ou credenciais que foram verificados em um repositório. - [ ] Regras de triagem automática personalizadas: - [ ] Análise de dependência: Mostre o impacto completo das alterações nas dependências e veja detalhes de qualquer versão vulnerável antes de fazer merge de um pull request.

Números de identificação CVE¶

GitHub Security Advisories baseia-se na base da lista de Vulnerabilidades e Exposições Comuns (CVE).

GitHub é uma Autoridade de Numeração CVE (CNA) e está autorizada a atribuir números de identificação CVE. Para obter mais informações, confira "Sobre o CVE" e "Autoridades de Numeração do CVE" no site do CVE.

Comandos Git e GitHub CLI¶

sequenceDiagram
    Usário->>+GitHub: Commit ou Push mudanças
    GitHub->>+GitHub: "Run Secret Regexp patterns"
    GitHub->>+Verify EndPoint: Send match to verify endpoint
    Verify EndPoint->>+Verify EndPoint: Verifique se é uma correspondência
    activate Verify EndPoint
      Note right of Verify EndPoint: Revoke Secret
      Note right of Verify EndPoint: eMail Alert
    deactivate Verify EndPoint

Git¶

• Controle de versão Colaboração
• Gerenciamento de Código Automação
• Documentação e Auditoria
• Segurança e Backup
• Flexibilidade e Controle

MOTIVAÇÃO PARA CRIAÇÃO DO GIT¶

Controle Desentralizado¶

Antes do Git, o desenvolvimento do kernel Linux utilizava um sistema de controle de versão centralizado chamado Bitkeeper.

Ferramentas Proprietárias¶

O Bitkeeper era uma ferramenta proprietária. Em 2005, houve uma disputa entre a comunidade do kernel Linux e a empresa que desenvolvia Bitkeeper.

Desempenho e Eficiência¶

Linus Torvalds queria uma ferramenta que fosse rápida e eficiente para grandes projetos de software.

Branching e Merging¶

Um dos principais problemas com os sistemas de controle de versão anteriores era a dificuldade em lidar com branching e merging.

Principais recursos do Git e serviços de repositório remoto¶

Controle de versão: usando o Git, você pode registrar, rastrear e recuperar seus históricos de codificação. Codificação colaborativa: no Git e nos serviços de repositório remoto, você pode compartilhar seu código, obter códigos de outras pessoas e trabalhar em equipe. Gerenciamento e automação de tarefas: a maioria dos repositórios remotos do Git: Os serviços fornecem recursos adicionais para gerenciar tarefas e automatizar o fluxo de trabalho, como implantação automática.

Um repositório é um local onde diferentes versões de códigos são armazenadas. Existem dois tipos de repositórios:

• Repositório Local: é instalado no seu computador local.
• Repositório Remoto: geralmente é criado em uma plataforma web, como o GitHub, na Internet.
• Commit cria um snapshot para registrar o status da codificação em um repositório.
• O Git usa hashes que têm 160 bits de comprimento.
• Objeto: um repositório Git contém quatro tipos de objetos, cada um exclusivamente identificado por um hash SHA-1.
  • Um objeto de blob contém um arquivo comum.
  • Um objeto de árvore representa um diretório; ele contém nomes, hashes e permissões.
  • Um objeto de commit representa uma versão específica da árvore de trabalho.
  • Uma marca é um nome anexado a um commit;
• Os comandos são frequentemente acompanhados por opções, que usam hifens (-) ou hifens duplos (--). Por exemplo, git reset --hard.
• A Working Tree (diretório de trabalho) é usada para editar seu arquivo de trabalho.Os arquivos e diretórios que você normalmente vê no diretório do projeto.
• Staging Area (INDEX) é uma área de buffer usada para preparar seus arquivos de trabalho para commit.(git add)
• O Repositório Local é um lugar onde os arquivos confirmados são armazenados com históricos de versão. (git commit)
• A codificação colaborativa é tipicamente gerenciada por meio de um Repositório Remoto.
• Um Branch no Git é uma linha independente de desenvolvimento com um histórico de commits. Cada branch fornece um espaço de gravação dedicado e tem seu próprio histórico de codificação (uma linha de commits).

Separe¶

• Fork é um recurso fornecido pelo GitHub usado para criar uma réplica de um Repositório Remoto no GitHub. Após implementar o Fork, o repositório replicado será separado do repositório original. Fork não é um comando git.
• Clone: Clone é usado para criar uma cópia local de um Repositório Remoto. Para implementar Clone, você precisa executar git clone com o nome do Repositório Remoto e a URL do Repositório Remoto.
• Working Tree (Working Directory) é usado para editar seus arquivos de trabalho. Os arquivos e diretórios que você geralmente vê no diretório do projeto são a Working Tree.
• Staging Area é uma área de buffer usada para preparar seus arquivos de trabalho para commit. O comando para trazer os arquivos de trabalho para a Staging Area é git add.
• Repositório Local é um lugar onde os arquivos confirmados são armazenados com seus históricos de versão.
• O último commit (a versão mais recente) é chamado HEAD. Para indicar um commit antes de HEAD, você pode usar HEAD~ (til) ou HEAD^ (acento circunflexo). O significado de ~ e ^ será diferente
• INDEX é outro termo para a área de preparação. A partir desta página, usamos INDEX em vez de Staging Area.
• Untracked Files → Quando você não executou uma confirmação antes e não preparou nenhum arquivo, os arquivos podem ter os status mostrados na ilustração abaixo.
• No Staged Files → Arquivos modificados mas ainda não foram para o INDEX
• Index → Arquivos adicionados
• HEAD → Arquivos confirmados.

git init --initial-branch=main
git diff HEAD~1
+ código adicionado
- código excluído
git restore [ caminho do arquivo ou caminho do diretório ] ou git restore [caminho do arquivo ou caminho do diretório] -s [Hash de confirmação]

clonando repositórios do GitHub usando HTTPS, recomendamos você usar o GitHub CLI ou o Git Credential Manager (GCM) para lembrar suas credenciais. Quando o Git solicitar sua senha, insira seu personal access token. Em um sistema de controle de versão distribuído, cada desenvolvedor tem uma cópia completa do projeto e do histórico do projeto

Diferenças entre .git/info/exclude e .gitignore:

Para impedir que determinados arquivos sejam exibidos em comparações por padrão, ou que sejam considerados na linguagem do repositório, você poderá marcá-los com o atributo linguist-generated em um arquivo .gitattributes.

O .gitignore é compartilhado entre todos os desenvolvedores que clonavam o repositório, ou seja, ele é versionado e sincronizado no repositório.

O .git/info/exclude é específico para o repositório local. Ele não é versionado e não afeta outros colaboradores. Ou seja, o que você coloca ali só vale para o seu ambiente local.

Revise edições e crie uma transação de commit

$ git status

Lista todos os arquivos novos ou modificados para serem commitados

$ git diff

Mostra diferenças no arquivo que ainda não foram preparadas

$ git add [arquivo]

Faz o snapshot de um arquivo na preparação para versionamento

$ git diff --staged

Mostra a diferença entre arquivos preparados e suas últimas versões

$ git reset [arquivo]

Retira o arquivo da área de preparação, mas preserva seu conteúdo

$ git commit -m "[mensagem descritiva]"

Grava o snapshot permanentemente do arquivo no histórico de versão

Mudanças em grupo
Nomeie uma série de commits e combine os esforços completos

$ git branch

Lista todos os branches locais no repositório atual

$ git branch [nome-do-branch]

Cria um novo branch

$ git switch -c [nome-do-branch]

Muda para o branch especificado e atualiza o diretório de trabalho

$ git merge [nome-do-branch]

Combina o histórico do branch especificado ao branch atual

$ git branch -d [nome-do-branch]

Exclui o branch especificado

Navegue e inspecione a evolução dos arquivos do projeto

$ git log

Lista o histórico de versões para o branch atual

$ git log --follow [arquivo]
Lista o histórico de versões para um arquivo, incluindo mudanças de nome
$ git diff [primerio-branch]...[segundo-branch]
Mostra a diferença de conteúdo entre dois branches
$ git show [commit]
Retorna mudanças de metadata e conteúdo para o commit especificado
Desfaça commit
Apague enganos e crie um histórico substituto
$ git reset [commit]
Desfaz todos os commits depois de [commit], preservando mudanças locais
$ git reset --hard [commit]
Descarta todo histórico e mudanças para o commit especificado
Sincronize mudanças
Registre um repositório remoto e troque o histórico de versão
$ git fetch [nome-remoto]
Baixe todo o histórico de um repositório remoto
$ git merge [nome-remoto]/[branch]
Combina o branch remoto ao branch local atual
$ git push [alias] [branch]
Envia todos os commits do branch local para o GitHub
$ git pull
Baixa o histórico e incorpora as mudanças
Refatore nomes de arquivos
Mude e remova os arquivos versionados
$ git rm [arquivo]
Remove o arquivo do diretório de trabalho e o prepara a remoção

$ git rm --cached [arquivo]

Remove o arquivo do controle de versão mas preserva o arquivo localmente

$ git mv [arquivo-original] [arquivo-renomeado]

Muda o nome do arquivo e o prepara para o commit

Suprima o monitoramento
Ignore arquivos e diretórios temporários

*.log
build/
temp-*
Um arquivo de texto chamado .gitignore suprime o versionamento acidental de arquivos e diretórios correspondentes aos padrões especificados

$ git ls-files --others --ignored --exclude-standard

Lista todos os arquivos ignorados neste projeto

Salve fragmentos
Arquive e restaure mudanças incompletas

$ git stash

Armazena temporariamente todos os arquivos monitorados modificados

$ git stash pop

Restaura os arquivos recentes em stash

$ git stash list

Lista todos os conjuntos de alterações em stash

$ git stash drop

Descarta os conjuntos de alterações mais recentes em stash

git remote -v
git remote add origin https://github.com/octocat/Spoon-Knife.git
git remote set-url origin https://github.com/OWNER/REPOSITORY.git
git remote rename origin destination
git remote rm destination
git config --global user.name "Mona Lisa"
git config --global core.editor "code --wait"
git config --global core.autocrlf input
git config --global core.autocrlf input
# push changes to github
git push --set-upstream origin main
git push REMOTE-NAME LOCAL-BRANCH-NAME:REMOTE-BRANCH-NAME
git push REMOTE-NAME TAG-NAME 
git push REMOTE-NAME --tags (Push de todas as suas tags)
git push REMOTE-NAME :BRANCH-NAME (Excluir uma tag)
git remote add upstream THEIR_REMOT (Adiciona outro remoto)

git push origin main
git fetch origin
git merge origin YOUR_BRANCH_NAME
git pull origin YOUR_BRANCH_NAME

.gitattributes¶

Opcionalmente, você pode configurar um arquivo .gitattributes para gerenciar como o Git lê delimitadores de linha em um repositório específico.

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto
# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text
# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
# Denote all files that are truly binary and should not be modified.
*.png binary

• text=auto O Git vai manipular os arquivos da forma que achar melhor. Essa é uma boa opção padrão.
• text eol=crlf O Git sempre converterá delimitadores de linha em CRLF no check-out. Você deve usar isso para arquivos que devem manter finais CRLF, mesmo no OSX ou Linux.
• text eol=lf O Git sempre converterá delimitadores de linha em LF no check-out. Você deve usar isso para arquivos que devem manter os delimitadores LF, mesmo no Windows.
• binary O Git entenderá que os arquivos especificados não são texto e não deverá tentar alterá-los. A configuração binary também é um alias para -text -diff.

.gitignore¶

• Cancela o rastreamento de um determinado arquivo: git rm --cached FILENAME
• Para sempre ignorar um determinado arquivo ou diretório, adicione-o a um arquivo chamado ignore que está localizado dentro do diretório ~/.config/git.
• Como excluir arquivos locais sem criar um arquivo .gitignore
  • Abrir o arquivo chamado .git/info/exclude na raiz do repositório Git.

Adicionar um arquivo ao seu repositório¶

No campo do nome de arquivo, digite o nome e a extensão do arquivo. Para criar subdiretórios, digite o separador de diretório .

Branches¶

Branch é um lugar seguro para experimentar novos recursos ou correções. git checkout -b newBranchName

Commits¶

Uma confirmação é uma alteração em um ou mais arquivos de um branch. confirmação é criada, é atribuído a ela uma ID exclusiva. 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 emcó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).
• raw : Commits do tipo raw indicam mudanças relacionadas a arquivos de configurações, dados, features, parâmetros.
• cleanup : Commits do tipo cleanup são utilizados para remover código comentado, trechos desnecessários ou qualquer outra forma de limpeza do código-fonte, visando aprimorar sua legibilidade e manutenibilidade.
• remove : Commits do tipo remove indicam a exclusão de arquivos, diretórios ou funcionalidades obsoletas ou não utilizadas, reduzindo o tamanho e a complexidade do projeto e mantendo-o mais organizado.

Estados primários de um arquivo (lazygit)¶

Os estados primários de um arquivo em um repositório Git são Não rastreado e Rastreado.

https://learn.microsoft.com/pt-br/training/modules/introduction-to-github/3-components-of-github-flow

• Não rastreado: Um estado inicial de um arquivo quando ele ainda não faz parte do repositório Git. O Git desconhece a existência dele.
• Rastreado: Um arquivo rastreado é aquele que o Git está monitorando ativamente. A imagem pode estar em um dos seguintes subestados:
  • Não modificado: O arquivo é rastreado, mas não foi modificado desde a última confirmação.
  • Modificado: O arquivo foi alterado desde o último commit, mas essas alterações ainda não foram preparadas para o próximo commit.
  • Encenado: O arquivo foi modificado e as alterações foram adicionadas à área de preparo (também conhecida como índice). Essas mudanças estão prontas para serem confirmadas.
  • Empenhado: O arquivo está no banco de dados do repositório. Ele representa a versão confirmada mais recente do arquivo.

Configuração Básica - Git¶

Configurações do usuário do Git – git config

git config --global user.name   "nome"
git config --global user.email  "nome"
git config --global core.editor "nome" --wait
git config --global --list 
git config --global unset core.editor
git config --global --get user.email

Fluxo de Contribuição¶

Normalmente elaboramos dois fluxos a serem tratados no GitHub, um que você começa e outro que você participa de um outro projeto. O gh auth login, poderá ser abandonado caso a variável GH_TOKEN, esteja definida.

Criando um repositório¶

gh auth login
gh repo create ghf --public --description "Estudo prova de Certificação - GitHub Foundations" --add-readme --gitignore "Java" --license mit
gh project create "projeto-ghf" --owner "@me" --title "Projeto Estudo GitHub Foundation"
gh issue create --title "Falha na Documentação" --body "O corpo da documentação não esta com acentuação" --label documentation --project "Projeto Estudo GitHub Foundation" --repo "https://github.com/s60pportunities/ghf"
Associar a Issu a uma branch (criar uma branch)
git clone https://github.com/seu-usuario/prova-foundations.git  -b nome_da_branch
cd prova-foundations
git checkout -b nova-branch
echo "Conteúdo do novo arquivo" >> novo-arquivo.txt
git add novo-arquivo.txt
git commit -m "Adiciona novo arquivo"
git push origin nova-branch
gh pr create --base main --head  1-falha-na-documentao --title "Adiciona novo arquivo" --body "Descrição do que foi feito fix #1" --draft
gh pr edit <NÚMERO_DO_PR> --body "Descrição do que foi feito. Relacionado à #<NÚMERO_DA_ISSUE>"
gh issue close <NÚMERO_DA_ISSUE>

Forkeando um Repositório¶

gh auth login
gh repo fork usuario/original-repositorio --clone
cd original-repositorio
git checkout -b nova-branch
echo "Conteúdo do novo arquivo" >> novo-arquivo.txt
git add novo-arquivo.txt
git commit -m "Adiciona novo arquivo"
git push origin nova-branch

gh pr create --base main --head nova-branch --title "Adiciona novo arquivo" --body "Descrição do que foi feito" --draft
gh issue create --title "Título da Issue" --body "Descrição da issue"
gh pr edit <NÚMERO_DO_PR> --body "Descrição do que foi feito. Relacionado à #<NÚMERO_DA_ISSUE>"
gh issue close <NÚMERO_DA_ISSUE>

Com o github e git¶

git clone https://github.com/owner/repo.git
cd repo
git branch my-branch
git checkout my-branch
git add file1.md file2.md
git commit -m "my snapshot"
git push --set-upstream origin my-branch

Com o GiHhub CLI¶

gh repo fork https://github.com/octocat/Spoon-Knife
gh repo set-default s60pportunities/Spoon-Knife
gh repo clone s60pportunities/Spoon-Knife
cd Spoon-Knife
git checkout -b feature
vi LICENsE.md
git add .
git commit -m "Descrição das alterações feitas"
git push origin feature
gh pr create --draft --base main --head origin/feature --title "Título do PR" --body "Descrição do que foi feito"
gh pr ready --draft

Sobre merges de subárvore do Git¶

Uma subárvore é usado para conter um repositório dentro de outro repositório. O

mkdir test
cd test
git init
touch .gitignore
git add .gitignore
git commit -m "initial commit"
git remote add -f spoon-knife https://github.com/octocat/Spoon-Knife.git
git merge -s ours --no-commit --allow-unrelated-histories spoon-knife/main
git read-tree --prefix=spoon-knife/ -u spoon-knife/main
git commit -m "Subtree merged in spoon-knife"

Sincronizar com atualizações e alterações¶

git pull -s subtree REMOTE-NAME BRANCH-NAME

Rebase¶

• Editar mensagens anteriores do commit
• Combinar vários commits em um
• Excluir ou reverter commits que não são mais necessários

git rebase --interactive OTHER-BRANCH-NAME git rebase --interactive HEAD~7

Dividir uma subpasta em um novo repositório¶

Você pode transformar uma pasta em um repositório do Git repository em um novo repositório.

git clone https://github.com/USERNAME/REPOSITORY-NAME
cd REPOSITORY-NAME
git filter-repo --path FOLDER-NAME/
git filter-repo --subdirectory-filter FOLDER-NAME
crie um repositório
git remote add origin https://github.com/USERNAME/REPOSITORY-NAME.git
git remote -v
git push -u origin BRANCH-NAME

Há uma pasta oculta chamada .git que informa que nosso projeto é um repositório git.

Se quiséssemos criar um repositório git em um novo projeto, criaríamos a pasta e inicializaríamos esse repositório usando: git init

mkdir /workspaces/tmp/new-project
cd /workspaces/tmp/new-project
git init
touch Readme.md
code Readme.md
git status
git add Readme.md
git commit -m "add readme file"

Clonagem¶

Podemos clonar de três maneiras: HTTPS, SSH, Github CLI. Como estamos usando o GitHub Codespaces, criaremos um diretório temporário em nosso workspace

mkdir /workspace/tmp
cd /workspace/tmp

HTTPS¶

git clone https://github.com/horaciovasconcellos/estudo.git
cd estudo

Você precisará gerar um Token de Acesso Pessoal (PAT): https://github.com/settings/token

Você usará o PAT como sua senha ao fazer login

• Dê a ele acesso ao Conteúdo para Commits

SSH¶

git clone git@github.com:horaciovasconcellos/estudo.git
cd estudo

Precisaremos criar nosso próprio par de chaves SSH rsa

sshe-keygen -t rsa

Para usuários do WSL e se você criar uma chave não padrão, pode ser necessário adicioná-la

eval `ssh-agent`
ssh-add /home/horaciovasconcellos/.ssh/alt-github_id_rsa

Podemos testar nossa conexão aqui:

ssh -T git@github.com

Github CLI¶

Instale o CLI por exemplo, Linux (Ubuntu)

brew install gh

gh auth login
gh repo clone horaciovasconcellos/estudo

Commits¶

Quando queremos fazer commit de código, podemos escrever git commit, que abrirá a mensagem de edição de commit no editor de sua escolha.

git commit

Definir o editor global

git config --global core.editor code

Criar um commit e uma mensagem de commit sem abrir um editor

git commit -m "<doc>: Adicionar outra exclamação"

Branches¶

• Lists all local branches : git branch
• Creates a new branch : git branch [branch-name]
• Checkout (switch to) a branch : git checkout [branch-name]
• Create and checkout a branch : git checkout -b [branch name]
• Deletes a branch : git branch -d [branch-name]
• Renames a branch : git branch -m [old-name] [new-name]
• Lists both remote and local branches: git branch -a

Remotes¶

Podemos adicionar remoto, mas geralmente você adicionará remoto via upsteam ao adicionar um branch

git remote -v
git remote add origin https://github.com/OWNER/REPOSITORY.git
git remote add ...
git branch -u origin new-feature

Stashing¶

git stash list
git stash
git stash save my-name
git stash apply
git stash pop

Mesclando¶

git checkout dev
git merge main

Adicionar¶

Quando queremos preparar alterações que serão incluídas no commit Podemos usar o . para adicionar todos os arquivos possíveis.

git add Readme.md
git add .

Redefinir¶

Redefinir permite que você mova alterações preparadas para não preparadas. Isso é útil quando você deseja reverter todos os arquivos para não serem confirmados

git add .
git reset

git reset irá revogar um git add.

Status¶

O status do Git mostra quais arquivos serão ou não confirmados.

git status

Arquivo Gitconfig¶

O arquivo gitconfig é o que armazena suas configurações globais para o git, como e-mail, nome, editor e muito mais.

Exibindo o conteúdo do nosso arquivo .gitconfig

git config --list

Quando você instala o Git pela primeira vez em uma máquina, você deve configurar seu nome e e-mail

git config --global user.name "Usuário"
git config --global user.email "usuario@dominio.com.br"

Log¶

git log mostrará os commits recentes do git para a árvore git

Push¶

Quando queremos enviar um repositório para nossa origem remota

git push

GitHub Classroom¶

É uma ferramenta de ensino que permite que professores e administradores escolares criem e gerenciem salas de aula e tarefas digitais.

• Modelos de tarefa: Proprietários de organizações que são administradores de uma sala de aula podem criar uma tarefa a partir de um repositório de modelos que seja público ou de propriedade da organização.

GitHub Apps¶

Os GitHub Apps são ferramentas que estendem a funcionalidade do GitHub. Os GitHub Apps podem fazer coisas no GitHub como abrir problemas, fazer comentários sobre solicitações de pull e gerenciar projetos.

    sequenceDiagram
    WorkingDirectory->>StagingArea:staging
    StagingArea->>Repository: commiting
    Repository->>WorkingDirectory: checking out

Passos de um projeto¶

Quando você encontra um projeto que gosta, pode segui-lo e rastrear Fork clone fazer todas as alterações na sua cópia do projeto enviar uma solicitação de pull para o mantenedor do projeto Outros colaboradores revisam suas alterações e podem solicitar algumas modificações adicionais. Depois que todas as partes concordam com as alterações, a solicitação de pull é aceita e suas alterações se tornam parte do projeto! Você pode contribuir para projetos escrevendo documentação, fornecendo traduções ou revisando as alterações feitas por outros colaboradores. precisam de testadores e indivíduos para oferecer insights

sequenceDiagram
    participant Usuário
    participant GitHub
    participant Mantenedor
    participant Colaboradores
    participant Projeto

    Usuário->>GitHub: Encontra um projeto interessante
    Usuário->>GitHub: Segue o projeto para rastrear atualizações
    Usuário->>GitHub: Realiza um **Fork** do projeto
    Usuário->>GitHub: Clona o repositório para seu ambiente local
    Usuário->>Usuário: Faz alterações na sua cópia do projeto
    Usuário->>GitHub: Envia um **Pull Request** para o repositório original
    Mantenedor->>GitHub: Recebe a solicitação de pull
    Mantenedor->>Colaboradores: Solicita revisão da solicitação de pull
    Colaboradores->>Mantenedor: Revisam alterações e solicitam modificações, se necessário
    Mantenedor->>Usuário: Solicita modificações adicionais (se houver)
    Usuário->>GitHub: Realiza as modificações solicitadas e atualiza a solicitação de pull
    Mantenedor->>GitHub: Aceita o Pull Request
    GitHub->>Projeto: A integração é concluída e as alterações são mescladas no projeto
    Usuario->>Projeto: Contribui com documentação, traduções ou revisão de código
    Colaboradores->>Projeto: Outros colaboram fornecendo insights ou atuando como testadores

1. Mantenedor (Maintainer) Responsabilidades: Gestão do Projeto: O mantenedor é responsável por guiar o desenvolvimento do projeto, definindo a direção do código, as funcionalidades e as versões. Revisão de Pull Requests (PRs): Avaliar e aceitar ou rejeitar contribuições de outros desenvolvedores. Isso inclui validar o código, garantir que ele siga as diretrizes do projeto e que não quebre funcionalidades existentes. Gestão de Releases: Criar e manter as versões do projeto, incluindo a gestão de versões estáveis e beta. Decisões Estratégicas: Tomar decisões sobre novas funcionalidades, mudanças no design e outras alterações importantes no projeto. Comunicação com a Comunidade: Representar o projeto e interagir com a comunidade de desenvolvedores e usuários. Muitas vezes, o mantenedor responde a questões, problemas e solicitações de usuários.
2. Contribuidores (Contributors) Responsabilidades: Desenvolvimento de Código: Contribuir com novos recursos, correções de bugs e melhorias no código. Os contribuidores normalmente fazem fork de um repositório e enviam pull requests com suas alterações. Testes e Revisões: Testar funcionalidades e revisar o código de outros colaboradores, fornecendo feedback útil. Documentação: Contribuir com a documentação do projeto, seja para funcionalidades específicas, tutoriais ou guias de uso. Discussões Técnicas: Participar de discussões sobre as direções do projeto e discutir questões técnicas.
3. Colaboradores (Collaborators) Responsabilidades: Colaborar no Código e nas Revisões: Embora o termo "colaborador" possa ser usado de forma geral para descrever qualquer pessoa que contribua para o projeto, em alguns projetos open-source, colaboradores têm permissões especiais no repositório, como a capacidade de revisar e mesclar pull requests. Gerenciamento de Issues: Ajudar a gerenciar as issues, atribuindo, comentando e priorizando os problemas que precisam ser resolvidos no projeto. Moderadores de Discussões: Em alguns casos, colaboradores ajudam a moderar discussões em fóruns ou em plataformas como GitHub Discussions ou Slack.
4. Usuários (Users) Responsabilidades: Uso do Software: A principal responsabilidade dos usuários é utilizar o software e reportar bugs ou problemas encontrados. Feedback: Fornecer feedback sobre o uso do software e sugerir melhorias. Relatar Issues: Informar sobre falhas ou erros encontrados, além de documentar problemas de forma útil para os desenvolvedores. Testadores Beta: Usuários também podem testar versões beta ou candidatas a lançamento de novas versões do software, fornecendo informações críticas sobre o comportamento do sistema em diferentes cenários.
5. Testadores (Testers) Responsabilidades: Testar Funcionalidades: Validar se as funcionalidades estão funcionando como esperado, testar novos recursos e reportar falhas ou inconsistências. Automação de Testes: Em projetos maiores, os testadores podem colaborar na criação de testes automatizados, garantindo que o código seja continuamente verificado e que erros sejam detectados rapidamente. Revisão de Testes: Revisar e validar os testes existentes, sugerindo melhorias ou atualizações conforme o projeto evolui.
6. Documentadores (Documenters) Responsabilidades: Documentação Técnica: Criar e manter a documentação técnica do projeto, que pode incluir guias de instalação, manuais de uso, exemplos de código e explicações detalhadas sobre como o código funciona. Tutoriais e Guias: Criar tutoriais ou guias para novos usuários ou desenvolvedores interessados em contribuir. Melhoria da Documentação: Revisar e melhorar a documentação existente, corrigindo erros ou tornando as informações mais claras.
7. Designers (Designers) Responsabilidades: Design de Interface: Trabalhar na interface do usuário (UI), criando protótipos e layouts que melhoram a experiência do usuário. Design de Marca: Criar elementos visuais para o projeto, como logotipos, esquemas de cores e outros recursos gráficos que ajudam a estabelecer uma identidade visual para o projeto. Experiência do Usuário (UX): Focar na experiência geral de interação do usuário com o software, sugerindo alterações no design para torná-lo mais intuitivo.
8. Gerentes de Comunidade (Community Managers) Responsabilidades: Gerenciamento da Comunidade: Estabelecer e cultivar a comunidade de colaboradores e usuários em torno do projeto. Isso pode incluir moderar fóruns, criar canais de comunicação e facilitar discussões produtivas. Engajamento e Crescimento da Comunidade: Criar estratégias para aumentar o envolvimento da comunidade, como campanhas para novos contribuidores, organização de eventos, e promover boas práticas de colaboração. Resolução de Conflitos: Gerenciar disputas ou conflitos dentro da comunidade, garantindo que todos os envolvidos sigam as normas do projeto e que a colaboração seja respeitosa e produtiva.
9. Revisores de Código (Code Reviewers) Responsabilidades: Revisão de Pull Requests: Avaliar as alterações de código propostas por outros desenvolvedores, procurando por erros, oportunidades de melhorias e garantindo que o código siga as convenções do projeto. Sugestões e Aprovação: Fornecer sugestões para melhorar o código e aprovar pull requests para integração ao projeto principal. Garantir Qualidade: Manter a qualidade do código do projeto, garantindo que novos recursos ou correções não introduzam falhas ou quebras.
10. Tradutores (Translators) Responsabilidades: Tradução de Documentação e Software: Traduzir o software e sua documentação para diferentes idiomas, para tornar o projeto acessível a uma audiência global. Revisão de Traduções: Garantir que as traduções sejam precisas e que a terminologia usada no contexto do projeto seja consistente.
11. Patrocinadores (Sponsors) Responsabilidades: Patrocinar o Projeto: Empresas ou indivíduos podem financiar o projeto ou oferecer recursos como infraestrutura (servidores, ferramentas, etc.), permitindo que o projeto continue seu desenvolvimento. Apoio em Promoção e Divulgação: Em alguns casos, patrocinadores ajudam a divulgar o projeto, garantindo mais visibilidade e apoio financeiro.
12. Gerentes de Projeto (Project Managers) Responsabilidades: Coordenação das Tarefas: Organizar e coordenar o trabalho entre os diferentes colaboradores, garantindo que as metas sejam atingidas e os prazos sejam cumpridos. Planejamento e Prioridade: Trabalhar com a comunidade para definir o que será desenvolvido em cada release, priorizando as funcionalidades mais importantes.

¶

O arquivo README deve apresentar o projeto e transmitir os problemas que ele pretende resolver.

man gittutorial

GitHub no Enterprise geralmente usam SCIM e funcionam com IdPs como Microsoft Entra e Okta,¶