• 1.0 - O que é git ?
  • 1.1 - Detalhes importantes
• 2.0 - Ta, mas como o git funciona?
  • 2.1 - Ciclos de vida
• 3.0 - Criando um gitHub
• 4.0 - Criando um repositório
• 5.0 - Adicionar credenciais ao vs code
• 6.0 - Conectando um repositório a uma origen remota
• 7.0 - Comandos
  • 7.1 - Git status
  • 7.2 - Git log
  • 7.3 - Git add
  • 7.4 - Git commit
  • 7.5 - Git push
  • 7.6 - Git pull
  • 7.7 - Git checkout
  • 7.8 - Git merge
• 8.0 - gitignore
• 9.0 - Conventional commits
• 10.0 - git workflow
  • 10.1 - Fluxo iniciante - aprendendo a usar git
  • 10.2 - Fluxo de desenvolvimento individual
  • 10.3 - Workflow esperado em equipes
• 11.0 - Encerramento e extras

Esse repositório reúne meus estudos e testes sobre git e gitHub. Será um apanhado de informações, se sinta livre para ler, salvar, forkar ou compartilhar o projeto, e se achar correções ou melhorias sua contribuição é bem vinda.

Lembrando que todo tipo de opinião sobre o uso de algum conceito ou ferramenta também está atrelado a minha visão da forma de se usar ou proceder. Sendo então parcial e não passando de uma recomendação, se acaso algo for normativo irei indicar em conjunto a própria informação da mesma.

E se gostou do conteúdo deixe uma estrela para incentivar o trabalho.

Git é uma ferramenta de versionamento de código, e serve literalmente para criar versões, igual quando temos aplicativos com 1.0, 1.2, 2.5 e por aí vai. Não entrando em questões de como isso é numerado, a ideia é a mesma, é criado múltiplas versões do item em questão, que no caso se faça de código, ou mais especificamente arquivos de código. Porém o git é tão poderoso que pode criar versões de qualquer arquivo que se desejar.

Para explicar melhor o conceito de versionamento pode-se citar os diversos trabalhos de escola ou um TCC de curso ou graduação. Sempre se inicia com um nome, porém conforme passa por revisões tende-se a mudar o nome do arquivo, virando algo como:

Trabalho-revisado

Trabalho-revisado-final

Trabalho-revisado-final-agoraVai

E isso dificulta muito o controle por que não é possível saber o que foi feito em cada parte, nem mesmo olhando daria pra saber exatamente qual a ordem em que vieram. Pois se houverem mais marcações pode gerar confuções.

Com git poderia se manter o nome e geral códigos de marcação e comentários, marcando as versões.

Git te responde algumas perguntas básicas sobre as alterações feitas.

1. O que mudou ?
2. Quando mudou ?
3. Por que mudou?
4. Quem fez a mudança?
5. Podemos reproduzir essa mudança?

Isso gera uma estrutura de marcações de commit, que evidencia essas informações.

nome do Trabalho(arquivo) - data de alteração - código único de alteração (hash do commit) - comentário de alteração - quem alterou

E quanto a replicação do comportamento, podemos conferir nas descrições de alteração dos arquivos alterados ou clonar o repositório em si

Seria muito mais fácil de fazer trabalho em grupo usando um versionador, e a ideia é essa mesma, porém com códigos.

Como o git é um sistema de gerenciamento de controle de versões de código (arquivos e documentos se olhar de modo mais geral), ele possui recursos avançados para monitorar e acompanhar o que os arquivos do projeto em si.

Isso conta tanto em alterações no arquivo quanto o caminho dentro das pastas (diretórios).

Isso o permite monitorar todas as mudanças ocorridas, logo a partir do momento que é iniciado no projeto. Geralmente esse processo ocorre no repositório local, e a cada alteração isso é indicado e mapeado pela ferramenta.

A primeira parte indicada mostra que o código era como estava a esquerda, mas isso foi removido e então está em vermelho. E então ficou como está a direita, e como foi adicionado está em verde.

Sendo na realidade apenas uma mudança de formatação, por isso indica que algo foi removido e agora se tem um novo bloco.

Já a segunda parte que mostra um espaço vazio a esquerda e um texto em com fundo em verde a direita mostra adição de parte totalmente novas.

As mudanças monitoradas são demonstrada através de um poderoso sistema que pode ser chamado como relativo a estágios ou fases.

Cada fase representa algo que ocorre com os arquivos, há imagens com mais detalhes ou até mais comandos ou relações a estados. Mas o primeiro contato está relativo a um ciclo resumido.

De modo geral, após se linkar um repositório ao git, o sistema git está monitorando esses arquivos, mas eles não foram se quer adicionados para o monitoramentos, então ficam contando estado como untracked.

Ao usar o comando git add, e o estado do arquivo se torna staged, ou seja, agora o arquivo se torna monitorado pelo sistema git.

Após isso, se usar o git commit se torna unmodified, que diz que as alterações do arquivo estão fixadas, e também estão como não modificados e podem ser upados para o repositório remoto.

Qualquer alterações a partir do momento que o arquivo foi adicionado ao monitoramento git, ele se torna modified, indicando que a modificações que devem ser adicionadas.

Esses são os estados ou fases básicas dp git, a seguir será mencionado com mais detalhes os comandos e ações em geral.

O processo de criação de um gitHub é bem simples é preciso acessar o site do gitHub através do link https://github.com.

A tela será a seguinte:

Deve se clicar em Sign up no canto superior direito.

Então preencher os dados comuns, que são email, senha e nome de usuário.

Também será pedido um número de código que foi enviado para e-mail informado nos daos. Como uma confirmação para e-mail válido.

Daí é só escolher se você quer receber notificações do gitHub e responder o captcha para concluir a primeira etapa.

O procedimento pode ser visto na gif abaixo :

Logo depois há algumas configurações a se preencher

O primeiro é a pergunta de quantas pessaos atuam na equipe, no geral será respondido "apenas eu", porque é sua conta pessoal.

O segundo são possíveis usos para sua conta do gitHub, se tiver focos em mente já é legal colocar. Se não tiver, recomendo colocar pelo menos o último, que menciona comunidade.

O terceiro tópico é sobre escolher modalidade free ou modalidade paga, aqui escolha o free que é mais que suficiente.

E pronto, sua conta esta criada e já é possível criar repositórios com projetos, gerar commits e participar da comunidade em si.

Primeiramente, cabe dizer que um repositório é no sentido do dicionário, um lugar onde se armazena, guarda, arquiva ou coleciona alguma coisa. E nesse caso, um repositório git se destina, primáriamente, a guardar projetos e códigos. Assim como temos a ferramenta git monitorando as versões dos nossos arquivos dentro de um projeto, teremos os repositórios para alocar os projetos e suas estruturas de pastas e arquivos.

Esses repositórios são um ambiente remoto, que alocam os dados em uma espécie de nuvem. Assim, nossos códigos versionados podem ficar em um lugar seguro. E nos permite compartilhar códigos e projetos, demonstrar a evolução dos projetos em si e da nossa maneira de codar e trabalhar com projetos. Além de também nos permitir criar uma espécie de portfólio e mapa de trajetória.

Sendo também possível ter contato com códigos e projetos de outros programadores e projetos open source.

Para criar um repositório é um processo bem simples. Basta clicar no simbolo + (de mais) no canto direito superior da página. Estará entre o sininho de notificações e a foto de perfil.

Ao clicar aparecerá opções. Então aparecerá opções, a primeira é para criar um novo repositório.

Irá abrir uma janela conforme abaixo.

você estará colocado como dono do repositório (owner), e será necessário um nome para ele (repository name). A descrição (Description) do que é esse repositório é opicional, eu costumo colocar após já fazer coisas no repositório, pois terei uma visão mais clara de como descrevê-lo, porém se decidir adicionar já na abertura já pode também.

Uma opção logo abaixo da descrição é se o repositório será público (public) ou privado (private), se for público qualquer pessoa que acessar seu perfil poderá ver o repositório, se for privado apenas você ou quem tiver permição poderá ver. É importante colocar como público caso sejam projetos pessoais e para portfólio.

Outro detalhe é que commits em repositórios privados só contam se você ativar a opção de mostrar contribuições privadas. Caso contrário, qualquer commit feito em repositórios privados não irão contar no seu histórico de contribuições.

A última parte de configurações é adicionar ou não um readme (para descrever o repositório e informações importantes), um .gitignore (que indica arquivos e diretórios que o git não irá monitorar) e uma licença. Esses inicialmente ficam como opcionais mesmo, mesmo criando sem é possível criar depois.

Preenchendo tudo é só clicar em 'create repository' e pronto, já temos o repositório criado.

Adicionar suas credenciais é necessário para que os commits fiquem registrados no seu nome. Sendo fácil de entender quem fez que alteração e também para preencher o histórico de commits na página inicial do seu gitHub.

O processo todo é bem fácil, podendo entrar no terminal integrado do vs code pra isso, sendo esse terminal qual for. O processo vai ser clicar em terminal na parte superior esquerda.

E então o terminal que está definido como padrão do vs code irá abrir na parte inferior. Sendo o meu o ZSH.

O processo pode ser visto abaixo:

Então será inserido o nome e e-mail de usuário.

Para configurar as credenciais para apenas o projeto que está mexendo no momento, deve se usar os comandos abaixo, setando nome e e-mail para o projeto, de modo local.

# configura o nome de usuário de modo local
git config  user.name "Um nome maneiro"

# configura o email de usuário de modo local
git config  user.email "[email protected]"

Já para configurar o nome e e-mail de forma global, se usa o mesmo comando, mas adicionando a flag --global. Que faz com que o nome e usuário sejam definidos para o computador. E todo projeto que você mexer com esse computador irá usar essas credenciais por padrão, a não ser que seja mudado ou configurado um outro nome e e-mail localmente para um projeto após sua abertura.

# configura o nome de usuário de modo global
git config --global user.name "Um nome maneiro"

# configura o email de usuário de modo global
git config --global user.email "[email protected]"

Após qualquer um dos comandos de configuração o usuário está configurado e é possível enviar commits assinados por você.

Só cabe lembrar que não é recomendado usar configurações globais em um computador que possa ser acessado por várias pessoas.

Para enviar os commits feitos localmente para um repositório remoto é preciso definir a origem em que se encontra esse repositório. Há mais de uma maneira de fazer isso, mas talvez a mais rápida e simples é via um endereço HTTPS. Que já é fornecido pelo gutHub ao criar uma repositório.

Após criar o repositório no github, crie uma pasta local que conterá seu projeto, servindo como um repositório local. Nele digite o comando de git init para iniciar o monitoramento git nos arquivos.

git init

Então pegue o comando da primeira linha do segundo bloco da imagem anterior.

git remote add origin https://github.com/JCDMeira/creando-rep.gi

Isso adicionará a origin ao repositório, sendo possível agora adicionar os arquivos e subir para o repositório remoto.

Já quanto ao processo de subir os dados propriamente ditos vamos ver em breve mais a frente.

No geral tudo no git será realizado por comandos, e aprender a manipular as situações via comandos é essencial. Até é possível hoje em dia manipular tudo via interface, mas isso te torna nada mais que um apertador de botões.

Aprender realmente a usar os comandos é que te torna um melhor profissional, e após masterizar os comandos, mesmo que não seja completamente (isso seria muito difícil), é possível usar a interface a seu favor em alguns casos.

O comando git status serve para ver os status atuais de cada arquivo no projeto. Permitindo ver em que momento do ciclo de vida eles estão.

Permitindo com isso entender quais são os próximos passos para manipular esses arquivos.

O comando git log permite que seja visto o histórico de commits do projeto.

O log simples mostra apenas os últimos commits feitos, mas é possível usar git log --all para mostrar todos os commits feitos. Ou o git log --oneline para mostrar os últimos com informações resumidas.

Outro fator importante de se notar é que o comando abre um modo diferente no terminal. E para sair do modo log é só apertar a tecla q do teclado

Outra função importante do log, mas que é pouco conhecida, é que há uma função de pesquisa no comando. Enquanto na tela de log se teclar / entra em um modo de pesquisa, que permite pesquisar por palavras que aparecem nas mensagens dos commits.

Após executar uma pesquisa é possível voltar para o todo dos commits apertando a tecla b

Além disso há outras flags além de all que podem ser úteis

Pesquisar commits anteriores a uma data: git log --before="2022-04-01"

Pesquisar commits posteriores a uma data: git log --after="2022-04-01"

Pesquisar commits entre datas: git log --before="2022-04-01" --after="2022-06-01"

Pesquisar commits desde: git log --since="2 days ago"

pesquisar commits por autor: git log --author="jean"

Esses recursos permitem fazer uma busca mais focada nos commits feitos.

O comando git add permite adicionar os arquivos e diretórios para o estado de tracked, ou seja, monitorados. Há diversas formas diferentes de se usar o comando, divergindo o comportamento do mesmo.

Adicionar um arquivo ou diretório

git add caminho_do_arquivo-diretorio

Um exemplo para algo que esteja na raiz.

git add readme.md

git add images/

git add .

Ao usar o ponto, todos os arquivos e pastas são registrados. Sejam novos arquivos, as mudanças feitas em um arquivo já monitorado ou mesmo arquivos que foram deletados. Todas alterações são computadas.

Um ponto de alerta para usar o ponto é que se estiver dentro de um diretório no projeto e não na raiz. As alterações que serão contadas é do ponto do projeto em que se está em diantes (pastas e arquivos dentro da pasta atual).

git add --all ou git add -A

Usar --all ou -A garante o mesmo comportamento do git add . com a diferença que o ponto de partida vai ser a raiz do projeto. Sendo sempre adicionada todas as alterações do projeto.

git add -u

A flag -u faz com que os novos arquivos não tenham suas mudanças adicionadas. Apenas arquivos que já existiam, e pode haver alterações no arquivo ou mesmo o a ação de deletar o arquivo todo.

git add *

O git add * não computa deleções, e por isso serve um grande aviso aqui, dependendo de como estiver seu projeto, usar muito o comando com o asterisco irá gerar conflitos. Pois o uso de pull e push não irão contar arquivos deletados, e isso pode conflitar em algum momento (tende fortemente a gerar conflitos).

Em pesquisas vi dizeres de que o comando com o asterisco não adicionava arquivos começados em . também, mas nos testes que fiz a única diferença dele para o git add . foi não computar deleções.

commits são a passagem dos arquivos que estão trackeados para o estatus staged. Deixando eles prontos para enviar ou submeter para o repositório remoto (principal).

Os commits são o ato de efetivar as mudanças feitas, sejam ela alterações, remoções ou adições.

O commit cria uma espécie de "fotografia" do momento atual do projeto, e essa fotografia é marcada por um hash_id. Que nada mais é que uma sequencia alfa numérica única, que define aquele momento do projeto.

Com momento se entende o estado que cada arquivo tinha, a estrutura de pastas e tudo que o projeto continha naquele commit. Sendo possível assim criar um histórico de alterações e voltar a um determinado commit se necessário.

Em geral nos commmits se passa uma mensagem, através da flag -m, essa mensagem fala de modo resumido o que foi a alteração causada por aquele commit.

gi commit -m 'mensagem do commit'

O git push envia as alterações commitadas localmente para o repositório marcado como a origin remota. Do ingles push é empurrar, e é de certa forma isso que é feito, os commits são "empurrados" para o repositório remoto.

git push

Uma informação importante é que geralmente o push precisa indicar a origin a qual se quer enviar os commits. Que geralmente será a branch que se quer que receba os commits.

git push origin minha_origin

Para facilitar é possivel configurar uma origin para aquela branch. E assim ela fica salva e todo commit após isso fica direcionado aquela origin.

git push --set-upstrean origin minha_origin

O que também pode ser feito usando a flag -u que vem de upstrean

git push -u origin minha_origin

O git pull serve para atualizar seu repositório local com as alterações do remoto. Pull do inglês é puxar, então é o mesmo que literalmente "puxar" as novas alterações que existem no remoto.

É muito útil quando se trabalhar em equipe ou quando se faz alguma alteração diretamente no remoto.

O comando indica de onde do repositório remoto se quer puxar os dados e qual branch local vai receber.

git pull (remote) (branch)

No caso de origin se trata da origin setada para essa branch

git pull origin master

Se passado apenas um argumento se trata do local remoto, sendo entendido como o local será a branch atual.

git pull (remote)

Sem argumento algum trata da referência da branch atual, tanto pegar dados da origin configurada para branch. quando a própria branch em que estamos para receber.

git pull

git checkout é o comando que nos permite navegar entre as diversas branchs do projeto.

Branch vem do inglês, significa ramo. Ter múltiplas branchs é como ter diversas linhas do tempo num projeto. Podendo ter cada qual o seu objetivo único. Uma branch vai compartilhar os arquivos da branch que originou ela. Ou seja, ao criar um branch chamada minha_branch a partir do ramo master, temos tudo que ocorreu no ramo master na branch minha_branch também.

Porém vale lembrar que tudo que ocorrer em master após a criação de minha_branch não estará disponível em minha_branch. Assim como o que for criado nesse novo ramo também não estará em master.

A não ser que comandos como pull ou merge (entre outros) sejam usados para fazer os ramos terem o que o outro criou após a separaçao da linha do tempo.

E é justamento o checkout que permite a navegação pelas branchs. O comando a seguir sairia do ramo atual para o chamado de minha_branch.

git checkout minha_branch

Se acaso quiser criar uma branch é possível usar a flag -b no comando checkout.

git checkout -b minha_nova_branch

O comando acima criaria uma branch chamada minha_nova_branch

Se não quiser mais usar uma branch é possível ainda apagar a mesma, usando o comando branch com a flag -d

git branch -d minha_branch

Porém dessa forma só é possível deletar branchs que não contenham alterações a serem commitadas. Acaso se queira deletar branchs com alterações ainda por commitar se deve forçar a deleção, usando o D maiúsculo.

git branch -D minha_branch

O comando merge uni dois ramos, depositando as alterações de um ramo no ramo atual, ou seja, pega as alterações commitadas de um ramo e mescla no ramo em que estamos nesse momento.

Se estivermos em master e usarmos o comando a seguir, mesclariamos as alterações de minha_branch em master.

git merge minha_branch

Isso também é possível de fazer na interface online, mas não vem ao caso no momento.

O arquivo .gitignore serve para ignorar arquivos e suas mudanças. O git não irá "olhar" para arquivos ou diretórios inseridos no corpo do arquivo chamado .gitignore, sendo assim não são assistidos ou monitorados pelo git.

Alguns exemplos de maneiras de colocar estará abaixo.

Ignorar um arquivo

teste.js

Ignorar todos os arquivos da mesma extensão

*.js

Ignorar diretórios

images/

Ignorar diretórios (buscando sub-diretórios também)

**images

Também é possível 'instalar' uma versão padrão de .gitignore

Para isso basta rodar o seguinte comando no seu projeto

npx gitignore node

O arquivo virá com diversos cases padrões tendo em conta o node para esse caso, e é possível adicionar ou remover o que desejar do corpo do arquivo.

E para qualquer gitignore, é possível usar # para criar comentários.

Em projetos é muito comum se fazer um número incalculável de commits, ainda mais em projetos grandes que perduram ao longo do tempo. E isso resulta em uma necessidade, a padronização de commits, e aqui não é somente adequal um molde que todos que trabalham naquele projeto façam mensagens de commits parecidas. É mais sobre conseguir tirar informações úteis da mensagem do commit.

Há uma necessidade que também é comentada para códigos, sejam para nomes de variváveis, funções e classes. Ou para a maneira geral de se escrever o código. Sempre há uma necessidade de semântica muito bem colocada.

No dicionário semântica é "Semântica é o estudo do significado. Incide sobre a relação entre significantes, tais como palavras, frases, sinais e símbolos, e o que eles representam, a sua denotação. A semântica linguística estuda o significado usado por seres humanos para se expressar através da linguagem." segundo a wikipédia. É nada mais que o sentido das palavras, e nesse caso, se o que se coloca de nomes dentro do código estão condizentes com seus funcionamentos dentro do arquivo e projeto. E acredite, a semântica ajuda demais na compreenção.

Para commits, semântica irá ajudar a entender melhor o que é feito de mudança naquele commit, ou seja, que tipo de alterações foram realizadas.

Portanto, os commits convencionais nada mais são que commits com semântica. E os mesmos não servem apenas para projetos grandes e com equipes. Se você quer melhorar a qualidade do seu desenvolvimento, deve usar os Conventional commits, subir o projeto todo em um commits não traz a história por trás do progresso do projeto.

Ao usar commits pequenos e bem colocados é possível mostrar todo o histórico e a maneira com que algo foi desenvolvido, de maneira muito mais clara e objetiva.

A estrutura esperada do commit é:

tipo(escopo |?| ): mensagem

(Mensagem com detalhes mais explicados |?| )

Footer é para informações adicionais, podendo também passar closes #id_issue, para fazer o commit fechar issues automáticamente.

Sendo que os campos com |?| são opcionais.

As opções de tipo de commits são:

1. feat - Um inclusão de um novo recurso (se relaciona com o MINOR do versionamento semântico, ou seja, são mudanças que não compõe um versão inteira, mas geral novos recursos, o mesmo que dizer que alterou a versão de um software de 1.0 para 1.1).
2. docs - Mudanças na documentação, No readme ou em outras docs. (Não inclui mudanças em arquivos de código).
3. style - Alterações referentes a formatações de código, semicolons, trailing spaces, lint... (espaço em branco, formatação, ponto e vírgula ausente etc.).
4. refactor - Mudança por refatorações de código, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, melhorias de performance devido a um code review ou ainda melhorias da apresentação do código para melhor compreenção de desenvolvedores.
5. build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.
6. test - Altera arquivos de testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código).
7. chore - Atualiza tarefas que não geram alterações no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas que realmente não entram em produção. (Não inclui alterações em código).
8. perf - Vem de performance. altera códigos com objetivo de melhorar o desempenho.
9. ci - Altera arquivos e scripts de configuração de CI (exemplo: Travis, Circle, BrowserStack, SauceLabs).
10. env - basicamente utilizado na descrição de modificações ou adições em arquivos de configuração em processos e métodos de integração contínua (CI), como parâmetros em arquivos de configuração de containers.

Exemplos de commits:

git commit -m "feat: add Home

git commit -m "fix(Home): Title

Corrige erro de tipografia

Aqui nessa sessão quando falo em git workflow se trata de certas maneiras de se trabalhar com git, como a própria tradução seria, fluxos de trabalho com git. Ou seja, trabalhar com o versionamento de uma forma ou outra.

Já adianto que essa parte terão mais de minhas opniões e minha vivência. Você leitor é livre para adotar ou não, concordar ou não. Enfim, trabalhar com o versionamento é algo que está no dia a dia do programador, seja trabalhando sozinho, com equipe ou mesmo ao fazer projetos testes e portfólio. E acredito que não haja exatamente um certo e errado, tudo vai se basear em padrões e formas adotadas.

Mas se você está começando a aprender programação, ou fazendo uma transição de carreira, como eu fiz em algum momento. Você pode estar se deparando com um mundo enorme de conteúdos distintos e ao mesmo tempo necessário e correlatos. Você pode estar vendo coisas de front-end como html, css, js e frameworks/bibliotecas ou mais a parte de back-end com rotas, métodos http, api's, end-point e além de todas essas coisas está tendo que ver git e versionamento de código.

Sim, são várias coisas para aprender. E pode gerar um pouco de desconforto no começo. Principalmente o fato de usar o terminal para executar o git. E acredite, essa é uma reclamação que ouço muito do pessoal que está começando ou até de pessoas que já estão programando bem e não acostumaram a usar terminal para comandos git desde o começo.

E se você leu esse repositório deve ter visto que eu acredito que usar o terminal é a maneira mais adequada de aprender. Mesmo com o desconforto inicial, é primordial usar o terminal e aprender os comandos, mesmo apanhando no começo. E agredite, usar coisas sem entender completamente os comportamentos me fez ter que resolver muitos conflitos, e até mesmo gerar vários comportamentos estranhos em commits, como duplicações, embaralhar linhas do tempo ou ficar tendo que arrumar conflitos entre remoto e local. Mas acredite, apesar da raiva momentânea, isso me fez crescer muito e aprender cada vez. Sendo que até hoje contínuo aprendendo.

Recentemente fiz um mini curso de git e o instrutor chegou a mostrar o uso da interface, mas antes disse ele disse algo mais ou menos como:

Então nos subcapítulos a seguir vou tentar te ajudar a pegar melhor o uso do git, ou pelo menos facilitar um pouco a sua vida ao usar o terminal. Claro, se permitar errar e gerar os comportamentos loucos que você vai ter que resolver, mas também espero que meus comentários lhe sejam úteis. As pessoas costumam falar que tenho métodos meio espartanos (já ouvi isso muitas vezes ao falar de git kk). Mas ainda acho melhor apanhar usando o terminal no começo a me acostumar com um anestésico que vai apenas ser um paleativo, vai facilitar a vida no momento e até me tornar dependente, porém nunca vai solucionar a causa (falta de costume e/ou conhecimento).

Esse primeiro fluxo de trabalho é pensando em quem está aprendendo. É o que vejo como mais simples, mas ainda tem alguns pontos a se tomar cuidado, porque pode gerar confusão ou conflitos nos arquivos se não pensar nisso.

Aqui, se você ainda está aprendendo te recomendo algo que vai te ajudar bastante a tirar boa parte do peso. É o que pode ser chamado de mínimo ridiculo possível.

A ideia vai ser, para não ter que ficar pensando em que commitar ou que tipo de projeto fazer e como fazer os commits, que ordem, em que padrão ou qualquer coisa do tipo. Você só vai commitar e fazer push, não importa o padrão da mensagem.

E para não pensar no projeto e esses detalhes, você vai criar commits de algum curso que estiver fazendo.

Teve exercício ? faz o exercício em um arquivo e commita ele.

Fez aula, faz um arquivo e faz commentários da aula no arquivo.

Aqui nessa parte, seu repositório pode ser o mesmo título do curso. E até pode ser um commit por aula vista. A ideia é pegar costume usando git via terminal aumentando bastante o uso.

Já aviso, não é a forma ideal e quanto antes você deve começar a fazer projetos, mesmo que pequenos. Não torne commitar aulas um padrão ou uma dependência, pode lhe servir até mesmo após pegar maior compreensão e estar fazendo projetos, pois vai criar notas consistentes dos seus insights de um conteúdo, e estará hospedado no gitHub (ou algum outro banco de repositórios). Mas é diferente de estruturar e fazer um projeto.

E por isso é o mínimo ridiculo possível.

Quanto aos passos e cuidados que falei, eles são o seguinte:

1. Abra o repositório sempre no gitHub;
2. Não crie o repositório com nenhum arquivo;
3. Crie uma pasta local;
4. Use git init na pasta;
5. Use o link http indicado após o repositório ser criado para conectar a pasta ao repositório remoto (se precisar volte a seção 6);
6. Crie um readme.md detalhando seu projeto;
7. Use um git add .
8. Use git add commit -m 'initial commit'
9. Use git push -u origin master (ou mais se preferir)
10. Pode começar a criar e editar os arquivos e fazer os commits sempre repetindo o padrão add, commit e push. (O push agora não precisa do -u origin mastes, bastando apenas git push)
11. Não crie alterações direto no repositório online.

Esse fluxo fará com que a criação e conexão dos repositórios seja simples e você não corre o risco de tornar o remoto mais atualizado que o local, que pode ocasionar conflitos ou não deixar o push ser completado. E também limita o número de ações (nem precisa se preocupar com semântica dos commits ou em usar os add's diferentes).

Use pra praticar e se estiver confortável, me fale o resultado depois.

Esse segundo já segue um fluxo se você está trabalhando sozinho. Cheguei nele após conversar com um amigo que está a mais tempo no ramo, e comecei a usar bem antes de começar a trabalhar, acredite ou não, me ajudou bastante a desenvolver em equipe.

Aqui se presa o controle de branches. E a forma de criar o repositório pode até ser diferente, ou os passos podem ter variação, mas pra facilitar vou descrever próximo ao que foi o anterior.

1. Abra o repositório sempre no gitHub;
2. Não crie o repositório com nenhum arquivo;
3. Crie uma pasta local;
4. Use git init na pasta;
5. Use o link http indicado após o repositório ser criado para conectar a pasta ao repositório remoto (se precisar volte a seção 6);
6. Crie um readme.md detalhando seu projeto;
7. Use um git add .
8. Use git add commit -m 'initial commit'
9. Use git push -u origin master (ou mais se preferir);
10. Adicione a estrutura inicial do seu projeto se ela existir. (o conteúdo de npx create-react-app por exemplo ou qualquer boilerplate que você tenha);
11. Se adicionou uma estrutura use o processo de git add . , git commit -m 'Initial setup' e depois o git push;
12. Use o comando git checkout develop (ou development), criando assim sua branch de desenvolvimento;
13. Pode começar a criar e editar os arquivos e fazer os commits;
14. No primeiro push da branch de desenvolvimento use git push -u oringin developt (ou development);
15. Pode seguir desenvolvendo, repetindo o padrão add, commit e push. (O push agora não precisa do -u origin mastes, bastando apenas git push)
16. Após cada agrupamento de commits que complete algum propósito você fará o merge das alterações para master. Tendo duas opções.
17. Va para master com git checkout master, e use git merge develop. Depois use o git push na master e volte para a develop (esse evita alguns conflitos);
18. ou va na plataforma online do github e faça um pull-request de develop para master. Depois no local usar git pull na master, e volte para develop e siga programando;
19. Evite alterações direto no repositório online.

Nesse caso, o fluxo esperado é sempre criar na branch de desenvolvimento e passar as alterações para a master depois.

Se puder já use os conventional commits.

Essa maneira também te permite já começar a aplicação e fazer o deploy, porque alterações na branch de desenvolvimento não irá disparar atualizações automáticas no deploy. Sendo que só irá ocorrer após os merges.

Há uma variação nesse caso que pode contér uma branch stage (staging), que irá refletir a master sempre, mas estará ligada a bancos de dados mirror e a condições que são possíveis quebrar ao fazer testes, ou que se mantenha um backup de master para testes. Sempre atualizando com certa periodicidade. Mas só vou citar para saber que existe, não sei que formas tanto podem ser usadas para criar esse formato.

Esse já é o mais complexo de certa forma. A ideia aqui é que será criado uma branch por tarefa, sejam features, correções de bug ou refatorações. Sempre irá criar uma branch para executar.

Muitas vezes não terá criação de repositório ou qualquer coisa do tipo, pois quando você chega o projeto já existe e roda a um tempo que não da pra dizer (depende do projeto/empresa que você chegou).

A única coisa que quero dizer aqui, é que no geral features em geral vão ter suas branchs criadas da branch mirror ou da branch de ambiente do seu squad, enquanto correções de bugs são de branchs criadas a partir da master.

Esse fluxo também requer aprovações. Como na imagem abaixo, que representa o fluxo todo esperado. (pode variar dependendo da empresa/equipe).

Em resumo: A branch da tarefa é criad; O trabalho em si é feito (passando por vários git add, commit e push); Um pull request (PR) é aberto, solicitando mesclar a branch da tarefa com a de destino (pode não ser a master, mas sim um ambiente de testes); Se discute o commit com os revisores (podendo ou não ter alterações necessárias); A PR ganha as aprovações necessárias; O merge acontece.

Esse são os passos esperados (ou mais ou menos eles, pois irá variar de lugar para lugar).

É possível usar mais ou menos esse padrão sozinho, criando uma branch por tarefa com nomes relativos a tarefa, mas não terá a parte de comentários ou a necessidade de aprovações.

Fala galera, foi um prazer criar esse repositório, me ajudou a revisar e também a trazer assuntos a toda, permitindo que eu discutisse com outros devs e com diversas pessoas da área.

Espero que tenha sido útil pra todos que leram e te agradeço se você leu até aqui. Se gostou dê estrelas e compartilhe com outros desenvolvedores ou com quem está começando, isso me incentiva a criar mais coisas. E se sentir falta de algo me manda pelo linkedin que na medida do possível vou atualizando o repositório. Sei que ele não fala sobre tudo de git e que tem muito conteúdo a mais, seja sobre comando, táicas, dicas e até coisas além disso tudo.

E por isso vou deixar umas indicações de conteúdo extra também.

Se você quiser saber mais dos comandos, inclusive de vários que não comentei nesse repositório, esse link tem diversos deles, falando de modo separado dos básicos, intermediários e avançados.

O link a seguir é mais um tutorial abrangente, mas tem diversas coisas legais.

Esse último é par você se testar usando git, é um "joguinho" bem divertido que te obrigará a usar git para solucionar os enigmas dentro do repositório git-game.

Grato a todos, até uma próxima

⬆ Voltar ao top