Uma Introdução ao Git para Hardware com Altium Designer

Introdução

Há alguns anos, fiz uma transição temporária de trabalhar em um ambiente de startup hip e supercafeinado para um emprego de engenharia em uma empresa mais madura e experiente. Foi então que percebi a conexão binomial entre cultura técnica e ferramentas. Como pensamos e como trabalhamos é moldado pelas ferramentas disponíveis para nós, já que nossas necessidades e costumes influenciam as ferramentas que escolhemos.

A nova empresa onde trabalhei não estava acostumada com impressoras 3D, software de rastreamento de bugs interno ou mesmo um bom CMS. Era tudo bastante antiquado. Isso teve uma influência significativa no que eu e meus colegas criávamos diariamente.

Um exemplo incluiria as últimas duas décadas, onde a indústria fez a transição de pacotes TO220 para D2PAK. Ao mesmo tempo, os engenheiros equiparam-se com ferros de soldar de alta potência de pico, como os fabricados pela JBC.

Um jovem engenheiro acessando um laboratório bem equipado sequer consideraria algum CI popular em um TO220 nesta década? Eu não acho. É muito mais fácil trabalhar com D2PAKs e não se atrapalhar com parafusos, arruelas e folhas isolantes, desde que você tenha um ferro de soldar de última geração. Essa simples mudança pode direcionar um engenheiro a projetar placas mais planas, o que muitas vezes pode levar a produtos mais esteticamente agradáveis pelos padrões modernos.

Git é um exemplo raro de uma ferramenta que virou uma indústria inteira de cabeça para baixo. Dez anos atrás, gerentes de engenharia de software seriam considerados loucos ao adotar uma abordagem de mover rápido e quebrar coisas. Git para hardware e design de PCB tornou isso possível, habilitando o rastreamento de revisões, controle de versão e a reversão de mudanças de design. Desenvolvedores agora têm a certeza de que seus esforços em projetos de código aberto podem sempre ser atribuídos e verificados, graças a uma funcionalidade chamada Git blame. Uma década atrás, ser reconhecido por sua contribuição a projetos de código aberto era deixado para a política. Estes são todos exemplos de mudanças pelas quais podemos agradecer ao Git.

Embora por sua própria natureza, a indústria eletrônica se mova mais lentamente do que a de software, muitas das inovações estão se infiltrando em nosso trabalho do dia a dia. Altium Designer®, com a introdução do Altium 365® e do Concord Pro™ este ano, liderou o caminho na indústria, com outros players importantes lutando para acompanhar, às vezes com recursos lançados há mais de uma década. Git para hardware e design de PCB é uma das tecnologias que impulsionam essa mudança.

O que é Git?

Muito simplesmente, Git é um sistema de controle de versão (VCS). É um software (incluindo os protocolos subjacentes e formatos de dados) usado por desenvolvedores de software para rastrear e gerenciar mudanças no código. Se você é um desenvolvedor de software trabalhando nesta década, você provavelmente não duplica pastas na sua área de trabalho para experimentar coisas, você provavelmente usa um VCS baseado em Git.

Embora o Git seja massivamente popular para rastrear mudanças de código no desenvolvimento de software, ele pode ser usado para rastrear mudanças em qualquer conjunto de arquivos. Esses arquivos não precisam conter código, podem ser seus arquivos de design de PCB, documentação de design, arquivos de fabricação de PCB e quaisquer outros arquivos que você precisará para o seu projeto. Git para hardware é uma extensão natural do ecossistema Git para design mecânico, design de PCB, firmware e muito mais.

O Git está disponível gratuitamente para uso comercial. É de código aberto e distribuído sob a licença pública geral GNU. Cada diretório Git é uma entidade separada e é, por si só, um repositório contendo um histórico completo de seus itens. Cada arquivo colocado em um repositório Git é totalmente rastreável até cada bit, por quem e quando. Os repositórios Git não requerem acesso à rede, com cada repositório sendo completamente independente dos servidor(es) que assumem o nome de remoto(s).

Portanto, não deve ser surpresa que atualmente é o VCS mais popular do mundo. A maioria das análises de participação no mercado mostra o Git com mais de 75%, e a alternativa mais popular, SVN, está em declínio desde 2012. O número de vagas de emprego que exigem SVN (um VCS legado, também suportado pelo Altium Designer) também está em declínio enquanto o Git tem ganhado popularidade.

História do Git

O Git foi criado e escrito em 2005 por Linus Torvalds, o homem, a lenda, o criador e desenvolvedor do kernel Linux, para acompanhar o próprio desenvolvimento do kernel. A comunidade Linux havia recebido o uso gratuito de um software comercial chamado BitKeeper. Em abril de 2005, o autor do Bitkeeper retirou a licença depois que um membro proeminente da equipe Linux e inventor do servidor de arquivos Samba, Andrew Tridgell, começou a trabalhar em um cliente de código aberto baseado no protocolo BitKeeper (alegadamente) engenharia reversa. A licença do BitKeeper proíbe expressamente a engenharia reversa.

Assim, Linus Torvalds decidiu criar seu próprio sistema de controle de versão, inspirado não tão vagamente pelo BitKeeper, já que nenhuma das alternativas restantes estava sequer perto de atender às suas exigências.

Torvalds decidiu que o novo software seria muito diferente dos populares CVS (Sistemas de Versão Concorrente) em uso na época. Ele percebeu que os sistemas atuais poderiam levar muito tempo para aplicar patches e, como ele precisava aplicar centenas de patches de uma vez ao sincronizar com sua equipe, o desempenho deles estava longe de ser aceitável. Ele elaborou uma série de requisitos:

• Um fluxo de trabalho distribuído semelhante ao que o BitKeeper habilitava. O usuário deve ser capaz de trabalhar offline e sincronizar mais tarde.
• Protegido contra acidentes como corrupção de dados
• Seguro contra ataques maliciosos
• Capaz de calcular patches em menos de dois segundos

O trabalho de escrita do Git começou no início de abril de 2005. Em 16 de junho de 2005, a versão 2.6.12 do kernel Linux, razão pela qual o software foi necessário às pressas, foi lançada. O desenvolvimento e a manutenção do Git foram então entregues a Junio Amano, que contribuiu e ainda contribui para o seu desenvolvimento, sendo amplamente reconhecido por tornar o software fácil de usar; o Git 1.0 foi lançado em dezembro de 2005.

Convenção de Nomes

Por que Git? Um nome estranho, para dizer o mínimo! Como a maioria das pessoas no Reino Unido sabe, o termo é frequentemente dado a alguém que é um pouco atrevido ou, de acordo com o Oxford Online Dictionary, "uma pessoa desagradável ou desprezível". Significados adicionais relatados são "tolo" (gíria do século 18 ao 19 (Reino Unido)) ou "filho bastardo" (gíria de meados do século 18 ao 19 (EUA)), ambos os quais se encaixariam bastante poeticamente em seu mito do gênio solitário escondido para criar uma obra de arte que mudaria o mundo.

Torvalds deu várias razões para nomear seu sistema de "Git", a ser escolhido com base no que o usuário está sentindo no dia, ou provavelmente como ele estava se sentindo em diferentes momentos ao escrever o sistema! Ele frequentemente o descreve como "o rastreador de conteúdo estúpido" na documentação oficial, e a definição de Git como sendo:

• "Uma combinação aleatória de 3 letras que não pode ser pronunciada".
• Uma pronúncia errada de "get"!
• Rastreador de informações global se funcionar conforme o planejado
• Estúpido, desprezível e desagradável quando não funciona.

Ah, o humor dos programadores.

Desvantagens

O Git não é perfeito, no entanto, e tem algumas desvantagens. A estrutura de dados difícil de compreender e a nomenclatura estranha estão, sem dúvida, entre elas. Isso inclui o Git para projetos de hardware, onde a mesma estrutura de arquivo e operações são aplicadas.

Cherry-picking, Checkout, Index, Clone, Push, Stash, Pull/Pull Request, Tag, Upstream, Fork, Rebase, Origin, Fetch e HEAD (sempre escrito em maiúsculas, não faço ideia do porquê) estão entre alguns dos termos mais estranhos que você pode esperar encontrar no mundo do software.

Pode ser difícil entender como configurar um repositório como software do lado do servidor, e entender a relação entre repositórios locais e remotos junto com as operações para mantê-los sincronizados. O Git tende a ser muito mais complexo do que o SVN para aprender e usar, parcialmente devido a ser muito mais poderoso e eficiente.

Felizmente, o Altium Designer e o Concord Pro cuidam da maioria desses problemas. Enquanto temos acesso total ao poder do Git através da linha de comando, a interface do usuário e a integração estrita do Concord Pro tornam sua operação fácil e intuitiva. Ao mesmo tempo, o Altium 365 cuida de todos os problemas do lado do servidor.

Como Funciona o Git para Hardware?

Git pode parecer... muito estranho! A nomenclatura, principalmente, reflete um fluxo de trabalho que difere substancialmente do clássico copiar-colar, compactar e enviar e-mails que muitos engenheiros estão acostumados.

Ramo (e Mesclagem)

O modelo de ramificação é talvez a característica mais popular que separa o Git de outro VCS como o SVN. O Git pode ter múltiplos ramos, tanto locais quanto remotos. Assim como o ramo de uma árvore se bifurca do tronco ou de outros ramos, os ramos do Git brotam de outros ramos. O "tronco" da árvore, ou o ramo principal, é chamado de master. Os ramos podem ser facilmente criados, mesclados e deletados. Veja como essas operações funcionam:

• Cada ramo é independente, e quando trabalhando remotamente, você não precisa pisar nos pés de ninguém. Você pode até ter múltiplos ramos você mesmo, cada ramo contendo uma variação ligeiramente diferente do seu próprio design de software ou hardware, e eles podem ser alternados dentro do mesmo diretório sem ter que fechar e reabrir arquivos manualmente.
• No mundo do software, a regra geral é ter um ramo de produção, chamado de master, e um segundo ramo de trabalho em progresso chamado develop e tantos ramos pequenos quanto necessário para novas funcionalidades e correções. A mesma abordagem pode ser tomada com projetos de hardware. Na verdade, existem muitos repositórios no GitHub com designs de PCB e outros projetos especificamente para hardware.
• Nem todos os ramos precisam ser mesclados ao ramo master. Muitas vezes, os desenvolvedores percebem que a nova funcionalidade não é exatamente uma faísca de gênio, e o ramo pode simplesmente ser deletado quando não for mais necessário.

[Modo nerd ATIVADO]

Então, como essa característica inteligente funciona? Um ramo é essencialmente um ponteiro para um commit. Um commit é um conjunto de mudanças de arquivo, adições ou remoções empurradas para o repositório. O commit tem uma soma de verificação criptográfica SHA-1 de 40 caracteres que é escrita em um arquivo. Cada commit também inclui um ponteiro para o commit pai de onde ele se originou.

Há muitos passos intermediários adicionais, por exemplo, arquivos são convertidos em blobs binários com soma de verificação e organizados em diretórios através de uma árvore binária. A soma de verificação da árvore também é calculada. Como tudo é criptograficamente hash, não há como alterar (ou corromper) os dados ou a história sem mudar o hash do último commit. A hash criptográfica torna a história do Git de certa forma permanente, então seja educado ao escrever mensagens de commit!

[Modo nerd DESATIVADO]

Fluxos de trabalho no Git para Hardware

Graças à natureza distribuída do Git para hardware e ao sistema avançado de ramificação, bem como a uma série de outras características, os usuários são livres para adotar qualquer fluxo de trabalho.

Entre os mais populares, o modelo de *Fluxo de Trabalho Centralizado* é um frequentemente usado quando pessoas que têm experiência com sistema de controle de versão centralizado começam a usar o Git (que é *descentralizado*) pela primeira vez. O *Fluxo de Trabalho Centralizado* depende quase exclusivamente do ramo master, onde todos os commits são empurrados para e buscados de, fazendo o Git imitar o comportamento do SVN e sistemas de arquivos remotos.

O workflow de Feature Branching é uma evolução do *Workflow Centralizado*. O trabalho de desenvolvimento é realizado em branches separadas que são posteriormente mescladas em uma master. Sou um entusiasta deste modelo em engenharia eletrônica e estou ansiosamente esperando que a Altium anuncie seu suporte a branches para tirar vantagem disso. Exemplos de branches de recursos poderiam ser “fix_current_generator_oscillation”, “upgrade_microcontroller”, “lower_power_consumption” ou “reduce_thermal_drift”.

No workflow GitFlow, talvez o mais complexo entre os workflows populares, a branch master contém apenas lançamentos de design completos, você pode pensar nisso como board_v_1.0, board_v_1.1, etc. O desenvolvimento é feito em uma branch separada chamada develop, e recursos e correções derivam da branch develop. Apenas develop pode ser mesclada em master quando estiver pronta.

Descentralização e Velocidade

Git é mais rápido do que outros sistemas de controle de versão por várias razões. Cada usuário pode clonar o repositório original, e commits podem ser feitos regularmente para branches locais e enviados para o remoto com menos frequência. Outros VCSs que não são tão descentralizados são limitados pela capacidade do servidor remoto, que tem que desacelerar consideravelmente para satisfazer todas as suas solicitações.

Esta abordagem local em primeiro lugar é particularmente crucial na indústria eletrônica, pois os arquivos podem ser bastante grandes. Não é incomum que um design de PCB tenha dezenas de megabytes de tamanho, especialmente com centenas de corpos 3D. Arquivos de código-fonte, por outro lado, tendem a ser de algumas centenas de KBytes no máximo.

Na última empresa em que trabalhei, tínhamos um repositório SVN hospedado nos escritórios principais, acessível através de uma VPN, onde armazenaríamos os arquivos do projeto e documentação. Levaria uma eternidade para fazer qualquer operação, e nossa conexão limitada à internet era frequentemente congestionada por todas as solicitações para gerenciar os milhares de arquivos.

Git também é escrito na linguagem C, o que significa que seu overhead é mínimo comparado a outras linguagens de alto nível. Dependendo da operação, Git pode ser de algumas vezes a centenas de vezes mais rápido do que SVN.

A abordagem descentralizada e offline em primeiro lugar também faz com que Git seja muito mais leve na rede. Mesmo que sua empresa não tenha acesso à banda larga, você pode enviar os dados na hora do almoço ou depois do trabalho, sem perda de desempenho no trabalho do dia-a-dia.

No Concord Pro, você pode desfrutar de todos os benefícios do Altium 365 quando você tem acesso a uma conexão de internet, depois roam sua licença Altium Designer e continuar trabalhando offline.

Áreas de Staging

Ao trabalhar com o Git, é essencial perceber que os arquivos passam por três estágios antes de poderem ser realmente considerados sob controle de versão:

1. Não rastreado
2. Preparado
3. Cometido

Não rastreado é quando o arquivo existe no disco, mas está fora do sistema de controle de versão. O arquivo não rastreado pode então ser preparado, o que significa que foi adicionado ao sistema de controle de versão, mas ainda não foi cometido. Neste ponto, as alterações preparadas podem ser cometidas. O sistema de preparação é usado para se preparar para o commit, mas a funcionalidade é usada principalmente em operação de linha de comando.

Ao usar o Git através do Altium, graças à interface gráfica do usuário que simplifica a operação, a abordagem de preparação é aplicada automaticamente em segundo plano quando você salva as alterações no servidor.

Criando um Repositório

Os repositórios são criados automaticamente no lado do servidor quando você cria um novo projeto. Na janela abaixo, estou criando um novo projeto de PCB a partir de um modelo dentro do meu espaço de trabalho da Fermium LTD. Assim que eu criar o projeto, ele estará acessível no meu espaço de trabalho do Altium 365, e a plataforma criará automaticamente um repositório Git para o novo projeto.

Configuração Inicial do Repositório

Os repositórios criados com o Concord Pro são automaticamente configurados, então apenas os arquivos essenciais já estão cometidos no repositório Git do projeto, enquanto backups locais e arquivos LOG não estão. Normalmente seria necessário configurar adequadamente um arquivo chamado ".Gitignore" e cuidar para não cometer arquivos desnecessários, mas o Concord Pro cuida disso.

Configurando Credenciais

Para acessar repositórios Git, geralmente seria necessário configurar chaves SSH e credenciais de usuário tanto do lado do servidor quanto do cliente. O Concord Pro cuida disso automaticamente quando um novo usuário é adicionado.

Clonando Repositórios

Clonar é o processo através do qual o Git replica o repositório remoto em uma cópia local. Clonar manualmente grandes repositórios com arquivos binários, como arquivos PcbDoc e SchDoc, normalmente exigiria uma operação de linha de comando de nível especialista no Git. O Altium Designer e o Concord Pro automaticamente clonam o repositório para sua máquina local em segundo plano quando você abre um projeto remoto.

Resolvendo Conflitos e Comparando Alterações

O Concord Pro permite que você compare alterações entre diferentes revisões, tanto locais quanto remotas, através do painel de gerenciamento de armazenamento. No exemplo a seguir, adicionei um objeto de nota de texto e cometi as alterações localmente, mas não as enviei para o remoto.

Isso nos dá a funcionalidade completa necessária em uma plataforma Git para hardware.

Conclusões

O Git é uma ferramenta formidável, e o git para hardware oferece aos designers de PCB um fluxo de trabalho abrangente para controle de versão, compartilhamento e gerenciamento de revisão. Esse sistema popular ajudou a moldar a cultura dos programadores modernos. Agora, com o Altium Designer® e a plataforma Altium 365®, os designers podem acessar recursos do Git para design de PCB.

Você pode iniciar um teste do Altium 365 hoje, carregado com projetos de exemplo, para vivenciar completamente o desenvolvimento eletrônico no estilo do século 21. Tem mais perguntas? Fale com um especialista da Altium hoje.