Git explicado para fundadores não técnicos

Git explicado para fundadores não técnicos: é uma máquina do tempo para o teu código: guarda uma fotografia de todo o teu produto sempre que lho pedes e permite-te voltar a qualquer uma dessas fotografias quando algo se parte. Pensa no Controlo de Alterações do Word, ou na Time Machine de um Mac — mas para toda a tua base de código. Se é a IA que escreve o teu código, o git é a rede de segurança que torna reversível cada erro da IA.

Não precisas de dominar o git. Precisas de perceber seis palavras e adotar um hábito. Aqui tens as duas coisas.

Git explicado para fundadores não técnicos: porque existe

Imagina construir uma funcionalidade sem git. O teu código funciona na perfeição. Fazes umas alterações. Parte-se tudo. Não te lembras exatamente do que mudaste. Não consegues voltar atrás. Instala-se o pânico.

Agora a mesma tarde com git. O código funciona na perfeição — guardas uma fotografia. Fazes alterações — parte-se tudo — voltas à fotografia. Estado funcional reposto, nada perdido, e tentas outra vez com outra abordagem. O medo de partir coisas desaparece e, com ele, a maior razão pela qual os fundadores não técnicos ficam paralisados diante do próprio produto. Podes dar-te ao luxo de ser ousado precisamente porque nada está alguma vez a mais do que um recuo de distância da segurança.

As seis palavras do git, traduzidas

Repositório: a pasta que o git vigia. Contém os teus ficheiros de código, o histórico completo de cada alteração e o registo de quem mudou o quê.

Commit: uma fotografia do teu código num determinado momento, com uma mensagem curta a descrever o que mudou — "Adicionar início de sessão". Como gravar o jogo: podes sempre carregar esta gravação mais tarde.

Branch: uma versão paralela do teu código. Pensa num multiverso — cada branch é a sua própria linha temporal. O branch main é a produção, o que os teus utilizadores veem. Um branch de funcionalidade é a linha temporal experimental onde acontece o trabalho novo. Se a funcionalidade funcionar, fazes merge para o main. Se falhar, apagas o branch — sem estragos, o main nunca soube de nada.

Remote: o teu histórico git vive no teu computador; um remote é a cópia guardada online, normalmente no GitHub. É a tua cópia de segurança fora de casa — o portátil morre, o produto sobrevive — e é de lá que o teu alojamento vai buscar o código para o publicar (essa passagem é o que o deployment realmente é).

Merge e conflito: fazer merge junta dois branches — três dias de trabalho num branch de funcionalidade integrados de volta no main. Um conflito é o caso raro em que o git não consegue fazê-lo sozinho: mudaste a linha 50 no teu branch, outra coisa mudou a linha 50 no main, e o git não sabe que versão manter. Marca o sítio no ficheiro e um humano decide.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Porque é que o git importa dez vezes mais quando é a IA que escreve o teu código

Para um programador tradicional, o git é uma boa prática. Para um fundador que constrói com IA, é todo o modelo de segurança — de quatro formas:

• Fotografia antes de a IA tocar em alguma coisa. Faz commit do estado funcional primeiro. Se a IA partir alguma coisa, um comando leva-te de volta a antes de ela começar. Sem arqueologia, sem pânico.
• Deixa a IA experimentar em branches. As alterações arriscadas acontecem numa linha temporal separada. Testa o resultado como deve ser; faz merge apenas do que o merece.
• O histórico mostra exatamente o que a IA mudou. O git consegue mostrar cada linha que a IA acrescentou, removeu ou editou. Revês as alterações reais — não o resumo animado que a IA faz delas.
• Qualquer erro da IA pode ser desfeito. Uma alteração má que tenha passado pode ser revertida de forma limpa, de volta ao estado funcional anterior.

O hábito que faz as quatro funcionarem: faz commit antes de cada interação com a IA. Estado funcional, fotografia, e só depois soltas a IA. Isso transforma "a IA acabou de me destruir a tarde" em "recua, reformula, tenta outra vez" — a diferença entre jogar a sorte e experimentar.

O que precisas mesmo de saber fazer

Eis o alívio: não corres o git à mão. Os assistentes de IA executam as operações de git — criar branches, fazer commits, mostrar o que mudou — a partir de pedidos em linguagem corrente. O teu trabalho é compreender e aprovar: perceber o que é um commit quando a IA diz "vou fazer commit disto primeiro", reconhecer "estás num branch de funcionalidade" como uma boa notícia e não como um aviso, e saber que momentos merecem toda a tua atenção. Seis palavras de vocabulário dão-te essa compreensão; o resto é hábito.

Um desses momentos está acima de todos os outros: publicar. Deixar uma IA fazer push de código para o GitHub sem a tua revisão é como erros privados se tornam públicos — aprendi isso com uma chave exposta e quatro horas de limpeza, e é por isso que as regras do push têm um artigo só para elas: nunca deixes a IA fazer push para o GitHub.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

Preciso de decorar comandos do git?

Não. Precisas dos conceitos — fotografia, linha temporal, cópia de segurança — suficientemente bem para acompanhares o que está a acontecer e aprovares as coisas certas. O teu assistente de IA corre os comandos a partir de linguagem corrente: "guarda uma fotografia antes de começarmos", "cria um branch para esta experiência", "mostra-me o que mudou".

Qual é a diferença entre Git e GitHub?

O Git é a própria máquina do tempo — software que corre no teu computador e regista fotografias do teu projeto. O GitHub é a casa online dessas fotografias: cópia de segurança, colaboração e o sítio a partir do qual o teu alojamento faz o deployment. O Git funciona sem o GitHub; o GitHub é para onde o teu histórico vai para estar seguro e ser partilhado.

Com que frequência devo fazer commit?

Sempre que o produto chega a um estado funcional, e sempre antes de deixares a IA fazer alterações. Os commits são gratuitos e recuar só é tão preciso quanto a tua última fotografia. Os fundadores que se queimam são os que deixam acumular horas de trabalho sem commit antes de uma sessão com IA.

O git consegue recuperar tudo?

Tudo o que tenha tido commit, sim — é esse o objetivo da máquina do tempo. O que o git não consegue recuperar é trabalho de que nunca fizeste commit; as alterações sem commit são as únicas que podem desaparecer de vez. O que transforma toda a disciplina numa frase: faz commit cedo, faz commit muitas vezes, faz commit antes da IA.