Atividade Análise Github

UNIVERSIDADE FEDERAL DE JUIZ DE FORA Curso de Especialização em Gerência de Projetos de Software na Era de Dados de Sensores e IA Código Gerência de Configuração de Software 2025 3º Prof Gleiph Ghiotto Lima de Menezes Enunciado do Trabalho Prático Trabalho Análise do Controle de Versão e Releases em Projetos de Código Aberto Descrição Este trabalho visa analisar as práticas de Desenvolvimento Paralelo e Gestão de Entregas de um projeto real aplicando os conceitos de ramos merges e baselines estudados no curso O objetivo geral consiste em demonstrar a compreensão dos conceitos fundamentais de Gerência de Configuração de Software GCS focados no fluxo de trabalho de desenvolvimento versionamento e entregas de produtos de software Os objetivos específicos são descritos a seguir Identificar a Estratégia de Ramificação do dos merges e justificar seu uso para isolar o desenvolvimento e novas funcionalidades Analisar o processo de merge como o mecanismo de controle para integrar o trabalho isolado a outras linhas de desenvolvimento Relacionar a utilização de tags no repositório com o gerenciamento de releases identificando as baselines de produto do projeto Descrever a diferença prática entre os ramos identificados em merges no projeto O grupo escolherá um projeto de código aberto no GitHub GitLab ou similar versionado com o Git A tarefa é inspecionar o histórico do repositório focando em Ramosmerges como o trabalho é isolado e integrado Tagsreleases Como as versões finais são marcadas e liberadas O resultado deve ser um relatório que apresente exemplos concretos com hashes nomes de ramos tags e a url do projeto A seguir são definidas as atividades de forma mais detalhada 1 Escolha do Projeto Selecione um projeto de código aberto disponibilizados em plataformas como o GitHub utilizem o Git para versionamento e que possua um histórico ativo de ramos merges e tags 2 Roteiro de Análise Focada O Relatório deve ser estruturado em torno dos seguintes pontos Use capturas de tela e exemplos de código para ilustrar sua análise A Análise da estratégia de ramificação o Ramo Principal Qual é o nome do ramo principal ex main master Este ramo representa os artefatos sempre pronto para produção ou apenas os artefatos em desenvolvimento ativo o Fluxo de trabalho de ramos Identifique no projeto um exemplo de um ramo de funcionalidade e um ramo de correção ativo ou recémfinalizado Descreva como o trabalho nesses ramos foi isolado o Controle de Integração 5 Merges Análise quem fez o merge O que foi exigido antes do merge ser aprovado ex revisão de código testes automatizados Tente inferir pelo histórico de mensagens B Análise do gerenciamento de releases e tags o Identificação da baseline de produto Liste as últimas 5 cinco tags criadas no repositório ex v210 v201 Descreva o padrão de nomeação dessas tags o Relacionamento tag release Compare o conteúdo do commit associado às últimas 5 tags mais recente com o conteúdo do ramo principal na mesma época Em sua opinião as tags marcam pontos no tempo que servem como baselines que só pode ser alterada por um novo processo de Controle de Mudanças Justifique com o que você observou no projeto O que deverá ser entregue um arquivo em formato pdf com o relatório de pesquisa com os repositórios contendo no máximo 5 páginas que deverá conter a especificação dos objetivos da pesquisa métodos adotados para a análise e a justificativa do por que selecionou o repositório apresentação e análise dos dados coletados considerando a análise da estratégia de ramificação e a análise do gerenciamento de releases e tags Ao final deste documento no Apêndice A há um modelo de relatório que apresenta as seções sugeridas Observação entregar o arquivo com a seguinte nomenclatura CódigodaDisciplinaTX ouTrabalhoGrupoXXNomeSobrenome de um membro do grupo Análise do Controle de Versão e Releases no Projeto PyTorch Repositório analisado httpsgithubcompytorchpytorch Introdução Este trabalho tem como objetivo mostrar de forma prática como funcionam os conceitos de Gerência de Configuração de Software GCS dentro de um projeto real Para isso escolhi analisar o repositório do PyTorch que é um dos frameworks de machine learning mais usados atualmente Objetivos da Pesquisa O foco geral é demonstrar a compreensão dos principais mecanismos de GCS aplicados a um caso real Dentro disso os objetivos específicos são Entender e descrever a estratégia de ramificação adotada no projeto Mostrar como o processo de merge funciona e como ele atua como mecanismo de integração Relacionar tags com o gerenciamento de releases e baselines Destacar diferenças práticas entre os ramos encontrados Métodos Utilizados Para realizar essa análise explorei as principais áreas do repositório Branches Releases Tags Pull requests já mergeados Network graph Essa investigação permitiu observar padrões de desenvolvimento fluxo de versionamento e comportamento das entregas Por que escolher o PyTorch Escolhi o PyTorch porque ele reúne características perfeitas para um estudo de GCS projeto extremamente ativo e vivo grande volume de contribuidores alta complexidade releases frequentes e bem estruturadas Em dezembro de 2025 o repositório segue com commits diários então ele é excelente para observar desenvolvimento paralelo real A Análise da Estratégia de Ramificação Ramo Principal O repositório utiliza o ramo main como branch padrão Ele é o centro do desenvolvimento recebe commits constantes e é mantido sempre em um estado integrável Diferente de um Git Flow tradicional o PyTorch opera num estilo mais próximo de trunk based development O main está sempre saudável Testes automatizados rodam o tempo todo Releases estáveis são geradas a partir de pontos específicos do main mas o branch segue avançando logo depois Fluxo de Trabalho dos Ramos O PyTorch usa um fluxo baseado em PRs muito semelhante ao GitHub Flow mas mais estruturado O desenvolvimento acontece quase sempre em branches temporários normalmente criados em forks dos contribuidores Cada PR corresponde em geral a um branch de curta duração Exemplos de branches comuns novos recursos ex melhorias de performance suporte a novas arquiteturas correções rápidas de bugs ajustes específicos como documentação ou refactors pequenos Essa estratégia permite que tudo fique isolado do main até que o código esteja aprovado e testado Controle de Integração Exemplos de 5 Merges Os merges são sempre feitos via Pull Requests e eles seguem um processo bem rígido Quem aprovamergeia Normalmente membros core da MetaFAIR ou bots autorizados como pytorchbot Antes de aprovar é obrigatório pelo menos 2 a 3 revisões positivas todos os testes passarem validação automática lint compatibilidade build CI no hudpytorchorg e GitHub Actions Exemplos de merges recentes novdez 2025 1 PR de melhoria de performance integrado após todo o CI passar 2 Pull request corrigindo regressão detectada em GPU kernels 3 Hotfix rápido para problema de compatibilidade com CUDA 4 Ajuste em documentação com revisão simples mas exigindo CI 5 Pequena feature no módulo inductor revisada e mergeada após aprovação dupla Todas essas integrações seguem o padrão branch PR reviews CI merge B Gerenciamento de Releases e Tags Últimas Baselines Tags Recentes As últimas 5 tags encontradas no repositório foram v291 12112025 v290 15102025 v280 06082025 v271 04062025 v270 23042025 O padrão de versionamento é exatamente o do Semantic Versioning MAJORMINORPATCH Isso deixa explícita a intenção de cada release se é correção nova funcionalidade ou quebra de compatibilidade Como tags e releases se relacionam Cada tag corresponde ao commit exato que representa a versão liberada A partir daquele ponto A tag fica congelada imutável O main continua avançando normalmente Usuários que instalarem aquela versão sempre receberão o mesmo artefato Isso funciona como uma baseline formal porque Não é alterada depois de criada Representa um estado estável e reprodutível do produto Qualquer mudança posterior gera uma nova tag v292 por exemplo Conclusão A análise do PyTorch mostra claramente como práticas modernas de Gerência de Configuração funcionam na vida real O projeto faz uso eficiente de trunkbased development garantindo integração contínua branches curtos de PR que isolam mudanças e evitam conflitos CICD robusto que protege a integridade do main tags e releases bem definidas funcionando como baselines confiáveis