Git e GitLab

Saindo do zero

Vanilton Pinheiro

vanilton.net

Quem sou eu?

Pinheiro

Vanilton

Quem são vocês?

O que trás vocês até aqui?

# O que vamos precisar

Ambiente

  1. Instalar Git (Link)
    • Mac - Instalar o Xcode e Homebrew
  2. Instalar PyCharm (Link)
  3. Opcional
    • Shell (Linux e Mac)
    • Terminal iTerm (Mac)
    • Terminal Terminator (Linux) 
# O que vamos precisar

Windows

iTerm 

Terminator

1

Sistema de Versão

2

Git

3

Configuração Git

5

Remoto

4

Versionando

6

Interface Gráfica

# O que veremos
# 1 INTRODUÇÃO
  • Controle de Versão
    • História
    • Benefícios
    • Aplicações
  • Sistemas de Controle de Versão (SVC)
    • Local
    • Central
    • Distribuído

Controle de Versão

# 1 INTRODUÇÃO

Fonte: https://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%B5es

Controle de Versão

# 1 INTRODUÇÃO

Fonte: https://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%B5es

Source Code Control System (SCCS)

Marc Rochkind desenvolveu o SCCS em SNOBOL4 no Bell Labs para um computador IBM System/370 rodando OS/360 MVT

* Código proprietário

1972

1982

Revision Control System (RCS)

Lançado por Walter F. Tichy, enquanto ele estava na Universidade de Purdue, como uma alternativa livre e mais evoluída para o então popular Source Code Control System (SCCS)

* Código aberto

86-90

Concurrent Version System (CVS)

Dick Grune "Criei o CVS para poder cooperar com meus alunos Erik Baalbergen e Maarten Waage no ACK (Amsterdam Compiler Kit) Compilador C."

* Código aberto

# 1 INTRODUÇÃO

Controle de Versão - História

Subversion (SVN)

Fundado pela CollabNet, Inc., o projeto e o software Subversion tiveram um sucesso incrível na última década.

* Código aberto

2000

2000

BitKeeper SCM

é um sistema de controle de versão distribuído, o primeiro beta utilizável estava disponível em Maio de 1999 e em 4 de Maio de 2000, o primeiro lançamento público do BitKeeper se fez disponível

* Código aberto

2005

Mercurial

é uma ferramenta multiplataforma de controle de versão distribuído para desenvolvedores de software. O criador e desenvolvedor líder do Mercurial é o Matt Mackall

* Código aberto

# 1 INTRODUÇÃO

Controle de Versão - História

  • Reverter estados
  • Comparar mudanças
  • Modificações (identificar causas e quem ocasionou)
  • Quando foram introduzidos problemas
# 1 INTRODUÇÃO

Controle de Versão - Benefícios

Controle de Versão - Mais benefícios

# 1 INTRODUÇÃO

Fonte: https://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%B5es

Control de Histórico e Rastreabilidade

Trabalho em Equipe

Marcação e Ramificação

Organização

Confiança

# 1 INTRODUÇÃO

Controle de Versão - Aplicações

  • Projetos de Software
  • Projeto de UX
  • Documentação
  • Estáticos de site

Sistemas Locais de Versão

# 1 INTRODUÇÃO

Quais vantagens e problemas possuímos nesse sistema?

Sistema Centralizado de Versão (CVCS)

# 1 INTRODUÇÃO

Quais vantagens e problemas possuímos nesse sistema?

Exemplos de CVCSs

# 1 INTRODUÇÃO

Sistemas Distribuído de Versão (DVCS)

# 1 INTRODUÇÃO
  • Em um DVCS os clientes não somente usam o estado mais recente dos arquivos: eles duplicam localmente o repositório completo.

Sistemas Distribuído de Versão (DVCS)

# 1 INTRODUÇÃO
  • Desta maneira, se qualquer servidor morrer, e diversas pessoas estiverem colaborando por meio de um sistema distribuído de controle de versão, qualquer um dos repositórios de clientes podem ser copiado de volta para o servidor para restaurá-lo.

Sistemas Distribuído de Versão (DVCS)

# 1 INTRODUÇÃO
  • Podemos afirmar que cada clone de repositório é, de fato, um backup completo de todos os dados.

Exemplos de DVCS

# 1 INTRODUÇÃO

Sistemas Distribuído de Versão (DVCS)

# 1 INTRODUÇÃO

Quais vantagens e problemas possuímos nesse sistema?

Sistemas Distribuído de Versão (DVCS)

# 1 INTRODUÇÃO
Ponto de Vista Vantagens Desvantagens
Desenvolvedor Rapidez Necessidade de maior conhecimento da ferramenta e do processo
Autonomia
Coordenação/Gerência do Time Redução de custos com servidor e infraestrutura externa de rede Necessidade de maior capacitação de desenvolvedores
Confiabilidade Importante ter um fluxo de trabalho bem definido

1

Sistema de Versão

2

Git

3

Configuração Git

5

Remoto

4

Versionando

6

Interface Gráfica

# 2 Git

Git - História

2005

# 2 Git

Git - História

# 2 Git

Git - História

  • Linus criador do Git
  • O termo "Git", uma gíria em inglês britânico para cabeça dura, pessoas que acham que sempre têm razão, argumentativas, podendo ser também pessoa desagradável ou estúpida

"Eu sou um desgraçado egocêntrico, então batizo todos os meus projetos com meu nome. Primeiro Linux, agora Git."

— Linus Torvalds

Git - Licença

# 2 Git

O Git é um software livre, distribuído sob os termos da versão 2 da GNU General Public License. Sua manutenção é atualmente supervisionada por Junio Hamano.

Portabilidade

# 2 Git
  • O Git foi primariamente desenvolvido para Linux, mas pode ser usado em outros sistemas operacionais baseados no Unix, incluindo o BSD, o Solaris e o Darwin. O Git é extremamente rápido em arquiteturas POSIX como o Linux.
  • O Git também roda no Microsoft Windows.

Quem usa?

# 2 Git

Git - Estrutura

# 2 Git

GitLab

Git - Estrutura

# 2 Git

GitLab

Vantagens 

# 2 Git
  • Open Source
  • Controle de histórico
  • Trabalho em equipe
  • Ramificação do projeto
  • Autonomia
  • Segurança
  • Organização
  • Repositórios reduzidos em tamanho

Entendendo Melhor

# 2 Git

Entendendo Melhor

# 2 Git

Estratégia

# 2 Git

O formato do objeto dos arquivos de repositório do Git usa uma combinação de codificação delta (armazenamento de diferenças de conteúdo)

v1

src/code.py 

work

src/code.py 

Fonte: https://stringfixer.com/pt/Delta_encoding

Os 3 Estados

# 2 Git

Prepara

Valida

Envia para o git

1

Sistema de Versão

2

Git

3

Configuração Git

5

Remoto

4

Versionando

6

Interface Gráfica

# 3 Configuração

 

A leitura da configuração é realizada de modo hierárquico

Configuração Inicial do Git

Primeiro aqui

Segundo aqui

Terceiro aqui

  • /etc/gitconfig: válido para todos os usuários no sistema e todos os seus repositórios. Se você passar a opção --system para git config, ele lê e escreve neste arquivo.
  • ~/.gitconfig ou ~/.config/git/config: Somente para o seu usuário. Você pode fazer o Git ler e escrever neste arquivo passando a opção --global.
  • config no diretório Git (ou seja, .git/config) de qualquer repositório que você esteja usando: específico para este repositório.

Perfil

# 3 Configuração

 

  1. Abrir o git bash
  2. Criar uma pasta com nome "git"
  3. Acessar a pasta "git"
$ git config --list
credential.helper=osxkeychain
alias.tree=log --graph --decorate --pretty=oneline --abbrev-commit
core.excludesfile=/Users/vaniltonpinheiro/.gitignore_global
core.autocrlf=input
difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"
difftool.sourcetree.path=
mergetool.sourcetree.trustexitcode=true
user.name=Vanilton Pinheiro
user.email=vanilton.pinheiro@fpf.br
commit.template=/Users/vaniltonpinheiro/.stCommitMsg

Perfil

# 3 Configuração

 

$ git config --global user.name "Vanilton Pinheiro"
$ git config --global user.email vanilton.pinheiro@fpf.br

Impacta no histórico do commit

Independe de como foi clonado o repositório ou se foi feito pull

E o que isso impacta?

Identificando o usuário

Perfil

# 3 Configuração

 

$ git config --global core.editor "nano"

Que tal alterar o editor padrão utilizado pelo git?

Para windows: https://stackoverflow.com/questions/10564/how-can-i-set-up-an-editor-to-work-with-git-on-windows

Perfil

# 3 Configuração

 

Vamos definir a branch padrão ao criar repositórios git

$ git config --global init.defaultBranch main

Ficou na dúvida do comando?

# 3 Configuração

 

Vamos configurar nosso primeiro repositório git

# 3 Configuração

 

  1. Criar uma pasta chamada "Project" dentro de nossa pasta git 
  2. Acessar a pasta
$ git init

Vamos configurar nosso primeiro repositório git

# 3 Configuração

 

  1. E se quisermos alterar uma configuração apenas para o repositório?
$ git config user.name "Vanilton de S. F. Pinheiro"

As demais configurações serão do global

Vamos configurar nosso primeiro repositório git

# 3 Configuração

 

Branch (local)

Repositório git

1

Sistema de Versão

2

Git

3

Configuração Git

5

Remoto

4

Versionando

6

Interface Gráfica

  1. nano README.md
  2. Escreva: Olá Mundo!
  3. Salve o arquivo

Vamos criar nosso primeiro arquivo no repositório

# 4 Versionando

 

Estou na brach master

Nenhum commit ainda

Existe arquivos não rastreados

Arquivos identificados

Nada em Stage

Brincando no Stage

# 4 Versionando

 

Adicionando na Stage

Removendo da Stage

Nosso primeiro commit

# 4 Versionando

 

Agora temos o commit e o status não possui nada para comitar

Vamos testar apenas com "git commit"

Visualizando o histórico de commit

# 4 Versionando

 

Histórico de commits

Mensagem do commit

Utilizou o nome da configuração de perfil do projeto

Nosso primeiro ponto na árvore de commit

Commit Hash - SHA-1

Visualizando o histórico de commit

# 4 Versionando

 

$ git log --pretty=format:"%h - %an - %ar : %s"

https://git-scm.com/docs/git-log#Documentation/git-log.txt-emHem

%h - Hash do commit abreviado

%an - Nome do Autor

%ar - Data relativa do commit 

%s - Mensagem do commit

Visualizando o histórico de commit

# 4 Versionando

 

$ git log -3
$ git log --stat
$ git log --pretty=oneline --reverse
$ git log --pretty=oneline --reverse -2
$ git log --since=2.weeks
$ git log --since=2.days
$ git log --since=23.hour

https://git-scm.com/docs/git-log#_examples

Experimente

Realizando alterações em arquivos

# 4 Versionando

 

  1. nano README.md
  2. Inclua: Primera alteração no arquivo..
  3. Salve o arquivo

M - Modificação 

(simbolizado por vermelho)

Visão curta (short)

Restaurando alterações

# 4 Versionando

 

Modificações desfeitas para a última versão comitada no repositório local

Restaurando alterações do remoto

# 4 Versionando

 

Modificações desfeitas para a última versão comitada no repositório remoto

Comitando e adicionando junto e misturado

# 4 Versionando

 

Altere o arquivo README.md conforme abaixo

Adiciona todos arquivos da área no commit

Comitando e adicionando arquivos por expressão regular

# 4 Versionando

 

$ git add *.md
$ git add git-*.sh
$ git add script/\*.js
$ git add arquivo1 arquivo2 arquivo3

Inclui todos arquivos com extensão .md

Inclui todos arquivos iniciados por "git-" seguidos de qualquer texto e na extensão .sh

Inclui todos arquivos do diretório e subdiretórios script seguidos na extensão .js

Incluindo arquivos individualmente

Fonte: https://git-scm.com/docs/git-add

Corrigindo commit

# 4 Versionando

 

  1. Corrigir antes do envio para remoto
  2. Corrigir após o envio para o remoto

git commit --amend

git commit --reset

Fonte: https://git-scm.com/docs/git-commit

Corrigindo commit - amend

# 4 Versionando

 

  1. Alterar o README.md com o conteúdo que desejar
  2. Adicionar o arquivo em Stage

Altere a mensagem do commit "Primeiro commit corrigido"

Verde (em Stage)

  1. Altera mensagem do commit
  2. Comitar o que está em stage

Corrigindo commit - amend

# 4 Versionando

 

  1. Vamos confirmar que o amend inclui o que está no stage
  2. Crie um novo arquivo chamado "nome.txt" na pasta do projeto

?? (Novo arquivo no repositório)

Obs: amend é sempre no último commit

E o reset?

# 4 Versionando

 

Redefine o HEAD atual para o estado especificado

  • git reset --mixed (default)
  • git reset --soft
  • git reset --hard

Fonte: https://medium.com/@andgomes/os-tr%C3%AAs-tipos-de-reset-aa220658d9b2

Voltando versões

# 4 Versionando

 

Duas maneiras simples

$ git reset HEAD~1 --soft
$ git checkout HASH_COMMIT

Coloca o HEAD um commit atrás do atual (~1)

Iremos reforçar na seção de Interface Gráfica :)

Coloca o HEAD um commit atrás do atual

Ignorando arquivos (não rastreando)

# 4 Versionando

 

Vamos simular a necessidade de ignorar arquivos que não necessitam ser enviados para o repositório git.

Vamos criar uma pasta chamada libs e incluir dois arquivos nela.

Para ignorar vamos criar o arquivo .gitignore e definir o que gostariamos de ignorar

Ignorando arquivos (não rastreando)

# 4 Versionando

 

O .gitignore usa padrões globbing para fazer a comparação dos nomes de arquivos. Ex:

  • **/logs - Padrão com um asterisco duplo para combinar diretórios em qualquer lugar no repositório.
  • *.log - Um asterisco é um curinga que corresponde a zero ou mais caracteres.
  • !important.log - Ignora um padrão
  • debug[0-9].log - Colchetes podem ser usados para corresponder a um único caractere de um intervalo especificado.

Fonte: https://git-scm.com/docs/gitignore

Ignorando arquivos (não rastreando)

# 4 Versionando

 

Importante comitar o .gitignore

Fonte: https://git-scm.com/docs/gitignore

Ignorando um arquivo após o commit

# 4 Versionando

 

$ echo debug.log >> .gitignore
$ echo '*.txt' >> .gitignore

$ git rm --cached debug.log
rm 'debug.log'
$ git rm --cached nome.txt
rm 'nome.txt'

$ git add .gitignore
$ git commit -m "Ignorando debug.log e arquivos .txt"

Vamos criar os arquivos chamado debug.log e nome.txt, em seguida commitar

Vamos realizar o processo para remover.

Vamos ver nosso histórico com mais detalhes

# 4 Versionando

 

$ git log -p
$ git log -p -2 #últimos 2 commits

Fonte: https://git-scm.com/docs/git-log

Vamos ver nosso histórico com mais detalhes

# 4 Versionando

 

$ git log --stat
$ git log -3 --stat #últimos 3 commits

Vamos ver nosso histórico com mais detalhes

# 4 Versionando

 

$ git log --graph --decorate --pretty=oneline --abbrev-commit

Dica: git config --global alias.tree "log --graph --decorate --pretty=oneline --abbrev-commit"

Cria um apelido para um outro comando

Branch

# 4 Versionando

 

Nota: git tree = "git log --graph --decorate --pretty=oneline --abbrev-commit"

Um branch no Git é simplesmente um ponteiro móvel leve para um commit. O nome da branch padrão no Git é a master . Conforme você começa a fazer commits, você recebe um branch master que aponta para o último commit que você fez. Toda vez que você confirma, o ponteiro do branch master avança automaticamente.

git checkout -b vava

Branch

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-branch

https://git-scm.com/docs/git-checkout

Branch

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-branch

Deletar uma branch

Listando Branchs

Branch

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-branch

Vamos experimentar:

  1. Crie uma branch chamada "funcionalidade1"
  2. Faça 2 commits na branch "funcionalidade1" com novos arquivos
  3. Retorne a branch master
  4. Liste os arquivos contidos no repositório
  5. O que ocorreu?

Merge

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-merge

Juntar dois ou mais históricos de desenvolvimento

Rebase

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-rebase/pt_BR

Reaplicar commits em cima de outra ramificação (base)

Vamos verificar como ficou nossa árvore de commits

Stash

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-stash

O Stash é útil quando queremos tirar temporariamente arquivos do stage para utilizar posteriormente.

Remove do stage e inclui no stash

Aplica o stage na branch atual

Stash

# 4 Versionando

 

Fonte: https://git-scm.com/docs/git-stash

Criando um nome para o Stash

Aplicando um stash específico

Limpando os stash's salvos

Resumindo

# 4 Versionando

 

1

Sistema de Versão

2

Git

3

Configuração Git

5

Remoto

4

Versionando

6

Interface Gráfica

Tem remoto?

$ git remote -v
$ git remote --verbose 

# 5 Remoto

Fonte: https://git-scm.com/docs/git-remote

# 5 Remoto

O GitLab é um gerenciador de repositório de software baseado em git, com suporte a Wiki, gerenciamento de tarefas e CI/CD.

  • Software Livre
  • Permite que os desenvolvedores armazenem o código em seus próprios servidores 
# 5 Remoto

Quem usa?

Fonte: https://pt.wikipedia.org/wiki/GitLab

# 5 Remoto

História

Fonte: https://pt.wikiversity.org/wiki/GitLab

2013

Produtos

Em Julho  ouve a separação em dois produtos:

  • Gitlab (CE) Comunity Edition
  • Gitlab (EE) Enterprise Edition

2014

Open Core

Adoção do modelo 'Open Core'. Assim mudando a licença MIT do produto Gitlab EE para licença proprietária contendo alguns aspectos a mais que o produto Gitlab CE.

Início

O software foi escrito originalmente por Dmitriy Zaporozhets (atual CTO), da Ucrânia  em 2011, era chamado GitLab sendo totalmente de graça e open source, distribuído sob a Licença MIT.

2011

# 5 Remoto

E vamos criar nosso primeiro repô remoto

  1. Criar uma conta no https://gitlab.com
  2. Criar um novo projeto https://gitlab.com/projects/new 
# 5 Remoto

E vamos criar nosso primeiro repô remoto

Vamos as opções..

  1. Podemos clonar o repositório utilizando SSH ou HTTPS
  2. Existem possibilidades caso:
    1. Seja um novo repositório
    2. Já exista o repositório localmente
    3. Já exista o repositório localmente com um remoto diferente

Text

https://gitlab.com/Vanilton18/git-whatever.git

# 5 Remoto

E vamos incluir o remoto a nosso repositório local

Agora vai..

  1. Vamos utilizar o protocolo TCP/IP HTTPS dado que pra SSH devemos configurar chaves (veremos depois como configura)
  2. Como ja possuímos um repositório local vamos incluir apenas o remoto.

Nome convenção

Pode haver mais de um

Dica: A configuração do remoto pode ser vista através do git config --list

Enviar

Baixar

# 5 Remoto

E vamos enviar nosso commits para o remoto no GitLab

  1. Para enviar o conteúdo de nosso repositório local devemos utilizar o git push 
# 5 Remoto

Agora é só confirmar os arquivos enviados para o remoto

# 5 Remoto

E se eu quiser só puxar do remoto?

git clone https://repositorio.git nome_da_pasta

# 5 Remoto

Vamos ver nossas brachs

  • git branch
  • git branch -a
# 5 Remoto

Vamos realizar o checkout de uma branch do remoto

  • git checkout -b nome_branch_local origin/nome_branch_no_remoto
# 5 Remoto

Vamos experimentar atualizar nosso local a partir do remoto

$ git fetch origin # Busca de todas as branches
$ git pull # Puxa de acordo com HEAD 
$ git pull origin master # Puxa de acordo com a origem (remoto)
  1. O professor irá alterar o arquivo README.md
  2. Comitar a modificação
  3. Puxar a partir do repositório local

 

# 5 Remoto

Se localizando na árvore do git

  1. Vamos simular uma "nova funcionalidade", para isso crie uma nova linha no arquivo README.md
  2. Faça o commit 
  3. Checar o status
  4. Verificar a árvore
  5. Faça o Push
# 5 Remoto

Tá lindo, mas pode conflitar..

Vamos simular um conflito

  1. Alunos criem um novo commit Alterando  o README.md 
  2. O Professor alterará o arquivo só que diretamente no remoto
  3. Agora vamos fazer um "git fetch origin" para atualizar nossas branchs e um "git status"

Cadê a origem que estava aqui!

# 5 Remoto

Tá lindo, mas pode conflitar..

  1. Vamos fazer o pull (baixar) do remoto
  2. O que vai acontecer?
  3. Resolver o conflito
# 5 Remoto

Matando o conflito..

  1. Comitar as modificações
  2. Fazer o push
  3. Verificar nossa árvore
# 5 Remoto

SSH - Secure Shell

Fonte: https://pt.wikipedia.org/wiki/Secure_Shell

É um protocolo de rede criptográfico para operação de serviços de rede de forma segura sobre uma rede insegura. O melhor exemplo de aplicação conhecido é para login remoto de utilizadores a sistemas de computadores.

# 5 Remoto

E como eu crio a chave SSH com o git?

Fonte: https://git-scm.com/book/pt-pt/v2/Git-no-Servidor-Generating-Your-SSH-Public-Key

Com poucos passos conseguimos configurar nossa chave pública e privada (local) e associar ao remoto

  1. Gerar as chaves 
    1. id_rsa.pub (pública)
    2. id_rsa (privada)
  2. Você pode criá-los executando um programa chamado ssh-keygen, que é fornecido com o pacote SSH em sistemas Linux/Mac e vem com o Git para Windows:

chave pública

# 5 Remoto

Agora basta associar ao remoto

  1. Acessar Preferencias do seu usuário no gitlab

2. Agora basta adicionar sua chave pública gerada. Prontinho pode usar o repositório remoto com SSH.

$ git remote set-url origin git@gitlab.com:Vanilton18/git-whatever.git
# 5 Remoto

O que vimos até aqui...

  • push
  • pull
  • clone
  • fetch
  • remote
  • merge
  • rebase
  • branch
  • stash
  • ignore
  • status
  • log
  • log com gráfico
  • add
  • rm
  • reset
  • checkout
  • switch
  • commit (amend e com add)

1

Sistema de Versão

2

Git

3

Configuração Git

5

Remoto

4

Versionando

6

Interface Gráfica

Clientes Git

# 6 Interface Gráfica

Por meio dos clientes git podemos realizar todas as ações realizadas no terminal com ganhos de produtividade.

Vamos utilizar o PyCharm da JetBrains

# 6 Interface Gráfica
  1. Instale o PyCharm CE (Community)

2. Importar o projeto que já criamos no git

Fonte: https://www.jetbrains.com/help/pycharm/using-git-integration.html

Vamos utilizar o PyCharm da JetBrains

# 6 Interface Gráfica
  1. Ver nosso repositório agora, podemos usar o terminal do próprio PyCharm

.idea/ gerada pela IDE

2. Como é uma pasta gerada para cada usuário, vamos incluí-la no .gitignore.

Vamos utilizar o PyCharm da JetBrains

# 6 Interface Gráfica
  1. Já sabemos visualizar os status pelo terminal agora vamos checar isso na IDE
  2. Agora temos a lista de arquivos alterados pendentes de commit, abra o arquivo e vamos poder visualizar a diferença do arquivo comitado para o alterado.

Vamos utilizar o PyCharm da JetBrains

# 6 Interface Gráfica
  1. Agora vamos comitar nossa alteração pela interface gráfica

Comitar local

Comitar e enviar para o remoto

Visualizar o histórico

# 6 Interface Gráfica
  1. Para exibir o log podemos acessar o Show Git Log

Agora vamos experimentar resolver um conflito

# 6 Interface Gráfica
  1. Façam alterações no repositório e enviem o commit (push) para o remoto.
  2. Alguém irá realizar o envio primeiro para o remoto e fatalmente alguém terá que realizar o Merge após tentar um Push :)

Agora vamos experimentar resolver um conflito

# 6 Interface Gráfica
  1. Agora vamos resolver..

Merge = Novo Commit

Atualizar seu repositório com o remoto

# 6 Interface Gráfica
  1. Atualizar a branch atual com o remoto
  2. Busca as alterações de todas as raízes e branches do projeto e mescla as branches remotas rastreadas em sua cópia de trabalho local (equivalente a pull)

Criando Branch e enviando ao remoto

# 6 Interface Gráfica
  1. Crie uma branch com seu nome
  2. Faça o Push para o remoto
  3. Agora realize uma alteração na sua branch e faça o push
  4. Vamos verificar as alterações trocando de branch

Shelve (deixando pra depois)

# 6 Interface Gráfica
  1.  Altere um arquivo e clique com o direito sobre ele na lista de alterações
  2. Salve o Shelve

Nota: Shelves são salvar em .idea/shelf

Filtrando branchs

# 6 Interface Gráfica

Merge entre branchs

# 6 Interface Gráfica
  1. Vamos ver onde está nosso HEAD
  2. Faça checkout de sua Branch
  3. Clique com o direito na branch que deseja puxar para a sua
  4. Faça o merge

Git Reset 

# 6 Interface Gráfica
  1. git reset --soft
  2. git reset --mixed (default)
  3. git reset --hard

Reinicia a árvore sem perder o conteúdo dos commits, e incluindo os arquivos em stage

Reinicia a árvore sem perder o conteúdo dos commits, porém não incluindo os arquivos em stage

Reinicia a árvore e perde o conteúdo dos commits anteriores, mantendo apenas os arquivos do commit selecionado

Git Reset 

# 6 Interface Gráfica

Git Flow

# 6 Interface Gráfica

O Git Workflow é uma receita ou recomendação de como usar o Git para realizar o trabalho de maneira consistente e produtiva. Há vários Git Workflows divulgados que podem ser uma boa opção para sua equipe. ​

Fixa

Descartáveis

Git Flow - Feature

# 6 Interface Gráfica

feature/nome_da_feature

Git Flow - hotfix

# 6 Interface Gráfica

hotfix/nome_do_hotfix

Git Flow - develop

# 6 Interface Gráfica

develop

Git Flow - master

# 6 Interface Gráfica

master

Rebase Interativo

# 6 Interface Gráfica

Vamos simular a implementação de uma feature

  1. Criar uma branch "Develop"
  2. Criar uma branch a partir da develop "feature/minha_feature"
  3. Alterar o README.md para "Começando minha feature" e commitar "Commit 1".
  4. Vamos criar mais 2 commits "Commit 2 e 3" para cada um deles incrementando mais o arquivo README.md.
  5. Por fim faça o Push para o remoto

Rebase Interativo 

# 6 Interface Gráfica

Vamos renomear os commits com Rebase

De baixo para cima para recriar a árvore

Rebase Interativo - Renomeando commits

# 6 Interface Gráfica

Após renomear os commits vamos iniciar o rebase

Minha origem se mantem no Commit 3

Uma nova ramificação é criada para eu remanejar os commits para a árvore principal

Rebase Interativo - Renomeando commits

# 6 Interface Gráfica

E por fim ajustamos a árvore 

Sobrescreve o remoto com seu local "git push --force"

Fonte: https://git-scm.com/docs/git-push

Rebase Interativo - Drop

# 6 Interface Gráfica

Temos como realizar o rebase removendo commits

Como temos alterações no arquivo devemos fazer o merge e definir o que ficará no mesmo

Rebase Interativo - Drop

# 6 Interface Gráfica

Temos como realizar o rebase removendo commits

Depois de um force Push pronto temos a arvore reestruturada sem o commit 1

Rebase Interativo - Squash

# 6 Interface Gráfica

Também podemos unir commits em apenas um, o que é chamado de squash

Depois de um force Push pronto temos a arvore reestruturada com apenas o commit 2 com o conteúdo do 3

Rebase Interativo - Squash

# 6 Interface Gráfica

Renomeando o commit e fazendo o push para integrar com a develop

Com o commit renomeado ficará limpo o commit inserido na develop

Rebase - Branch com Branch

# 6 Interface Gráfica

Restruturar a develop para uma nova branch

  1. Vamos criar um nova branch "feature/joazin" a partir da "develop"
  2. Alterar o README.md com uma nova linha
  3. Comitar e fazer um push para o remoto

Rebase - Branch com Branch

# 6 Interface Gráfica

Restruturar a develop para uma nova branch

  1. Vamos fazer checkout da develop
  2. Rebase / Merge com a branch do "feature/joaozin"
  3. Faça Force Push para a develop :)

Só será gerado um novo commit com merge se houver conflito

git rebase --onto develop feature/joazin

Rebase - Branch com Branch

# 6 Interface Gráfica

Agora vamos estruturar a branch feature/vanilton 

  1. Vamos fazer checkout da feature/vanilton
  2. Rebase com a branch do "develop"

Minha remoto ficou para trás, vamos restruturar fazendo o Force Push

Rebase - Branch com Branch

# 6 Interface Gráfica

Agora vamos estruturar a branch vanilton 

  1. Com a árvore estruturada, agora basta voltar para develop
  2. Puxar a atualização da branch feature/vanilton
  3. Fazer Push para a develop no remoto

GitLab - Configurações

# 6 Interface Gráfica
  1. Gerais
  2. Integrações
  3. Webhooks
  4. Repositório
  5. CI/CD
    1. Runners

GitLab - Importante conhecer

# 6 Interface Gráfica
  1. Repositório
    1. Commits
    2. Branchs
    3. Tags
  2. Issues
  3. Board
  4. Wiki

GitLab - Merge Request

# 6 Interface Gráfica
  1. Vamos desenvolver um script python para realizar as operações matemáticas de adição, subtração, divisão, multiplicação.
  2. Para cada operação desenvolvida vamos abrir um Merge Request ou Pull Request
    • Vamos verificar como resolver conflitos em MR
  3. Code Review 
    • Correção de review

GitLab - Merge Request

# 6 Interface Gráfica

GitLab - Merge Request

# 6 Interface Gráfica

GitLab - Pipeline

# 6 Interface Gráfica
  1. Possuir um runner compartilhado ou dedicado https://docs.gitlab.com/runner/register/

  2. Configurar os estágios do pipeline no .gitlab-ci.yml

  3. Configurar as regras de execução

vanilton18@gmail.com

Vanilton Pinheiro

Me encontre em...

/vaniltonpinheiro

/in/vaniltonpinheiro

/vaniltonpinheiro

Referências >>

Ignore

https://www.atlassian.com/br/git/tutorials/saving-changes/gitignore​

Git Básico

https://pt.slideshare.net/AndrJusti/git-bsico-72882356

Sistemas de Versionamento

https://mazer.dev/controle-de-versao-o-que-e/

https://platzi.com.br/blog/importancia-dos-sistemas-controle-versao/