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

Instalar Git (Link)
- Mac - Instalar o Xcode e Homebrew
Instalar PyCharm (Link)
Opcional
- Shell (Linux e Mac)
  - https://ohmyz.sh/
- 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

Um sistema de controle de versões (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software que tem a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer.

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

Controle de Versão

# 1 INTRODUÇÃO

Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões — histórico e desenvolvimento — dos códigos-fontes e também da documentaçã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

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

Git é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo.
O Git foi baseado na ferramenta proprietária chamada BitKeeper

# 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

Abrir o git bash
Criar uma pasta com nome "git"
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

Criar uma pasta chamada "Project" dentro de nossa pasta git
Acessar a pasta

$ git init

Vamos configurar nosso primeiro repositório git

# 3 Configuração

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

nano README.md
Escreva: Olá Mundo!
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

nano README.md
Inclua: Primera alteração no arquivo..
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

Corrigir antes do envio para remoto
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

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

Altere a mensagem do commit "Primeiro commit corrigido"

Verde (em Stage)

Altera mensagem do commit
Comitar o que está em stage

Corrigindo commit - amend

# 4 Versionando

Vamos confirmar que o amend inclui o que está no stage
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:

Crie uma branch chamada "funcionalidade1"
Faça 2 commits na branch "funcionalidade1" com novos arquivos
Retorne a branch master
Liste os arquivos contidos no repositório
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?

É usado por mais de 100 000 organizações, entre elas:
- IPqM (Marinha do Brasil)
- IBM
- Serpro (Serviço Federal de Processamento de Dados)
- NASA, Alibaba, Invincea, O’Reilly Media, CERN, Projeto GNOME, SpaceX
- FPF Tech

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

Criar uma conta no https://gitlab.com
Criar um novo projeto https://gitlab.com/projects/new

# 5 Remoto

E vamos criar nosso primeiro repô remoto

Vamos as opções..

Podemos clonar o repositório utilizando SSH ou HTTPS
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..

Vamos utilizar o protocolo TCP/IP HTTPS dado que pra SSH devemos configurar chaves (veremos depois como configura)
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

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)

O professor irá alterar o arquivo README.md
Comitar a modificação
Puxar a partir do repositório local

# 5 Remoto

Se localizando na árvore do git

Vamos simular uma "nova funcionalidade", para isso crie uma nova linha no arquivo README.md
Faça o commit
Checar o status
Verificar a árvore
Faça o Push

# 5 Remoto

Tá lindo, mas pode conflitar..

Vamos simular um conflito

Alunos criem um novo commit Alterando o README.md
O Professor alterará o arquivo só que diretamente no remoto
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..

Vamos fazer o pull (baixar) do remoto
O que vai acontecer?
Resolver o conflito

# 5 Remoto

Matando o conflito..

Comitar as modificações
Fazer o push
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

Gerar as chaves
1. id_rsa.pub (pública)
2. id_rsa (privada)
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

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

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

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

Já sabemos visualizar os status pelo terminal agora vamos checar isso na IDE
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

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

Para exibir o log podemos acessar o Show Git Log

Agora vamos experimentar resolver um conflito

# 6 Interface Gráfica

Façam alterações no repositório e enviem o commit (push) para o remoto.
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

Agora vamos resolver..

Merge = Novo Commit

Atualizar seu repositório com o remoto

# 6 Interface Gráfica

Atualizar a branch atual com o remoto
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

Crie uma branch com seu nome
Faça o Push para o remoto
Agora realize uma alteração na sua branch e faça o push
Vamos verificar as alterações trocando de branch

Shelve (deixando pra depois)

# 6 Interface Gráfica

Altere um arquivo e clique com o direito sobre ele na lista de alterações
Salve o Shelve

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

Filtrando branchs

# 6 Interface Gráfica

Merge entre branchs

# 6 Interface Gráfica

Vamos ver onde está nosso HEAD
Faça checkout de sua Branch
Clique com o direito na branch que deseja puxar para a sua
Faça o merge

Git Reset

# 6 Interface Gráfica

git reset --soft
git reset --mixed (default)
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

Criar uma branch "Develop"
Criar uma branch a partir da develop "feature/minha_feature"
Alterar o README.md para "Começando minha feature" e commitar "Commit 1".
Vamos criar mais 2 commits "Commit 2 e 3" para cada um deles incrementando mais o arquivo README.md.
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

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

Rebase - Branch com Branch

# 6 Interface Gráfica

Restruturar a develop para uma nova branch

Vamos fazer checkout da develop
Rebase / Merge com a branch do "feature/joaozin"
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

Vamos fazer checkout da feature/vanilton
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

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

GitLab - Configurações

# 6 Interface Gráfica

Gerais
Integrações
Webhooks
Repositório
CI/CD
1. Runners

GitLab - Importante conhecer

# 6 Interface Gráfica

Repositório
1. Commits
2. Branchs
3. Tags
Issues
Board
Wiki

GitLab - Merge Request

# 6 Interface Gráfica

Vamos desenvolver um script python para realizar as operações matemáticas de adição, subtração, divisão, multiplicação.
Para cada operação desenvolvida vamos abrir um Merge Request ou Pull Request
- Vamos verificar como resolver conflitos em MR
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

Possuir um runner compartilhado ou dedicado https://docs.gitlab.com/runner/register/
Configurar os estágios do pipeline no .gitlab-ci.yml
Configurar as regras de execução