2. Produtos do Github
Vamos lá pessoal, vamos agora abordar sobre os tipos e planos de conta do Github.
- O quê? Conta individual no GitHub.com.
- Recursos: Repositórios, pacotes, projetos.
- Plano: GitHub Free ou GitHub Pro.
- O quê? Contas compartilhadas para colaboração em projetos.
- Recursos: Repositórios, pacotes, projetos.
- Gestão: Feita através de contas pessoais.
- Permissões: Diferentes papéis para membros.
- Destaque: Colaboração e gerenciamento avançado.
- O quê? Para administradores gerenciarem políticas e faturamento em várias organizações.
- Recursos: Repositórios, pacotes, projetos.
- Gestão: Centralizada com políticas empresariais.
- Para quem? Pessoas e organizações.
- Recursos: Repositórios ilimitados, alertas Dependabot, suporte da comunidade.
- Limitações: Recursos limitados para repositórios privados.
- Para quem? Desenvolvedores individuais.
- Recursos Adicionais: Suporte via e-mail, mais minutos de GitHub Actions, armazenamento adicional.
- Destaque: Ferramentas avançadas para repositórios privados.
- Para quem? Organizações.
- Recursos Adicionais: Mesmos benefícios do GitHub Pro, mas com mais minutos e armazenamento.
- Colaboração: Suporte a equipes maiores.
- Para quem? Empresas.
- Recursos Adicionais: Suporte empresarial, controles de segurança avançados, opções de implantação.
- Opções: GitHub Enterprise Server (auto-hospedado) ou GitHub Enterprise Cloud.
Neste tópico, vamos conhecer um pouco sobre as quatro novas Certificações do Github :)
Com as Certificações do GitHub, podemos destacar nossas habilidades em tecnologias e fluxos de trabalho do GitHub. Com a Certificação do GitHub temos uma ampla vantagem competitiva no mercado de trabalho, que possibilita a promoção das nossas habilidades em um domínio específico do GitHub.
Com o certificado de Fundamentos do GitHub, você pode destacar sua compreensão dos tópicos e conceitos fundamentais de colaboração, contribuição e trabalho no GitHub. Este exame abrange:
- Colaboração
- Produtos do GitHub
- Noções básicas do Git
- Trabalhando dentro de repositórios do GitHub
Você pode certificar sua proficiência em automatizar fluxos de trabalho e acelerar o desenvolvimento com Ações do GitHub, obtendo um certificado de Ações do GitHub. Este exame abrange:
- Otimização de fluxos de trabalho
- Automatização de tarefas
- Otimização de pipelines de software
Você pode destacar seu conhecimento em segurança de código com o certificado Avançado de Segurança do GitHub. Este exame abrange:
- Identificação de vulnerabilidades
- Segurança de fluxo de trabalho
- Implementação de segurança
Você pode certificar sua capacidade de otimizar e gerenciar um ambiente GitHub saudável com o exame de Administração do GitHub. Este exame abrange:
- Gerenciamento de repositórios
- Otimização de fluxo de trabalho
- Colaboração eficiente
Após a conclusão bem-sucedida de um exame de certificação, você receberá um distintivo e certificado Credly para verificar suas credenciais.
Sobre o Github Certification: https://docs.github.com/pt/get-started/showcase-your-expertise-with-github-certifications/about-github-certifications FAQ Oficial: https://examregistration.github.com/faq Manual do Candidato: https://examregistration.github.com/handbook Detalhes das Certificações: https://resources.github.com/learn/certifications/ Registro de Certificação: https://examregistration.github.com/login?ReturnUrl=%2Foverview
Vamos aprender sobre o Projects, umaa ferramenta de gerenciamento de programas do GitHub, onde podemos organizar e priorizar o trabalho da nossa equipe em um único espaço. Bora lá?! xD
-
Criando e Configurando Projetos:
- A criação de projetos no GitHub oferece uma experiência aprimorada para organizar e priorizar o trabalho de uma equipe.
- Os projetos permitem o acompanhamento visual em tabelas e quadros, personalizando campos, atribuindo iterações e vinculando solicitações de pull.
- Dados personalizados, gráficos, e automação, como a API GraphQL e webhooks, são destacados para uma gestão mais eficiente.
-
Organizando Seu Projeto:
- A organização de projetos envolve a criação de campos personalizados, iterações, e a configuração de visualizações de quadro.
- Priorização e categorização de tarefas são facilitadas pela criação de campos de prioridade e iteração.
- A visão de quadro proporciona uma abordagem visual para entender e trabalhar nas tarefas prioritárias.
-
Adicionando e Gerenciando Tarefas:
- Adicionar problemas e solicitações de pull aos projetos é fundamental para o acompanhamento do progresso e coordenação das metas.
- Diferentes métodos são apresentados, como colar URLs, procurar itens existentes e adicionar em massa para repositórios existentes.
- A capacidade de agrupar, filtrar e mover tarefas em tempo real é destacada para uma gestão dinâmica.
-
Visão Geral e Controle de Acesso:
- O controle de acesso e visibilidade do projeto são fundamentais para garantir a segurança e a privacidade.
- Configurações de visibilidade pública ou privada são destacadas, com a capacidade de gerenciar acessos para organizações e projetos pessoais.
- Papéis, como leitura, gravação e administração, são explicados para ambos os níveis de projeto.
-
Insights e Automação:
- Os insights fornecem uma visão analítica do projeto, permitindo a criação e personalização de gráficos para análises atuais e históricas.
- Gráficos atuais podem destacar atribuições e iterações, enquanto os históricos exibem tendências e progresso ao longo do tempo.
- A automação é discutida, cobrindo fluxos de trabalho incorporados, GraphQL API e GitHub Actions para personalização avançada e otimização de tarefas.
GitHub Copilot é um parceiro de codificação de IA que fornece sugestões de preenchimento automático enquanto você codifica. Obtenha sugestões digitando o código ou descrevendo-o em linguagem natural.
Mas afinal, o que é o Github Copilot?
O GitHub Copilot é um serviço que fornece um programador de IA como parceiro, compatível com todas as linguagens de programação populares, e acelera drasticamente a produtividade geral dos desenvolvedores. Em pesquisas recentes, o GitHub e a Microsoft descobriram que os desenvolvedores experimentam um aumento significativo na produtividade ao trabalhar em projetos e tarefas do mundo real usando o GitHub Copilot. Na verdade, em menos de dois anos desde o seu lançamento, os desenvolvedores experimentaram o seguinte ao usar o GitHub Copilot:
- 46% do novo código é agora escrito pela IA
- 55% de aumento na produtividade geral dos desenvolvedores
- 74% dos desenvolvedores se sentem mais focados no trabalho satisfatório
Desenvolvido em colaboração com a OpenAI, o GitHub Copilot é alimentado pelo OpenAI Codex, um sistema de IA criado pela OpenAI. O OpenAI Codex possui amplo conhecimento sobre como as pessoas usam código e é mais capaz do que o GPT-3 na geração de código, em parte porque foi treinado em um conjunto de dados que inclui uma concentração maior de código-fonte público.
O GitHub Copilot está disponível como uma extensão para o Visual Studio Code, Visual Studio, Vim/Neovim e a suíte de ambientes de desenvolvimento integrado (IDEs) da JetBrains.
O GitHub Copilot iniciou uma nova era no desenvolvimento de software como um programador de IA que mantém os desenvolvedores no fluxo, autocompletando comentários e código, mas a autocompletção alimentada por IA foi apenas o ponto de partida. Aqui estão algumas características do GitHub Copilot que realmente o tornam uma ferramenta de desenvolvedor do futuro, ultrapassando apenas um editor e tornando-se um assistente de IA prontamente acessível ao longo de todo o ciclo de desenvolvimento.
O GitHub Copilot traz uma interface de chat para o editor focada em cenários de desenvolvedores e integra-se nativamente ao VS Code e ao Visual Studio. Ele reconhece o código que um desenvolvedor digitou, quais mensagens de erro são exibidas e está profundamente integrado ao IDE. Um desenvolvedor pode obter análises detalhadas e explicações sobre o que os blocos de código pretendem fazer, gerar testes unitários e até obter correções propostas para bugs.
Essa nova funcionalidade é alimentada pelo novo modelo GPT-4 da OpenAI e adiciona suporte para tags alimentadas por IA em descrições de pull requests por meio de um aplicativo GitHub que administradores de organizações e proprietários de repositórios individuais podem instalar. Essas tags são preenchidas automaticamente pelo GitHub Copilot com base no código alterado. Os desenvolvedores podem revisar ou modificar a descrição sugerida.
O GitHub está lançando o GitHub Copilot for Docs, uma ferramenta experimental que utiliza uma interface de chat para fornecer aos usuários respostas geradas por IA para perguntas sobre documentação, incluindo perguntas que os desenvolvedores têm sobre as linguagens, frameworks e tecnologias que estão utilizando.
Além do editor e do pull request, o terminal é o local onde os desenvolvedores passam mais tempo. No entanto, mesmo os desenvolvedores mais proficientes precisam rolar por muitas páginas para lembrar a sintaxe precisa de muitos comandos. O GitHub Copilot CLI pode compor comandos e loops, e utilizar flags de busca obscuras para atender à sua consulta.
O GitHub Copilot está disponível por meio de contas pessoais do GitHub com o GitHub Copilot Individual, ou por meio de contas de organização ou empresa com o GitHub Copilot Business e GitHub Copilot Enterprise.
O Copilot Business permite que você controle quem pode usar o GitHub Copilot em sua empresa. Depois de conceder acesso a uma organização, seus administradores podem então conceder acesso a indivíduos e equipes.
Com o Copilot Business, o GitHub Copilot está aberto a todos os desenvolvedores, equipes e organizações, e empresas.
Com recursos como completar código, chat na IDE e mobile, filtro de vulnerabilidades de segurança, referência de código, filtro de código público, indenização de IP e segurança, privacidade de nível empresarial, o GitHub Copilot Business visa tornar as organizações mais produtivas, seguras e satisfeitas. Esses recursos permitem que os desenvolvedores codifiquem mais rapidamente e se concentrem em trabalhos mais satisfatórios.
O GitHub Copilot Enterprise está disponível para organizações por meio do GitHub Enterprise Cloud.
O Copilot Enterprise permite que suas equipes de desenvolvedores se familiarizem rapidamente com sua base de código, pesquisem e construam documentação, recebam sugestões com base em código interno e privado e revisem rapidamente pull requests.
O GitHub Copilot Enterprise inclui tudo no GitHub Copilot Business, além de uma camada adicional de personalização para organizações e integração ao GitHub como uma interface de chat para permitir que os desenvolvedores conversem sobre sua base de código e botões de ação em toda a plataforma. O GitHub Copilot Enterprise pode indexar a base de código de uma organização para uma compreensão mais profunda do conhecimento do cliente para sugestões mais personalizadas e oferecer aos clientes acesso à Customização do GitHub Copilot para ajustar modelos personalizados e privados para completar código.
Esteja ciente de que, ao se inscrever para o teste gratuito do GitHub Copilot, será solicitado que você forneça uma forma de pagamento, embora você não seja cobrado até o final do teste gratuito. Certifique-se de cancelar antes dos 30 dias para evitar o pagamento.
Antes de começar a usar o GitHub Copilot, você precisa configurar um teste gratuito ou assinatura para sua conta pessoal.
- Selecione sua foto de perfil e depois selecione Configurações. O Copilot está no menu à esquerda, sob Código, planejamento e automação.
- Após a inscrição, será necessário instalar uma extensão para o ambiente de sua preferência. O GitHub Copilot é compatível com GitHub.com, Visual Studio Code, Visual Studio, IDEs JetBrains e Neovim como uma extensão discreta.
Siga estas etapas para adicionar a extensão do Visual Studio Code para o GitHub Copilot.
- No Visual Studio Code Marketplace, vá até a página de extensão do GitHub Copilot e selecione Instalar.
- Aparecerá um popup pedindo para abrir o Visual Studio Code. Selecione Abrir.
- Na guia Extension: GitHub Copilot no Visual Studio Code, selecione Instalar.
- Se você ainda não autorizou anteriormente o Visual Studio Code em sua conta do GitHub, será solicitado que faça login no GitHub no Visual Studio Code. Selecione Fazer login no GitHub.
O GitHub Copilot pode autocompletar o código conforme você digita ao usar o Visual Studio Code. Após a instalação, você pode ativar ou desativar o GitHub Copilot e configurar configurações avançadas dentro do Visual Studio Code.
- Para ativar ou desativar o GitHub Copilot, selecione o ícone de status no painel inferior da janela do Visual Studio Code. Captura de tela do ícone de status para o GitHub Copilot no painel inferior da janela do Visual Studio Code. A cor de fundo corresponde à cor da barra de status quando ativada.
- Ao desativar o GitHub Copilot, será perguntado se você deseja desativar as sugestões globalmente ou para o idioma do arquivo que você está editando no momento.
- Para desativar as sugestões do GitHub Copilot globalmente, selecione Desativar globalmente.
- Para desativar as sugestões do GitHub Copilot para um idioma específico, selecione Desativar para o IDIOMA.
- No menu Arquivo, vá para Preferências e selecione Configurações. Captura de tela do menu Arquivo no Visual Studio Code. O submenu suspenso Preferências está aberto com Configurações selecionadas.
- No painel esquerdo da guia de configurações, selecione Extensões e, em seguida, selecione Copilot.
- Em Inline Suggest: Enable, selecione ou desmarque a caixa de seleção para ativar ou desativar as sugestões em linha. Além disso, você pode optar por ativar ou desativar sugestões em linha e especificar para quais idiomas deseja ativar ou desativar o GitHub Copilot.
No Visual Studio Code, os arquivos de log são úteis para diagnosticar problemas de conexão. A extensão do GitHub Copilot armazena os arquivos de log na localização padrão para extensões do Visual Studio Code. Você pode encontrar os arquivos de log por meio da opção de desenvolvedor e abrir a pasta de logs de extensões dentro do Visual Studio Code.
Em casos raros, os erros podem não ser registrados nos locais regulares. Se encontrar erros e não houver nada nos logs, pode tentar visualizar os logs do processo em execução do Visual Studio Code e da extensão. Esse processo permite visualizar os logs do Electron. Você pode encontrar esses logs em desenvolvedor e em Ajuda > Alternar Ferramentas de Desenvolvedor dentro do Visual Studio Code.
Restrições de rede, firewalls ou seu proxy podem causar problemas ao se conectar ao GitHub Copilot. Se isso ocorrer, você pode seguir estas etapas para abrir um novo editor com as informações relevantes que você pode inspecionar ou compartilhar com a equipe de suporte.
- Abra a Paleta de Comandos do Visual Studio Code:
- Para Mac, use Shift+Command+P
- Para Windows ou Linux, use Ctrl+Shift+P
- Digite Diagnóstico, depois selecione GitHub Copilot: Coletar Diagnósticos na lista.
Vamos entender um pouco sobre o ciclo de vida do Codespace
GitHub Codespaces é um ambiente de desenvolvimento totalmente configurado e hospedado na nuvem. Ao usar GitHub Codespaces, seu espaço de trabalho, juntamente com todos os seus ambientes de desenvolvimento configurados, ficam disponíveis em qualquer computador com acesso à Internet. Objetivos de aprendizado
GitHub Codespaces é configurável, permitindo criar um ambiente de desenvolvimento personalizado para o seu projeto. Ao configurar um ambiente de desenvolvimento customizado para o seu projeto, você pode ter uma configuração de Codespace repetível para todos os usuários do seu projeto.
O ciclo de vida de um Codespace começa quando você cria um Codespace e termina quando você o exclui. É possível desconectar e reconectar-se a um Codespace ativo sem afetar seus processos em execução. Você pode parar e reiniciar um Codespace sem perder as alterações feitas em seu projeto.
Você pode criar um Codespace em GitHub.com, no Visual Studio Code ou pelo GitHub CLI. Existem quatro maneiras de criar um Codespace:
- A partir de um modelo GitHub ou de qualquer repositório de modelos em GitHub.com para iniciar um novo projeto.
- De uma ramificação em seu repositório para novos recursos funcionarem.
- De uma solicitação pull aberta para explorar o trabalho em andamento.
- De um commit no histórico de um repositório para investigar um bug em um momento específico.
Você pode usar temporariamente um Codespace para testar o código ou pode retornar ao mesmo Codespace para trabalhar em recursos de longa duração.
Você pode criar mais de um Codespace por repositório ou até mesmo por branch. No entanto, há limites para o número de Codespaces que você pode criar e executar ao mesmo tempo. Se você atingir o número máximo de Codespaces e tentar criar outro, será exibida uma mensagem informando que um Codespace existente precisa ser removido/excluído antes que um novo Codespace possa ser criado.
Você pode criar um novo Codespace sempre que desenvolver em GitHub Codespaces ou manter um Codespace de longa duração para um recurso. Se estiver iniciando um novo projeto, crie um Codespace a partir de um modelo e publique-o posteriormente em um repositório no GitHub.
Ao criar um novo Codespace sempre que trabalhar em um projeto, você deve enviar regularmente suas alterações para garantir que quaisquer novos commits estejam no GitHub. Ao usar um Codespace de longa execução para um novo projeto, extraia da ramificação padrão do repositório sempre que começar a trabalhar no Codespace. Isso permite que o ambiente obtenha os commits mais recentes. O fluxo de trabalho é semelhante a trabalhar com um projeto em uma máquina local.
Os administradores de repositório podem habilitar pré-compilações do GitHub Codespaces para um repositório para acelerar a criação do Codespace.
Para obter instruções detalhadas e orientações passo a passo, consulte os recursos intitulados Um guia para iniciantes para aprender a codificar com GitHub Codespaces e Desenvolvendo em um Codespace localizados na unidade Resumo no final deste módulo.
When creating a GitHub Codespace, four processes occur:
- VM and storage are assigned to your Codespace.
- A container is created.
- A connection to the Codespace is made.
- A post-creation setup is made.
Quando você se conecta a um Codespace pela web, o AutoSave é ativado automaticamente para salvar as alterações após um período de tempo específico. Ao se conectar a um Codespace por meio do Visual Studio Code em execução em sua área de trabalho, você deve habilitar o AutoSave.
Seu trabalho é salvo em uma máquina virtual na nuvem. Você pode fechar e parar um Codespace e retornar ao trabalho salvo posteriormente. Se você tiver alterações não salvas, receberá uma solicitação para salvá-las antes de sair. No entanto, se o seu Codespace for excluído, seu trabalho será perdido. Para salvar seu trabalho, você deve confirmar suas alterações e enviá-las para seu repositório remoto ou publicar seu trabalho em um novo se você criou seu Codespace a partir de um modelo. Abra um Codespace existente
Você pode reabrir qualquer um dos seus Codespaces ativos ou interrompidos em GitHub.com, em um IDE JetBrains, no Visual Studio Code ou usando GitHub CLI.
Para retomar um Codespace existente, você pode ir ao repositório onde o Codespace existe e pressionar a tecla "," no teclado e selecionar Retomar este codespace ou abrir https://github.com/codespaces no navegador, selecionar o repositório e em seguida, selecione o Codespace existente.
Se um Codespace estiver inativo ou se você sair do Codespace sem parar explicitamente, o aplicativo expirará após um período de inatividade e interromperá a execução. O tempo limite padrão é após 30 minutos de inatividade. Não é possível personalizar a duração do período de tempo limite para novos Codespaces. Quando um Codespace expira, seus dados são mantidos desde a última vez que suas alterações foram salvas.
Um Codespace requer uma conexão com a Internet. Se a conexão com a Internet for perdida enquanto você trabalha em um Codespace, você não conseguirá acessar seu Codespace. No entanto, quaisquer alterações não confirmadas serão salvas. Ao restabelecer a conexão com a Internet, você poderá acessar o Codespace no mesmo estado em que estava quando a conexão foi perdida.
Se você tiver uma conexão de Internet instável, você deve confirmar e enviar suas alterações com frequência.
Se você sair do Codespace sem executar o comando stop (por exemplo, fechando a guia do navegador) ou deixar o Codespace em execução sem interação, o Codespace e seus processos em execução continuarão durante o período de tempo limite de inatividade. O período de tempo limite de inatividade padrão é de 30 minutos. Você pode definir sua configuração de tempo limite pessoal para Codespaces criados, mas isso pode ser anulado pela política de tempo limite de uma organização.
Apenas a execução de Codespaces incorre em cobranças de CPU. Um Codespace parado incorre apenas em custos de armazenamento.
Você pode parar e reiniciar um Codespace para aplicar alterações. Por exemplo, se você alterar o tipo de máquina usado para seu Codespace, será necessário interrompê-lo e reiniciá-lo para que a alteração entre em vigor. Quando você fecha ou interrompe seu Codespace, todas as alterações não confirmadas são preservadas até que você se conecte ao Codespace novamente.
Você também pode interromper o Codespace e optar por reiniciá-lo ou excluí-lo se encontrar um erro ou algo inesperado.
Você pode reconstruir seu Codespace para implementar alterações na configuração do contêiner de desenvolvimento. Para a maioria dos usos, é possível criar um novo Codespace como alternativa à reconstrução de um Codespace. Ao reconstruir seu Codespace, as imagens do cache aceleram o processo de reconstrução. Você também pode executar uma reconstrução completa para limpar o cache e reconstruir o contêiner com imagens novas.
Ao reconstruir o contêiner em um Codespace, as alterações feitas fora do diretório /workspaces são limpas. As alterações feitas dentro do diretório /workspaces, incluindo o clone do repositório ou modelo a partir do qual você criou o Codespace, são preservadas durante uma reconstrução.
Você pode criar um Codespace para uma tarefa específica. Depois de enviar suas alterações para uma ramificação remota, você poderá excluir esse Codespace com segurança.
Se você tentar excluir um Codespace com commits git não enviados, o editor notificará que há alterações que não foram enviadas para uma ramificação remota. Você pode enviar quaisquer alterações desejadas e excluir seu Codespace. Você também pode continuar excluindo seu Codespace e quaisquer alterações não confirmadas ou exportar o código para uma nova ramificação sem criar um novo Codespace.
Codespaces interrompidos que permanecem inativos por um período de tempo especificado são excluídos automaticamente. Codespaces inativos são excluídos após 30 dias, mas você pode personalizar os intervalos de retenção do Codespace.
GitHub Codespaces é um ambiente dedicado para você. Você pode configurar seus repositórios com um contêiner de desenvolvimento para definir seu ambiente GitHub Codespaces.
Há muitas maneiras de personalizar seu Codespace. Vamos entender cada um deles:
- Sincronização de configurações: você pode sincronizar as configurações do Visual Studio Code (VS Code) entre o aplicativo de desktop e o cliente web do VS Code.
- Dotfiles: você pode usar um repositório
- para especificar scripts, preferências de shell e outras configurações.
- Renomear um Codespace: quando você cria um Codespace, ele recebe um nome de exibição gerado automaticamente. Se você tiver vários Codespaces, o nome de exibição ajudará a diferenciar entre Codespaces.
- Alterar seu shell: você pode alterar seu shell em um Codespace para manter a configuração com a qual está acostumado. Ao trabalhar em um Codespace, você pode abrir uma nova janela de terminal com um shell de sua escolha, alterar seu shell padrão para novas janelas de terminal ou instalar um novo shell. Você também pode usar dotfiles para configurar seu shell.
- Alterar o tipo de máquina: você pode alterar o tipo de máquina que está executando seu Codespace, para usar recursos apropriados para o trabalho que está realizando.
- Definir o editor padrão: você pode definir seu editor padrão para Codespaces em sua página de configurações pessoais. Defina sua preferência de editor para que, quando você criar um Codespace ou abrir um Codespace existente, ele seja aberto em seu editor padrão.
- Código do Visual Studio (aplicativo de desktop)
- Código do Visual Studio (aplicativo cliente da web)
- JetBrains Gateway - para abrir Codespaces em um JetBrains IDE
- JupyterLab - a interface web do Projeto Jupyter Definir a região padrão: você pode definir sua região padrão na página de configurações de perfil do GitHub Codespaces para personalizar onde seus dados são mantidos.
- Defina o tempo limite: um Codespace irá parar de funcionar após um período de inatividade. Por padrão, esse período é de 30 minutos, mas você pode especificar um período de tempo limite padrão maior ou menor em suas configurações pessoais no GitHub. A configuração atualizada se aplica a quaisquer novos Codespaces que você criar ou a Codespaces existentes na próxima vez que você iniciá-los.
- Configurar exclusão automática: Codespaces inativos são excluídos automaticamente. Você pode escolher por quanto tempo seus Codespaces interrompidos serão retidos, até um máximo de 30 dias.
Você pode adicionar plug-ins e extensões em um Codespace para personalizar sua experiência no JetBrains e no VS Code.
Se você trabalhar em seus Codespaces no aplicativo de desktop VS Code ou no cliente Web, poderá adicionar quaisquer extensões necessárias do Visual Studio Code Marketplace. Consulte Suporte ao Desenvolvimento Remoto e Codespaces GitHub na documentação do VS Code para obter informações sobre como as extensões são executadas em Codespaces GitHub.
Se você já usa o VS Code, pode usar o Settings Sync para sincronizar automaticamente extensões, configurações, temas e atalhos de teclado entre sua instância local e quaisquer Codespaces que você criar.
Se você trabalha em seus Codespaces em um IDE JetBrains, poderá adicionar plug-ins do JetBrains Marketplace.
Você provavelmente está se perguntando: quando devo usar GitHub Codespaces e quando devo usar GitHub.dev?
Você pode usar GitHub.dev para navegar em 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 pull request no editor GitHub.dev.
Se você quiser fazer um trabalho mais pesado, como testar seu código, use GitHub Codespaces. Ele possui computação associada para que você possa construir seu código, executá-lo e ter acesso ao terminal. GitHub.dev não contém computação. Com GitHub Codespaces, você obtém o poder de uma máquina virtual (VM) pessoal com acesso ao terminal, da mesma forma que usaria seu ambiente local, apenas na nuvem. Comparação de Codespaces e GitHub.dev
A tabela a seguir lista as principais diferenças entre Codespaces e GitHub.dev:
| GitHub.dev | GitHub Codespaces | |
|---|---|---|
| Custos | Free | Cota mensal gratuita de uso para contas pessoais |
| Disponibilidade | Disponível para todos em GitHub.com | Disponível para todos em GitHub.com |
| Comece | 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 | Quando você cria ou retoma um Codespace, uma VM é atribuída ao Codespace e o contêiner é configurado com base no conteúdo de um arquivo devcontainer.json. Esta configuração leva alguns minutos para criar o ambiente de desenvolvimento. |
| Computação | Não há computação associada, portanto você não pode criar e executar seu código ou usar o terminal integrado. | Com GitHub Codespaces, você obtém o poder de uma VM dedicada para executar e depurar seu aplicativo. |
| Acesso ao terminal | Nenhum | GitHub Codespaces fornece um conjunto comum de ferramentas por padrão, o que significa que você pode usar o Terminal exatamente como faria em seu ambiente local. |
| Extensões | Apenas um subconjunto de extensões que podem ser executadas na Web aparece na visualização de extensões e pode ser instalado | Com GitHub Codespaces, você pode usar a maioria das extensões do Visual Studio Code Marketplace. |
Você pode iniciar seu fluxo de trabalho em GitHub.dev e continuar trabalhando em um Codespace. Se você tentar acessar a visualização Run, Debug ou o Terminal, você será notificado de que eles não estão disponíveis em GitHub.dev.
Para continuar seu trabalho em um Codespace, selecione Continuar trabalhando em…. Selecione Criar novo codespace para criar um codespace em sua ramificação atual. Antes de escolher esta opção, você deve confirmar quaisquer alterações.
Vamos entender o que é o Inner Souce, seus benefícios, visibilidade e permissões no github, além de algumas dicas do github.
O Inner Source é uma abordagem de desenvolvimento de software que utiliza práticas de código aberto dentro de uma organização. Em vez de desenvolver projetos isoladamente, as equipes colaboram de forma transparente e compartilham recursos, promovendo a colaboração interna.
- Colaboração Eficiente: Fomenta a colaboração entre equipes, promovendo a troca de conhecimento e experiências.
- Reutilização de Código: Facilita a reutilização de código, evitando a duplicação de esforços e promovendo a eficiência.
- Inovação: Estimula a inovação ao permitir que diferentes equipes contribuam para a melhoria contínua dos projetos.
- Transparência: Torna o desenvolvimento mais transparente, possibilitando que todos na organização tenham visibilidade sobre o progresso e as decisões.
Existem diferentes níveis de visibilidade e permissões no GitHub, que são fundamentais para o controle de acesso aos repositórios. Alguns exemplos incluem:
- Repositórios Públicos: Acesso aberto a todos.
- Repositórios Privados: Acesso restrito a colaboradores específicos.
- Permissões de Colaboradores: Controle granular sobre as ações que os colaboradores podem realizar.
Links: https://github.com/mntnr/awesome-contributing
Vamos compreender o que é o InnerSouce e suas boas práticas.
O desenvolvimento de software tradicionalmente se dividia entre dois modelos: código aberto e proprietário. O código aberto permite contribuições abertas, enquanto o software proprietário mantém-se fechado para proteger a propriedade intelectual.
Se você lidera uma empresa que investiu em software proprietário, pode querer combinar as vantagens do código aberto sem abrir completamente seu software. É aí que entra o InnerSource.
O software de código aberto pode ser livremente usado, modificado e compartilhado por qualquer pessoa. Usando software de código aberto, qualquer pessoa pode visualizar, modificar e distribuir um projeto para qualquer finalidade, com a ideia de que compartilhar código leva a software melhor e mais confiável.
InnerSource é a prática de aplicar padrões de código aberto a projetos com um público limitado. Por exemplo, uma empresa pode estabelecer um programa InnerSource que espelha a estrutura de um projeto de código aberto típico, exceto que ele só é acessível aos funcionários dessa empresa. Na prática, é um programa de código aberto atrás do firewall da sua empresa.
Um programa InnerSource pode oferecer inúmeros benefícios além dos modelos tradicionais de código fechado.
Primeiramente, eles incentivam a transparência. O acesso ao código-fonte de outros projetos da empresa pode ajudar os desenvolvedores a serem mais produtivos ao trabalharem em seus próprios projetos. Eles podem ver como diferentes equipes resolveram problemas semelhantes aos que estão enfrentando e muitas vezes encontrar código e outros recursos que podem reutilizar. O acesso a problemas da equipe, solicitações de pull e planos do projeto também fornece melhores dados para entender a velocidade e direção do projeto.
Em seguida, eles reduzem o atrito. Se uma equipe consumidora depende de uma correção de bug ou novo recurso para um projeto de propriedade de outra equipe, eles têm um canal por meio do qual podem propor as mudanças necessárias. E se essas mudanças não puderem ser mescladas por qualquer motivo, a equipe consumidora tem a opção de bifurcar o projeto para atender às suas necessidades.
Finalmente, eles padronizam práticas. Um desafio comum que as organizações de desenvolvimento enfrentam é que diferentes equipes frequentemente divergem nas formas como operam. Criar um programa InnerSource é uma ótima oportunidade para adotar convenções padrão que podem ser usadas em todas as equipes de desenvolvimento, mesmo que não sigam práticas idênticas. Por exemplo, duas equipes podem preferir processos diferentes para aceitar contribuições. Padronizá-las na forma como comunicam esses processos diferentes torna muito mais fácil para qualquer pessoa contribuir para ambas.
Você pode configurar repositórios do GitHub com três níveis de visibilidade. Usuários que não atendem ao requisito de visibilidade veem páginas "não encontradas" ao tentar acessar seu repositório. Os níveis são:
- Repositórios públicos são visíveis para todos. Use esta visibilidade para projetos que são realmente de código aberto e oferecem acesso a pessoas dentro e fora de sua organização.
- Repositórios internos são visíveis apenas para membros da organização que os possui. Use esta visibilidade para projetos InnerSource.
- Repositórios privados são visíveis apenas para o proprietário e quaisquer equipes ou indivíduos que eles adicionarem. Use esta visibilidade para projetos aos quais apenas usuários e grupos específicos devem ter acesso.
Depois de estabelecer a visibilidade do repositório, você pode configurar permissões individualmente ou por equipe. Existem cinco níveis de permissão:
- Nível de leitura é recomendado para contribuidores não programadores que desejam visualizar ou discutir o projeto.
- Nível de triagem é recomendado para contribuidores que precisam gerenciar proativamente problemas e solicitações de pull sem acesso de gravação.
- Nível de gravação é recomendado para contribuidores que empurram ativamente para o projeto.
- Nível de manutenção é recomendado para gerentes de projeto que precisam gerenciar o repositório sem acesso a ações sensíveis ou destrutivas.
- Nível de administrador é recomendado para pessoas que precisam de acesso total ao projeto, incluindo ações sensíveis e destrutivas, como gerenciar segurança ou excluir um repositório.
À medida que um programa InnerSource cresce, o número de repositórios provavelmente aumenta significativamente. Embora seja ótimo ter todos esses ativos disponíveis para a organização, pode se tornar um desafio encontrar e trabalhar eficientemente com o conteúdo. Para abordar proativamente esse problema, é uma prática recomendada para as equipes considerar o que podem fazer para facilitar a descoberta e o trabalho com seus repositórios por parte de outras pessoas.
Algumas melhores práticas incluem:
- Usar um nome descritivo para o repositório, como warehouse-api ou supply-chain-web.
- Incluir uma descrição concisa. Uma ou duas frases devem ser suficientes para que os usuários em potencial saibam se o projeto pode atender às suas necessidades.
- Licenciar seu repositório para que os usuários saibam como podem usar, modificar e distribuir o software.
- Incluir um arquivo README.md no repositório. O GitHub usa este arquivo como a página inicial quando as pessoas visitam o repositório.
Um arquivo README comunica as expectativas para o seu projeto e ajuda a gerenciar contribuições. Os arquivos README podem:
- Articular o propósito e a visão do projeto para que os consumidores em potencial entendam se atende às suas necessidades.
- Oferecer auxílios visuais, como capturas de tela ou trechos de código, para ilustrar o projeto em ação.
- Incluir links para uma versão de produção ou demo do aplicativo para revisão.
- Definir expectativas para pré-requisitos e procedimentos de implantação.
- Incluir referências aos projetos dos quais você depende. Essas referências são uma boa maneira de promover o trabalho de outros.
- Usar Markdown para orientar os leitores por meio de conteúdo formatado corretamente.
Se você colocar seu arquivo README no diretório oculto .github, docs ou no diretório raiz, o GitHub reconhece e exibe automaticamente seu README para visitantes do repositório. Se um repositório contiver mais de um arquivo README, o arquivo mostrado é escolhido em locais na seguinte ordem: o diretório .github, depois o diretório raiz do repositório e, finalmente, o diretório docs.
Depois que o projeto for lançado, use o e-mail e outros canais de networking para promovê-lo. Alcançar um público apropriado pode resultar em um impulso significativo na participação no projeto. Gerenciar projetos no GitHub
À medida que os projetos ganham tração, o influxo de usuários e contribuições pode exigir muito trabalho para gerenciar. Dependendo do projeto, pode ser necessário um esforço significativo apenas para gerenciar as expectativas dos participantes do projeto.
Para abordar proativamente esse problema, o GitHub procura um arquivo CONTRIBUTING.md na raiz (ou /docs ou /.github) de um repositório. Use este arquivo para explicar a política de contribuição para o projeto. Os detalhes exatos podem variar, mas é uma boa ideia informar aos potenciais contribuidores quais convenções o projeto segue, onde a equipe procura solicitações de pull, quais detalhes são solicitados para relatórios de bugs, etc.
Se um CONTRIBUTING.md existir, o GitHub apresenta um link para ele quando os usuários criam problemas ou solicitações de pull para incentivá-los a segui-lo.
Além disso, considere adicionar um arquivo CODEOWNERS ao repositório para definir indivíduos ou equipes responsáveis por revisar modificações de código. Criar modelos de problemas e solicitações de pull
O GitHub oferece modelos iniciais para novos problemas e solicitações de pull. Use-os para fornecer o texto de descrição inicial para um problema ou solicitação de pull recém-criado.
Por exemplo, se seu projeto tiver .github/ISSUE_TEMPLATE.md, sempre que um usuário iniciar o processo de criação de um problema, eles verão esse conteúdo. Em vez de ter que se referir constantemente aos detalhes necessários de um CONTRIBUTING.md, eles podem preencher o problema como um formulário usando o texto do modelo.
É o mesmo para solicitações de pull, exceto que o caminho é .github/PULL_REQUEST_TEMPLATE.md.
Confira alguns exemplos incríveis de modelos de problemas e solicitações de pull do GitHub.
Para projetos que incentivam contribuições externas, certifique-se de especificar qual fluxo de trabalho o projeto segue. O fluxo de trabalho deve incluir detalhes sobre onde e como os ramos devem ser usados para bugs e recursos, como as solicitações de pull devem ser abertas e quaisquer outros detalhes que as pessoas fora da equipe do repositório devem saber antes de enviar código. Se você ainda não tem um fluxo de trabalho em mente, deve considerar o fluxo de trabalho do GitHub.
Você deve comunicar uma estratégia para gerenciar lançamentos e implantações. Essas partes do fluxo de trabalho afetam o branching e merging diários, então é importante comunicá-las aos contribuidores. Saiba mais sobre como elas se relacionam com sua estratégia de branching do Git. Medir o sucesso do programa
Qualquer equipe que se aventura no InnerSource deve pensar nos tipos de métricas que deseja rastrear para avaliar o sucesso de seu programa. Embora métricas tradicionais como "tempo de lançamento no mercado" e "bugs relatados" ainda sejam aplicáveis, elas não necessariamente ilustram os benefícios obtidos por meio do InnerSource.
Em vez disso, considere adicionar métricas que mostrem como a participação externa melhorou a qualidade do projeto. O repositório está recebendo solicitações de pull de fontes externas que corrigem bugs e adicionam recursos? Existem participantes ativos nas discussões sobre o projeto e seu futuro? O programa está inspirando uma expansão do InnerSource que gera benefícios em outras partes da organização?
Em resumo, métricas são difíceis, especialmente quando se trata de medir o valor e o efeito das contribuições individuais e de equipe. Se mal utilizadas, as métricas podem prejudicar a cultura, os processos existentes e diminuir o sentimento coletivo em relação à organização ou à equipe de liderança. Ao pensar em medir a adoção do InnerSource, considere o seguinte:
- Meça o processo, não o resultado
- Tempo de revisão de código
- Tamanho da solicitação de pull
- Trabalho em andamento
- Tempo para abrir
- Meça em relação a metas e não absolutos
- Meça equipes e não indivíduos
- Número de contribuidores únicos para um projeto
- Número de projetos reutilizando código
- Número de menções cruzadas entre equipes