🐙 Github

O Git é uma ferramenta incrivelmente poderosa de controle de versões de software utilizada em projetos grandes ou pequenos. Inicialmente pode parecer bastante intimidador aprender todos os comandos do Git, principalmente quando cometemos um erro e somos tomados pelo medo de piorar a situação e perdermos o código escrito.

Novos Projetos

Nomeando um novo projeto

Para nomear um projeto devemos nos atentar em algumas condições

• Nome do cliente do qual o projeto vai ser desenvolvido
• Categoria do projeto
• Identificação do projeto dentro do segmento

Vamos para o exemplo:

1. "Fipo" é o nosso cliente

2. A categoria do projeto será um "gerenciador"

3. Identificação do projeto será "nivy"

Como ficaria o nome do projeto tendo os dados do exemplo acima:

fipo-gerenciador-nivy

Como documentar um novo projeto

Um projeto pode ter inumeros tipos de documentações diferentes, mas uma apenas é obrigatória desde o nascimento do projeto. Estamos falando da documentação de Principal

Markdown

Por Padrão todo projeto da Dump é documentado com a linguagem de marcação markdown, é importante que você saiba usar isso!

Vou deixar um guia basico do Markdown abaixo para você

• Markdown Basic Guide

Documentação Principal

A documentação principal é dividita em tópicos

Apresentação do projeto

Com o nome o titulo do projeto em evidencia, teremos que fazer uma breve descrição do que se trata e o resultado que entrega a aplicação para o cliente.

Tecnologias aplicadas

Nesse tópico faleremos de uma ou mais tecnologias que merecem ênfase, pode ser uma lib que resolve um problema interessante no projeto, uma inteligencia artificial como GPT3 ou V8, frameworks etc...

Dependencias da aplicação

As dependencias são todas as coisas que precisam estar instaladas/coexistir em conjunto com a aplicação.

Passo a passo de como subir o projeto

Aqui faremos um passo a passo de como subir o projeto, descreveremos detalhadamente todos os comandos que devem ser ultilizados desde a hora de clonar o repositorio do projeto na sua maquina até a aplicação funcionando por completo.

Dependencia de serviços externos

Nesse tópico descreveremos, se houver, a dependencia de serviços externo, como API por exemplo. Informaremos as rotas ultilizadas e o formato da comunicação entre ambas.

Diagrama do fluxo da aplicação

É um recurso gráfico bastante didático, cujos desenhos explicam vários aspectos do projeto de maneira direta e visual. Usamos uma linguagem padrão para criar esses gráficos.

Mermaid é a linguagem padão para graficos Live Editor Mermaid isso deixa as coisas um pouco mais faceis agora!

Exemplo de uma documentação de projeto.

Documentação Padrão

O que não versionar

Arquivos Binarios

O que você tem de ter em mente é: formatos binários não são muito "diffáveis", ou seja, quando o arquivo mudar, o controle de versão vai armazenar uma versão nova do arquivo inteiro, e o tamanho total do repositório vai aumentar na mesma proporção. Se for um arquivo binário grande e que muda o tempo todo, isso pode ser um problema. Geralmente se evita armazenar ativos que são produto do build/processo de compilação, pois mudam o tempo todo, não colaboram para "contar a história" do código-fonte, e podem ser gerados novamente sempre que necessário.

Logs do sistema

Esses arquivos não devem ser versionados, pois eles não contribuem para a história do projeto

Senhas da empresa ou dados comporativos frageis

É muito comum programadores versionarem arquivos que contem senhas pessoais de acesso da empresa como servidores, banco de dados, storage, chaves ssh entre outros. Devemos tomar muito cuidado ao subir para o repositório nossos códigos e devemos sempre nos certificar de que nada crucial de acesso está sendo "commitado"

Trabalhando no repositório do projeto

Fluxo de trabalho de ramificação de recursos usando Git

A ideia central por trás do Fluxo de trabalho de ramificação de recursos é que todo desenvolvimento de recursos deve ocorrer em uma ramificação dedicada em vez de na ramificação homolog. Esse encapsulamento facilita para vários desenvolvedores trabalharem em um recurso particular sem perturbar a base de código.

Encapsular o desenvolvimento de recursos também permite aproveitar solicitações pull, que são uma maneira de iniciar discussões em torno de uma branch. Eles dão a outros desenvolvedores a oportunidade de aprovar um recurso antes que ele seja integrado ao projeto oficial. Ou, se você ficar preso no meio de um recurso, vai poder abrir uma solicitação de recebimento pedindo sugestões de seus colegas. O ponto é que as solicitações pull tornam muito fácil para a equipe comentar sobre o trabalho um do outro.

Como funciona

O fluxo de trabalho da ramificação de recursos pressupõe um repositório central, e a ramificação homolog representa o histórico oficial do projeto. Em vez de fazer o commit direto na ramificação homolog local, os desenvolvedores criam uma nova ramificação sempre que começam a trabalhar em um novo recurso. As ramificações dos recursos serão sempre os mesmos nomes das issues criadas no jira, inclusive, na descrição de cada issue do jira contem um local chamado Criar branch, que permite copiar o comando completo git checkout -b FIPO-282-descricao-da-tarefa-no-jira, você poderá usar isso diretamente no seu terminal do projeto. A ideia é dar um objetivo claro e bastante focado a cada ramificação. O Git não faz distinção técnica entre a ramificação homolog e as de recursos, então os desenvolvedores podem editar, preparar e fazer o commit de alterações em uma ramificação de recurso.

Além disso, as ramificações de recursos podem (e devem) ser enviadas para o repositório central. Assim é possível compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial. Uma vez que a homolog é a única ramificação “especial”, o armazenamento de várias ramificações de recursos no repositório central não apresenta problemas. Com certeza, essa também é uma maneira conveniente de fazer backup das commits locais de todos. A seguir, é apresentado um passo a passo do ciclo de vida de uma ramificação de recursos.

Comece criando uma ramificação apartir da ramificação homolog

Todas as ramificações de recursos são criadas a partir do último estado de código de um projeto. Este guia pressupõe que a manutenção e a atualização disso sejam feitas na ramificação homolog.

git checkout homolog
git fetch --all
git pull
git checkout -b FIPO-282-descricao-da-tarefa-no-jira

Essa ação muda o repositório para a ramificação homolog, obtém os commits mais recentes e redefine a cópia local do repositório novo a ser implementado à versão mais recente.